Pluralization support too limited

[trevor@…]

Django's pluralization support is fine for English, since we only have two number forms, singular and plural. However, this is not the case for many of the world's languages. This has the effect of translations unavoidably being incorrect in certain languages where the number scheme is incompatible with Django's. For a more-or-less comprehensive catalog of these possible schemes, see ​http://eiffelsoftware.origo.ethz.ch/index.php/Internationalization/plural_forms. For example, ​http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html cites Rafal Maszkowski's illustration of this problem in Polish:

   In Polish we use e.g. plik (file) this way:
              1 plik
              2,3,4 pliki
              5-21 plików
              22-24 pliki
              25-31 plików
    and so on. 

Each of those pages describes the issue quite well.

[Malcolm Tredinnick]

Can you be more specific about the actual bug(s) you are reporting here, please? We are well aware that there are multiple plural forms in other languages. Django's internationalization support in templates and the Python source can handle this already. There are a couple of known places (mentioned in other tickets in the internationalization component here) where we still need to try and make some improvements (might not always be possible, but we're going to try).

So, please file a specific problem report. At the moment, this is far too general (and a bit inaccurate, since we already support plural forms).

[Russell Keith-Magee]

If you search the ticket archive, you will see that this issue has come up before (See #794, #2202). It has also been proposed and discussed at length on the mailing lists. The outcome of those discussions has historically been to reject this idea.

Pluralization is almost impossible to handle in such a way as to be both comprehensive enough to support languages like Polish with complex pluralization requirements, while remaining simple to use for those languages that have relatively simple pluralization requirements (Cases 1-5 in the page you reference).

If you have a specific suggestion for an elegant way to handle Polish (and other complex pluralization cases) that is compatible with existing usage, feel free to reopen this ticket.

[Malcolm Tredinnick]

Russell: we already handle things like the pluralisation requirements of Polish in the PO files (translators can specify arithmetic functions to specify which plural form to use and then ungettext() is used in the code). That being said, without more details about the reporter's actual problem, it's hard to know where the gaps are (aside from the known tickets I referred to earlier).

[Russell Keith-Magee]

Malcolm: I took his comments to be referring to the pluralize template filter. Adding Polish/Czech/Serbian etc pluralization is something that has been suggested many times before, and Adrian has knocked back because developing a 100% solution is near impossible, and the i18n framework can handle pluralization for the complex cases.

Trevor: If I've misunderstood your issue, please reopen the ticket with more details of your specific problem.

[trevor@…]

django.utils.translation.ungettext() is an example of a function which only knows about the singular vs. plural scheme. It could instead accept the same parameters, but generate the more complete selection of plural configurations, and annotate each with its respective plural form. The same principle could apply to {% blocktrans %} / {% plural %}.

[Mitar]

I think all those wontfix tickets (#794, #2202 and #5997) are a little bit strange as this is something gettext have already solved through ungettext and similar functions. So ​Python gettext implementation of ungettext already supports complex plural systems which enable also multiple possible values for plural forms and defining a mechanism of choosing one. So parameters to ungettext are just fallback values but a translator can define more complex pluralization. As I understand Django already supports this through {% blocktrans %} and {% plural %} blocks in templates.

I have opened a ticket, #11688, with a clean and backwards compatible solution (as it is written: So, please file a specific problem report.) to this problem for models, but was marked as a duplicate and pointed to other wontfix tickets (also this one). Now I am trying another suggestion and I am reopenning this ticket with my suggestion for models, more precisely that verbose_name should allow dynamical translation based on a number.

verbose_name of meta data for models should allow dynamical translation based on a number of elements through ungettext and not just two possibilities of verbose_name and verbose_name_plural which is not enough for languages with complex plural forms. Django could check if verbose_name is a function and call it with a number of elements as a parameter. This would also be backwards compatible. (verbose_name_plural would then be ignored.)

Implementing this would make us one step closer to support wide range of languages with complex pluralization forms. And I do not see anything too hard or impossible in this step by step approach to get a comprehensive enough solution at the end.

[Malcolm Tredinnick]

The solution here isn't to keep reopening tickets. We also aren't unconvinced that multiple plural forms are a good idea -- since Django clearly already supports that in a lot of places. I am going to reopen #11688, since it is fairly specific. However, there has been a lot of discussion around this area on the mailing list and you haven't referenced any of it, so please spend some time in the archives looking at the difficulties involved in this as a broader topic.