Me, too interested in ZIP. Especially, the following point.
there are a *lot* of english string literals everywhere in the code right now, so internationalisation would involve at the very least adding one extra level of indirection everywhere those string literals are being used... but I think this could be really good in the long run.
I've tried translating various messages in code(modules & dtmls) into Korean for Zope 1.9.x using Zope & external methods(just search & replace strings and start the translated Zope) to change Zope's own codes. There seems no enourmous difficulty except there a lots of strings to translate. It (partially Koreanized one) works all right, at least seems so during my experimentation. However, Zope source base seems changing rapidly and I did not know how to automate applying the previous translation to the new version. One idea was that let Globals.py have a STRING class and let all the raw stiring refer to an instance of this class. ie. Hellow_str.en ="Hellow", Hellow_str.jp="Goniziwa", Hellow_str.kr ="An Nyoung" .... I suspect that this might not slow down ZOPE's response a lot but just enlarge memory requirement. Then each product (or directory) can have just one repository module for STRING objects and translating Zope into another language will be just search & replacing '_str.en' (default) with '_stri.xx' and modifying the repository module. Then, taking into Zope's capability, ZIP's work flow seems to be able to fully Web-based collaboration and mobilize those with less code based skills. Well ... this seems to be dependent tell which part of the source tree will remain longer or be change Just a newbie's thought to be overrided by gurus'. LEE Kwan Soo.