[Po4a-dev] Re: [Translation-i18n] Re: French translation of GNU software manuals

[Martin Quinson]

On Sat, Dec 07, 2002 at 08:28:10PM +0100, Arnaud Gomes-do-Vale wrote:
> address@hidden (Martin v. Löwis) writes:
>
> I don't think po files or similar
> mechanisms can easily be used for documentation.

I strongly disagree here. I claim that po files are very usefull to
translate documentation. There is at least two examples I am aware of:

- as someone else said in this thread, KDE use po files to translate the
  documentation. And the documentation of this project are the best
  translated ones. I think it's because of the use of gettext.
- Along with Denis Barbier, we are doing quite a lot of lobbying inside the
  Debian project to use po files everywere translation take place. We call
  this (sub)project po4a (po for anything). This is hosted in savanah, and
  our goal is to make scripts able to extract strings to translate from the
  document, let the translator handle the resulting po file, and put the
  translation back to document.
  For now, it is the main way to translate debconf templates (questions used
  by packages at installation time for configuration), it looks like that
  the trend for debiandoc (the sgml based format for debian specific
  documentation) is also to use po-debiandoc, even if it's mainly used by
  the french team for now. Finally, I have a bunch of scripts to do that for
  pod files (Perl documentation) and man pages. 
  These new scripts are quite unstable (read: need some more work to be
  fairly usable), but the idea is there, and they seem generic enough to be
  usable on any format (read: writing a new parser for texinfo or what ever
  seems pretty easy).
  
Imho, what is now needed is a separation of domains as Karl said (gcc-bin,
gcc-man, gcc-info,...) and some more work on po4a to stabilize it. Then,
po4a could be integrated into the TP-project to allow the robot to extract
the strings to be translated, send the po to translators, get the
translations back, and if it's terminated, send the translated documentation
to the maintainer for inclusion.

The unit of translation is the paragraph, which is quite usefull from
experience I have in it. Of course, you can't translate a paragraph ex
nihilo, but most po translation program show you the msgids around the one
you are currently using, which gives you the needed context. This approach
is not perfect (because of big fuzzied entries, see below), but is a very
big improvement to handle major original document reorganization. We have
quite a bunch of debian documentation which where translated per hand until
the english author decided of a major reorganization, with parts moved
around and such. In that case, translating per hand is such a pain that most
often, the translation stops. Using po4a, this is automated. ;)

Another big problem with this approach which was not discussed here is the
ability to add text which is not directly a translation. For example, the
translator wants to add its name in a "Translator" section after the
"Author" one, or may want to add a section "About this translation" at the
end of the introduction. This case is already handleled by some of the po4a
scripts, and I plan to integrate this in po4a modules lacking this feature.

To be prefectly honnest, I think that the KDE documentation is so good
because of the CVS mode. It gives you the ability to see the changes in the
msgid for fuzzy entries. It would be great to add the result of wdiff (in
comments) for fuzzied entries. In a perfect world, it would take place
inside msgupdate, but could be scripted around.

That being said, I need a week more to make the new scripts of po4a widely
usable. For now, focus on po-debiandoc and po-debconf, maintained by Denis,
and already usable. ;)

Thanks, Mt.

-- 
Each language has its purpose, however humble.  Each language expresses the
Yin and Yang of software.  Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
          -- The Tao of programming