On 12/5/08 10:05 AM, Hanno Schlichting wrote:
> 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.
My problem is that I can't rely on zope.i18n: I need to integrate with
pylons, formencode and others, none of which use zope.i18n but use
gettext. As long as the rest of the python world uses gettext and we
need to integrate with that there is little choice.
> 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.
In a WSGI environment the language should just be a field in environ.
Where that comes from should not matter at all - it couldl be from a
repoze.who metadata provider, a language negotiation middleware or
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