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 ?
Afficher les réponses par date
Le Wed, Jul 25, 2001 at 11:15:51AM +0200, Nicolas Chauvat a écrit:
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 ?
Sisi, je ne sais pas pour Xavier, mais perso je suis d'attaque depuis 8h30, merci :)
Sinon, en commentaire, j'attends toujours que le gentil gazo nous gazouille un rapport sur la liste avec howto a jour, pas a jour, a traduire et obsoletes. histoire de voir ce qui reste a faire...
Arnaud.
En réponse à Arnaud S . Launay :
Le Wed, Jul 25, 2001 at 11:15:51AM +0200, Nicolas Chauvat a écrit:
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 ?
Sisi, je ne sais pas pour Xavier, mais perso je suis d'attaque depuis 8h30, merci :)
Ben ça va pour un type qui à dormi trois heures ; en même temps, j'ai comme un peu mal à la tête, là.
Xavier -- du pas bonheur du tout de se lever très tôt
Sinon, en commentaire, j'attends toujours que le gentil gazo nous gazouille un rapport sur la liste avec howto a jour, pas a jour, a traduire et obsoletes. histoire de voir ce qui reste a faire...
C'est ça que tu cherches ?
http://www.traduc.org/HOWTO/etat.html
Tous les commentaires sont les bienvenus, sachant qu'il y reste certainement des erreurs et que les métadonnées sources sont disponibles au format OMF :
http://www.traduc.org/HOWTO/howtodb.xml
Le mer 25 jui 2001 à 19:21 +0200, Nicolas Chauvat a écrit :
Sinon, en commentaire, j'attends toujours que le gentil gazo nous gazouille un rapport sur la liste avec howto a jour, pas a jour, a traduire et obsoletes. histoire de voir ce qui reste a faire...
C'est ça que tu cherches ?
formidable. C'est opérationnel depuis longtemps ? Je croyais que ça ne fonctionnait que pour la Gazette (et là, à l'instant, je viens de comprendre le nom de Gazo).
Tous les commentaires sont les bienvenus, sachant qu'il y reste certainement des erreurs et que les métadonnées sources sont disponibles au format OMF :
Commentaires : - l'auteur d'origine n'est pas dans la base xml, c'est normal ? - as-tu une DTD pour ce fichier ?
Sur la présentation de etat.html : - ajouter date+jour de la génération de la page (c'est psychologique ;-)
- est-ce qu'on peut (oui) avoir une vue triée par état ? ie tous les dispos, puis tous les en cours, tous les en relec, tous les à jour.
Merci.
Commentaires :
- l'auteur d'origine n'est pas dans la base xml, c'est normal ?
Je ne sais pas si c'est souhaitable, mais en tous cas c'est voulu. L'auteur d'origine a son nom dans http://www.lupercalia.net/ldp-status.xml
- as-tu une DTD pour ce fichier ?
http://www.ibiblio.org/osrt/omf/ (voir menu de droite)
Y'a aussi des ajouts personnels dans il faudrait idéalement se débarasser. Faut considérer ça comme un travail en cours de réalisation.
- ajouter date+jour de la génération de la page (c'est psychologique ;-)
Ok, je vais le faire.
- est-ce qu'on peut (oui) avoir une vue triée par état ? ie tous les
dispos, puis tous les en cours, tous les en relec, tous les à jour.
Grâce à ma machine à remonter le temps (ou au fait que tu ne t'es pas connecté au net pour envoyer tes messages depuis hier), j'ai mis ça en place avant même de recevoir ton courrier.
juste un petit ajout sur ce que vient de dire nico :
la difficulté de syncronization entre les doc originaux et la traduction francaise a aussi ete (un peu) traitée dans les debats d'hier soir.
MHA là dessus, c'est qu'il faudrait peut etre, avant de commencer une traduction, se mettre en relation avec l'(les) auteur(s) et leur expliquer que l'on va la traduire leur connerie de document ! :). comme ca, si le traducteur devient 'le traducteur officiel' aupres de traduc.org, il faudrait qu'il le soit aussi aupres de l'auteur.
Si on veut formaliser/automatiser ce processus, c'est pas bien dur, il suffit de faire un ou deux emails types, que traduc.org et le traducteur envoient a l'auteur comme une sorte de document officiel, pour montrer qu'on est pas des rigolos non plus et donc pour qu'on soit pris au serieux. Comme ca, si le traducteur n'est pas trop con^H^H^H occupé, il peut donner des explications supplémentaires, envoyer les versions en cours pour que le traducteur voit les futurs changement, etc etc.
Moi, je sais pas si j'ai eu de la chance ou quoi, mais avant de commencer la traduction, j'ai pris contact avec les auteurs, qui sont vraiment super sympas mais super busy. Ca ne les as pas empeché de m'envoyer quelques messages de temps en temps et de mettre ma traduction sur leur site. En plus, maintenant que je suis identifié aupres d'eux, ils me donnent des nouvelles des prochaines versions en cours, me les envoient, etc. ca permet une certaine cohérence de la demarche je trouve.
Voilà, c'etait mon humble proposition, j'attends vos avis,
-- Pejvan BEIGUI "je sais pas ou est Ornicar" - Tabarnac,kebek (kanada)
Nicolas Chauvat wrote:
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 ?
- 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.
- 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.
- 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é.
- DEBIAN
Rien retenu...
- 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.
- 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 ?
-- Nicolas Chauvat
http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)
The Wed, Jul 25, 2001 at 11:15:51AM +0200, Nicolas Chauvat wrote : [...]
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
Le rapport signal/(troll+picole) me semble quand même plus qu'honorable.
[...]
- DEBIAN
Rien retenu...
- suggestion d'outils de type reportbug (cf http://packages.debian.org/testing/utils/reportbug.html); - utilisation massive de cvs avec délégation assez stricte des droits de commit; - la localisation des pages webs se marie bien avec wml; - la localisation des paquetages au sein du projet ne remonte pas facilement vers les auteurs (même pb pour les bug-fixes); - certains scripts de gestion de la bdd sont aujourd'hui dans les choux.
[...]
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.)
+ la même chose sur une page www (on l'a déjà mais ne l'oublions pas au passage).
[...]
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).
Oui.
[...]
un automate de mail écrit en perl...
Présent.
On Wed, Jul 25, 2001 at 11:15:51AM +0200, Nicolas Chauvat wrote:
Bonjour tout le monde,
Salut,
pourquoi `fin' ?
[...]
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.
Toujours pas trouvé sur Logilab, t'as une URL ? Je vais commencer par regarder Narval. Je vois dans les pré-requis que je dois installer 4suite, tu peux me dire quelle est sa licence ? Je cherche depuis 1/4 d'heure dans les sources et sur leur site, mais je ne trouve rien.
[...]
- KDE
KDE utilise pour sa documentation un mélange de Docbook + gettext/po.
Je ne me souviens pas qu'il ait parlé de Docbook.
- PYTHON
Python utilise LaTeX pour sa documentation, mais est sur le point de passer à XML/Docbook.
Olivier, tu confirmes ? J'avais pas entendu ça.
[...]
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...
Ce qui m'embête dans ton message, c'est que ta conclusion, tu aurais pu l'écrire sans cette réunion. Tu occultes complètement (dans la conclusion) la présentation de Gérard sur l'utilisation des fichiers po, qui a été pour moi le point le plus original et intéressant. L'autre idée qui m'a beaucoup plu et à laquelle il faut s'attaquer est d'intégrer dès le départ dans le document original le fait que des traducteurs vont passer derrière.
Des documents structurés sont souhaitables, mais pourquoi en XML ? Les fichiers po sont structurés, les .spec de rpm sont structurés, les fichiers LaTeX décrits par Olivier sont structurés. Ces documents ne seront pas écrits en XML, un outil général doit néanmoins pouvoir les prendre en compte.
Bon maintenant, il me reste à bouffer du narval pour essayer de comprendre coment ça marche.
Denis
The Wed, Jul 25, 2001 at 11:16:16PM +0200, Denis Barbier wrote : [...]
Des documents structurés sont souhaitables, mais pourquoi en XML ?
Peut-être parce qu'il serait bon que les fichiers parlent un même dialecte avant qu'on s'en serve pour générer de la page de man, de l'info ou du PostScript (R) (TM) ? Hors de sa tendance au bloat et de la lenteur des moulinettes à DocBook, c'est peut-être un bon candidat. Pour les howto c'est clair. Qu'en est-il des autres documents ?
Les fichiers po sont structurés, les .spec de rpm sont structurés, les fichiers LaTeX décrits par Olivier sont structurés. Ces documents ne seront pas écrits en XML, un outil général doit néanmoins pouvoir les prendre en compte.
Sans format source commun, ça implique un balisage spécifique par langage pour stocker les métadonnées et un outil adapté. On a donc le choix entre 1) s'engager dans un schéma de migration des formats source de documentation vers un même dialecte 2) spécifier le format des métadonnées en fonction du type de document auquel on les applique et écrire les moulinettes adéquates au coup par coup.
1) serait bien mais c'est du long terme et avant que tout le monde soit d'accord au niveau global, ça laisse du temps. Ca n'empèche pas de bosser sur 2) et de commencer par s'entendre sur le contenu des métadonnées.
Donc: qu'est-ce qu'on doit mettre dans ces métadonnées ?
Donc: qu'est-ce qu'on doit mettre dans ces métadonnées ?
Y'a déjà des gens qui se sont posé beaucoup de questions à ce sujet et qui sont arrivés à un certain nombre de conventions :
OMF : open-source metadata framework - http://www.ibiblio.org/osrt/omf/
lui-même (très) inspiré de
DC : Dublin Core Metadata Initiative - http://dublincore.org/
pour ceux qui ne connaissent pas et qui souhaiteraient porusuivre leurs lectures, y'a http://www.w3c.org/RDF et http://www.w3c.org/2001/sw/, mais là on commence à s'éloigner du sujet.
(en ce qui me concerne, j'ai mis à disposition toutes les metadonnées concernant les HOWTOs sur le site http://www.traduc.org/HOWTO/howtodb.xml)
Francois Romieu romieu@ensta.fr writes:
Hors de sa tendance au bloat et de la lenteur des moulinettes à DocBook, c'est peut-être un bon candidat. Pour les howto c'est clair. Qu'en est-il des autres documents ?
Pas si lentes que ça, les moulinettes. Enfin, pas toutes. Pour la FAQ fcol, nous avons récemment abandonné xp/xt pour la libxslt de Gnome http://xmlsoft.org/XSLT/, il y a une sacrée différence.
Francois Romieu a écrit :
The Wed, Jul 25, 2001 at 11:16:16PM +0200, Denis Barbier wrote : [...]
Des documents structurés sont souhaitables, mais pourquoi en XML ?
Peut-être parce qu'il serait bon que les fichiers parlent un même dialecte avant qu'on s'en serve pour générer de la page de man, de l'info ou du PostScript (R) (TM) ? Hors de sa tendance au bloat et de la lenteur des moulinettes à DocBook, c'est peut-être un bon candidat. Pour les howto c'est clair. Qu'en est-il des autres documents ?
Les pages de man peuvent être écrites en DocBook (sauf erreur de ma part).
Pour produire de l'info, il me semble que c'est faisable depuis du DocBook aussi...
pourquoi `fin' ?
fin de la bouffe et de son organisation, pas des discussions ni des traductions...
Toujours pas trouvé sur Logilab, t'as une URL ? Je vais commencer par regarder Narval.
Je croyais l'avoir mis, mais il n'y était pas, je viens de le rajouter sur le site ftp (ftp://www.logilab.org/pub/narval/applications/). Ce n'est pas encore documenté, tu ferais mieux de commencer par regarder des recettes simples (le journal par exemple) avant de te plonger dans les recettes de Gazo. Et surtout, n'hésite pas à me poser des questions, soit directement, soit sur narval-utilisateurs@logilab.org, je sais que ce n'est pas trivial de se plonger dans Narval et suis tout disposé à passer du temps à expliquer aux nouveaux venus le pourquoi et le comment de certains aspects du système.
Je vois dans les pré-requis que je dois installer 4suite, tu peux me dire quelle est sa licence ? Je cherche depuis 1/4 d'heure dans les sources et sur leur site, mais je ne trouve rien.
Tu va sur http://4suite.org et tu suis le lien Download dans le menu de gauche et tu choisis un paquetage quelconque. Il t'affiche la licence avant que tu puisses cliquer sur le lien de téléchargement.
A ma connaissance, 4Suite est déjà inclus dans la Debian.
- KDE
KDE utilise pour sa documentation un mélange de Docbook + gettext/po.
Je ne me souviens pas qu'il ait parlé de Docbook.
Gérard, tu confirmes ?
Ce qui m'embête dans ton message, c'est que ta conclusion, tu aurais pu l'écrire sans cette réunion.
Non, plusieurs points qui proviennent de cette réunion, en particulier l'idée que c'est le système de coordination qui doit se charger de déterminer les différences entre les versions successives des documents pour permettre au traducteur de se concentrer sur la traduction.
Tu occultes complètement (dans la conclusion) la présentation de Gérard sur l'utilisation des fichiers po, qui a été pour moi le point le plus original et intéressant.
C'est en effet original, mais cela présente (à *mon* avis) de gros désavantages : le document n'existe plus. Il est conservé dans une boîte plus ou moins opaque, dont on peut tirer des versions particulières. Fini le format standard, bonjour le format spécifique/propriétaire.
De plus, je ne pense pas que cela facilite le travail de l'auteur que de gérer des identifiants de paragraphes d'un côté et le contenu des paragraphes de l'autre.
L'autre idée qui m'a beaucoup plu et à laquelle il faut s'attaquer est d'intégrer dès le départ dans le document original le fait que des traducteurs vont passer derrière.
Oui. Mais je pense qu'avec un outil adapté pour faire la différence entre deux arbres XML et pour refondre un un seul plusieurs arbres distincts, on peut obtenir la même chose, sans avoir à développer des outils spécifiques : xmldiff c'est extrêmement générique et des transforamtions XML aussi.
Et le format d'origine reste du DocBook "normal".
En fait, je propose de développer des outils qui permettent de traduire "simplement" des fichiers DocBook standard plutôt que de créer un nouveau standard qui dévie du précédent. En revanche, je ne pas du tout contre adopter des conventions particulières pour faciliter la traduction. En particulier, donner un identifiant unique à tous les paragraphes et d'un document ne me paraît pas une contrainte inconcevable, surtout si cela permet de faciliter la traduction.
Des documents structurés sont souhaitables, mais pourquoi en XML ? Les fichiers po sont structurés, les .spec de rpm sont structurés, les fichiers LaTeX décrits par Olivier sont structurés. Ces documents ne seront pas écrits en XML, un outil général doit néanmoins pouvoir les prendre en compte.
J'utilise XML depuis trois ans et je suis très satisfait du résultat. En particulier, les outils et autres bibliothèques pour manipuler du XML sont très largement répandus et disponibles dans de nombreux langages. C'est tout l'intérêt des standards, tu t'en sers de base pour faire le reste et ça t'épargne un grand nombre d'efforts.
A mon avis, il faut commencer par un système qui marche avant de passer à un système "général". De plus, la structuration des fichiers po et rpm, bien qu'elle existe, est bien faible en regard de ce qui faisable et courant avec des fichiers XML.
Une façon simple de faire, qui va malheureusement peut-être en faire hurler certains, est d'écrire un parser SAX pour tes fichiers po et rpm, de manière à récupérer des arbres XML que tu compares entre eux avec tes outils standards. Et que tu peux retransformer en po et rpm "texte" ensuite si tu le désires. Suffit de se mettre d'accord sur la DTD équivalente au format d'origine.
Bon maintenant, il me reste à bouffer du narval pour essayer de comprendre coment ça marche.
Surtout, n'hésite pas à m'écrire.
On Thu, Jul 26, 2001 at 11:18:31AM +0200, Nicolas Chauvat wrote:
pourquoi `fin' ?
fin de la bouffe et de son organisation, pas des discussions ni des traductions...
Toujours pas trouvé sur Logilab, t'as une URL ? Je vais commencer par regarder Narval.
Je croyais l'avoir mis, mais il n'y était pas, je viens de le rajouter sur le site ftp (ftp://www.logilab.org/pub/narval/applications/).
Ok merci.
[...]
Je vois dans les pré-requis que je dois installer 4suite, tu peux me dire quelle est sa licence ? Je cherche depuis 1/4 d'heure dans les sources et sur leur site, mais je ne trouve rien.
Tu va sur http://4suite.org et tu suis le lien Download dans le menu de gauche et tu choisis un paquetage quelconque. Il t'affiche la licence avant que tu puisses cliquer sur le lien de téléchargement.
A ma connaissance, 4Suite est déjà inclus dans la Debian.
Exact, c'est même Jérôme qui s'y est collé.
- KDE
KDE utilise pour sa documentation un mélange de Docbook + gettext/po.
Je ne me souviens pas qu'il ait parlé de Docbook.
Gérard, tu confirmes ?
Effectivement, j'avais mal compris, désolé.
Ce qui m'embête dans ton message, c'est que ta conclusion, tu aurais pu l'écrire sans cette réunion.
Non, plusieurs points qui proviennent de cette réunion, en particulier l'idée que c'est le système de coordination qui doit se charger de déterminer les différences entre les versions successives des documents pour permettre au traducteur de se concentrer sur la traduction.
Ok, j'ai le cerveau lent, il va falloir que ça se décante un peu.
[...]
Des documents structurés sont souhaitables, mais pourquoi en XML ? Les fichiers po sont structurés, les .spec de rpm sont structurés, les fichiers LaTeX décrits par Olivier sont structurés. Ces documents ne seront pas écrits en XML, un outil général doit néanmoins pouvoir les prendre en compte.
J'utilise XML depuis trois ans et je suis très satisfait du résultat. En particulier, les outils et autres bibliothèques pour manipuler du XML sont très largement répandus et disponibles dans de nombreux langages. C'est tout l'intérêt des standards, tu t'en sers de base pour faire le reste et ça t'épargne un grand nombre d'efforts.
A mon avis, il faut commencer par un système qui marche avant de passer à un système "général".
C'est justement pour ça que j'ai trouvé ce qu'a dit Gérard très intéressant, il a présenté un système qui marche, et qui manque de matière à traduire et pas de traducteurs, ce qui est à mon sens un point extrêmement positif, qui mérite qu'on y regarde de plus près. Vous en connaissez beaucoup, des projets de traduction qui se permettent de dire ça ?
De plus, la structuration des fichiers po et rpm, bien qu'elle existe, est bien faible en regard de ce qui faisable et courant avec des fichiers XML.
Oui, mais suffisante.
Une façon simple de faire, qui va malheureusement peut-être en faire hurler certains, est d'écrire un parser SAX pour tes fichiers po et rpm, de manière à récupérer des arbres XML que tu compares entre eux avec tes outils standards. Et que tu peux retransformer en po et rpm "texte" ensuite si tu le désires. Suffit de se mettre d'accord sur la DTD équivalente au format d'origine.
Tant que tu ne les exclues pas d'emblée sous prétexte que ce n'est pas du XML, ça me va.
Bon maintenant, il me reste à bouffer du narval pour essayer de comprendre coment ça marche.
Surtout, n'hésite pas à m'écrire.
Ok, je promets pas de le faire dans la minute.
Denis
A mon avis, il faut commencer par un système qui marche avant de passer à un système "général".
C'est justement pour ça que j'ai trouvé ce qu'a dit Gérard très intéressant, il a présenté un système qui marche, et qui manque de matière à traduire et pas de traducteurs, ce qui est à mon sens un point extrêmement positif, qui mérite qu'on y regarde de plus près. Vous en connaissez beaucoup, des projets de traduction qui se permettent de dire ça ?
Je trouve moi aussi l'approche Docbook/gettext intéressante, mais l'idée qui me gêne est de toujours avoir un document incomplet... soit on a la structure d'un côté et le contenu de l'autre, soit on a une partie dans une langue et une partie dans une autre. Sans compter qu'on saucissonne le document et donc sa traduction, ce qui peut donner un résultat difficle à la lecture.
On peut aussi faire un message = un paragraphe, ce qui résoudrait ce dernier problème, mais j'ai cru comprendre que ce n'était pas ce qui avait été fait pour KDE et je suppose qu'il y a une raison qui l'empêche.
Gérard, y'a-t-il une raison ?
De plus, nous parlions de limiter au maximum les outils à installer sur la machine du traducteur et du relecteur... si pour le coup on impose Kbabel.
Je sais qu'on peut mettre à jour des fichiers .po avec vi, mais il m'a semblé que la plupart des fonctions intéressantes (correction orthographique, statistiques, versions, etc.) étaient dans Kbabel. Il faudrait donc les recoder pour les autres outils si elles ne sont pas déjà disponibles.
Gérard, est-ce que je me trompe ?
De plus, la structuration des fichiers po et rpm, bien qu'elle existe, est bien faible en regard de ce qui faisable et courant avec des fichiers XML.
Oui, mais suffisante.
Oui. Mais qui peut le plus peut le moins. Donc si on a les outils qui traitent du XML générique, on a tout ce qu'il faut pour des fichiers XML dont la structure est simple.
Ce que je cherche à éviter, c'est d'avoir un prog qui gère les différences entre versions pour les .spec, un autre qui gère les différences entre versions pour les pages de man, un autres pour les HOWTO, etc.
Je cherche à utiliser XML comme format pivot.
Ok, je promets pas de le faire dans la minute.
La semaine prochaine faudra t'adresser à narval-utiliisateurs@logilab.org, car je ne serai pas là.
Nicolas Chauvat a écrit :
En fait, je propose de développer des outils qui permettent de traduire "simplement" des fichiers DocBook standard plutôt que de créer un nouveau standard qui dévie du précédent. En revanche, je ne pas du tout contre adopter des conventions particulières pour faciliter la traduction. En particulier, donner un identifiant unique à tous les paragraphes et d'un document ne me paraît pas une contrainte inconcevable, surtout si cela permet de faciliter la traduction.
Pour cet ID, je crois que c'est la solution qu'a adopté Mandrake (Sbi + Camille Begnis... il serait peut-être bon qu'il se joigne à nous, d'ailleurs...)
Tant qu'on y pense, pourquoi ne pas inviter l'ensemble des gens ayant une activité de traduction sur le Libre à se joindre à la liste (Mandrake, *BSD... etc.) ?
Comme je l'ai évoqué à la bouffe, nous avons besoin de décloisonner les projets, de communiquer, et d'avoir des occasions de travailler spécifiquement sur la problématique de la doc...
Je crois que le topic doc des RMLL de Bordeaux a été un des plus actifs et fructueux (et principalement orienté trad, d'après ce que j'ai pu en juger)... et si je ne m'abuse la conf O'Reilly OpenSource qui vient de se terminer avait un cursus spécifique doc... il serait probablement intéressant d'en avoir un certain feedback, car la problématique de la trad s'est probablement posée un peu là bas, même si c'était basé aux states...
Olivier qui va peut-être s'abonner à discuss@linuxdoc.org... même s'il n'a pas le temps de tout lire :(
Pour cet ID, je crois que c'est la solution qu'a adopté Mandrake (Sbi + Camille Begnis... il serait peut-être bon qu'il se joigne à nous, d'ailleurs...)
Tant qu'on y pense, pourquoi ne pas inviter l'ensemble des gens ayant une activité de traduction sur le Libre à se joindre à la liste (Mandrake, *BSD... etc.) ?
Bonne idée. Tu as des adresses ? Tu les contactes directement, ou tu m'envoies les adresses que tu as que je les invite ?
On pourrait les inviter à nous rejoindre dès que j'aurai placé sur le site le compte-rendu de notre bouffe mis à jour avec les remarques de chacun.
A TOUS: si d'autres parmi vous ont des adresses ou des idées de groupes de traduction à contacter, ça serai bien qu'ils me les envoient. Le but ne serait pas de fédérer tous les projets en un seul (bonjour l'administration !), mais de discuter tous ensemble des outils et des "bonnes pratiques".
Le 2001-08-01 11:26:13 +0200, Nicolas Chauvat écrivait :
A TOUS: si d'autres parmi vous ont des adresses ou des idées de groupes de traduction à contacter, ça serai bien qu'ils me les envoient. Le but ne serait pas de fédérer tous les projets en un seul (bonjour l'administration !), mais de discuter tous ensemble des outils et des "bonnes pratiques".
Une petite question : hier soir, je suis passé regarder le site de linuxdoc, et j'ai jeté un coup d'oeil à la page où des volontaires peuvent laisser leurs coordonnées :
http://www.linuxdoc.org/authors/vlist.html
Il y a là un certain nombre de personnes qui souhaîte participer à des traductions anglais-français.
Prenons-nous contact avec les personnes qui s'inscrivent sur cette liste ?
On Tue, Jul 31, 2001 at 12:02:09AM +0200, Olivier Berger wrote:
Tant qu'on y pense, pourquoi ne pas inviter l'ensemble des gens ayant une activité de traduction sur le Libre à se joindre à la liste (Mandrake, *BSD... etc.) ?
Pourquoi pas. Un message dans le newsgroup fr.comp.os.bsd est une bonne idee en effet. En ce qui concerne FreeBSD, il faut poster dans la mailing-list freebsd-questions@freebsd-fr.org. Voir
http://www.freebsd-fr.org/local-fr/www/spec/mailing-lists.html
pour plus de details.
Denis Barbier a écrit :
Des documents structurés sont souhaitables, mais pourquoi en XML ? Les fichiers po sont structurés, les .spec de rpm sont structurés, les fichiers LaTeX décrits par Olivier sont structurés. Ces documents ne seront pas écrits en XML, un outil général doit néanmoins pouvoir les prendre en compte.
Parce que XML est facile à parser, dans tous les langages de programmation qu'on puisse inventer... contrairement aux autres formats...
C'est donc un format particulièrement bien adapté aux (mauvais) traitements qu'on veut pouvoir faire subir à nos docs (diffs, etc...)... même s'il reste à trouver des éditeurs XML suffisamment utilisables par les traducteurs (sauf si on convertir XML en .po... ?)
Denis Barbier a écrit :
- PYTHON
Python utilise LaTeX pour sa documentation, mais est sur le point de passer à XML/Docbook.
Olivier, tu confirmes ? J'avais pas entendu ça.
C'est ce que j'ai cru comprendre des débats du topic documentation du LSM... mais je ne suis pas vraiment personnellement la doc Python... peut-être quelqu'un a-t-il plus d'infos (voir le SIG doc de python.org ?)... Benoît Lacherez ?
On Wed, Jul 25, 2001 at 11:15:51AM +0200, Nicolas Chauvat wrote:
- LDP
%< ---
Format souhaité des documents : XML/DocBook.
- TRADUC.ORG
%< ---
Format souhaité des documents : XML/Docbook.
- KDE
KDE utilise pour sa documentation un mélange de Docbook + gettext/po.
%< ---
de Gérard Delafond "On peut avoir un document en deux langues, mais toute l'information est à jour".
Personnellement, je n'aime pas çà du tout. L'idée peut paraître certe séduisante mais a de gros défauts. Un document est écrit par un auteur ou un groupe d'auteur ce qui lui donne un style propre. Le traducteur se _contente_ de traduire au mieux en adaptant à la langue "cible". De plus c'est très déroutant pour le lecteur. Tout le monde n'est pas polyglotte. Il vaut mieux un document pas tout à fait à jour bien compris qu'un document en 25 langues a proximativement compris.
GNOME -----
SGML/Docbook
(je ne veus pas jouer le chieur mais c'est XML/DocBk normalement, non ?)
- DEBIAN
Rien retenu...
- PYTHON
Python utilise LaTeX pour sa documentation, mais est sur le point de passer à XML/Docbook.
Il semble que tout le monde s'oriente vers du Docbook. Bien, qu'on aime ou pas au moins cela harmonise.
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.
Interessant mais lourd à la longue. J'imagine d'ici la gueule du document avec des dizines de langues (avec du cyrilique tiens !)
- MANDRAKE, GNU, etc.
%< ---
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.
Tout à fait d'accord !!
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.
Oh ! oui !!!!
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.
Euh ... Oui mais pas trop souvent ... Ou gentiement ;-)
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.
Je pense que ton format est XML/Docbk. Pour les traducteurs, outils existent déjà; il faudrait juste en simplifier la mise en oeuvre (installation, utilisation ...).
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. :-)
C'est encore toi le plus mal loti car il n'y a pas d'outil d'administration. Mais Gazo peut être étendu pour faire ce qu'il faut, non ?
L'idéal serait que _tout_ le monde s'accorde sur un format et des outils (génération, administration ...) et qu'on en fasse un "package" commun à tous mais donc chacun serait libre de n'utiliser que la partie qu'il souhaite.
<mode je rève et vais me faire des amis <g>> L'idéal serait aussi que toutes les traductions se fassent sur une même et unique liste avec des tags pour ceux qui veulent trier parce qu'ils ne veulent pas voir les autres. Cela permettrait d'avoir une archive commune et éviter qu'une même question sur Docbook se répète sur 25 ml à la fois. </end>
Faut qu'on s'organise !
%< ---
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
Je crois que c'est plus ou moins évident. Je devrais tout lire avant de répondre :-)
%< ---
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
Euh, qu'est-ce que tu veus dire par là ?
certains veulent coordonner ça avec une application web écrite en PHP ou
Pourquoi pas.
Danigo Ludovic a écrit :
On Wed, Jul 25, 2001 at 11:15:51AM +0200, Nicolas Chauvat wrote:
GNOME
SGML/Docbook
(je ne veus pas jouer le chieur mais c'est XML/DocBk normalement, non ?)
XML aussi, je crois bien, maintenant (ou au moins dans Gnome 2.0 ?) : http://developer.gnome.org/projects/gdp/handbook/gdp-handbook/docbookbasics....
Nicolas Chauvat a écrit :
- 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.
Plus de détail sur les outils mis en place par le groupe de trad de la doc Python dans le HOWTO suivant : http://frpython.sourceforge.net/docs/page.php3?id=12
SNIP
Sinon, suggestion, Nicolas : publier ce texte (avec quelques contributions intégrées) sur www.traduc.org ? (ça permet de dynamiser le site, ce qui n'est pas mal non plus pour donner envie aux contributeurs de monter à bord ;)
Sinon, suggestion, Nicolas : publier ce texte (avec quelques contributions intégrées) sur www.traduc.org ? (ça permet de dynamiser le site, ce qui n'est pas mal non plus pour donner envie aux contributeurs de monter à bord ;)
Bonne idée. C'est maintenant dans ma pile.
Nicolas Chauvat a écrit :
- PYTHON
Python utilise LaTeX pour sa documentation, mais est sur le point de passer à XML/Docbook.
A ma connaissance, il n'est pas question d'utiliser Docbook pour la documentation anglaise de Python, les pythoniens ayant besoin de balises plus spécifiques.
Par ailleurs, un autre de nos problèmes est que la date de ce passage à XML n'est pas encore définie...
On 01 Aug 2001 04:37:13 +0200, Benoit Lacherez wrote:
Nicolas Chauvat a écrit :
- PYTHON
Python utilise LaTeX pour sa documentation, mais est sur le point de passer à XML/Docbook.
A ma connaissance, il n'est pas question d'utiliser Docbook pour la documentation anglaise de Python, les pythoniens ayant besoin de balises plus spécifiques.
Oui, en effet... j'ai gourragé ;)
La doc existante, bien qu'en LaTeX, est déjà dans des feuilles de style correspondant à des normes très précises, qui constituent facilement une DTD adhoc. Il ne s'agit donc pas d'un passage vers DocBook, mais vers du XML adapté à la doc Python.
Pour les intéressés par la "DTD" / les styles LaTeX existants : http://ftp.easynet.be/python/doc/current/doc/doc.html
A+
-
Arnaud Gomes-do-Vale -
Arnaud S . Launay -
Benoit Lacherez -
Danigo Ludovic -
Denis Barbier -
Francois Romieu -
Guillaume Allègre -
jean-philippe.guerard＠laposte.net -
Nicolas Chauvat -
Olivier Berger -
Paul Marques Mota -
Pejvan -
Xavier Venient