CLDR pluralization with interpolations#418
Draft
K1DV5 wants to merge 4 commits into
Draft
Conversation
🦋 Changeset detectedLatest commit: 335a53c The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current pluralization implementation requires the language rules to be defined and stored in the catalogs. While that could make it independent, it requires too much special handling to keep it working and maintain the rules storage alongside the items. Considering the fact that the rules for 100+ languages are already provided by almost all popular JS runtime environments through the
IntlAPI, maintaining a parallel implementation makes even less sense.The challenge was that the
IntlAPI works with CLDR categories instead of straight indices. And that was considered to be too verbose to use (plural(days, {one: 'a day', many: '# days'})vsplural(days, ['a day', '# days'])) and couldn't be directly mapped to PO file items. But it can be solved by keeping a consistent order of the categories and leveragingIntlat decision time.In addition, this implements support for template literal candidates (which are not currently supported #406). And also solves the problem that all messages were stored in an array and the length was used to detect plurals, which could create problems when the source language only has one plural form (e.g. Japanese), and it now uses arrays for plurals and strings for singulars.