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.