Foire aux questions de la liste debian–l10n–french

            Patrice Karatchentzeff <p.karatchentzeff@free.fr>

Version 1.11

Résumé

Ce document est la foire aux questions de la liste de diffusion debian–l10n–french qui a pour but de franciser Debian. Il rassemble les questions les plus fréquemment posées sur la liste, de façon à répondre rapidement à toutes les questions que se posent les nouveaux arrivants. Veuillez donc lire avec attention le document suivant de façon à éviter de poser une question dont la réponse se trouve ci–après.

Copyright

Copyright \begin{matrix}c \\ ◯ \end{matrix} 2001 Patrice Karatchentzeff Contributeur :

– Martin Quinson (auteur original de la partie « Traduire pour Debian (et pour le logiciel libre) »

– Youssef Oualmakran (auteur original de la partie « Comment traduire les descriptions de paquets Debian »)

Ce manuel est distribué dans l’espoir qu’il vous sera utile mais sans aucune garantie. Il est distribué sous la licence « GNU General Public License », version 2 ou suivante. Pour obtenir cette licence, lisez /usr/doc/copyright/GPL dans votre distribution Debian GNU–Linux ou

sur la toile http://www.gnu.org/copyleft/gpl.html

\underline{i}

Table des matières

1 La vie de la liste 1 1.1 Où trouver cette FAQ ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Comment lire cette FAQ ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Comment s’abonner ? se désabonner ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 Comment se règlent les différends ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 Je n’ai plus le temps de (ou je ne veux plus) participer . . . . . . . . . . . . . . . . . . . 2 1.6 Quelle est la fréquentation du forum ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.7 Quels sont les critères pour participer ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.8 Qui est le responsable ? (Qui contacter en cas de…) . . . . . . . . . . . . . . . . . . . . 3 1.9 Où est archivée la liste ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.10 Qui est René Cougnenc ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Techniques 5 2.1 Quel est le format des traductions ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Comment apprendre le format debian–doc sgml et wml ? . . . . . . . . . . . . . . . . 5 2.3 Quelle traduction choisir ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Comment se déclarer traducteur ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Comment récupérer la responsabilité d’une traduction ? . . . . . . . . . . . . . . . . . . 7 2.6 Comment récupérer un document ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7 Comment éditer une traduction ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8 Comment modifier une traduction ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.9 Comment m’assurer que je n’ai pas modifié une balise par inadvertance ? . . . . . . . . 9 2.10 Quels sont les paquets Debian nécessaires à la compilation d’un document ? . . . . . . . 9 2.11 Comment compile–t–on un document au format sgml ? . . . . . . . . . . . . . . . . . 9 2.12 Comment obtenir une sortie imprimable d’un document ? . . . . . . . . . . . . . . . . . 10 2.13 Y a–t–il un site ou une référence pour les traductions ? . . . . . . . . . . . . . . . . . . 10

2.13.1 Vocabulaire spécifique à Debian . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.13.2 Vocabulaire spécifique à Debian–Hurd . . . . . . . . . . . . . . . . . . . . . . . 11 2.13.3 Vocabulaire spécifique à l’informatique . . . . . . . . . . . . . . . . . . . . . . 11 2.13.4 Faux–amis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.13.5 Termes polémiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.14 Comment poster une traduction ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.15 Comment relire une traduction ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.16 Comment poster une relecture ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.17 Comment demander de l’aide ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.18 Que devient un document traduit ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.19 Qu’est–ce qui fait référence en matière de traduction pour Debian ? . . . . . . . . . . . . 15

3 Traduire pour Debian (et pour le logiciel libre en général) 17

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1 Que traduire dans un paquet ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.2 Les pour et les contre de la traduction dans Debian . . . . . . . . . . . . . . . . 21

3.2 Comment aider : la partie administrative . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.1 Coordination entre traducteurs au sein de Debian . . . . . . . . . . . . . . . . . 22 3.2.2 Coordination entre traducteurs et développeurs Debian . . . . . . . . . . . . . . 23 3.2.3 Coordination entre Debian et le reste du monde . . . . . . . . . . . . . . . . . . 23 3.2.4 En résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Comment traduire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.1 Choisir sa cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.2 Comment récupérer le matériel à traduire . . . . . . . . . . . . . . . . . . . . . 25 3.3.3 Comment traduire les catalogues po ? . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.4 Comment traduire les templates Debconf ? . . . . . . . . . . . . . . . . . 26 3.3.5 Comment traduire les descriptions de paquets Debian ? . . . . . . . . . . . . . . 27 3.3.6 Comment traduire les pages de manuel ? . . . . . . . . . . . . . . . . . . . . . . 29 3.3.7 Comment traduire les fichiers info ? . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.8 Comment traduire la documentation ? . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Conclusion, avenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4 Vieux débats classés… 31

4.1 Pourquoi « paquet » et pas « paquetage » ? . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Pourquoi ne peut–on pas mettre d’image dans le format debian–doc ? . . . . . . . . . . . 31 4.3 Peut–on changer une traduction établie dans le lexique ? . . . . . . . . . . . . . . . . . 31

5 Règles typographiques de base 33

5.1 Règles typographique de la langue française . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1 La ponctuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.2 Règles basiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.1.3 Les outils d’aide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

TABLE DES MATIÈRES  iv

\underline{1}

Chapitre 1

La vie de la liste

1.1 Où trouver cette FAQ ?

Vous trouverez les sources (au format sgml debian–doc) de cette FAQ sur le serveur cvs de Debian :

/cvs/webwml/french/international/french/debian–l10–french–faq.sgml

(voir « Comment récupérer un document ? ») et en ligne sur le serveur de Debian à l’adresse :

http://www.debian.org/intl/french/debian-l10-french-faq.html/

Pour contribuer, me contacter directement ou poster sur debian–l10n–french.

1.2 Comment lire cette FAQ ?

J’ai essayé, suite à différentes remarques, de satisfaire tout le monde. Du coup, chaque point important est divisé en deux parties : une partie destinée à celui qui a besoin de l’information rapidement et sans fioriture et une autre plus développée avec explications techniques à la clé.

1.3 Comment s’abonner ? se désabonner ?

Tout est détaillé dans la page http://www.debian.org/intl/French.fr.html.

Si vous n’avez pas accès à http, il vous suffit d’envoyer un courriel à debian–l10n–french–request@lists.debian.org avec DANS LE CORPS DU MESSAGE :

        subscribe <votre_adresse_électronique>

Pour se désabonner, la procédure est indiquée sur chacun des courriels reçus de la liste de diffusion. Il vous suffit d’envoyer un courriel à debian–l10n–french–request@lists.debian.org avec DANS LE CHAMP SUJET :

        unsubscribe

1.4 Comment se règlent les différends ?

À coups de poings virtuels, bien sûr :–)

En fait, en cas de désaccord sur une traduction (un terme, un sens général…), on fait un vote des gens inscrits. Un inscrit participant vaut une voix. Tout le reste ne vaut rien. Personne ne vaut plus qu’un autre. La démocratie, quoi :–).

Bon, le tout est d’arriver à un consensus pour pouvoir continuer. Ne pas oublier quand même que l’on n’est pas là pour se battre sur la terminologie mais pour faire avancer la francisation de Debian.

Le pouvoir ici se résume à la traduction de documents en français. Et uniquement cela. Pour tout le reste du projet Debian, la liste ici n’a aucun pouvoir.

Il y a quand même une règle non écrite en cas de litige profond : c’est au final toujours celui qui est l’auteur du document qui peut imposer son point de vue en vertu du fait que c’est lui qui a fait l’effort de créer le premier document. Bien sûr, il est rare d’en arriver à de telles extrémités…

1.5 Je n’ai plus le temps de (ou je ne veux plus) participer

Il se peut que, débordé par votre vie professionnelle ou familiale, vous n’ayez plus de temps à consacrer à la traduction pour Debian. Si vous étiez responsable de traduction, il est bon alors de contacter un des responsables de la liste ou d’y poster un message en disant que vous renoncez à votre charge, de façon à faciliter la maintenance des projets de traductions.

1.6 Quelle est la fréquentation du forum ?

Faible. Quelques messages par semaine, sauf les jours de grands débats :–). Cela dit, cela a notablement augmenté ces derniers temps. La rançon du succès ?

On pourra visualiser l’état de la fréquentation de la liste directement sur le site Debian à

http://lists.debian.org/stats/

1.7 Quels sont les critères pour participer ?

Être volontaire. Et surtout, être volontaire. Et puis, enfin, être volontaire. Si en plus, vous êtes volontaire…

Tous les gens inscrits peuvent (doivent…) participer au débat et surtout aux relectures. Pas de fausse pudeur…

Pour participer, il vous suffit de savoir lire et écrire correctement le français. Pas besoin d’être Molière ni Rabelais : il vous suffit de savoir vous servir d’un éditeur de texte.

1.8 Qui est le responsable ? (Qui contacter en cas de…)

Il y a maintenant un triumvirat responsable de cette liste :

        Denis Barbier <barbier@imacs.polytechnique.fr>,
        Christophe Le Bars <clebars@debian.org>,
        Martin Quinson <mquinson@ens-lyon.fr>.

On peut aussi aller directement sur le site Debian pour obtenir cette information :

http://www.fr.debian.org/devel/website/translation_coordinators

Ce sont les gens qui ont les droits d’accès au cvs du serveur Debian et qui peuvent archiver les traductions au fur et à mesure de leur arrivée. Ils ont aussi pour rôle d’essayer de faire régner l’harmonie et l’amour entre les participants de la liste ;–)

1.9 Où est archivée la liste ?

http://lists.debian.org/i18n.html

Puis allez cliquer dans le mois–année qui vous intéresse dans debian–l10–french.

http://lists.debian.org/debian-l10n-french/

1.10 Qui est René Cougnenc ?

René Cougnenc fut un des précurseurs de Linux en France et il a contribué à sa diffusion par la qualité de ses traductions. Un certain nombre d’ouvrages faisant encore référence ont été traduits de sa main (liste chez O’Reilly).

