Provided by:
po4a_0.40-1_all 
NOM
po4a - Cadre de travail pour la traduction de documentations et autres
documents
Introduction
L'objectif du projet po4a [PO for anything -- PO pour tout] est de
simplifier la traduction (et de faon plus intressante, la maintenance
des traductions) en utilisant les outils gettext dans des domaines pour
lesquels ils n'taient pas destins, comme la documentation.
Table des matires
Ce document est organis de la manire suivante:
1 Pourquoi utiliser po4a? quoi cela sert-il?
Cette section d'introduction explique les motivations du projet et
sa philosophie. Vous devriez le lire si vous cherchez valuer po4a
pour vos traductions.
2 Comment utiliser les fonctionnalits de po4a?
Cette section est une sorte de manuel de rfrence qui cherche
rpondre aux questions des utilisateurs et qui vous donnera une
meilleure comprhension de son fonctionnement. Il vous donnera les
bases de l'utilisation de po4a et sert d'introduction la
documentation des outils spcifiques.
Comment commencer une nouvelle traduction?
Comment convertir la traduction en un fichier de documentation?
Comment mettre jour une traduction faite avec po4a?
Comment convertir une traduction pr-existante ce systme?
Comment ajouter des choses n'tant pas des traductions (comme le nom
du traducteur)?
Comment automatiser tout ceci?
Comment personaliser po4a?
3 Comment a marche?
Cette section vous donne un bref aperu des rouages internes de po4a
afin que vous vous sentiez plus mme de nous aider le maintenir et
l'amliorer. Elle peut galement vous permettre de comprendre
pourquoi cela ne fait pas ce que vous souhaitez et corriger vos
problmes par vous-mme.
4 FAQ
Cette section regroupe les questions le plus souvent poses. En
fait, la plupart d'entre elles sont des questions de design du
projet. Si vous pensez que po4a n'est pas la bonne rponse au
problme de traduction de documentation, lisez cette section avant
de nous donner votre avis sur la liste de diffusion
<po4a-devel@lists.alioth.debian.org>. Votre avis nous intresse.
5 Notes spcifiques certains modules
Cette section prsente les spcificits de chaque module du point de
vue du traducteur et de l'auteur original. Lisez le pour prendre
connaissance du format des traductions pour ce module et les rgles
suivre dans le document original pour rendre le travail des
traducteurs plus simple.
Cette section ne fait pas vraiment partie de ce document, mais elle
est place dans chaque documentation des modules. Ceci permet de
s'assurer que les informations sont jour en conservant la
documentation et le code ensemble.
Pourquoi utiliser po4a? Dans quel domaine est-il bon?
J'aime le concept des logiciels sources ouverts, qui permettent de
donner
tous un accs au logiciel et son code source. Mais, tant moi-mme
franais, je suis conscient que la licence n'est pas le seul frein
l'ouverture d'un logiciel: les logiciels non traduits, mme s'ils sont
libres, sont sans aucune utilit pour ceux qui ne comprennent pas
l'anglais, et il y a encore beaucoup de travail pour les rendre
accessibles vraiment tout le monde.
La perception du problme par les acteurs du dveloppement libre s'est
fortement acclre rcemment. Nous, les traducteurs, avons gagn une
premire bataille et avons convaincu tout le monde de l'importance des
traductions. Mais c'est malheureusement la partie la plus facile. Il
faut maintenant raliser tout le travail et traduire tous les documents.
Les logiciels aux sources ouverts bnficient d'un niveau de traduction
relativement bon, grce la formidable suite d'outils gettext. Ces
outils permettent d'extraire les chanes traduire du programme, de les
prsenter sous une forme standard pour les traducteurs, puis d'utiliser
le rsultat de leur travail lors de l'excution pour afficher les
messages traduits aux utilisateurs.
Mais cette situation est assez diffrente en ce qui concerne les
documentations. Trop souvent, la documentation traduite n'est pas assez
visible (pas distribue avec le programme), seulement partielle ou pas
jour. Cette dernire situation est de loin la moins bonne. Les
traductions pas jour peuvent se rvler plus embtantes pour les
utilisateurs que l'absence de traduction parce que d'anciens
comportements d'un programme peuvent y tre dcrits, mais ne plus tre en
vigueur.
La problmatique
La traduction des documentations n'est pas une tche difficile en
elle-mme. Les textes sont bien plus longs que les messages des
programmes ce qui rend leur traduction plus longue, mais il n'y a
aucune difficult technique faire ceci. La difficult vient en fait de
la maintenance de la traduction. La dtection des parties ayant t
modifies et ncessitant une mise jour est une tche trs difficile, ce
qui explique que tant de traductions ne correspondent plus la version
originale.
La rponse de po4a
La maintenance de la traduction est donc la raison premire de po4a. La
faon de faire de gettext a t rutilise dans ce but. Comme avec gettext,
des chanes de texte sont extraites de leur emplacement d'origine de
faon tre prsentes de faon standardise aux traducteurs. Les outils pour
gettext sont ensuite utiliss pour aider le traducteur faire son
travail lorsqu'une nouvelle version du document est disponible. Mais,
la diffrence de l'utilisation classique de gettext, les traductions
sont rinjecte dans la structure du document d'origine de faon pouvoir
les utiliser ou les distribuer comme les documents de la version
anglaise.
Grce ceci, la dtection des parties du document qui ncessitent une mise
jour est trs facile. Un autre avantage est que l'outil va faire une
bonne partie du travail lorsque seule la structure du document t
modifie et que des chapitres ont t dplacs, rassembls ou redcoups. En
extrayant le texte traduire de la structure du document, il permet
galement de masquer la complexit de la mise en page et rduit les
chances d'avoir un document dfectueux (mme s'il reste un risque).
Veuillez galement consulter la FAQ plus bas dans ce document pour une
liste plus complte des avantages et inconvnients de cette approche.
Formats pris en charge
Actuellement, cette approche a t implmente avec succs pour un certain
nombre de formats de mise en page de texte.
man
Le bon vieux format des pages de manuel, utilis par beaucoup de
programmes. Le support de po4a pour ce format est trs utile parce que
ce format est assez compliqu, surtout pour les dbutants. Le module
Locale::Po4a::Man(3pm) supporte galement le format mdoc, utilis par les
pages de manuel BSD (elles sont galement assez frquentes sous Linux).
pod
C'est le format pour la documentation en ligne de Perl (Perl Online
Documentation). Le langage et ses documentations sont documents de
cette faon, ainsi que la plupart des scripts Perl existants. Il permet
de garder la documentation plus fidle au code en les intgrant tous deux
au mme fichier. Il rend la vie du programmeur plus simple, mais
malheureusement pas celle du traducteur.
sgml
Mme s'il est de plus en plus remplac par le XML, ce format est encore
assez utilis pour les documents dont la taille dpasse plusieurs crans.
Il permet de faire des livres complets. La mise jours de documents
aussi longs est un vrai cauchemar. diff se montre souvent inutile quand
le document original a t rindent aprs une mise jour. Heureusement,
po4a vous aide dans cette tche.
Actuellement, seules les DTDDebianDoc et DocBook sont prises en charge,
mais l'ajout d'une nouvelle est trs facile. Il est mme possible
d'utiliser po4a avec une DTDSGML inconnue sans modifier le code en
fournissant les informations ncessaires sur la ligne de commande.
Veuillez consulter Locale::Po4a::Sgml(3pm) pour plus de dtails.
TeX / LaTeX
Le format LaTeX est un format majeur utilis pour les documentations
dans le monde du logiciel libre ou pour des publications. Le module
Locale::Po4a::LaTeX(3pm) a t test avec la documentation de Python, un
livre et avec quelques prsentations.
texinfo
Toutes les documentations du projet GNU sont crites dans ce format
(c'est mme une des exigences pour devenir un projet officiel du projet
GNU). Le support pour Locale::Po4a::Texinfo(3pm) dans po4a en est
encore ses dbut. Veuillez nous envoyer des rapports de bogue ou des
demandes de nouvelle fonctionnalit.
xml
Le format XML est la base de beaucoup de formats pour la
documentation.
ce jour, la DTDDocBook est prise en charge par po4a. Veuillez
consulter Locale::Po4a::Docbook(3pm) pour plus de dtails.
autres
Po4a peut galement grer des formats plus rares et plus spcifiques, tels
que celui de la documentation des options de compilation des noyaux
2.4.x ou les diagrammes produits par l'outil dia. L'ajout d'un nouveau
format est souvent trs simple, et consiste principalement fournir un
interprteur pour le format voulu. Veuillez consulter
Locale::Po4a::TransTractor(3pm) pour plus d'informations ce sujet.
Formats non supports
Malheureusement, po4a ne supporte pas encore certains formats utiliss
pour les documentations.
Il y a une quantit d'autres formats que nous aimerions supporter avec
po4a, et pas seulement des formats de documentation. En fait, nous
visons toutes les niches laisses par les outils gettext classiques.
Cela va de la traduction de la documentation des descriptions des
paquets Debian et paquetages rpm, aux les questions poses par les
scripts d'installation, ex passant par les fichiers changelog, et de
tous les formats spcifiques tels que les scnarios de jeux ou les
fichiers de ressource pour wine.
Comment utiliser po4a?
Cette section est une sorte de manuel de rfrence qui cherche rpondre
aux questions des utilisateurs et qui vous donnera une meilleure
comprhension de son fonctionnement. Il vous donnera les bases de
l'utilisation de po4a et sert d'introduction la documentation des
outils spcifiques.
Rsum graphique
Le schma suivant donne un aperu du processus mis en oeuvre pour la
traduction de documents avec po4a. Ne soyez pas effray par son
apparente complexit, qui est due au fait que le processus complet y est
prsent. Une fois que vous avez converti votre projet po4a, seule la
partie de droite du graphique est utilise.
Notez que maitre.doc est pris pour exemple de documentation traduire
et traduction.doc est la traduction correspondante. L'extension
pourrait tre .pod, .xml ou .sgml en fonction du format. Chaque partie
de la figure est dtaille dans les sections suivantes.
maitre.doc
|
V
+<-----<----+<-----<-----<--------+------->-------->-------+
: | | :
{traduction} | { mise jour de maitre.doc } :
: | | :
XX.doc | V V
(optionnel) | maitre.doc ->-------->------>+
: | (nouveau) |
V V | |
[po4a-gettextize] doc.XX.po--->+ | |
| (ancien) | | |
| ^ V V |
| | [po4a-updatepo] |
V | | V
traduction.pot ^ V |
| | doc.XX.po |
| | (I<fuzzy>) |
{ traduction } | | |
| ^ V V
| | {dition manuelle} |
| | | |
V | V V
doc.XX.po --->---->+<---<-- doc.XX.po addendum maitre.doc
(initial) ( jour) (optionnel) ( jour)
: | | |
: V | |
+----->----->----->------> + | |
| | |
V V V
+------>-----+------<------+
|
V
[po4a-translate]
|
V
XX.doc
( jour)
La partie gauche illustre la conversion d'une traduction n'utilisant
pas po4a. En haut de la partie droite est prsent ce qui est du ressort
de l'auteur du document d'origine (la mise jour de la documentation).
Au milieu de la partie de droite se trouve la partie automatise par
po4a. Les nouvelles chanes sont extraites et compares avec la
traduction existante. Pour celles qui n'ont pas chang, la traduction
prcdente est utilise. Celles qui ont t en partie modifies sont galement
associes leur ancienne traduction, mais avec un marquage spcifique
indiquant que la traduction doit tre mise jour. La partie du bas
indique comment le document format est construit.
En fait, en tant que traducteur, la seule opration manuelle consiste en
l'tape indique par {dition manuelle}. En effet, nous nous en excusons,
po4a aide la traduction, mais il ne traduit rien pour vous...
Comment commencer une nouvelle traduction?
Cette section prsente les tapes ncessaires pour dbuter une nouvelle
traduction avec po4a. Les modifications appliquer pour la conversion
d'un projet existant sont dtailles dans la section correspondante.
Voici les tapes permettant de commencer une traduction avec po4a:
- Extraction du texte du document d'origine <maitre.doc> qui doit tre
traduit dans <traduction.pot>, un nouveau fichier POT (le format
utilis par gettext). Pour ceci, utilisez po4a-gettextize de cette
faon:
$ po4a-gettextize -f <format> -m <maitre.doc> -p <traduction.pot>
Naturellement, <format> est le format du document maitre.doc et la
sortie est place dans traduction.pot. Veuillez consulter
po4a-gettextize(1) pour plus de dtails concernant les options
existantes.
- Traduit rellement ce qui doit tre traduit. Pour cela, vous devez
renommer le fichier POT en doc.XX.po (o XX est le code ISO639 de la
langue vers laquelle vous tes en train de traduire, c.--d. fr pour le
franais), puis diter ce fichier. C'est souvent une bonne ide de ne
pas nommer le fichier XX.po pour viter de confondre ce fichier avec
la traduction des messages du programme, mais vous faites comme vous
voulez. N'oubliez pas de mettre jour les en-ttes du fichier PO, ils
sont importants.
La traduction peut tre ralise avec Emacs et son mode PO ou Lokalize
(bas sur KDE) ou Gtranslator (bas sur GNOME) ou encore n'importe quel
programme que vous prfrez utiliser pour l'dition de ces fichiers. Un
bon vieux vi fera l'affaire, mme s'il n'y a pas de mode spcial pour
ce type de tche.
Si vous voulez en apprendre plus ce sujet, vous voudrez probablement
consulter la documentation de gettext, disponible dans le paquet
gettext-doc.
Comment convertir la traduction en un fichier de documentation?
Une fois que la traduction est effectue, il faut gnrer la documentation
traduite et la distribuer avec l'original. Pour cela, utilisez
po4a-translate(1) de cette faon (XX reprsente le code de la langue):
$ po4a-translate -f <format> -m <maitre.doc> -p <doc.XX.po> -l <XX.doc>
Comme prcdemment, <format> est le format du document maitre.doc. Mais
cette fois-ci, le fichier PO fourni en paramtre de l'option -p est un
fichier d'entre. Il s'agit de votre traduction. La sortie se trouve
dans le fichier XX.doc.
Veuillez consulter po4a-translate(1) pour plus de dtails.
Comment mettre jour une traduction faite avec po4a?
Pour mettre jour votre traduction lorsque l'original maitre.doc a
chang, utilisez po4a-updatepo(1) comme ceci:
$ po4a-updatepo -f <format> -m <nouveau_maitre.doc> -p <ancien.XX.po>
(Veuillez consulter po4a-updatepo(1) pour plus de dtails)
Naturellement, les nouveaux paragraphes de ce document ne seront pas
traduits par magie dans le fichier "PO" par cette opration, et vous
devrez mettre jour le fichier "PO" manuellement. De la mme faon, vous
devrez vrifier les traductions des paragraphes qui ont t lgrement
modifis. Pour vous assurer que vous n'en oubliez pas, ils sont marqus
comme approximatifs (fuzzy) pendant cette phase, et vous devrez retirer
cette marque avant d'utiliser la traduction avec po4a-translate. Comme
pour la traduction originelle, vous pouvez utiliser votre diteur de
fichier PO prfr.
Une fois que votre fichier "PO" est de nouveau jour, sans aucune chane
non traduite ou marque comme approximative (fuzzy), vous pouvez gnrer
un fichier de documentation traduit, comme expliqu dans la section
prcdente.
Comment convertir une traduction pr-existante ce systme?
Souvent, vous traduisez manuellement le document sans difficult, jusqu'
ce qu'une rorganisation majeure du document d'origine maitre.doc
apparaisse. Alors, aprs quelques essais infructueux en utilisant diff
ou des outils similaires, vous voulez convertir la traduction po4a.
Mais bien sr, vous ne souhaitez pas perdre votre traduction existante
dans le mme temps. Pas de panique, ce cas est aussi gr par les outils
de po4a et est appel gettextization.
Le point important pour ceci est d'avoir la mme structure de document
pour l'original et la version traduite, de faon ce que les outils
associent leur contenu correctement.
Si vous avez de la chance (c.--d., si les structures des deux documents
se correspondent parfaitement), ceci fonctionnera sans soucis, et vous
n'en aurez que pour quelques secondes. Sinon, vous allez comprendre
pourquoi ce processus a un nom si barbare, et vous devriez vous prparer
une tche ingrate. Dans tous les cas, souvenez-vous que c'est le prix
payer pour bnficier du confort que po4a vous apportera par la suite. Le
point positif est que vous n'aurez faire cela qu'une seule fois.
Ceci ne sera jamais rpt suffisamment: afin de faciliter ce processus,
il est trs important de trouver la version exacte qui a t utilise pour
raliser la traduction. La meilleure situation est quand vous avez not
la version CVS lors de la traduction.
a ne fonctionnera pas trs bien si vous utilisez le document d'origine
mis
jour avec l'ancienne traduction. a reste possible, mais sera plus
compliqu et doit tre vit autant que possible. En fait, je pense que si
vous n'arrivez pas trouver le document original, la meilleure solution
est de trouver quelqu'un pour faire la gettextization pour vous (mais,
s'il vous plat, pas moi;).
Je dramatise peut-tre un peu trop ici. Mme lorsque tout ne se passe pas
bien, c'est bien plus rapide que de tout retraduire. J'ai pu raliser
une gettextization de la traduction franaise de Perl en un jour, mme si
les choses ne se sont pas bien passes. Il y avait plus de deux
mgaoctets de textes, et une nouvelle traduction aurait pris des mois.
Voici d'abord la procdure, puis nous reviendrons sur les astuces qui
permettent d'y parvenir avec succs lorsqu'il y a un problme. Pour
faciliter la comprhension, rutilisons encore une fois l'exemple
prcdent.
Une fois que vous avez l'ancien maitre.doc correspondant la traduction
XX.doc, la gettextization peut tre faite directement dans doc.XX.po
sans traduction manuelle du fichier traduction.pot:
$ po4a-gettextize -f <format> -m <ancien_maitre.doc> -l <XX.doc> -p <doc.XX.po>
Si vous avez de la chance, c'est fini. Vous avez converti votre
ancienne traduction pour po4a et pouvez commencer la phase de mise
jour qui suit. Utiliser la procdure dcrite quelques sections auparavant
pour synchroniser votre fichier PO avec le nouveau document original,
et mettez jour votre traduction en consquence.
Veuillez noter que mme si tout semble s'tre bien pass, il reste une
possibilit que des erreurs se soient introduites au cours du processus.
En fait, po4a est incapable de vrifier que les chanes correspondent
l'original, et il marque toutes les chanes comme approximatives (fuzzy)
au cours de cette procdure. Vous devriez vrifier chacune d'elle
soigneusement avant de retirer ces marques.
Souvent, la structure du document ne correspond pas exactement, ce qui
empche po4a-gettextize de faire son travail correctement. Pour
contourner cela, vous pouvez diter les fichiers afin de faire
correspondre leur structure.
La section "Gettextization: Comment a marche?" ci-dessous pourra vous
aider. La comprhension du fonctionnement interne vous aidera raliser
cette tche. Par chance, po4a-gettextize est relativement bavard sur ce
qui s'est mal pass. Dans un premier temps, il indique o, dans les
documents, se trouve la diffrence des structures. Vous obtiendrez les
chanes qui ne correspondent pas, leur position dans le texte, et leur
type De plus, le fichier PO gnr ainsi sera crit dans
gettextization.failed.po.
- Retirez toutes les parties propres la traduction, telles que les
sections dans lesquelles vous avez indiqu le nom du traducteur et
les remerciements envers toutes les personnes qui ont contribu la
traduction. Les addenda qui sont dcrits dans la section suivante
vous permettront de les rajouter par la suite.
- N'hsitez pas diter les deux fichiers. Le plus important est
d'obtenir le fichier PO. Vous pourrez le mettre jour par la suite.
Cela dit, il est tout de mme prfrable d'diter la traduction quand
c'est possible, puisque a simplifiera les tapes suivantes.
- Si besoin, supprimez des parties de l'original s'il se trouve
qu'elles n'ont pas t traduites. Elles reviendront par la suite
lorsque vous synchroniserez le PO avec le document.
- Si vous avez un peu modifi la structure (pour combiner deux
paragraphes ou pour en dcouper un autre), enlevez ces
modifications. S'il y a des problmes avec l'original, vous devriez
en informer son auteur. Faire la correction dans votre traduction
n'en fait bnficier qu'une partie de la communaut. Et de plus, ce
n'est pas possible lorsque po4a est utilis.
- Parfois, le contenu des paragraphes correspond, mais pas leur type.
Corriger cela dpend du format. Pour les formats POD et man, cela
provient souvent du fait qu'un des deux contient une ligne
commenant par des espaces et pas l'autre. Pour ces formats, cela
signifie que ce paragraphe ne doit pas tre reformat, il a donc un
type diffrent. Retirez simplement les espaces et vous serez
tranquille. Il se peut aussi qu'il s'agisse d'une petite erreur
dans le nom d'une balise.
De la mme faon, deux paragraphes peuvent avoir t combins, dans le
format POD, si la ligne qui les spare contient des espaces, ou s'il
n'y a pas de ligne vide avant la ligne =item et le contenu de cet
lment.
- Il arrive galement qu'il se produise une dsynchronisation entre les
fichiers, et la traduction se retrouve alors attache au mauvais
paragraphe. C'est le signe que le problme se situe avant dans le
fichier. Consultez gettextization.failed.po pour voir quand la
dsynchronisation s'est produite, et corrigez-la.
- D'autres fois, vous aurez l'impression que po4a a oubli des parties
du texte original ou de la traduction. gettextization.failed.po
indique que les deux correspondent correctement, mais la
gettextization choue parce que po4a essaie de faire correspondre un
paragraphe avec le paragraphe suivant (ou prcdant) de celui qui
devrait lui tre associ, comme si celui-ci avait disparu. Vous
pesterez srement contre po4a comme je l'ai fait quand a m'est
arriv.
Cette situation malheureuse se manifeste quand un mme paragraphe
est rpt dans le document. Dans ce cas, aucune nouvelle entre n'est
cre dans le fichier PO, mais une nouvelle rfrence est ajoute
l'entre existante.
Donc, lorsque le mme paragraphe apparat deux fois dans l'original
mais n'est pas traduit exactement de la mme faon chaque fois, vous
aurez l'impression qu'un paragraphe de l'original a disparu.
Supprimez juste la seconde traduction. Si vous prfrez plutt
supprimer la premire traduction parce que la nouvelle traduction
est meilleure, enlevez la seconde de sa place et replacez-la la
place de la premire.
De la mme faon, si deux paragraphes lgrement diffrents ont t
traduits de faon identique, vous aurez l'impression qu'un
paragraphe de la traduction a disparu. Une solution consiste
ajouter une certaine chane dans le paragraphe du document original
(I'm different par exemple). Ne vous inquitez pas, ces
modifications disparatront pendant la synchronisation, et quand le
texte ajout est suffisamment court, gettext associera votre
traduction au texte existant de toute faon (en le marquant comme
approximatif (fuzzy), ce qui n'a pas d'importance puisque toutes
les chanes sont marques fuzzy aprs la gettextization).
Avec un peu de chance, ces astuces vous permettront de raliser la
gettextization et d'obtenir le prcieux PO. Vous serez alors prt pour
synchroniser votre fichier et commencer la traduction. Veuillez noter
que pour les gros fichiers, la synchronisation peut prendre beaucoup de
temps.
Par exemple, la premire excution de po4a-updatepo pour la traduction de
la documentation Perl (un fichier PO de 5,5 Mo) a pris presque deux
jours sur un G5 1GHz. Eh oui, 48 heures. Mais les mises jour
suivantes n'ont pris que quelques secondes sur un vieux portable. Ceci
parce que la premire fois, la plupart des msgid du PO ne correspondent
aucun dans le fichier POT. Ce qui oblige gettext rechercher la chane
la plus proche avec un algorithme de recherche coteux.
Comment ajouter des choses n'tant pas des traductions (comme le nom du
traducteur)?
Du fait de l'approche de type gettext, faire ceci est plus compliqu
avec po4a que a ne l'tait en ditant simplement le nouveau fichier et en
lisant l'original ct. Mais ceci reste possible en utilisant les
addenda.
Pour aider leur comprhension, on peut considrer les addenda comme des
sortes de rustines appliquer sur le document traduit la fin du
processus. Ils sont assez diffrents des rustines usuelles (il n'y a
qu'une seule ligne de contexte, qui peut contenir une expression
rationnelle Perl, et ne peuvent que rajouter du texte, sans en
enlever), mais la fonctionnalit qu'ils apportent est la mme.
Leur but est de permettre au traducteur d'ajouter au document du texte
qui ne soit pas une traduction, mais quelque chose de spcifique la
version traduite. De cette faon, ils peuvent ajouter une section
indiquant qui a particip cette traduction ou expliquer comment
rapporter des bogues de traduction.
Un addendum est fourni dans un fichier spar. La premire ligne constitue
un en-tte indiquant o le texte qu'il contient doit tre plac dans le
document. Le reste du fichier est ajout tel quel cette position dans
le document rsultant.
Les en-ttes ont une syntaxe relativement rigide: ils doivent commencer
par la chane PO4A-HEADER:, suivie par une liste de champs de la forme
clef=valeur spars par des points-virgules. Les espaces ONT leur
importance. Notez qu'il n'est pas possible d'utiliser de point-virgule
dans la valeur, mme en la plaant entre des guillemets.
Encore une fois, a parat peut-tre effrayant, mais les exemples ci-
dessous devraient vous aider crire les en-ttes dont vous avez besoin.
Supposons que nous voulons ajouter une section propos de cette
traduction aprs la section propos de ce document.
Voici les diffrentes clefs d'en-tte existantes:
position (obligatoire)
une expression rationnelle. L'addendum sera plac prs de la ligne
correspondant cette expression rationnelle. Notez qu'il s'agit ici
du document traduit, et non pas du document original. Si plus d'une
ligne correspond cette expression (ou si aucune ne correspond),
l'ajout chouera. Il est prfrable de donner un message d'erreur que
d'ajouter l'addendum au mauvais endroit.
La ligne est appele point de position par la suite. L'endroit o est
ajout l'addendum est appel point d'insertion. Ces deux points sont
proches, mais pas identiques. Par exemple, si vous voulez insrer
une nouvelle section, il est plus simple de placer le point de
position au niveau du titre de la section prcdente, et d'expliquer
po4a o se termine la section (souvenez-vous que le point de
position doit tre donn par une expression rationnelle ne
correspondant qu' une seule ligne.
La localisation du point d'insertion par rapport au point de
position est contrle par les champs "mode", "beginboundary" et
"endboundary", comme expliqu par la suite.
Dans notre cas, nous aurons:
position=<title> propos de ce document</title>
mode (obligatoire)
Le mode est soit before (avant) soit after (aprs). Il permet de
prciser la position de l'addendum par rapport au point d'ancrage.
Comme nous voulons placer la nouvelle section sous celle qui
correspond, nous utilisons:
mode=after
beginboundary (utilis uniquement avec mode=after, et obligatoire dans
ce cas)
endboundary (idem)
expression rationnelle correspondant la fin de la section aprs
laquelle l'addendum doit tre plac.
Lorsque le mode vaut after (aprs), le point d'insertion se trouvera
aprs le point de position, mais pas juste aprs! Il est plac la fin
de la section qui dbute par le point de position, c'est--dire aprs
la ligne correspondant l'expression rationnelle donne par le champ
"beginboundary" ou avant la ligne correspondant l'expression
rationnelle donne par le champ "endboundary".
Dans notre cas, nous pouvons choisir d'indiquer la fin de la
section qui doit correspondre en ajoutant:
endboundary=</section>
ou en indiquant le dbut de la section suivante en indiquant:
beginboundary=<section>
Dans les deux cas, notre addendum sera plac aprs </section> et
avant <section>. La premire solution est meilleure puisqu'elle
fonctionnera toujours, mme si le document est rorganis.
Les deux existent parce que les formats des documentations sont
diffrents. Dans certains d'entre eux, il est possible d'indiquer la
fin d'une section comme "</section>" que nous avons utilis), et
dans d'autres les fins de section ne sont pas spcifies
explicitement (c'est le cas du format man). Dans le premier cas, la
frontire (boundary) est la fin de section, et le point d'insertion
vient aprs. Dans le second cas, la frontire correspond au dbut de
la section suivante, et le point d'insertion vient juste avant.
Tout ceci peut sembler confus, mais l'exemple suivant devrait vous
clairer.
Pour rsumer l'exemple utilis, pour ajouter une section appele propos
de cette traduction aprs la section propos de ce document dans un
document SGML, vous pouvez utiliser une de ces lignes d'en-tte.
PO4A-HEADER: mode=after; position= propos de ce document; endboundary=</section>
PO4A-HEADER: mode=after; position= propos de ce document; beginboundary=<section>
Si vous voulez ajouter quelque chose aprs la section nroff suivante:
.SH "AUTEURS"
vous devez utiliser un champ "position" correspondant cette ligne,
et un champ "beginboundary" correspondant au dbut de la section
suivante (c'est--dire "^\.SH"). L'addendum sera plac aprs le point de
position et immdiatement avant la premire ligne correspondant au
champ "beginboundary". C'est--dire:
PO4A-HEADER:mode=after;position=AUTEURS;beginboundary=\.SH
Si vous voulez ajouter quelque chose une section (par exemple aprs
Copyright Tralala) au lieu d'ajouter une section entire, vous pouvez
fournir une "position" correspondant cette ligne, et un champ
"beginboundary" correspondant n'importe quelle ligne.
PO4A-HEADER:mode=after;position=Copyright Tralala, 2004;beginboundary=^
Si vous voulez ajouter quelque chose la fin du document, donnez une
position correspondant n'importe quelle ligne du document (mais une
seule ligne, puisque po4a n'acceptera pas que la position ne
corresponde pas une ligne unique), et donnez un champ "endboundary" ne
correspondant aucune ligne. N'utilisez pas de chane simple, comme FIN,
mais prfrez-en une qui a une chance moindre de se trouver dans votre
document.
PO4A-HEADER:mode=after;position=<title>Au sujet de...</title>;beginboundary=FausseLimitePo4a
Dans tous les cas, rappelez-vous qu'il s'agit d'une expression
rationnelle. Par exemple, si vous voulez pointer la fin d'une section
nroff qui se termine par la ligne:
.fi
N'utilisez pas ".fi" comme valeur pour endboundary, parce que cette
expression rationnelle correspond galement ce[fi]chier, ce qui n'est
videmment pas ce que vous voulez. La valeur du champ endboundary dans
ce cas est "^\.fi$".
Si l'addendum n'est pas positionn l o vous l'escomptiez, essayez en
fournissant l'option -vv aux outils, ce qui vous donnera des
indications sur ce qui est fait pour le placement de l'addendum.
Voici un exemple plus dtaill.
Document original (au format POD):
|=head1 NAME
|
|dummy - a dummy program
|
|=head1 AUTHOR
|
|me
Voici maintenant un addendum qui s'assure qu'une section est ajoute la
fin du fichier pour indiquer le traducteur.
|PO4A-HEADER:mode=after;position=AUTEUR;beginboundary=^=head
|
|=head1 TRADUCTEUR
|
|moi
De faon placer l'addendum avant l'AUTEUR (section nomme AUTHOR dans le
document original), utilisez l'en-tte suivant:
PO4A-HEADER:mode=after;position=NOM;beginboundary=^=head1
Ceci fonctionne parce que la premire ligne correspondant l'expression
rationnelle donne dans le champ beginboundary (/^=head1/) aprs la
section NOM (correspondant la section NAME dans le document original),
est celle indiquant les auteurs. De cette faon, l'addendum est plac
entre les deux sections.
Comment automatiser tout ceci?
L'utilisation de po4a s'est montre propice aux erreurs pour les
utilisateurs parce que deux programmes doivent tre appels dans le bon
ordre (po4a-updatepo puis po4a-translate), chacun d'eux prenant au
moins 3 paramtres. De plus, il tait difficile avec ce systme d'utiliser
un seul fichier PO pour tous les documents quand plusieurs formats
taient utiliss.
Le programme po4a(1) a t conu pour rpondre ces difficults. Une fois
que votre projet a t converti po4a, vous crivez un petit fichier de
configuration indiquant o se trouvent vos fichiers de traduction (les
fichiers PO et POT), o se trouvent les documents originaux, leurs
formats, et o doivent tre places leur traduction.
Ensuite, l'appel de po4a(1) avec ce fichier vrifie que les fichiers PO
sont synchroniss avec le document original, et que les documents
traduits sont gnrs correctement. Bien sr, il vous faudra appeler ce
programme deux fois: une fois avant l'dition des fichiers PO pour les
mettre jour et une autre fois aprs pour mettre jour les documents
traduits. Mais vous n'aurez qu' vous rappeler cette commande.
Comment personaliser po4a?
Les modules po4a ont des options (fournies l'aide de l'option -o) qui
peuvent tre utilises pour modifier le comportement du module.
Il est aussi possible de personaliser un module, d'ajouter de nouveaux
modules ou des modules drivs / modifis en plaant un module dans
lib/Locale/Po4a/ et en ajoutant lib aux chemins indiqus par les
variables d'environnement PERLLIB ou PERL5LIB. Par exemple:
PERLLIB=$PWD/lib po4a --previous po4a/po4a.cfg
Note: le nom du rpertoire lib n'est pas important.
Comment a marche?
Cette section vous donne un bref aperu des rouages internes de po4a
afin que vous vous sentiez plus mme de nous aider le maintenir et
l'amliorer. Elle peut galement vous permettre de comprendre pourquoi
cela ne fait pas ce que vous souhaitez et corriger vos problmes par
vous-mme.
Quel est le plan gnral ici?
L'architecture po4a est oriente objet (en Perl, n'est-ce pas
formidable?). L'anctre commun de tous les classes d'analyseur est appel
Transtractor. Ce nom trange provient du fait qu'il est la fois charg
de la traduction et de l'extraction des chanes du document.
Plus formellement, il prend un document traduire et un fichier PO
contenant les traductions en entre et produit en sortie deux autres
fichiers: un autre fichier PO (rsultant de l'extraction des chanes
traduire du document d'entre), et un document traduit (avec la mme
structure que le document d'entre, mais dont toutes les chanes
traduire ont t remplaces par leur traduction donne par le PO fournit en
entre). Voici une reprsentation graphique de tout ceci:
document entre --\ /---> document sortie
\ TransTractor:: / (traduit)
+-->-- parse() --------+
/ \
PO entre --------/ \---> PO sortie
(extrait)
Cette forme d'os est le coeur de l'architecture de po4a. Sans le
fichier PO en entre et le document en sortie, cela donne
po4a-gettextize. Si vous fournissez les deux entres et ignorez le PO de
sortie, vous aurez po4a-translate.
TransTractor::parse() est une fonction virtuelle implmente dans chaque
module. Voici un petit exemple pour montrer comment elle marche. Cet
exemple analyse une liste de paragraphes qui dbutent tous par <p>.
1 sub parse {
2 PARAGRAPH: while (1) {
3 $my ($paragraph,$pararef,$line,$lref)=("","","","");
4 $my $first=1;
5 while (($line,$lref)=$document->shiftline() && defined($line)) {
6 if ($line =~ m/<p>/ && !$first--; ) {
7 $document->unshiftline($line,$lref);
8
9 $paragraph =~ s/^<p>//s;
10 $document->pushline("<p>".$document->translate($paragraph,$pararef));
11
12 next PARAGRAPH;
13 } else {
14 $paragraph .= $line;
15 $pararef = $lref unless(length($pararef));
16 }
17 }
18 return; # Did not got a defined line? End of input file.
19 }
20 }
la ligne 6, <p> est rencontr pour la seconde fois. Cela indique le
passage un paragraphe suivant. Nous replaons donc la ligne, qui vient
juste d'tre obtenue, dans le document d'origine (ligne 7) et envoyons
le paragraphe ainsi construit dans les sorties. Aprs avoir retir le <p>
de tte en ligne 9, nous envoyons la concatnation de cette balise avec
la traduction du reste du paragraphe.
Cette fonction translate() est trs pratique. Elle envoie son paramtre
dans le fichier PO de sortie (l'extraction) et renvoie sa traduction
telle qu'elle a t trouve dans le fichier PO d'entre (la traduction).
Comme elle est utilise dans le paramtre de pushline(), cette traduction
se retrouve dans le document de sortie.
N'est-ce pas gnial? Il est possible de construire un module complet
pour po4a en moins de 20 lignes, si le format est suffisamment
simple...
Vous trouverez plus de dtails ce sujet dans
Locale::Po4a::TransTractor(3pm).
Gettextization: Comment a marche?
L'ide ici est de prendre la fois le document d'origine et sa
traduction, et de supposer que la nime chane extraite du document
traduit correspond
la traduction de la nime chane du document original. Pour que cela
fonctionne, il faut donc que les deux documents aient exactement la mme
structure. Par exemple, si les fichiers ont la structure suivante, il y
a trs peu de chance pour que la quatrime chane de la traduction (qui
est de type chapter) soit la traduction de la quatrime chane du
document original (de type paragraph).
Original Traduction
chapitre chapitre
paragraphe paragraphe
paragraphe paragraphe
paragraphe chapitre
chapitre paragraphe
paragraphe paragraphe
Pour cela, les analyseurs po4a sont utiliss la fois sur l'original et
sur la traduction pour extraire des fichiers PO, et un troisime fichier
PO est construit partir d'eux en utilisant les chanes du second comme
traductions des chanes du premier. Pour s'assurer que les chanes ainsi
associes sont bien les traductions, les analyseurs de po4a doivent
ajouter des informations sur le type syntaxique des chanes extraites du
document (les analyseurs existants le font, les vtres devraient
galement). Ensuite, ces informations sont utilises pour s'assurer que
les deux documents ont la mme syntaxe. Dans l'exemple prcdent, cela
permet de dtecter que la quatrime chane est dans un cas un paragraphe
et dans l'autre un titre de chapitre, et le problme est affich.
En thorie, il devrait tre possible de dtecter le problme, puis de
resynchroniser les fichiers par la suite (comme le fait diff). Mais il
est alors difficile de savoir quoi faire des chanes prcdant la
dsynchronisation, et le rsultat pourrait parfois ne pas tre bon. C'est
pourquoi l'implmentation actuelle ne resynchronise rien et choue avec
un message d'erreur complet quand quelque chose se passe mal, indiquant
qu'une modification manuelle des fichiers est ncessaire pour corriger
le problme.
Mme avec ces prcautions, des erreurs peuvent survenir. C'est la raison
pour laquelle toutes les traductions trouves de cette faon sont marques
fuzzy, pour s'assurer que le traducteur les relira et vrifiera.
Fonctionnement d'un Addendum
Bien, il n'y a rien de bien compliqu ici. La traduction n'est pas
directement crite sur le disque, mais est conserve en mmoire jusqu' ce
que tous les addenda soient ajouts. Les algorithmes utiliss sont assez
simples. Une ligne correspondant l'expression rationnelle de la
position est recherche, et l'addendum est ajout juste avant si
mode=before. Sinon, la premire ligne trouve partir de cette position
correspondant l'expression rationnelle donne par le champ boundary est
recherche et l'addendum est insr juste aprs cette ligne s'il s'agit
d'un "endboundary" ou juste avant s'il s'agit d'un "beginboundary".
FAQ
Cette section regroupe les questions le plus souvent poses. En fait, la
plupart d'entre elles sont des questions de design du projet. Si vous
pensez que po4a n'est pas la bonne rponse au problme de traduction de
documentation, lisez cette section avant de nous donner votre avis sur
la liste de diffusion <po4a-devel@lists.alioth.debian.org>. Votre avis
nous intresse.
Pourquoi traduire chaque paragraphe sparment?
En effet, avec po4a, tous les paragraphes sont traduits sparment (en
fait, c'est au choix de chaque module, mais tous les modules existants
font ainsi, et les vtres devraient galement). Il y a deux avantages
principaux cette approche:
o Quand les parties techniques du document sont masques, le traducteur
ne peut pas faire de btises avec. Moins nous prsentons de marqueurs
au traducteur, moins il pourra faire d'erreurs.
o Dcouper le document aide isoler les changements apparaissant dans le
document original. Lorsque l'original est modifi, la mise jour des
parties modifies est plus facile.
Mme avec ces avantages, certains n'aiment pas l'ide de traduire chaque
paragraphe sparment. Voici quelques rponses leurs inquitudes:
o Cette approche a t couronne de succs dans le cadre du projet KDE et a
permis de produire la plus grosse documentation traduite et mise
jour notre connaissance.
o Les traducteurs peuvent toujours utiliser le contexte pour traduire,
puisque les chanes du fichier PO se trouvent dans le mme ordre que
dans le document original. La traduction squentielle est donc
relativement comparable qu'elle soit faite avec ou sans po4a. Et dans
tous les cas, la meilleure faon reste de convertir le document dans
un format imprimable puisque les indications de formatage ne sont pas
vraiment lisibles.
o C'est l'approche utilise par les traducteurs professionnels. Mme si
je l'admets, leurs buts peuvent tre diffrents des traducteurs de
logiciels source ouvert. La maintenance tant par exemple souvent
moins critique puisque le contenu change rarement.
Pourquoi ne pas dcouper au niveau des phrases (ou un niveau plus petit)?
Les outils des traducteurs professionnels dcoupent parfois les
documents au niveau des phrases, de faon maximiser la rutilisation de
traductions prcdentes et acclrer leur travail. Le problme est qu'une
mme phrase peut avoir plusieurs traductions en fonction du contexte.
Les paragraphes sont par dfinition plus longs que les phrases. Cela
permet la plupart du temps d'assurer que deux paragraphes dans deux
documents diffrents auront le mme sens (et la mme traduction),
indpendamment du contexte.
Un dcoupage un niveau encore plus petit qu'une phrase pourrait tre trs
gnant. Ce serait un peu long d'expliquer pourquoi ici, mais les
lecteurs intresss pourront par exemple consulter la page de manuel
Locale::Maketext::TPJ13(3pm) (qui est fournie avec la documentation de
Perl). Pour faire court, chaque langue a ses propres rgles syntaxiques,
et il n'y a aucun moyen de construire des phrases partir de morceaux
de phrases pour toutes les langues existantes (ou pour les 5 10
langues les plus parles, et mme moins).
Pourquoi ne pas mettre la version originelle en commentaire avec la
traduction?
premire vue, gettext ne semble pas adapt tous les types de
traduction. Par exemple, il ne semblait pas adapt debconf, l'interface
que tous les paquets Debian utilisent pour l'interaction avec
l'utilisateur pendant l'installation. Dans ce cas, les textes traduire
taient assez courts (une dizaine de lignes pour chaque fichier), et il
tait difficile de placer la traduction dans un fichier spar parce qu'il
doit tre disponible avant l'installation du paquet.
C'est pourquoi les concepteurs de debconf ont dcid d'implmenter une
autre solution, plaant les traductions dans le mme fichier que
l'original. C'est une solution plutt sduisante. Certains voudront
galement faire ainsi pour les fichiers XML, par exemple. Voici quoi
cela ressemblerait:
<section>
<title lang="en">My title</title>
<title lang="fr">Mon titre</title>
<para>
<text lang="en">My text.</text>
<text lang="fr">Mon texte.</text>
</para>
</section>
Mais cette solution a t si problmatique que l'approche base sur PO est
dsormais utilise. Seul l'original peut tre dit dans le fichier, et les
traductions sont places dans des fichiers PO gnrs partir du modle
matre (et replacs au cours de la compilation). L'ancien systme a t
abandonn cause de plusieurs problmes:
o problmes de maintenance
Si plusieurs traducteurs fournissent une rustine (patch) au mme
moment, il est difficile de les appliquer ensemble.
Comment dtecter les modifications dans l'original qui doivent tre
appliques une traduction? Pour pouvoir utiliser diff, il faut
noter la version du document original traduit. C'est--dire qu'il
faut un fichier PO dans le fichier;)
o problmes d'encodage
Cette solution n'est envisageable que quand seules des langues
europennes sont impliques, mais la traduction pour le coren, le
russe ou l'arabe peuvent compliquer la situation. UTF peut tre une
solution, mais il y a galement des problmes avec.
De plus, ces problmes sont difficiles dtecter (c.--d. que seules
les personnes capables de lire le coren pourront s'apercevoir que
l'encodage pour le coren est dfectueux [ce qui aurait t caus par un
traducteur russe]).
gettext rsout tous ces problmes.
Mais gettext n'a pas t conu pour faire a!
C'est vrai, mais ce jour, personne n'a apport de meilleure solution.
La seule solution alternative est la traduction manuelle, avec tous les
problmes de maintenance qu'elle comporte.
Qu'en est-il des autres outils de traduction de documentation utilisant
gettext?
Il n'y en notre connaissance que deux:
poxml
C'est l'outil dvelopp au sein du projet KDE pour grer les
XMLDocBook. C'est notre connaissance le premier programme qui a
extrait des chanes traduire d'une documentation pour les mettre
dans un fichier PO, et les rinjecter ensuite dans le document aprs
la traduction.
Il ne peut grer que le format XML, avec une DTD particulire. Je
n'aime pas beaucoup la faon dont les listes sont gres: elles sont
rassembles en un seul gros msgid. Lorsque la liste est de taille
importante, les lments sont assez durs grer.
po-debiandoc
Ce programme crit par Denis Barbier est un prcurseur du module SGML
de po4a, qui le remplace plus ou moins. Comme son nom l'indique, il
ne gre que la DTD DebianDoc, qui est en voie d'extinction.
Le principal avantage de po4a par rapport eux est la facilit d'ajouter
du contenu additionnel (ce qui est encore plus difficile avec ces
outils) et la possibilit de faire une gettextization.
duquer les dveloppeurs au problme des traductions
Lors de la traduction de documentations ou de programmes, trois types
de difficults sont rencontrs; des problmes linguistiques (tout le monde
ne parle pas deux langues), des problmes techniques (la raison d'tre de
po4a) et des problmes de type relationnel et humain. Tous les
dveloppeurs ne voient pas la ncessit de raliser des traductions. Mme
avec la meilleure volont, ils peuvent aussi ignorer comment faciliter
le travail des traducteurs. C'est pour cela que po4a fournit une bonne
quantit de documentation que vous pouvez leur indiquer.
Un autre point important est que chaque fichier traduit contient un
petit commentaire indiquant ce qu'est le fichier et comment l'utiliser.
Ceci devrait aider les pauvres dveloppeurs inonds de tonnes de fichiers
contenant les traductions pour des langues qu'ils ne parlent quasiment
pas, et qui devrait les aider grer ces fichiers correctement.
Dans le projet po4a, les fichiers traduits ne sont plus des fichiers
source. Comme les fichiers SGML sont d'habitude des fichiers source,
ceci peut tre droutant. C'est pourquoi tous les fichiers contiennent un
en-tte similaire celui-ci:
| *****************************************************
| * GENERATED FILE, DO NOT EDIT *
| * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION *
| *****************************************************
|
| This file was generated by po4a-translate(1). Do not store it (in cvs,
| for example), but store the PO file used as source file by po4a-translate.
|
| In fact, consider this as a binary, and the PO file as a regular source file:
| If the PO gets lost, keeping this translation up-to-date will be harder ;)
De la mme faon, les fichiers PO usuels n'ont qu' tre copis dans le
rpertoire po/. Mais ce n'est pas le cas de ceux manipuls par po4a. Le
principal risque tant que le dveloppeur crase la traduction existante
de son programme avec la traduction de sa documentation. (Les deux ne
peuvent pas tre stockes dans le mme fichier PO parce que le programme
doit installer sa traduction en tant que fichier mo et que la
documentation n'a besoin de la traduction qu'au moment de la
compilation). C'est pourquoi les fichiers PO crs par le module po-
debiandoc contient l'en-tte suivant:
#
# ADVISES TO DEVELOPERS:
# - you do not need to manually edit POT or PO files.
# - this file contains the translation of your debconf templates.
# Do not replace the translation of your program with this !!
# (or your translators will get very upset)
#
# ADVISES TO TRANSLATORS:
# If you are not familiar with the PO format, gettext documentation
# is worth reading, especially sections dedicated to this format.
# For example, run:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Some information specific to po-debconf are available at
# /usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
RSUM des avantages de l'approche base sur gettext
o Les traductions ne sont pas stockes indpendamment de l'original, ce
qui rend possible la dtection des parties mettre jour.
o Les traductions sont stockes dans des fichiers diffrents pour chaque
langue, ce qui vite les interfrences entre traducteurs. Que ce soit
pour la soumission de rustines ou pour le choix d'un encodage.
o En interne, tout est bas sur "gettext" (mais "po4a" offre une
interface simple qui ne ncessite pas de comprendre comment a marche
en interne pour pouvoir l'utiliser). Ce qui permet de ne pas
rinventer la roue, et du fait de leur utilisation importante, nous
pouvons supposer qu'ils ont peu ou pas de bogue.
o Pour l'utilisateur final, rien ne change ( part que les
documentations seront probablement mieux maintenues:). La
documentation distribue reste la mme.
o Il n'est pas ncessaire pour les traducteurs d'apprendre une nouvelle
syntaxe et leur diteur de fichier PO prfr (qui peut tre le mode PO
d'Emacs, Lokalize ou Gtranslator) sera parfait.
o Gettext permet d'obtenir facilement des statistiques sur ce qui a t
fait, ce qui doit tre revu et mis jour, et sur ce qu'il reste
faire. Vous trouverez des exemples ces adresses:
- http://kv-53.narod.ru/kaider1.png
- http://www.debian.org/intl/l10n/
Mais tout n'est pas rose, et cette approche a aussi quelques
dsavantages que nous devons grer.
o Les addenda sont... surprenants au premier abord.
o Il n'est pas possible d'adapter le texte traduit votre got, comme de
dcomposer ou recomposer des paragraphes. Mais d'un autre ct, s'il
s'agit d'un problme dans le document original, celui-ci doit tre
signal de toute faon.
o Mme s'il a une interface simple, il reste un nouvel outil qu'il
faudra apprendre matriser.
Un de mes rves serait d'intgrer po4a Gtranslator ou Lokalize.
Lorsqu'un fichier SGML serait ouvert, ses chanes seraient extraites
automatiquement. Lors de l'enregistrement, le fichier SGML traduit
serait crit sur le disque. Si nous arrivons faire un module pour
MSWord (TM) (ou au moins pour le format RTF), des traducteurs
professionnels pourraient mme l'utiliser.
AUTEURS
Denis Barbier <barbier,linuxfr.org>
Martin Quinson (mquinson#debian.org)
