On Wed, Oct 03, 2001 at 05:30:45PM +0200, Nicolas Chauvat wrote:
D'autre part, il y a quelques discussions off-list dont le fait de les tenir en public pourrait pporter je pense une meilleure dynamique, afin que tout le monde puisse suggérer des idées et/ou prendre sa part du boulot.
Bonne idée.
Si j'ai bien compris, nous avons :
- Martin Quinson, déjà actif dans le projet de Traduction de Debian
prend en main la gestion des trads des programmes (docs ?) du projet GNU dans le cadre du "Translation Project" (lire Translation Project des éléments du projet GNU)
Vi, on parle pas de la doc des programmes, mais des messages affichés par les programmes. Il s'agit donc de traduire les classiques fichiers pot en non moins classiques fichiers po. Et précision supplémentaire, j'y tiens pour m'etre fait grondé par Karl y'a pas longtemps, le GNU est de trop dans le nom. Quasi tous les programmes GNU (au sens, parainés par la FSF) sont la dedans, mais y'a pas besoin d'etre GNU pour profiter de cette infrastructure. J'avais discuté avec Francois Pinard (l'auteur originel, meme s'il semble s'etre dégagé) y'a maintenant un moment, et il disait qu'il regrettait que les autres projets tels que kde, gnome et debian aient mis en place une infrastructure comparable.
Donc, une fois pour toute, d'accord pour parler de projet de traduction GNU à l'oral (en concidérant la liste de diffusion comme orale), mais dans les faits, il s'agit du 'projet de traduction libre', ouvert à tous.
- Nicolas Chauvat, gestionnaire du projet de traduction en français du
Linux Documentation Project (LDP == HOWTOs, mans et autres)
C'est moi :-)
Bonjour !
- Christophe Merlet (récemment arrivé ici), gestionnaire du projet
(moins formel que les précédents pour l'instant) de traduction de Gnome en français (rattaché au Gnome Translation Project), btw qui vient de rejoindre cette liste
Salut RedFox ! C'est moins formel du coté de Gnome parce que pendant un moment, il y a eu un seul traducteur régulier (lui) et de rares occasionels (dont moi), alors l'irc etait amplement suffisant pour gerer tout ca. Mais les choses sont en train de bouger...
D'autres, que je ne citerai pas pour l'instant.
Ah, dommage...
Il doit bien y avoir quelqu'un de KDE et quelqu'un d'autre de python dans la salle, non ? Qui d'autre ?
Il me semble qu'il y a de fortes synergies entre ces 3/4 projets à développer.
A mon avis, les principaux problèmes de la situation actuelle sont :
- difficile, parmi tous les projets en cours, de savoir rapidement qui a besoin d'aide et pour quoi
Pour 1. rassembler un peu plus les projets. L'idée n'est pas de tout intégrer dans une structure rigide, mais de permettre à ceux qui veulent conrtibuer de s'y retrouver plus facilement. Une façon de faire serait de maintenir un site web commun dans lequel les différents projets auraient chacun une section qui respecterait une même structure (description, référence mailing-list, outils, état de la traduction, ...)
La navigation serait ainsi plus facile et on peut espérer fédérer les différentes tâches à faire au moyen de canaux RSS, par exmple, pour les présenter sur la page d'accueil.
Lorsque j'ai eu Joël au téléphone hier, nous avons discuté de la possibilité de mettre en place un CVS sur www.traduc.org, lequel permettrait aux coordinateurs des différents projets de maintenir à jour leurs pages web. Pour que tout ait même un aspect, je propose d'employer une représentation intermédiaire en XML, à partir de laquelle seront générées les pages du site. Y'aurait rien à inventer, je génére déjà www.traduc.org comme ça...
Je suis assez d'accord, mais j'ai un bemol : on a des pages chez Debian, qui ont le look 'page Debian' classique, et on a pas le gout d'en faire 15 sortes... Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
- difficile d'installer les outils pour DocBook,
Pour 2. Il faut attendre que les distributions fassent avancer les choses, ou s'organiser un peu pour pousser à la roue. Il me semble qu'il y a déjà pas mal de documentation disponible sur le sujet, mais parfois, trop de documentation nuit à la documentation, pour le débutant tout au moins.
no comment qui ne soit pas un troll
- difficile de savoir rapidement quels outils et formats employer,
Pour 3. Se mettre d'accord sur les formats et développer des outils pour les manipuler. Mon avis personnel est formé : DocBook/XML 4.1.2 comme format de base, convertible au besoin en po/html/pdf/ps etc. (oui, oui, .po inclus pour gérer les versions avec les mêmes outils :-)
Je suis *vraiment* d'accord avec ce souhait d'universalité du format po. Je pense que les traducteurs ont maintenant des outils sympas pour traduire les po, tels que kbabel, gtranslator, ou le mode po d'emacs, et il faut leur permettre de les utiliser.
- difficile, quand on maintient une traduction, de savoir ce qui a changé depuis la version précédente lorsqu'il y a une mise à jour
Pour 4. Logilab a contribué http://www.logilab.org/xmldiff/ dont j'ai déjà parlé sur cette liste. Je n'ai pas eu plus de temps à y consacrer, un volontaire pour creuser le sujet serait le bienvenu.
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
- déplaisant, quand on prend sur son temps libre pour traduire, de ne pas voir le résultat de son travail publié rapidement,
Pour 5. S'il y avait moins de format différents et de possibilités d'avoir des problèmes au moment de la génération des documents, j'avoue que le genre de travail que j'ai à faire serait facilité.
Oui. gettext rules. Voila pour la famille d'outils. Ensuite, pour l'extraction/la remise en place des chaines à traduire, les gens de KDE ont ca, meme s'il me semble qu'on devrait pouvoir améliorer un peu.
Pour la logistique, j'y reviens apres.
- difficle, quand on coordonne un projet de traduction, de s'assurer de la qualité des documents et de ne pas trop ralentir le mouvement,
Pour 6. C'est le problème de la relecture et de la qualité du résultat. Avec certains traducteurs, la relecture est presque inutile, avec d'autres elle est tout simplement indispensable. Il faut cependant que tous puissent participer et il est difficile pour celui qui coordonne de se faire une idée de la qualité du résultat sans lire une grosse part des documents, ce qui prend du temps... et ralenti encore le processus de publication.
Chez Debian, le role de relecteur et de coordinateur est séparé. On poste sur la liste tout ce qu'on voudrait voir relire, et on a des gens qui font ca tres bien. Mieux que ce que nous, coordinateurs avec Denis nous ne pourrions faire. Chacun son job.
De plus, toujours chez Debian, on pense qu'il vaut mieux moins de traduction de meilleur qualité. On veut pas faire du chiffre. Donc, on passe beaucoup de temps à relire. Donc, un traducteur qui fait une mauvaise traduction va se manger pleins de mails de correction et il va passer un sale quart d'heure pour integrer toutes ces corrections. La fois suivante, il utilisera ispell avant d'envoyer son document, il fera attention à ce que le format de son document soit juste d'un point de vue technique et tout et tout. Mais on a de la chance d'avoir de bons relecteurs, aussi.
Dans mes reves les plus fous, on aurait des moulinettes pour extraire dans des fichiers po tous les formats existants, afin que les traducteurs et relecteurs puissent faire leur boulot sans se soucier de savoir si c'est un livre, les messages d'un programme, la page man, des fichiers debconf, la description d'un paquet ou dieu sait quoi.
Ensuite, on utiliserait tous des robots comme celui du projet de traduction GNU. Voire ce robot la exactement, lui meme. Je ne parle pas de cette instance la, mais de ce programme la. Ie, de la meme facon qu'il existe des floppées de bugzilla sur terre, il pourrait y avoir des floppées de TP-Robot.
Ce robot gererait qui traduit quoi, relancerait les traducteurs quand qqch change, demanderait leur avis à quelques relecteurs triés sur le volet avant d'accepter quoi que ce soit, ferait de belles pages webs de statistiques, et ainsi de suite. La vie serait belle, et les coordinateurs pourraient aller dormir (ce que je fais maintenant ;).
Remarque finale : j'avais dit la dernière fois que je ferai un résumé de notre discussion au resto et de celle qui avait suivi sur la liste, mais je n'ai pas trouvé le temps. Pourrions-nous cette fois-ci trouver un volontaire "secrétaire de séance" qui nous fera un résumé qui sera mis sur www.traduc.org et mis à jour au fur et à mesure ?
Je suis d'accord, car je suis marié à Lyon, alors c'est meme pas la peine de me parler de bouffe à Paris...
M'en fous, j'ai au moins deux espions dans la place : Denis et RedFox... ;)
Bye, Mt.