Intl.PluralRules()

[zbraniecki]

UPDATE: This proposal has advanced to stage 1, details here: https://github.com/caridy/intl-plural-rules-spec

cloned from: https://groups.google.com/forum/#!topic/javascript-globalization/3nFDf5al5hU

It would be very helpful for all l10n libraries to get CLDR plural forms into Intl API.

The proposed API could look like this:

var cardinal = new Intl.PluralFormat(‘en’, {style: ‘cardinal’});
console.log(cardinal.format(0)); // “other”
console.log(cardinal.format(1)); // “one”
console.log(cardinal.format(2)); // “other”

var ordinal = new Intl.PluralFormat(‘en’, {style: ‘ordinal’});
console.log(ordinal.format(11)); // “one”
console.log(ordinal.format(22)); // “two”
console.log(ordinal.format(33)); // “few”
console.log(ordinal.format(44)); // “other”

[caridy]

Makes sense, and it aligns well with some other proposals around this. Last time we talked about ICU messages, we ended up agreeing that better to do baby steps on this and get pluralization in place instead.

/cc @ericf, he has some ideas around this, and he was planning to champion the pluralization low level api.

[caridy]

Here is a backpointer to the discussion: https://groups.google.com/forum/#!topic/javascript-globalization/3nFDf5al5hU

[ericf]

@caridy Yeah @zbraniecki took this from the email thread. You guys both posted the same link to it :)

[caridy]

jaja

[zbraniecki]

The latest proposal that seems to address all comments so far:

var f = Intl.PluralForm(navigator.languages);

f.resolve(100); // 'other'
f.format(100, {
  one: 'comment',
  other: 'comments'
}); // 'comments'

I would say that the latter method should be lower priority for us. I like how simple it is, but I'm not sure if it would really be applicable for libraries that need it, while the former is definitely going to be directly applicable in multiple libraries I know of.

[caridy]

@zbraniecki let's keep the format with options out of the initial scope of this feature, we can discuss more later on.

[caridy]

Ok guys, finally got a chance to work on this, the initial proposal flush out:

https://github.com/caridy/intl-plural-form-spec

The generated spec [draft] is here:
https://rawgit.com/caridy/intl-plural-form-spec/master/index.html

I will work with @ericf next week for formalize the proposal and to see if we can formally presented (if we get a chance to add it to the agenda, which I doubt).

P.S.: I hate to post in groups and here.

[srl295]

Yes, just resolve plurals first… formatting is another step

I hate to post in groups and here

Just post a link to here and say follow up in github?

[srl295]

The spec looks great, very straightforward.

[rxaviers]

/cc @eemeli

[eemeli]

Thanks for the pointer @rxaviers. I added my comments to the mailing list thread.

Once the spec is ready-ish, I could probably pretty easily implement a polyfill for Intl.PluralRules from make-plural.js.

[ericf]

@eemeli awesome! I was hoping you'd say that 😄

[caridy]

@eemeli let's have the discussion about your feedback here tc39/proposal-intl-plural-rules#1

[rxaviers]

@eemeli thx

[caridy]

update: we are cooking the proposal for the next meeting in two weeks.

[eemeli]

Forgot to mention it here, but I did actually end up writing a polyfill for Intl.PluralRules. There are some comments about how it diverges from the current spec at tc39/proposal-intl-plural-rules#3

[caridy]

we have reached stage 1 on this proposal :)

[rxaviers]

🎉

[zbraniecki]

Heads up, this has been advanced to Stage 2 as of today. @ericf is championing it and what's left is to update the spec to deal with decimal portion of the Number. We have reviewers assigned.

[zbraniecki]

Slides from TC39 meeting: https://docs.google.com/presentation/d/1WflzD4YMOYYmJDAmjwmG0wi5GnLZd74EwvDRKSL9vA8/edit#slide=id.gd4949377b_1_17

[littledan]

