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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to