[PATCH] Support of PO files for translations

Jens Seidel jensseidel at users.sf.net
Thu Sep 18 14:20:18 CDT 2008

On Wed, Sep 17, 2008 at 09:09:41PM -0400, C. Michael Pilato wrote:
> Jens Seidel wrote:
> > Currently all translations are based on XML files. This has many
> > disadvantages:

> > Nearly all these disadvantages are solved by using PO files.
> Jens, what is the state of the art with respect to XML-to-PO file generation

There are no news, except that the errors in po4a I noticed got already fixed.
Except the three mails I sent to the list (including this one) I
contacted also the German and Russian team. The German team has
currently no interest in switching, this is OK for me. No reply yet from
the Russian team.

Again: There is no need that all teams switch. But once PO is supported
by the build system and documented (I can later provide some guide) it's
easier for translators, I think.

> (and back)?  It seems to me (and I admit ignorance on this topic) that there
> are two steps to moving from today's scenario to a more ideal one where
> translation teams need only upgrade PO files:
>    1. First, convert the existing XML into something "gettext-ized"  I
>       don't know what this looks like, but maybe its:
>          <sect1 ...>
>            <title>_(Version Control with Subversion)</title>
>            <para>_(This is a sentence.)
>            _(This is another sentence.)
>            _(And a third!)</para>
>          </sect1>

No, the English file doesn't need to be touched at all! The initial step
is just required for translations and is a little bit error prone
(requires manual work, but I can do it probably as well without knowing
the language). This step is important to reuse existing translations by
extracting untranslated-translated string pairs from XML into PO.

Without this step one starts a translation with status:
0 translated messages, 0 fuzzy translations, 4186 untranslated messages.

Nevertheless providing this POT (PO template) file (without existing
translations) can/should be considered as a service to new translators.
This reduces the need to specify the sync status of the translation, to
write individual scripts (as the Russian team did), ...

>       Or maybe you do whole paragraphs at a time:

Yep, this is the default po4a uses.

>        And then use PO-generation and maintenance tools, just like the
>        Subversion source code does.

Right. It would be simplified if
 1) the Makefile patch get's committed
 2) po4a is installed on the build server

If 2) is not possible it would also possible to commit generated XML
files and to not remove these files in the clean target. It's also
possible that a 3rd party (me?) just calls po4a on the PO file
from the repository and commits the generated XML files via cronjob.

This would fill the repository with generated files but that's not a big
problem (except people start editing these files).

>    2.  Secondly, you use automated tools to generate PO files from the
>        "gettext-ized" XML sources.
> Is this right?

Not to generate PO files, only to update these with new English strings.
Currently I assumed that the English source is ../en/, but
that's just an Makefile variable ... po4a scans a list of given files
(could even be version 1.4 *and* version 1.5 of the English book and replaces
English paragraphs by translated ones. The tag structure is not changed,
so less changes to get build errors :-)

Apart from this it is right.

> If so, then I'd like to know the options for that first step.  Is it a
> one-time operation that we'd perform and then the English authors would be
> working in gettext-ized XML from now on?  Or is it the kind of thing that,
> say, a nightly cron job could generate from the current English XML sources
> and commit nightly to the repository?

Yep, the second part is true. But it would also possible to manually
update the PO file, let's say every two weeks by just calling po-update
in each translation directory.

Try to read my mails again, I know it is boring but you can do it


More information about the svnbook-dev mailing list