-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Localisation capabilities of the RelativeTime plugin are insufficient for fusional languages #302
Comments
This is also needed for proper Finnish translation. Otherwise either future or past tense can't work correctly and is unacceptable for real use. E.g. |
This adds basic support for Finnish locale but atm. proper Finnish support can't be implemented until issue iamkun#302 is fixed. relativeTime properties are now configured for past tense usage only because I think it's a more common use case with this kind of library. For now using future tense with this locale will result in incorrect forms and text that doesn't make sense.
@iamkun please prioritize this issue. I do understand that it will probably be a breaking change (new major release), but it's essential in order to move further and ensure the bright future of A lot of localisations are invalid with the format |
@limonte, I took care not to break the existing language packs in the suggested fix #304. Czech, Slovak, Russian and Ukrainian language packs are updated. The others are loaded and work as they did before the change. They can be gradually upgraded as the community goes on. I reused the existing patterns "m" and "mm" for the mnemonic tags "one" and "few". I added pattern "mmm" for the "many" tag. Tag "zero" is not needed for relative time values. Tag "two" is rare and tag "other" has no common rules. Tags "one", "few" and "many" hardcoded for 1, 2-4 and 5+ numbers mean a small change and cover many languages. The future step could be implementing the full CLDR rules. See plural rules on CLDR for more information.) |
My original simplification was not enough. Even the common languages were not covered well with the three plural forms and the single rule for them, as @leovp pointed out. It would be better to go for the universal solution right away instead of trying something simpler as I did originally. For example, by specifying both the plural rule (a number or a function) and the plural forms as an array of strings, which the plural rule is an index to. relativeTime: {
// Slavic (Slovak, Czech), 3 plural forms for 1, 2-4, 5-
pluralRule: 8,
duration: {
s: 'několik sekund',
m: 'minuta',
mm: ['%d minuta', '%d minuty', '%d minut'],
h: 'hodina',
hh: ['%d hodina', '%d hodiny', '%d hodin'],
d: 'den',
dd: ['%d den', '%d dny', '%d dní'],
M: 'měsíc',
MM: ['%d měsíc', '%d měsíce', '%d měsícú'],
y: 'rok',
yy: ['%d rok', '%d roky', '%d let']
},
future: {
s: 'za několik sekund',
m: 'za minutu',
mm: ['za %d minutu', 'za %d minuty', 'za %d minut'],
h: 'za hodinu',
hh: ['za %d hodinu', 'za %d hodiny', 'za %d hodin'],
d: 'zítra',
dd: ['za %d den', 'za %d dny', 'za %d dní'],
M: 'za měsíc',
MM: ['za %d měsíc', 'za %d měsíce', 'za %d měsícú'],
y: 'za rok',
yy: ['za %d rok', 'za %d roky', 'za %d let']
},
past: {
s: 'před několika sekundami',
m: 'před minutou',
mm: ['před %d minutou', 'před %d minutami', 'před %d minutami'],
h: 'před hodinou',
hh: ['před %d hodinou', 'před %d hodinami', 'před %d hodinami'],
d: 'včera',
dd: ['před %d dnem', 'před %d dny', 'před %d dny'],
M: 'před měsícem',
MM: ['před %d měsícem', 'před %d měsíci', 'před %d měsíci'],
y: 'vloni',
yy: ['před %d rokem', 'před %d roky', 'před %d lety']
}
} // Plural rule #8
n => n === 1 ? 0 : n >= 2 && n <= 4 ? 1 : 2 I had to to separate the special singular form from the plural forms. It has usually no number and thus the first plural form (for 1, 21, 31, ...) cannot be reused for it. I updated #304 with this approach. Eventually, the plural rules should make it out of the |
fixed in #767 |
This adds basic support for Finnish locale but atm. proper Finnish support can't be implemented until issue iamkun/dayjs#302 is fixed. relativeTime properties are now configured for past tense usage only because I think it's a more common use case with this kind of library. For now using future tense with this locale will result in incorrect forms and text that doesn't make sense.
This adds basic support for Finnish locale but atm. proper Finnish support can't be implemented until issue iamkun/dayjs#302 is fixed. relativeTime properties are now configured for past tense usage only because I think it's a more common use case with this kind of library. For now using future tense with this locale will result in incorrect forms and text that doesn't make sense.
This adds basic support for Finnish locale but atm. proper Finnish support can't be implemented until issue iamkun/dayjs#302 is fixed. relativeTime properties are now configured for past tense usage only because I think it's a more common use case with this kind of library. For now using future tense with this locale will result in incorrect forms and text that doesn't make sense.
What do you think about re-working the current locale definition of the RelativeTime plugin to support fusional languages without grammatical mistakes?
Moment.js has more complicated locale definitions, but it allows grammatically correct localisation for Slavic languages, for example. Your Russian localisation suffers from the second problem below and my Czech localisation from both, which makes the localised expressions look so wrong, that they cannot be used in real-world applications.
Problem
For example, Slavic languages do not use just one noun form for singlular (one second) and one for plural (many seconds). Usually there are different forms after numerals 1, 2-4 and 5+. Additionally, the noun changes according to to the grammatical case, which is needed in the particular expression. The grammatical case depends on the preposition, for example.
Examples of English, German Russian and Czech expressions
Years - Past
Years - Future
Days - Past
Days - Future
Seconds - Past
Seconds - Future
Solution
The text was updated successfully, but these errors were encountered: