Bonjour,
Déjà, merci pour les infos... po4a m'intéresse de plus en plus.
Selon Martin Quinson Martin.Quinson@tuxfamily.org:
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.
OK.
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*.
La meilleure façon de comprendre tout ça est de tester po4a et poxml. Donc, je vais les essayer en transformant le RedHat HOWTO en .po. Ca me permettra de mieux comprendre le coup des paragraphes, qui n'est pas limpide pour moi actuellement.
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? ;)
Là dessus, entièrement d'accord... les virgules sont mortelles :) D'un autre côté, isoler les 'morceaux' du document peut être dangereux, on n'a plus d'idée globale du document.
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.
Le mieux, ou le plus? en meilleur français, tu parles de la qualité ou de la quantité?
[...] 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.
Je suis d'accord que si on cherche à diviser le document, c'est pour en faire les plus petites parties intelligibles. Le paragraphe, voire la sous-section, semble un bon compromis.
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.
Il faut vraiment que je regarde ça.
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).
Oui, en effet.
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.
Oui, d'où cette discussion :) Mais de toute façon, on peut utiliser CVS sur les .po au lieu des .(sg|x)ml .
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.
Oui, Gérard m'en a parlé hier, et je suis en train de lire le KDE Translation HOWTO, qui en parle lui aussi.
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.
Intéressant. Son gros avantage est qu'il est immédiatement disponible, contrairement à po4a si j'ai bien compris.
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 ;)
Oui, ne t'en fais pas. Je vais les scruter.
Merci encore pour toutes ces infos.
-- Guillaume.
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/