Version : 0.25
Ce document libre a été créé par Jean-Philippe Guérard <fevrier CHEZ tigreraye POINT org> en mars 2003. Vous pouvez le diffuser et le modifier selon les termes de la licence Art Libre. Vous trouverez un exemplaire de cette licence sur le site de Copyleft Attitude.
3 juillet 2004
Résumé
Ce document est le fruit de l'expérience accumulée par le projet traduc.org dans l'adaptation en français de guides pratiques (howto). Il tente de résumer les informations dont le traducteur a besoin et de définir des normes permettant de rendre cohérentes entre elles la présentation des traductions.
Table des matières
Ce document est destiné aux traducteurs et aux relecteurs, et tente de répondre aux questions qui se posent lors de la traduction d'un guide pratique au format DocBook.
Les exemples présentés dans ce document sont rédigés en utilisant le format XML DocBook. Ils ne faut pas hésiter à copier certains exemples dans une traduction et à s'en servir comme trame de base.
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 :
pensez à systématiquement vérifier votre traduction avec un correcteur orthographique ;
relisez toujours vos propres traductions au moins une fois à tête reposée ;
respectez dans vos traductions les conventions typographiques françaises ;
ne traduisez jamais un passage sans le comprendre ;
vérifiez tous les liens du document et adaptez-les si besoin ;
indiquez en première page le nom du traducteur et du relecteur ;
indiquez en première page la date et la version de la version française ;
indiquez systématiquement sous quelle licence la version française est distribuée ;
donnez à votre document un titre clair et vendeur ;
assurez-vous que le résumé est clair et compréhensible par lui-même.
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/.
Ce chapitre explique comment préparer une traduction. Il décrit chacune des étapes préliminaires permettant de s'assurer que l'on réalisera un travail utile.
Le projet de traduction des documents libres utilise deux listes de diffusion. Une liste de discussion interne et une liste destinée aux commentaires et corrections des lecteurs.
La liste traduc CHEZ traduc POINT org est le cœur de traduc.org. Les traducteurs des différents projets s'y retrouvent. Elle permet de se tenir informé des grandes évolutions de chacun des projets.
Cette liste est le lieu de rencontre de nombreux traducteurs, ce qui en fait l'endroit idéal pour obtenir de l'aide sur une traduction difficile. Je vous recommande fortement de vous y abonner si vous souhaitez participer aux traductions.
La liste commentaires CHEZ traduc POINT org est destinée à recevoir les commentaires des lecteurs des documents que nous avons traduits. Son adresse est indiquée dans les documents traduits.
Cette liste est ouverte aux traducteurs, relecteurs, ainsi qu'à toute personne participant au projet, mais il n'est nullement obligatoire de s'y abonner. Le débit de cette liste devrait être relativement faible.
Choisir un document à traduire est relativement simple. Il faut trouver un document :
qui vous plaise (^_^) ;
que vous jugez d'une taille raisonnable ;
qui n'aie pas encore été traduit, ou qui aie besoin d'être mis à jour ;
qui ne soit pas déjà en cours de traduction ;
que vous soyez libre de 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é.
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.
Avant de se lancer, une recherche rapide via un moteur de recherche du type Google permettra de vérifier si une version française du document n'a pas déjà été publiée. Si l'on utilise Google, il est possible de limiter sa recherche aux pages francophones, ce qui simplifie les choses.
Lorsqu'un document contient l'adresse du site personnel de son auteur, il est souvent payant d'aller y jeter un œil : celui-ci peut en effet contenir une copie ou un lien vers une traduction française déjà existante.
Avant de commencer à traduire un document, il est impératif de vérifier que l'on a le droit de le traduire et d'en diffuser la traduction.
Il faut donc commencer par lire consciencieusement la licence du document afin de vérifier ce que est permis et ce qui ne l'est pas. Il faut faire d'autant plus attention à la licence que celle-ci peut avoir des exigences quant au contenu de la version française, et la façon dont le document doit être adapté.
Un document ne comportant aucune mention précisant que son utilisation est libre ne l'est pas. Et il n'y a aucune raison de supposer qu'il peut être librement traduit. Dans un tel cas, le mieux à faire est de contacter l'auteur (cf. Section 2.4, « Prendre contact avec l'auteur »), pour vérifier les conditions d'utilisation de son document. Rien n'empêche alors de lui demander de diffuser son document sous une licence libre.
Afin d'éviter une duplication du travail, le projet de traduction des documents libres a mis en place du 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'a 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, et lui indiquant qu'on le tiendra informé de la publication de la version française.
C'est un peu technique, mais il est important de reconnaitre 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é.
Un document SGML au format LinuxDoc commencera ainsi :
<!doctype linuxdoc system> |
Un document SGML au format DocBook commencera ainsi :
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN"> |
Si nous regardons de plus près, cette ligne nous indique que le format du document est le format DocBook (SGML), que la version de DocBook employée est la version 4.2 et que ce document est un article.
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN"> ^ ^ ^ | | | Type de document DTD Version (article, book, et cætera) |
La version peut changer, le type de document peut être différent, mais le DTD employé doit être le DTD « DocBook ». À noter, les premières version du format DocBook (3.0) mentionnent « -//Davenport// » au lieu de « -//OASIS// ».
Enfin, un document XML au format DocBook commencera ainsi :
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"> |
La version peut changer, le type de document (ici un article) peut être différent, mais le DTD employé doit être un DTD « DocBook XML ».
Le format recommandé par le projet traduc.org est le format XML DocBook (version 4.1.2 ou 4.2).
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 finale à 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).
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.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> <article lang="fr"> <articleinfo> ... (en-tête du document) ... </articleinfo> ... (corps du document) ... </article> |
Remarquez l'attribut lang="fr" de la balise <article>. Il indique que le document devra respecter les conventions d'écriture et typographiques françaises.
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 épais utiliseront plutôt la classe book.
Le format XML DocBook permet de réaliser des documents en utilisant le jeu de caractère (ou codage) Unicode, le jeu de caractère dit universel.
Cependant, afin de faciliter le travail sur le document, je vous recommande d'utiliser le jeu de caractères latin 1 (connu sous le poétique sobriquet de codage ISO 8859-1). Contrairement à Unicode, ce jeu de caractère permet l'édition du document avec l'essentiel des outils disponibles.
L'en-tête de votre fichier XML devra mentionner le jeu de caractère utilisé[2]. Pour ce faire, la première ligne de votre document devra être :
<?xml version="1.0" encoding="iso-8859-1"?> |
Dans cet en-tête, encoding="iso-8859-1" indique que le codage utilisé est le codage latin 1.
Il vous suffit alors d'entrer votre texte en utilisant les caractères accentués normaux de votre clavier. Les seuls caractères français auxquels vous devrez faire attention sont les caractères « Œ », « œ », « Ÿ » et le symbole « € ». En effet, ces caractères avaient été oubliés lors de la définition du codage latin 1 (et l'Euro n'était pas encore à l'ordre du jour). Ces caractères ne peuvent donc pas être tapés directement mais doivent être entrés au moyen des entités suivantes :
Tableau 1. Caractères français manquant dans le codage latin 1
Caractère | Nom | Entité |
---|---|---|
Œ | E dans l'O majuscule | Œ |
œ | E dans l'O minuscule | œ |
Ÿ | Y tréma majuscule | Ÿ |
€ | Symbole monétaire de l'Euro | € |
Pour terminer, un petit rappel. Pour le français imprimé, contrairement au français manuscrit, il est d'usage d'accentuer les majuscules. En plus l'accentuation des majuscules augmente 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 les ponctuations doubles[3] d'un blanc insécable (entité ) afin d'éviter qu'elles se retrouvent renvoyées toutes seules en début de ligne.
Tableau 2. Espacement de la ponctuation (cas général)
Ponctuation | Avant | Après | Exemple (source)[a] | Exemple (résultat) |
---|---|---|---|---|
Virgule (,) | rien | espace | mot,␣mot | mot, mot |
Point (.) | rien | espace | mot.␣Mot | mot. Mot |
Point-virgule (;) | espace insécable | espace | mot ;␣mot | mot ; mot |
Deux points (:) | espace insécable | espace | mot :␣mot | mot : mot |
Point d'exclamation (!) | espace insécable | espace | mot !␣Mot | mot ! Mot |
Point d'interrogation (?) | espace insécable | espace | mot ?␣Mot | mot ? Mot |
Point de suspension (…) | rien | espace | mot…␣Mot | mot… Mot |
Ouvrez les guillemets («) | espace | espace insécable[b] | mot␣<quote>mot | mot « mot |
Fermez les guillemets (») | espace insécable[b] | espace | mot</quote>␣mot | mot » mot |
Tiret (—) | espace | espace | mot␣—␣mot | mot — mot |
[a] Le caractère « ␣ » est utilisé pour représenter une espace normale. [b] L'espace insécable est ici automatiquement ajoutée par la balise <quote>. |
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 :
Tableau 3. Espacement de la ponctuation (cas particulier)
Ponctuation | Avant | Après | Exemple (source)[a] | Exemple (résultat) |
---|---|---|---|---|
Ouvrez les guillemets («) | espace | espace insécable | mot␣« mot | mot « mot |
Fermez les guillemets (») | espace insécable | espace | mot »␣mot | mot » mot |
[a] Le caractère « ␣ » est utilisé pour représenter une espace normale. |
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 tout simplement non traduit ne sera pas lue par le public francophone qu'elle pourrait intéresser. Ceci, tout simplement parce que la lecture du titre n'éveillera pas la curiosité et l'intérêt du lecteur !
Lu isolément, le titre doit donner une idée claire du sujet du document, car il sera repris dans des index ne contenant pas forcément de résumé.
Le projet de documentation Linux (LDP) a défini 3 formats de documents, qui composent l'essentiel de sa production.
Les howto sont en règle générale des documents pratiques présentant la marche à suivre pour réaliser un objectif précis. Les mini-howto sont des howto plus courts et d'une étendue plus limitée. Enfin, les LDP guides sont des livres complets couvrant un thème spécifique.
Ces 3 noms de formats, que ce soit dans le titre ou dans le corps du texte, seront systématiquement traduits en français de la façon suivante :
Anglais | Français |
---|---|
Mini-howto | Petit guide |
Howto | Guide pratique |
LDP guide | Livre |
Indiquez en sous-titre le nom original du document.
Cela permettra d'une part d'indiquer clairement l'origine de ce document, sans avoir a recourir à un titre en franglais. Cela facilitera également la recherche de la version française d'un document à partir des moteurs de recherche.
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>Online Troubleshooting Resources HOWTO</foreignphrase> </subtitle> ... </articleinfo> |
Rien de compliqué ici. Vous trouverez ci-dessous un exemple de code XML DocBook montrant comment citer le nom du traducteur et du relecteur en plus du nom de l'auteur.
<articleinfo> ... <author> <firstname>Jeffrey</firstname> <surname>Sinclair</surname> <email>jeff CHEZ bab POINT com</email> </author> <othercredit role="traduction"> <firstname>Jean</firstname> <surname>Dupont</surname> <contrib>Adaptation française</contrib> <email>jdupont CHEZ dupont POINT fr</email> </othercredit> <othercredit role="relecture"> <firstname>Alice</firstname> <surname>Martin</surname> <contrib>Relecture de la version française</contrib> <email>alice CHEZ ouebe POINT org</email> </othercredit> ... </articleinfo> |
Toute version française publiée doit systématiquement comporter son propre numéro de version.
Ce numéro de version doit comporter des indications exactes permettant d'identifier aussi bien la version du document original que la version exacte de la traduction. Cette dernière précision est notamment utile si une nouvelle version française est publiée, afin de s'assurer qu'un lecteur puisse sans problème déterminer laquelle des deux versions est la plus à jour.
Pour les version française, en général, on adopte la solution suivante : la version 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.
Tableau 4. Exemple de versions
Version | Description |
---|---|
3.0.fr.1.1 | Mise à jour de la version française |
3.0.fr.1.0 | Première version française de la nouvelle version |
3.0 | Nouvelle version originale |
2.2.fr.1.1 | Mise à jour de la version française |
2.2.fr.1.0 | Première version française |
2.2 | 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 : 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 ne sera cité que 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.
Si la version originale comporte déjà un historique des révisions, chaque version française doit faire l'objet d'une entrée séparée dans l'historique des révisions.
Les entrées originales de l'historique des révisions doivent être traduites, afin que les lecteurs puissent se faire une idée des modifications ayant été effectuées entre chaque version.
Attention ! Les documents publiés sous la Licence de documentation libre GNU (GFDL) doivent conserver le texte des entrées en version originale de l'historique des révisions. Pour ces entrées, il faut conserver le texte original entre parenthèses, derrière la version française.
Ce qui donnera par exemple :
<articleinfo> ... <revhistory> <revision> <revnumber>0.2.fr.1.0</revnumber> <date>2003-12-20</date> <authorinitials>MG</authorinitials> <revremark>Première traduction française</revremark> </revision> <revision> <revnumber>0.2</revnumber> <date>2002-10-08</date> <authorinitials>GK</authorinitials> <revremark> Ajout d'une partie consacrée aux inverseurs de polarité (<emphasis>Added a part on polarity reversers</emphasis>) </revremark> </revision> ... </revhistory> ... </articleinfo> |
Le résumé est le texte d'en-tête compris entre les balises <abstract> et </abstract>. C'est une synthèse du document qui doit être concise, précise, et donner envie de le lire.
Lorsque le résumé du texte original n'est pas très bon, il vaut mieux refaire un résumé à partir de zéro plutôt que d'essayer de l'adapter.
Si la version originale contient d'autres éléments (comment contacter l'auteur, licence d'utilisation, et cætera), ils devront être déplacés dans la section appropriée.
Le résumé doit pouvoir être repris tel quel hors du document. Il doit donc se limiter à résumer le document, et être clair par lui-même.
Un bon moyen d'évaluer le résumé est de le lire hors du contexte du document, afin de vérifier qu'il offre bien une présentation claire du contenu du document.
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> |
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 soit plus difficiles à récolter automatiquement.
En conséquence, lorsqu'un document contient des adresses électroniques, il doit utiliser le système de transcription suivant :
Tableau 5. Transcription des adresses électroniques
Caractère original | Texte de remplacement |
---|---|
@ | ␣CHEZ␣ |
. | ␣POINT␣ |
- | ␣TIRET␣ |
_ | ␣SOULIGNÉ␣ |
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> |
Attention ! Du fait de la présence d'espaces entre les balises <email>, l'adresse électronique pourrait se retrouver coupée par une fin de ligne. 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.
Les documents originaux comportent souvent une mention du style :
<sect2> <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> </sect2> |
Ici, plusieurs remarques s'imposent :
En traduisant cette phrase, il sera important de bien préciser la langue à utiliser pour contacter l'auteur. En effet, il y a fort à parier que si l'auteur reçoit un message en français, il ne le comprenne pas.
Il est intéressant de rajouter ici un court paragraphe indiquant au lecteur francophone comment signaler des erreurs, des idées d'amélioration ou des commentaires relatifs à la version française.
À cette fin, nous avons créé une liste commentaires CHEZ traduc POINT org. Cette liste est destinée à recevoir les commentaires des lecteurs et à en assurer le suivi.
Cette liste offre l'avantage d'éviter de dépendre de l'adresse du traducteur d'un document. Il n'est donc plus nécessaire de mettre à jour le document lorsque le traducteur change d'adresse, ou dans le cas d'un changement de traducteur.
Le document traduit pourrait donc ressembler à ceci :
<sect2> <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 tout commentaire relatif à la version française de ce document à <email>commentaires CHEZ traduc POINT org</email> en précisant son titre, sa date et sa version. </para> </sect2> |
Les liens d'un document doivent être vérifiés, et si possible traduits.
Internet étant en constante évolution, il y a fort à parier que certains des liens du document seront soit morts, soit redirigés vers de nouvelles URL. Il est donc important de vérifier chacun des liens du document.
Dans le cas de liens renvoyés vers de nouvelles URL, on remplacera le lien par la nouvelle URL.
Dans le cas des liens morts, il faudra rechercher la nouvelle adresse du site en question, les coordonnées du projet qui a pris le relais ou des miroirs toujours existant, et remplacer le lien par cette nouvelle URL.
S'il n'existe plus aucun site pertinent, il faudra selon les cas soit supprimer la mention de ce lien (en la conservant en commentaires dans la traduction), soit le remplacer par une ressource équivalente.
Il est important de noter chacune de ces modifications, et en informer l'auteur du document original, qui pourra ainsi bénéficier du travail réalisé sur la version française.
Enfin, s'il existe une version française d'un lien donné, on remplacera le lien vers la version originale par un lien vers la version française. Par exemple :
<ulink url="http://www.redhat.com">RedHat Web Site</ulink> |
sera remplacé par :
<ulink url="http://www.redhat.fr">site de Red Hat</ulink> |
La version française d'un lien pourra être le site français du même projet ou de la même société, ou une adaptation en français dans le cas d'un document.
Le site traduc.org offre une adresse de lecture stable pour tous les howto du projet de documentation Linux (LDP). Cette adresse de lecture stable offre l'avantage de présenter au lecteur, d'une manière dynamique, la version française si elle est disponible, et la version anglaise autrement.
Ce système évite d'avoir à mettre à jour tous les documents qui font référence à un howto lorsque celui-ci est traduit.
Pour utiliser ce système, il suffira de remplacer le lien vers le howto par un lien vers :
<!-- Cas d'un guide pratique (howto) --> <ulink url="http://www.traduc.org/docs/howto/lecture/nom_original_du_guide.html"></ulink> <!-- Cas d'un livre (LDP guide) --> <ulink url="http://www.traduc.org/docs/guides/lecture/nom_original_du_livre/"></ulink> |
Pour simplifier ce système, il suffit de définir en tête de document des entités correspondant à ces deux types de liens.
Pour insérer les entités, il faut modifier la déclaration du type du document :
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN"> |
Pour cela, à la fin de cette déclaration, on insère entre crochets la définition des deux entités :
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [ <!ENTITY howto "http://www.traduc.org/docs/howto/lecture/"> <!ENTITY guide "http://www.traduc.org/docs/guides/lecture/"> ]> |
L'utilisation des adresses de lecture stables se fera alors de la façon suivante :
<!-- Cas d'un guide pratique (howto) --> <ulink url="&howto;nom_original_du_guide.html"></ulink> <!-- Cas d'un livre (LDP guide) --> <ulink url="&guide;nom_original_du_livre/"></ulink> |
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> |
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 :
$ /sbin/ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:22 errors:0 dropped:0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1780 (1.7 KiB) TX bytes:1780 (1.7 KiB) |
deviendra[4] :
$ /sbin/ifconfig lo lo Lien encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:22 errors:0 dropped:0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:1780 (1.7 KiB) TX bytes:1780 (1.7 KiB) |
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=C pour obtenir la version originale 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=C 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, 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 parfait, 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 pouvoir utiliser Aspell pour corriger un fichier XML, il faut modifier ou créer un fichier de configuration utilisateur ~/.aspell.conf et y ajouter la ligne :
add-sgml-extension xml |
Une fois cette ligne ajoutée, il suffit de lancer la commande suivante pour vérifier un fichier XML :
aspell check Mon-Fichier.xml |
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 <relecture 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.
Ce patron présente un exemple commenté de l'en-tête d'un document XML DocBook. Il reprend tous les éléments de l'en-tête d'une traduction française placés dans leur contexte.
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> <article lang="fr"> <articleinfo> <!-- Merci à Simon Depiets qui a réalisé la version initiale de ce patron. --> <!-- Titre et sous-titre --> <title> Petit guide d'installation de MMBase sur un système Woody Débian </title> <subtitle> Version française du <foreignphrase>MMBase Mini-HOWTO: Installation on Debian Woody</foreignphrase> </subtitle> <!-- On conserve toujours la mention du titre original en sous-titre afin de rendre le document plus facile à trouver par une recherche réalisée à partir du titre original. --> <!-- Version et date de la version française --> <releaseinfo>Version : 0.2.fr.1.0</releaseinfo> <pubdate>10 février 2004</pubdate> <!-- La date du document doit être en clair (ie en français) --> <!-- Auteurs, traducteurs et relecteurs --> <author> <firstname>Casper Joost</firstname> <surname>Eyckelhof</surname> <email>joost CHEZ dnd POINT utwente POINT nl</email> </author> <othercredit role="traduction"> <firstname>Simon</firstname> <surname>Depiets</surname> <contrib>Adaptation française</contrib> <email>2df CHEZ tuxfamily POINT org</email> </othercredit> <othercredit role="relecture"> <firstname>Austin</firstname> <surname>Powers</surname> <contrib>Relecture de la version française</contrib> <email>sexteen's TIRET powers CHEZ superhero POINT org</email> </othercredit> <!-- Historique des révisions --> <revhistory> <revision> <revnumber>0.2.fr.1.0</revnumber> <date>2004-02-10</date> <!-- Les dates de l'historique des révisions doivent utiliser le format Iso : « aaaa-mm-jj » avec aaaa = année sur 4 chiffres, mm = mois sur 2 chiffres et jj = jour sur 2 chiffres. --> <authorinitials>SD</authorinitials> <revremark>Première traduction française</revremark> </revision> <revision> <revnumber>0.2</revnumber> <date>2002-05-28</date> <authorinitials>CJE</authorinitials> <revremark> Mise à jour pour MMBase 1.5, support de l'interface apache perdue (<emphasis>Updated for MMBase 1.5; lost support for apache frontend</emphasis>) <!-- Si la licence l'exige - c'est par exemple le cas de la licence de documentation libre GNU (GFDL) - il est nécessaire de conserver une copie du texte de l'historique des révision en version originale. --> </revremark> </revision> <revision> <revnumber>0.1</revnumber> <date>2000-10-01</date> <authorinitials>CJE</authorinitials> <revremark> Version initiale — Installer MMBase 1.4 sur Woody (<emphasis>Initial version - Installing MMBase 1.4; on Woody</emphasis>) </revremark> </revision> </revhistory> <!-- Résumé du document --> <abstract><para> Ce document décrit brièvement la mise en place de MMBase sur un système Linux/GNU Débian (Woody) en utilisant autant que possible les paquets inclus dans cette distribution. <!-- Ce résumé doit être clair et pouvoir être compris hors du contexte du document --> </para></abstract> </articleinfo> <para> Corps du texte. </para> </article> |
Cette annexe est un aide-mémoire des points à respecter lors de l'adaptation française d'un document distribué selon sa licence.
Attention ! Cet aide-mémoire ne vous dispense pas de lire complètement la licence d'un document avant d'en commencer la traduction !
Lire la licence d'un document vous permettra de connaître les conditions selon lesquels un document peut être traduit et sa traduction diffusée.
Attention ! La traduction d'un document est une version modifiée de sa version originale. Donc une licence interdisant la diffusion d'une version modifiée interdit également d'en diffuser une traduction !
La licence publique générale GNU [GPL] est une licence plutôt adaptée aux logiciels qu'aux documents. Elle est néanmoins parfois utilisée.
Les points à respecter sont les suivants :
le document final doit indiquer clairement qu'il est une traduction, le nom du traducteur et la date de la traduction ;
chacun des fichiers sources traduits doit indiquer clairement qu'il est une traduction, le nom du traducteur et la date de la traduction ;
le document traduit doit être distribué selon les termes de la licence GPL ;
lorsque le document est distribué, il doit être accompagné de son code source.
[1] Si vous n'avez aucune idée du délai nécessaire, ce n'est pas grave, c'est juste à titre indicatif de toutes façons ^_^
[2] Les documents SGML aux formats LinuxDoc et DocBook utilisent le jeu de caractère latin 1 par défaut.
[3] Les ponctuations doubles sont les deux points (:), points-virgules (;), point d'exclamation (!) et point d'interrogation (?).
[4] Vous noterez au passage que l'adaptation française de ifconfig, ce n'est pas encore tout à fait ça… ^_^