Prev: catching my own exception
Next: announcing jsonutil package
From: Hans-Joachim Widmaier on 18 Jun 2010 13:09
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
 | 
Pages: 1
Prev: catching my own exception
Next: announcing jsonutil package