[Localization] Localization update

[Christopher Lenz]

Hi Samuel,

Am 22.06.2007 um 22:48 schrieb Samuel Klein:
> 2. Noah noted earlier that cmlenz has been working on a Babel  
> Python library for localization; Christopher, can you write a bit  
> on the olpc wiki about how to use this in coordination with the  
> other parts of our l10n process?
>    http://www.cmlenz.net/blog/2007/06/announcing_babe.html

sorry about my lack of responsiveness so far. My problem is that I  
don't have much of an idea of where OLPC stands in regards to L10,  
what your requirements are, etc. And I have unfortunately not found  
the time yet to read up on all this on the wiki. So I'm not sure my  
input in this area is helpful.

Babel is in relatively early stages, having just being announced.  
IMHO it certainly has the potential to become the definitive solution  
for I18n/L10n in Python (if you ignore zope.i18n and PyICU, which are  
of course viable options if the environment in question allows using  
them). But although many things are working nicely, we're not quite  
there yet, and some parts of the code need more work.

Whether Babel would be a good fit for Python software on OLPC depends  
on your requirements:

* For localization, do you really need more than the features Python  
includes, i.e. the POSIX-based "locale" module, the strftime/strptime  
functions, etc? Those parts simply call through to the operating  
systems locale database, and do an okay job most of the time. The  
primary focus of Babel is on web-based applications, where you can't  
use the "locale" module and the other builtin POSIX-based L10n  
functionality because it assumes there's only one locale per process  
at any one time.

* For message catalogs (i.e. gettext), the value-add by Babel is not  
in *using* translations catalogs (you just use the builtin "gettext"  
module for that, basically), but in creating and managing them. It  
provides pure Python replacements for the most commonly used parts of  
the gettext/uniforum toolchain (xgettext, msgfmt, msgmerge, etc), and  
also lets Python web template languages plug in to the process. The  
real value-add is the latter, actually. If you don't need to support  
template engines and the like, and the GNU gettext tools are  
available, you can just use those for the same catalog management tasks.

Babel certainly adds both convenience and sophistication to I18n/L10n  
even for Python-based client applications. But it does come at a  
cost: the disk footprint weighs in at almost 1MB (but that includes  
locale data for every language in the CLDR, which are a lot, and  
could be stripped down), and the locale data is loaded into memory  
for every locale used (I haven't actually measured memory usage, but  
based on the file sizes it should be around 50-100 KB). And of course  
all the number and date formatting is implemented in Python, and has  
not seen optimization beyond common-sense-based design choices.

I'd be happy to answer any questions on how Babel might fit in with  
the OLPC Python apps, but at this point I simply haven't been able to  
collection sufficient background information to give really useful  
advice.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/