On Fri, Jan 29, 2010 at 11:09 AM, Damien Baty <damien.b...@gmail.com> wrote:
> I must be missing something, here. Let's restrict the use case to
> template i18n. In my BFG app, I use Chameleon. And Chameleon is pretty
> tied up to "zope.i18n" (cf. "chameleon.core.i18n"), isn't it?

Ah right. Chameleon has a hard dependency on zope.i18n right now, I
forgot. Not working with BFG nor Chameleon in any projects doesn't
help to remember these things :)

> One way or
> another, I have to register an utility for ITranslationDomain. That is
> what "zope.babel" seems to do, using (a subset of) Babel message
> catalogs instead of "zope.i18n" ones (although I am not quite sure that
> they are very different). So "zope.babel" seems useful to me if I want
> to use Babel advanced features.

Well yes. I think Chameleon should not depend on zope.i18n in the
current way, but it should probably either depend on Babel directly or
get some pluggable i18n hooks. All it needs to do is template
translation of messages. Chameleon shouldn't need to know about
language negotiation, which is hard to avoid with zope.i18n.

For zope.babel the basic message translation stuff is quite similar to
the other ones. But even there we'd have differences with the way you
handle the default fallback for a message, which will show in some
API's. Babel supports proper msgctxt to do this, while zope.i18n
doesn't understand that feature and uses a custom format resulting in
invalid Gettext po files.

The harder stuff I haven't really tackled in zope.babel is all the
language negotiation and locale data support. In both of these cases
zope.i18n's current API is pretty broken. I've worked around all of
that on the Plone level for quite a while, but at some point that
should find its way down in the stack. zope.babel is the place to do
that for me.

Two pretty basic problems with zope.i18n are, that language
negotiation is the responsibility of each message catalog. It calls
into the negotiation machinery inside each "translate" call. That's
both horribly inefficient and doesn't make much sense. You will get a
different negotiation result for a page for each domain depending on
the po files available for each domain. The other one is that it does
negotiation only based on the request. But quite often you actually
want to influence the language result based on the context you are in.
And then the locale data exposed as some request.locale object has a
pretty bad API and the underlying data is incomplete and ancient.

Repoze-dev mailing list

Reply via email to