-
-
Notifications
You must be signed in to change notification settings - Fork 36
(Design) Number Selection #471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for starting on this. Much appreciated!
exploration/0006-number-selection.md
Outdated
Here, because selection on `:number` is not allowed, | ||
it's easy to duplicate the options because _some_ annotation is required on the selector. | ||
It would also be relatively easy to leave out the `minimumFractionDigits=1` option from the selector, | ||
as it's not required for the English source. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One could still have:
let $count = {$count :number minimumFractionDigits=1}
match ($count :plural}
when 0 {You have no apples}
when one {You have {$count} apple}
when * {You have {$count} apples}
Note that your example doesn't use keywords.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not using keywords was intentional, as the when 1
case exhaustively covers the "one" category in English, and allows for the "one apple" expression to be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does and that is good from the point of view that "one apple" is incorrectly internationalized with keyword one
. You'll notice that elsewhere I did both 😉
However, we should be careful to model good internationalization in our docs because others will copy us. In my example above I put the formatted count in the "one" example for that reason.
exploration/0006-number-selection.md
Outdated
when * {You have {$count} apples} | ||
``` | ||
|
||
The proposed design is more robust than this alternative, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When writing options or alternatives, I think it is better to write from a "flat" perspective. The alternatives should be presented on their own merits and then dive into pros/cons of each. If we first agree about the pros/cons of each design, that makes it easier to find common ground or discuss the relative priority that each of us takes for a given issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So where in this document should this discussion be placed if not here?
exploration/0006-number-selection.md
Outdated
and to define three further functions, each with a `<matchSignature>`: | ||
|
||
- `:plural` | ||
- `:ordinal` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that ordinal
is both a selector and a formatter, e.g.
Value | Selector | Output |
---|---|---|
1 | one | 1st |
2 | two | 2nd |
3 | few | 3rd |
4 | other | 4th |
97 | other | 97th |
101 | one | 101st |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If an implementation does support :ordinal
as a formatter, then it should probably also support it as a selector. But I'm not convinced that we'll want to include that in the required set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ordinal would be needed for MF1 compatibility, if by MF1 compatibility we mean "ICU". But the callout is, I think, important, as you only mentioned ordinal as a selector.
exploration/0006-number-selection.md
Outdated
Given that we already have a `:number`, | ||
it makes sense to add a `<matchSignature>` to it with an option |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually... we don't yet have a :number
. I kind of expected to find it in this doc! A complete definition would help figure out if this is a good design.
My first reaction to your proposal to use :number
for both was that it was conceptually complicated (functions do multiple different things depending on context), but I can see how it could be potentially both a simplifier and thus more robust for users who don't understand plurals.
At the same time, I think that some common shorthands might be useful, just as MF1 has {count,number,integer}
.
I also am concerned about the need to do multiple annotation (this has to do with the mutability question we're working), e.g.:
let $count = {$count :number groupingUsed=true
minimumFractionDigits=0 minimumDecimalDigits=4
maximumFractionDigits=2} <- formatting
match {$count :number type=plural} <- get the right selector
when ...
I recognize that my example uses the default selector plural
, and so wouldn't need type=
, but how do I get the exact
selector if I want it without hosing all of that formatting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually... we don't yet have a
:number
. I kind of expected to find it in this doc! A complete definition would help figure out if this is a good design.
We have its definition in spec/registry.xml
, which includes a <formatSignature>
for it. Follow-up work from #457 should probably add a document describing that and :datetime
to start with.
At the same time, I think that some common shorthands might be useful, just as MF1 has
{count,number,integer}
.
Possibly yes, but this sounds like a separate follow-on spec PR or design doc. :)
I also am concerned about the need to do multiple annotation (this has to do with the mutability question we're working), e.g.:
let $count = {$count :number groupingUsed=true minimumFractionDigits=0 minimumDecimalDigits=4 maximumFractionDigits=2} <- formatting match {$count :number type=plural} <- get the right selector when ...
I recognize that my example uses the default selector
plural
, and so wouldn't needtype=
, but how do I get theexact
selector if I want it without hosing all of that formatting?
First of all, the :number
in your selector would be getting the resolved rather than formatted value of the first expression, so it could extend rather than clobber the set of options defined in the variable declaration. So just using type=exact
where you have type=plural
should do the trick.
Alternatively, you should be able to include it in the first bag of options:
let $count = {$count :number type=exact groupingUsed=true
minimumFractionDigits=0 minimumDecimalDigits=4
maximumFractionDigits=2}
match {$count}
when ...
If/as we'll want to keep the formatting and selection options compatible, you should be able to assign a bag of options covering both to a variable.
Co-authored-by: Addison Phillips <addisonI18N@gmail.com>
I think this might need a revision in light of our Slack conversation yesterday. Having number shorthands for I like the idea of using |
I refreshed the design doc a bunch, please take another look? This now relies somewhat on #532. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments, but generally looks good.
```xml | ||
<alias name="plural" supports="match"> | ||
<setOption name="select" value="plural"/> | ||
</alias> | ||
<alias name="ordinal" supports="match"> | ||
<setOption name="select" value="ordinal"/> | ||
</alias> | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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}}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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})}}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 withsupports="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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:ordinal
is a formatter too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to? Can we finish up numbers and be done with them? 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would very strongly prefer taking this smaller step first, and not expanding the scope of this design document.
Co-authored-by: Addison Phillips <addisonI18N@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bunch of housekeeping suggestions in this round.
Note the dependency on #433 that we need to resolve.
This approach would also mostly work, but it introduces new failure modes: | ||
|
||
- If a `:number` is used directly as a selector, this should produce a runtime error. | ||
- If a `:plural`/`:ordinal`/`:exact` is used as a formatter, this should produce a runtime error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Addison Phillips <addisonI18N@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ship it.
🚢
|
||
## Proposed Design | ||
|
||
Given that we already have a `:number`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right.. that comment goes against what I'm trying to say, so I fixed it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
One note: we might not want to treat :integer as simply an alias for :number. There is one difference in handling: When you have a match, for translation the when clauses are expanded (or contracted) depending on the locale. There are some locales that have a plural category that is only present when the number is fractional, and in those locales you can limit the expansion by not including that category if the numeric value is known to be integral. |
@macchiati |
Ah, my mistake; I thought I had read that :integer was just an alias; glad that it isn't. And having it inherit from :number except when overridden for given locales makes sense. |
See the document for details.
I started to draft a PR for the proposed design directly, but then admitted to myself that my PR description text started to look so much like a design doc that I should write it as one.
Ping @mihnita and @ryzokuken, whom I name-drop in the doc.