[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Correct management of .po files for translation
On Wed, Apr 04, 2007 at 05:02:23PM +0100, Daniel P. Berrange wrote:
> In updating Fedora rawhide to work against xen-unstable.hg (3.0.5) I noticed
> that there is now gettext support for translating the error messages returned
> from XenAPI in xm. Unfortauntely the way the .po files have been created is
> completely wrong & useless for translators to work kwith.
> First there is no master .pot file - merely an english 'translation'. Since
> the convention is for the untranslated strings to be in english to start with,
> providing an english .po file is redundant unless you specialize it to a
> variant like en_GB.po
> The core problem though is that the catalog file ..
> ..does not contain untranslated strings at all - it is instead full of
> msgid "INTERNAL_ERROR"
> msgstr "Internal error: %(1)s."
> msgid "MAP_DUPLICATE_KEY"
> msgstr "This map already contains %(1)s -> %(2)s."
> msgid "MESSAGE_METHOD_UNKNOWN"
> msgstr "The method %(1)s is unsupported."
> msgid "MESSAGE_PARAMETER_COUNT_MISMATCH"
> msgstr "The method %(1)s takes %(2)s argument(s) (%(3)s given)."
> There are two critical reasons why msgid should always contain the master
> english untranslated string:
> - Translators need to be able to compare the original english alongside
> the translated text to ensure accurate translations. Referring to external
> files to find the english is not practical
> - The msgmerge tool used to periodically update the catelogs looks at
> the msgid entries to identify added / removed / editted strings. If
> the msgid is a symbolic constant it'll never be able to identify strings
> which have changed & thus mark them as needing re-translation
> Basically the code is abusing the gettext translation service to do both the
> constant -> string conversion & the translation in one go. The normal way to
> do the constant -> string conversion is to have a statically declared hash
> table in the application itself. This contains the master english strings
> annotated with N_(...string..). The xgettext program will then generate
> the .pot files automatically in the correct format.
> I'm attaching an example to show how this ought to work in the Xen case.
> The makefiles could be hooked up to automatically run
> xgettext --keyword=N_ -o xen-xm.pot tools/python/xen/xm/XenAPI.py
Sounds good to me, Daniel, thanks. Could you write a patch to hook up the
Makefiles as well? I reckon we'll be able to sneak this one in for 3.0.5 if
Xen-devel mailing list