[BUG] `I18n::Backend::Pluralization` should support CLDR pluralization

[movermeyer]

ruby-i18n/i18n should ship with a pluralization backend compatible with CLDR.

Especially when the README advertises it as such:

The default I18n::Backend::Pluralization does not support CLDR's pluralization rules.

Differences with the CLDR spec:

• I18n::Backend::Pluralization has an incorrect special case for count == 0, which returns zero, which is the incorrect key to use for count == 0 in many locales

  • e.g., ar requires the use of zero key, so if you use zero in en, the translation of the en zero value into ar will conflict with the translation for the zero key produced by translating the en one and other keys.

• CLDR allows for explicit plural rules that exactly match count == 0 and count == 1, independent of locale:

  "0": I don't have any cars # Used for count == 0, taking precedent over locale-specific rules
  "1": I have a single car # Used for count == 1, taking precedent over locale-specific rules
  one: I have %{count} car
  other: I have %{count} cars

  • i.e., People who are using zero today in locales that don't use the zero key (e.g., en), should be using the explicit "0" key instead.

• When a lookup for a plural case key fails, a Lateral Inheritance lookup should occur within the same locale before falling back to a Locale Inheritance (I18n::Backend::Fallbacks) lookup in a parent locale.

  • e.g. it falls back to using the other plural rule before falling back to an ancestor locale
  • Without this behaviour, as a user you have to pre-process the data to copy the other key into any missing plural rules

Limitations

1. We don't currently have a defined standard way to serialize the other lateral inheritance attributes (e.g., case, gender) present in the CLDR XML into YAML. If/when we figure out how to support those, that would be a future change.

2. Making these changes to I18n::Backends::Pluralization would be a breaking change. While I'm personally in favour of this change (i.e., forcing users to rename their already problematic zero keys to "0"), obviously this is your call.

[franzliedke]

Should this be re-opened now that #630 was reverted?