Discussion:
Translation of messages with automatic content into inflecting languages.
Strahinja Lukic
2017-11-10 17:00:08 UTC
Permalink
Hi,

I am relatively new to Django, and I recently ran into the problem of
translating messages with automatic inclusion of model names / verbose
names into a language in which nouns are inflected depending on the gender
and case. I see that this problem occurs in forums, but has no definitive
solution. Occasionally people suggest using more case/gender neutral
messages, but this approach has both linguistic and technical difficulties.

Has anyone yet looked into the possibility to have Django expand the
automatic parts of messages *before* ugettext(), so that the *expanded*
messages would appear in the message files to be translated as a whole?
Would that be even possible?

Thanks for any insight/suggestion.
--
You received this message because you are subscribed to the Google Groups "Django internationalization and localization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-i18n+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
Visit this group at https://groups.google.com/group/django-i18n.
For more options, visit https://groups.google.com/d/optout.
Mathias Rav
2017-11-10 19:38:19 UTC
Permalink
On Fri, 10 Nov 2017 09:00:08 -0800 (PST)
Post by Strahinja Lukic
I am relatively new to Django, and I recently ran into the problem of
translating messages with automatic inclusion of model names / verbose
names into a language in which nouns are inflected depending on the gender
and case. I see that this problem occurs in forums, but has no definitive
solution. Occasionally people suggest using more case/gender neutral
messages, but this approach has both linguistic and technical difficulties.
I don't have any solutions to this problem but I just want to give an
example in my own native language:

In the Danish translation of the Django admin, "Save and add another"
is translated into "Gem og tilføj endnu en", which is correct and
literally means "Save and add another one".

Unfortunately this translation uses the gendered pronoun "en" which
should ideally be inflected according to the gender of the model being
added/modified, using "en" for nouns of common gender and "et" for
nouns of neuter gender. The variant "Gem og tilføj endnu" is not
grammatically valid; the Danish language only has a translations of
"another one" and not of simply "another" in this context.

I don't know how Django could accomodate automatic inflection of such
messages.

Best,
Mathias Rav
--
You received this message because you are subscribed to the Google Groups "Django internationalization and localization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-i18n+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
Visit this group at https://groups.google.com/group/django-i18n.
For more options, visit https://groups.google.com/d/optout.
Strahinja Lukic
2017-11-11 08:59:23 UTC
Permalink
Hi Mathias,

Thanks for sharing your example. I agree, there is no point attempting to
provide automatic inflections.

I was just wondering the following:
At present, the message file for the app can be made to provide
translations for all messages with inflected forms that appear in the app.
However, wherever the app uses automatic inclusion of e.g. model names,
ugettext() will look for translation *before* expanding the automatic text.
In your example, ugettext("Save and add another %s") will return "Gem og
tilfÞj endnu en %s", and "%s" will be translated separately.
Thus, even if you provided separate translations for different genders in
the message file, these translations will not be used.
Imagine if ugettext() was looking for translation *after *expanding "%s".
In that case, one would have the following sequence of transformations when
"%s" stands for, e.g., "user"
ugettext("Save and add another %s") -> ugettext("Save and add another
user") -> <message provided in the message file for this specific case>.

The translator would now be able to anticipate the messages that will
appear in the app as a result of automatic inclusions and provide
translations for each specific case.

I would find such a feature immensely helpful.
--
You received this message because you are subscribed to the Google Groups "Django internationalization and localization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-i18n+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
Visit this group at https://groups.google.com/group/django-i18n.
For more options, visit https://groups.google.com/d/optout.
Strahinja Lukic
2017-11-14 19:58:17 UTC
Permalink
Hi Maciej,

Thanks for your suggestion. This is nearly the kind of thing that I wanted
to do.
But if I am not mistaken, makemessages cannot capture expanded messages,
since it analyses the code when it is not running, so it cannot predict
what will be expanded. So it seems to me that changing the gettext calls in
this way would break the standard translation workflow with
makemessages/compilemessages. This way the whole idea starts to look more
complicated than alternative solutions.

Perhaps a new variant of the gettext function could offer the desired
behavior in the translation step, while avoiding breaking things in the
makemessages step. I will look into this and post an update if I have any
success.

Best,
Strahinja
--
You received this message because you are subscribed to the Google Groups "Django internationalization and localization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-i18n+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
Visit this group at https://groups.google.com/group/django-i18n.
For more options, visit https://groups.google.com/d/optout.
Loading...