[Freeipa-devel] python i18n options

[Pavel Zuna]

I've been playing around with localizing python strings for a while and this is 
what I figured out:

Currently we use xgettext to get strings to be translated from python files. 
 From withing python we call the gettext library wrapped in ipalib/text.py 
classes to provide on request translation. We need on request translation, so 
that we can translate strings on the client.

Apart from the classes in ipalib/text.py, there are also localization functions 
in ipalib/request.py. These function are old and deprecated. Despite this they 
are still used when translating exception messages. That's why exceptions aren't 
currently being localized. Rob posted a patch recently that fixes this, but it 
wasn't fixing the problem at its root. There's another patch by me (69: Remove 
deprecated i18n code...) that removes references to ipalib/request.py and 
replaces it with ipalib/text.py classes.

This patch should definitely be accepted. It doesn't change anything - it just 
removes code that shouldn't be there anyway.

There's another problem with exceptions. They are localized when they are first 
created on the server. When transmitting exceptions from server to client, the 
data is wrapped in a xmlrpclib.Fault class. This class can only contain an error 
code and string making it impossible to reconstruct on the client especially if 
it contains template strings (i.e. '%(reason)s').

I propose we change the way exceptions are created and encode information about 
them as Fault string data. We can then reconstruct them on the client a perform 
localization there. Python 2.6+ provides secure ways to encode and decode 
literal types to/from strings. This will require changes to the PublicError class.

Now there's the issue of localizing the built-in help system ('ipa help') which 
translates to localizing python docstrings. xgettext can't do that on its own. 
There's an alternative called pygettext. Unfortunately pygettext can't 
translated ngettext string (meaning strings that have a singular and plural 
form). I found two solutions around this:

1) a) use both xgettext and pygettext
    b) merge the resulting .po files
    c) use msguniq utility to get unique translatable strings

2) theres a patch for pygettext to handle ngettext string

Solution 1) will probably works fine, but it's not very effective. I would 
prefer the second solution, but I still have to determine how good the patch is 
since it was sent by some random guy on the python mailing list.

Links:
http://bugs.python.org/issue8502
http://bugs.python.org/file17639/pygettext.py.patch

Opinions?

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.

Pavel