Salut,
Bonne bouffe à tous ceux qui y seront. J'aurais bien aimé en faire partie
mais les finances ne sont pas au beau fixe ... c'est la vie ... vive les
knackis.
Manu
Bonjour à tous,
un peu de pinaillage avant la bouffe (biture ?-) de ce soir (mais je n'y
serai pas) :
je m'arrache actuellement les cheveux pour essayer de caser les points
suivants
dans un document DocBook 4.1 pour la Linux Gazette :
- copyright de fin, puisque les mentions dans le source SGML
(article->articleinfo->copyright) n'apparaissent pas dans le document final
(HTML, PDF,
etc...)
- mention du traducteur. Là encore, idem point précédent, si je mets un
<othercredit> dans <articleinfo>, ça n'apparait pas...
J'ai vu sur les listes DocBook que Eric Dumas avait posé la question du
traducteur (pour KDE, si ma mémoire est bonne, ce devait être avant le
passage
au format .po), la réponse de (je sais plus qui : N. Walsh ?) était : oui,
ce
serait bien, surtout pour le traducteur (les autres étant les relecteurs,
etc...).
Le pire, c'est qu'il est explicite dans le Canard que ces champs ne
ressortent
pas après triturage (processing).
Que penseriez-vous de la création d'un appendice aux articles de la gazette,
ayant un titre genre << Ours >>, pour y caser les informations qui sont au
delà
du nom de l'auteur dans les articles originaux (à savoir : les petites notes
sur l'auteur -- qui suis-je, dans quel état j'ère, le copyright, le lien sur
la
licence de la LG, la date de publication, et enfin, le traducteur et le
relecteur).
Autre point : la future version (V5 en alpha) de DocBook sera pure XML.
Vu la bidouille pour passer en XML (cf. http://i18n.kde.org/translation-
howto/doc-translation.html#doc-conversion), ça va être comique. Sans compter
qu'il faut déployer l'artillerie lourde (exit Jade, welcome Java) pour en
faire
qqch.
Mais ça peut attendre un peu.
Bref, ça peut faire un beau sujet de conversation pour les ceusses qui
seront
présents ce soir. Je suis preneur du retour à ce sujet :
- format de la doc française
- outils associés
Cordialement,
Jérôme
--
JF
Bonjour,
puisqu'il est beaucoup question de XML ces temps-ci, je souhaitais savoir si il
existait des moyens *simples* d'avoir un environnent utilisateur pour générer
des documents en différents formats.
Je viens de lire la doc d'É. Jacoboni
(http://www.linux-france.org/article/appli/intro-xml/index.html), qui est
compréhensible (par moi [comprendre : elle est simple, est c'est bien]) et ne
nécessite pas de jongler avec tout plein de truc java.
Sinon, je crois que Sylvain Amrani nous avez promis une doc là dessus, qu'en
est-il ?
Merci,
Xavier
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 ?
--
Nicolas Chauvat
http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)
Hello, members of the French team at `traduc(a)traduc.org'. This is a
message from the Translation Project robot. I`m happy to announce that
a new file, available as:
> http://www.iro.umontreal.ca/contrib/po/teams/PO/fr/tar-1.13.19.fr.po
has been integrated in the central PO archives, and is now kept with
all other accepted French translations. The file should soon be made
available in mirror sites as:
> ftp://ftp.unex.es/pub/gnu-i18n/po/teams/PO/fr/tar-1.13.19.fr.po
> ftp://ftp.chg.ru/pub/doc/gnu-i18n/teams/PO/fr/tar-1.13.19.fr.po
All its 227 messages have been translated, and this PO file has been
submitted to the maintainer of `tar', hoping s/he will include
it in a future release of programs using this textual domain.
Let me thank you for all users of the French language.
The following HTML pages should also be updated by tomorrow.
> http://www.iro.umontreal.ca/contrib/po/HTML/domain-tar.html
> http://www.iro.umontreal.ca/contrib/po/HTML/team-fr.html
The Translation Project robot, in the
name of your kind translation coordinator.
mailto:translation@iro.umontreal.ca
P.S. - You may find a copy (maybe not official) of the distribution as:
> ftp://alpha.gnu.org/gnu/tar/tar-1.13.19.tar.gz
Il me semble que quelqu'un (Xavier V. ?) vient de s'enquérir des moyens
existants pour générer les versions HTML/PDF/etc. des documents DocBook.
Voici l'URL des XSL "spéciales LDP".
--
Nicolas Chauvat
http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)
---------- Forwarded message ----------
Date: Tue, 31 Jul 2001 12:10:39 -0400
From: Dan York <dyork(a)e-smith.com>
To: "discuss @ linuxdoc . org" <discuss(a)linuxdoc.org>
Subject: LDP XSLT stylesheets uploaded to LDP CVS
After Ferg suggested where I should put them in CVS, I uploaded
my experimental XSLT stylesheets to the LDP CVS server in the
directory /builder/xsl. You can view them online at:
http://cvsview.linuxdoc.org/index.cgi/builder/xsl/
In keeping with what I have suggested here, and since no one (here
or on docbook-apps) could suggest anything better, there are three
files for the HTML stylesheets. Two of the files are the ones that
you actually use for XSLT processing:
ldp-html.xsl - generates a single HTML file
ldp-html-chunk.xsl - generates multiple HTML files (breaks on
<chapter>, <sect1>, <appendix>, etc.)
Both of those just import the appropriate Norman Walsh XSL stylesheet
(either "docbook.xsl" or "chunk.xsl") and then import the third file:
ldp-html-common.xsl - where all the actual customizations are
Note that I also uploaded a file "ldp-print.xsl" which does nothing
yet but is the place where customizations for creating FO could be
placed for doing print generation using XML/XSL.
If anyone else out there is experimenting with DocBook XML/XSL, any
suggestions and tests would be welcome.
There is one minor problem with ldp-html-common.xsl which I will
detail in a separate message. It does not appear to affect the
outcome, though, and the results (using 'xsltproc') seem to be
perfectly fine.
Enjoy,
Dan
--
Dan York, Director of Training dyork(a)e-smith.com
Ph: +1-613-751-4401 Mobile: +1-613-263-4312 Fax: +1-613-564-7739
e-smith, inc. 150 Metcalfe St., Suite 1500, Ottawa,ON K2P 1P1 Canada
http://www.e-smith.com/ open source, open mind
_________________________
http://list.linuxdoc.org/
Marc Baudoin <babafou(a)babafou.eu.org> writes:
> > Okay, I installed this data (I can change it back when needed):
> >
> > <translator>Marc Baudoin
> > <mailto>babafou(a)babafou.eu.org
> > <disclaimer>
> > <do>flex
> >
> > <translator>Michel Robitaille
> > <mailto>robitail(a)IRO.UMontreal.CA
> > <disclaimer>
> > <do>a2ps<do>bash<do>bison<do>cpio<do>diffutils<do>enscript<do>error
> > <do>fileutils<do>gcal<do>grep<do>findutils<do>hello<do>id-utils
> > <do>indent<do>libc<do>lilypond<do>make<do>parted<do>sh-utils
> > <do>sharutils<do>tar<do>textutils<do>wget
>
> Well, thank you for asking me first...
Hello,
I'm not sure how I've to read your statement. If one of you isn't
happy with my action, please complain :)
Maybe, I failed because I didn't wait for an okay by Nicolas. Sorry.
Nicholas, please tell me if you've different plans.
Peace,
Karl
--
Free Translation Project:
Karl Eichwalder http://www.iro.umontreal.ca/contrib/po/HTML/