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.
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
