Opened 10 years ago

Closed 10 years ago

#6368 closed (invalid)

Internationalization KeyError in templates

Reported by: Adrian Owned by: nobody
Component: Internationalization Version: master
Severity: Keywords: keyerror dictionary blocktrans
Cc: aribao@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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

{% load i18n %}
{% blocktrans %}
Name: {{ }}
{% endblocktrans %}

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

This doesn't works, it raises Keyerror exception.

{'data': {'name': u'Name', }}
[{}, {'data': {'name': u'Name', }}]

Change History (3)

comment:1 Changed 10 years ago by 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/ 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/

        data = dict([(v, force_unicode(context[v])) for v in vars])  # line 82
        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>

comment:2 Changed 10 years ago by R Kemmetmueller <rskm1@…>

Hmm, on closer inspection, this is probably a duplicate of

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).

comment:3 Changed 10 years ago by Malcolm Tredinnick

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top