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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
