Opened 3 years ago

Closed 3 years ago

#16596 closed Cleanup/optimization (wontfix)

Tags within {% blocktrans %} blocks should work.

Reported by: llugosch@… 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


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 %}


Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by bpeschier

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.