Giters

unicode-org / message-format-wg

Developing a standard for localizable message strings

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

A name other than :number for plural selection

mihnita opened this issue · comments

commented

It is not new feedback, but it was ignored again and again, then :number was landed as "agreed".

Why :number is not a good name for selection?

Let's try and see how readable this is (in a fictitious programming language), without reading documentation or registry.

switch( gender($foo) ) {
...
}

Pretty clear, takes the gender if $foo and decides on it.

switch( isPrime($foo) ) {
...
}

Again, pretty clear. Probably takes a number-like thing, and returns a boolean. Without reading the registry.

switch( even($foo) ) {
...
}

Again, pretty clear. Probably takes a number-like thing, and returns a boolean. Without reading the registry.

switch( number($foo) ) {
...
}

Again, pretty clear. Takes anything, tries to get a numeric value out of it (probably by parsing it?), and returns a number.
So I expect the keys (the cases) to be numbers.
I have no reason to expect some kind of plural decision.

:number(foo) vs :string(foo) => takes foo and converts it to a number / string.

Because we have this:

switch( string($foo) ) {
...
}

which takes foo and stringifies it, then make decision on the strings.

Python has str(foo), which stringifies, and num(foo), which parses foo as a number.
Java has String.valueOf(obj), which stringifies the obj, and Integer.valueOf(str)

These are common operations, and similar ones can be found in other programming languages.
There is no programming language that has some kind of plural operation on numeric values.

So it is not at all obvious that :number(foo) means a plural decision.
If anything, it looks like parsing or casting.

commented

(chair hat on)

The Working Group agreed to consider this issue as part of the LDML45 release in the 2024-01-15 teleconference, but we didn't make @mihnita file it during the call.

commented

The design document on number selection was proposed and discussed in PR #471, which was opened on 6 September and merged as accepted following an unanimous call for consensus during the MFWG call of 11 December.

@mihnita, you participated in reviewing that document in this thread, where @aphillips replied to your comment with #471 (comment), where he poses the following questions:

The first is: should the :number function used for formatting also do selection? [...]
The second question is: if :number is a selector, what sort of selector is it by default? [...]
So... @mihnita are you objecting to the phrasing here or the conclusion? If the phrasing, do you want to suggest alternate text?

Would it be possible for you to respond to those questions here, as they were left unanswered in the preceding discussion?

commented

@mihnita I have included this item in our next agenda (2024-01-22). Do you have any additional comments? If so, could you supply them or a response to @eemeli's comment in time for that? Or do you need me to defer?

commented

I have included this item in our next agenda (2024-01-22). Do you have any additional comments? If so, could you supply them or a response to @eemeli's comment in time for that? Or do you need me to defer?

Thank you. I'm fine with it on the agenda, no defer, and no extra comments.

I didn't see any technical argument in Eemeli's comment, so I was not planning to answer.
But it looks like he is trying to say that I can't open issues anymore?

Would it be possible for you to respond to those questions here, as they were left unanswered in the preceding discussion?

I answered there, and the important part was "I expect :plural on it"
With clarifications why in the currently opened issue.

I argued against :number for selection for a long time, that is not news.

The merge was done with

MIH had some comments
and
APP - additional to plural. Merge, and if strong feelings, create a new PR Merged
(see meeting notes)

So, here it is. Issue, before PR.

In general approving a design document does not mean agreement on the exact variable / class / method names.
That's why there are still code reviews, approved separately from design reviews.

I did not try to block a design document, to allow things to move forward.
But we should not claim that the merge is more "unanimously" than it really was, or that the document is perfect.
Or that the decisions in the document are as obvious as claimed.

Examples from the doc + the PR

The doc says:

As pointed out by @mihnita in particular,
category selection is not always appropriate for selection on a number:
the number may be representing some completely other quantity,
such as a four-digit year or the integer value of an enumerator.

And then does nothing with that info, does not try to address it in any way.
The point was: plural is not the most obvious selection that one can do on a number.

From the PR time, the doc says:

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

and comments in PR:

aphillips: Actually... we don't yet have a :number. I kind of expected to find it in this doc!

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

The door was always opened for issue / updates. And should be.

aphillips: Do we need to? Can we finish up numbers and be done with them? 😁
eemeli: I would very strongly prefer taking this smaller step first, and not expanding the scope of this design document.

Meeting notes "Merge, and if strong feelings, create a new PR Merged"

We had issues opened on things like start in code mode, after having agreement for more than one year.

We explicitly voted on how to delimit strings, and we still had issue opened asking to use " instead.
That was rejected, and still a new issue was opened 4 days ago on this topic.

We had * mandatory for a long time, also agreed.
And yet we have an issue opened 4 days ago.

So I would say that we should argue on technical arguments, instead of trying to block issues based on "anonymous agreement" (real or perceived)

commented

@mihnita Thanks for your response.

(chair hat OFF)

The first question is, given that :number is a formatter (which I think is uncontroversial?), should it be possible to use it for selection. This at first may seem odd, but what many of us have in mind are messages like this:

.input {$num :number groupingUsed=false minimumFractionDigits=1}
.match {$num}
* {{You have {$num} kumquats}}

We currently require that selectors be annotated, but we don't check on how they are annotated. If :number's not permitted, it makes numbers special compared to other values.

It should be noted that both :number and :plural do exact value selection. That is, this works:

.match {$num :plural}
0 {{0 is not zero}}
1 {{1 is the exact value 1}}
one {{This is plural rule one}}
* {{etc.}}

