Goals and Non-Goals

[stasm]

Related to #49 and #50. I think it would be helpful to create a list of goals which we want to accomplish as the WG, as well as non-goals to help us stay focused.

I find the group's charter to be well written; it already contains a number of deliverables (emphasis mine):

The Message Format Working Group (MFWG) is tasked with developing an industry standard for the representation of localizable message strings to be a successor to ICU MessageFormat. MFWG will recommend how to remove redundancies, make the syntax more usable, and support more complex features, such as gender, inflections, and speech. MFWG will also consider the integration of the new standard with programming environments, including, but not limited to, ICU, DOM, and ECMAScript, and with localization platform interchange. The output of MFWG will be a specification for the new syntax, which is expected to be on track to become a Unicode Technical Standard.

Personally, I think this is a great definition of what I'd hope the WG will accomplish. I'm not sure if that's a general sentiment, however, which is why I'm filing this issue.

To rephrase the above in terms of explicit goals:

Goals

• Design a data model for defining translation units (messages).
• Support many-to-many translations between the source and the target languages.
• Design a canonical syntax for describing the message data models.
• Ensure interoperability with existing interchange formats like XLIFF.
• Design an API for formatting translation units given some input arguments (to be interpolated in the translation).

[stasm]

I'd also like to add an (opinionated) list of non-goal examples to consider:

Non-Goals

• Design a general interchange format, like XLIFF.
• Support every grammatical feature possible.
• Create an engine capable of transforming parts of speech in a grammatically-correct fashion.
• Create optimized and efficient implementations of the standard.
• Build a framework for localizing software.

[eemeli]

Based on the discussion on the need for a runtime format, I think the data model should not only represent individual messages, but also the full resource (i.e. set of messages). This will allow for a place to store essential metadata about the messages which would otherwise need to be repeated for each separately, such as the locale. Furthermore, any actual runtime implementation will be interested in being able to deal with sets of messages, rather than only treating them individually.

To be clear, this is completely independent of the canonical syntax allowing or not allowing for any references between messages.

[stasm]

I opened PR #77 with a draft of a goals and non-goals document.

[stasm]

77 was merged yesterday. Thanks to everyone for a productive discussion!