Bonjour tout le monde,
Ceux qui n'étaient pas là se demandent probablement ce qui a bien pu être dit hier soir, ceux qui étaient là savent que la longueur de la table, la musique de fond et le nombre de conversations tenues en parallèle ont empêché d'entendre tout ce qui était dit... moralité, un compte-rendu est nécessaire pour tout le monde. Voici ma version, les autres présents enverrons la leur ou commenterons.
Qu'est-ce qui existe ? ----------------------
1. LDP ------
Le Linux Documentation Project (HOWTO, LGazette, Man, Guides, etc.) dispose d'un CVS, dans lequel sont conservés tous les HOWTOs et les guides. Quand un auteur se propose pour écrire un nouveau document ou reprendre un document existant non maintenu, les coordinateurs du LDP lui donnent accès en écriture au CVS. Lorsqu'il est satisfait de son document, il envoie un courrier aux coordinateurs en disant "je souhaite que mon doc soit publié". Ces derniers le valident (ispell, sgmlcheck, etc.), puis génèrent les différentes versions et mettent à jour le site http, ftp et les nouvelles (LDP Weekly News).
Une base de données regroupe toutes les métadonnées concernant les documents : auteur, date de la dernière version, numéro de version, DTD utilisée, etc. Cette base de données est mise à jour par les coordinateurs et par tous ceux qui participent au processus de revue (ils demandent à être inscrits aux coordinateurs).
C'est à partir de cette base de données qu'est généré le fichier http://www.lupercalia.net/ldp-status.xml qui regroupe toutes les métadonnées au format OMF.
Format souhaité des documents : XML/DocBook.
2. TRADUC.ORG -------------
Y'a un coordinateur (moi), qui centralise tout : attribution des traductions et des relectures, réception des documents, génération des documents en différents formats pour la publication, etc.
Le coordinateur en question dispose d'un automate (gazo), qui le décharge de la plus grande part de son boulot : attribution et réception des documents, mise à jour du site web, etc.
Toutes les informations concernant les documents en cours de traduction sont conservées au format OMF (XML) et mises à jour par le coordinateur ou par l'automate. Les documents sont conservés dans des répertoires, sans gestion de version.
Format souhaité des documents : XML/Docbook.
3. KDE ------
KDE utilise pour sa documentation un mélange de Docbook + gettext/po. Le document d'origine est découpé en "messages" (par exemple un paragraphe = un message) indépendents. Les messages sont traduits un par un, puis les documents sont générés dans chaque langue avec un outils spécial, qui pour chaque message choisit celui qui est le plus à jour entre la version d'origine et la version traduite. Quand un document est modifié, si sa traduction n'est pas mise à jour, c'est le message dans la langue d'origine qui apparaît dans la version traduite. Pour reprendre les mots de Gérard Delafond "On peut avoir un document en deux langues, mais toute l'information est à jour".
L'outil utilisé est KBabel, qui est fait pour gérer la traduction des fichiers po.
Je n'ai pas retenu comment tout cela était coordonné.
4. DEBIAN ---------
Rien retenu...
5. PYTHON ---------
Python utilise LaTeX pour sa documentation, mais est sur le point de passer à XML/Docbook.
Pour la traduction, le document d'origine en anglais est repris et on y ajoute des balises <langfr> avec la traduction française. On obtient ainsi un document source en deux langues, avec des paragraphes entrelacés : paragraphe d'origine, sa traduction entre balises, paragraphe d'origine, etc.
Un outil permet ensuite, à partir de ce document source en deux langues, de générer la VO ou la VF. On peut ainsi générer la VO traduite, pour faire un diff avec la nouvelle VO. Ou même générer une version spéciale relecteurs avec les deux langues entrelacées.
6. MANDRAKE, GNU, etc. ----------------------
La bonne granularité pour le découpage d'un document en "unités élémentaires" dont on gère les versions successives est le paragraphe. Il faut donc avoir un moyen de savoir que d'une version à l'autre du document, c'est tel et tel paragraphes qui ont été modifiés et qui doivent être mis à jour dans la traduction.
L'idéal, c'est quand le document d'origine est fait pour être traduit.
De quoi a-t-on besoin ? -----------------------
Les traducteurs et relecteurs voudraient passer plus de temps à relire et à traduire et moins de temps à configurer leur machine. Ou tout au moins, ne pas avoir trop de contraintes sur les outils à utiliser et disposer d'une interface simple avec le système qui coordonne les traductions : courrier électronique, interface web. CVS, ispell, un mode emacs, docbook, etc. c'est souvent beaucoup trop lourd à gérer.
De plus, ils aimeraient savoir ce qui a changé depuis la version précédente et ce qui doit être mis à jour, sans que ça leur demande de garder des versions successives des documents et de faire des opérations compliquées.
Enfin ils aimeraient que le système de traduction leur rappelle leurs tâches en cours et les prévienne quand leurs documents sont mis à jour.
Pour ce qui est des relectures et de la traduction à plusieurs d'un document, laisser la responsabilité de la chose à celui qui maintient la version traduite semble raisonnable. Le coordinateur n'a pas à se préoccuper de ces détails et se contente de mettre en relation ceux qui souhaitent traduire et ceux qui souhaitent relire avec celui qui est en charge d'un document.
S'il y avait un système commun à tous les projets de traduction et d'internationalisation, ce serait l'idéal puisqu'on pourrait écrire tous les documents au même format qui facilite les traductions et on pourrait partager des outils plutôt que de développer chacun sa solution dans son coin.
Du point de vue du coordinateur que je suis, moins y'a de boulot et mieux c'est... donc il faut trouver les bons outils pour automatiser au maximum tout ce qui est automatisable. :-)
Faut qu'on s'organise ! -----------------------
La nuit portant conseil, voici ce que je propose de mettre en place pour traduc.org :
* du point de vue des traducteurs/relecteurs
Des alertes pour l'état de la traduction (nouvelle version d'un document, rappel que le document doit être traduit, synthèse envoyée sur la liste, relecteur se porte volontaire, etc.)
Le responsable d'un document se débrouille avec ceux qui veulent l'aider (autres traducteurs, relecteurs). La seule convention de communication entre le responsable d'un document et le système de coordination est l'envoi d'un fichier texte au format XML/Docbook (ou Linuxdoc pour les documents qui sont encore dans ce format).
* du point de vue du coordinateur
Un automate (gazo) qui m'assiste et automatise quantité de choses : l'attribution des documents, le passage à ispell et sgml/xmlcheck, l'envoi de rappels, etc.
Pour déterminer les différences entre deux versions successives de la VO, Logilab doit justement publier demain un xmldiff en python qui devrait permettre d'obtenir l'information qui nous intéresse (paragraphes modifiés) sans pour autant rendre plus complexe le document source (en mélangeant Docbook et po par exemple).
Les informations sur les documents (VO et traduction) sont conservées sous forme de métadonnées au format OMF et publiées sur le site web en HTML et directement au format OMF. Après, chacun en fait ce qu'il veut.
Crânement, j'irai jusqu'à prétendre qu'une bonne partie de tout ceci est déjà en place :-)
En gros, ma position peut se résumer à :
* faut se mettre d'accord sur des formats d'échange et laisser le choix à chacun des outils
* faut pas rendre les choses plus complexes que nécessaire (le mieux est l'ennemi du bien, pas d'overdesign, c'était une phrase Romieu-special).
* avec des documents structurés, on peut faire énormément de choses croyez-en-ma-longue-expérience (chez Logilab, on gère tout, tout, tout sous forme de XML, avec des liens RDF et des transformations ad-hoc, et ça simplifie quantité de problèmes)
Moralité, vive le XML/Docbook et je vais voir comment ajouter des choses à ce que fait Gazo et si xmldiff convient pour détecter les changements. Je ne sais pas si je vais parvenir à partager Gazo comme outil d'aide à la coordination, mais un bon xmldiff devrait intéresser du monde. Ensuite si certains veulent coordonner ça avec une application web écrite en PHP ou un automate de mail écrit en perl...
Epilogue --------
Certains ont regretté qu'on ne boive pas plus et qu'on arrête de discuter à 1h du matin, je suis curieux de savoir si ils ont effectivement poursuivi la soirée au bar d'à côté... mais si c'est le cas, ils ne sont pas forcément devant leur clavier pour mé répondre :-)
Voili, voilou, commentaires anyone ?