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

On Nov 18, 4:41 pm, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote:
> 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 
> patchhttp://code.djangoproject.com/ticket/5972
> ?
>
> On Nov 18, 7:43 am, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote:
>
> > 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 <[EMAIL PROTECTED]>
> > wrote:
>
> > > 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/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to