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

[Martin Quinson]

People, I'm on the two mailing lists involved in the CC, no need to add me a
third time ;)

On Wed, Dec 11, 2002 at 06:57:48PM +0100, Arnaud Gomes-do-Vale wrote:
> Karl Eichwalder <address@hidden> writes:
> 
> > The easiest solution would be to add this info to the original text,
> > too.  Maybe, it's even useful within the English text, if it isn't, oen
> > can put it into an ifdef'ed environment.  Using XML something like this
> > could work:
> > 
> >     <para only_for="fr">Text for fr.</para>
> > 
> > Using SGML one would go for marked sections:
> > 
> >     <![ %fr; [
> >     <para>Text for fr.</para>
> >     ]>
> > 
> > I'm pretty sure, texi has something similar to offer.
> 
> I don't know about texinfo itself, but at the worst I think it can be
> done in TeX. However, I am not sure it is as easy as with XML.
> 
> BTW, this could allow to store the translation in the same source
> file(s) as the original. In XML, this would be something along the
> lines of:
> 
> <section>
>  <title lang="en">My title</title>
>  <title lang="fr">Mon titre</title>
> 
>  <para>
>   <text lang="en">
>    My text.
>   </text>
>   <text lang="fr">
>    Mon texte.
>   </text>
>  </para>
> 
>  <para>
>   <text lang="en">
>    This is an untranslated paragraph.
>   </text>
>  </para>
> 
>  <para>
>   <text lang="fr">
>    Ce paragraphe est spécifique à la version française.
>   </text>
>  </para>
> 
> </section>
> 
> Probably not useful for long manuals (this would quickly become a
> nightmare, with conflicting patches if several translators work on
> several languages at the same time -- in this case, gettext is
> better), but it could be nice for shorter documents that don't change
> often.

If you go for that solution, your project is dead before being born. You'll
go into two major problems (plus the one you cited):
  - encoding problems. Your solution can work as long as you translate to
    european language, that can be feasible, but if it's translated to
    korean, russian and arab, you're dead.
    You could go for UTF, but AFAIK, editing tools are not mature enough wrt
    UTF.
    Moreover, such problems are hard to detect (ie, only korean speaking
    people can see that the encoding of korean is broken [because of the
    russian translator])
  - maintainance problems. Let's say you translate your document that way.
    How will you detect changes to the original, which need to be applied to
    the translations? diff isn't that usefull because:
      - it will show all changes, and not only the changes to original
      - in case of major reorganization, with sections moving around in the
        document, you're dead.

In fact, we tryied to work that way for debconf templates, did go into those
problems, and moved to a po-based solution since a few months.

The major drawback you said against po based solution is the difficulty to
add a paragraph to the translation which is not the translation of an
existing stuff, but an original, specific to this language one. In the po4a
framework, it is done by using other files (called addendums). For example,
if you want to add a section "About this translation", you make a new file
for that. The first line is a header stating where this text should take
place in the produced document, and the rest is added verbatim a the
position determined by the header.

That's a bit overkill if you want to add a lot of addendums here and there
in the document, but i really think that if you do so, you're not
translating the document anymore, but you're adapting the document. I claim
that it's a bad idea. If the document can be improved with some paragraphs
added here and there, that's not specific to your language, and should be
repported upstream as a bug.

> > I think, communication with the original author isn't that bad.
> > Getting work done, is important, but human understanding is even more
> > important.
> 
> Yes. It is just not necessarily practical. I mean, keeping in touch
> with the author, sending him feedback and keeping him informed of your
> changes is important, but I think a translator should not have to
> bother the author just to "please add this magic comment stuff here".

In po4a, you have two options: 
 - let the original author deal with your translation (prefered)
   In that case, you give him the po file resulting of your translation, as
   long as all addendums files you need.
   
 - deal yourself with translation (not a good option, because other
   contributor won't get your source files),
   In that case, you do the work for producing the translation from po and
   addendum files, and give only the resulting file.

> > BTW, I don't think one way to handle the translation business does not
> > mean we have to handle all the other translations the same way.  We must
> > not forget to work out a scheme to provide updated manuals reliably; if
> > it isn't possible to update the docs, the whole project will suffer a
> > lot.
> > 
> > I think it's also reasonable to translate a document intially straight
> > away.  But than we need a so called alignment tool that's able to
> > combine original and translation paragraph by paragraph and turn the
> > result into a .po file like structure.
> 
> Yes, that would be a good tool. Quite difficult to do, I think,
> precisely because paragraphs can be added (or in some cases removed)
> in the translation.

No, that's not. It exists. It's called po4a. ;)
Ok, po4a is still beta, but it's really what you're looking for.


Elsewhere, Karl said that it would be better to go for a texi<->xml
conversion that for a texi<->po one, because the texi format was quite lax,
and doing such a conversion seemed impossible. My question is why would it
be impossible to do a texi<->po conversion when a texi<->xml one is
possible? po4a is written in perl, so is texi2html. Why couldn't I borrow
this code?


I would say that po-based solution are a bit technically hard to use,
because of addendums, for example, but nobody ever showed me a better
solution when it comes about maintainance of the translation.


My feeling is that the perfect environment wrt documentation translation is
kbabel (or gtranslator), with direct use of po4a. Ie, you open kbabel on a
man page, it uses automagically po4a to extract the translatable strings,
let you translate them, use po4a again to put your work into the man page,
and show you the result in another window.

That way, you'll approach professional translators plateform, with an
unified interface able to translate any document by parsing it underneath,
you'll benefit of all neat features of kbabel (like compendiums and
kdedict), and you'll be able to *maintain* the translations.


Thanks for reading 'till the end, Mt.

-- 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
          --- Isaac Asimov