René nous a quitté il y a quelques années.

Comme ses traductions sont remarquables, nous y faisons souvent référence.

Chapitre 1. La vie de la liste  4

Chapitre 2

Techniques

2.1 Quel est le format des traductions ?

Le format retenu pour la documentation Debian est le sgml : il s’agit du format debian–doc dont la documentation est livrée avec toutes les distributions Debian (cf. « Comment apprendre le format debian–doc sgml ? »).

En ce qui concerne le format des pages du site oueb de Debian, le format retenu est le wml. Il est peu probable que vous ayez directement à créer une page donc une connaissance très approximative de ce format est suffisante. Il s’agit en fait de html.

Enfin, il y a des documents plus particuliers comme les pages de manuels ou les logiciels spécifiques à Debian (comme dpkg ou apt). Pour le coup, il vaut mieux savoir un peu ce que l’on fait avant de se jeter sur ce type de traduction. Pour plus de détails, voir le chapitre « Traduire pour Debian (et pour le logiciel libre en général) ».

2.2 Comment apprendre le format debian–doc sgml et wml ?

Il existe deux documents, l’un en anglais et l’autre traduit en français. Le premier est disponible dans le paquet debiandoc–sgml et le second dans le paquet doc–debian–fr. Ils sont donc livrés en standard dans chaque distribution Debian.

On peut aussi trouver directement le document en français sur le site de Debian à

http://people.debian.org/~clebars/f2dp/translations/markup.fr.html/

2.3 Quelle traduction choisir ?

De préférence une traduction qui ne soit pas en cours ou maintenue activement par quelqu’un. Cela dépend un peu de vos compétences et de votre temps disponible. Ne soyez pas trop gourmand au début : commencez par quelque chose de court pour vous faire la main.

Pour éviter de se noyer dans la masse des documents à traduire, Martin Quinson a écrit un petit script pour faciliter et automatiser la recherche. Son script, en fait, synchronise les pages traduites avec les pages originales. Voici comment cela fonctionne^{1} :

Il faut avoir en local (c’est–à–dire sur son disque dur) toutes les pages anglaises et françaises. Mettez à jour régulièrement l’ensemble par cvs. Ensuite pour chaque page anglaise, sa version cvs (listée dans le CVS/Entries du répertoire où se trouve le document) est récupérée. Puis, il essaie de déterminer si la page française traduite existe. Dans l’affirmative, il cherche à déterminer si la version de traduction est conforme. Pour cela, il tente d’extraire l’information de la ligne

#use wml : :debian : :translation–check translation=“X.x" maintainer="aze”

du document. C’est un en–tête obligatoire des documents comme l’indique le document :

http://www.fr.debian.org/devel/website/uptodate

Le script /cvs/webwml/check_trans.pl détermine ainsi ce qui est à jour ou non. De plus, il envoie automatiquement un courriel au responsable de la traduction du document en cas de changement pour le prévenir. Pour cela, il faut que ledit responsable ait préalablement indiqué dans le fichier /cvs/webwml/french/international/french/translator.db.pl son adresse électronique et la fréquence avec laquelle il veut recevoir ces notifications.

