Selection method expectations #425
Description
In the following, the (a), (b), etc. may be used to refer to individual messages.
For formatting, I believe that it's relatively uncontroversial to expect that with an en-US message (a)
{Foo is {$foo}}
formatting it to a string with { foo: 'bar' } would result in Foo is bar while formatting it to a string with { foo: 1234 } would result in Foo is 1,234 rather than Foo is 1234.
In other words, we would expect a numerical value to be formatted according to the current locale, even if the type of the value is not made explicit in the message.
Separately, I also believe that it's almost as uncontroversial to expect that with an en-US message (b)
match {$foo}
when bar {Foo is bar}
when * {Foo is other}
formatting it to a string with { foo: 'bar' } would result in Foo is bar.
However, going further from this I believe we encounter less agreement. Specifically, with an en-US message (c)
match {$foo}
when one {{$foo} foo}
when * {{$foo} foos}
should formatting it to a string with { foo: 1 } result in 1 foo or 1 foos?
In fact, we may disagree on the results even with an en-US message (d)
let $bar = {$foo :number}
match {$bar}
when one {{$bar} foo}
when * {{$bar} foos}
when formatting it to a string with { foo: 1 }; should that result in 1 foo or 1 foos?
On a related note, we probably do want to define what happens when an en-US message (e)
match {$foo :number}
when |1,234| {Localized match}
when 1234 {Numeric match}
when * {No match}
is formatted with { foo: 1234 }, because there an argument could be made for any variant.
I think we should make explicit determinations
- whether to assign "plural" or "select" treatment to numbers, and
- whether to apply the same sort of built-in type casting during selection as formatting.
As I see it, this is in part a discussion on how do we want to conceptually present our selection or matching expressions. In MF1, one of the keywords select, plural, selectordinal is always required. In MF2, we only use match. Therefore we've effectively left it open so far whether with regard to selection we want to use methods that imply that we are performing e.g. "plural selection" or "select selection" as in MF1, or if we're performing "selection on a number" or "selection on a string".
In #420 we are adding at least the number and datetime formatting functions to our base registry. I think at least one of the following additional functions is needed to deal with selection:
pluralselectstring
With just plural, we would in general default to "select selection" and require its explicit use for plural category consideration. The (e) message would still require some special consideration of numbers.
With just select, we would default to "plural selection" for numbers and "select selection" otherwise. Using select on a number would explicitly opt out of its plural category consideration, and would need to define what happens in (e).
With string, the behaviour would in practice be the same as with select, but the conceptual sense of what's happening with expressions used for matching is different: the input value is in a sense cast to the given type, which comes with given selection behaviour.
The question of whether to require some explicit function on each selector (i.e. the difference between messages (c) and (d)) may be considered separately. For example, one of plural/select or number/string could always be required.