Bonjour,
Encore un nouveau venu qui va s'exprimer sur ce sujet :)
- faire marcher mon assistant, ou le remplacer par un autre système.
J'imagine que l'assistant actuel fonctionne par CGI. Un système basé sur PHP/MySQL ne serait-il pas plus simple à mettre en oeuvre et à maintenir ?
Ca me semblerait plus simple en effet.
Gérard Delafond a mentionné l'autre jour son système à base de PHP+MySQL dans lequel tout le monde peut s'inscrire. La traduction espagnole de la Linux Gazette a un truc similaire.
Ca peut effectivement être intéressant. S'il y a une URL pour en savoir
plus,
je suis preneur.
Je vais regarder leur travail. En ce qui concerne le couple habituel PHP/MySQL, je vais vous faire part de ma propre expérience dans ce domaine.
Je coordonne actuellement la traduction du livre LinuxFromScratch depuis mi-décembre. Un système, baptisé TNT, gère la réservation des fichiers. J'ai codé quelques modifications sur ce système. Voici comment le tout fonctionne: 1- Chaque contributeur peut connaître la liste des fichiers de la traduction et leur état (à traduire, en cours de traduction, traduit, en cours de relecture, relu). 2- Chaque contributeur peut réserver (en traduction, ou en relecture si il est déjà traduit) un fichier après s'être identifié avec un login et un mot de passe. 3- Une fois réservé, le contributeur va traduire/relire le fichier... pour récupérer les fichiers en question, il dispose de lien vers les documents XML. 4- Une fois son travail effectué, il renvoie par mail soit directement au coordinateur soit par le biais de la liste de diffusion. 5- Le coordinateur vérifie que l'ensemble des fichiers à intégrés est bien valide (le livre est au format DocBook). 6- Si tout est valide, le coordinateur va sur une page d'administration où il pourra indiquer que le fichier est traduit/relu et intégrera les modifications dans le CVS (dont lui-seul à l'accès en écriture).
Voilà en gros les différentes étapes pour la traduction/relecture d'un fichier. J'ai simplifié un peu car nous sommes réellement trois coordinateurs, qu'il faut aussi mettre à jour le FTP avec les fichiers et les archives. L'ensemble de scripts permettant cette gestion est évidemment disponible sous GPL. Si vous avez des questions, je suis tout à fait disposé à y répondre.
faudrait faire du LDP un projet multilingue plutôt que d'avoir une version officielle en anglais et des gens qui rament autour pour
avoir
de la doc dans d'autres langues
La nouvelle orientation du LDP offre en effet des possibilités tout à fait intéressantes. Je vais tout à fait dans ce sens.
Entièrement d'accord.
Je vais continuer mon petit tour du site traduc.org et tdlp.org en ma qualité de nouveau venu pour comprendre un peu comment réserver des fichiers.
A bientôt, Guillaume.
Afficher les réponses par date
Bonjour,
je suis l'un des coordinateurs de l'équipe de traduction Debian, et aussi du Translation Project (qui traduit les messages de toutes les applications GNU, mais pas seulement).
En ce qui concerne Debian, on traduit plusieurs sortes de choses, et on a diverses procedures pour chacunes (je melange alégrement les spécificités francophones aux procédures normales chez Debian).
En ce qui concerne le site web, le plus important n'est pas de traduire, mais de garder la traduction à jour. Aussi, chaque traducteur est nomé responsable du fichier, et on des batteries de scripts pour faire des courriels au traducteur quand il faut mettre à jour, et pour indiquer sur le site lui meme que la traduction est désyncronisée. C'est le plus rapide qui s'attribue une traduction, en mettant son nom avec la bonne syntaxe dans le fichier, et en obtenant des coordinateurs qu'ils commitent le fichier.
En ce qui concerne les traductions des descriptions des paquets, meme si les outils de gestion des paquets ne gerent pas encore les traductions de descriptions, on a un effort pour les traduire. C'est qu'il y a pres de 10000 paquets dans Debian, et au rythme actuel, tout sera traduit d'ici 18 mois, si ma mémoire est bonne. Pour cela, on a un serveur mail. On peut demander des traductions à faire au serveur, et donner le résultat de son travail par la meme voie. On peut aussi demander des relectures à faire, et une traduction est réputée valide quand trois relecteurs ont relu sans rien trouver à redire. Le serveur gere donc aussi les rapports de bogues.
En ce qui concerne les traductions des messages des programmes spécifiques à Debian, la plupart de ces programmes sont dans des CVS ou les coordinateurs ont le droit d'écrire, et on a pas de procédure particuliere. C'est qu'il y a au maximum une demi douzaine de projets dont il faut traduire les messages comme ca...
En ce qui concerne la traduction de la documentation, on est totalement archaique par rapport à ce qui se fait chez KDE, par exemple. Notre probleme, c'est que Debian fait la plupart de sa doc au format DebianDoc, qui est du SGML, et on arrive pas à mettre au point des programmes de convertion po<->sgml (KDE utilise du XML, moins permissif, ce qui simplifie l'écriture de programme de retraitement). Pourtant, sans cela, chaque mise à jour dans l'original est un petit cauchemard pour le traducteur : « sapristi, mais qu'est ce qui a changé, et qu'est ce qui est resté pareil ? ». De plus, les procedures d'attribution des traductions sont tres manuelles aussi, et je sais pas pourquoi, mais on arrive pas à atteindre la masse critique dans ce domaine. Certains manuels sont bien maintenu, d'autres sont completement à la dérive. Ca dépend du temps et de l'organisation personnelle du traducteur. C'est pour ca que le systeme TNT dont tu me parle m'interresse tant. Mais j'y reviendrais.
Un autre truc qu'on traduit, c'est ce qu'on appelle les templates debconf. Il s'agit d'un programme qui permet aux paquets de tous poser les questions qu'ils doivent poser pour pouvoir se configurer de la meme maniere. Et, entre autre, on peut traduire ces messages. Dans ce domaine, c'est un peu galere pour nous car il faut que la traduction soit incluse dans le paquet qui va poser la question. Et c'est top galere de centraliser tout ca, et de s'assurer que les mainteneurs incluent le fichier sans casser l'encodage au bon endroit. Denis Barbier (l'autre coordinateur Debian francophone) gère tout ca plus ou moins à la main, si j'ai bien compris.
On a rien de particulier pour traduire les pages man, les manuels info ou autre joyeusetés du genre. À mon grand désespoir.
Du coté du Translation Project, on ne s'occupe que de fichiers po. Pour le prix, on s'occupe de tous les fichiers po issus de GNU, plus quelques autres. Ici, tout est centralisé par le robot que vous connaissez bien pour avoir recu des tonnes de mails de lui y'a quelques mois. Ce robot est spécialisé sur les po, mais il est vraiment tres bien. Il a une base de donnée des « dommaines textuels » et des traducteurs de chacuns d'entre eux dans toutes les langues, et ensuite, le mainteneur envoie le nouveau fichier pot, et le robot prévient qui doit l'etre. Ensuite, les traducteurs envoient leur prose, le robot lance une série de vérification syntaxiques, enregistre le fichier si tout va bien, puis prévient le mainteneur qu'une nouvelle trad est dispo. Bref, tout marche tout seul, y'a plus qu'a traduire, et laisser les problemes logistiques de coté ;)
Je coordonne actuellement la traduction du livre LinuxFromScratch depuis mi-décembre. Un système, baptisé TNT, gère la réservation des fichiers. J'ai codé quelques modifications sur ce système. Voici comment le tout fonctionne: 1- Chaque contributeur peut connaître la liste des fichiers de la traduction et leur état (à traduire, en cours de traduction, traduit, en cours de relecture, relu). 2- Chaque contributeur peut réserver (en traduction, ou en relecture si il est déjà traduit) un fichier après s'être identifié avec un login et un mot de passe. 3- Une fois réservé, le contributeur va traduire/relire le fichier... pour récupérer les fichiers en question, il dispose de lien vers les documents XML. 4- Une fois son travail effectué, il renvoie par mail soit directement au coordinateur soit par le biais de la liste de diffusion. 5- Le coordinateur vérifie que l'ensemble des fichiers à intégrés est bien valide (le livre est au format DocBook). 6- Si tout est valide, le coordinateur va sur une page d'administration où il pourra indiquer que le fichier est traduit/relu et intégrera les modifications dans le CVS (dont lui-seul à l'accès en écriture).
Voilà en gros les différentes étapes pour la traduction/relecture d'un fichier. J'ai simplifié un peu car nous sommes réellement trois coordinateurs, qu'il faut aussi mettre à jour le FTP avec les fichiers et les archives. L'ensemble de scripts permettant cette gestion est évidemment disponible sous GPL. Si vous avez des questions, je suis tout à fait disposé à y répondre.
Ca ressemble furieusement à ce que je cherches pour les documentations Debian. T'as une URL, une tarball à télécharger ?
Merci, Mt.
une traduction est réputée valide quand trois relecteurs ont relu sans rien trouver à redire.
Ce n'est pas trop exigeant? As-tu assez de relecteurs pour y arriver?
Ca ressemble furieusement à ce que je cherches pour les documentations Debian. T'as une URL, une tarball à télécharger ?
TNT est disponible ici: http://traduc.lfs.tuxfamily.org/archives/tnt-0.8.zip (86ko tout trempé :).
Ceci dit, je ne crois pas que ce package soit vraiment à jour. En fait, un bug sur le script 'Mot de passe perdu' vient d'être découvert et je dois encore travailler dessus. De plus, il manque un certain nombre d'informations, comme les tables à créer sur la base MySQL.
Bref, ce package est intéressant pour se donner une idée du système (ainsi que de ma mauvaise façon de coder :).
Je prépare pour ce week-end une version améliorée, avec beaucoup plus d'infos sur la façon de l'utiliser.
Guillaume.
une traduction est réputée valide quand trois relecteurs ont relu sans rien trouver à redire.
Ce n'est pas trop exigeant? As-tu assez de relecteurs pour y arriver?
Pour les HOWTOs et la Linux Gazette, chaque traducteur est responsable de son document. Le site et la liste ne servent qu'à lui faciliter la recherche de relecteur. Ensuite, c'est au traducteur d'envoyer le document pour au relecture, d'intégrer les modifications au besoin et d'envoyer le document final.
C'est l'organisation à laquelle nous sommes arrivés après discussion et cela présente l'avantage de ne pas avoir des traductions anonymes, qui peuvent inciter traducteur ou relecteur à se dire "bof, ça ira bien comme ça". Le traducteur est responsable de son document, si le résultat est mauvais, c'est de sa faute. Les relecteurs doivent expliquer au traducteur pourquoi ils proposent tel ou tel changement. D'une part, s'ils sont mauvais, les traducteurs auront moins envie de faire appel à eux et d'autre part, ils ne peuvent pas changer un document sans l'avis de celui qui a fait tout le boulot.
Moi, j'explique comment et pourquoi on a travaillé comme ça jusqu'à maintenant, après, ça veut pas dire qu'on ne peut pas faire évoluer les choses...