Translation of application names in admin app: Usage of blocktrans in templates
Ramiro Morales
There have been another [1]thread about translatability of app names in
the admin app.
Actually (and as the people participating in such discussion has found
in the hard way), it seems clear the current handling of the app name in
the admin app templates is broken.
As one [2]thread dating back to from January 2006 shows, having
{% blocktrans with app.name as name %}{{ name }}{% endblocktrans %}
in an admin template as we currently do means there should be a
"%(name)s" msgid in some .po file and that literal is the one
that needs to be translated.
Problem is, this is stripping the variable-ness provided by the app.name
variable (app is a var in a for loop over the app_list context
variable). This means only one app name can be translated (only one of
the translation for "%(name)s" will be taken in account for a AdminSite
instance).
Searching over the repository history, this can be traced back to
revision [3]3270 from July 2006 that introduced usage of the blocktrans
tag in the django/contrib/admin/templates/admin/index.html file, and it
seems work done on other templates simply copied that fragment
([4]r8474, app_index.html).
It is well known there are plans to solve the issue of application
objects (possibly including a way to provide metadata like the name) in
a definitive fashion, and this technique of adding
ugetetxt_lazy()-wrapped literals to some application .py file to get
them in the application/project message file is an interim solution. But
I'd say this usage of blocktrans is intrinsically broken, independent of
which strategy gets used to solve the problem and, because of this, a
bug worth fixing now.
I am willing to open a ticket with a simple patch (that would
essentially just implement the template modifications enumerated
[5]here) to fix this but wanted to get opinions from people with more
experience in this domain.
Regards,
--
Ramiro Morales
http://rmorales.net
1. http://groups.google.com/group/django-users/browse_frm/thread/f8fcbe25e3327c5d
2. http://groups.google.com/group/Django-I18N/browse_thread/thread/5f262db230bb393d
3. http://code.djangoproject.com/changeset/3270
4. http://code.djangoproject.com/changeset/8474
5. http://groups.google.com/group/django-users/msg/ef5a723983e56e96
Malcolm Tredinnick
[...]
> I'd say this usage of blocktrans is intrinsically broken, independent of
> which strategy gets used to solve the problem and, because of this, a
> bug worth fixing now.
Firstly, good analysis of the problem, since (as can be seen by my
response on django-users), I couldn't immediately see why this wasn't
working.
I agree with your conclusion. The "blocktrans" tag is simply being used
inappropriately here. It's a good tag for translating essentially static
template content. What it doesn't do it look inside the variables it
substitutes, so is appropriate where the translation works regardless of
the variable content. It appears particularly severe in this case
because the blocktrans section *only* includes a variable replacement.
This is the old problem that you can't build up truly translatable
sentences from pieces, so if parts of the sentence has replaceable
parts, they are restricted to being things that can be replaced
everywhere.
In this case, the "trans" tag is the right solution, since it does the
translation based on the variable's value: that is, resolves the
variable first and then looks up that string in the message catalog.
> I am willing to open a ticket with a simple patch (that would
> essentially just implement the template modifications enumerated
> [5]here) to fix this but wanted to get opinions from people with more
> experience in this domain.
Yes, I think the ideas posted in the summary in that thread are the
correct solution.
I've got your revisions to the i18/l10n documentation in my pile to
review this weekend, so I'll also have a look at explaining blocktrans
vs. trans usage a bit more clearly.
The fact that I entirely missed why this was failing has me worried. I
know I have my bad days, but I'm not entirely a novice in this area and
until you laid out what's going on, it was confusing (now it's
blindingly obvious). We need to document that better, for sure! :-)
Regards,
Malcolm