Skip to content

(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

Merged
merged 8 commits into from
Dec 11, 2023
Merged

Conversation

eemeli
Copy link
Collaborator

@eemeli eemeli commented Sep 6, 2023

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.

@eemeli eemeli added design Design document or issues related to design functions Issue pertains to the default function set labels Sep 6, 2023
Copy link
Member

@aphillips aphillips left a 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!

Comment on lines 109 to 112
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.
Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Member

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.

when * {You have {$count} apples}
```

The proposed design is more robust than this alternative,
Copy link
Member

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.

Copy link
Collaborator Author

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?

and to define three further functions, each with a `<matchSignature>`:

- `:plural`
- `:ordinal`
Copy link
Member

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

Copy link
Collaborator Author

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.

Copy link
Member

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.

Comment on lines 65 to 66
Given that we already have a `:number`,
it makes sense to add a `<matchSignature>` to it with an option
Copy link
Member

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?

Copy link
Collaborator Author

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 need type=, but how do I get the exact 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.

eemeli and others added 2 commits September 7, 2023 10:57
Co-authored-by: Addison Phillips <addisonI18N@gmail.com>
@aphillips
Copy link
Member

I think this might need a revision in light of our Slack conversation yesterday. Having number shorthands for integer and such present in the proposal seems like a good way to work through it.

I like the idea of using :number as a model for other additions to the default registry, which we really really need to do next 😉

@aphillips aphillips changed the title Add design document on number selection (Design) Number Selection Nov 12, 2023
@eemeli
Copy link
Collaborator Author

eemeli commented Nov 28, 2023

I refreshed the design doc a bunch, please take another look? This now relies somewhat on #532.

Copy link
Member

@aphillips aphillips left a 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.

Comment on lines +91 to +98
```xml
<alias name="plural" supports="match">
<setOption name="select" value="plural"/>
</alias>
<alias name="ordinal" supports="match">
<setOption name="select" value="ordinal"/>
</alias>
```
Copy link
Member

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

Copy link
Collaborator Author

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?

Copy link
Collaborator Author

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.

Copy link
Member

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})}}

Copy link
Collaborator Author

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

Copy link
Member

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

Copy link
Collaborator Author

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.

Copy link
Member

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? 😁

Copy link
Collaborator Author

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.

@eemeli eemeli linked an issue Nov 29, 2023 that may be closed by this pull request
@eemeli eemeli requested a review from aphillips December 8, 2023 06:05
Copy link
Member

@aphillips aphillips left a 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.
Copy link
Member

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>
Copy link
Member

@aphillips aphillips left a 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`,
Copy link
Collaborator

@mihnita mihnita Dec 9, 2023

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.

Copy link
Member

@aphillips aphillips Dec 10, 2023

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?

Copy link
Collaborator Author

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

Copy link
Member

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.

Copy link
Collaborator

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.

@macchiati
Copy link
Member

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.

@aphillips
Copy link
Member

@macchiati :integer is not "just an alias for :number". It includes the settings that force numbers to be formatted as integers (and thus guides selection also). What this design doc says, in effect, is that :integer as a function/selector inherits all of its setup from the :number entry in the registry except for it's overrides. That saves us from having to recreate every detail of :number in a separate function description.

@macchiati
Copy link
Member

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.

@aphillips aphillips merged commit a2420bb into unicode-org:main Dec 11, 2023
@eemeli eemeli deleted the design-number-selection branch December 11, 2023 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design document or issues related to design functions Issue pertains to the default function set
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Selection method expectations
4 participants