Opened 13 years ago
Closed 13 years ago
#16596 closed Cleanup/optimization (wontfix)
Tags within {% blocktrans %} blocks should work.
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Translations | Version: | 1.3 |
Severity: | Normal | Keywords: | translation |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Tags within {% blocktrans %} blocks break. Presumably, Django's developers have it this way so that long {% if %} blocks and other switches don't get thrown at a helpless translator. An unfortunate consequence is that translated sentences containing tags need to be rewritten, and sometimes this is completely impossible. The alternative is to split the sentence awkwardly where the tag occurs. For example,
This sentence was translated at {% now %} by the good linguists at {% get url etc. etc. %}!
would have to be formatted as something awful like
{% trans "This sentence was translated at" %}{% now %}{% trans " by the good linguists at" %} {% get url etc. etc. %}!
Wouldn't it be better for Djangonaut and translator alike if it could be done like this:
{% blocktrans %}This sentence was translated at {% now %} by the good linguists at {% get url etc. etc. %}!{% endblocktrans %}
?
This seems unfeasible to do since the blocktrans has to be translated to a gettext call with variable substitution, which means the template tag calls should be translated in some form of variable name which wouldn't be pretty for starters.
There is a perfectly simple mechanism to include variables in a blocktrans environment. The only catch is that templatetags should be able to put their output in context to do so. A ticket for (partial) extension of this mechanism can be found at #12104.
If you want to advocate the change in approach for blocktrans I would recommend taking it up on the django-developers mailinglist.