A few feature requests came up in discussion among some of us working on ECMA-402. I'm not sure if they might already be reflected in the text, but just to record the discussion, here's what we've talked about:

• More options should be added to PluralRules, in parallel with the options in NumberFormat which affect how the number is rounded and how many decimal digits are given. These include minFractionalDigits, maxFractionalDigits, and similar for signficant digits. This solves the 1.0
• format should be renamed to select, which is what CLDR calls it and which would reduce confusion since it doesn't produce the kind of string a user should see directly
• If possible, the CLDR range type should be exposed. This could be in the form of a type: 'range', or maybe better because it's more basic, a separate selectRange method which takes two different types as arguments and returns the combined type based on per-language rules. Maybe we would want both, as a convenience method, or maybe stay minimal at first.
• The slides should add an example use case, something simple like

var pr = new Intl.PluralRules('en', { type: 'cardinal' })
switch (pr.select(beers)) {
  case 'one': return 'one beer';
  default: return `${beers} beers`;
}

[eemeli]

Great!

However, the current draft still has the issue of not dealing correctly with the categorisation of numerical strings with visible fractional digits that end in 0. The unicode LDML uses the operands v and f for these, and they're actually pretty common.

For a specific example, in English you have 1 widget, but 1.0 widgets.

To fix this, ResolvePlural should accept string input that it asserts to contain the string representation of a number, and the select() call should not cast such a string to a number before passing it on to ResolvePlural.

Or is this what you meant by the "decimal portion of the Number"?

[caridy]

that is correct @eemeli, that's what @littledan meant by "decimal portion of the Number", we have some ideas about how to solve that in the spec text, we will be working on that very soon.

[eemeli]

I also added tc39/proposal-intl-plural-rules#5, which drops the forced cast to Number that would make @zbraniecki's GetOperands to always return 0 for the v and f operands.

[zbraniecki]

This proposal has been submitted to reviewers and we hope to be able to advance to Stage 3 at TC39 meeting in Munich in May.

[zbraniecki]

This proposal has been advanced to Stage 3. There's still editorial work going on in tc39/proposal-intl-plural-rules#15 , but the API is ready and I started working on SpiderMonkey implementation (behind the flag). I think we may want to start working on Intl.js one and test262 tests soon.

[zbraniecki]

@eemeli - I started working on an implementation of the spec for Intl.js. One item that I could use help with is getting the data from CLDR into the lib. Did you solve it already and can you port it to Intl.js?

[eemeli]

In make-plural.js I use Unicode's own cldr-core JSON export of the official XML data. Is that what you're looking for?

[zbraniecki]

Opened an issue in andyearnshaw/Intl.js#243

[zbraniecki]

I landed mozIntl.PluralRules today in mozilla-central: https://hg.mozilla.org/mozilla-central/rev/80234a27490b
which is a full implementation of PluralRules spec proposal.

@jungshik, @littledan - is there a chance we could get it in V8 anytime soon?
I know jungshik said that it should be easy - https://bugs.chromium.org/p/v8/issues/detail?id=5601 - but now it's a bit of a race against the time. If we can get Google's support behind it in time for January TC39 meeting, I'd like to suggest it for stage 4.

[littledan]

We have a bug open for it, but we don't have an implementation yet. I'd like to avoid thinking about these things as a race against time. It doesn't seem likely that this will get into ES2017, but the annual version numbers shouldn't matter for most purposes. Instead, what should matter is when it gets to Stage 4, meeting by meeting, so there's no real significant cutoff cliff. Chrome has shipped a number of features when they were at Stage 4 without waiting for the annual numbered version, e.g., async/await.

I've been making some changes to the Intl implementation recently to try to make our ECMA 402 implementation have less technical debt so it easier to add more features. We have this bug filed. Many people are taking Christmas break. Let's be OK with this taking a little bit of time.

[zbraniecki]

Let's be OK with this taking a little bit of time.

