Using filters with {% trans %} tag

[Dmitri Fedortchenko]

Once again I return with my whacky ideas.

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

Does anyone think this is useful?

PS: the patch is not too complicated, it replaces about 10 lines of
code and adds 10 extra. but the results are magnificent! ;-)

[Malcolm Tredinnick]

On Sat, 2007-11-17 at 17:47 -0800, Dmitri Fedortchenko wrote:
> Once again I return with my whacky ideas.
>
> 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...
>
> Does anyone think this is useful?

+1 from me, providing it doesn't break the existing usage with _().
Create a ticket and attach the patch.

Malcolm

--
The sooner you fall behind, the more time you'll have to catch up.
http://www.pointy-stick.com/blog/

[Dmitri Fedortchenko]

Ok I put it up.

It does not affect the _() syntax at all, except for allowing the use
of _() within a trans tag... But I don't feel that it is a problem.

The patch includes a backwards-compatiblity workaround. Again I bring
up the single/double quote issue, but since {% trans %} works with
single quotes and FilterExpression does not, I had to add a few lines
of code to fix strings surrounded with single quotes so they would be
surrounded with doubles instead :)

There are still some issues around that actually, for example if the
user has something like this:

{% trans 'Please select an "object"' %}

It will be broken with the new patch since the single quotes will be
replaced with doubles. I am working on some ideas on how to combat
this since simply escaping the quotes with two \\ does do the trick
because FilterExpression interprets them literally...

Now it's time for bed.

//D

On Nov 18, 4:09 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Dmitri Fedortchenko]

I found something.

FilterExpression seems to be a bad boy.

Check out these two pieces of code (in the __init__ function of
FilterExpression):
if i18n_constant:
var = "'%s'" % _(i18n_constant)
elif constant:
var = "'%s'" % constant
======================
if i18n_arg:
args.append((False, _(i18n_arg.replace(r'\"',
'"'))))
elif constant_arg is not None:
args.append((False, constant_arg.replace(r'\"',
'"')))

One fixes escaped strings, the other does not. This is inconsistent.
Picture:

{{ _("This is an \"object\"")|filter:"Some\"thing\"" }}

This will be parsed ok, but the translation will fail.
Adding replace('\"','"') to the "constant" in the first piece of code
will solve this little problem and it seems only fair that you should
be able to escape doublequotes (since it's clearly possible in filter
arguments)...

Should I start a new ticket for this or bake it into the "backwards
compatibility fix" of my i18n templatetag patch http://code.djangoproject.com/ticket/5972
?

[Dmitri Fedortchenko]

I killed a few birds with one stone.

This patch turned out to be even more interesting then I thought.

As I was working on it I found a really neat way to move even more of
the implementation out from the templatetag itself and into the
template processor. Check it out:
http://code.djangoproject.com/ticket/5972

This is the patch to fix FilterExpression's treatment of escaped
quotes:
http://code.djangoproject.com/ticket/5980

I've now been using these patches on my own django projects and they
feel solid.
However if someone was relying on the lack of escape processing in
FilterExpression for some strange hacks, then they may have some
issues.

//D

> compatibility fix" of my i18n templatetag patchhttp://code.djangoproject.com/ticket/5972