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-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
