Charter

[sffc]

I'm working on getting this working group somewhat more formalized under the Unicode Consortium. As a first step I need a charter (no more than a paragraph) layout out the scope of the group and the expected end result. Here's my first draft. Please leave feedback:

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.

[zbraniecki]

New syntax or new data model or both?

You mention features that are data model and syntax related, is API part of the conversation or would it be separate?

I feel like our experience from working on Fluent made the API part of the conversation about syntax because ergonomics, separation of concerns, principle of least power, and error recovery required end-to-end cycle monitoring which involves API as well.

[eemeli]

Overall, this sounds excellent. I do have a concern about this bit though:

[...] including more complex features, such as gender, inflections, and speech, that are not first-class features in the current syntax.

To me, this makes it seem like we're primarily focused on adding features and complexity to MessageFormat. I don't think that's necessarily a desirable design goal, though it may be a result of our work. Instead, I would see more value in focusing on removing redundancies and otherwise making the syntax more usable by a wider audience.

[sffc]

New syntax or new data model or both?

It's not clear we have consensus yet on exactly the scope (whether we want to tackle syntax, data model, or both).

You mention features that are data model and syntax related, is API part of the conversation or would it be separate?

I feel like our experience from working on Fluent made the API part of the conversation about syntax because ergonomics, separation of concerns, principle of least power, and error recovery required end-to-end cycle monitoring which involves API as well.

My idea is to put the specific Intl API is out of scope for the time being, although we should "consider" the impact on ECMAScript and maybe make a recommendation to ECMA-402. ECMAScript is not our only target. I added some language clarifying that: "programming environments, including, but not limited to, ICU and ECMAScript"

To me, this makes it seem like we're primarily focused on adding features and complexity to MessageFormat. I don't think that's necessarily a desirable design goal, though it may be a result of our work. Instead, I would see more value in focusing on removing redundancies and otherwise making the syntax more usable by a wider audience.

I added those two points to the OP, and made it say "recommend how to support more complex features" to clarify that while we want to provide a framework to support these new features, we don't necessarily need to put them in our initial spec. Does that sound ok?

[eemeli]

I added those two points to the OP, and made it say "recommend how to support more complex features" to clarify that while we want to provide a framework to support these new features, we don't necessarily need to put them in our initial spec. Does that sound ok?

Yes, now it's good. Having more than one point included underlines the fact that we're exploring this space, rather than having a predetermined direction and target.

[zbraniecki]

My idea is to put the specific Intl API is out of scope for the time being, although we should "consider" the impact on ECMAScript and maybe make a recommendation to ECMA-402. ECMAScript is not our only target

What about DOM? Should DOM be one of the targets? As I mentioned on the call, I struggle to imagine a localization format for JS that misses on the opportunity to also address the DOM, and if we do aim for both, we're basically aiming for some sort of WebL10n standard with, likely, some form of declarative API for it.

If we want to narrow it down to "something that can be imperatively called from a programming language", then we exclude DOM from our considerations and may end up with a significantly suboptimal proposal for the Web forcing some future DOML10n API to use a different system.

[sffc]

Added DOM as one of the example targets alongside ECMAScript and ICU.

[romulocintra]

Great work sounds excellent !!!

I have just a little "something" about this this extract :

MFWG will recommend how to remove redundancies, make the syntax more usable, and support more complex features, such as gender, inflections, and speech.

IMHO this should sound more generic and not just an the enumeration of features or duties

MFWG will be responsible for creating procedures and recommend the best practices to remove redundancies, make the syntax more usable, and support more complex features, such as gender, inflections, and speech"

What do you think about ?

[sffc]

Thanks for the suggestion; although, I don't see how your new wording changes the paragraph. It looks like a lot of words and makes the sentence a bit weaker and more confusing. I think it is in the scope of MFWG to issue recommendations; I don't think we need it to sound more generic.

[romulocintra]

@sffc previous wording was already good to me. My intention or suggestion was related more with the "meaning"; not exact wording.

I believe the message should be something like "We not cover only this list of things but we are responsible for more than that ... ". but as i said the paragraph LGTM