How to properly add entries for computed values to the django internationalization messages file?

Question

Django documentation states:

The caveat with using variables or computed values, as in the previous two examples, is that Django's translation-string-detecting utility, django-admin.py makemessages, won't be able to find these strings.

That is fine with me, I'm ready to provide translations for all possible values of the translated variable by hand. But how to do that?

Let's say I have in my template code like this:

{% trans var %}

The var is extracted from the database, and I know all of the possible values of it - let's say the possible values are "Alice" and "Bob".

I thought all I need to do is provide entries like these:

msgid "Alice"
msgstr "Alicja"

in django.po file. Unfortunately, whenever i run djangoadmin makemessages after that, these entries are being commented out:

#~ msgid "Alice"
#~ msgstr "Alicja"

What am I doing wrong? Have I misunderstood the idea of translating computed values?

score 13 · Accepted Answer · answered Nov 18 '11 at 02:35

We're currently in the process of figuring this out as well. While we haven't done so properly, we do have a rather annoyingly ugly hack to get around it.

We simply define a "dummy" function somewhere in the code (for example your models.py or even settings.py) and fill it up with all the strings that we need to have a translation for.

from django.utils.translation import ugettext_lazy as _, pgettext

def dummy_for_makemessages():
    """
    This function allows manage makemessages to find the forecast types for translation.
    Removing this code causes makemessages to comment out those PO entries, so don't do that
    unless you find a better way to do this
    """
    pgettext('forecast type', 'some string')
    pgettext('forecast type', 'some other string')
    pgettext('forecast type', 'yet another string')
    pgettext('forecast type', 'etc')
    pgettext('forecast type', 'etc again')
    pgettext('forecast type', 'and again and again')

This function is never called but simply defining it prevents the message strings from getting commented out by makemessages.

Not the most elegant solution but it works.

It seems there is no "correct" "elegant" and widely accepted solution. A pity. Yours seems optimal to me, thanks! — Przemysław Pietrzkiewicz, Dec 15 '11 at 00:48
You can also use a template for that (you don’t even have to use that template anywhere in your applications). See [this gist](https://gist.github.com/4298465) for an example. Also please note that you can use special packages when you deal with model objects translation (they even allow you to edit the translation using the admin site). I’ve added a couple of links in a comment to the gist. — Arseny, Dec 15 '12 at 19:39
I think this is good only for strings, which don't appear in any code at all (nor in fixtures, etc.), like a string completely "from outside" - like from a stranger webservice etc. Otherwise there are other solutions (see my answer). — Tomasz Gandor, Jan 09 '13 at 15:37

score 1 · Answer 2 · answered Jan 09 '13 at 15:20

There is one nice way of doing this! (I know, because I happened to work on the same code).

First of all - this value is computed somewhere. So, in your action, you may have:

context['var'] = 'good' if condition(request) else 'bad'

and later in the template:

{% if var == 'good' %}
    {% trans "Congratulations, var equals: "}
{% else %}
    {% trans "Oops, var equals: "}
{% endif %}
{% trans var %}

You may have different values, which can become impractical... Unless you use this trick:

_ = lambda x: x 
context['var'] = _('good') if condition(request) else _('bad')

You need to make _ something local if you don't want to clash with ugettext_lazy, etc.

This way, you're not:

translating prematurely
using some lame "dummy" redundant function to "list" your translated strings
messing up, and having to give up manage.py makemessages

score 0 · Answer 3 · edited Dec 18 '14 at 12:54

0

I ended up solving it with a similar solution suggested in @StFS answer.

When I used pgettext('forecast type', 'some string'), then using {% trans varName %} in my template still returns "some string" instead of "New Text" for the translation.

So I have changed the syntax in the function to gettext('some string').

Now using {% trans varName %} would give "New Text" in my template.

edited Dec 18 '14 at 12:54

rakhi4110

9,253
2
30
49

answered Dec 18 '14 at 07:56

shlomiLan

659
1
9
33

Why to you say that this doesn't answers the question? it will allow for adding string that will not be comment-out in the translation file. so what did I missed? – shlomiLan Dec 18 '14 at 12:31
1

This looks more of an enhancement to StFS answer than an answer in itself. Hence would have been good if it was included in StFS answer than having it here. However I am removing my comment for now and formatting your answer a bit. – rakhi4110 Dec 18 '14 at 12:43

How to properly add entries for computed values to the django internationalization messages file?

3 Answers3

Linked