As I mentioned in the other comment, my understanding was that ES releases are creating opportunity to increase adoption of ECMA402 features.

Instead, what should matter is when it gets to Stage 4, meeting by meeting

Understood.

[ray007]

Any reason ordinal/cardinal/spell-out doesn't become a style for Intl.NumberFormat?

[littledan]

@ray007 Can you say more about your use case?

[ray007]

Our customers can configure "number controls" which allows to select 1 of several styles.
The formatted number is part of the displayed string.
The ICU number formatting API also seems to have styles for ordinal, cardinal, ...
I can work with it either way, as long as it gets implemented somewhere.

[rxaviers]

@ray007 are you saying Intl.NumberFormat should be used to output plural forms? For example, new Intl.NumberFormat('en', {style: 'ordinal'}).format(0); // "other"? Can you explain your suggestion?

[ray007]

Explain?
Not sure what kind of explanation/reasoning you would expect for an opinion?
It just seems easy to extend the existing NumberFormat and I had thought it would maybe take less discussion as making a new Object...

[rxaviers]

Sorry, but your suggestion is pretty vague to me and you're not helping to clarify it.

[ray007]

To use your example:

new Intl.NumberFormat('en', {style: 'ordinal'}).format(1);

should return 1st or maybe a variation with "st" in superscript.

Guess that means, PluralFormat would be a low-level part of this...

[rxaviers]

Thanks, I know understand what you want. Though, I'm afraid such feature isn't the right way to go. Please, see this reply from Mark Davis (Unicode president) about this topic: http://unicode.org/pipermail/cldr-users/2016-February/000462.html

[zbraniecki]

ordinal number formatting has nothing to do with PluralRules.

[zbraniecki]

This proposal has advanced to Stage 4 at today's TC39 meeting.

The committee raised a question about rationale for type: ordinal. One question was if it would be possible to support this via NumberFormat that would format 2nd, 3rd etc. without the need to adjust the whole sentence to the plural category. That seems to be the case in English.

Using Fluent syntax:

key =
    { PLURAL($num, type="ordinal") ->
        [one] {$num}st floor
        [two] {$num}nd floor
        [few] {$num}rd floor
        [other] {$num}th floor
    }

vs.

key = { NUMBER($num, type="ordinal") } floor

But we identified a number of languages that require a whole sentence to be adjusted based on the ordinal plural category.

Examples:

• Filipino: http://www.unicode.org/cldr/charts/29/supplemental/language_plural_rules.html#fil
• Irish: http://www.unicode.org/cldr/charts/29/supplemental/language_plural_rules.html#ga
• Welsh: http://www.unicode.org/cldr/charts/29/supplemental/language_plural_rules.html#cy

For example in Filipino it seems to require:

key =
    { PLURAL($num, type="ordinal") ->
        [one] Lumiko sa unang kanan.
        [other] Lumiko sa ika-{$num} kanan.
    }

while Irish requires:

key =
    { PLURAL($num, type="ordinal") ->
        [one] Glac an {$num}ú chasadh ar dheis
        [other] Glac an {$num}ú casadh ar dheis.
    }

Thus we decided to stay with the current proposal and advance it to Stage 4!

[caridy]

@littledan are you going to send the PR to merge the new spec into 402? or do you need some help?

[zbraniecki]

Intl.PluralRules has been exposed in SpiderMonkey - https://bugzilla.mozilla.org/show_bug.cgi?id=1403318

[mathiasbynens]

V8 v6.3.172 and Chrome 63 ship it as well. https://developers.google.com/web/updates/2017/10/intl-pluralrules

[jackhorton]

Joining the party a bit late here, but the PR to add PluralRules to ChakraCore has opened and should land soon (coming in Edge later this year): chakra-core/ChakraCore#4940

[eemeli]

As a sidenote, I recently updated my polyfill to match the current spec: https://github.com/eemeli/intl-pluralrules