#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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.809c9d88e3f51463f14424e793e54f88%40djangoproject.com.
