Add support for CLDR data in I18n::Backend::Pluralization
#630
Conversation
This is a breaking change. Anyone using the `zero` key in locales that don't require the `zero` key will have to change the key to use the explicit "0" key.
movermeyer
force-pushed
the
movermeyer/pluralization_cldr_support
branch
from
ed22cbd
to
a7b92a1
Compare
|
Spec mentions:
Which, in my experience, covers languages such as Russian that have particular words for "few" and "many" vs two of a thing (iirc) PR looks good. Thank you very much :) |
|
Hello! I just faced problem when upgrading rubygems.org (https://github.com/rubygems/rubygems.org/runs/7312344176?check_suite_focus=true) since there was different text in kaminari pagination ( I was able to track down this to https://github.com/kaminari/kaminari/blob/bf20fccfdbf7d10c337aeead7ecf4f54a230a5fb/kaminari-core/config/locales/kaminari.yml#L19 and fix it (at least temporarily) in app itself by providing following in helpers:
page_entries_info:
one_page:
display_entries:
"0": "No %{entry_name} found"Does it mean providing "zero" as a key for special key value was removed starting If so, that seems like a "drastic" change actually since it is even recommended in Rails Guides and per my experience this kind of unexpected change is hard to spot by automated tests (usually I don't test those edge cases for each pluralized test). Those locales are often shipped with 3rd party gems (like kaminari in my case) as well making it totally invisible to debug. All applications I have around right now needs to lock dependency before latest release since I would need to scan them manually to ensure all pluralizations using this Is there any chance to reconsider this and make it at least deprecated first, put under configuration flag and change the behaviour later with major release? |
@simi Yes. IMO, this change should be highlighted in the CHANGELOG / release notes.
Thanks for the reminder. I've opened a PR to correct the docs. |
+1 |
|
Apologies for the trouble everyone. I'll remove this with #633. There should absolutely be no breaking changes between i18n minor versions. |
|
I18n v1.12.0 has now been released with this rolled back. |
|
Thanks @radar! Would it be welcomed to re-introduce this in small steps? I can try to prepare new version with deprecation warning for example. But I'm still afraid the impact of this change is enormous. |
|
@simi sure, go ahead. Can you figure out how to do the deprecation warning for 1.x, and then we’ll release this change again as a 2.x? |
What are you trying to accomplish?
Fixes #629
What approach did you choose and why?
count == 0using thezerokeyotherplural categoryWhat should reviewers focus on?
This is a breaking change. Anyone using the
zerokey in locales that don't require thezerokey will have to change the key to use the explicit "0" key instead.Q&A
Q: Are
0&1the only special cases, or can one introduce others? Perhaps2: I have a pair of carsA: It might be allowed, depending on how you read the spec... but the spec only mentions
0and1, the LDML DTD only considers0and1to be valid, and CLDR has only ever used0and1. I left support for arbitrary numbers out of this PR, as I figure that it would be better to be restrictive with what we accept right now. It's an easy change to accept other values if it turns out to be desirable.The impact of these changes
Pluralization lookups will will support CLDR's data.
The problematic use of the
zerokey will be resolved.Fixes #629