i18n for applications and modules

[Hans-Joachim Widmaier]

Internationalizing Python applications is not really hard, and there are 
some useful how-tos available for the beginner.

I've written several (still smallish) applications and localized them.
Although it works, it has some rather inelegant areas or rough edges 
that keep nagging me.

1. Python itself is not really ready for i18n. Some modules, like 
optparse (or argparse in 2.7) create user-visible messages, but are not 
prepared for localization. Since I needed to add some functionality to 
optparse anyways, I've done the i18n, too. IMHO not nice.

2. What's the preferred way if you use several modules (your own) that 
are reused in other applications? Put '_' in the __builtins__ namespace,
use it in your modules and make one message catalog? Plus: fairly easy 
to do. Minus: you keep translating the same things over and over again, 
and you still need some armor in front of every module so you can import 
it, e.g., in the interactive interpreter. My armor looks like this:

def NullTranslation(x):
     return x
try:
     _("works when not standalone")
except NameError:
     import __builtins__
     __builtins__.__dict__['_'] = NullTranslation

Or create a message catalog for every module and setup the gettext 
machinery at the start of every module? Plus: modules must be translated 
only once, changes in a module do not require all your applications 
where it is used to be updated with new translations.
Minus: if your application is cross-platform, and you make it nice for 
Windows users with py2exe, you may get into trouble helping your modules 
find their message catalogs. At least I had severe problems doing it.

Quoting the Zen:

"There should be one-- and preferably only one --obvious way to do it."

I haven't found this way yet.

I'd like to know how others cope with these problems. Maybe I'm just 
missing the obviuos.

-- 
Hans-Joachim Widmaier