> 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 )

Reply via email to