Wichert Akkerman wrote:
> Currently chameleon uses zope.i18n to do translation. zope.i18n is quite
> heavy and is much more complex than a lot of sites need, so I would like
> us to consider making zope.i18n optional.
> Is this a path that would be interesting? I doubt people using pylons or
> other non-zope environments want to buy into the complexity that
> zope.i18n brings..
zope.i18n provides three main features: translation, language
negotiation and locales (locale aware formatting).
The first is wrapping around Python gettext support. Note however that
gettext support in Python itself isn't updated for a long time and seems
to lack maintenance. GNU Gettext itself has progressed in various ways.
If you don't want to use zope.i18n's translate machinery anymore, we
should consider alternatives. Using the standard libraries gettext
support is a step backwards.
The second part is language negotiation. On the incoming data side this
is framework agnostic. The implementation depends on a specific request
object, though. I think almost all of this can be pushed into a WSGI
middleware layer, since it only operates on the request. From what I can
tell pushing this out into WSGI middleware in combination with the
specific negotiators from PloneLanguageTool would be a good option. The
negotiated language than becomes a value in the request, which can be
picked up by any translation machinery.
The third part is locale aware formatting. The zope.i18n implementation
is based on the ICU data set, but hasn't been updated in a long time.
There are two other more well-maintained Python API's on top of the same
data set, which seem like better contenders.
So you get a gentle +0.5 from me on the direction ;)
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at