En pratique, pour choisir une traduction, il faut récupérer les sources des documents par cvs des pages anglaises et françaises (cf. « Comment utiliser cvs ? »). Ensuite, il faut lancer le script précité, sans l’option –m qui active l’envoi des courriels, et en précisant la langue (par exemple, ./check_trans.pl

french.

À ce moment, le script va vous renvoyer plein de lignes NeedToUpdate et Missing. Il suffit alors de choisir un document manquant (ligne Missing).

On peut aussi consulter ces informations en ligne sur http://www.debian.org/devel/website/

stats/fr.html ou de manière plus détaillée sur http://www.debian.org/intl/french/

www-untranslated.fr.html (la page est bien sûr beaucoup plus lourde que la précédente).

2.4 Comment se déclarer traducteur ?

Il suffit de poster un message sur la liste de diffusion debian–l10n–french déclarant que vous allez vous occuper de tel document, si personne ne le fait déjà. Dans ce cas, généralement, il y a approbation simple d’un des responsables des traductions et vous devenez automatiquement responsable de la traduction que vous avez choisie. Vous en devenez aussi le responsable officiel, c’est–à–dire qu’il vous incombe de suivre le document original et de modifier la traduction le cas échéant. Vous devez de plus rassembler les relectures qui vous seront adressées sur la liste et corriger votre texte en conséquence.

Si par hasard vous n’avez pas reçu d’approbation, vous pouvez vous considérer comme nommé responsable automatiquement. Faites bien attention toutefois que le courriel destiné à la liste a bien été acheminé… Attendez quand même un ou deux jours avant de vous lancer.

Si quelqu’un s’occupe déjà du document, il le fera savoir.

1Vous n’êtes bien sûr pas obligé d’en comprendre les mécanismes internes pour vous en servir : l’explication est ici juste dans un but pédagogique.

2.5 Comment récupérer la responsabilité d’une traduction ?

Il arrive qu’un traducteur n’ait plus le temps de poursuivre son travail. Et vous avez envie de prendre la suite (le document a par exemple beaucoup de retard dans la mise à jour…). Il vous suffit de contacter directement le responsable ou bien de vous déclarer sur la liste. Dans ce dernier cas, il vous faudra attendre obligatoirement une confirmation d’un responsable qui contactera lui–même l’ancien responsable.

Il est d’usage de réattribuer une traduction si rien n’en est sorti au bout de deux mois et que le responsable officiel ne donne plus signe de vie.

2.6 Comment récupérer un document ?

L’ensemble de la documentation est géré par cvs sur le site de Debian. C’est un outil permettant de régler les problèmes de versions avec aisance. Par mesure de prudence, seuls les responsables officiels de la liste ont le droit d’accès en écriture via cvs. Par contre, tout le monde y a accès en lecture. Cela permet de récupérer n’importe quel document très facilement. Voici deux pages d’explications :

http://www.debian.org/intl/french/cvs.fr.html
http://www.debian.org/devel/website/using_cvs.fr.html

Si vous n’êtes pas connecté en lisant ces lignes, voici un rapide résumé des opérations à effectuer :

Créez–vous un répertoire local de travail :

      mkdir debian
      cd debian

Positionnez la variable CVSROOT correctement :

      export CVSROOT=":pserver:anonymous@cvs.debian.org:/cvs/webwml"

Pour éviter de le faire à chaque fois, inscrivez–la en dur dans votre fichier de configuration de shell par défaut. Si vous ne savez pas ce que vous utilisez, mettez–le par défaut dans votre ~/.bashrc.

La première fois, vous aurez à taper :

      cvs login

et ensuite sur la touche Entrée lorsque cvs demandera le mot de passe.

Toujours la première fois, vous aurez à valider (co : check–out) chaque nouvelle entrée dans l’arborescence :

       cvs co <nom du répertoire>

puis, pour mettre à jour (update), faire régulièrement

      cvs update <nom de répertoire>

Exemple :

      cvs co webwml/english
      cvs co webwml/french/Bugs

Ceci créera dans le répertoire debian une image du site Debian contenant le répertoire webwml contenant lui–même le contenu de english et celui de french/Bugs.

Le répertoire english est très gros mais je conseille de le faire, même avec un modem. Au 14 octobre 2001, il faisait environ 18 mégaoctets. Un petit mauvais moment à passer. Les mises à jour ne sont pas du tout coûteuse. Le répertoire french est lui plus petit (4,8 Mo le 14 octobre 2001).

2.7 Comment éditer une traduction ?

Il faut récupérer le document original sur le cvs de Debian au format sgml pour un document et wml pour une page oueb. Le document est alors en ASCII s’il ne comporte que la langue anglaise et en iso–latin 1 (ou 15) s’il comporte du français. Les accents sont autorisés (et même chaudement recommandés :–) Vous pouvez donc l’éditer avec n’importe quel (bon) éditeur de texte. Ceux qui permettent la mise en couleur de balises favorisent évidemment le travail du traducteur–relecteur.

Si vous ne connaissez rien aux éditeurs de texte, j’ai fait une introduction à Emacs destinée aux débutants sur mon site :

http://p.karatchentzeff.free.fr/freesoft/emacs/html

Cela peut vous servir de base de départ. L’emploi d’un mode ad hoc comme le psgml–mode peut grandement vous aider. Voir la page de Stéphane Bortzmeyer à ce sujet :

http://people.debian.org/~bortz/SGML-HOWTO/potato/x323.html

Si vous partez d’un document vierge, il suffit de coller au document original en respectant scrupuleusement les balises initiales. Tout ce qui est à l’extérieur des balises doit être traduit. Les balises doivent toutes être conservées. À l’exception de l’attribut name de la balise url qui doit être traduit.

2.8 Comment modifier une traduction ?

De la même façon que pour un nouveau document mais en partant cette fois d’un document déjà traduit. Si la dernière traduction est trop ancienne, il peut être judicieux de repartir d’une feuille blanche.

Vous devez aussi inclure votre nom comme traducteur ou l’ajouter à celui qui vous a précédé dans ce travail. Pour cela, il suffit d’ajouter au–dessous des auteurs originaux :

       <author>
       Jean Dupont
      <email> jean.dupont@fai.fr </email>
       </author>

Même si vous repartez d’une feuille blanche, conservez le(s) nom(s) de celui ou ceux qui vous ont précédé dans la traduction du document.

2.9 Comment m’assurer que je n’ai pas modifié une balise par inadvertance ?

La meilleure méthode consiste encore à compiler votre document s’il s’agit d’un format debian–doc ou bien de l’éditer dans un butineur html s’il s’agit d’un document wml.

2.10 Quels sont les paquets Debian nécessaires à la compilation d’un document ?

Il vous faudra installer le paquet debiandoc–sgml. Pour ce faire, acquérez les droits de root et faites :

      $ apt-get install debiandoc-sgml

Et c’est tout.

2.11 Comment compile–t–on un document au format sgml ?

Tout d’abord, vous devez avoir installé le paquet debiandoc–sgml (cf. « Quels sont les paquets Debian nécessaires à la compilation d’un document ? »).

Vous devez avoir sur votre système la série d’utilitaires suivante :

      /usr/bin/debiandoc2html
      /usr/bin/debiandoc2latex
      /usr/bin/debiandoc2texinfo
      /usr/bin/debiandoc2text
      /usr/bin/debiandoc2textov
      /usr/bin/debiandoc2info
      /usr/bin/debiandoc2latexdvi
      /usr/bin/debiandoc2latexpdf
      /usr/bin/debiandoc2latexps

Ces commandes permettent une transformation aisée du document sgml vers le format de sortie de votre choix (ici, dans l’ordre de la série précédente : html, LaTeX, texte, textov (troff), info, dvi, pdf et PostScript.

Si vous désirez une sortie en PostScript, vous n’avez alors qu’à taper la commande suivante :

      $ debiandoc2latexps MonDocument.sgml

Si le document compile sans erreur, vous obtiendrez alors dans le répertoire en cours le document Mon-Document.ps en PostScript. Il en va de même pour tous les formats de conversion.

Si la compilation tourne mal, debiandoc2xxx s’arrête et renvoie sur la sortie standard l’erreur en anglais qui l’a fait se planter. Comme les numéros de ligne et de colonne sont fournis, il est aisé d’aller enquêter et de déterminer l’erreur (la plupart du temps, c’est un problème d’ouverture–fermeture de balises…). Il y a aussi à ce moment un fichier MonDocument.sasp qui est engendré automatiquement.

N’hésitez pas à aller lire la documentation afférente à ces outils.

2.12 Comment obtenir une sortie imprimable d’un document ?

Il vous est peut–être plus facile de relire la documentation sur papier pour différentes raisons (la première généralement est que l’écran de votre ordinateur et la baignoire ne font pas bon ménage…).

Le site Debian ne propose la documentation que sous sa forme de sources (sgml ou wml). Donc, vous allez devoir le faire vous–même. Récupérez le document source, de toute façon indispensable à l’annotation des erreurs et compilez–le vous–même. Reportez–vous à la question « Comment compile– t–on un document au format sgml ? » pour ce faire.

Si votre système d’impression est bien configuré sous votre Debian, la méthode la plus rapide consiste à obtenir du dvi. Vous pourrez l’imprimer directement en tapant tout simplement la commande lpr. Sinon, utilisez du PostScript ou du pdf suivant la configuration de votre environnement. Si vous n’y arrivez pas, faites–vous aider pour la configuration de votre système.

Il n’y a rien d’analogue pour les pages du site au format wml. Vous pouvez toujours les éditer dans un butineur html et tenter de les imprimer directement. Sachez toutefois qu’il existera toujours une ligne en en–tête du document, du genre :

#use wml : :debian : :template title=“Lexique du projet de traduction de Debian”

qui n’est évidemment pas une erreur ;–)

2.13 Y a–t–il un site ou une référence pour les traductions ?

La page de départ est

http://www.debian.org/intl/french/ltcp.fr.html

Pour les traducteurs et relecteurs, un lexique de base est disponible à :

http://www.debian.org/intl/french/aide.fr.html

Pour ceux qui ne sont pas connectés, voici un petit lexique (qui sera forcément moins à jour que la page ci–dessus) :

2.13.1 Vocabulaire spécifique à Debian

      backport ............ :  portage arrière, rétroportage
      bug tracking system . :  système de suivi des bogues
      dependency .......... :  dépendance (pour dpkg)
      diversion ........... :  détournement (pour dpkg)

diverted ............ :  détourné (pour dpkg)
essential ........... :  essentiel (pour dpkg)
maintainer .......... :  responsable
newsletter (DWN) .... :  gazette
on hold ............. :  gelé, {à garder, bloquer, en suspens,
                             en attente, préservé, maintenu}(pour dpkg)
overriding .......... :  recouvrement (pour dpkg)
package ............. :  paquet
package management .. :  gestion des paquets
release note ........ :  carnet de lancement (?), note de version,
                             numéro de version
selected ............ :  sélectionné (pour dpkg)
to divert ........... :  détourner (pour dpkg)
unpacked ............ :  dépaqueté
unpacking ........... :  dépaquetage
update .............. :  mise à jour
upgrade ............. :  mise à niveau

2.13.2 Vocabulaire spécifique à Debian–Hurd

translator  ............ :  traducteur

2.13.3 Vocabulaire spécifique à l’informatique

(device) driver ........ : pilote ou gestionnaire (de périphérique)
FAQ .................... : Foire aux questions
RAM disk ............... : disque virtuel, image de disque en mémoire
accounting ............. : comptabilité
back-end ............... : dorsal, de sortie (suivant contexte)
block device files ..... : fichiers de périphérique en mode bloc
buffering .............. : retenir, mettre en mémoire
character device files . : fichiers de périphérique en mode caractère
checksums .............. : (MD5 checksum -> code de contrôle MD5),
                               code de contrôle
depot .................. : dépôts, entrepôt,
downgrade .............. : remise à un niveau inférieur,
                               « abaissement du niveau », mise à jour
e-mail ................. : courrier, courriel, adresse électronique
error handler .......... : routine de traitement d'erreurs
failure ................ : échec
file details field ..... : champ des détails du fichier
force .................. : forçage
front-end .............. : interface, frontal, surcouche,
                               lanceur de programme

garbage ................ : résidu
incorporated ........... : intégré, incorporé
linker ................. : éditeur de liens
mailing list ........... : liste de diffusion
matching ............... : correspondance, identification
out of memory .......... : mémoire insuffisante
patch .................. : rustine
padding ................ : remplissage
pattern ................ : motif, modèle
plain file ............. : vrai fichier (?) fichier ASCII, régulier (?)
regular expressions .... : expressions rationnelles
repository ............. : référentiel
support ................ : assistance
timestamps ............. : cachet de date (pour les tar.po)
to fsync ............... : synchroniser (?) synchroniser des fichier par fsync
to overwrite ........... : remplacer
to rewind .............. : revenir, rembobiner, recommencer
to seek ................ : rejoindre, atteindre, traverser
to set ................. : paramétrer
to scan ................ : numériser
to stat ................ : analyser (?) extraire à des fins statis-
tiques (?)
trailing garbage ....... : résidus restant
transceiver ............ : émetteur-récepteur, « transcepteur »
                               (néologisme, à éviter si possible),
                                micro-transmetteur (expression utilisée
                                dans certaines docs, mais incorrecte)
unable ................. : impossible de, préférer « incapacité à » ou
                                « je ne peux pas »
unable seek ............ : déplacement impossible, destination impossible

2.13.4 Faux–amis

alternative ............ : solution de remplacement, de rechange , (?)
completion ............. : complètement
compress ............... : comprimer
couple ................. : quelques
decade ................. : décennie
generate ............... : engendrer, fabriquer, produire
library ................ : bibliothèque
pipe ................... : tube
status  ................ : état

2.13.5 Termes polémiques

(dans cette partie sont regroupés les termes dont l’usage n’a pas encore décidé sous quelle forme ils vont être figés. Le traducteur a donc la liberté de choisir la forme de celui qui lui paraît être la meilleure)

      CD-ROM ..............  : cédérom, CD-ROM
      DVD-ROM .............  : dévédérom, DVD-ROM (?)
      epoch ...............  : époque

2.14 Comment poster une traduction ?

Une fois votre traduction terminée, vous n’avez plus qu’à la poster directement sur la liste de diffusion afin de la soumettre à relecture. Vous pouvez aussi très bien la faire relire par d’autres personnes complètement extérieures. Mais elle doit être obligatoirement postée sur la liste.

Le document doit être posté tel quel et dans la mesure du possible livré en attaché (pour faciliter un traitement ultérieur automatique). Il serait aussi pratique de positionner le type MIME en text/plain avec un encodage favorisant une intervention directe comme le 8 bits (évitez l’uuencodage si possible). Si vous êtes sous Linux, créez un fichier \$HOME/.mime.types contenant text/plain wml diff patch devrait suffire. Il faut indiquer le nom du document et aussi sa révision, en demandant sa relecture. Sauf empêchement majeur, le document sera archivé rapidement sur le cvs de Debian en l’état, à charge au responsable de centraliser les relectures et d’apporter les modifications nécessaires. Il pourra alors déposer une nouvelle version qui mettra ainsi à jour le cvs de Debian jusqu’au document final.

Si le document est déraisonnablement trop gros pour être posté sur la liste (pensez que tout le monde n’a pas une liaison haut débit (i.e. qui commence à 56 kbps)), il vaut mieux contacter en privé ou sur la liste les responsables de la liste. Le document leur sera alors À LEUR DEMANDE envoyé personnellement et ils s’occuperont de sa mise en place sur le site de Debian. Une annonce sera postée alors sur la liste pour un appel à relecture avec le pointeur ad hoc.

En ce qui concerne le format du messagee, soyez raisonnable : une petite page en wml pourra être postée dans le corps du message ou en attaché tandis qu’un diff conséquent sera attaché après avoir été gzipé.

2.15 Comment relire une traduction ?

Tout d’abord, bien lire la page :

http://www.debian.org/intl/french/aide.fr.html

et notamment la partie « Comment relire une traduction ».

Pour résumer, tout le monde peut participer à son niveau donc il ne faut pas hésiter une seconde. Il n’y a pas de commentaire stupide : chaque pierre apportée construit l’édifice.

Il vous faut récupérer le document posté sur la liste de diffusion ou bien sur le serveur cvs de Debian. Sauvegardez alors le document original sous son nom d’origine et dupliquez–le sous un autre nom (soyez logique : gardez le même nom avec un commentaire astucieux : si le document s’appelle

toto.fr.sgml, appelez le vôtre toto.fr.relu.sgml).

Éditez alors le document et apportez–y les modifications que vous désirez (fautes d’orthographe, de grammaire, de traduction, maladresse de style, incompréhension,…). Vous pouvez bien sûr commenter pour vous faire comprendre. Quand vous aurez fini (et même si vous n’avez pas le temps de tout faire : il vaut mieux un texte relu au quart que pas du tout), vous faites alors :

        diff -u texte texte.relu > diff_texte

diff est un utilitaire Unix qui permet d’extraire avec l’option –u les différences entre deux fichiers. On redirige le tout vers un nouveau fichier (ici, diff_texte). Éditez ce fichier et vous comprendrez vite… L’intérêt est qu’il permet au responsable de la traduction d’appliquer rapidement les modifications et que l’envoi du fichier est allégé (on ne renvoie que les modifications et non tout le texte modifié).

2.16 Comment poster une relecture ?

Vous devez poster la relecture comme une demande de relecture (de préférence dans le corps du message, sans attaché ni compression). Si vous avez conservé l’envoi original de demande de relecture, faites un « reply–to » sur le courriel original. Sinon, mettez un titre explicite pour que le responsable de traduction sache bien que cela lui est destiné. Un titre du genre « relecture du document toto.fr.sgml » ou « [relecture] toto.fr.sgml » est parfait.

Inutile de mettre le responsable en copie (CC). Il est abonné.

2.17 Comment demander de l’aide ?

S’il s’agit d’un problème spécifique à Debian ET à la traduction, la liste debian–l10n–french est là pour cela. Assurez–vous avant d’avoir bien cherché par vous–même — notamment en ayant lu la FAQ et les documents d’aides à

http://www.debian.org/intl/french/ltcp.fr.html

Sinon, sur Debian en général, adressez–vous à la liste de diffusion debian–user–french pour avoir des renseignements en français sur Debian. Après avoir lu la FAQ à

http://www.ens-lyon.fr/~mquinson/debian/faq-french/debian-french-faq.
html/

2.18 Que devient un document traduit ?

Tout document traduit se voit intégré dans le système de gestion de versions (cvs) de Debian. La liste des traductions en cours est accessible à

http://www.debian.org/intl/french/index.fr.html

2.19 Qu’est–ce qui fait référence en matière de traduction pour Debian ?

La page http://www.debian.org/intl/french/aide.fr.html donne un lexique mini-

maliste qui a été arrêté pour la traduction en français de certains termes spécifiques.

Il n’y a pas spécialement de doctrine arrêtée pour le reste, chacun puisant là où il veut. Toutefois, en dernier ressort, en cas de dilemme, c’est la majorité qui emporte la décision. Le mot ou l’expression est alors entré dans le lexique Debian et les traducteurs doivent alors s’y conformer.

Chapitre 2. Techniques  16

Chapitre 3

Traduire pour Debian (et pour le logiciel libre en général)

Note : Ce chapitre est appelé à être traduit en anglais de façon à devenir le HOWTO–l10n de Debian en particulier mais aussi de tous les logiciels libres.

Ce chapitre est l’oeuvre de Martin Quinson : il a été publié originalement dans la Foire aux questions de debian–french. Je le reprends à mon compte à présent.

3.1 Introduction

La traduction fait partie des objectifs de Debian. C’est un fait. Mais tout n’est pas si simple, et les volontaires potentiels sont souvent rebutés par les difficultés rencontrées. L’objectif de ce document est de faire le point sur ce qui se fait et comment le faire.

Il convient tout d’abord d’insister sur le fait que la traduction est l’une des tâches les plus simples permettant de faire avancer Debian et les logiciels libres. Nul besoin de savoir programmer pour le faire. Mais il ne faut pas non plus prendre cela à la légère. Il ne s’agit pas de traduire à la chaîne, n’importe comment. Il faut se souvenir que c’est ce que les utilisateurs verront. Il faut donc faire attention à ne pas faire de contresens, et soigner sa grammaire et son orthographe. Cela me semble évident et cela va sans le dire, mais je suppose que cela va mieux en le disant.

3.1.1 Que traduire dans un paquet ?

Avant de continuer, il faut préciser que traduire les messages affichés n’est qu’une pierre de l’édifice. Avant ça, il faut que quelqu’un modifie le code source pour que le programme puisse utiliser plusieurs catalogues de messages. C’est une partie de ce qu’on appelle l’internationalisation d’un code source, ou i18n en raccourci. Les autres parties consistent à permettre aux programmes d’afficher des caractères autre que ceux utilisés aux États–Unis (Le problème ne se pose plus vraiment pour le français et les langues européennes, mais il est d’une actualité brûlante pour les langues asiatiques, par exemple). Mais nous ne parlerons ici que de la traduction (« localization » en anglais, l10n pour faire court). Pour l’i18n, un bon point de départ est le manuel « Introduction à i18n », disponible à l’adresse http:

//www.debian.org/doc/devel-manuals#i18n.

Voyons maintenant les différentes choses que l’on peut traduire dans un paquet Debian

Les messages affichés

Debian (et Linux en général) sont dotés de beaux mécanismes pour traduire les messages des programmes. Le plus célèbre (et le seul dont je parlerais ici) est gettext. D’un point de vue technique, c’est basé sur une bibliothèque gettext, justement) qui permet au programme de charger à l’exécution le catalogue de messages utilisé pour pouvoir parler dans la langue de l’utilisateur. Pour ceux qui veulent en savoir plus sur comment ça marche, le manuel de gettext n’est pas si mal fait que ça (www.gnu.org/manual/gettext ou /usr/share/doc/gettext–doc/index.html si vous avez installé le paquet

gettext–doc).

