OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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!


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

1. Store your source language (usually English) as modular DocBook


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.


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.


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.


To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]