i18n questions

[Donn Ingle]

Hi,
A soon-to-be happy new year to everyone!

I'm 100% new to this i18n lark and my approach so far has been to create
a .mo file per module in my app.
My thinking was, why load one huge .mo file when a single module only needs
a few strings? Since then, it seems, I have made the wrong decision.

For example I have module A that imports module B. Each one does this:

gettext.install( domain, localedir, unicode = True )
lang = gettext.translation(domain, localedir, languages = [ loc ] )
lang.install(unicode = True )

(where doman is the name of the module, so "A" and "B")

The problem is that domain "A" loads and then import B happens and so
the "lang" reference (I think) gets replaced by domain "B" -- the result is
that module A can only translate strings that are in domain "B".

How does one 'merge' gettext.translations objects together? Or is that
insane?

What's the best way to handle a project with multiple domain.mo files?

I hope someone can give me some advice.

\d

 

[kyosohma]

Hi,
A soon-to-be happy new year to everyone!

I'm 100% new to this i18n lark and my approach so far has been to create
a .mo file per module in my app.
My thinking was, why load one huge .mo file when a single module only needs
a few strings? Since then, it seems, I have made the wrong decision.

For example I have module A that imports module B. Each one does this:

gettext.install( domain, localedir, unicode = True )
lang = gettext.translation(domain, localedir, languages = [ loc ] )
lang.install(unicode = True )

(where doman is the name of the module, so "A" and "B")

The problem is that domain "A" loads and then import B happens and so
the "lang" reference (I think) gets replaced by domain "B" -- the result is
that module A can only translate strings that are in domain "B".

How does one 'merge' gettext.translations objects together? Or is that
insane?

What's the best way to handle a project with multiple domain.mo files?

I hope someone can give me some advice.

\d

I've never messed with .mo files, but a little "googling" turned up
this interesting module on PyPI: http://cheeseshop.python.org/pypi?:action=search&term=polib

If you're messing with unicode in general, I've heard this is a good
article to read:
http://kevino.theolliviers.com/python-unicode.html

This article looks related, although the author is using .po instead
of .mo files:
http://www.learningpython.com/2006/12/03/translating-your-pythonpygtk-application/

Finally, I found a wxPython specific one that looks like it might be
general enough for you:
http://wiki.wxpython.org/Internationalization

I hope that gives you some ideas anyway.

Mike

 

[Donn Ingle]

Thanks for taking the time to post those links. I have read most of them
before. They don't seem to cover the basic issue in my OP, but i18n on
Python is a dark art and maybe there's something I missed.

\d

 

[Thorsten Kampe]

* Donn Ingle (Fri, 28 Dec 2007 20:01:48 +0200)

I'm 100% new to this i18n lark and my approach so far has been to create
a .mo file per module in my app.
My thinking was, why load one huge .mo file when a single module only needs
a few strings? Since then, it seems, I have made the wrong decision.

For example I have module A that imports module B. Each one does this:

gettext.install( domain, localedir, unicode = True )
lang = gettext.translation(domain, localedir, languages = [ loc ] )
lang.install(unicode = True )

(where doman is the name of the module, so "A" and "B")

The problem is that domain "A" loads and then import B happens and so
the "lang" reference (I think) gets replaced by domain "B" -- the result is
that module A can only translate strings that are in domain "B".

How does one 'merge' gettext.translations objects together? Or is that
insane?

What's the best way to handle a project with multiple domain.mo files?

I can give you just general advice how I dealt with
internationalization in my example app. "scipt" is the main app with
its own mo file and imports optparse which has again its own mo file

#
gettext.textdomain('optparse')
gettext.install('script', unicode = True)

from optparse import OptionParser, \
OptionGroup
# [...]


Thorsten

 

[Donn Ingle]

gettext.textdomain('optparse')
gettext.install('script', unicode = True)

They speak of a 'global' domain in the docs, but (as is my usual beef with
the Python docs -- see PHP docs for sterling help) there is no clarity.

It *sounds* like there can be a .mo file for *everything* and then one can
also install others on a per-script/module basis, as your code seems to
suggest.

All very confusing.

I have had an entire day to stew and I spent it combining all my po files
into one big file. Now I install that once, and efficiency be damned.

Still, I'm interested in what's possible and I'll give your approach a
whirl.

Don't let the thread die yet, c'mon you i18n boffins!

Thanks,
\d