Évidemment, pour que cela marche, il faut bien que quelqu’un traduise lesdits catalogues de messages. L’objectif de ce document est entre autres d’expliquer comment le faire. Nous reviendrons sur ce point dans une partie ultérieure.

La documentation

La documentation est une partie importante à traduire. Qu’il s’agisse des pages de manuel, (ce qu’on obtient par la commande man(1)), des fichiers info (cf. info(1)) ou des manuels de l’utilisateur fournis (en html ou autre) par certains paquets.

Mais pour tout cela, il n’y a rien de bien fixé. Pas de belles procédures pour savoir si la traduction est à jour. Et pour être honnête, pour l’instant, chaque projet développe sa propre méthode sans qu’aucun plan général ne se dégage jusqu’à présent. Je n’en parlerai donc pas dans ce document. On a déjà assez à faire avec le reste.

Les différents fichiers GNOME

Mais même si on se restreint au matériel à traduire pour lesquels il existe des procédures automatiques, parler des fichiers po ne suffit pas [tout à fait]. Les menus de GNOME (et KDE ?) sont à traduire, aussi, mais ce ne sont pas des messages affichés par le programme lui–même. Donc, dans un premier temps, on a inventé des fichiers .desktop qui contenaient ces informations.

Voici un exemple :

      [Desktop Entry]
      Name=Netscape
      Comment=Netscape browser
      Name[ro]=Netscape
      Name[bg]=Netscape
      Comment[bg]=Netscape Íàâèãàòîð
      Comment[br]=Merdeer Netscape

Name[ca]=Netscape
Comment[ca]=Navegador d'Internet Netscape
Name[cs]=Netscape
Comment[cs]=Prohlí\frac{3}{4}eè HTML souborù umístìných na Síti nebo disku
Name[da]=Netscape
Comment[da]=Netscape webbrowser
Name[de]=Netscape
Comment[de]=Netscape Navigator
Name[el]=Netscape
Comment[el]=ÖõëëïìåôñçôÞò Netscape
Name[es]=Netscape
Comment[es]=Navegador Netscape
Name[et]=netscape
Comment[et]=WWW lehitseja Netscape
Name[eu]=Netscape

La syntaxe n’est pas si complexe, et je n’approfondis pas.

Mais ce n’était pas vraiment pratique de tenir à jour les .po et les .desktop. Les gens de GNOME (je ne sais pas comment font les gens de KDE ou de WindowMaker, mais cela doit être équivalent) ont donc fait les programmes que l’on peut installer sur sa machine en installant le paquet xml–i18n–tools. Il s’agit de séries de scripts qui prennent les chaînes à traduire dans le .desktop (et autre du même genre), les met dans le .po pour que les traducteurs puissent faire leur boulot simplement, et récupère la traduction pour la remettre à sa place dans le .desktop lors de la compilation. Bref, tout ça pour dire que du point de vue du traducteur, les .desktop peuvent être oubliés. On traduit les .po, et la machine se dépatouille.

Les templates debconf

Autre catégorie que l’on peut traduire : les fichiers de templates debconf. Il s’agit des textes de questions qu’on va voir quand on configure un paquet. C’est une debianerie (i.e., hors de Debian, ça n’existe pas [encore]).

Voici un exemple (traduit) :

Template: debconf/showold
Type: boolean
Default: false
Description: Show all old questions again and again?
 Debconf normally only asks you any given question once. Then it remembers
 your answer and never asks you that question again. If you prefer, debconf
 can ask you questions over and over again, each time you upgrade or
 reinstall a package that asks them.
 .
 Note that no matter what you choose here, you can see old questions again
 by using the dpkg-reconfigure program.

      Description-fr: Poser de nouveau les anciennes questions ?
       Normalement, debconf ne pose chaque question qu'une seule fois. En-
suite,
       il se  souvient de la réponse que vous avez donnée, et ne repose jamais
       cette question. Si vous préférez, debconf peut reposer chaque question
       encore et encore, chaque fois qu'un paquet ayant besoin de cette réponse
       est installé ou mis à jour.
       .
       Notez que quel que soit votre choix ici, vous pouvez revoir la
       configuration  d'un paquet avec le programme dpkg-reconfigure.
      Description-it: Mostrare sempre le vecchie domande?
       Debconf normalmente pone le domande una sola volta, ricorda le risposte
       date e non pone più la stessa domanda. Se preferite potete ora scegliere
       che vi venga posta la stessa domanda ogni volta che aggiornate o
       reinstallate un pacchetto.
       .
       Notate che non importa la scelta fatta qui, potete vedere di nuovo le
       vecchie domande usando il programma dpkg-reconfigure.

Encore une fois, cela se passe d’explication.

Il existe toute une mécanique pour gérer les traductions, ce qui permet de vérifier que les traductions sont à jour. C’est dans le paquet debconf–utils : ce sont les programmes debconf–getconf et

