Internationalization KeyError in templates

[Adrian]

I get the error Keyerror when using internationalization in this context:

{% load i18n %}
{% blocktrans %}
Name: {{ data.name }}
{% endblocktrans %}

data pass a dictionary to the template, where data[ 'name' ]=Name

This doesn't works, it raises Keyerror exception.

d  	
{'data': {'name': u'Name', }}
key 	
u'data.name'
self 	
[{}, {'data': {'name': u'Name', }}]

[rskm1@…]

I just ran into this too; glad I searched before posting. I wasn't sure whether it was a bug, but it makes using {% blocktrans %} very clumsy. I'm using the subversion r7020 trunk.

<p>Untranslated version of user name: {{ user.first_name }} {{ user.last_name }}</p>

That works fine; nice and straightforward. But unfortunately,

<p>{% blocktrans %}Translated version of user name: {{ user.first_name }} {{ user.last_name }}{% endblocktrans %}</p>

That throws a KeyError exception,

  Exception Type: KeyError
  Exception Value: u'user.first_name'
  Exception Location: /usr/lib/python2.4/site-packages/django/template/context.py in __getitem__, line 43
  Python Executable: /usr/bin/python
  Python Version: 2.4.3

In the traceback, I see where {% blocktrans %} is "flattening" all of the variable nodes into plain ol' strings; line 82 of /usr/lib/python2.4/site-packages/django/templatetags/i18n.py:

        data = dict([(v, force_unicode(context[v])) for v in vars])  # line 82
        context.pop()
        return result % data

I hope that's just a bug or a "shortcut" that can be implemented better (I'm just a novice, but I'm hoping that blocktrans can leave the tree of nodes intact, rather than doing that string-flattening and "immediate" rendering on line 84).

If that's not a bug, the workaround is awfully ugly and annoying. But this does work:

<p>{% blocktrans with user.first_name as u_f_n and user.last_name as u_l_n %}Translated version of user name: {{ u_f_n }} {{ u_l_n }}{% endblocktrans %}</p>

[R Kemmetmueller <rskm1@…>]

Hmm, on closer inspection, this is probably a duplicate of ​http://code.djangoproject.com/ticket/5073

And thinking about it some more, although it IS awfully cumbersome and unwieldy to give new names to all of an object's sub-fields, it does make sense in many cases to expose a "meaningful" name to the person that's writing the translations, rather than exposing your internal class design to them (since that might NOT have such intuitive field names as my example).

[Malcolm Tredinnick]

This isn't a bug. It's by design and is documented. As noted in comment 2, it gives the translator a less opaque string that they have to copy faithfully without making a single typo. This is much easier to check.