The right way to do i18n

Laszlo Zsolt Nagy gandalf at geochemsource.com
Wed Sep 7 17:24:11 CEST 2005


  Hello,

I wonder if there is a standard for making i18n in Python projects. I 
have several Python projects that are internationalized. I also have 
Python packages with i18n. But it is still not clean to me what is the 
recommended way to do it. Currently, I use a module called 
'localization.py' with this code:

from i18n_domain import DOMAIN
import gettext
t = gettext.translation(DOMAIN,'messages',languages=['hu'])
t.install()


But I believe this is not the best way to do it. Problem one: I cannot 
do unit testing and I cannot use pydoc/epydoc for my libraries. They all 
use the _() function but it is installed in the main program only. What 
I do now is this:

import pydoc
import sys
import __builtin__
import os
sys.argv.append('-g')
def _(s):
    return str(s)
__builtin__._ = _

pydoc.cli()

But this is very very ugly.

Another problem is with libraries. I have a common library 'LibFoo' and 
several projects 'Project1', 'Project2' etc. I would like to distribute 
my projects and my library as distinct Python (distutil) packages. Of 
course, I would like to include all messages (po, pot and mo files) with 
my distributions. Is there a standard way to do it? I mean, there are 
many packages out there and most of them need i18n. Also there are many 
projects and they also need i18n. But how these two come together? There 
should be a standard way to unify gettext messages from various 
libraries. I'm thinking about a general i18n protocol, where each 
package or module has a standard way to add its own messages to the whole.

   Les




More information about the Python-list mailing list