debconf–mergetemplates.

Mais bon. Je commence à me dire qu’il serait pas mal de faire des fichiers de templates comme des fichiers po. Disons que j’y réfléchis. En attendant, il faut passer par la traduction séparée des templates (sur laquelle on reviendra plus tard).

Les pages oueb

Le site oueb de Debian compte parmi les mieux internationalisés. Si on a bien réglé son navigateur (la page http://www.debian.org/intro/cn indique comment le faire), les pages arrivent directement dans la langue choisie.

Il y a aussi un mécanisme pour vérifier que la traduction est à jour, et indiquer au visiteur si la traduction qu’il voit est obsolète, ainsi que pour prévenir le traducteur qu’il doit mettre son travail à jour. Plus de

détails sur la page http://www.debian.org/devel/website/.

Les menus Debian

Comme Debian utilise un méta–système de menu, on devrait arriver à les traduire. Il y a même un pseudo mécanisme de traduction dans le paquet menu. Et dans le fichier doc/translate, on peut lire :

What I propose is that update–menus simply learns the dutch, german, whatever translations for “Apps", "Editors", "The Gimp”, “X Window Snapshot”, and so on. These translations would be provided in a form similar/identical to the already used i18n format.

The French translations would be provided by a menu–fr.deb package, the Dutch translations by menu– du.deb, etc.

This may seem strange at first, as now the gimp package has no control over how the menu–entry looks in german. It might at first sight be much better to put in the menu entry file for the gimp all translations of “The Gimp” in however many languages we want to support.

The downside of this, is that it simply doesn’t work in Debian. The maintainer of the gimp surely doens’t know the translations of “The Gimp” in Dutch, Turkish, Japanise, Esperanto, whatever. Somewhere in Turkey there may be somone who is really good at translating all english titles into turkish, but s/he will have a very hard time convincing all 500+ package maintainers to include his/her translation into the package. And, a week later someone in Bulgaria wakes up, and sends 500+ discriptions to 500+ maintainers, asking them to include that. Well, you see, with about 6000 languages on this earth, the maintainers are going to have a hard time.

That is why I propose that the package maintainers simply don’t do anything about the languages, but simply upload their packages with menu entry files in them. Then some deamon on master scans all menu entry files in the distribution, and creates a file with all english words/phrases that should be translated. This file can be put somewhere on the web, and then this the translators simply gets that file, translate the 500+ entries in it, and create a menu–tr.deb (menu–de.deb, etc) package, and uploads that. Then, the users that want turkish systems simply install menu–tr.deb package, set the appropriate LC_* variables, and update–menus does what it should do.

This approach has the advantages that

– It actually works. Forceing 500+ package maintainers to include the world’s 6000+ languages into their menu entry files is really never going to work.

– It makes things easy for both the maintainer of the packages with the menu entry files (they do nothing), and for the translators (they don’t need to get the to–be–translated words and phrases from all kinds of packages, and send the results to many different package maintainers).

– It allows users to select what languages to install, so they don’t have to buy extra harddisks because each menu entry file now is 0.5 M big (5000 languages, 100 chars per language).

Mais à ma connaissance, rien n’a été fait dans ce sens…

Les descriptions de paquets

Je n’ai pas vraiment suivi ce qui se passe de ce côté. J’ai juste un petit pointeur à vous proposer. http:

//lists.debian.org/debian-devel-0101/msg02162.html

input welcome.

3.1.2 Les pour et les contre de la traduction dans Debian

Et oui, tout n’est pas si rose, et tout le monde n’est pas prêt à traduire Debian à tout va. Et même, on peut dire que dpkg n’est pas vraiment prêt à ce que tout ce qu’il est possible de traduire le soit. Il est impossible de lui préciser quelles langues on veut avoir sur la machine, et le résultat, c’est qu’il installe plein de trucs dont la plupart des gens n’ont aucune utilité. Allez visiter le répertoire /usr/share/locale/ sur votre machine. C’est là que sont placés les fichiers po compilés prêts à l’emploi. Il y a plusieurs dizaines de mégaoctets utilisés pour avoir les messages en russe ou en coréen, ce que je suis bien incapable d’exploiter. Alors comme je suis un peu juste en place, je fais le nettoyage à la main de temps en temps, mais ceci est l’argument principal des opposants à cette méthode. Dans le camp des pour,

il y a quelques idées (voir par exemple http://lists.debian.org/debian-devel-0011/

msg00887.html) mais rien n’a été fait jusque là.

La morale de l’histoire, c’est que pour l’instant, le consensus semble être que les fichiers po sont inclus avec le paquet qu’ils traduisent (sauf pour KDE. Tous les messages de tous les paquets KDE dans toutes les langues sont dans le paquet kde–i18n, ce qui n’est pas mieux). Certaines langues font un paquet qui contient tous les catalogues existants. Cette pratique est courante pour les pages de manuel des paquets de base. Ainsi, le paquet manpages–fr installe les pages de manuel les plus courantes. En ce qui concerne les templates Debconf, jusqu’à présent, personne n’a refusé de les inclure à son paquet pour gagner de la place. Mais ça pourrait se produire un jour. Ce jour–là, la querelle de clocher de savoir comment aider dpkg à gérer les traductions pourra reprendre de plus belle. ;)

3.2 Comment aider : la partie administrative

Le plus gros problème en ce qui concerne la traduction (mis à part la qualité des traductions, qui est évidemment primordiale), est de se coordonner.

Ce besoin de coordination doit se manifester :

– Entre les traducteurs : pour ne pas faire le travail deux fois, et que les traductions restent à jour. Il y a pire qu’une page de manuel non traduite : une page traduite non à jour, puisque l’utilisateur n’a aucun moyen simple de s’en rendre compte.

– Entre traducteurs et responsables : pour que les choses traduites soient incluses dans les paquets, et que les traductions restent à jour.

– Entre Debian et le reste du monde : la très grande majorité des programmes distribués par Debian ne sont pas développés au sein du projet. Et quelques projets extérieurs ont mis en place des sous projets de traductions. Il s’agit donc de ne pas marcher sur les plates–bandes de ces gens et, encore une fois, de ne pas dupliquer le travail fait (et ne pas ternir encore la réputation de Debian auprès des développeurs).

Pour résoudre ces problèmes, je propose les procédures suivantes :

3.2.1 Coordination entre traducteurs au sein de Debian

Les abonnés à la liste debian–devel connaissent les messages dont le titre commence par « ITP ». Il s’agit de « Intend To Package ». Ce sont des déclarations d’intention de mise en paquet. L’usage veut qu’on annonce sur la liste son intention de créer un nouveau paquet avant de se mettre au boulot, afin d’éviter que deux personnes se mettent à travailler sur la même chose dans leur coin.

Je propose de reprendre le principe et de poster des « ITT »(Intend To Translate) sur la liste qui va bien. Pour les traductions vers le français, la liste est évidemment debian–l10n–french.

