Si vous n'avez pas le temps, voici en résumé ce qu'il faut retenir de ce document. Si certains des points ci-dessous ne vous paraissent pas évidents, reportez-vous à la suite du document, où ils seront expliqués plus en détail :

N'hésitez pas à faire parvenir vos suggestions et commentaires relatifs à ce document à Jean-Philippe Guérard <fevrier CHEZ tigreraye POINT org>.

La dernière version de ce document est toujours accessible à l'adresse http://tigreraye.org/.

Le projet de traduction des documents libres utilise deux listes de discussion. Une liste pour les discussions internes et une liste destinée aux commentaires et corrections des lecteurs.

Choisir un document à traduire est relativement simple. Il faut trouver un document :

2.2.1. Les documents à traduire

Le projet de traduction des documents libres dispose de pages de suivi pour chaque type de document : guides pratiques (howto) et livres (LDP guides). Ces pages permettent également de réserver en ligne un document non attribué.

	Note
	En plus de ce projet, Traduc.org rassemble d'autres groupes de traduction, qui sont toujours à la recherche de volontaires. Jetez un œil à la page de garde du projet Traduc.org qui vous conduira à ces différents projets.

Afin d'éviter une duplication du travail, le projet de traduction des documents libres a mis en place une procédure permettant d'assurer le suivi des traductions.

Avant de se lancer dans une traduction, il est donc nécessaire de réserver le document auprès du coordinateur. Pour cela, il faut soit réserver le document via les pages de suivi des guides pratiques (howto) et livres (LDP guides), soit envoyer un courrier au coordinateur (<coordination TIRET howto CHEZ traduc POINT org>), en indiquant votre nom, votre adresse électronique, quel document vous souhaitez traduire et sous quel délai vous pensez réaliser cette traduction^[1].

Une fois le document réservé, vous n'avez plus qu'à attendre le feu vert du coordinateur.

Cette démarche peut être rendue obligatoire par la licence du document, mais elle est de toutes façons fortement recommandée. D'une part, elle permet d'établir un premier contact dans de bonnes conditions avec l'auteur du document, d'autre part, elle permet de s'assurer que l'auteur n'a pas connaissance d'une autre traduction en cours et qu'une nouvelle version du document n'est pas sur le point d'être publiée.

Il suffit d'envoyer un courrier électronique à l'auteur en l'informant du démarrage de la traduction, lui indiquant qu'on le tiendra informé de la publication de la version française.

Afin de faciliter le suivi des traductions, mettez en copie de ce message le coordinateur <coordination TIRET howto CHEZ traduc POINT org>.

Ce courrier peut par exemple ressembler à ceci :

Object : French translation of the [XXXX]-HOWTO
Cc :     coordination TIRET howto CHEZ traduc POINT org

Dear [Sir or Madam]:

I would like to translate in French the [XXXX]-HOWTO.
I am contacting you as you are the [author or current maintainer]
of this document.

Before starting this translation, I would like to ask you a few
questions:

- Could you tell me if you are aware of any existing French translation,
  or any French translation being currently done?

- Are you currently working on an update to this document? If it
  is the case, could you send me a preliminary version I can
  start working on?

- And, naturally, do you agree to have us translating this
  document?

For your information, once you have agreed to this translation,
I'll start working on it. After translation, the document will
be proofread and then published by the Traduc.org French
translation project.

I will notify you as soon as the translation is completed, and
if appropriate, send you a report of the updates applied to the
French version that could be integrated into your document.

The French version of this document will be available at the
following location:
http://www.traduc.org/docs/howto/lecture/[XXXX]-HOWTO.html

Thanks a lot in advance.

Best Regards.


[Prénom Nom]
[Adresse électronique]

C'est un peu technique, mais il est important de reconnaître le format utilisé par le document à traduire afin de savoir comment le modifier et comment produire les versions finales.

