Re: [Xen-devel] Correct management of .po files for translation

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

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 ..
> 
> tools/python/xen/xm/messages/en/xen-xm.po
> 
> ..does not contain untranslated strings at all - it is instead full of 
> symbolic
> constants.
> 
>   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
you did.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel