Petit guide du traducteur
Jean-Philippe Guérard
<fevrier CHEZ tigreraye POINT org>
Version : 0.57
Copyright © 2003, 2004, 2005 Jean-Philippe Guérard
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 à la fin de ce document,
ainsi que sur le site Copyleft Attitude
[http://www.artlibre.org/].
23 octobre 2005
+----------------------------------------------------------------+
| Historique des versions |
|----------------------------------------------------------------|
| Version 0.57 | 2005-10-23 | JPG |
|----------------------------------------------------------------|
| Correction de la section « Production de la version HTML de ce |
| guide pratique » (il n'y a pas de catalogue XML dans l'archive |
| XSL DocBook). Mise à jour de la section « Ponctuation » pour |
| revenir à l'utilisation de « » à la place de |
| «   », pour des raisons de compatibilité avec certains |
| navigateurs. |
|----------------------------------------------------------------|
| Version 0.56 | 2005-09-28 | JPG |
|----------------------------------------------------------------|
| Ajout d'une note à la section « Production de la version HTML |
| de ce guide pratique ». |
|----------------------------------------------------------------|
| Version 0.55 | 2005-08-27 | JPG |
|----------------------------------------------------------------|
| Modification de la section sur l'historique des révisions |
| suite à une judicieuse remarque de Christophe Gaubert. |
|----------------------------------------------------------------|
| Version 0.54 | 2005-08-15 | JPG |
|----------------------------------------------------------------|
| Amélioration des sections sur la ponctuation et sur les |
| commentaires et corrections. Ajout d'une section sur la |
| relecture. |
|----------------------------------------------------------------|
| Version 0.53 | 2005-03-14 | JPG |
|----------------------------------------------------------------|
| Suite à la disparition de l'option add-sgml-extension dans la |
| version 0.60 d'Aspell, modification de la section sur la |
| vérification d'orthographe, pour suggérer l'emploi de Aspell |
| avec l'option -H pour vérifier l'orthographe des fichiers XML. |
|----------------------------------------------------------------|
| Version 0.51 | 2005-02-15 | JPG |
|----------------------------------------------------------------|
| Ajout d'un deux-points oublié dans la procédure de production |
| de la version HTML de ce guide pratique. Merci à Pascal Miquet |
| de cette correction ! |
|----------------------------------------------------------------|
| Version 0.44 | 2004-12-28 | JPG |
|----------------------------------------------------------------|
| Ajout en annexe de la commande utilisée pour produire la |
| version HTML de ce guide pratique. |
|----------------------------------------------------------------|
| Version 0.41 | 2004-12-13 | JPG |
|----------------------------------------------------------------|
| Ajout d'une note sur l'écriture simplifiée des hyperliens. |
| Ajout d'une section sur l'adaptation des paragraphes |
| « Nouvelles versions de ce document ». |
|----------------------------------------------------------------|
| Version 0.39 | 2004-11-20 | JPG |
|----------------------------------------------------------------|
| Ajout d'un section sur les blocs de texte littéral. Merci à |
| Pierre Machard et Guillaume Lelarge de leurs corrections et |
| suggestions ! |
|----------------------------------------------------------------|
| Version 0.35 | 2004-10-18 | JPG |
|----------------------------------------------------------------|
| Ajout d'un chapitre sur la traduction de la licence. |
|----------------------------------------------------------------|
| Version 0.33 | 2004-08-25 | JPG |
|----------------------------------------------------------------|
| Ajout d'une section sur les titres de section (^_^). Ajout |
| d'une section « Commentaires et corrections » au patron |
| DocBook. |
|----------------------------------------------------------------|
| Version 0.31 | 2004-08-01 | JPG |
|----------------------------------------------------------------|
| Reformatage du modèle de courrier à envoyer à l'auteur pour |
| respecter les marges des versions PostScript et PDF. Ajout |
| d'une section sur la vérification de la structure avec |
| xmllint. Mises à jour mineures du patron DocBook. |
|----------------------------------------------------------------|
| Version 0.27 | 2004-07-14 | JPG |
|----------------------------------------------------------------|
| Quelques corrections de Guillaume Lelarge, ajout d'un courrier |
| type à envoyer aux auteurs pour les prévenir du début d'une |
| traduction. |
+----------------------------------------------------------------+
Résumé
Ce document est le fruit de l'expérience accumulée par le projet
Traduc.org [http://www.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
1. Introduction
1.1. Ce qu'il faut retenir
1.2. Commentaires et corrections
1.3. Nouvelles versions de ce document
2. Avant de commencer
2.1. S'abonner aux listes de discussion
2.2. Choisir un document
2.3. Obtenir le feu vert du coordinateur
2.4. Prendre contact avec l'auteur
3. La traduction
3.1. Reconnaître le format du document
3.2. Le format DocBook
3.3. Le codage du texte
3.4. La ponctuation
3.5. Le titre
3.6. Le nom du traducteur et du relecteur
3.7. La version
3.8. La date
3.9. L'historique des révisions
3.10. Le résumé
3.11. La licence du document
3.12. Les adresses électroniques
3.13. Les titres des sections
3.14. La section « Commentaires et corrections »
3.15. La section « Nouvelles versions de ce
document »
3.16. Les liens et les références
3.17. Les blocs de texte littéral
3.18. Les scripts et les extraits de code
3.19. Les captures d'écrans et les exemples
4. Une fois la traduction terminée
4.1. Vérifier l'orthographe
4.2. Vérifier la structure du document
4.3. Livrer la traduction
5. Relire
5.1. Livrer sa relecture
A. Annexes
1. Patron DocBook
2. Produire simplement une version HTML d'un document
XML DocBook
2.1. Utiliser un script de production
3. Production de la version HTML de ce guide pratique
4. Aide-mémoire des licences libres
4.1. La licence de documentation libre
GNU [GFDL]
4.2. La licence publique générale GNU
[GPL]
5. Licence Art libre
5.1. Préambule
5.2. DÉFINITIONS
5.3. OBJET
5.4. L'ÉTENDUE DE LA JOUISSANCE
5.5. L'INCORPORATION DE L'¼UVRE
5.6. VOS DROITS D'AUTEUR
5.7. LA DURÉE DE LA LICENCE
5.8. LES DIFFÉRENTES VERSIONS DE LA
LICENCE
5.9. LES SOUS-LICENCES
5.10. LA LOI APPLICABLE AU CONTRAT
1. Introduction
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. Il ne faut pas hésiter à copier certains
exemples dans une traduction et à s'en servir comme trame de base.
1.1. Ce qu'il faut retenir
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 :
o vérifiez votre traduction avec un correcteur orthographique ;
o relisez toujours vos propres traductions à tête reposée ;
o respectez les conventions typographiques françaises ;
o ne traduisez jamais un passage sans le comprendre ;
o vérifiez tous les liens du document et adaptez-les si besoin ;
o indiquez en première page le nom du traducteur et du
relecteur ;
o indiquez en première page la date et la version de la version
française et ajoutez une entrée correspondante dans
l'historique des révisions ;
o indiquez systématiquement sous quelle licence la version
française est distribuée ;
o donnez à votre document un titre clair et vendeur ;
o assurez-vous que le résumé est clair et compréhensible de par
lui-même.
1.2. Commentaires et corrections
N'hésitez pas à faire parvenir vos suggestions et commentaires
relatifs à ce document à Jean-Philippe Guérard <fevrier CHEZ
tigreraye POINT org>.
1.3. Nouvelles versions de ce document
La dernière version de ce document est toujours accessible à
l'adresse http://tigreraye.org/ [http://tigreraye.org/].
2. Avant de commencer
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.
2.1. S'abonner aux listes de discussion
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.
o La liste traduc CHEZ traduc POINT org
[http://www.traduc.org/mailman/listinfo/traduc/] est le c½ur
de Traduc.org [http://www.traduc.org]. Cette liste est le lieu
de rencontre de nombreux traducteurs appartenant à de
multiples projets, 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.
o La liste commentaires CHEZ traduc POINT org
[http://www.traduc.org/mailman/listinfo/commentaires/] est
destinée à recevoir les commentaires des lecteurs des
documents que nous avons traduits. Son adresse doit être
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.
2.2. Choisir un document
Choisir un document à traduire est relativement simple. Il faut
trouver un document :
o qui vous plaise (^_^) ;
o que vous jugez d'une taille raisonnable ;
o qui n'aie pas encore été traduit, ou qui aie besoin d'être mis
à jour ;
o qui ne soit pas déjà en cours de traduction ;
o que vous soyez libre de traduire.
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
[http://www.traduc.org/docs/HOWTO/nouvel_etat.php?howto] (howto)
et livres
[http://www.traduc.org/docs/HOWTO/nouvel_etat.php?guides] (LDP
guides). Ces pages permettent également de réserver en ligne un
document non attribué.
[1][Note] 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 [http://www.traduc.org] qui vous
conduira à ces différents projets.
2.2.2. Vérifier que le document n'est pas déjà traduit
Avant de se lancer, une recherche rapide via un moteur de
recherche du type Google [http://www.google.fr] 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.
2.2.3. Vérifier que la licence du document permet sa traduction
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 qui 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.
2.3. Obtenir le feu vert du coordinateur
Afin d'éviter une duplication du travail, le projet de traduction
des documents libres a mis en place une procédure
[http://www.traduc.org/article.php?6.0.1] 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 [http://www.traduc.org/docs/HOWTO/nouvel_etat.php?howto]
(howto) et livres
[http://www.traduc.org/docs/HOWTO/nouvel_etat.php?guides] (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.
2.4. Prendre contact avec l'auteur
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 translation,
or any 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 proofreaded 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]
3. La traduction
3.1. Reconnaître le format du document
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é.
o Un document SGML au format LinuxDoc commencera ainsi :
<!doctype linuxdoc system>
o Un document SGML au format DocBook commencera ainsi :
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.3//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.3 et que ce
document est un article.
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.3//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// ».
o 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.3//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 ».
3.2. Le format DocBook
Le format recommandé par le projet Traduc.org
[http://www.traduc.org] est le format XML DocBook (version 4.2 ou
4.3).
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).
[2][Note] 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.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/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 volumineux utiliseront plutôt la classe book.
3.3. Le codage du texte
Le format XML DocBook permet de réaliser des documents en
utilisant pour le texte le codage Unicode. Ce codage à l'ambition
de permettre l'écriture de toutes les langues du monde.
Cependant, afin de faciliter le travail sur le document, je vous
recommande d'utiliser le codage latin 1 (connu sous le poétique
sobriquet de ISO 8859-1). Contrairement à Unicode, ce codage
permet l'édition du document avec l'essentiel des outils
disponibles.
L'en-tête de votre fichier XML devra mentionner le codage utilisé
pour ce document^[3]. 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 | €; |
+----------------------------------------------------------------+
Pour terminer, un petit rappel. Pour le français imprimé,
contrairement au français manuscrit, il est d'usage d'accentuer
les majuscules. De 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).
3.4. La ponctuation
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^[4] les
points-virgules, points d'exclamation et points d'interrogation et
d'une espace mot insécable^[5] les deux-points.
Tableau 2. Espacement de la ponctuation (cas général)
+---------------------------------------------------------------------------------+
|Ponctuation | Avant | Après | Exemple | Exemple |
| | | | (source)^[a] | (résultat) |
|--------------------+--------------+--------------+-----------------+------------|
|Virgule | rien | espace | mot,_mot | mot, mot |
|--------------------+--------------+--------------+-----------------+------------|
|Point | rien | espace | mot._Mot | mot. Mot |
|--------------------+--------------+--------------+-----------------+------------|
|Point-virgule | espace fine | espace | mot ;_mot | mot ; mot |
| | insécable | | | |
|--------------------+--------------+--------------+-----------------+------------|
|Deux-points | espace | espace | mot :_mot | mot : mot |
| | insécable | | | |
|--------------------+--------------+--------------+-----------------+------------|
|Point d'exclamation | espace fine | espace | mot !_Mot | mot ! Mot |
| | insécable | | | |
|--------------------+--------------+--------------+-----------------+------------|
|Point | espace fine | espace | mot ?_Mot | mot ? Mot |
|d'interrogation | insécable | | | |
|--------------------+--------------+--------------+-----------------+------------|
|Ouvrez les | espace | espace | mot_<quote>mot | mot « mot |
|guillemets | |insécable^[b] | | |
|--------------------+--------------+--------------+-----------------+------------|
|Fermez les | espace | espace | mot</quote>_mot | mot » mot |
|guillemets |insécable^[b] | | | |
|--------------------+--------------+--------------+-----------------+------------|
|Tiret | espace | espace | mot_—_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 | | espace | …_mot | ... mot |
|suspension^[c] | | | | |
|--------------------+--------------+--------------+-----------------+------------|
|Point de | rien | espace | mot…_mot | mot... mot |
|suspension^[d] | | | | |
|--------------------+--------------+--------------+-----------------+------------|
|Point de | espace | espace |mot_…_mot |mot ... mot |
|suspension^[e] | | | | |
|---------------------------------------------------------------------------------|
|[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>. |
| |
|^[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 :
Tableau 3. Espacement de la ponctuation (cas particulier)
+-------------------------------------------------------------------+
|Ponctuation | Avant | Après | Exemple | Exemple |
| | | | (source)^[a] |(résultat) |
|-----------------+----------+----------+---------------+-----------|
|Ouvrez les | espace | espace |mot_« mot | mot « mot |
|guillemets | |insécable | | |
|-----------------+----------+----------+---------------+-----------|
|Fermez les | espace | espace |mot »_mot | mot » mot |
|guillemets |insécable | | | |
|-------------------------------------------------------------------|
|^[a] Le caractère « _ » est utilisé pour représenter une espace |
|normale. |
+-------------------------------------------------------------------+
3.5. Le titre
[3][Important] 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 !
o 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é.
o Le projet de documentation Linux (LDP) [http://www.tldp.org/]
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 |
+------------------------------------------------------------+
o 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>
3.6. Le nom du traducteur et du relecteur
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>
3.7. La version
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 numéros de version des adaptations françaises, on adopte
en général la convention 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>
3.8. La date
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>
3.9. L'historique des révisions
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.
o 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.
o 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.
o 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 :
o Afin de normaliser la présentation des documents publiés,
utilisez le format de date ISO 8601
[http://www.w3.org/QA/Tips/iso-date] 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.
o 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">^[6]Added a part on polarity
reversers.</emphasis>
</revremark>
</revision>
...
</revhistory>
...
</articleinfo>
3.10. Le résumé
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>.
o 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.
o 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.
o 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.
o 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>
3.11. La licence du document
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 :
o 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.
o 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.
o 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.
o 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.
o 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>
3.12. Les adresses électroniques
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>
[4][Avertissement] 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>.
3.13. Les titres des sections
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 | Limitations de responsabilité |
|------------------------------+---------------------------------|
| Feedback | Commentaires et corrections |
+----------------------------------------------------------------+
3.14. La section « 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 :
o 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.
o 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
[http://www.traduc.org/mailman/listinfo/commentaires/]>. 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>
3.15. La section « Nouvelles versions de ce document »
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>
3.16. Les liens et les références
Les liens d'un document doivent être vérifiés et si possible
traduits.
3.16.1. Les liens morts
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.
3.16.2. Traduire les liens
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.
3.16.3. Les liens vers d'autres guides pratiques
3.16.3.1. Le principe
Le site traduc.org [http://www.traduc.org] offre une adresse de
lecture stable pour tous les guides pratiques (howto) du projet de
documentation Linux (LDP) [http://www.tldp.org/]. 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/"/>
3.16.3.2. En pratique
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.3//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/"/>
[5][Note] 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 !
3.17. Les blocs de texte littéral
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é ^_^
[6][Important] 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>
...
[7]1[8]6 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.
[9]2 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.
[10]3 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.
[11]4 Le texte littéral se termine immédiatement avant la
balise de fin de bloc, sans laisser de ligne blanche
entre les deux.
[12]5 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.
3.18. Les scripts et les extraits de code
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 :)
3.19. Les captures d'écrans et les exemples
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.
4. Une fois la traduction terminée
4.1. Vérifier l'orthographe
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
[http://aspell.net]. 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
4.2. Vérifier la structure du document
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.
4.3. Livrer la traduction
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.
5. Relire
L'étape de la relecture doit permettre de vérifier le document,
autant sur la forme que sur le fond. Cette étape peut être
réalisée par une seule personne, mais il est intéressant de faire
relire le document par plusieurs personnes ayant des profils
différents :
1. un relecteur technique pouvant vérifier l'exactitude technique
des informations contenues dans le document, et qui pourra,
dans la mesure du possible, essayer directement les
manipulations indiquées dans le document ;
2. un traducteur expérimenté, dont l'expérience permettra plus
facilement de dénicher les faux amis et les erreurs de
traduction ;
3. un relecteur pour la langue, qui s'assurera que le document
est écrit en bon français, et que les tournures employées ne
sont ni trop lourdes, ni trop familières.
Deux types de relecture doivent être réalisées. Tout d'abord, la
version française doit être relue en parallèle de la version
originale (ce qui sera plutôt fait par un relecteur ayant un
profil de traducteur). Ensuite, une fois que la version française
donne satisfaction par rapport à la version originale, elle doit
être relue indépendemment.
Relire la version française indépendemment de la version originale
est indispensable pour s'assurer que le document traduit sera
clair et compréhensible par un francophone.
5.1. Livrer sa relecture
Il existe de multiples façons de fournir une relecture :
o La méthode la plus classique et la plus employée est de
travailler directement sur une copie du code source de la
version française et d'y intégrer ses corrections.
On peut alors également ajouter des commentaires de relecture
en utilisant des commentaires XML :
<!-- Texte de mon commentaire -->
ou
<!--
Texte très long de mon commentaire
se poursuivant sur de nombreuses
lignes !
-->
Si l'on procède de cette façon, il est recommandé de renvoyer
au traducteur, en plus du fichier source modifié, un résumé
réalisé avec la commande diff des modifications réalisées lors
de la relecture :
diff -u traduction_originale.xml traduction_relue.xml > mes_corrections.diff
o Une solution très simple pour le relecteur est de partir de la
version texte ou html du document et de renvoyer ses
corrections en citant à chaque fois le texte du paragraphe où
la correction s'applique et en expliquant en détail ce qui ne
va pas.
Ce type de correction est surtout approprié pour un document
avec un nombre de corrections assez limité, et il implique un
certain surcroît de travail pour le traducteur.
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>.
A. Annexes
1. Patron DocBook
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.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
<!ENTITY howto "http://www.traduc.org/docs/howto/lecture/">
<!ENTITY guide "http://www.traduc.org/docs/guides/lecture/">
<!ENTITY traduc "http://www.traduc.org">
]>
<article lang="fr">
<articleinfo>
<!--
Merci à Simon Depiets qui a réalisé la version initiale de
ce patron.
-->
<!-- Titre et sous-titre -->
<!--
Si vous voulez être sûr que votre document soit lu,
assurez-vous que le titre français du document soit
simple, clair et compréhensible. Garder le titre
original n'est en général pas un bon choix.
-->
<title>
Petit guide d'exemple de structure XML DocBook
</title>
<subtitle>
Version française du <foreignphrase lang="en">DocBook
Structure Example Mini-HOWTO</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.6.fr.1.0</releaseinfo>
<pubdate>1er août 2004</pubdate>
<!--
La date du document doit être en clair (i. e. en français)
-->
<!-- Auteurs, traducteurs et relecteurs -->
<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>
<!-- Historique des révisions -->
<revhistory>
<revision>
<revnumber>0.6.fr.1.0</revnumber>
<date>2004-08-01</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>BLC, AM</authorinitials>
<revremark>Première traduction française.</revremark>
</revision>
<revision>
<revnumber>0.6</revnumber>
<date>2003-06-17</date>
<authorinitials>JS</authorinitials>
<revremark>
Quelques corrections pour que le document aie une
structure valide. <emphasis lang="en">Some
fixes to get a valid document structure.</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.4</revnumber>
<date>2002-02-20</date>
<authorinitials>JS</authorinitials>
<revremark>
Version initiale. <emphasis lang="en">Initial
revision.</emphasis>
</revremark>
</revision>
</revhistory>
<!-- Résumé du document -->
<abstract><para>
Ce document est un document d'exemple donnant la structure
de base d'une traduction française rédigée selon le format
XML DocBook. Ce document n'est pas intéressant en lui-même.
Tout son intérêt tient en son code source (^_^).
<!--
Ce résumé doit être clair et pouvoir être compris hors
du contexte du document
-->
</para></abstract>
</articleinfo>
<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>jeff CHEZ bab POINT com</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="&traduc;">Traduc.org</ulink> à
l'adresse :
<email>commentaires CHEZ traduc POINT org</email>.
</para>
</section>
<section>
<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;patron.html"/>.
</para>
<para>
La plus récente version originale de ce document est disponible à
l'adresse : <ulink
url="http://www.tldp.org/HOWTO/patron.html"/>.
</para>
</section>
<section>
<title>
Reste du document
</title>
<para>
Bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla.
</para>
<para>
Bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla.
</para>
<para>
Bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla.
</para>
</section>
</article>
2. Produire simplement une version HTML d'un document XML DocBook
Ce court chapitre explique comment produire le plus simplement
possible un document HTML à partir d'un document au format XML
DocBook.
Cette procédure est écrite avec en tête la distribution Linux
Débian. Vous devez avoir installé les paquets suivants :
o docbook-xml
o docbook-xsl
o ldp-docbook-xsl
o xsltproc
Pour commencer, utilisez dpkg pour trouver la feuille de style XSL
du Projet de documentation Linux (LDP). C'est cette feuille de
style que nous allons utiliser pour produire une version HTML de
notre document :
$ dpkg -S tldp-one-page.xsl
ldp-docbook-xsl: /usr/share/xml/docbook/stylesheet/ldp/html/tldp-one-page.xsl
Le résultat de cette commande indique le nom du paquet contenant
la feuille de style en question et le chemin exact vers cette
feuille de style.
[13][Note] Note
Il est possible d'utiliser dlocate^[7], beaucoup plus
rapide, à la place de dpkg -- la ligne de commande
utilisée ne change pas.
Il ne reste plus qu'à utiliser xsltproc pour produire la version
HTML du document :
# Définition du chemin vers la feuille de style
FEUILLE_DE_STYLE="/usr/share/xml/docbook/stylesheet/ldp/html/tldp-one-page.xsl"
# Production de la version HTML
xsltproc "$FEUILLE_DE_STYLE" mon_document.xml > mon_document.html
Et voilà ! C'est fini. Vous disposez maintenant d'une version HTML
de votre document.
2.1. Utiliser un script de production
Pour simplifier la production de version HTML, vous pouvez
utiliser le petit script suivant :
#!/bin/bash
# Chemin vers la feuille de style XSL
# Indiquez ici le chemin approprié à votre environnement
FEUILLE_DE_STYLE="/usr/share/xml/docbook/stylesheet/ldp/html/tldp-one-page.xsl"
# Vérification des paramètres
# Le nombre de paramètres est-il correct ?
if [ "$#" -ne 1 ] ; then
echo "Utilisation : $0 document_source.xml"
exit 1
fi
# Le fichier source existe-t-il ?
SOURCE="$1"
if [ ! -f "$SOURCE" ] ; then
echo "Erreur : $1 est introuvable !"
exit 1
fi
# Le fichier source est-il au format DocBook
FORMAT="OK"
grep -i '<!doctype' $SOURCE | grep -i "DocBook.*XML" \
> /dev/null \
|| FORMAT="KO"
if [ $FORMAT = "KO" ] ; then
echo "Erreur : $SOURCE n'est pas au format XML DocBook !"
exit 1
fi
# Vérification de l'extension du fichier
if ! `echo "$SOURCE" | grep -q -E "\.xml$"` ; then
echo "Erreur : $SOURCE ne se termine pas par « .xml » !"
exit 1
fi
# Calcul du nom du fichier destination
DESTINATION=`echo $SOURCE | sed -e "s/.xml$//"`.html
xsltproc "$FEUILLE_DE_STYLE" "$SOURCE" > "$DESTINATION"
Pour cela, enregistrez ce script sous le nom production.sh, puis
rendez-le exécutable avec la commande suivante :
$ chmod u+x production.sh
Pour produire une version HTML, il ne vous restera plus qu'a
exécuter le script en lui indiquant en paramètre le nom du
document source :
$ ./production.sh document_source.xml
La version HTML sera automatiquement enregistrée dans le fichier
document_source.html.
3. Production de la version HTML de ce guide pratique
Ce court chapitre explique comment produire la version HTML de ce
guide pratique sous Linux.
Ce chapitre explique quels outils utiliser, comment les installer
et se termine par la commande permettant la production de la
version HTML de ce guide pratique. La bibliothèque libxml2 et ses
outils associés sont supposés installés sur votre machine. Les
commandes nécessaire à la production des autres formats sont
laissées en exercice pour le lecteur (^_^)
L'outil utilisé pour produire la version HTML de ce guide pratique
est la version Java 2 de Xalan [http://xml.apache.org/xalan-j/].
[14][Note] Note
Xsltproc, bien qu'il soit plus simple à utiliser, ne
permet pas de produire une version complètement
correcte de ce document. En effet, ce document utilise,
dans un extrait de code, des icônes numérotées de
renvois (callout). Le rendu de ces icônes n'est pas
possible sans utiliser de bibliothèques d'extensions
complémentaires, ce qui est notamment possible avec
Xalan et Saxon.
Dans les étapes qui suivent, lorsque nous installons de nouveaux
outils, nous les installerons dans /usr/local. Si vous n'êtes pas
administrateur de votre machine ou si vous ne souhaitez pas faire
une installation globale, vous remplacez tout simplement ce chemin
par votre répertoire personnel ou un sous-répertoire de celui-ci.
Nous allons commencer par installer le DTD^[2] XML DocBook.
Téléchargez sur http://www.oasis-open.org/docbook/xml/4.3/
[http://www.oasis-open.org/docbook/xml/4.3/] l'archive zip
contenant le DTD et installez-le comme suit :
# Création du dossier où installer le DTD
mkdir /usr/local/docbook-xml-4.3/
# Décompression de l'archive
unzip docbook-xml-4.3.zip -d /usr/local/docbook-xml-4.3/
# Création d'un lien logique docbook-xml
cd /usr/local/
ln -s docbook-xml-4.3 docbook-xml
Pour utiliser ce DTD, vous devrez modifier la variable
d'environnement XML_CATALOG_FILES :
export XML_CATALOG_FILES="/usr/local/docbook-xml/catalog.xml $XML_CATALOG_FILES"
Cette commande devra être répétée à chaque nouvelle session. Pour
simplifier les choses, ajoutez cette commande à vos scripts de
production ou à vos scripts de début de session.
Il nous faut maintenant installer la feuille de style XSL utilisée
pour transformer le XML DocBook en HTML. Téléchargez les feuilles
de style XSL sur : http://docbook.sourceforge.net/projects/xsl/
[http://docbook.sourceforge.net/projects/xsl/] et installez-les
comme suit :
# Décompression et installation de l'archive
tar -xvjf docbook-xsl-1.68.1.tar.bz2 -C /usr/local/
# Création d'un lien logique docbook-xsl
cd /usr/local
ln -s docbook-xsl-1.68.1 docbook-xsl
# Installation de la feuille de style
cd docbook-xsl
sh INSTALL
Téléchargez la feuille de style personnalisée du Projet de
documentation Linux (LDP) [http://www.tldp.org/] sur
http://www.happy-monkey.net/docbook/
[http://www.happy-monkey.net/docbook/] et installez-la comme
suit :
# Décompresser l'archive
tar xvzf tldp-xsl-21MAR2004.tar.gz
# Recopier la feuille de style personnalisée du LDP
# avec la feuille de style XSL DocBook
cp -Rv tldp-xsl-21MAR2004/* /usr/local/docbook-xsl/
Vous n'avez pas besoin de conserver le dossier tldp-xsl-21MAR2004/
après cela.
Nous allons maintenant télécharger et installer l'environnement
d'exécution Java. Vous pourrez le télécharger sur le site de Sun :
http://java.sun.com/j2se/ [http://java.sun.com/j2se/].
# Déplacez l'archive dans /usr/local
mv jre-1_5_0_04-linux-i586.bin /usr/local/
# Exécutez l'installation
cd /usr/local
sh jre-1_5_0_04-linux-i586.bin
Pour utiliser ce moteur d'exécution, vous devrez définir la
variable d'environnement suivante :
export JAVA_HOME=/usr/local/jre1.5.0_04
Nous allons maintenant installer le logiciel Xalan lui-même. Ce
logiciel est disponible sur
http://xml.apache.org/xalan-j/index.html
[http://xml.apache.org/xalan-j/index.html]. Téléchargez la version
binaire de Xalan et installez-la comme ceci :
# Définition du chemin vers l'environnement d'exécution Java
JAVA_HOME=/usr/local/jre1.5.0_04
# Décompression de l'archive
tar xvzf xalan-j-current-bin.tar.gz
# Installation de Xalan dans l'environnement d'exécution Java
cd xalan-j_2_6_0/bin
cp xalan.jar xercesImpl.jar xml-apis.jar "$JAVA_HOME/lib/ext/"
Une fois cette dernière étape faite, vous n'aurez plus besoin de
conserver le dossier xalan-j_2_6_0.
Il ne reste plus qu'à produire la version HTML avec la commande
appropriée :
# Répertoire local d'installation de Java
JAVA_HOME=/usr/local/jre1.5.0_04
# Répertoire d'installation des catalogues XML
#
# - Le premier correspond au catalogue du DTD XML
# DocBook installé en local.
#
# - Le second correspond au catalogue des feuilles
# de style XSL installées en local.
XML_CATALOG_FILES="/usr/local/docbook-xml/catalog.xml $XML_CATALOG_FILES"
# Extensions Java des feuilles de style XSL écrites pour Xalan
EXTENSIONS_XALAN=/usr/local/docbook-xsl/extensions/xalan25.jar
# Feuille de style XSL personnalisée du Projet de documentation Linux
XSL_LDP_MONOHTML=/usr/local/docbook-xsl/html/tldp-one-page.xsl
# Production de la version HTML
$JAVA_HOME/bin/java -classpath "$EXTENSIONS_XALAN" \
org.apache.xalan.xslt.Process \
-IN "Petit-guide-du-traducteur.xml" \
-OUT "Petit-guide-du-traducteur.html" \
-XSL "$XSL_LDP_MONOHTML" \
-PARAM "admon.graphics" "1" \
-PARAM "use.extensions" "1" \
-PARAM "callouts.extensions" "1"
En cas de problème, vous pouvez vérifier que votre installation
est correcte avec la commande suivante :
# Répertoire local d'installation de Java
JAVA_HOME=/usr/local/jre1.5.0_04
# Extensions Java des feuilles de style XSL écrites pour Xalan
EXTENSIONS_XALAN=/usr/local/docbook-xsl/extensions/xalan25.jar
# Production de la version HTML
$JAVA_HOME/bin/java -classpath "$EXTENSIONS_XALAN" \
org.apache.xalan.xslt.EnvironmentCheck
Une fois le document HTML créé, il ne vous reste plus qu'à
récupérer la feuille de style CSS du projet Traduc.org
[http://www.traduc.org] http://tigreraye.org/style.css
[http://tigreraye.org/style.css] et les images correspondant aux
icônes utilisées. Pour les installer, recopiez la feuille de style
style.css et le dossier /usr/local/docbook-xsl/images/ au même
endroit que le fichier HTML :
wget http://tigreraye.org/style.css
cp -Rv /usr/local/docbook-xsl/images .
4. Aide-mémoire des licences libres
Cette annexe est un aide-mémoire des points à respecter lors de
l'adaptation française d'un document distribué selon sa licence.
[15][Avertissement] 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.
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 !
4.1. La licence de documentation libre GNU [GFDL]
La licence de documentation libre GNU [GFDL] est une licence
plutôt bien conçue pour la diffusion de documents. Elle est par
contre assez lourde pour les documents traduits, car elle oblige à
conserver les versions originales d'un certain nombre de passages.
De plus, il n'existe pas de version française officielle de cette
licence, donc, pour bien faire, la version française doit inclure
une copie de la licence officielle en version originale et une
copie de sa version française officieuse.
Les principaux points à respecter sont les suivants :
o Le titre de la version française doit être différent du titre
original (cf. Section 3.5, « Le titre ») ;
o le nom des personnes ayant collaboré à cette traduction doit
être clairement indiqué dans la page de titre (cf.
Section 3.6, « Le nom du traducteur et du relecteur ») ;
o dans la page de titre, le nom de l'éditeur original doit être
remplacé par l'éditeur de la version française (i. e. si le
document est publié par le Projet de documentation Linux
(LDP), la version française sera par exemple publiée par
Traduc.org -- la version française ne doit pas indiquer
qu'elle est publiée par le Projet de documentation Linux à
moins que le projet de documentation Linux n'aie directement
publié cette traduction.)
o Toutes les mentions de copyright, de droits d'auteurs, de
droits d'utilisations et de limitations de responsabilités
(disclaimer) doivent être préservées en version originale dans
le document. Le cas échéant, afin que les lecteurs
francophones puissent comprendre ce dont il s'agit, nous vous
recommandons fortement d'inclure une version française de ces
éléments, en indiquant que seule la version originale fait foi
(cf Section 3.11, « La licence du document ») ;
o la version française doit inclure une copie non modifiée du
texte de la licence (GFDL) et, si possible, une copie de sa
version française officieuse indiquée comme telle ;
o la version française du document doit comporter un historique
des révisions reprenant le texte en version originale de
l'historique et comprenant une entrée additionnelle pour la
version française (cf. Section 3.9, « L'historique des
révisions ») ;
o la version française doit inclure les liens vers la version
originale de référence qui se trouvaient dans la version
originale.
4.2. La licence publique générale GNU [GPL]
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 principaux points à respecter sont les suivants :
o le document final doit indiquer clairement qu'il est une
traduction, le nom du traducteur et la date de la traduction ;
o chacun des fichiers sources traduits doit indiquer clairement
qu'il est une traduction, le nom du traducteur et la date de
la traduction ;
o le document traduit doit être distribué selon les termes de la
licence GPL ;
o lorsque le document est distribué, il doit être accompagné de
son code source.
5. Licence Art libre
Version 1.2
5.1. Préambule
Avec cette Licence Art libre, l'autorisation est donnée de copier,
de diffuser et de transformer librement les ½uvres dans le respect
des droits de l'auteur.
Loin d'ignorer les droits de l'auteur, cette licence les reconnaît
et les protège. Elle en reformule le principe en permettant au
public de faire un usage créatif des ½uvres d'art.
Alors que l'usage fait du droit de la propriété littéraire et
artistique conduit à restreindre l'accès du public à l'½uvre, la
Licence Art libre a pour but de le favoriser.
L'intention est d'ouvrir l'accès et d'autoriser l'utilisation des
ressources d'une ½uvre par le plus grand nombre. En avoir
jouissance pour en multiplier les réjouissances, créer de
nouvelles conditions de création pour amplifier les possibilités
de création. Dans le respect des auteurs avec la reconnaissance et
la défense de leur droit moral.
En effet, avec la venue du numérique, l'invention de l'internet et
des logiciels libres, un nouveau mode de création et de production
est apparu. Il est aussi l'amplification de ce qui a été
expérimenté par nombre d'artistes contemporains.
Le savoir et la création sont des ressources qui doivent demeurer
libres pour être encore véritablement du savoir et de la création.
C'est à dire rester une recherche fondamentale qui ne soit pas
directement liée à une application concrète. Créer c'est découvrir
l'inconnu, c'est inventer le réel avant tout souci de réalisme.
Ainsi, l'objet de l'art n'est pas confondu avec l'objet d'art fini
et défini comme tel.
C'est la raison essentielle de cette Licence Art libre :
promouvoir et protéger des pratiques artistiques libérées des
seules règles de l'économie de marché.
5.2. DÉFINITIONS
L'½uvre
il s'agit d'une ½uvre commune qui comprend l'½uvre
originelle ainsi que toutes les contributions postérieures
(les originaux conséquents et les copies). Elle est créée
à l'initiative de l'auteur originel qui par cette licence
définit les conditions selon lesquelles les contributions
sont faites.
L'½uvre originelle
c'est-à-dire l'½uvre créée par l'initiateur de l'½uvre
commune dont les copies vont être modifiées par qui le
souhaite.
Les ½uvre conséquentes
c'est-à-dire les propositions des auteurs qui contribuent
à la formation de l'½uvre en faisant usage des droits de
reproduction, de diffusion et de modification que leur
confère la licence.
Original (source ou ressource de l'½uvre)
exemplaire daté de l'½uvre, de sa définition, de sa
partition ou de son programme que l'auteur présente comme
référence pour toutes actualisations, interprétations,
copies ou reproductions ultérieures.
Copie
toute reproduction d'un original au sens de cette licence.
Auteur de l'½uvre originelle
c'est la personne qui a créé l'½uvre à l'origine d'une
arborescence de cette ½uvre modifiée. Par cette licence,
l'auteur détermine les conditions dans lesquelles ce
travail se fait.
Contributeur
toute personne qui contribue à la création de l'½uvre. Il
est l'auteur d'une ½uvre originale résultant de la
modification d'une copie de l'½uvre originelle ou de la
modification d'une copie d'une ½uvre conséquente.
5.3. OBJET
Cette licence a pour objet de définir les conditions selon
lesquelles vous pouvez jouir librement de cette ½uvre.
5.4. L'ÉTENDUE DE LA JOUISSANCE
Cette ½uvre est soumise au droit d'auteur et l'auteur par cette
licence vous indique quelles sont vos libertés pour la copier, la
diffuser et la modifier :
5.4.1. LA LIBERTÉ DE COPIER (OU DE REPRODUCTION)
Vous avez la liberté de copier cette ½uvre pour un usage
personnel, pour vos amis, ou toute autre personne et quelle que
soit la technique employée.
5.4.2. LA LIBERTÉ DE DIFFUSER, D'INTERPRÉTER (OU DE
REPRÉSENTATION)
Vous pouvez diffuser librement les copies de ces ½uvres, modifiées
ou non, quel que soit le support, quel que soit le lieu, à titre
onéreux ou gratuit si vous respectez toutes les conditions
suivantes :
o joindre aux copies, cette licence à l'identique, ou indiquer
précisément où se trouve la licence,
o indiquer au destinataire le nom de l'auteur des originaux,
o indiquer au destinataire où il pourra avoir accès aux
originaux (originels ou conséquents). L'auteur de l'original
pourra, s'il le souhaite, vous autoriser à diffuser l'original
dans les mêmes conditions que les copies.
5.4.3. LA LIBERTÉ DE MODIFIER
Vous avez la liberté de modifier les copies des originaux
(originels et conséquents), qui peuvent être partielles ou non,
dans le respect des conditions prévues à l'article Section 5.4.2,
« LA LIBERTÉ DE DIFFUSER, D'INTERPRÉTER (OU DE REPRÉSENTATION) »
en cas de diffusion (ou représentation) de la copie modifiée.
L'auteur de l'original pourra, s'il le souhaite, vous autoriser à
modifier l'original dans les mêmes conditions que les copies.
5.5. L'INCORPORATION DE L'¼UVRE
Tous les éléments de cette ½uvre doivent demeurer libres, c'est
pourquoi il ne vous est pas permis d'intégrer les originaux
(originels et conséquents) dans une autre ½uvre qui ne serait pas
soumise à cette licence
5.6. VOS DROITS D'AUTEUR
Cette licence n'a pas pour objet de nier vos droits d'auteur sur
votre contribution. En choisissant de contribuer à l'évolution de
cette ½uvre, vous acceptez seulement d'offrir aux autres les mêmes
droits sur votre contribution que ceux qui vous ont été accordés
par cette licence.
5.7. LA DURÉE DE LA LICENCE
Cette licence prend effet dès votre acceptation de ses
dispositions. Le fait de copier, de diffuser, ou de modifier
l'½uvre constitue une acception tacite.
Cette licence a pour durée la durée des droits d'auteur attachés à
l'½uvre. Si vous ne respectez pas les termes de cette licence,
vous perdez automatiquement les droits qu'elle vous confère.
Si le régime juridique auquel vous êtes soumis ne vous permet pas
de respecter les termes de cette licence, vous ne pouvez pas vous
prévaloir des libertés qu'elle confère.
5.8. LES DIFFÉRENTES VERSIONS DE LA LICENCE
Cette licence pourra être modifiée régulièrement, en vue de son
amélioration, par ses auteurs (les acteurs du mouvement « copyleft
attitude ») sous la forme de nouvelles versions numérotées.
Vous avez toujours le choix entre vous contenter des dispositions
contenues dans la version sous laquelle la copie vous a été
communiquée ou alors, vous prévaloir des dispositions d'une des
versions ultérieures.
5.9. LES SOUS-LICENCES
Les sous-licences ne sont pas autorisées par la présente. Toute
personne qui souhaite bénéficier des libertés qu'elle confère sera
liée directement à l'auteur de l'½uvre originelle.
5.10. LA LOI APPLICABLE AU CONTRAT
Cette licence est soumise au droit français.
--------------
^[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] 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] Les documents SGML aux formats LinuxDoc et DocBook utilisent
par défaut le codage latin 1.
^[4] 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.
^[5] Représentée par l'entité .
^[6] 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
».
^[7] dlocate fait partie du paquet dlocate ^_^
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
ebac5394abc62d2e0b61505bfba9712a
>
files
>
168
