The right way to do i18n

  • Thread starter Laszlo Zsolt Nagy
  • Start date
L

Laszlo Zsolt Nagy

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,021
Latest member
AkilahJaim

Latest Threads

Top