hi! there are a couple of details that make zope a little bit inconvenient when using it outside the US. for example: <!--#var money thousands_commas fmt=dollars-and-cents--> will output: $10,000.00 if you want to develop software for non-angloamerican countries and want to output monetary values you usually want something like this: fl 10.000,00 (Dutch guilders) DM 10.000,00 (Deutsche Mark) 10.000,00 F (French francs) L. 10.000,00 (Italian Lira) please mind the different use of "," to seperate decimals and "." to seperate thousands and the currency symbols before or after the money value. this is how most continental european countries format money values. in addition, the available output formats for the DateTime object (aCommon, fCommon, etc.) are not suitable for use in continental europe. for example, in germany i would like to have a format to output a date like this: "22. Juni 1999" or "22. 06. 1999". writing zope products that behave according to these local conventions is quite difficult. on the other hand, i think making zope aware of the locale system that is available on most unix systems shouldn't be this hard. therefore, i'd like to suggest the creating of ZIP - the ZOPE INTERNATIONALIZATION PROJECT instead of asking DC to implement the features mentioned above a couple of volunteers could develop some more output methods for the DateTime object and expand the money output methods to behave more internationally. strictly keeping the new version compatible with the old one of course. later, these code contributions might be merged with the official zope if DC approved the changes. i already have a couple of ideas but i'm still looking for a couple of people (preferably from different european countries) to discuss and implement these i18n functions. suggestions? comments? volunteers? thilo
Thilo Mezger wrote: [snip internationalisation problems with money and time] I'd like to add translation to this; it'd be nice if there was a facility in Zope to get the same text in multiple languages in a consistent way. I imagine using acquisition could be of service here. For instance: http://localhost/foo Displays 'foo' in the default language. http://localhost/English/foo Tries to display 'foo' in English, if possible, otherwise displays 'sorry, can't translate'. http://localhost/Nederlands/foo Tries to display 'foo' in Dutch, if possible, otherwise displays 'sorry, kan niet vertalen'. Is this feasible? You'd need some consistent way to store HTML in more than a single language; perhaps a MultiLingualDTMLDocument, or something like that?
therefore, i'd like to suggest the creating of ZIP - the
ZOPE INTERNATIONALIZATION PROJECT
Cool! :) I'm interested, though I don't know how much input I can give given lack of time. I'll join any mailing list on this that's opened, though. Regards, Martijn
I'm interested a lot in this topic too - I think that if we could agree on a feasible and sensible approach, then a lot of the infrastructure could be shared and reused for any language that anyone cared to provide support for... maybe a way of tie-ing mapping dictionaries to arbitrary objects, and then some conventions for naming the various messages... if we decided on the right implementation then automatic content negotiation could be easy to implement, too! (I am personally interested in Japanese...) A combination of server settings (environment variables, maybe a Control Panel widget or Locale object) and the desired HTTP_ACCEPT_CHARSET could be used to decide what language to use. I'm not sure what the cleanest way to do this would be... 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. Anyways, I'm pretty interested in the ZIP too, if it starts up! --Brian Martijn Faassen <faassen@vet.uu.nl> wrote:
Thilo Mezger wrote: [snip internationalisation problems with money and time]
I'd like to add translation to this; it'd be nice if there was a facility in Zope to get the same text in multiple languages in a consistent way. I imagine using acquisition could be of service here. For instance:
Displays 'foo' in the default language.
Tries to display 'foo' in English, if possible, otherwise displays 'sorry, can't translate'.
http://localhost/Nederlands/foo
Tries to display 'foo' in Dutch, if possible, otherwise displays 'sorry, kan niet vertalen'.
Is this feasible? You'd need some consistent way to store HTML in more than a single language; perhaps a MultiLingualDTMLDocument, or something like that?
therefore, i'd like to suggest the creating of ZIP - the
ZOPE INTERNATIONALIZATION PROJECT
Cool! :) I'm interested, though I don't know how much input I can give given lack of time. I'll join any mailing list on this that's opened, though.
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev
(For non-developer, user-level issues, use the companion list, zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
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.
Martijn Faassen wrote:
Thilo Mezger wrote: [snip internationalisation problems with money and time]
I'd like to add translation to this; it'd be nice if there was a facility in Zope to get the same text in multiple languages in a consistent way. I imagine using acquisition could be of service here. For instance:
Displays 'foo' in the default language.
Tries to display 'foo' in English, if possible, otherwise displays 'sorry, can't translate'.
http://localhost/Nederlands/foo
Tries to display 'foo' in Dutch, if possible, otherwise displays 'sorry, kan niet vertalen'.
Is this feasible? You'd need some consistent way to store HTML in more than a single language; perhaps a MultiLingualDTMLDocument, or something like that?
This topic was touched on about five months ago in the following thread: http://www.zope.org/pipermail/zope/1999-January/001132.html http://www.zope.org/pipermail/zope/1999-January/001133.html http://www.zope.org/pipermail/zope/1999-January/001174.html In general though, the consensus was that the issues of multiply rooted hierarchies, multidimensional content arrays, symbolic links, and explicit acquisition pointers are all interrelated and should be generalized beyond the issue of different language versions. As I understand it, more basic architectural issues need to be dealt with before DC can even think about this problem-space. I for one do not have the programming skill to implement this sort of thing, though I can articulate what I'm looking for. I do know that there is no fundamental reason that ZODB cannot support other structures such as circular references or bi-directional links, but that the Zope interface is pretty tightly wedded to the singly rooted hierarchy. Currently, two products partially address this problem space: The symbolic link patch (http://www.zope.org/Download/Contrib/Pointer.tar.gz) and ZTables, which will apparently provide some facilities for mapping tabular data to multiple hierarchical views. 01 (my two bits), Michael Bernstein.
participants (5)
-
Brian Hooper -
Martijn Faassen -
Michael Bernstein -
Thilo Mezger -
ÀÌ°ü¼ö