translation handling

[Wichert Akkerman]

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.

From what I can see chameleon only uses a few things from zope.i18n:
translate, interpolate and Message. Message is only used to set some
default values and easily be made optional. translate appears to be
easily mappable to stock python gettext calls. That leaves interpolate,
which is needed to handle i18n:name constructs in templates. interpolate
is a small function that could easily be copied into chameleon, or
possibly even be replaced with standard python string formatting with a
bit more work.

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

Wichert.
--
Wichert Akkerman<***@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "z3c.pt" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to z3c_pt+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en
-~----------~----~----~----~------~----~------~--~---

[Paul Everitt]

I think this idea has a lot of merit.

--Paul

Post by Wichert Akkerman
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.
translate, interpolate and Message. Message is only used to set some
default values and easily be made optional. translate appears to be
easily mappable to stock python gettext calls. That leaves
interpolate,
which is needed to handle i18n:name constructs in templates.
interpolate
is a small function that could easily be copied into chameleon, or
possibly even be replaced with standard python string formatting with a
bit more work.
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..
Wichert.
--
http://www.wiggy.net/ It is hard to make things simple.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "z3c.pt" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to z3c_pt+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en
-~----------~----~----~----~------~----~------~--~---

[Malthe Borch]

Post by Paul Everitt
I think this idea has a lot of merit.

Yes, I think so too, however I don't have an overview of the necessary changes.

\malthe

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "z3c.pt" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to z3c_pt+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en
-~----------~----~----~----~------~----~------~--~---

[Wichert Akkerman]

Post by Malthe Borch

Post by Paul Everitt
I think this idea has a lot of merit.

Yes, I think so too, however I don't have an overview of the necessary changes.

I'll see if I can prototype something. I created a very minimal pylons
app that used chameleon as a demo for others at
http://code.simplon.biz/git/pyleon.git/ . I'll see if I can make that do
i18n as well.

Wichert.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "z3c.pt" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to z3c_pt+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en
-~----------~----~----~----~------~----~------~--~---

[Hanno Schlichting]

Post by Wichert Akkerman
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 ;)

Hanno


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "z3c.pt" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to z3c_pt+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en
-~----------~----~----~----~------~----~------~--~---

[Wichert Akkerman]

Post by Hanno Schlichting
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.

Post by Hanno Schlichting
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
something else.

Wichert.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "z3c.pt" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to z3c_pt+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en
-~----------~----~----~----~------~----~------~--~---