Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#20811 closed New feature (wontfix)

Makemessages currently does not support alternative template languages

Reported by: cordery@… Owned by: nobody
Component: Internationalization Version: dev
Severity: Normal Keywords: makemessages i18n
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

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.

Change History (7)

comment:1 by cordery@…, 11 years ago

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

Will submit a pull request.

comment:2 by Tim Graham, 11 years ago

Component: TranslationsInternationalization

comment:3 by Ramiro Morales, 11 years ago

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.

Last edited 11 years ago by Ramiro Morales (previous) (diff)

comment:4 by cordery@…, 11 years ago

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.

comment:5 by Tim Graham, 11 years ago

Triage Stage: UnreviewedAccepted

comment:6 by Tim Graham, 10 years ago

Patch needs improvement: set

comment:7 by Aymeric Augustin, 10 years ago

Resolution: wontfix
Status: newclosed

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#.

Version 0, edited 10 years ago by Aymeric Augustin (next)
Note: See TracTickets for help on using tickets.
Back to Top