Le 2003-01-02 16:58:14 +0100, Marc Chantreux écrivait : Je viens de revérifier : le guide est effectivement disponible. Apparemment, son ancien auteur avait laissé tomber le projet.
Bonne nouvelle : une personne de la liste shellscript-fr@debianworld.org s'interesse lui aussi a la traduction de l'ABS. nous sommes donc deux sur la liste des volontaires potentiels. C'est un peu faible et j'espere que d'autres suivront.
Le mieux serait sans doute que tu envoies un message à la liste traduc@traduc.org pour trouver d'autres volontaires.
L'abonnement a la liste, c'est fait ...
La dernière version de ce document est la version 1.7 disponible sur le site de l'auteur :
http404
Pourras-tu me confirmer si tu te lance dans cette traduction, et dans quel délai tu penses pouvoir terminer ?
arghh ... le fait que je me lance dans cette traduction n'est pas du tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Le travail est facilement divisible : il existe de nombreux .sh dont les commentaires doivent etre traduits. Le SGML principal n'a pas l'air violent et qq macros vim rendent l'edition tres simple et rapide.
Je n'ai traduit de la doc. de facon tout a fait occasionnelle et je ne suis donc pas l'homme qu'il te faut pour estimer le temps de traduction.
Idem
Afficher les réponses par date
On Wed, Jan 08, 2003 at 12:01:43PM +0100, Marc Chantreux wrote:
La dernière version de ce document est la version 1.7 disponible sur le site de l'auteur :
http404
Un tour sur : http://web.archive.org/web/*/http://personal.riverusers.com/~thegrendel/
La dernière version (si c'est bien la 1.7) est dispo sur : http://www.tldp.org/LDP/abs/html/
Pourras-tu me confirmer si tu te lance dans cette traduction, et dans quel délai tu penses pouvoir terminer ?
arghh ... le fait que je me lance dans cette traduction n'est pas du tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Oui, elle sera obsolète, mais la mise à jour de la version suivante ne prendra pas autant de temps que la traduction initiale.
Raph
Un tour sur : http://web.archive.org/web/*/http://personal.riverusers.com/~thegrendel/
merci !
tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Oui, elle sera obsolète, mais la mise à jour de la version suivante ne prendra pas autant de temps que la traduction initiale.
c'est un des points qui sont tres obscures pour moi : la mise a jour des traductions. Sont-ce des diffs ? Bosse-t-on directement avec les nouveaux sources ? Existe-t'il des outils permettant la traduction simple de petites parties modifiées ?
Marc
On Wed, 8 Jan 2003, Marc Chantreux wrote:
Un tour sur : http://web.archive.org/web/*/http://personal.riverusers.com/~thegrendel/
merci !
tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Oui, elle sera obsolète, mais la mise à jour de la version suivante ne prendra pas autant de temps que la traduction initiale.
c'est un des points qui sont tres obscures pour moi : la mise a jour des traductions. Sont-ce des diffs ? Bosse-t-on directement avec les nouveaux sources ? Existe-t'il des outils permettant la traduction simple de petites parties modifiées ?
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 ?
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.
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).
C'est à mon avis l'un des points qui expliquent qu'il y ait pas mal de choses traduites en francais sous linux, mais nettement moins de choses à jour. Et en plus, pour l'instant, il est TRES difficile pour l'utilisateur de savoir si la doc en francais qu'il a sous les yeux est à jour, ou s'il vaut mieux l'oublier.
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.
Donnez moi un exemple de fichier à traduire, et je vous dirais comment ca va être dur d'utiliser po4a pour cela...
Bye, Mt.
Selon Martin Quinson mquinson@ens-lyon.fr:
On Wed, 8 Jan 2003, Marc Chantreux wrote:
tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Oui, elle sera obsolète, mais la mise à jour de la version suivante ne prendra pas autant de temps que la traduction initiale.
c'est un des points qui sont tres obscures pour moi : la mise a jour des traductions. Sont-ce des diffs ? Bosse-t-on directement avec les nouveaux sources ? Existe-t'il des outils permettant la traduction simple de petites parties modifiées ?
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... Le but de po4a est de traduire un fichier (quelque soit son format grâce aux modules) en un ensemble de fichiers po. 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). 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). 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).
C'est à mon avis l'un des points qui expliquent qu'il y ait pas mal de choses traduites en francais sous linux, mais nettement moins de choses à jour. Et en plus, pour l'instant, il est TRES difficile pour l'utilisateur de savoir si la doc en francais qu'il a sous les yeux est à jour, ou s'il vaut mieux l'oublier.
Malheureusement, oui... mais les derniers efforts de traduc.org laissent espérer des jours meilleurs.
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.
Guillaume Lelarge gleu@wanadoo.fr writes:
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.
Paragraphe par paragraphe, en fait. Ce qui me gêne quand même, pour plusieurs raisons. Tout d'abord, il arrive qu'on ait besoin de fusionner ou scissionner des paragraphes (j'ai dû le faire dans une traduction que j'ai sur le feu). D'autre part, pour certains formats de document (texinfo en ce qui me concerne), la notion de paragraphe est très mal définie.
M'enfin, j'essaierai po4a quand j'aurai le temps et quand il y aura un module texinfo. :-)
On Wed, Jan 08, 2003 at 03:10:48PM +0100, Arnaud Gomes-do-Vale wrote:
Guillaume Lelarge gleu@wanadoo.fr writes:
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.
Paragraphe par paragraphe, en fait. Ce qui me gêne quand même, pour plusieurs raisons. Tout d'abord, il arrive qu'on ait besoin de fusionner ou scissionner des paragraphes (j'ai dû le faire dans une traduction que j'ai sur le feu). D'autre part, pour certains formats de document (texinfo en ce qui me concerne), la notion de paragraphe est très mal définie.
<troll>Mauvais format, changer de format.</troll>
Denis
On Wed, Jan 08, 2003 at 02:55:33PM +0100, Guillaume Lelarge wrote: [...]
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.
Pas exactement, utiliser des fichiers PO permet surtout de gérer la synchronisation avec l'original. Il existe une moulinette qui génère un fichier traduit dans le même format que l'original, on peut donc utiliser le format natif, et régénérer le PO. On pourrait aussi essayer de générer un document contenant à la fois les paragraphes français et anglais, je l'avais fait pour un prédécesseur de po4a, voir p.ex. http://people.debian.org/~barbier/debian-l10n/dselect-beginner/dselect-begin... Ce n'est pas parfait, mais cela montre qu'on peut travailler sur un support autre que le fichier PO, si on le souhaite.
[...]
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).
Oui, c'est ce que je suis en train de tester pour les pages man spécifiques à Debian (non Gérard, je ne marche pas sur tes plates-bandes ;)). C'est aussi ce qu'on fait pour le site web de Debian, mais quand des paragraphes entiers sont déplacés (dans le même fichier ou dans un autre), on regrette de ne pas utiliser de fichiers PO ; le changement se ferait tout seul, on aurait juste à faire une chtite relecture.
[...]
Tiens-moi au courant que tu sera arrivé à intégrer un fichier docbook sgml et/ou xml.
Toute la documentation de KDE utilise Docbook/XML avec des fichiers PO, on s'en est inspiré pour po4a, en transposant l'idée sous-jacente à d'autres formats. Si tu veux du Docbook, le plus simple est de regarder comment ils font, c'est parfaitement opérationnel.
Denis
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 ;)
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/
On Thu, Jan 09, 2003 at 11:52:32AM +0100, Guillaume Lelarge wrote:
Bonjour,
Déjà, merci pour les infos... po4a m'intéresse de plus en plus.
Ca, c'est cool.
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.
Je prétend que si, on garde l'idée globale du document. Les gens de KDE qui utilisent souvent cette approche prétendent que si. Les traducteurs professionels prétendent que si. Mais je me repete, la, non ?
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é?
Des deux. Mais ce n'est pas un mystere. Débarrassés de galères techniques et rébarbatives, les traducteurs de KDE (appli et doc) peuvent se concentrer sur des choses comme uniformiser les traductions, faire la chasse aux typos, chercher de meilleures traductions pour des mots et expressions techniques et ainsi de suite. Pendant ce temps, nous, chez debian, on passe notre temps à chercher comment organiser le chaos ambiant. De l'agacement est né po4a.
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 .
A condition de bien passer les flags -I '^#:' à diff, pour éviter les changements sur les lignes générées automatiquement indiquant à quel endroit du source se trouve la chaine à traduire, car sinon, ca fait pleins de cacas inutiles.
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.
Well, contrairement aux modules sgml et xml de po4a, oui. Certes. Mais comment veux tu que je trouve du temps pour coder si je passe ma vie à faire des mails pour expliquer les avantages potentiels de la traduction de documentation avec gettext ? :)
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.
Voici ou trouver le CVS de po4a, et plus particulierement sa doc principale, écrite de frais (cette nuit):
http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/po4a/po4a/doc/po4a.7.p...
Bye, Mt.
Le Jeudi 9 Janvier 2003 13:11, Martin Quinson a écrit :
On Thu, Jan 09, 2003 at 11:52:32AM +0100, Guillaume Lelarge wrote:
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.
Je prétend que si, on garde l'idée globale du document. Les gens de KDE qui utilisent souvent cette approche prétendent que si. Les traducteurs professionels prétendent que si. Mais je me repete, la, non ?
Oui, mais moi aussi... un partout :)
[...]
Mais de toute façon, on peut utiliser CVS sur les .po au lieu des .(sg|x)ml .
A condition de bien passer les flags -I '^#:' à diff, pour éviter les changements sur les lignes générées automatiquement indiquant à quel endroit du source se trouve la chaine à traduire, car sinon, ca fait pleins de cacas inutiles.
Ah, merci pour l'info. Je préfère éviter les "gros cacas".
[...] Voici ou trouver le CVS de po4a, et plus particulierement sa doc principale, écrite de frais (cette nuit):
http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/po4a/po4a/doc/po4a.7. pod?rev=HEAD&content-type=text/plain
Bon, je sais ce qu'il me reste à faire. Je vais encore avoir des trucs à éditer demain et de la lecture pour le week-end :)
En réponse à Martin Quinson Martin.Quinson@ens-lyon.fr:
D'un autre côté, isoler les 'morceaux' du document peut être
dangereux, on n'a
plus d'idée globale du document.
Je prétend que si, on garde l'idée globale du document. Les gens de KDE qui utilisent souvent cette approche prétendent que si.
Les traducteurs professionels prétendent que si. Mais je me repete, la, non ?
J'ai aussi l'impression qu'on ne perd rien. En effet, pour avoir une idée globale d'un document, il ne suffit pas d'avoir un gros fichier avec tout le document dedans et les paragraphes qui se suivent etc., mais d'avoir lu ou au moins bien survolé le document, dans un format lisible tant qu'à faire (si quelqu'un dit que DocBook est lisible, je me fâche tout rouge ! - et je ne dis pas ça parce que je n'aime pas DocBook)
Tiens, j'en profite pour me placer en tant que traducteur d'un petit bout de l'ABS, s'il en reste ;)
-- Philippe
Bonjour tout le monde,
Selon Marc Chantreux khatar@phear.org:
tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Oui, elle sera obsolète, mais la mise à jour de la version suivante ne prendra pas autant de temps que la traduction initiale.
c'est un des points qui sont tres obscures pour moi : la mise a jour des traductions. Sont-ce des diffs ? Bosse-t-on directement avec les nouveaux sources ? Existe-t'il des outils permettant la traduction simple de petites parties modifiées ?
Tout dépend du cas. Le meilleur outil, à ma connaissance, est diff, que tu es un seul gros fichier ou plusieurs petits. Mais si la modification est très importante, il peut être nécessaire de retraduire le fichier complet. Par contre, je ne vois pas ce que tu entends pour ta dernière question. Personnellement, je fais un diff des fichiers et je modifie les anciennes traductions avec un éditeur (vim dans mon cas).
Un outil que j'allais oublier: cvs. Si tu as la chance que l'auteur original s'est donné la peine de mettre tous les sources de son document sur un cvs auquel tu peux accèder, tu peux ainsi savoir quels sont les fichiers modifiés. Si en plus, il a été assez aimable pour fournir un serveur web avec un gestionnaire de cvs, tu peux même savoir les modifs qu'il a effectué. Regarde par exemple cette page http://cvs.linuxfromscratch.org/index.cgi/LFS/BOOK/entities/manpages.ent.dif... . Et lorsque cet auteur est vraiment très généreux, il peut aussi avoir créé une liste de diffusion où sont envoyés les rapports de modification. En t'abonnant, tu peux savoir les fichiers modifiés et le boulot que tu auras à faire pour mettre à jour la traduction. Par exemple, ceci (http://archive.linuxfromscratch.org/mail-archives/lfs-book/2003/01/0057.html) ne me prendra pas très longtemps, alors que ceci (http://archive.linuxfromscratch.org/mail-archives/lfs-book/2003/01/0032.html) va être plus long mais peu demandant intellectuellement et que celui-ci (http://archive.linuxfromscratch.org/mail-archives/lfs-book/2003/01/0026.html) va être mortel :) Malheureusement, cvs est assez peu utilisé à ma connaissance. Une recherche rapide sur Google ne me permet pas de te dire si c'est le cas pour ce HOWTO.
Dernière chose: je veux bien participer à cette traduction.
je me propose egalement pour donner un coup de main a la traduction. Je peux mettre a dispo un pc en sous Linux (debian unstable) connecte en 24/24 (adsl) et des competances en linux / perl / ...
Ph. rimbault
On Wednesday 08 January 2003 14:38, Guillaume Lelarge wrote:
Bonjour tout le monde,
Selon Marc Chantreux khatar@phear.org:
tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Oui, elle sera obsolète, mais la mise à jour de la version suivante ne prendra pas autant de temps que la traduction initiale.
c'est un des points qui sont tres obscures pour moi : la mise a jour des traductions. Sont-ce des diffs ? Bosse-t-on directement avec les nouveaux sources ? Existe-t'il des outils permettant la traduction simple de petites parties modifiées ?
Tout dépend du cas. Le meilleur outil, à ma connaissance, est diff, que tu es un seul gros fichier ou plusieurs petits. Mais si la modification est très importante, il peut être nécessaire de retraduire le fichier complet. Par contre, je ne vois pas ce que tu entends pour ta dernière question. Personnellement, je fais un diff des fichiers et je modifie les anciennes traductions avec un éditeur (vim dans mon cas).
Un outil que j'allais oublier: cvs. Si tu as la chance que l'auteur original s'est donné la peine de mettre tous les sources de son document sur un cvs auquel tu peux accèder, tu peux ainsi savoir quels sont les fichiers modifiés. Si en plus, il a été assez aimable pour fournir un serveur web avec un gestionnaire de cvs, tu peux même savoir les modifs qu'il a effectué. Regarde par exemple cette page http://cvs.linuxfromscratch.org/index.cgi/LFS/BOOK/entities/manpages.ent.di ff?r1=1.9&r2=1.10&f=h . Et lorsque cet auteur est vraiment très généreux, il peut aussi avoir créé une liste de diffusion où sont envoyés les rapports de modification. En t'abonnant, tu peux savoir les fichiers modifiés et le boulot que tu auras à faire pour mettre à jour la traduction. Par exemple, ceci (http://archive.linuxfromscratch.org/mail-archives/lfs-book/2003/01/0057.ht ml) ne me prendra pas très longtemps, alors que ceci (http://archive.linuxfromscratch.org/mail-archives/lfs-book/2003/01/0032.ht ml) va être plus long mais peu demandant intellectuellement et que celui-ci (http://archive.linuxfromscratch.org/mail-archives/lfs-book/2003/01/0026.ht ml) va être mortel :) Malheureusement, cvs est assez peu utilisé à ma connaissance. Une recherche rapide sur Google ne me permet pas de te dire si c'est le cas pour ce HOWTO.
Dernière chose: je veux bien participer à cette traduction.
Le 2003-01-08 12:01:43 +0100, Marc Chantreux écrivait :
La dernière version de ce document est la version 1.7 disponible sur le site de l'auteur :
http404
Je viens de revérifier, ça marche à nouveau.
De toutes façons, la version 1.7 vient (hier soir) d'être publié sur le site du LDP :
http://www.tldp.org/guides.html
Pourras-tu me confirmer si tu te lance dans cette traduction, et dans quel délai tu penses pouvoir terminer ?
arghh ... le fait que je me lance dans cette traduction n'est pas du tout confirmé ! Je ne bougerais pas le petit doigt a moins de 4 ou 5 personnes. Je ne veux pas me lancer seul dans une traduction qui sera finalement obsolète lors de son achèvement.
Pas de problème. C'était une façon de te demander de me tenir au courant, pas une demande de résultats garantis :)
Je n'ai traduit de la doc. de facon tout a fait occasionnelle et je ne suis donc pas l'homme qu'il te faut pour estimer le temps de traduction.
Même chose, j'ai mentionné le délai pour me faire une idée, mais c'est de toutes façons à titre indicatif.
-
Arnaud Gomes-do-Vale -
Denis Barbier -
feloy＠free.fr -
Guillaume Lelarge -
jean-philippe.guerard＠laposte.net -
Marc Chantreux -
Martin Quinson -
Martin Quinson -
Martin Quinson -
ph. rimbault -
Raph