Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#26123 closed Bug (invalid)

Wrong Plural-Froms value in the 'ru' locale (regression from version 1.8.x)

Reported by: generalov Owned by: nobody
Component: Internationalization Version: 1.9
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

There are 3 plural forms in the Russian language.
http://localization-guide.readthedocs.org/en/latest/l10n/pluralforms.html

"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2)\n"

Django 1.9.1 locale catalog contains wrong Plural-Forms value:

"Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || (n"

https://github.com/django/django/blob/0c37bae189b41f3fd89dc10265750c78c91d90ca/django/conf/locale/ru/LC_MESSAGES/django.po#L27

The manage.py makemessages management command copies this value to the new *.po files and makes them wrong.

This bug is present in the core Django translations files too. For example https://github.com/django/django/blob/273ce8aa6ae8a7404f5a9cd08f5e2753f1aa9368/django/contrib/admin/locale/ru/LC_MESSAGES/django.po#L22

This is looks like a regression because a previous Django-1.8.x had the right Plural-Forms value https://github.com/django/django/blob/stable/1.8.x/django/conf/locale/ru/LC_MESSAGES/django.po#L27

Change History (4)

comment:1 Changed 4 years ago by Tim Graham

Resolution: invalid
Status: newclosed

Thanks for the report, however, translations are handled at Transifex and not in this tracker.

comment:2 Changed 4 years ago by Claude Paroz

See also #17065, which explains that Transifex is following the rules from http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html

comment:3 Changed 4 years ago by generalov

Thank you! It's wery interesting case. I've used Django for many years and manage.py makemessages -l ru management command always was generate the ru/django.po files with npluarls=3 for Russian. I've surpriced by this change last month.

tldr: It is a strange issue because in the case of nplurals=4 translators should fill the additional plural form (that CLDR was introduce for fractions in Russian language) in order to the message take a 'translated' state. But this form will nether used by Django world, because gettext advisedly doesn't support fractions in the pluralization functions and recommends to use the another way to handle them.

It seems there is a difference between CLDR and gettext here.

The CLDR was introduce in the Russian language the forth plural form ('other' category) for fractions:

In some languages, fractions require a separate category. For example, Russian 'other' in the example above

http://cldr.unicode.org/index/cldr-spec/plural-rules#TOC-Fractions and they are note below the "fractions are often a bit tricky".

The Django framework uses the ngettext https://docs.python.org/3/library/gettext.html that uses GNU gettext (man 3 ngettext) and there is special note about fractions too at https://www.gnu.org/software/gettext/manual/gettext.html#index-plural-form-formulas (look at last paragraphs below the languages list). Because the fractions are often a bit tricky, they are recommend to use the another way to handle them. The gettext functions advisedly accepts a decimal positive integers values only (unsigned long int n) for pluralization and doesn't have any deal with fractions:

char * ngettext (const char * msgid, const char * msgid_plural,
                        unsigned long int n);

gettext po catalog itself uses nplurals=3 for Russian. https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html . For example http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/po/ru.po#n19

comment:4 Changed 4 years ago by Claude Paroz

Thank you for the detailed explanation. Django is currently using the Transifex service for its translations, and AFAIK Transifex doesn't allow setting different plural strings per project. So for us the alternative is either use Transifex and abide to the plural forms on that platform, or choose another platform with more flexibility (which would be a heavy move).

Note: See TracTickets for help on using tickets.
Back to Top