Use filters with {% trans %} tag - depends on #5971

[Dmitri Fedortchenko <zeraien@…>]

I want to apply filters to my translations in the templates. So.....
I have created a patch which allows use of the following syntax:

{% trans "username"|capfirst|slice:"2:" noop %}
{% trans  somevar|slice:"2:" %}

The filters are applied on the result of the translation, and not the
translation id string.

While this is already possible by using the {{ _("username")|filter }}
syntax, I think that {% trans %} is more "django-ish" and looks nicer
too...

An important note:
This patch depends on ticket ​5971.
I have a patch that is free from that dependency, however since I got a positive response on said ticket I am posting the dependent patch. It's a bit smaller and fancier :)

See:
​thread1
​thread2

[Dmitri Fedortchenko <zeraien@…>]

the backwards compatiblity fix in the previous patch was a little weak. This one does the trick a little better.

[Dmitri Fedortchenko <zeraien@…>]

Cosmetic fix.

[Dmitri Fedortchenko <zeraien@…>]

This patch has a possible backwards compatiblity issue.

Existing {% trans 'Something "or" other' %} strings will be converted into:
"Something "or" other" (including the outer quotes), so they will become invalid strings.

I am working on some ideas for this, but essentially it might require some work within FilterExpression itself...

[Dmitri Fedortchenko <zeraien@…>]

Fixes the backwards compatiblity issue and knocks out an inconsistency in the FilterExpression parser at the same time.

[Dmitri Fedortchenko <zeraien@…>]

Current patch is a little broken, for some reason setting the filter_expression.var breaks a few things.
Working on it.

[Dmitri Fedortchenko <zeraien@…>]

This patch should be now be fully functional, however it the patch in ticket ​5980 is strongly recommended.

[Remco Wendt]

We are discussing this issue here with the three of us, but are wondering what a possible use case would be for providing this change?

Possibilities we see are:

1. Your string is hardcoded and translations are done or in your python code by using gettext, or doing the same thing in your template by the facilities django templates provide.
2. Your values come from a database backend and you take care of translations there.

Could you please explain to us what you are trying to do here?

[Dmitri Fedortchenko <zeraien@…>]

I am just trying to avoid double translations.

In the django admin you can set verbose_name for models and fields, these are usually set using gettext_lazy. Django admin capitalizes these verbose_names sometimes and other times it uses the lower case version. Thus you only need one translation, for the lower case version.

Also, picture localizations in Japanese or Chinese. There are no capital letters in either language, so an english localisation would use automatic capitalisation and this would not require japanese or chinese translators to translate duplicate versions of many words.

This of course only affects titles and names of objects, not phrases and messages.

Example 1 - after patch:

{% trans "search" %}
{% trans "search"|capfirst %}

Example 2 - before patch:

{% trans "search" %}
{% trans "Search" %}

Example 1 requires only one translation while example 2 requiers two translations.

So the two main reasons are verbose_name in Admin and languages without capital letters.

However I am sure there are other reasons that I haven't thought of.

[MichaelBishop]

Ticket #5971 has been accepted, but needs tests. Once that patch is applied, this ticket should be evaluated.

[Ramiro Morales]

In addition to the use cases and rationale for this feature Dmitri mention both in the description and in ​comment 5 I think it's worth emphasizing that the

{% trans somevar|somefilter[|...] %}

case (i.e. argument to trans is a variable) is specially useful.

Currently, this can be implemented with a more verbose construct like:

{% filter somefilter[|...] %}
{% trans somevar %}
{% endfilter %}

But I've found it only works when somevar is a context variable itself (e.g. name) but now when it's an attribute of a variable (e.g. app.name)

[Ramiro Morales]

The possibility to use filters in arguments was implemented for non-i18n template tags in r10119.

[Jannis Leidel]

(In [12472]) Fixed #5972 - Allow the template filters to be used with the trans tag. Thanks for the initial patch, Dmitri Fedortchenko.