Makemessages currently does not support alternative template languages

[cordery@…]

Makemessages currently does not support alternative template languages, as it uses open() directly and therefore does not give alternative template languages the chance to preprocess templates. This seems an oversight as alternative template languages seems to be intended to be supported by Django, as discussed here ​https://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language

When using alternative template languages like hamlpy (​https://github.com/jessemiller/HamlPy), this prevents the templates from being parsed for trans and blocktrans tags.

In hamlpy they tried to solve it by monkeypatching django.utils.translation.trans_real.templatize but I think a better solution would be add a function to the loader module, get_template_source(), which operates using the same machinery as get_template but returns source rather than the compiled template. Makemessages could then use this new function to try to read each discovered file using the template loaders, before resorting to open().

This would enable makemessages to properly find trans and blocktrans tags in template files from other templating systems. For example in hamlpy these tags might appear like this:

- trans "hello"
- blocktrans
  This is a block trans'd string.

Which could not be read by makemessages. get_template_source would use the hamlpy loader to load the template.haml file, and compile it to:

{% trans "hello"
{% blocktrans %}
This is a block trans'd string
{% endblocktrans %}

Which can be read by makemessages.

I will momentarily submit a pull request regarding this ticket.

[cordery@…]

Patch here ​https://github.com/cordery/django/tree/ticket_20811

Will submit a pull request.

[Tim Graham]

​PR is here.

[Ramiro Morales]

Some historical information for your review:

Back in the times, we used to have a get_template_source() method on template loading backends.

They were removed with the refactoring work associated with the introduction of template caching (#6262 / [44b9076bbe]).

After that, there was at least one report asking for its reintroduction: #15102. Please don't take my comments on that ticket as a -1 to something like this. At the time I didn't grasp how having an abstraction to get the raw template source code could help in integrating other templating languages.

[cordery@…]

Hamlpy gets around this by decorating django.utils.translation.trans_real.templatize as seen here: ​https://github.com/jessemiller/HamlPy/blob/master/hamlpy/templatize.py

Although note that this code is parsing all files instead of only those with hamlpy extensions, so is actually broken when mutliple template formats are used.

While this method is workable I feel that if Django wants to support other template languages (many of which, like haml, are quite popular these days), then a more consistent and intuitive approach would be to always use the template loaders to load template files before trying a direct open(), particularly in cases like makemessages where I assume performance is not typically an issue.

[Aymeric Augustin]

Given the implementation of multiple template engines that landed in Django 1.8, Django template loaders aren't the right point to fix this problem anymore. For this reason I'm closing the ticket.

Unfortunately internationalization didn't make it in Django 1.8. Further work is tracked in #24167.