Re: [brlcad-devel] Traducción al español de los docbook

[Gabriel M. B. <ga...@te...>]

Hi Sean,

On Fri, 11 Dec 2009, Christopher Sean Morrison wrote:

> (Thanks!)  This has also sparked the need to sort out 
> multilingual Docbook processing, obviously, but a very 
> welcome addition and a great contribution!

I recently tackled this issue with Hydrogen[1]. The long 
story short:  using DocBook 4.x XML with poxml from the KDE 
4 SDK[2] works well... especially if you don't /already/ 
have a bunch of translations of your manual.

Taking a step back, several strategies for doing this 
kind of translation.  Of the free/open-source solutions, 
there are:

   + Making a copy and translating it.
     PROS: works, gets it done fast, translators are at
     liberty to alter stuff as needed, everything is
     done in DocBook (SGML or XML, your pick).
     CONS: very difficult to update, translators are at
     liberty to alter stuff as needed.

   + Using some specialized and limited in-house
     markup that's easy to diff or use lookup strings
     with.
     PROS: puts you in control of your tool-chain.
     CONS: you have to build the tool-chain.

   + Using DocBook XML and converting to to XLIFF[1]
     for translation.  Translators edit the XLIFF files.
     The XLIFF files are then merged back to generate a
     translation.
     PROS: Fully XML tool-chain, ability to do incremental
     updates.
     CONS: Limited choice of free XLIFF editors[4], even
     fewer free XLIFF processors, it's difficult (but
     possible) for non-*nix folks to get a reliable XML
     tool-chain together.

   + Using DocBook XML and converting to PO files[5]
     using POXML.  Translators edit the PO files.  The
     PO files are merged with the original document to
     create the output documents.
     PROS: PO-files are well known to translators, there
     are lots of free PO-file editors out there, PO files
     are part of GNU gettext, ability to do incremental
     updates.[8]
     CONS: The KDE3 version of POXML is buggy, it's
     difficult for non-*nix folks to get a reliable XML
     tool-chain together -- especially one involving KDE.

   + Adding ITS markup[6][7] to DocBook and using that for
     processing.  (Note that I've never fully explored
     this, and I don't know of any free tools for processing
     it.)

For Hydrogen, we chose the POXML route.  With the advent of 
KDE 4, I'm now very comfortable with it.

I hope this helps!

Sincerely,
Gabriel

[1] http://www.hydrogen-music.org
[2] http://www.kde.org, note that I encountered a lot
     of bugs with the KDE 3 version of poxml.
[3] http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html
[4] For example, the Qt Translation Assistant can
     read and write XLIFF files, but they totally rearrange
     the XLIFF file, which makes it difficult or impossible
     to merge with the original document in some cases.
[5] PO files come from GNU gettext.
[6] http://www.w3.org/TR/its/
[7] http://www.w3.org/TR/xml-i18n-bp/
[8] The KDE3 version of POXML had a pretty nice feature to
     do incremental updates.  It could even compare two docs
     and generate the PO files.  However, it was pretty
     unreliable, and that's probably why it was scrapped in
     KDE4.  However, many CAT tools (like KBabel) can use an
     old PO file as a database when updating a translation.