Given that we already have a :number,
it makes sense to add a <matchSignature> to it with an option

Sorry, but it is not that obvious.
:number is not a question, so one can't decide on it.

You have to ask a question about the number.

"Hey, :number 43?"
Is that true or false? If you answer correctly you win 1000$"

That means nothing. It is not a good question.

Hey, :number 43 is even?" is a question, you can answer.
Hey, :number 43 is prime?" is a question, you can answer.
Hey, :number 43 is plural?" is a question, you can answer.

There are two questions here.

The first is: should the :number function used for formatting also do selection? @eemeli has already pointed out that we want users to use the same configuration for selection (e.g. with :plural) as will ultimately be used to format the number. This message produces grammatically inferior results:

.local $tenths = {$num :number minFractionDigits=1}
.match {$num :plural}
one {{You have {$tenths} value}}  // not desirable
* {{You have {$tenths} values}}

The second question is: if :number is a selector, what sort of selector is it by default? @eemeli answers that :plural is the most common usage. Alternatives would be :ordinal and whatever we call exact match. I agree with @eemeli that :plural is the far-and-away most common case and thus should be the default.

So... @mihnita are you objecting to the phrasing here or the conclusion? If the phrasing, do you want to suggest alternate text?

@aphillips Your "won't be seen" comment is a bit misleading, as the problem with that message is that the one variant may indeed be seen, formatted as "You have 1.0 value".

You're right.. that comment goes against what I'm trying to say, so I fixed it.

Since we already defined $tenths and use it in the body of the options, then I expect :plural on it:

.local $tenths = {$num :number minFractionDigits=1}
.match {$tenths :plural}
one {{You have {$tenths} value}}  // not desirable
* {{You have {$tenths} values}}

And not doing that is easy to do at lint time.

Is this list exhaustive? #532 includes :integer. Presumably :integer is an integer plural selector by default (in addition to being a formatter).

Other candidates for shorthands might be :percent, :currency and (maybe??) :scientific. The first two are shorthands in ICU4J MF1. scientific is a numeric formatting option (but not exposed by MF1).

There is also the potentially lamentable :spellout from ICU4J MF1.

I'm guessing that what we want to promote is single-annotation messages, e.g.:

.input {$var :spellout}
.match {$var}                               // it's already a plural
[0]   {{You have no more bone dragons}}
[one] {{You have {$var} more bone dragon}}  // "You have one more..."
[*]   {{You have {$var} more bone dragons}}

I think the ones you mention are all formatters? The list here is purely about .match selectors, and for that I think just :plural and :ordinal could be enough. If you need exact matching, then the relatively rare :number select=exact is pretty good?

To clarify a bit, a proposed alias like :integer or :spellout still ends up calling the :number function, and so if the expression doesn't have an explicit select attribute and the alias does not set supports="format", it'll end up inheriting the default select="plural" for selection, together with the rest of the expression & alias options.

They are, but your assertion is that formatters and selectors are the same thing. There's some convenience to configuring the formatter and then using it as the selector also. None of the ones I mention would use exact or ordinal as the default selector.

We could just require that users use type=XXX for formatting options. That would make the example I gave:

.input {$var :number type=spellout}
.match {$var}
[one] {{You have {$var} more bone dragon}}
[*] {{...}}

Maybe more interesting examples would be:

.input {$savingsPercent :number type=percent maximumFractionDigits=0}
.input {$savingsAmount :number type=currency currency=$savingsCurrency}
.match {$savingsPercent} {$savingsAmount}
[one one] {{You saved {$savingsAmount} ({$savingsPercent})}}
[* *] {{...etc...}}

vs.

.input {$savingsPercent :percent maximumFractionDigits=0}
.input {$savingsAmount :currency currency=$savingsCurrency}
.match {$savingsPercent} {$savingsAmount}
[one one] {{You saved {$savingsAmount} ({$savingsPercent})}}
[* *] {{...etc...}}

and avoiding...

.match {$savingsPercent :plural} {$savingsAmount :plural}
[one one] {{You saved {$savingsAmount :number type=currency currency=$savingsCurrency} 
    ({$savingsPercent :number type=percent maxiumumFractionDigits=0})}}

Here's how I would classify the different aliases that have been mentioned so far:

• :integer -- The most obvious one, and therefore included already in #532.
• :plural and :ordinal -- Functions for selection only with supports="match". Included in this design doc.
• :percent, :currency,:scientific, :spellout -- Possible aliases for later/separate consideration. As with :integer, they might be used also for selection, but I don't see how any of them would specify a <setOption name="select">. So I don't think they belong in a design doc on Number Selection.

Once #532 lands, would a PR adding that third set be the right focal point for discussion of their merits, rather than this PR?

:ordinal is a formatter too

I agree that :ordinal could also be a formatter, but I am not here proposing that it be one of the core formatters that we expect all MF2 implementations to provide. That could be considered as a separate further step, should this design on number selection first introduce it as a selector.

Do we need to? Can we finish up numbers and be done with them? 😁

I would very strongly prefer taking this smaller step first, and not expanding the scope of this design document.

As noted elsewhere, :ordinal is also a formatter or formatting option, at least in MF1. The name for the selector (selectordinal) and the formatter (ordinal) are different because MF1's parser needed separate keywords (the syntax doesn't separate selectors and formatters the way ours does), but we don't have that problem.