This is something I have been questioning myself for a while now. Is
the current behaviour of {% trans %} like it should?
We have safe_string, which marks a string as safe for being rendered
in HTML.
{% trans %} blocks appear to be always considered safe. So {% trans
"<strong>test</strong>" %} will render strong text. No escaping is
done.
In this case, it's clear for the translator that he should escape
special characters as HTML, because the text is rendered in a HTML
context.
If it were {% trans "Hello" %}, then the translator can hardly
distinguis between that and ` ugettext("Hello") ` in a Python file.
The first seems to be concidered safe, but the second isn't. So, if
you would pass a context { 'hello': ugettext('Hello') } to the
template and render {{hello}}, it will be escaped.
What if the translation would involve inserting special entities which
are not valid in that context? The translator cannot know that he has
to escape it, because he doesn't know where the text is rendered.
In the past, we have used a patch on gettext, which allowed us to add
meta-information to each translation when we felt the need. Like:
_("comment[[ verb ]]"), _("comment[[ noun ]]"), or _("something...
[[ in html context]]") where the gettext patch always removed the meta
information from the ouput, while it was still present in the PO-files
for the translator.
Any thoughts about this? I'm also curious how other people handle
this, and whether other template languages have similar problems.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