Comme personne n’est parfait, il est possible que quelqu’un ait déjà traduit ce que vous comptiez traduire sans rien dire, et l’ait déjà renvoyé au responsable. Pour en avoir le coeur net, allez faire un tour sur la page des bogues du paquet pour lequel vous comptez travailler (http://bugs.debian. org/nom_du_paquet), afin de vérifier qu’il n’y a pas de rapport de bogue contenant les traductions.

En résumé

1. Avant de commencer à traduire, veuillez–vous inscrire à la liste de coordination des traductions. Dans le cas du français, il s’agit de debian–l10n–french@lists.debian.org

2. Ensuite, vérifiez que personne n’a traduit ce qui vous intéresse sans rien dire en regardant les rapports de bogue du paquet.

3. Annoncez votre intention par un courriel à la liste « ITT » avant de commencer.

4. Si personne ne réagit, allez–y. Vous pouvez traduire. (voir plus loin sur comment traduire quel type de matériel)

3.2.2 Coordination entre traducteurs et développeurs Debian

Ça, c’est facile. Une fois que vous avez fini votre traduction, il suffit de faire un rapport de bogue contre le paquet de sévérité « souhait » ou à l’extrême limite « normale » (pas pire), en expliquant ce que vous avez traduit, et en attachant le matériel traduit. Si vous êtes perfectionniste, vous pouvez surveiller la prochaine version du paquet pour voir si votre contribution a bien été prise en compte, et pour râler si ce n’est pas le cas, ou si le responsable a mis vos fichiers au mauvais endroit.

3.2.3 Coordination entre Debian et le reste du monde

Ça, c’est la partie la plus difficile. Je n’ai pas de réponse magique. Je considère qu’il y a plusieurs catégories de paquets :

– Les paquets purement Debian comme dpkg ou bug. Dans ce cas, le problème ne se pose pas.

– Les paquets issus de projet ayant un projet de traduction bien établi comme les programmes GNOME ou KDE. Dans ce cas, je pense que le plus simple est de rejoindre le projet de traduction associé. Voici la liste des plus gros projets de traductions (i–e., ceux que je connais) vers lesquels il faut vous tourner :

  – GNU : L’url est http://www.iro.umontreal.ca/contrib/po/HTML/. Attention, GNU

étant GNU, il faut avoir signé un papier disant qu’on renonce au copyright pour pouvoir traduire leurs programmes. Plus de détails sur leur site.

  – GNOME : l’url à connaître dans ce cas est http://developer.gnome.org/projects/
    gtp/.

– KDE : le projet de traduction de KDE est le plus organisé et efficace que je connaisse. Leur url est

    http://i18n.kde.org/.

Dans ce cas, il me semble important de traduire à la source. Les modifications se retrouveront dans la prochaine version du paquet Debian – Programmes ne faisant pas partie d’un grand projet, mais tout de même assez bien organisés en ce

qui concerne les traductions. Un exemple est bluefish. Il s’agit d’un programme « indépendant », mais il a tout de même des traducteurs attitrés. Le seul moyen de s’en rendre compte est d’aller sur la page du projet. Dans ce cas, il vaut mieux contribuer à la source, et ne pas rester au sein de Debian.

– Programmes indépendants où rien n’est fait pour la traduction. Il s’agit sans doute des petits projets, qui n’ont pas les reins assez solides pour avoir une logistique de traduction en place. Dans ce cas, on peut rester dans Debian (et espérer que le responsable enverra à la source nos traductions).

En résumé

Sauf dans le cas de paquets purement Debian, où il convient évidemment de traduire au sein de Debian, ou dans le cas de petits projets n’ayant aucune infrastructure pour la traduction, il me semble important de traduire à la source. Que cela ne vous dispense pas d’annoncer votre intention sur la liste. On peut y coordonner l’aide apportée à la source.

Problème supplémentaire

Tout ça ne résout pas le problème du matériel apporté par la mise en paquet Debian de programmes ayant une source extérieure. Dans le cas des templates Debconf, on les traduit évidemment au sein de Debian. Mais je me demande depuis longtemps s’il existe des chaînes de fichier po introduites par les responsables Debian (lors de leurs modifications). Si c’est le cas, je sais pas comment coordonner la chose.

3.2.4 En résumé

Toute cette démarche administrative peut paraître un peu rébarbative, mais elle n’est quand même pas très compliquée à appliquer. Et si on ne le fait pas, les traductions vont être dupliquées, ou au contraire ne seront plus maintenues, ou le projet Debian va se faire maudire par le reste du monde libre pour son manque de respect des autres projets existants. Alors s’il vous plaît, faites un petit effort…

3.3 Comment traduire

3.3.1 Choisir sa cible

Vouloir traduire, c’est très bien ; savoir ce qu’on va traduire, c’est mieux.

Il faut choisir la catégorie de matériel que l’on veut traduire : catalogues po, templates debconf, pages de manuel, document info, manuel de l’utilisateur en html ou assimilé, ou autre.

Pour choisir sur quel paquet travailler, la méthode dépend du matériel. Pour les deux premières catégories, un petit tour sur le Debian Translation Center (http://www.debian.org/intl/l10n) peut être utile pour voir quels paquets sont prêts à être traduits et ceux qui ont besoin d’une mise à jour. Pour toutes les autres catégories, il faut télécharger le code source des paquets et regarder à la main. Je n’ai pas encore trouvé comment les ajouter au DTC.

3.3.2 Comment récupérer le matériel à traduire

Vous pouvez récupérer les fichiers tous seuls depuis le DTC, mais personnellement, je préfère récupérer toutes les sources du paquet (avec la commande apt–get source nom_du_paquet). Comme ça, en cas de doute, je peux toujours me référer au code source. Maintenant, chacun est libre de faire comme bon lui semblera…

Une fois que vous avez choisi votre cible, que vous êtes assuré par la partie administrative que vous pouviez vous lancer et que vous avez récupéré votre cible, il reste à traduire la chose. Voyons comment faire.

3.3.3 Comment traduire les catalogues po ?

Commençons par quelques pointeurs vers plus de documentation.

– Le manuel de gettext : inclus dans le paquet gettext–doc.

– Le KDE Translation HOWTO : http://i18n.kde.org/translation-howto/index.html

Lorsque vous éditerez un catalogue po, vous verrez des initiales apparaître dans les commentaires, du genre

      167 t ; 166 f ; 12 u

.

C’est une indication pour vous guider dans le travail de traduction :

– [T]ranslated :

Chaîne traduite ; rien à faire.

– [F]uzzy :

Le programme qui cherche les nouvelles chaînes à traduire dans le code source trouve parfois des morceaux de chaînes qui ont peu changé. Il propose alors l’ancienne traduction, et marque la chaîne comme floue (fuzzy). Il faut alors une intervention humaine pour vérifier, et le cas échéant, corriger, et enfin supprimer le marqueur « flou ».

– [U]ntranslated :

Chaîne non traduite ; à traduire.

– [O]bsolete :

Chaîne à traduire dans une version précédente du programme mais qui a disparu depuis et n’est plus utilisée. On doit pouvoir se débarrasser de cette chaîne normalement.

Voyons ensuite les principaux programmes disponibles pour vous aider dans votre tâche :

– emacs dispose d’un mode po–mode. C’est ce que j’utilise, et c’est la solution que je conseille à tout le monde (évidemment, puisque c’est mon choix). Ses qualités :

– une fois qu’on connaît les raccourcis claviers, il est très simple à utiliser.

– permet de voir le code correspondant très simplement.

Ses défauts – C’est dans emacs, et il est préférable de connaître cette merveilleuse usine à gaz pour utiliser ce

mode.

– Pas de correction orthographique par défaut. Vous pouvez toutefois lancer le mode flyspell– mode pour le faire.

– pas de compendium (voir la documentation de gettext pour savoir ce qu’est un compendium

).

– kbabel est l’outil issu du monde KDE. Il semble très évolué, mais… je n’aime pas son ergonomie (c’est personnel, évidemment) Ses qualités :

– Correction orthographique.

– Compendiums.

Ses défauts :

– Je ne crois pas qu’il permette de voir le code simplement, mais je ne suis pas sûr, je ne le connais pas bien.

– On ne voit qu’une traduction à la fois.

– gtranslator est l’outil issu du monde GNOME. Je ne l’ai jamais utilisé. Input Welcome.

Attention, s’il s’agit d’une mise à jour, veuillez contacter le traducteur précédent (dont l’adresse figure normalement dans le document) pour avoir le feu vert. Il est le responsable de fait de cette mise à jour et vous pouvez lui offrir l’opportunité de vous substituer à lui. Ajoutez alors votre adresse à la suite de la sienne.

3.3.4 Comment traduire les templates Debconf ?

Voici quelques instructions issues du fichier README.translators du paquet debconf :

Le fichier que vous devez traduire est le template Debian, en engendrant un fichier template <lang>. Ceci est spécifique à debconf. Pour fabriquer facilement un fichier de référence d’un template <lang> vous n’avez qu’à taper :

      debconf-getlang <lang> debian/templates > debian/templates.<lang>

Ensuite, éditez le nouveau fichier, et remplissez par des traductions toutes les lignes vides. Lorsque je change le fichier template de référence, vous pouvez rassembler le tout avec la commande debconf–

mergetemplate :
      debconf-mergetemplate debian/templates debian/templates.<lang> > new

Un dernier mot au sujet de la syntaxe des templates : la première ligne de description est comme un en–tête. Vous n’êtes pas autorisé à poursuivre la première ligne sur les suivantes. Par exemple, le template suivant est mauvais :

      Template: autolog/note
      Type: note
      Description: Autolog daemon will start logging out users if it wants to,
       but it's not sure. Will see if it's nice today.
       The autolog daemon will be activated now and will log users out

       after two hours of idle time. If you do not want this then either uninstall
       autolog or customize /etc/autolog.conf and /etc/rc.d/autolog ac-
cording to
       your needs.

La description brève s’étale sur deux lignes mais debconf n’utilisera que la première ligne comme descriptif rapide, et le reste comme descriptif détaillé. Ainsi, ne faites pas de description rapide trop longue ! Les spécifications imposent une limite de « 50 caractères au plus ».

3.3.5 Comment traduire les descriptions de paquets Debian ?

Les descriptions de paquets Debian sont les parties de texte explicatives concernant ledit paquet. Les descriptions à traduire sont souvent très courtes, quelques lignes à peine, mais les traduire toutes est une tâche de longue haleine (prédiction : juillet 2003… date non–contractuelle bien sûr).

Plus que des traducteurs, il nous faut des relecteurs !

Organisation

Le projet a été initié par mailto:grisu@debian.orgMichael Bramer, qui en assure la maintenance. L’adresse électronique du serveur est mailto:grisu-td@auric.debian.org et la page d’accueil est http://auric.debian.org/~grisu/ddts. Comme on peut le constater, ce projet n’a pas encore de statut très clair au sein de Debian, ne disposant ni d’un espace oueb ni d’une liste de diffusion dédiés. De plus, son intégration en tant que tel pose aussi pas mal de soucis. Mais c’est un autre débat (suivre debian–devel pour les tenants et aboutissants).

Demander des traductions par courrier électronique

Il vous suffit d’envoyer un courriel banal à grisu–td@auric.debian.org, en mettant dans le sujet du courriel votre commande, (comme par exemple GET 1 fr, laissez le corps du courriel vide). Attendez quelques instants, puis vérifiez votre boîte aux lettres électroniques. Voila, ce n’est pas plus compliqué que cela !

Les commandes disponibles sont les suivantes :

– GET x fr demande « x » descriptions non encore traduites (nombre compris entre 1 et 9).

– REQUEST <nom du paquet> fr demande la description du paquet <nom du paquet>.

– SREQUEST <nom du paquet> fr demande toutes les descriptions du paquet source qui porte le nom <nom du paquet>.

– STATUS fr demande un rapport sur l’état des traductions pour la langue française.

– NOGUIDE n’affiche pas ce guide dans la réponse du serveur.

– NOTHING n’envoie pas de nouvelles descriptions, l’état des traductions, etc.

Traductions

Après avoir envoyé votre courriel, vous recevez un formulaire du serveur (il s’agit d’une pièce jointe). Sauvez la pièce jointe et ouvrez–la avec votre éditeur de texte favori. Dans ce formulaire, vous découvrirez la description originale, en anglais donc, (ne la modifiez surtout pas, même si elle contient des fautes) et le squelette de la traduction que vous allez faire.

Parfois deux descriptions différentes contiennent une phrase ou paragraphe identique, si le serveur a déjà reçu une traduction française d’un segment de texte identique (dans l’exemple qui suit : « GNOME signifie… »), il vous propose une traduction française pour vous alléger le travail. Il ne s’agit que d’une simple suggestion ; vous pouvez sans problème l’effacer ou la modifier.

Voici un exemple de formulaire :

       Description: A tetris clone.
        Gnome is the "GNU Network Object Model Environment"
        .
        It is a project to build a complete, user-friendly desktop
        based entirely on free software.
       Description-fr: <trans>
        Gnome signifie « GNU Network Object Model Environment »
        .
        <trans>

Dans le squelette du formulaire :

– Les lignes commençant par « # » sont des commentaires.

– La ligne commençant par « From : Nom <email@host.com> » indique l’adresse électronique du traducteur. (Cette ligne est utile si le traducteur envoie son courrier à partir d’une autre adresse électronique).

– Les descriptions doivent être séparées par une et une seule ligne vide.

Vous n’avez qu’à remplacer le « <trans> » par votre traduction, puis, sauvez votre traduction et envoyez– la en pièce jointe à grisu–td@auric.debian.org. Le contenu du sujet du courriel n’a pas d’importance.

Règles à respecter

– ne traduisez pas le mot description,

– gardez la structure de la description,

– ne modifiez pas la description anglaise : si vous trouvez une erreur, envoyez un rapport de bogue.

– Ne modifiez rien d’autre que le français. N’insérez pas de lignes supplémentaires notamment !

– Traduisez conformément aux règles en vigueur dans la traduction chez Debian.

Relectures

Il se peut qu’un membre de la liste vous écrive directement pour vous proposer des améliorations ou des corrections. Dans tous les cas, suivez la liste pour y relever les diverses corrections.

Il existe un script à http://perso.wanadoo.fr/nico.bertol/ddts/ddts-script.txt

en perl pour faciliter le travail. Il vous faut tout d’abord paramétrer votre configuration dans le fichier ˜ /.ddts–script, un fichier d’exemple est fourni à http://perso.wanadoo.fr/nico.bertol/ ddts/dot.ddts-script.txt, il vous suffit de renseigner les variables avec les valeurs qui vous conviennent, des commentaires expliquent leur signification.

Ensuite, voici la démarche à suivre :

– passer à l’entrée standard du script le rapport reçu avec l’option parse,

– renommer les fichiers NomDuPaquet.todo en NomDuPaquet.relu

– éditer NomDuPaquet.relu et effectuer les corrections nécessaires, vous pouvez ajouter des commentaires en ajoutant des lignes commençant par « >> » suivi d’une espace puis le texte de commentaire,

– lancer le script avec l’option mail pour fabriquer les courriels automatiquement.

Pour plus d’information, lisez la documentation fournie avec le script : perldoc ddts–script.

Profitez vous–même des traductions

Insérez simplement l’une des lignes suivantes dans le fichier /etc/apt/sources.lists :

       deb http://gluck.debian.org/~grisu/ddts/aptable fr/potato main
       deb http://gluck.debian.org/~grisu/ddts/aptable fr/woody main
       deb http://gluck.debian.org/~grisu/ddts/aptable fr/sid main

Après un « apt–get update », tous les outils (dselect, gnome–apt, deity,…) utiliseront les descriptions déjà traduites.

3.3.6 Comment traduire les pages de manuel ?

Pas de méthode particulière. Il faut ouvrir le document dans un éditeur de texte, et tout traduire. Le plus difficile, c’est de vérifier que la page reste à jour. Et je n’ai aucune idée de comment faire…

3.3.7 Comment traduire les fichiers info ?

Aucune idée. Input welcome…

3.3.8 Comment traduire la documentation ?

Il faut faire attention à bien traduire le document source. Par exemple, si la source est en XML, il vaut mieux ne pas traduire la conversion en HTML. Sinon, pas de méthode particulière, à part la classique ouverture dans un éditeur.

3.4 Conclusion, avenir

Voilà le premier jet de ce HOWTO traduire pour Debian. Si vous avez le moindre commentaire à faire, n’hésitez pas.

C’est tout, j’espère que Woody sera l’avènement de l’internationalisation effective de Debian…

Chapitre 3. Traduire pour Debian (et pour le logiciel libre en général)  30

Chapitre 4

Vieux débats classés…

4.1 Pourquoi « paquet » et pas « paquetage » ?

On trouve partout « paquetage » et non « paquet ». Pourquoi Debian se singularise–t–elle ?

Le débat a été tranché en 1997, c’est–à–dire bien avant qu’on ne trouve partout « paquetage ». C’est le résultat d’un consensus établi sur la liste et le terme a donc été introduit dans le lexique de Debian. Depuis, il fait référence pour toutes les traductions de Debian.

Il est donc inutile de relancer un n–ième débat sur le sujet. Lire en particulier « Peut–on changer une traduction établie dans le lexique ? ».

4.2 Pourquoi ne peut–on pas mettre d’image dans le format debian–doc ?

Le format debian–doc sgml est volontairement minimaliste pour permettre une plus large diffusion de la documentation. Il permet entre autre de fournir des sorties variées, aussi bien du PostScript que du texte. Dans ces conditions, le format de sortie le plus élémentaire impose évidemment ses bornes aux autres formats.

Si vous désirez une sortie plus complète, tournez–vous vers la DTD docbook du sgml.

Si vous désirez faire changer les choses, n’hésitez surtout pas à vous retrousser les manches et corriger les choses vous–même : la communauté entière vous remerciera…

4.3 Peut–on changer une traduction établie dans le lexique ?

Les termes du lexique de Debian sont arrêtés et servent de référence. Il est théoriquement possible de modifier une traduction d’un de ces termes mais il va falloir dans ce cas apporter des arguments extrêmement solides.

En effet, changer un terme de référence impose obligatoirement de réviser TOUS les documents qui ont été traduits et qui y font référence. C’est une tache énorme qui ne sera pas faite sans de solides raisons.

Évitez aussi de lancer des polémiques sur le sujet et gardez vos forces pour la traduction : Debian seule sera perdante sinon…

Chapitre 5

Règles typographiques de base

5.1 Règles typographique de la langue française

5.1.1 La ponctuation

La langue française impose des règles typographiques très strictes qu’il faut essayer de respecter. La typographie est l’ensemble des règles de mise en page d’un document que ce soit la distance entre les mots, leur césure, leur disposition ou bien l’usage de la ponctuation.

Bien entendu, on ne peut pas toujours respecter toutes les règles en usage pour la bonne raison que ces règles de mise en page ne sont applicables que pour un format qui permet de fixer la mise en page une fois pour toute. Ces formats sont les suivants : le dvi, le PostScript et le pdf. À noter que ces trois formats sont à peu près équivalents et que l’on passe sans trop de difficultés d’un format à l’autre. L’inconvénient est que ces formats sont des formats binaires et qu’ils nécessitent donc des outils spécifiques pour leur lecture (respectivement xdvi et gv). L’avantage est que le lecteur ne peut modifier le fichier source et que l’on est sûr que la mise en page et l’information ne vont pas être changées.

Il existe d’autres formats beaucoup utilisés qui est des formats textes, avec ou non des balises. Ces formats sont lisibles directement avec un éditeur de texte ou bien avec des outils dédiés qui mettent en page (comme un navigateur pour le HTML). On peut résumer ces formats au texte pur (caractères ASCII ou iso–latin 1 ou 15) et au HTML. L’inconvénient de ces formats est qu’il n’y a pas de mise en page facile à respecter pour deux raisons : la première est que la mise en page dépend du navigateur utilisé, de la fonte utilisée et de la façon dont la machine interprète le tout. Comme il n’y a pas vraiment de standard de rendu, le résultat varie beaucoup d’un environnement à l’autre. Deuxièmement, certains formats comme le texte sont extrêmement limités dans leur capacité de mise en page, ce qui impose évidemment de ne pas pouvoir respecter toutes les règles de typographie.

Un environnement bien fait devrait bien entendu gérer cela automatiquement. Ce n’est pas encore le cas chez nous. J’y travaille et j’ai espoir que cela se fasse avant le XXII–ième siècle. En attendant, il faut faire avec et compenser nous–même les faiblesses du système. Pour information, voici ce qui devrait être appliqué en ce qui concerne la mise en page des signes de ponctuation. J’ai synthétisé tout cela dans un document que vous pourrez trouver très bientôt à :

http://p.karatchentzeff.free.fr/freesoft/TeX

Voici un résumé très rapide. On différencie deux types de ponctuation : la basse et la haute. Elles sont définies par rapport à la ligne de base, c’est–à–dire la ligne virtuelle sur laquelle s’appuient les lettres pour s’aligner. La ponctuation basse est composée des signes suivants : le point, la virgule et les points de suspension. La ponctuation haute est composées du reste : le point–virgule, les deux–points, le point d’interrogation, d’exclamation, les guillemets et les parenthèses.

L’unité de l’espace de base en typographie est le cadratin. Pour ceux qui connaisse, elle est égale à « 1 em » sous TeX. Cette espace est variable et dépend de l’environnement (fontes, graisses, etc.). Voici ce qu’impose la typographie française :

 -----------------------------------------------------------
|        |                             |                             |
| Signe |  Espace (intervalle)     |   Espace (préconisée)   |
|        |                             |                             |
|---------------------------------------------------------- |                                                                   |
|   ;     (avant) insécable et fixe   aux environs de 10/100 |
|          entre 10/100 et 24/100                                |
|---------------------------------------------------------- |
|   :     (avant) insécable et fixe   aux environs de 24/100 |
|          entre 10/100 et 24/100                                |
|---------------------------------------------------------- |
|   !     (avant) insécable et fixe   aux environs de 24/100 |
|          entre 10/100 et 24/100                                |
|---------------------------------------------------------- |
|   ?     (avant) insécable et fixe   aux environs de 24/100 |
|          entre 10/100 et 24/100                                |
|---------------------------------------------------------- |
|   «     (après) insécable et fixe   aux environs de 24/100 |
|          entre 10/100 et 24/100                                |
|---------------------------------------------------------- |
|   »     (avant) insécable et fixe   aux environs de 24/100 |
|          entre 10/100 et 24/100                                |
 -----------------------------------------------------------

Notons que l’espace fine en typographie vaut 25/100 de cadratin. Pour plus de détails, allez lire le document placé en lien au–dessus.

On se rend bien compte que cela est ingérable pour nous au coup par coup. Je vais donc modifier debiandoc en conséquence. En attendant, on peut limiter beaucoup certains dégâts malheureux.

On ne peut transcrire aisément la finesse de la taille de l’espace préconisée mais on peut toujours au moins en mettre une. Et de plus la forcer à être insécable. C’est le rôle de la balise sgml (reconnue par debiandoc et le wml) &nbsp ; (no breaking space). Il vous faut donc écrire :

 «&nbsp;toto&nbsp;»  pour « toto »
 toto&nbsp;; pour toto ;
 toto&nbsp;: pour toto :
 toto&nbsp;? pour toto ?

       toto&nbsp;! pour toto !
       toto...&nbsp; pour toto...

On est tous d’accord pour dire que c’est lourd mais c’est un pis–aller… en attendant une correction plus globale et automatisée.

Voici un pointeur chez nos amis de FreeBSD :

http://www.freebsd-fr.org/books/translators

5.1.2 Règles basiques

Accentuation

On accentue normalement les éléments qui doivent l’être. On rappelle à ce sujet qu’une lettre capitale est une lettre comme les autres et doit être accentuée. Pas besoin d’utiliser les artifices des premières version de HTM (&eacute ; pour « é ») même si, techniquement, cela est parfaitement supporté. Le problème est que cela rend la relecture très difficile. Il y a suffisamment de balises indispensables pour ne pas en ajouter d’autres.

Pour ceux qui aurait la malchance de travailler sous Microsoft Windows \begin{matrix}r \\ ◯ \end{matrix}, voici quelques combinaisons qui devraient vous aider :

          «      Alt+0171
          »      Alt+0187
          À      Alt+0192
          Ç      Alt+0199
          É      Alt+0201

Guillemets

Les guillemets français sont le « pour le guillemet ouvrant et le » pour le fermant. Tout autre type de guillemet est a priori à proscrire. Les notations américaines du genre “” ou bien ‘’ sont donc à traduire.

On trouve exceptionnellement ” “ en français. À utiliser plutôt dans l’imbrication de citations, par soucis de clarté.

Mots étrangers

Les mots étrangers cités dans votre traduction sont à mettre en évidence. En typographie, on utilise généralement l’italique pour cela. Ici, il vous faudra utiliser les balises <em> </em>. Voici une liste non–exhaustive de termes à mettre en italique :

      a priori
      a fortiori
      confer

      id. ou idem
      i.e. ou id est
      loc. cit. ou loco citato (passage cité)

Attention, le sigle cf., lui, ne doit pas se mettre en italique.

Les titres

Les anglophones ont l’habitude d’utiliser des majuscules sur tous les mots d’un titres : « Debian GNU/Linux : Guide to Installation and Usage ». En français, seul le premier mot comportera une majuscule : « Debian GNU–Linux : guide d’installation et d’utilisation ».

Les majuscules

Partie copiée–collée d’un courriel de Norbert Bottlaender–Prie

On emploie [la majuscule] aussi :

au début d’une phrase : Après un deux–points, lorsqu’il annonce une citation fictive ou réelle en style direct (mais non quand il précède une explication ou une énumération) :

[exemples]

      Il ne répondait pas à la question que se posait chacun d'entre nous : À
      quoi cela sert-il ?
      Le père demanda : « Pourquoi as-tu agi ainsi ? »

Quelquefois même sans les deux–points :

[exemple]

      C'est aux cris de Vive l'empereur ! que la foule accueillit le
      souverain.

au départ d’un aliéna (même s’il n’est pas début de phrase)

Commençant directement par le texte :

[exemple]

      Nous étudierons successivement~:
      L'illusion de la sécurité collective~;
      La diplomatie des coups de force~;
      Le déclenchement de la guerre.

Commençant par un numéro ou une lettre de classification, suivi d’un point :

[exemple]

      Le Code pénal français distingue trois catégories d'infractions~:
      1. Les crimes ;
      2. Les délits ;
      3. Les contraventions.

Par contre,la minuscule est de règle après un « – » ou tiret :

[exemple]

      La Grande-Bretagne comprend :
      - l'Angleterre ;
      - l'Écosse ;
      - le pays de Galles.

Elle [la minuscule] s’impose également après le 1^{∘}, 2^{∘}, 3^{∘} etc., à l’intérieur d’un paragraphe de lignes pleines :

[exemple]

      « La communauté se dissout : 1^{∘} par la mort naturelle ; 2^{∘} par la mort
      civile ; 3^{∘} par le divorce ; 4^{∘} par la séparation de corps ; 5^{∘} par la
      séparation de biens. » (C. civ., art. 1441)

Extrait des Règles typographiques en usage à l’Imprimerie Nationale, p. 38–40.

Les énumérations :

Partie copiée–collée d’un courriel d’Alain Reinhard.

Il faut considérer l’ordre des caractères typo, l’ordre des parties logiques du texte, la ponctu et, si ma mémoire est bonne, la syntaxe aussi.

Considérons ici seulement la ponctuation qui est le problème posé.

Premier cas de figure : la phrase est brisée entre l’introduction et l’énumération

Il faut alors une capitale à chaque partie et on doit utiliser en tête de ligne des signes de ponctu comportant un point, du genre 1. IV. ou C. Il faut terminer chaque énumération par un point–virgule et cela même s’il se trouve n’importe quel autre signe typographique dans l’énumération. La dernière énumération est marquée d’un point. S’il y a une sous–énumération imbriquée dans une énumération, il faut alors une minuscule au début et une virgule à la fin de chaque partie, avec le point–virgule marquant la fin de l’énumération reporté à la fin de la dernière sous–énumération. Dans ce cas je pense aussi que la proposition qui introduit l’énumération doit se terminer par un deux–points.

Voici des exemples :

      A. Ceci est une partie d'énumération ;
      B. Ceci est une deuxième. Remarquez bien la ponctuation ;
      C. Ceci introduit une sous-énumération :

               . pas de majuscule ici,
               . virgule à la fin,
               . sauf ici, c'est le point-virgule ;
      D. Ceci met le point final de l'énumération.

Deuxième cas de figure : la phrase est continue entre l’introduction et l’énumération

Il faut alors une minuscule initiale à chaque partie et on utilise en tête de ligne des signes de ponctuation ne comportant pas de point cette fois, du genre – i) ou 1^{∘}. Dans ce cas je pense que la proposition qui introduit l’énumération n’a pas besoin de signe de ponctuation.

      Pour cette explication de traducteur à traducteur,
      - j'aurais souhaité faire plus simple,
      - expliquer plus concrètement,
      - voire, concocter un document ps :
               a) plus complet,
               b) plus élégant,
               c) mais peut-être trop lourd finalement.

