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

前端 未结 3 1713
不思量自难忘°
不思量自难忘° 2021-01-04 08:11

Django documentation states:

The caveat with using variables or computed values, as in the previous two examples, is that Django\'s translation-stri

相关标签:
3条回答
  • 2021-01-04 08:24

    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.

    0 讨论(0)
  • 2021-01-04 08:29

    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.

    0 讨论(0)
  • 2021-01-04 08:42

    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
    0 讨论(0)
提交回复
热议问题