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é.
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.5//EN">
Si nous la 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.5 et que ce document est un article.
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.5//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[2] 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-15"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//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 (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.
Le format XML DocBook permet de réaliser des documents en utilisant des caractères Unicode. Unicode est une norme qui a l'ambition de permettre l'écriture de toutes les langues du monde.
Si votre système d'exploitation vous permet de travailler en Unicode, utilisez-le pour rédiger votre document. Afin que les outils de production DocBook sachent quel codage vous utilisez, la première ligne de votre document devra être :
<?xml version="1.0" encoding="utf-8"?>
Dans cet en-tête, encoding="utf-8"
indique que le codage utilisé est le codage UTF-8 d'Unicode.
Unicode permet d'inclure dans votre document des textes dans presque toutes les langues du monde, cependant, disposer d'un environnement de travail en Unicode peut encore être assez compliqué.
Si vous n'utilisez pas Unicode, le meilleur codage disponible pour le français est le codage latin 9 (poétiquement nommé ISO 8859-15). Ce codage permet d'utiliser l'ensemble des caractères de la langue française. De plus, la plupart des distributions Linux vous permettront très simplement de l'utiliser. Si vous utilisez ce codage pour rédiger votre document, la première ligne de celui-ci devra être :
<?xml version="1.0" encoding="iso-8859-15"?>
Dans cet en-tête, encoding="iso-8859-15"
indique que le codage utilisé est le codage ISO 8859-15 dit
latin 9.
Avec ce codage, vous pourrez entrer au clavier tous les caractères nécessaire à la langue française.
Enfin, vous pouvez utiliser le codage latin 1 (connu sous le poétique sobriquet de ISO 8859-1). Ce codage devrait être compatible avec l'essentiel des outils et des systèmes d'exploitation existants.
Le codage de base de Windows pour les langues d'Europe de l'ouest (Windows-1252), notamment, est une extension du codage latin 1.
L'en-tête de votre fichier XML devra mentionner le codage utilisé pour ce document[4]. 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 ISO 8859-1 dit
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 saisis directement mais doivent être représentés de la façon suivante :
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 | € |
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.
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 fine insécable[5] | espace |
mot
| mot ; mot |
Deux-points | espace insécable | espace |
mot
| mot : mot |
Point d'exclamation | espace fine insécable[5] | espace |
mot
| mot ! Mot |
Point d'interrogation | espace fine insécable[5] | espace |
mot
| mot ? Mot |
Ouvrez les guillemets | espace | espace insécable[b] |
mot_
| mot « mot |
Fermez les guillemets | espace insécable[b] | espace |
mot
| mot » mot |
Tiret | espace | espace |
mot_
| mot — mot |
Parenthèse ouvrante | espace | rien |
mot_(mot
| mot (mot |
Parenthèse fermante | rien | espace |
mot)_mot
| mot) mot |
Crochet ouvrant | espace | rien |
mot_[mot
| mot [mot |
Crochet fermant | rien | espace |
mot]_mot
| mot] mot |
Point de suspension[c] | espace |
| … mot | |
Point de suspension[d] | rien | espace |
mot
| mot… mot |
Point de suspension[e] | espace | espace |
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 [c] Remplaçant le début d'un texte. [d] Servant de fin de phrase ou de mot. [e] Remplaçant un mot unique. |
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 !
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 2 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 LDP guides sont eux des livres complets couvrant un thème spécifique.
Le LDP disposait également auparavant d'un troisième format, qui a maintenant été fusionné avec les howto : les mini-howto. Ce terme se retrouve encore dans le titre de certains documents.
Ces trois 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 |
Enfin, indiquez en sous-titre le nom original du document.
Cela permettra d'une part d'indiquer clairement l'origine de ce document, sans avoir à 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 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 « <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.
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 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.
Si la version originale n'en comporte pas, il faut en ajouter un en indiquant une entrée pour la version française et une entrée pour la version originale (date, version, initiales de l'auteur).
Attention ! L'historique des révisions ne se trouve pas forcément dans l'en-tête du document. Assurez-vous d'avoir survolé l'ensemble du document avant d'en ajouter un.
Si la version originale en comporte déjà un, 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 original de l'historique des révisions. Pour ces entrées, il faut donc conserver le texte original entre parenthèses, derrière la version française.
Pour l'historique des révisions, respectez les règles de présentation suivantes :
Afin de normaliser la présentation des documents publiés, utilisez le format de date ISO 8601 dans l'historique des révisions. Dans ce format, la date se présentera ainsi :
aaaa
-mm
-jj
avec aaaa
l'année sur quatre
chiffres, mm
le mois sur deux
chiffres et jj
le jour sur deux
chiffres.
Indiquez systématiquement les initiales des auteurs en majuscules. Dans le cas des traductions, les initiales du traducteur et des relecteurs doivent systématiquement figurer.
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">[7]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>
.
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>
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 :
La première chose à faire avant de commencer une traduction est de lire la licence du document et de réfléchir point par point à ce qu'elle implique. S'il n'est pas possible de réaliser une version française en respectant les conditions qu'elle pose, il faut impérativement contacter l'auteur pour demander l'autorisation de réaliser et de diffuser librement une adaptation française.
La version française d'un document est une version modifiée de ce document. Toutes les conditions applicables à la réalisation d'une version modifiée s'appliquent à la réalisation de la version française.
Si la licence impose de conserver une version non modifiée de certains textes, ceux-ci doivent être conservés en version originale. Il est par contre recommandé d'ajouter à ces textes une version française, afin qu'un lecteur francophone puisse s'y retrouver.
Le document doit indiquer clairement les noms des membres de l'équipe de traduction et doit clairement indiquer sous quelles conditions la version française est distribuée.
Chaque mention « copyright » doit être accompagnée d'une mention équivalente relative à la version française.
Par exemple :
<para> Copyright (c) 2004 Jonas Skyfall. </para>
deviendra :
<para> Copyright © 2003 Jonas Skyfall pour la version originale. </para> <para> Copyright © 2004 Guillaume Lelarge et Jean-Philippe Guérard pour la version française. </para>
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 :
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>
![]() | Avertissement |
---|---|
Attention ! Pour que les adresses électroniques soient
correctement interprétées, il est important que le texte entre
les balises |
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 :
Anglais | Français |
---|---|
Copyright | Droits d'utilisation |
Credits | Remerciements |
Disclaimer | Limitation de responsabilité |
Feedback | Commentaires et corrections |
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 :
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éé la 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 :
<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 : <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 : <ulink url="&howto;nom_original_du_guide.html
"/> </para> <para> La plus récente version originale de ce document est disponible à l'adresse : <ulink url="http://www.tldp.org/HOWTO/nom_original_du_guide.html
/>. </para>
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 d'en informer l'auteur du document original, qui pourra ainsi bénéficier du travail réalisé sur la version française.
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 la traduction française du document.
Le site traduc.org offre une adresse de lecture stable pour tous les guides pratiques (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 si ce n'est pas le cas la version anglaise.
Ce système évite d'avoir à mettre à jour tous les documents qui font référence à un guide pratique lorsque celui-ci est traduit.
Pour utiliser ce système, il suffira de remplacer le lien vers le guide pratique par un lien vers :
<!-- Cas d'un guide pratique (howto) --> <ulink url="http://www.traduc.org/docs/howto/lecture/nom_original.html
"/> <!-- Cas d'un livre (LDP guide) --> <ulink url="http://www.traduc.org/docs/guides/lecture/nom_original
/"/>
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.5//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.5//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
"/> <!-- Cas d'un livre (LDP guide) --> <ulink url="&guide;nom_original_du_livre
/"/>
![]() | Note |
---|---|
Si un hyperlien ne comporte aucun texte, c'est l'adresse (l'URL) elle-même qui sera utilisée comme texte. Donc, si le texte d'un hyperlien est son adresse, inutile de la répéter ! <ulink url="http://tigreraye.org"/> est donc strictement équivalent à : <ulink url="http://tigreraye.org">http://tigreraye.org</ulink> Pensez donc systématiquement à utiliser la première forme, lorsque c'est possible. Elle est plus concise et limite le risque d'erreur ! |
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>
...
Le bloc de texte littéral ne sera en général pas inclus dans un paragraphe, mais sera utilisé comme un bloc indépendant entre des paragraphes fermés. | |
La balise initiale est placée seule en début de ligne, sans être précédée d'espace. Le texte littéral commence à la ligne suivante. | |
Le texte littéral commence à la ligne suivant immédiatement la balise de début de bloc. Il est collé au début de la ligne — autrement dit, il n'est pas précédé d'espace. Rien n'empêche par contre que le texte lui-même soit indenté pour être plus lisible. | |
Le texte littéral se termine immédiatement avant la balise de fin de bloc, sans laisser de ligne blanche entre les deux. | |
La balise finale, comme la balise initiale, est placée seule en début de ligne, sur la ligne suivant immédiatement la dernière ligne du bloc. |
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.
[2] Un DTD est une Définition de Type de Document. Il sert de définition à un format XML en définissant quelles balises sont reconnues et comment et dans quel contexte les employer.
[3] La balise racine du document est la première balise du document. Elle s'ouvre pour commencer le document et se ferme lorsque celui-ci se termine.
[4] Les documents SGML aux formats LinuxDoc et DocBook utilisent par défaut le codage latin 1.
[5]
En théorie, représentée par l'entité  
. Cependant, pour des
raisons de compatibilité, nous utilisons pour l'instant
l'entité
pour
représenter une espace fine.
[6]
Représentée par l'entité
.
[7]
On utilise ici <emphasis>
à la place
de <foreignphrase>
car cette dernière
balise est interdite à l'intérieur des commentaires relatifs à une
révision. De même, les balise <quote>
et </quote>
devraient ici être remplacée
par respectivement «
et
.
»