Re: [docbook-apps] Multilanguage DocBook documents - best practices needed

[Robert Fekete <frobert@balabit.com>]

Hello Everyone,

Thank you very much for your help and useful advice.

We have decided to give the following approach a try (hope to do a 
proof-of-concept in a few weeks):

- we will have the docbook xml files translated
- we will store the original and the translated xmls in separate directories for 
each language
- every book will have a top-level xml file in each language, consisting 
practically only the <book> tag and xincludes for the content (using relative 
paths, so the xincludes can be the same for every language):
- every xml will be stored in a single VCS repository (we are using git). I was 
tempted to use a separate branch for each language, but most of the screenshots 
will be the same for every language, so storing everything in a single branch is 
less painful
- localized images will be stored in the subdirectory for each language

I was thinking about translating the profiled xml files instead of the source 
xml-s, but the translated profiled xmls would require some postprocessing 
(correcting paths, and so on), which is feasible, but I am reluctant to do.

When I have the full process working, I will give you an update.

Thanks again!

Robert


On 07/23/2012 07:12 PM, honyk wrote:

> > > 1. Store your source language (usually English) as modular DocBook
> > > documents.
>
> +1:
>
> All our stuff to be localized is stored this way (in SVN). Almost every chapter is a separate file xincluded into the main file.
>
> > > 2. Prior sending document for translation assemble it into one
> > > large file.
>
> > As part of the preprocessing also:
> >
> > * Profile to remove any internal content,<remark>s, and comments that
> > won't be in the output and might confuse the issue.
> > * Normalize the line breaks so you have one line for each block
> > element (e.g. para, title, etc). That way the translation memory tools
> > won't be confused if the line wrapping changes between releases.
> > * If processing it into a single file results in a very large file,
> > consider chunking back into one file per chapter.
>
> -1:
>
> We do not pre-process our stuff in any way. We send the bunch of XML files together with the PDF output and get the same XML stuff in a different language. (The lang attribute is set only on the root element of the main file).
>
> This localized content is stored in SVN. Any outputs are generated from this modular source.
>
> > > 3. Use agency which has very good translation software with
> > > translation memory
> >
> > Require that they provide the TM as a deliverable so that you can use
> > it next time even if you select a different vendor.
> >
> > Get bids from more than one vendor and compare them carefully. There
> > are many aspects which can affect the price.
>
> +1
>
> An agency with the reliable CAT tool is a must. And as mentioned, an access to their TM is strongly recommended as it eases switching to the different vendor.
>
>
> There is one related issue connected with translations: GUI images.
> The size of elements in desktop or web apps intended for localization should depend on the text content. We try to avoid highlighting as it would have to be recreated in every particular language.
>
>
> Jan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org