Un mot quand même pour ajouter que nos amis anglophones ne prennent pas souvent soin d’être constant dans le choix de la catégorie grammaticale du mot débutant chaque partie d’une énumération. Si on choisit un verbe pour la première partie d’une énumération, on commencera toutes les autres parties de la même énumération par un verbe. Etc.

Debian GNU/Linux versus Debian GNU–Linux

La typographie anglophone utilise le « / ». La française utilise le « – ».

Debian est une femme…

Bien que l’on doive bien sûr parler de Debian GNU–Linux, et non faire précéder Debian d’un quelconque article défini ou non, on accordera les participes passés ainsi que les adjectifs qualifiant Debian au féminin faisant ainsi par défaut de Debian une entité féminine.

Référence

        Lexique des règles typographique
        en usage à l'Imprimerie Nationale
      ISBN 2-11-081075-0

Quelques liens utiles :

http://tex.loria.fr/typographie.htmlhttp://petitefabrique.free.fr/info/
divers/typo.htmlhttp://bisance.citi2.fr/typo/

5.1.3 Les outils d’aide

L’éditeur de textes

Tous les textes et fichiers à manipuler sont des fichiers ASCII ou encodés en iso–latin (1 ou 15). Un éditeur de textes est donc largement suffisant. Les éditeurs sous Debian GNU–Linux sont très nombreux donc vous n’avez que l’embarras du choix. Toutefois, pour des raisons pratiques, certains sont plus performants que d’autres pour ce genre de travail car ils permettent, outre une coloration lexicale des éléments de balise (bien pratique pour la relecture) de passer aussi certaines commandes UNIX directement depuis l’éditeur (pratique pour les diff et patch par exemple). Les deux plus puissants sont Vim et (X)Emacs.

