Provided by: po4a_0.41-1ubuntu1_all bug

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 facon plus interessante, la maintenance
       des traductions) en utilisant les outils gettext dans des domaines pour
       lesquels ils n'etaient pas destines, comme la documentation.

Table des mati`eres

       Ce document est organise de la maniere 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 a evaluer
           po4a pour vos traductions.

       2 Comment utiliser les fonctionnalites de po4a?
           Cette section est une sorte de manuel de reference qui cherche a
           repondre aux questions des utilisateurs et qui vous donnera une
           meilleure comprehension de son fonctionnement. Il vous donnera les
           bases de l'utilisation de po4a et sert d'introduction a la
           documentation des outils specifiques.

           Comment commencer une nouvelle traduction?
           Comment convertir la traduction en un fichier de documentation?
           Comment mettre a jour une traduction faite avec po4a?
           Comment convertir une traduction pre-existante a ce systeme?
           Comment ajouter des choses n'etant pas des traductions (comme le
           nom du traducteur)?
           Comment automatiser tout ceci?
           Comment personaliser po4a?
       3 Comment ca marche?
           Cette section vous donne un bref apercu des rouages internes de
           po4a afin que vous vous sentiez plus a meme de nous aider a le
           maintenir et l'ameliorer. Elle peut egalement vous permettre de
           comprendre pourquoi cela ne fait pas ce que vous souhaitez et
           corriger vos problemes par vous-meme.

       4 FAQ
           Cette section regroupe les questions le plus souvent posees. En
           fait, la plupart d'entre elles sont des questions de design du
           projet. Si vous pensez que po4a n'est pas la bonne reponse au
           probleme 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 interesse.

       5 Notes specifiques a certains modules
           Cette section presente les specificites 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 regles
           a 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 placee dans chaque documentation des modules. Ceci permet de
           s'assurer que les informations sont a jour en conservant la
           documentation et le code ensemble.

Pourquoi utiliser po4a? Dans quel domaine est-il bon?

       J'aime le concept des logiciels a sources ouverts, qui permettent de
       donner a tous un acces au logiciel et a son code source. Mais, etant
       moi-meme francais, je suis conscient que la licence n'est pas le seul
       frein a l'ouverture d'un logiciel: les logiciels non traduits, meme
       s'ils sont libres, sont sans aucune utilite pour ceux qui ne
       comprennent pas l'anglais, et il y a encore beaucoup de travail pour
       les rendre accessibles a vraiment tout le monde.

       La perception du probleme par les acteurs du developpement libre s'est
       fortement acceleree recemment. Nous, les traducteurs, avons gagne une
       premiere bataille et avons convaincu tout le monde de l'importance des
       traductions. Mais c'est malheureusement la partie la plus facile. Il
       faut maintenant realiser tout le travail et traduire tous les
       documents.

       Les logiciels aux sources ouverts beneficient d'un niveau de traduction
       relativement bon, grace a la formidable suite d'outils gettext. Ces
       outils permettent d'extraire les chaines a traduire du programme, de
       les presenter sous une forme standard pour les traducteurs, puis
       d'utiliser le resultat de leur travail lors de l'execution pour
       afficher les messages traduits aux utilisateurs.

       Mais cette situation est assez differente en ce qui concerne les
       documentations. Trop souvent, la documentation traduite n'est pas assez
       visible (pas distribuee avec le programme), seulement partielle ou pas
       a jour. Cette derniere situation est de loin la moins bonne. Les
       traductions pas a jour peuvent se reveler plus embetantes pour les
       utilisateurs que l'absence de traduction parce que d'anciens
       comportements d'un programme peuvent y etre decrits, mais ne plus etre
       en vigueur.

   La probl'ematique
       La traduction des documentations n'est pas une tache difficile en
       elle-meme. Les textes sont bien plus longs que les messages des
       programmes ce qui rend leur traduction plus longue, mais il n'y a
       aucune difficulte technique a faire ceci. La difficulte vient en fait
       de la maintenance de la traduction. La detection des parties ayant ete
       modifiees et necessitant une mise a jour est une tache tres difficile,
       ce qui explique que tant de traductions ne correspondent plus a la
       version originale.

   La r'eponse de po4a
       La maintenance de la traduction est donc la raison premiere de po4a. La
       facon de faire de gettext a ete reutilisee dans ce but. Comme avec
       gettext, des chaines de texte sont extraites de leur emplacement
       d'origine de facon a etre presentees de facon standardisee aux
       traducteurs. Les outils pour gettext sont ensuite utilises pour aider
       le traducteur a faire son travail lorsqu'une nouvelle version du
       document est disponible. Mais, a la difference de l'utilisation
       classique de gettext, les traductions sont reinjectee dans la structure
       du document d'origine de facon a pouvoir les utiliser ou les distribuer
       comme les documents de la version anglaise.

       Grace a ceci, la detection des parties du document qui necessitent une
       mise a jour est tres facile. Un autre avantage est que l'outil va faire
       une bonne partie du travail lorsque seule la structure du document a
       ete modifiee et que des chapitres ont ete deplaces, rassembles ou
       redecoupes. En extrayant le texte a traduire de la structure du
       document, il permet egalement de masquer la complexite de la mise en
       page et reduit les chances d'avoir un document defectueux (meme s'il
       reste un risque).

       Veuillez egalement consulter la FAQ plus bas dans ce document pour une
       liste plus complete des avantages et inconvenients de cette approche.

   Formats pris en charge
       Actuellement, cette approche a ete implementee avec succes pour un
       certain nombre de formats de mise en page de texte.

       man

       Le bon vieux format des pages de manuel, utilise par beaucoup de
       programmes. Le support de po4a pour ce format est tres utile parce que
       ce format est assez complique, surtout pour les debutants. Le module
       Locale::Po4a::Man(3pm) supporte egalement le format mdoc, utilise par
       les pages de manuel BSD (elles sont egalement assez frequentes sous
       Linux).

       pod

       C'est le format pour la documentation en ligne de Perl (<<Perl Online
       Documentation>>). Le langage et ses documentations sont documentes de
       cette facon, ainsi que la plupart des scripts Perl existants. Il permet
       de garder la documentation plus fidele au code en les integrant tous
       deux au meme fichier. Il rend la vie du programmeur plus simple, mais
       malheureusement pas celle du traducteur.

       sgml

       Meme s'il est de plus en plus remplace par le XML, ce format est encore
       assez utilise pour les documents dont la taille depasse plusieurs
       ecrans. Il permet de faire des livres complets. La mise a jours de
       documents aussi longs est un vrai cauchemar. diff se montre souvent
       inutile quand le document original a ete reindente apres une mise a
       jour. Heureusement, po4a vous aide dans cette tache.

       Actuellement, seules les DTDDebianDoc et DocBook sont prises en charge,
       mais l'ajout d'une nouvelle est tres facile. Il est meme possible
       d'utiliser po4a avec une DTDSGML inconnue sans modifier le code en
       fournissant les informations necessaires sur la ligne de commande.
       Veuillez consulter Locale::Po4a::Sgml(3pm) pour plus de details.

       TeX / LaTeX

       Le format LaTeX est un format majeur utilise pour les documentations
       dans le monde du logiciel libre ou pour des publications. Le module
       Locale::Po4a::LaTeX(3pm) a ete teste avec la documentation de Python,
       un livre et avec quelques presentations.

       texinfo

       Toutes les documentations du projet GNU sont ecrites dans ce format
       (c'est meme une des exigences pour devenir un projet officiel du projet
       GNU). Le support pour Locale::Po4a::Texinfo(3pm) dans po4a en est
       encore a ses debut. Veuillez nous envoyer des rapports de bogue ou des
       demandes de nouvelle fonctionnalite.

       xml

       Le format XML est a 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 details.

       autres

       Po4a peut egalement gerer des formats plus rares et plus specifiques,
       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 tres simple, et consiste principalement a
       fournir un interpreteur pour le format voulu. Veuillez consulter
       Locale::Po4a::TransTractor(3pm) pour plus d'informations a ce sujet.

   Formats non support'es
       Malheureusement, po4a ne supporte pas encore certains formats utilises
       pour les documentations.

       Il y a une quantite d'autres formats que nous aimerions supporter avec
       po4a, et pas seulement des formats de documentation. En fait, nous
       visons toutes les <<niches>> laissees par les outils gettext
       classiques. Cela va de la traduction de la documentation des
       descriptions des paquets Debian et paquetages rpm, aux les questions
       posees par les scripts d'installation, ex passant par les fichiers
       changelog, et de tous les formats specifiques tels que les scenarios de
       jeux ou les fichiers de ressource pour wine.

Comment utiliser po4a?

       Cette section est une sorte de manuel de reference qui cherche a
       repondre aux questions des utilisateurs et qui vous donnera une
       meilleure comprehension de son fonctionnement. Il vous donnera les
       bases de l'utilisation de po4a et sert d'introduction a la
       documentation des outils specifiques.

   R'esum'e graphique
       Le schema suivant donne un apercu du processus mis en oeuvre pour la
       traduction de documents avec po4a. Ne soyez pas effraye par son
       apparente complexite, qui est due au fait que le processus complet y
       est presente. Une fois que vous avez converti votre projet a po4a,
       seule la partie de droite du graphique est utilisee.

       Notez que ma^itre.doc est pris pour exemple de documentation a traduire
       et traduction.doc est la traduction correspondante. L'extension
       pourrait etre .pod, .xml ou .sgml en fonction du format. Chaque partie
       de la figure est detaillee dans les sections suivantes.

                                          maitre.doc
                                              |
                                              V
            +<-----<----+<-----<-----<--------+------->-------->-------+
            :           |                     |                        :
       {traduction}     |        { mise a 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
                 |              |  {edition manuelle}                  |
                 |              |           |                          |
                 V              |           V                          V
             doc.XX.po --->---->+<---<-- doc.XX.po    addendum     maitre.doc
             (initial)                   (a jour)   (optionnel)     (a jour)
                 :                          |            |             |
                 :                          V            |             |
                 +----->----->----->------> +            |             |
                                            |            |             |
                                            V            V             V
                                            +------>-----+------<------+
                                                         |
                                                         V
                                                  [po4a-translate]
                                                         |
                                                         V
                                                       XX.doc
                                                      (a jour)

       La partie gauche illustre la conversion d'une traduction n'utilisant
       pas po4a. En haut de la partie droite est presente ce qui est du
       ressort de l'auteur du document d'origine (la mise a jour de la
       documentation). Au milieu de la partie de droite se trouve la partie
       automatisee par po4a. Les nouvelles chaines sont extraites et comparees
       avec la traduction existante. Pour celles qui n'ont pas change, la
       traduction precedente est utilisee. Celles qui ont ete en partie
       modifiees sont egalement associees a leur ancienne traduction, mais
       avec un marquage specifique indiquant que la traduction doit etre mise
       a jour. La partie du bas indique comment le document formate est
       construit.

       En fait, en tant que traducteur, la seule operation manuelle consiste
       en l'etape indiquee par {edition manuelle}. En effet, nous nous en
       excusons, po4a aide a la traduction, mais il ne traduit rien pour
       vous...

   Comment commencer une nouvelle traduction?
       Cette section presente les etapes necessaires pour debuter une nouvelle
       traduction avec po4a. Les modifications a appliquer pour la conversion
       d'un projet existant sont detaillees dans la section correspondante.

       Voici les etapes permettant de commencer une traduction avec po4a:

       - Extraction du texte du document d'origine <maitre.doc> qui doit etre
         traduit dans <traduction.pot>, un nouveau fichier POT (le format
         utilise par gettext). Pour ceci, utilisez po4a-gettextize de cette
         facon:

           $ po4a-gettextize -f <format> -m <maitre.doc> -p <traduction.pot>

         Naturellement, <format> est le format du document ma^itre.doc et la
         sortie est placee dans traduction.pot. Veuillez consulter
         po4a-gettextize(1) pour plus de details concernant les options
         existantes.

       - Traduit reellement ce qui doit etre traduit. Pour cela, vous devez
         renommer le fichier POT en doc.XX.po (ou XX est le code ISO639 de la
         langue vers laquelle vous etes en train de traduire, c.-a-d. fr pour
         le francais), puis editer ce fichier. C'est souvent une bonne idee de
         ne pas nommer le fichier XX.po pour eviter de confondre ce fichier
         avec la traduction des messages du programme, mais vous faites comme
         vous voulez. N'oubliez pas de mettre a jour les en-tetes du fichier
         PO, ils sont importants.

         La traduction peut etre realisee avec Emacs et son mode PO ou
         Lokalize (base sur KDE) ou Gtranslator (base sur GNOME) ou encore
         n'importe quel programme que vous preferez utiliser pour l'edition de
         ces fichiers. Un bon vieux vi fera l'affaire, meme s'il n'y a pas de
         mode special pour ce type de tache.

         Si vous voulez en apprendre plus a 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 effectuee, il faut generer la
       documentation traduite et la distribuer avec l'original. Pour cela,
       utilisez po4a-translate(1) de cette facon (XX represente le code de la
       langue):

         $ po4a-translate -f <format> -m <maitre.doc> -p <doc.XX.po> -l <XX.doc>

       Comme precedemment, <format> est le format du document ma^itre.doc. Mais
       cette fois-ci, le fichier PO fourni en parametre de l'option -p est un
       fichier d'entree. Il s'agit de votre traduction. La sortie se trouve
       dans le fichier XX.doc.

       Veuillez consulter po4a-translate(1) pour plus de details.

   Comment mettre `a jour une traduction faite avec po4a?
       Pour mettre a jour votre traduction lorsque l'original ma^itre.doc a
       change, 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 details)

       Naturellement, les nouveaux paragraphes de ce document ne seront pas
       traduits par magie dans le fichier PO par cette operation, et vous
       devrez mettre a jour le fichier PO manuellement. De la meme facon, vous
       devrez verifier les traductions des paragraphes qui ont ete legerement
       modifies. Pour vous assurer que vous n'en oubliez pas, ils sont marques
       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 editeur de
       fichier PO prefere.

       Une fois que votre fichier PO est de nouveau a jour, sans aucune chaine
       non traduite ou marquee comme approximative (fuzzy), vous pouvez
       generer un fichier de documentation traduit, comme explique dans la
       section precedente.

   Comment convertir une traduction pr'e-existante `a ce syst`eme?
       Souvent, vous traduisez manuellement le document sans difficulte,
       jusqu'a ce qu'une reorganisation majeure du document d'origine
       ma^itre.doc apparaisse. Alors, apres quelques essais infructueux en
       utilisant diff ou des outils similaires, vous voulez convertir la
       traduction a po4a. Mais bien sur, vous ne souhaitez pas perdre votre
       traduction existante dans le meme temps. Pas de panique, ce cas est
       aussi gere par les outils de po4a et est appele gettextization.

       Le point important pour ceci est d'avoir la meme structure de document
       pour l'original et la version traduite, de facon a ce que les outils
       associent leur contenu correctement.

       Si vous avez de la chance (c.-a-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 preparer a une tache ingrate. Dans tous les cas, souvenez-
       vous que c'est le prix a payer pour beneficier du confort que po4a vous
       apportera par la suite. Le point positif est que vous n'aurez a faire
       cela qu'une seule fois.

       Ceci ne sera jamais repete suffisamment: afin de faciliter ce
       processus, il est tres important de trouver la version exacte qui a ete
       utilisee pour realiser la traduction. La meilleure situation est quand
       vous avez note la version VCS lors de la traduction.

       Ca ne fonctionnera pas tres bien si vous utilisez le document d'origine
       mis a jour avec l'ancienne traduction. Ca reste possible, mais sera
       plus complique et doit etre evite autant que possible. En fait, je
       pense que si vous n'arrivez pas a trouver le document original, la
       meilleure solution est de trouver quelqu'un pour faire la
       gettextization pour vous (mais, s'il vous plait, pas moi;).

       Je dramatise peut-etre un peu trop ici. Meme lorsque tout ne se passe
       pas bien, c'est bien plus rapide que de tout retraduire. J'ai pu
       realiser une gettextization de la traduction francaise de Perl en un
       jour, meme si les choses ne se sont pas bien passees. Il y avait plus
       de deux megaoctets de textes, et une nouvelle traduction aurait pris
       des mois.

       Voici d'abord la procedure, puis nous reviendrons sur les astuces qui
       permettent d'y parvenir avec succes lorsqu'il y a un probleme. Pour
       faciliter la comprehension, reutilisons encore une fois l'exemple
       precedent.

       Une fois que vous avez l'ancien ma^itre.doc correspondant a la
       traduction XX.doc, la gettextization peut etre faite directement dans
       le fichier PO 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 a
       jour qui suit. Utiliser la procedure decrite quelques sections
       auparavant pour synchroniser votre fichier PO avec le nouveau document
       original, et mettez a jour votre traduction en consequence.

       Veuillez noter que meme si tout semble s'etre bien passe, il reste une
       possibilite que des erreurs se soient introduites au cours du
       processus. En fait, po4a est incapable de verifier que les chaines
       correspondent a l'original, et il marque toutes les chaines comme
       approximatives (fuzzy) au cours de cette procedure. Vous devriez
       verifier chacune d'elle soigneusement avant de retirer ces marques.

       Souvent, la structure du document ne correspond pas exactement, ce qui
       empeche po4a-gettextize de faire son travail correctement. Pour
       contourner cela, vous pouvez editer les fichiers afin de faire
       correspondre leur structure.

       La section Gettextization: Comment ,ca marche? ci-dessous pourra vous
       aider. La comprehension du fonctionnement interne vous aidera a
       realiser cette tache. Par chance, po4a-gettextize est relativement
       bavard sur ce qui s'est mal passe. Dans un premier temps, il indique
       ou, dans les documents, se trouve la difference des structures. Vous
       obtiendrez les chaines qui ne correspondent pas, leur position dans le
       texte, et leur type De plus, le fichier PO genere ainsi sera ecrit dans
       gettextization.failed.po.

       -   Retirez toutes les parties propres a la traduction, telles que les
           sections dans lesquelles vous avez indique le nom du traducteur et
           les remerciements envers toutes les personnes qui ont contribue a
           la traduction. Les addenda qui sont decrits dans la section
           suivante vous permettront de les rajouter par la suite.

       -   N'hesitez pas a editer les deux fichiers. Le plus important est
           d'obtenir le fichier PO. Vous pourrez le mettre a jour par la
           suite. Cela dit, il est tout de meme preferable d'editer la
           traduction quand c'est possible, puisque ca simplifiera les etapes
           suivantes.

       -   Si besoin, supprimez des parties de l'original s'il se trouve
           qu'elles n'ont pas ete traduites. Elles reviendront par la suite
           lorsque vous synchroniserez le PO avec le document.

       -   Si vous avez un peu modifie la structure (pour combiner deux
           paragraphes ou pour en decouper un autre), enlevez ces
           modifications. S'il y a des problemes avec l'original, vous devriez
           en informer son auteur. Faire la correction dans votre traduction
           n'en fait beneficier qu'une partie de la communaute. Et de plus, ce
           n'est pas possible lorsque po4a est utilise.

       -   Parfois, le contenu des paragraphes correspond, mais pas leur type.
           Corriger cela depend du format. Pour les formats POD et man, cela
           provient souvent du fait qu'un des deux contient une ligne
           commencant par des espaces et pas l'autre. Pour ces formats, cela
           signifie que ce paragraphe ne doit pas etre reformate, il a donc un
           type different. 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 meme facon, deux paragraphes peuvent avoir ete combines, dans
           le format POD, si la ligne qui les separe contient des espaces, ou
           s'il n'y a pas de ligne vide avant la ligne =item et le contenu de
           cet element.

       -   Il arrive egalement qu'il se produise une desynchronisation entre
           les fichiers, et la traduction se retrouve alors attachee au
           mauvais paragraphe. C'est le signe que le probleme se situe avant
           dans le fichier. Consultez gettextization.failed.po pour voir quand
           la desynchronisation s'est produite, et corrigez-la.

       -   D'autres fois, vous aurez l'impression que po4a a oublie des
           parties du texte original ou de la traduction.
           gettextization.failed.po indique que les deux correspondent
           correctement, mais la gettextization echoue parce que po4a essaie
           de faire correspondre un paragraphe avec le paragraphe suivant (ou
           precedant) de celui qui devrait lui etre associe, comme si celui-ci
           avait disparu. Vous pesterez surement contre po4a comme je l'ai
           fait quand ca m'est arrive.

           Cette situation malheureuse se manifeste quand un meme paragraphe
           est repete dans le document. Dans ce cas, aucune nouvelle entree
           n'est creee dans le fichier PO, mais une nouvelle reference est
           ajoutee a l'entree existante.

           Donc, lorsque le meme paragraphe apparait deux fois dans l'original
           mais n'est pas traduit exactement de la meme facon chaque fois,
           vous aurez l'impression qu'un paragraphe de l'original a disparu.
           Supprimez juste la seconde traduction. Si vous preferez plutot
           supprimer la premiere traduction parce que la nouvelle traduction
           est meilleure, enlevez la seconde de sa place et replacez-la a la
           place de la premiere.

           De la meme facon, si deux paragraphes legerement differents ont ete
           traduits de facon identique, vous aurez l'impression qu'un
           paragraphe de la traduction a disparu. Une solution consiste a
           ajouter une certaine chaine dans le paragraphe du document original
           (<<I'm different>> par exemple). Ne vous inquietez pas, ces
           modifications disparaitront pendant la synchronisation, et quand le
           texte ajoute est suffisamment court, gettext associera votre
           traduction au texte existant de toute facon (en le marquant comme
           approximatif (fuzzy), ce qui n'a pas d'importance puisque toutes
           les chaines sont marquees fuzzy apres la gettextization).

       Avec un peu de chance, ces astuces vous permettront de realiser la
       gettextization et d'obtenir le precieux PO. Vous serez alors pret 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 premiere execution 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 a 1GHz. Eh oui, 48 heures. Mais les mises a jour
       suivantes n'ont pris que quelques secondes sur un vieux portable. Ceci
       parce que la premiere fois, la plupart des msgid du PO ne correspondent
       a aucun dans le fichier POT. Ce qui oblige gettext a rechercher la
       chaine la plus proche avec un algorithme de recherche couteux.

   Comment ajouter des choses n''etant pas des traductions (comme le nom du
       traducteur)?
       Du fait de l'approche de type gettext, faire ceci est plus complique
       avec po4a que ca ne l'etait en editant simplement le nouveau fichier et
       en lisant l'original a cote. Mais ceci reste possible en utilisant les
       <<addenda>>.

       Pour aider a leur comprehension, on peut considerer les addenda comme
       des sortes de rustines a appliquer sur le document traduit a la fin du
       processus. Ils sont assez differents 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 fonctionnalite qu'ils apportent est la meme.

       Leur but est de permettre au traducteur d'ajouter au document du texte
       qui ne soit pas une traduction, mais quelque chose de specifique a la
       version traduite. De cette facon, ils peuvent ajouter une section
       indiquant qui a participe a cette traduction ou expliquer comment
       rapporter des bogues de traduction.

       Un addendum est fourni dans un fichier separe. La premiere ligne
       constitue un en-tete indiquant ou le texte qu'il contient doit etre
       place dans le document. Le reste du fichier est ajoute tel quel a cette
       position dans le document resultant.

       Les en-tetes ont une syntaxe relativement rigide: ils doivent commencer
       par la chaine PO4A-HEADER:, suivie par une liste de champs de la forme
       clef=valeur separes par des points-virgules. Les espaces sont
       importants. Notez qu'il n'est pas possible d'utiliser de point-virgule
       dans la valeur, meme en la placant entre des guillemets.

       Encore une fois, ca parait peut-etre effrayant, mais les exemples ci-
       dessous devraient vous aider a ecrire les en-tetes dont vous avez
       besoin. Supposons que nous voulons ajouter une section <<A propos de
       cette traduction>> apres la section <<A propos de ce document>>.

       Voici les differentes clefs d'en-tete existantes:

       position (obligatoire)
           une expression rationnelle. L'addendum sera place pres de la ligne
           correspondant a cette expression rationnelle. Notez qu'il s'agit
           ici du document traduit, et non pas du document original. Si plus
           d'une ligne correspond a cette expression (ou si aucune ne
           correspond), l'ajout echouera. Il est preferable de donner un
           message d'erreur que d'ajouter l'addendum au mauvais endroit.

           La ligne est appelee point de position par la suite. L'endroit ou
           est ajoute l'addendum est appele point d'insertion. Ces deux points
           sont proches, mais pas identiques. Par exemple, si vous voulez
           inserer une nouvelle section, il est plus simple de placer le point
           de position au niveau du titre de la section precedente, et
           d'expliquer a po4a ou se termine la section (souvenez-vous que le
           point de position doit etre donne par une expression rationnelle ne
           correspondant qu'a une seule ligne.

           La localisation du point d'insertion par rapport au point de
           position est controlee par les champs mode, beginboundary et
           endboundary, comme explique par la suite.

           Dans notre cas, nous aurons:

                position=<title>A propos de ce document</title>

       mode (obligatoire)
           Le mode est soit before (avant) soit after (apres). Il permet de
           preciser 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 (utilise uniquement avec mode=after, et obligatoire dans
       ce cas)
       endboundary (idem)
           expression rationnelle correspondant a la fin de la section apres
           laquelle l'addendum doit etre place.

           Lorsque le mode vaut after (apres), le point d'insertion se
           trouvera apres le point de position, mais pas juste apres! Il est
           place a la fin de la section qui debute par le point de position,
           c'est-a-dire apres la ligne correspondant a l'expression
           rationnelle donnee par le champ beginboundary ou avant la ligne
           correspondant a l'expression rationnelle donnee 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 debut de la section suivante en indiquant:

              beginboundary=<section>

           Dans les deux cas, notre addendum sera place apres </section> et
           avant <section>. La premiere solution est meilleure puisqu'elle
           fonctionnera toujours, meme si le document est reorganise.

           Les deux existent parce que les formats des documentations sont
           differents. Dans certains d'entre eux, il est possible d'indiquer
           la fin d'une section comme </section> que nous avons utilise), et
           dans d'autres les fins de section ne sont pas specifiees
           explicitement (c'est le cas du format man). Dans le premier cas, la
           <<frontiere>> (boundary) est la fin de section, et le point
           d'insertion vient apres. Dans le second cas, la fronti`ere
           correspond au d'ebut de la section suivante, et le point d'insertion
           vient juste avant.

       Tout ceci peut sembler confus, mais l'exemple suivant devrait vous
       eclairer.

       Pour resumer l'exemple utilise, pour ajouter une section appelee <<A
       propos de cette traduction>> apres la section <<A propos de ce
       document>> dans un document SGML, vous pouvez utiliser une de ces
       lignes d'en-tete.
          PO4A-HEADER: mode=after; position=A propos de ce document; endboundary=</section>
          PO4A-HEADER: mode=after; position=A propos de ce document; beginboundary=<section>

       Si vous voulez ajouter quelque chose apres la section nroff suivante:
           .SH "AUTEURS"

         vous devez utiliser un champ position correspondant a cette ligne, et
         un champ beginboundary correspondant au debut de la section suivante
         (c'est-a-dire ^\.SH). L'addendum sera place apr`es le point de
         position et immediatement avant la premiere ligne correspondant au
         champ beginboundary. C'est-a-dire:

          PO4A-HEADER:mode=after;position=AUTEURS;beginboundary=\.SH

       Si vous voulez ajouter quelque chose a une section (par exemple apres
       <<Copyright Tralala>>) au lieu d'ajouter une section entiere, vous
       pouvez fournir une position correspondant a cette ligne, et un champ
       beginboundary correspondant a n'importe quelle ligne.
          PO4A-HEADER:mode=after;position=Copyright Tralala, 2004;beginboundary=^

       Si vous voulez ajouter quelque chose a la fin du document, donnez une
       position correspondant a n'importe quelle ligne du document (mais a une
       seule ligne, puisque po4a n'acceptera pas que la position ne
       corresponde pas a une ligne unique), et donnez un champ endboundary ne
       correspondant a aucune ligne. N'utilisez pas de chaine simple, comme
       "EOF", mais preferez-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 egalement a <<ce[fi]chier>>, ce qui
       n'est evidemment pas ce que vous voulez. La valeur du champ endboundary
       dans ce cas est ^\.fi$.

       Si l'addendum n'est pas positionne la ou 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 d'etaill'e.

       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 ajoutee a
       la fin du fichier pour indiquer le traducteur.

        |PO4A-HEADER:mode=after;position=AUTEUR;beginboundary=^=head
        |
        |=head1 TRADUCTEUR
        |
        |moi

       De facon a placer l'addendum avant l'AUTEUR (section nommee AUTHOR dans
       le document original), utilisez l'en-tete suivant:

        PO4A-HEADER:mode=after;position=NOM;beginboundary=^=head1

       Ceci fonctionne parce que la premiere ligne correspondant a
       l'expression rationnelle donnee dans le champ beginboundary (/^=head1/)
       apres la section <<NOM>> (correspondant a la section <<NAME>> dans le
       document original), est celle indiquant les auteurs. De cette facon,
       l'addendum est place entre les deux sections.

   Comment automatiser tout ceci?
       L'utilisation de po4a s'est montree propice aux erreurs pour les
       utilisateurs parce que deux programmes doivent etre appeles dans le bon
       ordre (po4a-updatepo puis po4a-translate), chacun d'eux prenant au
       moins troisparametres. De plus, il etait difficile avec ce systeme
       d'utiliser un seul fichier PO pour tous les documents quand plusieurs
       formats etaient utilises.

       Le programme po4a(1) a ete concu pour repondre a ces difficultes. Une
       fois que votre projet a ete converti a po4a, vous ecrivez un petit
       fichier de configuration indiquant ou se trouvent vos fichiers de
       traduction (les fichiers PO et POT), ou se trouvent les documents
       originaux, leurs formats, et ou doivent etre placees leur traduction.

       Ensuite, l'appel de po4a(1) avec ce fichier verifie que les fichiers PO
       sont synchronises avec le document original, et que les documents
       traduits sont generes correctement. Bien sur, il vous faudra appeler ce
       programme deux fois: une fois avant l'edition des fichiers PO pour les
       mettre a jour et une autre fois apres pour mettre a jour les documents
       traduits. Mais vous n'aurez qu'a vous rappeler cette commande.

   Comment personaliser po4a?
       Les modules po4a ont des options (fournies a l'aide de l'option -o) qui
       peuvent etre utilisees pour modifier le comportement du module.

       Il est aussi possible de personaliser un module, d'ajouter de nouveaux
       modules ou des modules derives / modifies en placant un module dans
       lib/Locale/Po4a/ et en ajoutant lib aux chemins indiques par les
       variables d'environnement PERLLIB ou PERL5LIB. Par exemple:

          PERLLIB=$PWD/lib po4a --previous po4a/po4a.cfg

       Note: le nom du repertoire <<lib>> n'est pas important.

Comment ,ca marche?

       Cette section vous donne un bref apercu des rouages internes de po4a
       afin que vous vous sentiez plus a meme de nous aider a le maintenir et
       l'ameliorer. Elle peut egalement vous permettre de comprendre pourquoi
       cela ne fait pas ce que vous souhaitez et corriger vos problemes par
       vous-meme.

   Quel est le plan g'en'eral ici?
       L'architecture po4a est orientee objet (en Perl, n'est-ce pas
       formidable?). L'ancetre commun de tous les classes d'analyseur est
       appele Transtractor. Ce nom etrange provient du fait qu'il est a la
       fois charge de la traduction et de l'extraction des chaines du
       document.

       Plus formellement, il prend un document a traduire et un fichier PO
       contenant les traductions en entree et produit en sortie deux autres
       fichiers: un autre fichier PO (resultant de l'extraction des chaines a
       traduire du document d'entree), et un document traduit (avec la meme
       structure que le document d'entree, mais dont toutes les chaines a
       traduire ont ete remplacees par leur traduction donnee par le PO
       fournit en entree). Voici une representation graphique de tout ceci:

         document entree --\                             /---> document sortie
                            \      TransTractor::       /       (traduit)
                             +-->--   parse()  --------+
                            /                           \
         PO entree --------/                             \---> PO sortie
                                                                (extrait)

       Cette forme d'os est le coeur de l'architecture de po4a. Sans le
       fichier PO en entree et le document en sortie, cela donne
       po4a-gettextize. Si vous fournissez les deux entrees et ignorez le PO
       de sortie, vous aurez po4a-translate.

       TransTractor::parse() est une fonction virtuelle implementee dans
       chaque module. Voici un petit exemple pour montrer comment elle
       fonctionne. Cet exemple analyse une liste de paragraphes qui debutent
       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 }

       A la ligne 6, <p> est rencontre pour la seconde fois. Cela indique le
       passage un paragraphe suivant. Nous replacons donc la ligne, qui vient
       juste d'etre obtenue, dans le document d'origine (ligne 7) et envoyons
       le paragraphe ainsi construit dans les sorties. Apres avoir retire le
       <p> de tete en ligne 9, nous envoyons la concatenation de cette balise
       avec la traduction du reste du paragraphe.

       Cette fonction translate() est tres pratique. Elle envoie son parametre
       dans le fichier PO de sortie (l'extraction) et renvoie sa traduction
       telle qu'elle a ete trouvee dans le fichier PO d'entree (la
       traduction). Comme elle est utilisee dans le parametre de pushline(),
       cette traduction se retrouve dans le document de sortie.

       N'est-ce pas genial? 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 details a ce sujet dans
       Locale::Po4a::TransTractor(3pm).

   Gettextization: Comment ,ca marche?
       L'idee ici est de prendre a la fois le document d'origine et sa
       traduction, et de supposer que la enieme chaine extraite du document
       traduit correspond a la traduction de la enieme chaine du document
       original. Pour que cela fonctionne, il faut donc que les deux documents
       aient exactement la meme structure. Par exemple, si les fichiers ont la
       structure suivante, il y a tres peu de chance pour que la quatrieme
       chaine de la traduction (qui est de type <<chapitre>>) soit la
       traduction de la quatrieme chaine du document original (de type
       <<paragraphe>>).

           Original         Traduction

         chapitre            chapitre
           paragraphe          paragraphe
           paragraphe          paragraphe
           paragraphe        chapitre
         chapitre              paragraphe
           paragraphe          paragraphe

       Pour cela, les analyseurs po4a sont utilises a la fois sur l'original
       et sur la traduction pour extraire des fichiers PO, et un troisieme
       fichier PO est construit a partir d'eux en utilisant les chaines du
       second comme traductions des chaines du premier. Pour s'assurer que les
       chaines ainsi associees sont bien les traductions, les analyseurs de
       po4a doivent ajouter des informations sur le type syntaxique des
       chaines extraites du document (les analyseurs existants le font, les
       votres devraient egalement). Ensuite, ces informations sont utilisees
       pour s'assurer que les deux documents ont la meme syntaxe. Dans
       l'exemple precedent, cela permet de detecter que la quatrieme chaine
       est dans un cas un paragraphe et dans l'autre un titre de chapitre, et
       le probleme est affiche.

       En theorie, il devrait etre possible de detecter le probleme, puis de
       resynchroniser les fichiers par la suite (comme le fait diff). Mais il
       est alors difficile de savoir quoi faire des chaines precedant la
       desynchronisation, et le resultat pourrait parfois ne pas etre bon.
       C'est pourquoi l'implementation actuelle ne resynchronise rien et
       echoue avec un message d'erreur complet quand quelque chose se passe
       mal, indiquant qu'une modification manuelle des fichiers est necessaire
       pour corriger le probleme.

       Meme avec ces precautions, des erreurs peuvent survenir. C'est la
       raison pour laquelle toutes les traductions trouvees de cette facon
       sont marquees fuzzy, pour s'assurer que le traducteur les relira et
       verifiera.

   Fonctionnement d'un Addendum
       Bien, il n'y a rien de bien complique ici. La traduction n'est pas
       directement ecrite sur le disque, mais est conservee en memoire jusqu'a
       ce que tous les addenda soient ajoutes. Les algorithmes utilises sont
       assez simples. Une ligne correspondant a l'expression rationnelle de la
       position est recherchee, et l'addendum est ajoute juste avant si
       mode=before. Sinon, la premiere ligne trouvee a partir de cette
       position correspondant a l'expression rationnelle donnee par le champ
       boundary est recherchee et l'addendum est insere juste apres 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 posees. En fait,
       la plupart d'entre elles sont des questions de design du projet. Si
       vous pensez que po4a n'est pas la bonne reponse au probleme 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 interesse.

   Pourquoi traduire chaque paragraphe s'epar'ement?
       En effet, avec po4a, tous les paragraphes sont traduits separement (en
       fait, c'est au choix de chaque module, mais tous les modules existants
       font ainsi, et les votres devraient egalement). Il y a deux avantages
       principaux a cette approche:

       o Quand les parties techniques du document sont masquees, le traducteur
         ne peut pas faire de betises avec. Moins nous presentons de marqueurs
         au traducteur, moins il pourra faire d'erreurs.

       o Decouper le document aide a isoler les changements apparaissant dans
         le document original. Lorsque l'original est modifie, la mise a jour
         des parties modifiees est plus facile.

       Meme avec ces avantages, certains n'aiment pas l'idee de traduire
       chaque paragraphe separement. Voici quelques reponses a leurs
       inquietudes:

       o Cette approche a ete couronnee de succes dans le cadre du projet KDE
         et a permis de produire la plus grosse documentation traduite et mise
         a jour a notre connaissance.

       o Les traducteurs peuvent toujours utiliser le contexte pour traduire,
         puisque les chaines du fichier PO se trouvent dans le meme ordre que
         dans le document original. La traduction sequentielle est donc
         relativement comparable qu'elle soit faite avec ou sans po4a. Et dans
         tous les cas, la meilleure facon reste de convertir le document dans
         un format imprimable puisque les indications de formatage ne sont pas
         vraiment lisibles.

       o C'est l'approche utilisee par les traducteurs professionnels. Meme si
         je l'admets, leurs buts peuvent etre differents des traducteurs de
         logiciels a source ouvert. La maintenance etant par exemple souvent
         moins critique puisque le contenu change rarement.

   Pourquoi ne pas d'ecouper au niveau des phrases (ou `a un niveau plus petit)?
       Les outils des traducteurs professionnels decoupent parfois les
       documents au niveau des phrases, de facon a maximiser la reutilisation
       de traductions precedentes et a accelerer leur travail. Le probleme est
       qu'une meme phrase peut avoir plusieurs traductions en fonction du
       contexte.

       Les paragraphes sont par definition plus longs que les phrases. Cela
       permet la plupart du temps d'assurer que deux paragraphes dans deux
       documents differents auront le meme sens (et la meme traduction),
       independamment du contexte.

       Un decoupage a un niveau encore plus petit qu'une phrase pourrait etre
       tr`es g^enant. Ce serait un peu long d'expliquer pourquoi ici, mais les
       lecteurs interesses 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 regles
       syntaxiques, et il n'y a aucun moyen de construire des phrases a partir
       de morceaux de phrases pour toutes les langues existantes (ou pour les
       5 a 10 langues les plus parlees, et meme moins).

   Pourquoi ne pas mettre la version originelle en commentaire avec la
       traduction?
       A premiere vue, gettext ne semble pas adapte a tous les types de
       traduction. Par exemple, il ne semblait pas adapte a debconf,
       l'interface que tous les paquets Debian utilisent pour l'interaction
       avec l'utilisateur pendant l'installation. Dans ce cas, les textes a
       traduire etaient assez courts (une dizaine de lignes pour chaque
       fichier), et il etait difficile de placer la traduction dans un fichier
       separe parce qu'il doit etre disponible avant l'installation du paquet.

       C'est pourquoi les concepteurs de debconf ont decide d'implementer une
       autre solution, placant les traductions dans le meme fichier que
       l'original. C'est une solution plutot seduisante. Certains voudront
       egalement faire ainsi pour les fichiers XML, par exemple. Voici a 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 ete si problematique que l'approche basee sur PO
       est desormais utilisee. Seul l'original peut etre edite dans le
       fichier, et les traductions sont placees dans des fichiers PO generes a
       partir du modele maitre (et replaces au cours de la compilation).
       L'ancien systeme a ete abandonne a cause de plusieurs problemes:

       o   problemes de maintenance

           Si plusieurs traducteurs fournissent une rustine (patch) au meme
           moment, il est difficile de les appliquer ensemble.

           Comment detecter les modifications dans l'original qui doivent etre
           appliquees a une traduction? Pour pouvoir utiliser diff, il faut
           noter la version du document original traduit. C'est-a-dire qu'il
           faut un fichier PO dans le fichier;)

       o   problemes d'encodage

           Cette solution n'est envisageable que quand seules des langues
           europeennes sont impliquees, mais la traduction pour le coreen, le
           russe ou l'arabe peuvent compliquer la situation. UTF peut etre une
           solution, mais il y a egalement des problemes avec.

           De plus, ces problemes sont difficiles a detecter (c.-a-d. que
           seules les personnes capables de lire le coreen pourront
           s'apercevoir que l'encodage pour le coreen est defectueux [ce qui
           aurait ete cause par un traducteur russe]).

       gettext resout tous ces problemes.

   Mais gettext n'a pas 'et'e con,cu pour faire ,ca!
       C'est vrai, mais a ce jour, personne n'a apporte de meilleure solution.
       La seule solution alternative est la traduction manuelle, avec tous les
       problemes 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 developpe au sein du projet KDE pour gerer les
           XMLDocBook. C'est a notre connaissance le premier programme qui a
           extrait des chaines a traduire d'une documentation pour les mettre
           dans un fichier PO, et les reinjecter ensuite dans le document
           apres la traduction.

           Il ne peut gerer que le format XML, avec une DTD particuliere. Je
           n'aime pas beaucoup la facon dont les listes sont gerees: elles
           sont rassemblees en un seul gros msgid. Lorsque la liste est de
           taille importante, les elements sont assez durs a gerer.

       po-debiandoc
           Ce programme ecrit par Denis Barbier est un precurseur du module
           SGML de po4a, qui le remplace plus ou moins. Comme son nom
           l'indique, il ne gere que la DTD DebianDoc, qui est en voie
           d'extinction.

       Le principal avantage de po4a par rapport a eux est la facilite
       d'ajouter du contenu additionnel (ce qui est encore plus difficile avec
       ces outils) et la possibilite de faire une gettextization.

   'Eduquer les d'eveloppeurs au probl`eme des traductions
       Lors de la traduction de documentations ou de programmes, trois types
       de difficultes sont rencontres; des problemes linguistiques (tout le
       monde ne parle pas deux langues), des problemes techniques (la raison
       d'etre de po4a) et des problemes de type relationnel et humain. Tous
       les developpeurs ne voient pas la necessite de realiser des
       traductions. Meme avec la meilleure volonte, ils peuvent aussi ignorer
       comment faciliter le travail des traducteurs. C'est pour cela que po4a
       fournit une bonne quantite 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 developpeurs inondes de tonnes de
       fichiers contenant les traductions pour des langues qu'ils ne parlent
       quasiment pas, et qui devrait les aider a gerer 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 etre deroutant. C'est pourquoi tous les fichiers contiennent
       un en-tete similaire a 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 VCS,
        | 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 meme facon, les fichiers PO usuels n'ont qu'a etre copies dans le
       repertoire po/. Mais ce n'est pas le cas de ceux manipul'es par po4a. Le
       principal risque etant que le developpeur ecrase la traduction
       existante de son programme avec la traduction de sa documentation. (Les
       deux ne peuvent pas etre stockees dans le meme 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 crees par le module po-
       debiandoc contient l'en-tete 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'ESUM'E des avantages de l'approche bas'ee sur gettext
       o Les traductions ne sont pas stockees independamment de l'original, ce
         qui rend possible la detection des parties a mettre a jour.

       o Les traductions sont stockees dans des fichiers differents pour
         chaque langue, ce qui evite les interferences entre traducteurs. Que
         ce soit pour la soumission de rustines ou pour le choix d'un
         encodage.

       o En interne, tout est base sur gettext (mais po4a offre une interface
         simple qui ne necessite pas de comprendre comment ca marche en
         interne pour pouvoir l'utiliser). Ce qui permet de ne pas reinventer
         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 (a part que les
         documentations seront probablement mieux maintenues:). La
         documentation distribuee reste la meme.

       o Il n'est pas necessaire pour les traducteurs d'apprendre une nouvelle
         syntaxe et leur editeur de fichier PO prefere (qui peut etre le mode
         PO d'Emacs, Lokalize ou Gtranslator) sera parfait.

       o gettext permet d'obtenir facilement des statistiques sur ce qui a ete
         fait, ce qui doit etre revu et mis a jour, et sur ce qu'il reste a
         faire. Vous trouverez des exemples a 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
       desavantages que nous devons gerer.

       o Les addenda sont... surprenants au premier abord.

       o Il n'est pas possible d'adapter le texte traduit a votre gout, comme
         de decomposer ou recomposer des paragraphes. Mais d'un autre cote,
         s'il s'agit d'un probleme dans le document original, celui-ci doit
         etre signale de toute facon.

       o Meme s'il a une interface simple, il reste un nouvel outil qu'il
         faudra apprendre a maitriser.

         Un de mes reves serait d'integrer po4a a Gtranslator ou Lokalize.
         Lorsqu'un fichier SGML serait ouvert, ses chaines seraient extraites
         automatiquement. Lors de l'enregistrement, le fichier SGML traduit
         serait ecrit sur le disque. Si nous arrivons a faire un module pour
         MSWord (TM) (ou au moins pour le format RTF), des traducteurs
         professionnels pourraient meme l'utiliser.

AUTEURS

        Denis Barbier <barbier,linuxfr.org>
        Martin Quinson (mquinson#debian.org)