On Wed, Jan 08, 2003 at 02:55:33PM +0100, Guillaume Lelarge wrote:
Selon Martin Quinson mquinson@ens-lyon.fr:
C'est, il me semble l'un des futurs défis de la traduction (francophone au moins. Les traducteurs arabes ont d'autres défis à relever) :
comment maintenir une traduction ?Entièrement d'accord.
C'est exactement pour cela que j'ai mis au point avec Denis Barbier l'outil po4a. Le principe est d'extraire les textes à traduire dans des fichiers po, comme on fait pour traduire des programmes.
A moins que je ne sois totalement à la masse, utiliser des fichiers .po revient à faire une traduction phrase par phrase. Ce qui fait qu'il est difficile de traduire le sens du document. Si je me trompe, dis-le moi...
Dans po4a, c'est paragraphe par paragraphe (mais c'est le module qui le détermine, cf plus loin).
L'interet, c'est que de cette facon, on limite au maximum le contact du traducteur avec le formattage du document. Il me semble que moins on demande de technicité au traducteur, plus on limite les risques d'erreurs.
Si on coupe en sections, le traducteur doit encore faire attention à bien mettre ses <p> et </p> comme il faut. Du moins en sgml, car dans une page man, c'est les .PP qu'il doit bien positionner (et les =head1 en pod, etc).
Si on coupe en paragraphe, il reste plus que les <b> et autres <i> (ou B<bla> I<bla> correspondant en pod ; le module man traduit les ".B bla" et ".I bla" du source en B<bla> et I<bla> pour le traducteur, pour lui faire un format de moins à maitriser ; tout ceci est documenté dans les pages man de chaque module). Alors c'est pas parfait, mais c'est le moins de technicité qu'on puisse faire sans couper les phrases en morceaux, ce qui est *mal*.
Un autre intérêt, c'est qu'en coupant le document en morceaux, on isole les parties les unes des autres, et ca permet de voir rapidement quels morceaux ont changé, et permettre de les mettre a jour tout aussi rapidement. Plus besoin de lire tout le document pour se rendre compte que le seul changement est un ajout de virgule. Certes, diff fait ca. Mais que faire quand une section est déplacée, et qu'une virgule y est ajoutée? ;)
Et la question qui revient tres souvent, c'est de savoir si un texte découpé en paragraphe reste compréhensible (et donc traduisible), ou si c'est mort. La réponse que j'aime bien faire, c'est que les docs de KDE sont traduites de cette facon depuis assez longtemps, et que comme par hasard, c'est les mieux traduites parmis la doc libre, il me semble. Une autre réponse, c'est que les chaines dans le fichier po sont dans le meme ordre que dans le document initial. Alors, pour avoir le contexte, il suffit de traduire le po dans l'ordre... Une derniere réponse est que c'est comme ca que font les traducteurs professionnels (bien que dans leur cas, le probleme de maintenance ne se pose quasi jamais).
Le but de po4a est de traduire un fichier (quelque soit son format grâce aux modules) en un ensemble de fichiers po.
Exact.
Ceux-ci sont éditables avec kBabel par exemple (http://i18n.kde.org/tools/kbabel/). Seulement sur leur copies d'écran, on voit bien que les traductions se font phrase par phrase ou paragraphe par paragraphe (voir http://i18n.kde.org/tools/kbabel/img/mainwindow1.png)... si c'est bien le cas, est-il possible d'indiquer le sous-ensemble (phrase, paragraphe, ou bien mieux à mon sens dans le cas d'un document docbook section).
C'est le module qui le détermine. Je peux te pondre un module sgml qui "traduit" section par section, mais à mon avis, ca n'a aucun interet, car tu perd tout l'avantage de l'approche. Principalement: - À la prochaine grosse mise à jour qui va fondre des sections les unes dans les autres, t'es mort.
- Les outils d'éditions de po (kbabel, le mode po d'emacs et gtranslator, principalement) ne sont pas vraiment destinés à traiter des gros bouts de textes à la fois.
- Et pis, couper en gros bout est contradictoire avec l'objectif de l'approche qui est de reperer rapidement les changements dans l'original. Quand un bout de l'original change, la traduction correspondante dans le po est marquée floue. Mais si le bout de texte en question fait 15 pages, t'es pas bien pour remarquer que le seul changement est une ptite virgule ajoutée ici.
Notons que kbabel permet d'obtenir le diff en question, si les fichiers po sont rangés dans une base cvs, il me semble. Mais je l'accorde, ca serait mieux si les outils gettext (ie, msgmerge) géraient ca directement.
L'autre intérêt de kBabel est d'avoir quelques stats sur l'état de l'avancé du projet (voir http://i18n.kde.org/tools/kbabel/img/previewKonq.png).
Oui, voir en continu l'état de la traduction (ce qui est fait, ce qu'il reste à faire, ce qu'il faut refaire car l'original a été modifié) est un gros avantage des approches basées sur les fichiers po (ca vient pas de kbabel, qui n'est qu'un éditeur, mais du format de fichier, en fait).
Si je me trompe, n'hésite pas à me le dire. Et en argumentant bien, je pourrais même finir par l'installer et l'utiliser :)
Contrairement à ce qu'on pourrait penser, le plus gros avantage n'est pas tant de simplifier la traduction en elle meme (il est tout a fait possible de traduire un document à la main), mais de rendre possible la maintenance de la traduction, ie faire evoluer la traduction quand l'original évolue.
Si on veut faire ca à la main, il faut faire des diffs sur l'original, et essayer de s'en sortir comme on peut. Y'a des fois ou ca va bien se passer (ie, si l'original ne change pas trop), mais y'a des fois ou c'est tout simplement mort (par exemple si l'original est completement restructuré, avec des chapitres qui changent de place, d'autres qui disparaissent, etc).
CVS est ton ami. Une solution autre po4a est de mettre en place un serveur CVS (par savannah de préférence, voire par sourceforge), d'y installer la version originale et la version traduite (donc deux dépôts). A la prochaine mise à jour, il suffit de faire un commit sur la version originale et on peut rapidement savoir ce qui a été modifié, savannah devant disposer d'un cgi pour cvs (en tout cas, sourceforge en dispose à coup sûr).
Bof. C'est ce qu'on fait pour les pages web debian, et c'est pas non plus mirobolant. Je pense que ca se passe bien pour les pages web car ce sont des documents de taille moyenne (quelques kilos), mais on le fait aussi pour les documents debian (basés sur sgml), et là, ca se passe nettement moins bien.
En général, à chaque refonte du document original, il se passe un an avant que la trad soit mise à jour, et ca demande un nouveau responsable qui refait parfois une retraduction quasi complete.
Perso, je trouve que c'est de l'artisanat, et que faire des choses comme ca à la main alors qu'on est sensé etre assez performants techniquement, ca fait pas riche.
Pour ce qui nous concerne ici, il faudrait faire un nouveau module po4a pour traiter les sources que vous avez dans les bash howto. Comme je sais pas quel est le format utilisé, je peux pas vous dire si ca va etre dur ou non.
Pour faire le pod et la doc des options de compil du noyau, ca a ete assez simple, car ces formats sont un peu simplistes. Pour faire les pages de manuel, j'ai pas mal galeré, car le format utilisé est un vrai langage de programmation (préhistorique et laxiste à souhait, en plus). Pour faire le sgml, je pense que j'ai trouvé comment faire, malgres le laxisme de la syntaxe, encore une fois.
Tiens-moi au courant que tu sera arrivé à intégrer un fichier docbook sgml et/ou xml.
Pour info, il existe déjà po-debiandoc de Denis, qui est en quelque sorte un module po4a pour gérer le sgml debiandoc. Mais il est mal intégré au reste de po4a, et demande une réécriture (qui est en cours, comme je le disais).
Y'a aussi poxml, qui est l'outil utilisé par les gens de KDE pour traduire le DocBook XML.
Le gros désavantage de poxml à mes yeux, c'est qu'il gère les listes comme un benêt. C'est a dire qu'il met toute la liste dans une seule chaine à traduire, ce qui fait de bien trop gros morceaux. Les deux autres coupent au niveau de l'item de liste, ce qui fait des morceaux bien plus digestes.
L'interet de po4a par rapport aux deux autres, c'est que ca rend possible/simplifie l'ajout de texte non traduit. Du style une partie « À propos de cette traduction ». C'est à mon avis le point le plus douteux de l'approche par fichier po pour la traduction de documentation, mais je pense que la solution de po4a est assez générique et utilisable.
Je vous laisse lire les pages de manuels qui viennent avec le programme pour voir comment on fait ;)
Bye, Mt.
PS: Merci. Grace à toi, j'ai écrit une belle FAQ pour po4a, à venir dans la prochaine version du programme. Reste plus qu'a la traduire en francais, maintenant. Ca serait le comble que la doc de po4a soit mal traduite ;)