Concrete message format use case

[romulocintra]

As we discussed in the last meeting, the group will propose a use case to be worked on for the next meeting.

Goals:

• Allow to have the practical experience and generate tangible output to be discussed next session.
• Apply the abstractions and comments we had on our MF long journey.
• Review all design principles and design process
• Failure and recovering :)

Process:

• All proposals must be in comments the ones with more thumbs up will be considered in the next Chair Group Meeting to be a candidate for the work described above.

[romulocintra]

cc @stasm @nbouvrette @rxaviers @eemeli

[eemeli]

My proposal for a first issue: The shape of multiple-choice selectors.

In MF1, we have plural, selectordinal and select, i.e. a specific set of selectors that each take some variable as input, and then select a case based on selector-specific logic. The first two also include offset as an optional argument.

In Fluent, there is only one selector, but it allows the input variable to be modified or formatted before the case is selected. For instance, the input variable may be wrapped by a NUMBER() function that determines how the plural category is chosen if an exact match isn't found for numeric input. This allows for all three types of MF1 selectors to be represented in Fluent.

We should decide how this should work in MF2.

[zbraniecki]

I agree with that proposal.

@stasm - If we decide to tackle this one, it may be also useful to extract the list of planned features for our selector (flatten selector, list selectors etc.) for the drawing board.

[zbraniecki]

hi all. @echeran suggested we start an experiment with rapid prototype in Rust - https://github.com/zbraniecki/message-format-2.0-rs

This is not intended to be any form of canonical representation of the work of this group, and I believe there's room for others to start other experiments :)

We'll wait for the group to agree on what scope we should target first and try to design a basic data model in AST plus maybe a trivial parser to work with it.

I invited @stasm, @sffc, @echeran and @mihnita to collaborate and if anyone else from this group wants to join, please let me know and I'll add you.

[stasm]

Thanks for bootstrapping the prototype implementation. I think it might be helpful for some to think about the data model through the lens of code.

For the next meeting, I'd like to suggest that we take the use-case @eemeli proposed, come up with a few actual examples (messages with English copy and translations), and then try to encode them into structures in various data models. My personal preference would be to represent the data model with XML or JSON. Everyone knows them; they're easy to write, read, and validate.

I'd store everything in a directory here on GitHub, and discuss different data model ideas in PRs. I'll start by preparing an example copy and its translation.

[rxaviers]

@eemeli proposal LGTM

[romulocintra]

Thanks, @zbraniecki for setup this repository. Next Monday's meeting I think we should talk about how we gonna handle these experiments/POC's.

@eemeli proposal sounds the most convenient to start.

@stasm LGTM

I'd store everything in a directory here on GitHub, and discuss different data model ideas in PRs. I'll start by preparing an example copy and its translation.

[romulocintra]

I think is related #85