Opened 8 years ago

Closed 5 years ago

#5972 closed (fixed)

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

Reported by: Dmitri Fedortchenko <zeraien@…> Owned by: nobody
Component: Internationalization Version: master
Severity: Keywords: i18n template i18n-nofix
Cc: benspaulding Triage Stage: Design decision needed
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: no
Easy pickings: UI/UX:

Description

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

Attachments (5)

trans_understands_filter_alternate_version.diff (2.0 KB) - added by Dmitri Fedortchenko <zeraien@…> 8 years ago.
trans_understands_filter_alternate_version.2.diff (2.2 KB) - added by Dmitri Fedortchenko <zeraien@…> 8 years ago.
the backwards compatiblity fix in the previous patch was a little weak. This one does the trick a little better.
trans_understands_filter_alternate_version.3.diff (2.2 KB) - added by Dmitri Fedortchenko <zeraien@…> 8 years ago.
Cosmetic fix.
trans_understands_filter_alternate_version.4.diff (3.0 KB) - added by Dmitri Fedortchenko <zeraien@…> 8 years ago.
Fixes the backwards compatiblity issue and knocks out an inconsistency in the FilterExpression parser at the same time.
trans_understands_filters.diff (2.0 KB) - added by Dmitri Fedortchenko <zeraien@…> 8 years ago.
This patch should be now be fully functional, however it the patch in ticket 5980 is strongly recommended.

Download all attachments as: .zip

Change History (16)

Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

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

Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

Cosmetic fix.

comment:1 Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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

Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

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

comment:2 Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

  • Patch needs improvement set

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

Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

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

comment:3 Changed 8 years ago by Dmitri Fedortchenko <zeraien@…>

  • Patch needs improvement unset

comment:4 Changed 8 years ago by shanx

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?

comment:5 Changed 8 years ago by 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.

comment:6 Changed 7 years ago by MichaelBishop

  • Summary changed from Use filters with {% trans %} tag to Use filters with {% trans %} tag - depends on #5971
  • Triage Stage changed from Unreviewed to Design decision needed

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

comment:7 Changed 6 years ago by ramiro

  • Needs documentation set
  • Needs tests set

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)

comment:8 Changed 6 years ago by benspaulding

  • Cc benspaulding added

comment:9 Changed 6 years ago by ramiro

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

comment:10 Changed 6 years ago by garcia_marc

  • Keywords i18n-nofix added

comment:11 Changed 5 years ago by jezdez

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.
Back to Top