Integrate plural rules from github.com/unicode-org

[axunonb]

unicode-org
https://github.com/unicode-org/cldr-json

[axunonb]

@karljj1
I created a new branch that includes a converter that imports CLDR plural rules and creates a class with corresponding C# delegates. It contains automated unit tests with test cases supplied by CLDR for full coverage.

The original idea was just to update the current PluralRules class. However, the PluralRules design makes this quite hard to accomplish:

Structural and Design Issues

• Custom Rule Definitions: The rules are manually encoded as delegates with ad hoc logic. This makes them hard to audit, extend, or verify against CLDR updates.
• No CLDR Operand Model: Unlike CldrPluralRules, it doesn’t use the standardized operands (n, i, v, w, f, t, e) defined by CLDR. This limits its ability to handle fractional values and edge cases correctly.
• PluralWordsCount Dependency: The use of pluralWordsCount to switch logic paths is non-standard and opaque. CLDR rules are based solely on numeric operands, not UI-driven word counts.
• Inconsistent Category Mapping: It returns an integer index (e.g., 0, 1, 2) based on the number of plural forms, rather than a semantic category (One, Few, Many, etc.). This makes it brittle and hard to interpret or localize correctly.

Maintainability and Auditability

• Hardcoded Language Map: The DefaultLangToDelegate dictionary is manually curated and not sourced from CLDR data. This risks drift from the spec.
• No Testability Hooks: There’s no operand inspection or rule introspection, making it difficult to write comprehensive unit tests or debug edge cases.
• No Versioning or Metadata: Unlike CldrPluralRules, it lacks CLDR version info, generation date, or source traceability.

AFAIK you're you're using your fork of SmartFormat for localization. Are you using the current SmartFormat PluralLocalizationFormatter as it is? Given the obstacles mentioned above I wonder whether a complete redesign would be the better choice. In this case, I'd appreciate your cooperation in terms of the future design.

Any thoughts to this subject from your side?

[karljj1]

Interesting idea. It would be a nice improvement. It may be a good idea to do this as a new formatter and keep the old one so that it can be gradually introduced, since it would be a significant change. Once we are happy, we can deprecate the old one and progressively remove it. I like the idea of returning a category instead of an index, which would make it much clearer to users who need to add translations for plurals.
We do currently use the PluralLocalizationFormatter as is. I like the idea of generating the rules from the CLDR, although I can't imagine they change much, so I don't think it would be a problem if it were something handwritten or a mixture.