#30439: Translations issues on Django upgrade due to unexpected changes in plural forms --------------------------------------+------------------------------------ Reporter: Michal Čihař | Owner: Rodrigo Type: Bug | Status: assigned Component: Internationalization | Version: 2.2 Severity: Normal | Resolution: Keywords: | Triage Stage: Accepted Has patch: 0 | Needs documentation: 0 Needs tests: 0 | Patch needs improvement: 0 Easy pickings: 0 | UI/UX: 0 --------------------------------------+------------------------------------
Comment (by Rodrigo): Replying to [comment:22 Michal Čihař]: > Replying to [comment:16 Rodrigo]: > > Then functions like [https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L633 copy_plural_forms] should get it from there, and when syncin', either overwrite it or generate an empty one and do a msgmerge. > > Overwriting plural form will mess up existing translations. For what I understood, this is only used when a new .po file is created by makemessages, if the file exists it will do a msgmerge and I think the plural form will be retained (though it will be overridden in the "general" merge of the catalogs for the language. This seems reasonable with the "only one plural form" support. > > > If you generate and compile the messages using the django-admin commands, there would be no problem, I think the case you are referring is when you put "pos and mos" from external sources - like a translation platform, which for convenience may use less plurals than the corresponding or specified for the languange - in locale dirs which have a different plural forms than the one coming with Django, which is not supported. > > The current mess was started by Transifex, which is AFAIK Django official localization platform. I don't think they support honoring plural forms existing in the file, they always rewrite to whatever they have hardcoded. > > > Then the ticket would be "Add support for variable number of plural forms in Django in order to support different translations platforms outputs", do you agree? > > True, I didn't notice this is covered in the docs. However, in such case Django should not unadvertised change plural forms in existing translations. I agree, it should be covered at least in the Release Notes. > > > > > I still don't understand why Django has the wrong approach, because a language should have only one number of plurals and one plural equation. Once it is right, if you provide less than specified, then it's incomplete. > > I noticed it on Czech where Django has wrong plural form (see above, it can never evaluate to 2, so even if it defines 4 plurals, one of them is never used). Still, there might be valid reason to have different plural forms and equations in different scope. > > I do have quite some insight into this because I develop [https://weblate.org/ Weblate] (using Django), where we put quite some effort to handle plural forms correctly :-). > > The earlier mentioned example of [https://hosted.weblate.org/languages/he/#information Hebrew] can be seen on our public hosting service - 25% of translations use simple two plurals and 75% use more complex four plurals. Both are correct and in many cases the one with two plural forms is working well at it makes it easier for translators. > > Another example where things would be messed up with current Django implementation is Lithuanian, see https://github.com/WeblateOrg/weblate/issues/901 for discussion we had on this at Weblate. I will try to synthesize my previous comments. I'm not saying there may be not valid reasons, I'm saying that I don't see them for what I have understood of the subject so far (I'm new to the domain). Django bases its i18n module on gettext and therefore follows its design. Why gettext does not support multiple pf on merge? I don't know, I only can guess deducing for what I have learn so far. Seems that it's also a gettext choice, every software that uses gettext and merges its catalog will have the same issues. There are two parts of the plural form, the number of plurals and the plural equation. As you said, the number of plurals may be less for convenience (making the life of the translators easier), which is not bad - don't misunderstand me. For what I have inferred of gettext is that this should be handled at the "front-end level", you allow less forms and generate the expected input of gettext with the total forms, i.e. if it evaluates to 4th form and that is the same as the second, then only 2 forms have to be addressed. I can be wrong, this is what I have understood so far. If so, there will be issues with any software using gettext with catalog merging (possibly leaving them empty and using the fallback language). The other part is the plural equation. If different plural equations are needed on different scopes for a language, then this seems a limitation of gettext - but again, I'm not knowledgeable on gettext nor the field. Supporting multiple plural forms via not merging the catalogs would be a way of not making one part of the translation community work interfere (unintentionally) with another part of it. That's a valid reason to me :) Handling broken plural equations is another issue :) The clearer the intention, the easier to get there :) -- Ticket URL: <https://code.djangoproject.com/ticket/30439#comment:24> Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines. -- You received this message because you are subscribed to the Google Groups "Django updates" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-updates+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/063.809c9d88e3f51463f14424e793e54f88%40djangoproject.com.