Eemeli Aro

A separate [working group on message resources](https://github.com/eemeli/message-resource-wg) is now being bootstrapped.

As an observation, based on the likely outcome of #103 to support top-level selectors with multiple input variables, this is going to create a desire for a human-accessible file format...

@Janpot & @ray007, could you expand a bit on why you've reacted to the above with a 👎? Is it that you don't think we should specify a file format,...

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...

I posted my degenerate-case message example in [this comment](https://github.com/unicode-org/message-format-wg/issues/103#issuecomment-696322838) on #103.

> Are `{button}`, `{/button}`, `{link}`, and `{/link}` also placeholders? I would say yes. I think _placeholder_ is a catch-all term for a container within a message that can either hold...

@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...

> Implementing MessageFormat v1 behavior compatibility for plural requires best match functionality (so that something like `{foo, plural, one {...} =1 {...} other {...}}` matches `=1` if `foo` is 1)...

> I don't understand @eemeli the part where you say `until a match succeeds`, since necessarily one needs to get more than one candidate for the second selector to consider....

I would consider a minimum level of compatibility being reached by being able to parse MF1 syntax into the MF2 data model, and to be able to then have it...