Re: Looking for informations

[Larry Kollar]

Ingo Schwarze <address@hidden> wrote:

> Writing good documentation requires good understanding of the source
> code of the program.  While writers documenting free software often
> have that, translators almost never have it.  Translated documentation
> is almost always of much lower quality than the real thing and
> usually also outdated on top of that.

In the Free software domain, where nearly everything is volunteer-driven,
this could well be true. It’s less true in commercial environments, mainly
because corporations have the $$$ to throw at professional translation
software and bureaus. I’ve had to drive my share of translation projects in
the past (and I’m glad to not be doing it now)—there’s a considerable
amount of prep work that needs to be done, at least the first time you have
it translated. Brand names, API names, system output (if not localized),
*roff markup, all has to be flagged as “leave this alone."

Technical translations are often done by people who 1) are native speakers
of the target language; 2) have a technical background. Someone translating
an API manual might never see the source code, but could well have been a
programmer at one time. In an open-source project that’s serious about their
documentation (and localized versions), there would need to be a L18N
(localization) czar who would coordinate not only translators, but reviewers
who could read the localized output and go “wait, what?"


> For a program used by a relatively small and technical community
> like groff it makes even less sense than for software used by vast
> crowds of unskilled people.

Coincidentally, at work we always translate end-user guides, but rarely the
more technical docs (but it does happen, if the product managers are willing
to pay what it takes). 

Translating manpages should be do-able in the context of a semi-popular
project, and man(1) can display manpages for specific languages by
specifying the country code in the LANG environment variable. For updates,
translators could use diff(1) to isolate changes in the source (usually EN-US)
document and focus on those instead of re-translating the entire thing from
scratch. But you would still need to depend on readers to catch stuff that, uh,
gets lost in translation. :-P

        Larry