I’ve enjoyed digging even deeper into the lazy text questions that I came up with last time. The “thingamajig” returned by ugettext_lazy indeed waits until unicode is called upon it, then it runs through translation.

You can see this by the way ugettext_lazy is defined. It’s in core/utils/translation/__init__.py:

That call to lazy produces a bit of functional programming magic (see core/utils/functional.py for the def lazy) that results in ugettest_lazy calling ugettext (the standard translation function) whenever its unicode value is requested (i.e., every time it’s used as a string.)

Fancy stuff, to my little brain anyway.

Inspired by Malcolm Tredinnick‘s appearance on TWiD 19, I decided to create a small dummy site and work through the steps of translating it to German.

Setting up all the translation files was easy enough, but then the first thing that bit me was overlooking this instruction on Django’s Internationalization documentation page:

Always use lazy translations in Django models.

Such a short, innocent sentence! Easy to miss. But the author (Malcolm himself, I believe) means it. Always use lazy translations in models.

My model contained:

I then displayed the model form (ProjectForm) in a template. The template also contained a language switcher, following the directions concerning the set_language redirect view. I ran the app and used the set_language redirect to set my language to German (the default language of the app was English.) I expected the combobox — the one auto-generated by using the choices parameter when defining the status member of the model — to show me German options, because I’d defined those options (when setting the values of the PROJECT_STATUSES tuple) to have translated text values.

Of course they displayed English options instead of German, because I used ugettext instead of ugettext_lazy. The question is, do I understand why ugettext doesn’t work? One of my goals during TDI is to understand how and why things work the way they do in Django. I haven’t dug into this yet, but I think it can be explained something like this: at the time the models.py is evaluated and, therefore, the time the PROJECT_STATUSES variable is filled, the thread (or whatever it’s called in this context) is still running under the site’s default locale. Since that’s English, when ugettext gets called it just returns the original string, since I haven’t specified any English translations. Only later (I guess when about to render a response?) is the user’s (i.e., session’s) locale evaluated and used. By that time, PROJECT_STATUSES values have already been sent through the translation engine, so they’re not sent through again.

So maybe ugettext_lazy returns some sort of thingamajig that doesn’t call into the translation engine until its __unicode__ function is accessed. I would guess that’s what the documentation means by…

The translation itself will be done when the string is used in a string context.

I look forward to digging deeper by:

• Searching for and learning about the place in Django code where the switch from the default to the session-specific locale takes place.
• Reading through the ugetext_lazy code to see how it works.