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.
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.
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
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 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.
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í¾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.
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. Ensuite,
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).
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/.
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
Mais à ma connaissance, rien n'a été fait dans ce sens...
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.
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. ;)
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 :
Pour résoudre ces problèmes, je propose les procédures suivantes :
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.
Ç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.
Ç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 :
dpkg ou
bug. Dans ce cas, le problème ne se pose pas.
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.
http://developer.gnome.org/projects/gtp/.
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
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.
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.
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.
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...
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.
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.
po ?
Commençons par quelques pointeurs vers plus de documentation.
gettext : inclus dans le paquet
gettext-doc.
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 :
Chaîne traduite ; rien à faire.
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 ».
Chaîne non traduite ; à traduire.
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 :
Ses défauts
emacs, et il est préférable de connaître cette
merveilleuse usine à gaz pour utiliser ce mode.
flyspell-mode pour le faire.
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 :
Ses défauts :
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.
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 according 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 ».
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 !
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).
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 :
demande « x » descriptions non encore traduites (nombre compris entre 1 et 9).
demande la description du paquet <nom du paquet>.
demande toutes les descriptions du paquet source qui porte le nom <nom du paquet>.
demande un rapport sur l'état des traductions pour la langue française.
n'affiche pas ce guide dans la réponse du serveur.
n'envoie pas de nouvelles descriptions, l'état des traductions, etc.
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 :
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
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 :
Pour plus d'information, lisez la documentation fournie avec le script : perldoc ddts-script.
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.
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...
Aucune idée. Input welcome...
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.
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...
p.karatchentzeff@free.fr