feedback from @eemeli on the first draft

[caridy]

@eemeli let's have the discussion around this draft here

on behalf @eemeli:

Something I just realised: in section 1.3.4, PluralRules#select()
casts its input to Number before passing it to ResolvePlural, which
then returns a string representing the plural form of the input. That
cast to Number should not be there, and ResolvePlural should be able
to accept String as well as Number input. This is because the plural
category of e.g. 1 is different from the plural category of 1.0 in
many languages, including for instance English (1 is "one", 1.0 is
"other"), and string representation is the only way to determine that.

A second question: the sets of locales for which ordinal and cardinal
plural rules are available in the CLDR are not the same. In 1.1.1,
InitializePluralRules first looks for the locale in
[[availableLocales]], and only then resolves the ordinal/cardinal
"style" of the given options. What is the resulting behaviour for
languages for which cardinal rules are available, but ordinal rules
are not?

[caridy]

Something I just realised: in section 1.3.4, PluralRules#select()
casts its input to Number before passing it to ResolvePlural, which
then returns a string representing the plural form of the input. That
cast to Number should not be there, and ResolvePlural should be able
to accept String as well as Number input. This is because the plural
category of e.g. 1 is different from the plural category of 1.0 in
many languages, including for instance English (1 is "one", 1.0 is
"other"), and string representation is the only way to determine that.

Good catch. We have two options here:

a) make explicit reference to %RelativeTimeFormat% (which is the other proposal), instead of using the abstract operations directly, in which case we can delegate the plural form selection, and we can work on that other piece of the puzzle to consider "1.0" vs 1.

b) adding more logic here to consider string values. I wonder what's the deal here, do you have a link to the details about this logic?

A second question: the sets of locales for which ordinal and cardinal
plural rules are available in the CLDR are not the same. In 1.1.1,
InitializePluralRules first looks for the locale in
[[availableLocales]], and only then resolves the ordinal/cardinal
"style" of the given options. What is the resulting behaviour for
languages for which cardinal rules are available, but ordinal rules
are not?

"1.2.3 Internal slots" is the one describing how the implementation uses pluralRules from locale data. Normally, the spec does not reference to CLDR structure, just make assumptions on how we envision the data to be provisioned for all supported locales, without describing the details about the algo resolution in CLDR. In this case, the runtime can do whatever it needs to do to provision the right pluralRules for all locales supported by the runtime.

[eemeli]

This probably should've been made into two separate issues, but it's perhaps a bit late for that.

b) adding more logic here to consider string values. I wonder what's the deal here, do you have a link to the details about this logic?

I'm not exactly sure what you're asking here, but the Unicode CLDR uses LDML Language Plural Rules to define its pluralization rules. For an implementation of mapping those to JavaScript, I've built make-plural.js. Which, btw, I should be able to turn into a polyfill for this, once the spec is ready for that. Does some part of that answer your question?

"1.2.3 Internal slots" is the one describing how the implementation uses pluralRules from locale data. Normally, the spec does not reference to CLDR structure, just make assumptions on how we envision the data to be provisioned for all supported locales, without describing the details about the algo resolution in CLDR. In this case, the runtime can do whatever it needs to do to provision the right pluralRules for all locales supported by the runtime.

Ok, so there's an assumption made in 1.2.3 that doesn't match the current state of affairs. Specifically, this part:

[[localeData]][locale] must have a pluralRules property for all locale values. The value of this property must be an object, which must have properties with the names of the two plural rules styles: "ordinal" and "cardinal". Each of these properties in turn must be a function. These functions expect a numeric argument and the return must be string value "zero", "one", "two", "few", "many" or "other".

The CLDR, which is probably the most comprehensive source of these functions, currently (v28) contains cardinal pluralization rules for 199 languages, but ordinal pluralization rules for only 84 languages. So would a conforming implementation that used the CLDR for its source data need to limit its supported locales to those 84?

I would recommend the spec be relaxed a bit, with something like this:

- Each of these properties in turn must be a function.
+ Each of these properties in turn must either be null or a function.

The next sentence also needs fixing, due to the above-mentioned issue:

- These functions expect a numeric argument and the return
+ These functions expect a numeric or string argument and the return
  must be string value "zero", "one", "two", "few", "many" or "other".

[caridy]

Ok, lets clear up the second part first:

The spec does not reference to CLDR structure, nor the details on how the runtime resolves data from CLDR or any other similar structure (in the case of Edge, the internal MS implementation). This is what we don't care much about that part. Even our own implementation of the extractor (https://github.com/yahoo/grunt-extract-cldr-data) does the proper compilation to produce the right data per locale, completing the structure automatically. The same can be done by implementers, and that's the position of the committee. In other words, it is the responsibility of the runtime to fill the blanks of CLDR to provide pluralRules object with ordinal and cardinal functions for this implementation. How they do it, it is not very important from the spec perspective. Makes sense?

[eemeli]

In other words, it is the responsibility of the runtime to fill the blanks of CLDR to provide pluralRules object with ordinal and cardinal functions for this implementation. How they do it, it is not very important from the spec perspective. Makes sense?

Sure, but given that ordinal rules are not available for all locales, this means that a conforming implementation will need to either make a smaller set of locales available than it could otherwise, or to return a stub function() { return "other"; } implementation for the missing ordinal rules. Both of those solutions are valid from the spec's point of view, but both have problems; the first in limiting the number of locales, the second in not communicating to the user that the implementation is a stub, rather than something real.

My argument here is that if ordinal rule support is not required for every locale, or if there's a way to indicate that the function is a stub, runtime implementations of the spec will be less problematic.

[caridy]

No, it will not return a stub. Runtimes will be responsible for completing the subset of locales that the runtime supports. Saying, if the runtime supports en, and en-US, it can simply provision both locales with all the details in terms of pluralRules, by computing the proper ordinal/cardinal per locale looking for the right values for both rules.

[caridy]

Ok, @ericf explained me what you're asking for, so here is what is going on, step 12:

12. Let r be ResolveLocale(%PluralRules%.[[availableLocales]], requestedLocales, opt, %PluralRules%.[[relevantExtensionKeys]], localeData).

that's a call to abstract operation http://tc39.github.io/ecma402/#sec-ResolveLocale

In this case, we use [[relevantExtensionKeys]] internal slot, which today it is pr, which denotes an internal key used by runtime to find the right locale data with the right keys. As this point we have two options:

• we can add 2 keys instead of one, pro for plural rules ordinal, and prc for plural rules cardinal, in which case, the locale value returned into resolvedOptions is in fact the one with the right values.
• use opt (3rd argument) to pass the keys, similar to what we do here: http://tc39.github.io/ecma402/#sec-InitializeCollator

Let me play around with this today, and we can make a decision.

Just to make sure we are on the same page:

"we want to resolve to the locale that not only have pluralRules, but the right key when creating an ordinal or cardinal instance."

[caridy]

@eemeli this is now fixed.