If :number is a selector, then a debate is whether it also does plural rules. With my top example in mind, I think most of us agreed that it makes more sense that if :number is a selector then it works like :plural.

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

:number is not a question, but match $num's number format is a question, no? And the details matter: in my example, $num in English never matches one because it has a fraction part.

I (you might disagree) think the technical question you should focus on is "why should we forbid using :number as the annotation for selecting numeric values?"

(char hat ON)

@mihnita

The merge was done with

The merge was done while you were on vacation. The note about "MIH has some issues" is quoting me calling out that you objected to the design doc's details. You go on to note that I called for additional issues/PRs for disagreement.

You appear to be supporting the alternatives considered design. A PR improving that alternative would very much help your case.

In general approving a design document does not mean agreement on the exact variable / class / method names.
That's why there are still code reviews, approved separately from design reviews.

I disagree. I would be disappointed to see "design says A / spec says B". In this case, the design doc and the spec are close in time and in agreement. Further, the design doc calls out details that could vary (and indeed did vary later, e.g. :exact turns out to be spelled :string).

But it looks like he is trying to say that I can't open issues anymore?

I think the real question here is whether (or not) you are trying to reopen a consensus issue. If I understand correctly, you feel that we either didn't have consensus or didn't reach one properly. That's a fair question. We should answer if :number selects and (if so) selects like :plural in Monday's call.

If we cannot reach consensus in a time-boxed period of time, I will call for balloting this issue to resolve it.

commented

The first question is, given that :number is a formatter (which I think is uncontroversial?), should it be possible to use it for selection.

I am not opposed in principle to a formatter also being used as selector.
But the names should be intuitive, it should make sense.

This at first may seem odd, but what many of us have in mind are messages like this:

.input {$num :number groupingUsed=false minimumFractionDigits=1}
.match {$num}

I understand. But why not this?

.input {$num :number groupingUsed=false minimumFractionDigits=1}
.match {$num :plural}

It means "decide what is the plural for the number above (with those options)"
And it it (at least to me) more clear what it means.
I think that we already decided that match should always have a function.

I (you might disagree) think the technical question you should focus on is "why should we forbid using :number as the annotation for selecting numeric values?"

I don't disagree to use a function as both selector and formatter, if it makes sense.
And I don't think here makes sense, for the reasons explained in the issue.

For example if we have a formatter called "ordinal" that takes a number and generates strings ("1st", "31st", "42nt") it kind of also sounds natural as a selector:
"What is the ordinal of 42 => two" kind of makes sense.
"What is the number of 13 in Romanian => few" does not look natural.

It is about naming things.
That's why I am OK with the design doc, but not with the "naming"

And let's note that this only affects the registry, not the spec.

I think the real question here is whether (or not) you are trying to reopen a consensus issue. If I understand correctly, you feel that we either didn't have consensus or didn't reach one properly

Third question (maybe): are we never allowed to open an issue on something that was agreed through consensus?
With a sub-question: is a thumb-up from people in the enough for "immutable consensus"?
Especially when the PR has unresolved comments and no approval from people not present?
I only missed one meeting (in vacation) in 3 years. I've been there before in vacations, junteen, 4th of July.
I know we explicitly refrained from submitting things or close issues when Eemeli was not present, especially when he commented on those issues / PRs.

In this case I thought it's not controversial to open an issue, as it was explicitly stated:

  • In the meeting when the merge happened: "Merge, and if strong feelings, create a new PR Merged"
    Well, I did have string feelings.
  • In the last meeting I said I intend to open an issue on this, and nobody said "no"

If the rule is "something merged / close with consensus cannot be reopened anymore" I'm also fine.
And it that's the bar, then "consensus" should probably be more than people weaving thumb-ups in a meeting, should maybe be on record who voted what.
But should apply to everything (using double quotes, mandatory *, etc), not just to my issues.

commented

As far as I can tell, we have three options here:

  1. The current design, defaulting to plural selection on :number.
  2. Allowing selection on exact values, but not plural categories.
  3. Producing a runtime error when :number is used as a selector.

No one is promoting defaulting to the exact-match solution, which is good as it's somewhat dangerous to allow for source messages like:

.match {$count :number}
1 {{{$count} apple}}
* {{{$count} apples}}

as that just happens to work in English, but not for other locales.

Reviewing the responses in this thread and the previous one, the only argument I see being made here is this argument against the first option:

For example if we have a formatter called "ordinal" that takes a number and generates strings ("1st", "31st", "42nt") it kind of also sounds natural as a selector:
"What is the ordinal of 42 => two" kind of makes sense.
"What is the number of 13 in Romanian => few" does not look natural.

Perhaps this concern could be addressed with more careful communication about how our .match statements ought to be "read"?

In particular, given the long discussion we had about ensuring we do "best match" rather than "first match" selection, we don't actually ever ask the question

What is the number of 13 in Romanian?

but instead we ask,

Which of 'one' or 'few' best matches the number 13 in Romanian?

In our previous calls and discussions on this, the conclusion we as a WG have come to is that presuming plural selection and answering "few" is the least wrong option in this case. I agree with this, and have yet to hear any compelling argument why "neither" would be an actually better choice.

The design doc considers option 3 as Completely Separate Functions, and discusses it in a bit more detail. It does not, however, list any "Pros" for this alternative, and none were even suggested for it during its three months of review.

commented
commented

In the 2024-01-22 teleconference we agreed to close this.