Comments (52)
Intl.PluralRules
has been exposed in SpiderMonkey - https://bugzilla.mozilla.org/show_bug.cgi?id=1403318
from ecma402.
V8 v6.3.172 and Chrome 63 ship it as well. https://developers.google.com/web/updates/2017/10/intl-pluralrules
from ecma402.
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!
from ecma402.
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
from ecma402.
As a sidenote, I recently updated my polyfill to match the current spec: https://github.com/eemeli/intl-pluralrules
from ecma402.
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?
from ecma402.
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
from ecma402.
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.
from ecma402.
Here is a backpointer to the discussion: https://groups.google.com/forum/#!topic/javascript-globalization/3nFDf5al5hU
from ecma402.
@caridy Yeah @zbraniecki took this from the email thread. You guys both posted the same link to it :)
from ecma402.
jaja
from ecma402.
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.
from ecma402.
@zbraniecki let's keep the format
with options out of the initial scope of this feature, we can discuss more later on.
from ecma402.
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.
from ecma402.
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?
from ecma402.
The spec looks great, very straightforward.
from ecma402.
/cc @eemeli
from ecma402.
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.
from ecma402.
@eemeli awesome! I was hoping you'd say that 😄
from ecma402.
@eemeli let's have the discussion about your feedback here tc39/proposal-intl-plural-rules#1
from ecma402.
@eemeli thx
from ecma402.
update: we are cooking the proposal for the next meeting in two weeks.
from ecma402.
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
from ecma402.
we have reached stage 1 on this proposal :)
from ecma402.
🎉
from ecma402.
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.
from ecma402.
Slides from TC39 meeting: https://docs.google.com/presentation/d/1WflzD4YMOYYmJDAmjwmG0wi5GnLZd74EwvDRKSL9vA8/edit#slide=id.gd4949377b_1_17
from ecma402.
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 separateselectRange
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`;
}
from ecma402.
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"?
from ecma402.
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.
from ecma402.
@littledan - what's the update on this proposal? Do you still to plan to get it to reviewers before the next ECMA meeting?
from ecma402.
@zbraniecki I think that's more of a question for the champions. I'm happy to review it if it's ready; is it?
from ecma402.
Oh, sure. @ericf - any updates?
from ecma402.
@zbraniecki No updates from me, I haven't been working on it.
from ecma402.
Ok!
@caridy - I created tc39/proposal-intl-plural-rules#4 which adds GetOperands
based on http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-numbers.html#Operands
In my testing that allowed for nice fractional digit resolution.
from ecma402.
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.
from ecma402.
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.
from ecma402.
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.
from ecma402.
@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?
from ecma402.
Opened an issue in andyearnshaw/Intl.js#243
from ecma402.
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.
from ecma402.
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.
from ecma402.
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.
from ecma402.
Any reason ordinal
/cardinal
/spell-out
doesn't become a style for Intl.NumberFormat
?
from ecma402.
@ray007 Can you say more about your use case?
from ecma402.
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.
from ecma402.
@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?
from ecma402.
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...
from ecma402.
Sorry, but your suggestion is pretty vague to me and you're not helping to clarify it.
from ecma402.
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...
from ecma402.
ordinal number formatting has nothing to do with PluralRules.
from ecma402.
@littledan are you going to send the PR to merge the new spec into 402? or do you need some help?
from ecma402.
Related Issues (20)
- Allow compact notation to depend on `style` HOT 3
- AvailableCurrencies and default fallback for unsupported currencies in NumberFormat HOT 1
- Ensure data returned from Intl Enumeration is consistent with data supported by Intl objects HOT 8
- Is there a polyfill for the "extend-timezonename" proposal? HOT 6
- Cyclic year doesn't show up in resolvedOptions HOT 1
- Ok HOT 1
- Numbering system option value not correctly passed to internal Intl.NumberFormat instances
- Feedback on ICU's new HOT 1
- Feedback on ICU's new "get IANA ID" API HOT 3
- Should ECMA-402 spec text for time zone canonicalization refer to CLDR or to IANA as authoritative? HOT 8
- Canonicalization for Calendar identifiers? HOT 2
- Consider making ResolveLocale return the normalized requested locale instead of the available locale HOT 6
- Default of ignorePunctuation need to be locale dependent HOT 3
- Support cash rounding HOT 3
- Displaying wrong date format for sr-Latn-me locale HOT 2
- Intl.NumberFormat with style: 'decimal' if the number has four digits, does not add the point on locale spanish HOT 1
- Should intrinsics be scoped? HOT 3
- Need support for nigerian currency. HOT 3
- Add option to use variant era names HOT 1
- Intl API for parsing locale aware strings HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ecma402.