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
