A few things stuck out for me in this week’s episode (TWiD 23):

• The staff_member_required decorator. Didn’t know about it.
• Discovering Jannis Leidel in Germany. Check out the things that he is working on. Very interesting projects.

Also, for the first time (and as part of TDI), I "actively" followed along with the show by doing things like viewing Trac to see the commit mentioned in "Tracking Trunk", checking out the links to "Community Catch-Up" items as they spoke about them, etc.

Thanks for doing the show, guys!

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.

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.

• Listen to each new TWiD as it comes out.
• During the "Tracking Trunk" part of TWiD, choose one or two of the more interesting commits, use Django Trac to examine their diffs and try to understand what’s going on.
• Review all previous TWiD show notes.
• Subscribe to the Django-Users mailing list.
• When reviewing mailing list updates, pick one of the more interesting messages and dig deeply into the topic or problem discussed in that message.
• Just generally be more ambitious about diving into Django’s source code to see how things work.

Of course the time that I need to spend to do this will be taken from other parts of my day. I’m therefore going to abandon my RSS reading lists (except feeds of Django-related content) for a month or so. That’s one thing I think I can cut out without much suffering. TV would be another, as would the reduction of weekend laziness. We’ll see how it goes.