Use correct labels for numeric fields when using a multiple plural forms language

Created on 3 June 2015, almost 10 years ago
Updated 22 February 2024, about 1 year ago

Postponed on #2454829: Configuration translation UI does not support plural sources/targets .

Problem/Motivation

The form for configuring and translating numeric fields has been copied multiple times: NumericField::buildOptionsForm(), TranslateEditForm::buildForm(), PluralVariants::getSourceElement(), and PluralVariants::getTranslationElement(). (That in itself is a problem -- it should be centralized.)

The problem is that the labels used in this form are not clear. Not only that, they are not appropriate for many languages. The reason is that while English, Spanish, etc. have two forms for plural expressions (singular, plural), many other languages have either one form, multiple forms, or two forms that are not "singular" and "plural".

Here's an easy-to read list of the rules:
http://localization-guide.readthedocs.org/en/latest/l10n/pluralforms.html
And here's a more definitive set of rules that is not as easy to code or follow, but should be more accurate since it comes from Unicode.org:
http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_r...

And this related issue demonstrates actual real-world problems that have resulted from our localization teams misunderstanding the labels (the same labels are used on localize.drupal.org)... These are the best experts we have in the Drupal community, and they can be educated on how to understand the labels, and even they are having difficulty. For ordinary users who are not part of a localization community, who are trying to translate their own Drupal site, the problem would be even worse.
#2538142: Some po files have wrong plural translations

So, we need to fix this!

Next: some examples of actual observed problems arising from these labels on localize.drupal.org from that other issue.

Languages with only 1 plural form

In this case the label for the translation is "Singular form". Bad!

So we are seeing output like:

msgid_plural "@count hours"                                      
msgstr[0] "1 сағат"

With this translation, '12 hours' will be translated as '1 сағат'.

Languages with 2 plural forms

For all languages with 2 plural forms, we are currently using these labels:
- Singular form
- Plural form

This is OK for English, Spanish, French, etc. But there are languages where the 1st form is actually for all numbers that end in 1 (Icelandic, for instance), or for all non-zero numbers (Javanese). So for instance, here's a translation from the current Javanese po file:

msgid_plural "@count comments"                                      
msgstr[0] "1 komèntar"                                               
msgstr[1] "@count komèntar"

In this case the result is that, '0 comments' will be translated as '1 komèntar' in Javanese, because the first plural form is used for 0 and the second for all non-zero numbers. This is not correct.

Languages with more than 2 plural forms

The labels in the UI currently are:

  • 'Singular form'
  • 'First plural form'
  • '2. plural form'
  • '3. plural form'
  • etc.

The problem here is that in many languages, the first form is for something like "Numbers that end in 1", not really singular. Since the English form they are translating will say something like "1 item", it's likely they will put "1 item" in their language as well for the first form, instead of using "@count item" or the equivalent.

So really what is needed are language-specific labels. So for Russian, the labels might be something like:
- Form for numbers ending in 1 but not 11
- Form for numbers ending in 2, 3, 4, but not 12, 13, 14
- Form for all other numbers

Proposed resolution

Add a centralized function or method that generates those labels appropriate for a given language, and translate them in the interface language.

Remaining tasks

Decide. Implement. Review.

User interface changes

We will have appropriate labels for every languages.

API changes

None.

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Language system 

Last updated 2 days ago

  • Maintained by
  • 🇩🇪Germany @sun
Created by

Live updates comments and jobs are added and updated live.
  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • Pipeline finished with Failed
    about 1 year ago
    Total: 187s
    #101055
  • 🇺🇸United States dww

    This came up as a random triage target in #bugsmash.

    I confess to not having read every comment, but this definitely still seems like a bug, and likely major is accurate.

    Turned patch #30 into MR 6729

    I'm sure we don't want locale_get_plural_form_labels() as a new procedural method for this as the API addition. 😂 I'm not sure we want to try to maintain this exact list in core code like this, but I'm not yet seeing an alternative. Thankfully, once we get it right, this list will never change except when adding new languages. And multiple plural forms is pretty rare. Even in ʻŌlelo Hawaiʻi (which I co-maintain with @xjm), a language with different versions of "we" for "the two of us" vs. "all of us", it still only has 2 plural forms for the purpose of this issue.

    Where do we put the logic?

    1. Maybe this would make sense as a new public method on the locale.plural.formula service?
    2. Or add it to StringTranslationTrait?
    3. Other?
  • 🇺🇸United States dww

    p.s. re #90.2: I suggested StringTranslationTrait since it's already providing getNumberOfPlurals().

  • 🇺🇸United States dww

    Fixed the PHPCS errors, both via phpcbf and manually.

    In comment #71 @jhodgdon pointed to 🐛 Misuse of formatPlural() in Numeric field prefix/suffix Needs work where they also need the labels and decided to add something to StringTranslationTrait. That could be read as a vote for #90.2.

    Also tagging that this needs tests before it could be committed, and started saving issue credits for the rich discussion here.

  • Pipeline finished with Failed
    about 1 year ago
    Total: 486s
    #101067
  • Pipeline finished with Failed
    about 1 year ago
    Total: 608s
    #101092
Production build 0.71.5 2024