[Dev] FYI: ICU and Python

[Brian Kirsch]

/I am still not 100% sold on gettext. A lot of Python / c projects do 
use the .po format but there are more advanced message formatter
out there including the ICU message resources based on properties files 
(Java approach). Need to think about this one a bit more. I
am sure there will be lots of different opinions with in the community 
and OSAF.

/Woops forgot to mention XLIFF as an additional alternative to gettext 
although there is still limited support currently in the
open source community.
/
/

Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org



Brian Kirsch wrote:

> Thanks for the info Phillip.
>
> I have been looking at the Zope ICU and will continue to evaluate it 
> more. It could be a good first step to get Chandler up and running
> on the internationalization front. I still feel in the long term that 
> wrapping the ICU will be a must for Chandler and would be a great 
> contribution to the Python community. But in the interest of path of 
> least resistance the zope.i18n* packages may be a good choice for now. 
> I will investigate more. Thanks for pointing out picu as you said it 
> should make a good reference for a wrap of the c / c++ ICU libraries.
>
> I am still not 100% sold on gettext. A lot of Python / c projects do 
> use the .po format but there are more advanced message formatter
> out there including the ICU message resources based on properties 
> files (Java approach). Need to think about this one a bit more. I
> am sure there will be lots of different opinions with in the community 
> and OSAF.
>
>
>
>
> Brian Kirsch - Email Framework Engineer
> Open Source Applications Foundation
> 543 Howard St. 5th Floor
> San Francisco, CA 94105
> (415) 946-3056
> http://www.osafoundation.org
>
>
>
> Phillip J. Eby wrote:
>
>> Per discussions the other day about Brian's internationalization 
>> proposal 
>> (http://wiki.osafoundation.org/bin/view/Chandler/ChandlerInternationalizationProposal), 
>> I did a little investigation into ICU implementations for Python.
>>
>> Zope 3 includes separately-distributable 'zope.i18n' and 
>> 'zope.i8n.locales' packages.  (They rely on a couple of other zope 
>> packages, one of which is already distributed with Chandler, so the 
>> footprint isn't too large.)
>>
>> These packages provide support for ICU locales, using the locale XML 
>> files from the ICU project.  This support includes locale-specific 
>> date, number, and currency formatting and parsing, as well as 
>> calendar, time zone, and language information, all using standard 
>> Python types, including the datetime types.  It does not, however, 
>> include collation support, or any other ICU features.
>>
>> zope.i18n also includes support for using gettext files, and for 
>> defining on-the-fly translatable message IDs.  It's not clear whether 
>> Chandler would need this if Brian's proposal is used, because much of 
>> the idea is to move translation to a different run phase.  However, 
>> under Brian's proposal a change in locale would force the system to 
>> search and re-translate all localized strings in the repository, or 
>> alternatively to re-load all parcels.  If that approach is taken then 
>> on-the-fly translations aren't needed, and we might as well use 
>> Python's built-in gettext support, perhaps with some enhancements for 
>> locale/language fallback.
>>
>> The interfaces for zope.i18n and zope.i18n.locales can be found at:
>>
>>     
>> http://svn.zope.org/Zope3/trunk/src/zope/i18n/interfaces/__init__.py?view=auto 
>>
>>     
>> http://svn.zope.org/Zope3/trunk/src/zope/i18n/interfaces/locales.py?view=auto 
>>
>>
>> While the ICU implementation here is far from complete, it has been 
>> around a while and used for some projects, so it has presumably 
>> already incorporated any important "lessons learned" for working with 
>> ICU locales in Python.  And of course there are lots of tests.  We 
>> would probably do well to actually try using some of it before 
>> embarking on any significant efforts to create a direct binding to 
>> the ICU libraries for Python, if for no other reason than that it's 
>> much easier to debug Python than C or C++, and it's much harder to 
>> make pure Python code crash your process.  :)
>>
>> The other Python ICU project I looked at was "picu", which can be 
>> found at:
>>
>>     http://cvs.sourceforge.net/viewcvs.py/python-codecs/picu/
>>
>> It is an actual binding to the C ICU library, primarily for 
>> supporting collation.  It hasn't been touched in years, however, so 
>> it's not clear that it would work with a current version of ICU.  
>> However, it could perhaps be a reasonable place to start when we need 
>> to implement collation support, and it's certainly a decent example 
>> of how to wrap ICU routines in C for Python, in the event we need 
>> additional services.
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
>