>There one problem left: filters use the _() syntax for their >parameter
>string (for example yesno is a candidate for a translated >parameter) to
>mark their parameter string for translation.
Another place where we will need to have the _("...") syntax for
strings to be translated is in template tags that accept constant
strings. We would want to translate them, too. From my gallery project:
<li>{% trans 'Picture:' %}</li>
<li>{% preview_resizer "50" as _("extra small") %}</li>
<li>{% preview_resizer "80" as _("small") %}</li>
<li>{% preview_resizer "100" as _("normal") %}</li>
<li>{% preview_resizer "150" as _("big") %}</li>
<li>{% preview_resizer "200" as _("extra big") %}</li>
Here the 'Picture:' string could easily be changed, but the
preview_resizer tag is something that just get's constant strings and
so I need to mark those for translation.
Looks like I will have to re-add some of the code I just deleted. At
least I don't see a nice way around that - every string constant in
template tags is a possible candidate for translation and so needs the
possibility to be marked up. It was done in the read_constant_string
function of the Parser thingy that is responsible for resolve_variable
and resolve_variable_with_filters. So actually that change will bring
back {{ _('anton') }} as a side effect, because {{ 'anton' }} now is
already a valid syntax.
But I won't readd the python string inperpolation against the context
;-)
bye, Georg
