Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translations in template vars with a macro are not picked up #27

Closed
joeribekker opened this issue Feb 4, 2016 · 4 comments
Closed

Translations in template vars with a macro are not picked up #27

joeribekker opened this issue Feb 4, 2016 · 4 comments

Comments

@joeribekker
Copy link

When upgrading a project from Django 1.6 to 1.8, several libraries had to be updated as well. One of them was BabelDjango 0.2.2 to django-babel 0.4.0.

One particular type of translation in templates was no longer picked up by the extract function in pybabel. When I run pybabel extract and pybabel update on the following template:

<html>
{% trans "test1" %}

{{ _('test2') }}

{% macro label(label) %}
    <label>{{ label }}</label>
{% endmacro %}

{{ label(_('test3')) }}

{% call macros.label(_('test4')) %}{% endcall %}
</html>

The output is:

#: templates2/staff/base.tmpl:3
msgid "test1"
msgstr ""

#: templates2/staff/base.tmpl:4
msgid "'test2'"
msgstr ""

#: templates2/staff/base.tmpl:12
msgid "'test4'"
msgstr ""

So test3 is not picked up anymore. I tried several combinations and/or versions of libraries, but could not get it to work with Django 1.8. I also compared the extract functions that both BabelDjango 0.2.2 and django-babel 0.4.0 use and not much changed there. My guess is that the extract function in django-babel does not pick up this translation with Django's template engine changes.

Installed packages (where "test3" is not picked up by extract)

Django==1.8.9
Jinja2==2.7.1
django_jinja==2.1.1
Babel==2.2.0
django-babel==0.4.0

Installed packages (where "test3" is picked up by extract)

Django==1.6.10
Jinja2==2.7.1
jingo==0.6.1
Babel==1.3
BabelDjango==0.2.2
@graingert
Copy link
Contributor

It looks like {% call %} is a custom template tag

@joeribekker
Copy link
Author

It's part of Jinja, yes. I don't think it has to do with that, but rather that it does work within block tags, but not within variable tags that has additional stuff (like a macro call).

Just after posting the issue here, we got it to work by reverting to our previous mapping file used by pybabel*:

-[django: templates/**.tmpl]
+[jinja2: templates/**.tmpl]
+extensions= jinja2.ext.i18n, jinja2.ext.with_

*To make that work we also added from django.conf import settings; settings.configure() to the pybabel script or it would complain.

When upgrading, we thought these extension would be picked up from the Django 1.8 template settings, where these extension are also defined:

TEMPLATES = [
    {
        'BACKEND': 'django_jinja.backend.Jinja2',
        'OPTIONS': {
            'debug': DEBUG,
            'match_extension': '.tmpl',
            'extensions': [
                'jinja2.ext.with_',
                'jinja2.ext.i18n',
                'django_jinja.builtins.extensions.UrlsExtension',
                'django_jinja.builtins.extensions.CsrfExtension',
            ],
            ...
        }
    }
]

@graingert
Copy link
Contributor

@joeribekker can you create a PR with some tests that use Jinja2 in your usecase?

benwad pushed a commit to benwad/django-babel that referenced this issue Feb 10, 2016
@akx
Copy link
Member

akx commented May 2, 2016

You should use Jinja's Babel extractor with Jinja-based templates, not the Django one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants