PluralRules Fails To Construct For Some Locales

[nordzilla]

Our current implementation of PluralRules fails to construct from a locale if the ID does not exactly match one of the IDs in plurals.json or ordinals.json.

This means, for example, that constructing a PluralRules object from en is fine, but constructing one from en-US fails.

ICU4C is able to retrieve the en PluralRules when provided the en-US locale.

ICU4C also has the behavior of constructing a default PluralRules object for any valid locale, even if it cannot resolve specific rules. In this event, it creates a default object whose only plural category is "other". One example of this is ordinal rules for br, which do not exist in ordinals.json.

We should decide how we want to handle this in ICU4X. I see three options:

1. Keep things the way they are. You must construct a PluralRules object with the exact lang-id that is in CLDR.

2. Attempt to resolve the correct langid from the locale, e.g. en from en-US, but continue to return an error on construction for locales that have no rules, such as br ordinals.

3. Do what ICU4C does and attempt to resolve specific rules from a locale, but otherwise construct a PluralRules object that defaults to "other" as the only category.

I think that 1) provides a needlessly complex user experience. I have not decided yet about whether I prefer option 2) or option 3).

[zbraniecki]

This is intentional. We decided to outsource the language negotiation from the class constructor. I think this is the right approach of modularizing an opaque and implicit logic of ICU4C/ECMA-402.

In the ICU4X model you are supposed to get the list of available locales, list of requested locales, negotiate between them and use the negotiated locale to construct an instance.

There may be many ways to negotiate it (Unicode has LocaleMatcher, Fluent uses a different one) and then there may be a chained model.

I'd take this issue as a need to document that.

[sffc]

Main issue: #173

We have #173 scheduled for a Deep Dive this month.

This is intentional. We decided to outsource the language negotiation from the class constructor. I think this is the right approach of modularizing an opaque and implicit logic of ICU4C/ECMA-402.

More precisely, we've previously discussed "outsourcing" language negotiation to the data pipeline, which allows for modularity as well as customization of the negotiation algorithms, but the details have yet to be ironed out, which is the purpose of #173. Once "outsourced", the user would need to simply plug a negotiation-enabled data provider into PluralRules to get @nordzilla's expected behavior.

In the interest of reducing duplicate issues, I'm closing this one, but feel free to reopen if there's something that needs to be done that is not within scope of #173.