Nous travaillons toujours à partir de documents SGML aux formats LinuxDoc ou DocBook et de documents XML au format DocBook. Pour identifier le format du document, il suffit de regarder ses premières lignes.

En effet, un document SGML ou XML commence toujours par une déclaration de type de document (une ligne commençant par « <!doctype »). Cette déclaration permet d'identifier le format XML ou SGML utilisé.

Le format recommandé par le projet Traduc.org est le format XML DocBook (en version 4.5).

C'est un format ouvert et libre, modifiable via un simple éditeur de texte, permettant la publication du document dans de multiples formats (entre autres texte, HTML et PDF).

Tout comme le HTML, le format XML DocBook est un format de texte balisé. Les balises définissent la structure du texte. La présentation finale du document sera déduite de ces balises grâce à l'application d'une feuille de style.

Le traducteur n'a nul besoin d'être un expert du format XML DocBook, ni de savoir comment réaliser le document final à partir du format source XML DocBook. Dans la plupart des cas, il suffira de traduire le texte autour des balises (en schématisant un peu).

	Note
	Pour des raisons historiques, les documents aux formats SGML DocBook (version 3 et plus) et LinuxDoc sont aussi acceptés. L'utilisation de ces formats peut simplifier la vie lors de la traduction de documents dont c'est le format d'origine.

Un document au format XML DocBook se présente en gros ainsi :

... (déclaration de la version XML et du codage utilisé) ...
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">

<article lang="fr">
  <articleinfo>
    ... (en-tête du document) ...
  </articleinfo>
  ... (corps du document) ...
</article>

L'exemple ci-dessus correspond à un document utilisant la classe article, ce qui est le cas de la majorité des guides pratiques. Des documents plus volumineux utiliseront plutôt la classe book.

Lorsque votre document sera prêt, on lui appliquera des feuilles de style DocBook pour en produire une version lisible (au format HTML ou PDF par exemple). Ces feuilles de style devront être capable de produire des textes adaptés à la langue du document. Par exemple, le résumé du document sera intitulé « Abstract » si le document est en anglais et « Résumé » si le document est en français.

