> The second is pretty exciting as well. I saw a presentation in Paris by > Juan David Palomar, of Localizer fame. (The presentation is now up at > http://estce.act.uji.es:9673/localizer). The presentation impressed me > on the need to get someone into the core of Zope that knows all these > details, but also convinced me that the Zope3 effort needs to anticipate > the needs of i18n and l10n.
> ZBabel and Localizer are good starts, but as jdavid says, both should be > thought of as non-core projects that start influencing the core > step-by-step. Hi! I fully agree that ZBabel and Localizer don't have to be core projects right now. But the core must be made fit for i18n to make sure that we don't have to patch things like the user folder implementation or the Help! button in the code. In Zopw 2.5, there still seem to be "hot spots" to fix with regard to i18n. The next step would be to agree on ONE syntax for use in Python, ZPT, and DTML (not necessarly the same for each, but not more than ONE way for each). So there can be two or more implementations of internationalization to choose from, but Product maintainers do not have to provide two or more sets of DTML/ZPT files. BTW, it is not too hard to make ZBabel accept Localizer-style tags (which I already implemented in a CVS branch) and vice versa. The remaining difference between ZBabel and Localizer is a rather political one: We, the ZBabel team, are for consequent "late binding" of translations. That means that we are against having multiple sets of properties for languages. There will only be one set of properties, e.g. in English, and then the BabelTower is used to translate them. This is for non-content things. For content, we prefer the generic approach of ZBabel objects, that actually is able to internationalize everything from images to CMF news (at least in theory). The concept could be extended to have real content negotiation support for Zope. I tried to outline that a bit in my comments at http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ExplicitNam espaceControlInURLs, which seems to be too hidden to be read. I envision a Zope server to be able to return a content object (e.g. an image) in a variety of supported formats and versions, just by setting the browser content negotiation settings right or choosing an appropriate URL. E.g., a browser that can display png images should get them where appropriate, and somebody who doesn't have MS Word installed should get a PDF version of a document instead, etc. etc. (same with language versions). Joachim _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )