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

[generalov]

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

[Tim Graham]

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

[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

[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

[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).