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 façon plus intéressante, la maintenance
des traductions) en utilisant les outils gettext dans des domaines pour
lesquels ils n'étaient pas destinés, comme la documentation.
Ce document est organisé de la manière suivante :
1 Pourquoi utiliser po4a ? A 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 fonctionnalités de po4a ?
Cette section est une sorte de manuel de référence qui cherche à
répondre aux questions des utilisateurs et qui vous donnera une
meilleure compréhension de son fonctionnement. Il vous donnera les
bases de l'utilisation de po4a et sert d'introduction à la
documentation des outils spécifiques.
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 système ?
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 aperçu des rouages internes de
po4a afin que vous vous sentiez plus à même de nous aider à le
maintenir et l'améliorer. Elle peut également vous permettre de
comprendre pourquoi cela ne fait pas ce que vous souhaitez et
corriger vos problèmes par vous-même.
4 FAQ
Cette section regroupe les questions le plus souvent posées. En
fait, la plupart d'entre elles sont des questions de design du
projet. Si vous pensez que po4a n'est pas la bonne réponse au
problème 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 intéresse.
5 Notes spécifiques à certains modules
Cette section présente les spécificités 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 règles
à 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 placée 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 accès au logiciel et à son code source. Mais, étant
moi-même français, je suis conscient que la licence n'est pas le seul
frein à l'ouverture d'un logiciel : les logiciels non traduits, même
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 problème par les acteurs du développement libre s'est
fortement accélérée récemment. Nous, les traducteurs, avons gagné une
première bataille et avons convaincu tout le monde de l'importance des
traductions. Mais c'est malheureusement la partie la plus facile. Il
faut maintenant réaliser tout le travail, traduire tous les documents.
Les logiciels aux sources ouverts bénéficient d'un niveau de traduction
relativement bon, grâce à la formidable suite d'outils gettext. Ces
outils permettent d'extraire les chaînes à traduire du programme, de
les présenter sous une forme standard pour les traducteurs, puis
d'utiliser le résultat de leur travail lors de l'exécution pour
afficher les messages traduits aux utilisateurs.
Mais cette situation est assez différente en ce qui concerne les
documentations. Trop souvent, la documentation traduite n'est pas assez
visible (pas distribuée avec le programme), seulement partielle ou pas
à jour. Cette dernière situation est de loin la moins bonne. Les
traductions pas à jour peuvent se révéler plus embêtantes pour les
utilisateurs que l'absence de traduction parce que d'anciens
comportements d'un programme peuvent y être décrits, mais ne plus être
en vigueur.
La problématique
La traduction des documentations n'est pas une tâche difficile en
elle-même. 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 détection des parties ayant été
modifiées (et nécessitant une mise à jour) est une tâche très
difficile, ce qui explique que tant de traductions ne correspondent
plus à la version originale.
La réponse de po4a
La maintenance de la traduction est donc la raison première de po4a. La
façon de faire de gettext a été réutilisée dans ce but. Comme avec
gettext, des chaînes de texte sont extraites de leur emplacement
d'origine de façon à être présentées de manière standardisée aux
traducteurs. Les outils de gettext sont ensuite utilisés pour aider le
traducteur à faire son travail lorsqu'une nouvelle version du document
est disponible. Mais, à la différence de l'utilisation classique de
gettext, les traductions sont réinjectée dans la structure du document
d'origine de façon à pouvoir les utiliser ou les distribuer comme les
documents de la version anglaise.
Grâce à ceci, la détection des parties du document qui nécessitent une
mise à jour est très facile. Un autre avantage est que l'outil va faire
une bonne partie du travail lorsque seule la structure du document a
été modifiée et que des chapitres ont été déplacés, rassemblés ou
redécoupés. En extrayant le texte à traduire de la structure du
document, il permet également de masquer la complexité de la mise en
page et réduit les chances d'avoir un document défectueux (même s'il
reste un risque).
Veuillez également consulter la FAQ plus bas dans ce document pour une
liste plus complète des avantages et inconvénients de cette approche.
Formats pris en charge
Actuellement, cette approche a été implémentée avec succès 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 très utile parce que
ce format est assez compliqué, surtout pour les débutants. Le module
Locale::Po4a::Man(3pm) supporte également le format mdoc, utilisé par
les pages de manuel BSD (également assez fréquentes sous Linux).
pod
C'est le format pour la documentation en ligne de Perl (Perl Online
Documentation). Le langage et ses documentations sont documentés de
cette façon, ainsi que la plupart des scripts Perl existants. Il permet
de garder la documentation plus fidèle au code en les intégrant tous
deux au même fichier. Il rend la vie du programmeur plus simple, mais
malheureusement pas celle du traducteur.
sgml
Même s'il est de plus en plus remplacé par le XML, ce format est encore
assez utilisé pour les documents dont la taille dépasse plusieurs
écrans. Il permet de faire des livres complets. La mise à jour de
documents aussi longs est un vrai cauchemar. diff(1) se montre souvent
inutile quand le document original a été réindenté après une mise à
jour. Heureusement, po4a vous aide dans cette tâche.
Actuellement, seules les DTDDebianDoc et DocBook sont prises en charge,
mais l'ajout d'une nouvelle est très facile. Il est même possible
d'utiliser po4a avec une DTDSGML inconnue sans modifier le code en
fournissant les informations nécessaires sur la ligne de commande.
Veuillez consulter Locale::Po4a::Sgml(3pm) pour plus de détails.
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 présentations.
texinfo
Toutes les documentations du projet GNU sont écrites dans ce format
(c'est même une des exigences pour devenir un projet officiel du projet
GNU). Le support pour Locale::Po4a::Texinfo(3pm) dans po4a en est
encore à ses débuts. 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.
A ce jour, la DTDDocBook est prise en charge par po4a. Veuillez
consulter Locale::Po4a::Docbook(3pm) pour plus de détails.
autres
Po4a peut également gérer des formats plus rares et plus spécifiques,
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 très simple et consiste principalement à
fournir un interpréteur pour le format voulu. Veuillez consulter
Locale::Po4a::TransTractor(3pm) pour plus d'informations à ce sujet.
Formats non supportés
Malheureusement, po4a ne supporte pas encore certains formats utilisés
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 laissées par les outils gettext classiques.
Cela va de la traduction de la documentation des descriptions des
paquets Debian et paquetages rpm, aux questions posées par les
scripts d'installation, en passant par les fichiers changelog, et de
tous les formats spécifiques tels que les scénarios de jeux ou les
fichiers de ressource pour wine.
Comment utiliser po4a ?
Cette section est une sorte de manuel de référence qui cherche à
répondre aux questions des utilisateurs et qui vous donnera une
meilleure compréhension de son fonctionnement. Il vous donnera les
bases de l'utilisation de po4a et sert d'introduction à la
documentation des outils spécifiques.
Résumé graphique
Le schéma suivant donne un aperçu du processus mis en oeuvre pour la
traduction de documents avec po4a. Ne soyez pas effrayés par son
apparente complexité, qui est due au fait que le processus complet y
est présent. Une fois que vous avez converti votre projet à po4a, seule
la partie de droite du graphique est utilisée.
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 détaillée 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 présent 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 automatisée par
po4a. Les nouvelles chaînes sont extraites et comparées avec la
traduction existante. Pour celles qui n'ont pas changé, la traduction
précédente est utilisée. Celles qui ont été en partie modifiées sont
également associées à leur ancienne traduction, mais avec un marquage
spécifique 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 opération manuelle consiste
en l'étape indiquée 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 présente les étapes nécessaires pour débuter une nouvelle
traduction avec po4a. Les modifications à appliquer pour la conversion
d'un projet existant sont détaillées 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
façon :
$ po4a-gettextize -f <format> -m <maitre.doc> -p <traduction.pot>
Naturellement, <format> est le format du document maitre.doc et la
sortie est placée dans traduction.pot. Veuillez consulter
po4a-gettextize(1) pour plus de détails concernant les options
existantes.
- Traduit réellement 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 français), puis éditer ce fichier. C'est souvent une bonne idée 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-têtes du fichier
PO, ils sont importants.
La traduction peut être réalisée avec emacs(1) et son mode PO ou
Lokalize (basé sur KDE) ou Gtranslator(1) (basé sur GNOME) ou encore
n'importe quel programme que vous préférez utiliser pour l'édition de
ces fichiers. Un bon vieux vi(1) fera l'affaire, même s'il n'y a pas
de mode spécial pour ce type de tâche.
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 effectuée, il faut générer la
documentation traduite et la distribuer avec l'original. Pour cela,
utilisez po4a-translate(1) de cette façon (XX représente le code de la
langue) :
$ po4a-translate -f <format> -m <maitre.doc> -p <doc.XX.po> -l <XX.doc>
Comme précédemment, <format> est le format du document maitre.doc. Mais
cette fois-ci, le fichier PO fourni en paramètre de l'option -p est un
fichier d'entrée. Il s'agit de votre traduction. La sortie se trouve
dans le fichier XX.doc.
Veuillez consulter po4a-translate(1) pour plus de détails.
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 détails.
Naturellement, les nouveaux paragraphes de ce document ne seront pas
traduits par magie dans le fichier "PO" par cette opération, et vous
devrez mettre à jour le fichier "PO" manuellement. De la même façon,
vous devrez vérifier les traductions des paragraphes qui ont été
légèrement modifiés. Pour vous assurer que vous n'en oubliez pas, ils
sont marqués 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 préféré.
Une fois que votre fichier "PO" est de nouveau à jour, sans aucune
chaîne non traduite ou marquée comme approximative (fuzzy), vous
pouvez générer un fichier de documentation traduit, comme expliqué dans
la section précdente.
Comment convertir une traduction pré-existante à ce système ?
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 général 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 entrée --\ /---> document sortie
\ TransTractor:: / (traduit)
+-->-- parse() --------+
/ \
PO entrée --------/ \---> 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 séparément ?
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 découper 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 très
génant. 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 ?
A 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é conçu 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 a à 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.
Eduquer les développeurs au problème 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 manipulés 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
#
Résumé des avantages de l'approche basée sur gettext
o Les traductions ne sont pas stockées indépendamment de l'original, ce
qui rend possible la détection des parties à mettre à jour.
o Les traductions sont stockées dans des fichiers différents pour
chaque langue, ce qui évite les interférences 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 nécessite pas de comprendre comment ça marche
en interne pour pouvoir l'utiliser). Ce qui permet de ne pas
réinventer 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 le fait que les
documentations seront probablement mieux maintenues :). La
documentation distribuée reste la même.
o Il n'est pas nécessaire 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
désavantages que nous devons gérer.
o Les addenda sont... surprenants au premier abord.
o Il n'est pas possible d'adapter le texte traduit à votre goût, comme
de décomposer ou recomposer des paragraphes. Mais d'un autre côté,
s'il s'agit d'un problème dans le document original, celui-ci doit
être signalé de toute façon.
o Même s'il a une interface simple, il reste un nouvel outil qu'il
faudra apprendre à maîtriser.
Un de mes rêves serait d'intégrer po4a à Gtranslator ou Lokalize.
Lorsqu'un fichier SGML serait ouvert, ses chaînes seraient extraites
automatiquement. Lors de l'enregistrement, le fichier SGML traduit
serait écrit sur le disque. Si nous arrivons à faire un module pour
Ms Word (TM) (ou au moins pour le format RTF), des traducteurs
professionnels pourraient même l'utiliser.
AUTEURS
Denis Barbier <barbier,linuxfr.org>
Martin Quinson (mquinson#debian.org)
