[xliff-tools] Another question on PO and XLIFF

[Asgeir Frimannsson]

Hi Rodolfo,

On Tue, 3 May 2005 23:24, Rodolfo M. Raya wrote:
> On Tue, 2005-05-03 at 22:45 +1000, Asgeir Frimannsson wrote:
>
> Hi,
>
> > > I see that you base everything on Gettext API. Isn't it too dangerous
> > > to assume that all files were originated in C programs?
> >
> > We're basing the guide on GNU Gettext - and the tools provided by GNU
> > Gettext. Not any 3rd party ad-hoc extraction tools out there (there are
> > plenty).  With the Gettext API I mean the one in use by gettext when
> > extracting from c, c++, php, sh, python and other formats the toolkit
> > supports.
>
> Why limit the scope of the guide?

Because software messages are the intent of the PO file format. The only 
reason PO is used for xml and such formats is good tool support. And instead 
of bloating the PO guide with all these issues (we should add a section 
describing this though), why not start working on the Docbook XML guide?

When that is said, it doesn't mean you shouldn't implement support for 
XML-converted PO files in your filter. I'm all for that, but I don't see a 
case for adding support for this in the repr. guide. 

The same goes for other formats with ad-hoc PO filters (like SVG, openoffice 
files and even XLIFF [yes, they exist]). We should have a section clarifying 
what we're targetting in the guide, but not investigate each and every filter 
used to produce PO files. 

> > > Some PO files are generated from XML documents. If at reverse
> > > conversion you add the sequence "\n" whenever you find a linefeed, the
> > > result will be a mess.
> >
> > PO files generated from XML documents are excluded - they are plain
> > simply evil.
>
> Unfortunately, many translation projects like Fedora --where I
> participate as translator-- include PO files generated from XML files. I
> still need to translate those PO files and I want to keep using my XLIFF
> editor for that.

As said, please implement support for these formats in your filters :) - And 
I'll do it for mine as well. Simply by ignoring newlines in TUs which doesn't 
have xml:space='preserve' :)

> > Let us keep to PO for Software Message catalogs in this discussion.
>
> Please don't do it. We are here to provide tools for translators
>
> Translators never generate the PO files, they simply download from a
> repository. So, if the file was generated from XML or whatever and a
> filter like yours is used, the result of the translation process will be
> terrible. The consequences will be against us: people will not convert
> from PO to XLIFF because the results will be bad.

If the PO file is generated from XML - the problem is higher up in the 'food 
chain', - What we want to achieve in the Fedora project, is to provide 
translators with XLIFF files, generated using PO filters for software 
messages, or Docbook filters for XML. It won't be of real benefit to the 
localisation process until we provide XLIFF files in the repository, as if we 
use PO files, we loose much of the additional information on back-conversion.

cheers,
asgeir