Vous devrez donc, pour que votre document final soit correct, indiquer dans quelle langue il est écrit. Pour cela, il suffit de rajouter à la balise servant de racine^[3] au document (<article> ou <book> l'attribut « lang="fr" » :

... (déclaration de la version XML et du codage utilisé) ...
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">

<article lang="fr">
  <articleinfo>
    ... (en-tête du document) ...
  </articleinfo>
  ... (corps du document) ...
</article>

Dans cet exemple, l'attribut « lang="fr" » de la balise <article> indique que le document devra respecter les conventions d'écriture et typographiques françaises.

Maintenant, un petit rappel. Pour le français imprimé, contrairement au français manuscrit, il est d'usage d'accentuer les majuscules. De plus, cette accentuation améliore la lisibilité et la clarté du texte. Donc, lorsque vous entrez votre texte, n'oubliez pas d'en accentuer les majuscules.

Votre clavier sous Linux devrait vous offrir la possibilité d'accéder à toutes les majuscules accentuées utilisées en français (via la touche « compose », via les touches mortes ou directement).

Le tableau ci-dessous résume les règles de présentation de la ponctuation applicables au français. On retiendra notamment que l'on fait précéder d'une espace fine insécable^[5] les points-virgules, points d'exclamation et points d'interrogation et d'une espace mot insécable^[6] les deux-points.

Certaines balises (comme <revremark>) ne permettent pas l'emploi de la balise <quote>. Dans un tel cas, il faudra directement utiliser les caractères représentant les guillemets et des espaces insécables :

	Important
	Le choix d'un titre français clair, compréhensible et qui donne envie de lire le document est crucial.

Le titre est souvent perçu par le traducteur comme quelque chose d'accessoire. Il est oublié ou traité à la va-vite. Pourtant, c'est lui qui décidera avant tout le reste de l'utilité d'un document.

En effet, l'adaptation française d'un document dont le titre est bâclé, incompréhensible ou non traduit ne sera tout simplement pas lue. Ceci, du fait que la lecture du titre n'éveillera ni la curiosité, ni l'intérêt du lecteur !

Voici un exemple de traduction de titre, qui peut servir de modèle. Le titre original suivant :

<articleinfo>
  ...
  <title>
     Online Troubleshooting Resources HOWTO
  </title>
  ...
</articleinfo>

pourra être traduit par :

<articleinfo>
  ...
  <title>
     Guide pratique du dépannage via Internet
  </title>
  <subtitle>
     Version française du <foreignphrase lang="en">Online 
     Troubleshooting Resources HOWTO</foreignphrase>
  </subtitle>
  ...
</articleinfo>

Pour être publié par le projet, un document doit indiquer le nom du traducteur et celui du relecteur. Un document qui ne mentionne ni l'auteur, ni le relecteur est un document sans licence, que nous n'aurons simplement pas le droit de publier.

Vous trouverez ci-dessous un exemple de code XML DocBook montrant comment indiquer le nom du traducteur et du relecteur dans l'en-tête du document.

<articleinfo>
  ...
  <author>
     <firstname>Jeffrey</firstname>
     <surname>Sinclair</surname>
     <email>jeff CHEZ bab POINT com</email>
  </author>

  <othercredit role="traduction" class="translator">
     <firstname>Brice</firstname>
     <surname>Le Creurer</surname>
     <contrib>Adaptation française</contrib>
     <email>brice CHEZ grandcroix POINT net</email>
  </othercredit>

  <othercredit role="relecture" class="translator">
    <firstname>Alice</firstname>
    <surname>Martin</surname>
    <contrib>Relecture de la version française</contrib>
    <email>alice CHEZ ouebe POINT org</email>
  </othercredit>
  ...
</articleinfo>

	Note
	L'attribut « class » de <othercredit> a été introduit dans la version 4.5 de DocBook. Pour un document utilisant une version antérieure de DocBook, utilisez <othercredit> sans cet attribut : <othercredit role="traduction"> <firstname>Brice</firstname> <surname>Le Creurer</surname> <contrib>Adaptation française</contrib> <email>brice CHEZ grandcroix POINT net</email> </othercredit>

Afin que le lecteur puisse toujours savoir quelle version du document il est en train de consulter, toute version française publiée doit comporter son propre numéro de version. Le seul examen du numéro de version doit toujours permettre de différencier deux versions françaises du même document.

Ce numéro de version doit être différent du numéro de la version originale, afin de pouvoir sans risque de confusion mettre à jour la version française (par exemple pour corriger une erreur) alors que la version originale n'a pas évoluée.

Afin de permettre au lecteur de repérer en un clin d'œil quelle version du document original correspond à ce document, nous avons choisi de construire le numéro de la version française à partir du numéro de la version originale.

Nous avons donc adopté la convention suivante : le numéro de la version française est constituée du numéro de la version originale suivi de « .fr. » suivi du numéro de la version française relatif à cette version originale.

Ce système permet notamment, si le besoin s'en fait sentir, de continuer à mettre à jour une ancienne version.

La version sera indiquée par une balise <releaseinfo> :

<articleinfo>
  ...
  <releaseinfo>Version&nbsp;: 3.0.fr.1.1</releaseinfo>
  ...
</articleinfo>

Chaque version française publiée doit systématiquement comporter une date. Cette date est sa date de publication.

En aucun cas la version française ne doit conserver la date du document original. La date du document original doit par contre être indiquée dans l'historique des révisions.

La date sera indiquée par une balise <pubdate> :

<articleinfo>
  ...
  <pubdate>20 décembre 2003</pubdate>
  ...
</articleinfo>

L'historique des révisions permet à un lecteur d'identifier facilement les modification faites par les nouvelles versions d'un document. Chaque document publié doit comporter un historique des révisions, que la version originale en comporte un ou non.

Pour l'historique des révisions, respectez les règles de présentation suivantes :

Ce qui donnera par exemple :

<articleinfo>
  ...
  <revhistory>
    <revision>
      <revnumber>0.2.fr.1.0</revnumber>
      <date>2003-12-20</date>
      <authorinitials>BLC,AM</authorinitials>
      <revremark>Première traduction française</revremark>
    </revision>
    <revision>
      <revnumber>0.2</revnumber>
      <date>2002-10-08</date>
      <authorinitials>JS</authorinitials>
      <revremark>
          Ajout d'une partie consacrée aux inverseurs de polarité.
          <emphasis lang="en">[]Added a part on polarity
          reversers.</emphasis>
      </revremark>
    </revision>
  ...
  </revhistory>
  ...
</articleinfo>

Le résumé une synthèse du document qui doit être concise, précise et donner envie de le lire. Il se trouve dans l'en-tête du document, entre les balises <abstract> et </abstract>.

Le résumé se présentera ainsi :

<articleinfo>
  ...
  <abstract><para>
      
    Ce document est le fruit de l'expérience accumulée par le
    projet <ulink url="http://www.traduc.org">Traduc.org</ulink>
    dans l'adaptation en français des guides pratiques du
    <ulink url="http://www.tldp.org/">projet de documentation Linux
    (LDP)</ulink>. Il tente de résumer les informations
    dont le traducteur à besoin et de définir des normes
    permettant de rendre cohérentes entre elles les traductions 
    réalisées.

  </para></abstract>
  ...
</articleinfo>

La licence du document est un point auquel il faut faire particulièrement attention. Lors de sa traduction, il faut notamment comprendre et respecter les points suivants :

Afin de lutter contre les envahissants courriers publicitaires, nous modifions systématiquement les adresses électroniques indiquées dans les documents. Le but de cette modification est que ces adresses restent utilisables pour un lecteur humain, mais soient difficiles à récolter automatiquement.

En conséquence, lorsqu'un document contient des adresses électroniques, il doit utiliser le système de transcription suivant :

Le caractère « _ » présent dans les textes de remplacement représente une espace normale.

Par exemple, l'adresse électronique suivante :

<email>tylor@corbeaunoir.org</email>

sera remplacé par :

<email>tylor CHEZ corbeaunoir POINT org</email>

	Avertissement
	Attention ! Pour que les adresses électroniques soient correctement interprétées, il est important que le texte entre les balises <email> soit écrit sur une seule ligne, c'est-à-dire qu'il n'y ait pas de passage à la ligne entre <email> et </email>.

Les titres de certaines sections reviennent régulièrement. Afin d'homogénéiser les traductions, cette section dresse un inventaire des traductions usuelles de ces intitulés :

Les documents originaux comportent souvent une mention du style :

<section>
<title>
    Feedback and corrections
</title>
<para>
    If you have questions or comments about this document, please
    feel free to contact the author at 
    <email>tylor@corbeaunoir.org</email>.
</para>
</section>

Ici, plusieurs remarques s'imposent :

Le document traduit pourrait donc ressembler à ceci :

<section>
<title>
    Commentaires et corrections
</title>
<para>
     
     Merci de faire parvenir en anglais à l'auteur vos questions
     et commentaires relatifs à la version originale de ce
     document à l'adresse
     
     <email>tylor CHEZ corbeaunoir POINT org</email>.
     
</para>
<para>
    
    N'hésitez pas à faire parvenir vos commentaires et suggestions
    concernant l'adaptation française de ce document au projet
    <ulink url="http://traduc.org">Traduc.org</ulink> à
    l'adresse&nbsp;:
    
    <email>commentaires CHEZ traduc POINT org</email>.

</para>
</section>

Le document original comporte souvent un lien vers le site de l'auteur ou du projet qui l'a créé. Ce lien permet aux lecteurs de retrouver la version la plus à jour du document.

Le lien vers le document original doit être conservé, en précisant bien qu'il s'agit d'un lien vers la version originale. Cependant, on rajoutera systématiquement un lien vers l'emplacement officiel de la version française, afin que le lecteur puisse se reporter à sa plus récente version.

Dans le cas des guides pratiques, on utilisera pour la plus récente version française le lien stable vers celle-ci.

Par exemple :

<title>
Latest version of this document
</title>

<para>
The latest version of this document can always be found at <ulink 
url="http://www.tldp.org/HOWTO/nom_original_du_guide.html/>.
</para>

sera traduit par :

<title>
Nouvelles versions de ce document
</title>

<para>
Vous trouverez la plus récente version française de ce document à 
l'adresse&nbsp;: <ulink url="&howto;nom_original_du_guide.html"/>
</para>

<para>
La plus récente version originale de ce document est disponible à 
l'adresse&nbsp;: <ulink 
url="http://www.tldp.org/HOWTO/nom_original_du_guide.html/>.
</para>

Ce court chapitre ne va pas parler d'adaptation française, une fois n'est pas coutume, mais de présentation et de rendu final. En effet, les blocs de texte littéral (<programlisting>, <screen>, <synopsis> et <literallayout> notamment) de par leurs caractéristiques doivent être modifiés avec précautions, afin d'éviter qu'ils ne soient illisibles dans la version française.

Dans les blocs de texte littéral, contrairement aux textes d'un document XML en général, chaque espace compte ! Chacun des espaces et des passages à la ligne inclus entre les balises de début et de fin de bloc sera pris en compte pour le rendu du document final.

Par exemple :

<programlisting>$ cd "$CHEMIN"
                $ mkdir "Mon dossier"
</programlisting>

deviendra, dans le document final :

$ cd "$CHEMIN"
                $ mkdir "Mon dossier"

ce qui n'est pas forcément le but recherché ^_^

	Important
	Un bloc de texte littéral doit donc être présenté dans le fichier source tel qu'il devra apparaître dans le document final.

Pour ces blocs de texte littéral, je vous recommande d'essayer d'adopter toujours la même présentation :

...
</para> 

<programlisting> 
BEGIN { 
    MOIS["janvier"]=1
    MOIS["février"]=2
    MOIS["mars"]=3
    MOIS["avril"]=4
    MOIS["mai"]=5
    MOIS["juin"]=6
    MOIS["juillet"]=7
    MOIS["août"]=8
    MOIS["septembre"]=9
    MOIS["octobre"]=10
    MOIS["novembre"]=11
    MOIS["décembre"]=12
}

{
    gsub( "er" , "" , $1 )
    if ($2 in MOIS) print $3 "-" MOIS[$2] "-" $1
    else print $0
} 
</programlisting> 

<para> 
...

Autre point, la largeur des blocs de texte littéral ne doit pas dépasser 66 colonnes. En effet, si le texte est trop long, il risque de déborder sur les marges et d'être coupé dans les versions imprimables (Postcript, PDF).

Attention cependant, redécouper des scripts ou des programmes demande de comprendre le langage utilisé, que le programme redécoupé soit syntaxiquement équivalent au programme original. Bref, que le programme fonctionne toujours ^_^

Je vous recommande de vérifier au fur et à mesure le rendu final des blocs de texte littéral, par exemple en produisant une version HTML du document. De plus, avant de finir le document, essayez de systématiquement produire une version d'impression (PostScript ou PDF) afin de vérifier le bon rendu des blocs littéraux.

Une question qui se pose souvent est de savoir s'il faut traduire les scripts et les extraits de code.

Il est important de traduire tout ce qui peut être traduit, afin de faciliter la compréhension du lecteur francophone. On ne traduira pas les commandes, mais on traduira les noms des variables, les commentaires, voire les valeurs.

Par exemple, le script suivant :

<programlisting>
#!/bin/bash

# This really stupid script will ping all listed host

HOST2PING="my_server my_pc my_gateway"

echo "Starting to ping"
for target in "$HOST2PING" ; do
    ping -c 1 "$target" ;
done
echo "All over"
</programlisting>

sera traduit comme suit :

<programlisting>
#!/bin/bash

# Ce script tout à fait idiot va faire un ping vers chacun des
# hôtes indiqués

HOTES_CIBLES="mon_serveur mon_pc ma_passerelle"

echo "Début des pings"
for cible in "$HOTES_CIBLES" ; do
    ping -c 1 "$cible" ;
done
echo "C'est fait"
</programlisting>

La solution la plus simple pour vérifier que l'on n'a pas fait d'erreur est d'essayer le script que l'on vient de traduire. Cela permet d'une part de vérifier qu'il fonctionne correctement et d'autre part, cela permet de relire ses traductions dans leur contexte d'utilisation, ce qui est toujours particulièrement intéressant :)

Il est important de traduire les captures d'écrans et les exemples afin que la version présentée corresponde à l'utilisation de la version française.

Il ne faut donc pas traduire les captures d'écran directement, par exemple avec un logiciel de dessin, mais réaliser les même captures d'écran sur la version française du logiciel (si elle existe).

Dans le cas de commandes en mode texte, c'est la même chose. Les exemples doivent être montrés avec la version française du logiciel.

Par exemple :

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1              18G  2,4G   15G  15% /
/dev/hda4              38M  8,9M   28M  25% /boot

deviendra :

$ df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/hda1              18G  2,5G   15G  15% /
/dev/hda4              38M  8,9M   28M  25% /boot

Pour choisir la langue utilisée par une commande lancée depuis un terminal, il suffit de faire précéder la commande de LANGUAGE=en pour obtenir la version anglaise et de LANGUAGE=fr pour obtenir la version française.

Par exemple, pour obtenir la version originale de la commande df, il suffira d'entrer la commande suivante :

LANGUAGE=en df

Ce qui aura pour effet de donner à la variable d'environnement LANGUAGE la valeur indiquée pour l'exécution de cette commande. Cette variable d'environnement est utilisée par gettext pour déterminer quelle langage utiliser pour communiquer avec l'utilisateur. C correspond à la version originale, en à la version anglaise et fr à la version française.

La première chose à faire une fois une traduction terminée est de la vérifier en utilisant un outil de correction orthographique.

Si ces outils ne sont pas parfaits, ils permettent de corriger les plus grosses erreurs. Vérifier une traduction avec un outil automatique est donc une étape indispensable.

Sous Linux, je vous recommande d'utiliser Aspell. Aspell permet de vérifier le texte en faisant abstraction des balises XML, ce qui facilite grandement le travail.

Pour vérifier un document XML, il suffit de lancer la commande suivante :

aspell -H check Mon-Fichier.xml

Il est possible de vérifier la cohérence de la structure d'un document XML au format DocBook. Pour cela, il suffit d'utiliser le programme xmllint :

xmllint --valid --noout mon_document.xml

Si xmllint se termine sans rien afficher, c'est que le format du document est correct. Si ce n'est pas le cas, xmllint indiquera où se trouve l'erreur, ce qu'il attendait et ce qu'il a trouvé. À l'aide de ces indications, il devrait être relativement simple de corriger l'erreur.

Une fois la traduction terminée, il ne reste plus qu'à la livrer au projet. Pour ce faire, il suffit d'envoyer le fichier source XML à l'adresse <coordination TIRET howto CHEZ traduc POINT org>.

Si le document original est livré avec des scripts, des images ou des fichiers externes, ils devront être renvoyés avec la traduction.

Il existe de multiples façons de fournir une relecture :

Une fois la relecture terminée, il ne reste plus qu'à la livrer au projet. Pour ce faire, il suffit de l'envoyer au traducteur, en mettant en copie le coordinateur des traductions : <coordination TIRET howto CHEZ traduc POINT org>.