Re: Doc Translations

[danilo gnome org (Danilo Åegan)]

Hi Pablo,

Today at 9:37, Pablo Saratxaga wrote:

> Kaixo!
>
> On Wed, Sep 08, 2004 at 11:50:12PM +0200, Danilo Åegan wrote:
>
>> xml2po is result of what I consider best practice for translations.
>>   xml2po C/planner-manual.xml > planner-manual.pot
>>   xml2po -p es.po -o es/planner-manual.xml C/planner-manual.xml
>
> It seems much easier to use than XML mode of intltools.

I certainly hope so, since this was designed especially for handling
translation of arbitrary XML documents which keep content in tag
content: basically, different designs, one more suitable than the
other.

> A question however; how are handled the useless formating of XML
> source?
>
> That is one of the bad things I've seen so far on XML<->po converters;
> when you add \n or spaces or tabs to the source XML, it changes
> the msgid on the po files, breaking the translations; while addign
> extra blank space to XML source has no change in meaning; imho the
> XML->po converter should simply ignore linebreaks and extra space
> (and then, when converting from po to XML, the text passed trough
> something like "par" to nicely format it for people liking to read XML
> directly...)

Spaces are stripped/unified depending on the context (DocBook mode has
some tags which don't strip spaces, and they're explicitely marked as
such; listing, and similar ones).  Default is to unify spaces so
messages are more translator-friendly (that's the merit of being a
translator when creating such software :-).

There's also automatic mode which is useful for those document types
which are not handled specially (-a option, instead of '-m docbook'
or something): it's a bit slower since it has to go down the DOM tree
to see if anything in this tag is suitable for translation, instead
of using pre-created tables.

>> Next time C/planner-manual.xml changes, you'd sync (gettextism is
>> "merge") your es.po first:
>> 
>>   xml2po -u es.po C/planner-manual.xml
>
> would there be a difference if merging with *.pot?

Well, no, but it may cause some problems.  I don't parse PO files
directly, but rather, I run "msgfmt -o .xml2po.mo <POFILE>", and use
Gettext functions from within Python to access .xml2po.mo messages.
With POT, this step would usually fail, since it contains
uninitialized fields (I'm not outputing a PO header at all, since I
expect PO tools to do that better than I would).

So, POT file would cause problems where it would otherwise cause
problems.

The bad thing with the way I'm doing merging is that if some things
are untranslated, you'd get mixed-up XML file: some <para>s
translated, others not, which is not a very nice sight.

There's another point where it may act weirdly: when merging
translations back, language used for the translation is deduced from
the filename passed to "-p" option, and that is set as <article
lang="...">. 

There's also a lot of room for improvements, but they will happen
once people start using it and tell me what they need added.

Cheers,
Danilo