FTL Proposal: Enforce default variant/trait

[zbran...@mozilla.com]

In the thread about bi-annual syntax review, I listed a number of potential problems with the syntax.

In this proposal, I'd like to tackle mainly problem (1) and (2).

Summary:

It would be beneficial to enforce on the level of syntax that each selector should have exactly one default member.
For traits, the default trait would be required only if there is no value.


Counterarguments:

>From early feedback to this proposal, the only counter argument I can see is added overhead and added visual clutter to the syntax in scenarios where without this proposal, localizer would chose not to mark any variant/trait as default.

Response:

I believe that it's a reasonable price to pay for additional resilience, improved tooling experience and forward compatibility.


Alternative proposals:

There are two other solutions we could try:

1) We could define a named default variant, like "other".

That's what MessageFormat does. The cons against it is that it's implicit, requires "other" to be always present (while sometimes the default shouldn't be "other", but, for example, "nominative") and it doesn't work that well for traits.

2) We could use other syntax to annotate the default variant. For example:

key = { OS() ->
[[win]] Windows
[mac] Mac
[lin] Linux
}

or:

key = { OS() ->
(win) Windows
[mac] Mac
[lin] Linux
}

In my opinion the former looks more cryptic and the latter not visible.

The asterisk mark, that we chose to resemble UI paradigm of a list with a selected option, seems to be easy to understand and gets good feedback.

Thoughts?
zb.

[Staś Małolepszy]

There's a related discussion in l20n/spec:

https://github.com/l20n/spec/issues/7
https://github.com/l20n/spec/pull/10

The final syntax depends on how we choose to solve variants vs. traits
in your other thread. I'd prefer to avoid creating new syntax just
for this. If we keep the asterisk syntax for select expression's
variants, I'd suggest we use it for here as well.