Une introduction rapide et simple à Emacs : http://p.karatchentzeff.free.fr/freesoft/
emacs/html
Comment se servir de sgml depuis Emacs : http://people.debian.org/~bortz/SGML-HOWTO/
potato/x323.html

Les dictionnaires

Sur Internet Français – Anglais : http://sun-recomgen.univ-rennes1.fr/FR-Eng.
html

Français – Anglais & Anglais – Français : http://wordreference.com/

Français : http://www.francophonie.hachette-livre.fr/
Jargon : http://www.linux-france.org/prj/jargonf/
La FAQ du forum fr.lettres.langue.française : http://www.chez.com/languefrancaise/faq/
faq.htm

(si vous trouvez un autre hébergeur que www.chez.com, signalez–le moi : leur publicité est vraiment fatigante au possible. Je changerai l’adresse.)

En ligne de commande : ; Français :

– Les programmes ispell et aspell sont fournis avec votre distribution de Debian GNU–Linux. Très facile à installer et à mettre en français pour les relectures afin d’éliminer toutes les fautes d’orthographe.

– Le dictionnaire de René Cougnenc (dico) sera disponible sur Woody. Une version pour Potato est disponible sur http://marillat.free.fr. Il vous donnera en plus l’ensemble des codes postaux du territoire français métropolitain :–)

Tous ces programmes s’interfacent très bien directement sous (X)Emacs, donc il n’est même pas nécessaire de sortir de votre éditeur pour corriger. Notez bien la présence du mode flyspell sous (X)Emacs pour corriger à la volée lors de l’écriture du texte.

Français – anglais :

Il s’agit de babytrans (programme non disponible sur Debian GNU–Linux et dont la licence est pour le moment douteuse). Il est disponible sur http://marillat.free.fr pour Potato et Woody.

C’est un excellent programme de traduction de mots très pratique qui réagit au copier UNIX de la souris. Très bon outil.