[Localization] [Translate-devel] Translating the manuals?

[Helge Kreutzmann]

Hello Clytie,
thanks for your very interesting and long e-mail. Having translated the
Debian web page and several man and help pages for a while, I agree
that is indeed different.

If you have long paragraphs then looking for diffs (even with previous
above) is very tedious (probably some tool could highlight the
difference which would make it easier, but still I routinely encounter
paragraphs which do not fit the screen, much less with previous). 

Also in (long) texts content might be split up differently in
different languages, e.g. when lists or examples are embedded in
paragraphs. Also "missing" content (i.e. when strings are reused from
other parts) can be confusing.

Still, the po based workflow is nice, especially since it requires no
changes from programm translations and when content is shifted within
documents (e.g. in relase announcements) then it really safes work.

On the other hand, having a VCS as backend and doing diffs also has
its advantages. If, e.g., some sentence is updated within a huge
paragraph, you can really nicely spot the difference and update the
translation quickly. You always have the full context. And "5 lines
difference" is a lower barrier than 5 paragraphs difference, where you
initially do not know if the entire paragraph was updated or only a
word exchanged.

The downside for VCS/diff based translations is, of course, that it is
highly specific to the project at hand. 

Regarding XLIFF I've no experience, so I cannot comment.

And I would definitly concentrate on more stable and more valuable
parts during translation. So translating an introductory document[0], which
requires only minor/seldom changes (if any) when the project/software
evolves, is much more sensible than working on highly dynamic wiki
pages[1]. And translating News really needs dedication: If it is done
carefully, then it might take so much time that is no longer news, but if 
it is done quickly everybody will point fingers (because news are frequently
read/discussed).

And as already mentioned translating documentation involves much more
proofreading. The program strings are seen by the developer(s) every
day, but the documentation is (IMHO) often written once and only
updated when there is a necessity, but I doubt that the
developer(s)/authors read them much afterwards. So the German team
routinely sets up patches for the original while translating. So a
"back channel" to the original document authors is required. 

I personally would prefer if there could be two ways to translate: A
"direct" approach, using a VCS, where I can get accustomed to the
developers/document authors and interact directly with them (e.g.
apply fixes, track documentation updates before releases, ...) and a
general, e.g. po4a based version, where "drive by translators" can
discover and work on the project. Before releasing, these translations
(which e.g. in the po4a case do not need changes in the original)
could be pulled in, built (the intermediate po files thrown away) and
shipped.[2]

This would allow me to first help a project as a one or two shot
effort and when I see my translation applied, my fixes taken and
feedback coming in I could join the group, pull the VCS and work more
closely. If not, well, then someone else could take over.

Hope my 2 cents help.

Greetings

           Helge

[0] Also this document might give the user so much information that he
    then can use the software/join the project even if some bits are
    still untranslated. Without it, he might have never
    tried/encountered the project/software.
[1] I firmly believe that wiki pages are out of scope of translation
    since the wiki concept is for frequent updates by a diverse group
    of people, so having consistency and stable versions is rather
    unlikely and the translation probably stays outdated almost all
    the time.
[2] This idea is not mine, I've recently read a developer who wondered
    if he would need the translation locally (in a VCS) at all. He
    simply would like an automatic exchange from his VCS to some
    central translation place, where during development the
    translators see the new strings/paragraphs and during release all
    translations available are being pulled. With po4a you could can
    arrange such that you only set it up once and then simply don't
    have to care if and how many translations are present (unless they
    break the build, of course).
-- 
      Dr. Helge Kreutzmann                     debian at helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.laptop.org/pipermail/localization/attachments/20100327/b000166b/attachment.pgp