[Freeipa-devel] python i18n options

Pavel Zuna pzuna at redhat.com
Fri Feb 4 15:09:02 UTC 2011


On 02/03/2011 05:13 PM, John Dennis wrote:
> On 02/03/2011 09:34 AM, Pavel Zuna wrote:
>> Python 2.6+ provides secure ways to encode and decode
>> literal types to/from strings.
>
> I'm not sure what you mean by this, could you elaborate please?

http://docs.python.org/library/ast.html#ast.literal_eval

We could use it to send data about the exception and have the client translate 
it for itself. However I decided to drop this idea, because it would require 
changes in a lot of places where we construct exceptions and that's just not 
worth it.

>
>> Summary:
>> ========
>> Unless we agree on a better way; I'm going to try the pygettext patch
>> and see
>> how usable it is. If it's not then I'll try the solution with merging
>> pygettext
>> and xgettext output. We also need to rethink the PublicError class and
>> it's
>> encoding/decoding in {JSON,XML}-RPC to have them translated on the
>> client.
>
> I think your proposal sounds fine if we expect the message catalog on
> the client to be in sync with the server. I'm not sure that's a good
> assumption. When they drift apart the effect will be that some messages
> appear localized and others won't. That will be a poor user experience.
> One way we could address this problem is by following the web model. The
> client sends their language preference in each request. When the server
> responds it performs the message translation prior to sending it back to
> the client. We're already doing this for the web UI, any reason not to
> follow the same model for other clients?

Yes, we're going to use the same model in the end. Already posted a patch on the 
list that does just that (71).

> I can't comment on the quality of the upstream pygettext patch, but one
> way to find out is to start using it :-)

That's exactly what I'm planning to do. :)

Pavel




More information about the Freeipa-devel mailing list