Design Principle: Compatible vs. Breaking

[stasm]

A dedicated issue for discussing a newly proposed design dimension, similar to those proposed in #50.

Compatible vs. Breaking

Do we want the standard to be compatible with MF1? To which extent? Should we only focus on enabling a one-time migration from MF1 to MF2?

Do we expect localization vendors and tools to adapt to the standard, or do want the standard to adapt to the current localization roundtrip workflows?

[DavidFatDavidF]

IMHO, this sets two compatibility axes..
1)
WRT, compatibility with the old message format. It seems clear that there will have to be breaking changes, otherwise there wouldn't be need for the new format, see #49 and #84
I think that this axis consideration has the corollary that the new format should be modularized and allow for retiring features as well as for introduction of new features..
2)
WRT compatibility with L10n roundtrip I obviously support being compatible with the XLIFF 2 data model. On this axis, it is possible to request new modular features but it's pretty much impossible to request core changes.
See e.g. OASIS XLIFF Version 2.1 or XLIFF, JLIFF, and LIOM intro slides

[ray007]

It seems the end result will not be compatible with MF1, has nothing to do with ICU MessageFormat, why still call it MessageFormat?

[romulocintra]

It seems the end result will not be compatible with MF1, has nothing to do with ICU MessageFormat, why still call it MessageFormat?

Hi @ray007 the intention it's to follow the goals agreed in our Guidelines and work in the evolution of MF1 where the retro compatibility is important but should not limit the design of MF2. We welcome you to give us more feedback about your thoughts and participate in our monthly calls, next one will happen it's next Monday please find details here #215 and more info about joining the group here

[ray007]

That's all nice, but when it's not compatible with any MessageFormat anymore it should get a new name.
Adding a 2 at the end is not enough and might mislead people looking for something with MessageFormat syntax.

[eemeli]

@ray007 What would you consider to be required for being "compatible with MF1"? For example, would it be sufficient for the spec to define how MF1 message content would be parsed in an MF2 context?

[ray007]

If it can use the old MF1 syntax without changes, then yes, but I'd call it "legacy support" or something like that.
But with the new syntax being different (and not only an extension of the old one), it still feels off to use the same name.

[aphillips]

This issue has been resolved: we are using an incompatible syntax.