Les traductions

Page créée le 2010-11-26 et mise à jour le 2010-12-10 par André Gillibert.

Les traductions des logiciels GNU sont prèsque toujours de qualité médiocre et incomplètes, mélangeant allègrement le français et l'anglais dans une même boîte de dialogue, parfois dans deux phrases se suivant.

GCC

GCC a une des plus belles perles.

$ cat strictectomie-bilatérale.c 
#include <stdio.h>

int main(void) {
        int c=42;
        short *p=(short *)&c;

        printf("%04X\n", (unsigned)*p);
        return 0;
}
$ LC_ALL=fr_FR.UTF-8 gcc-3.4.6 -O2 -Wall strictectomie-bilatérale.c
strictectomie-bilatérale.c: In function `main':
strictectomie-bilatérale.c:5: attention : déréférencement du pointeur type-punned brisera les strictes d'aliases

Ça dépasse la squeelotomie. Je n'imaginais même pas que l'on puisse substantiver l'adjectif strict.

Per contre, les dernières versions de GCC semblent ignorer la locale pour les messages, sortant toujours les messages en anglais.

Pour ceux qui n'auraient pas de talent de traduction inverse, voilà le texte original en anglais:

$ LC_ALL=C gcc-3.4.6 -O2 -Wall strictectomie-bilatérale.c
strictectomie-bilatérale.c: In function `main':
strictectomie-bilatérale.c:5: warning: dereferencing type-punned pointer will break strict-aliasing rules

GNU gettext

Cet outil est très largement utilisé pour les traductions des logiciels GNU, mais, par son principe même, fait apparaître du franglais et des traductions innoportunes.

Pour chaque phrase pour laquelle le logiciel souhaite fournir une traduction, il passe une chaîne de caractères l'identifiant à la fonction gettext(3). Des fichiers de traduction de type MO, situés dans un sous répertoire de /usr/share, font la correspondre une traduction à chaque identifiant. Si la traduction n'est pas définie, gettext(3) renvoie l'identifiant lui-même.

Il est donc naturel d'utiliser comme identifiant la phrase en anglais, puisqu'ainsi les fichiers de traduction ne sont pas nécessaires pour la version anglaise, et, si la traduction est incomplète, les éléments non traduit restent compréhensibles pour les anglophones. Mais, cela est aussi générateur de traductions cocasses:

• Des boîtes de dialogue contenant des boutons adjacents de traduction différente. En effet, le texte des boutons a pu être traduite ailleurs dans le logiciel.

  Créer

  Destroy

  Annuler

• La même traduction pour des homonymes anglais. Bon, en pratique c'est plutôt rare.

AbiWord

J'ai choisi AbiWord parce que c'est une des applications phare de GNOME, l'environement graphique de GNU. Il a un très grand nombre d'utilisateurs et de traducteurs. On peut s'attendre à ce que la traduction française soit de bonne qualité.

J'ai donc installé à l'occasion AbiWord 2.6.4 sur une CentOS et ai fouillé un peu tous les menus et boîtes de dialogues, comparant les versions anglaise et française.

Déjà, j'ai trouvé deux bogues sans avoir à les chercher. L'aperçu avant impression planta systématiquement, me gratifiant d'un message me suggérant d'installer bug-buddy, le copain des bogues. Ce bogue se révéla être lié au défaut de droits d'accès à /dev/random et doit se situer dans libcups. Ça reste un bogue. Le deuxième bogue concerne la gestion de la langue locale et nécessite une explication détaillée.

Les informations sur la locale, sous Linux, sont définies par des variables d'environnement, LANG, LC_CTYPE, LC_COLLATE, LC_MESSAGES, LC_NUMERIC, LC_TIME, LC_MONETARY et LC_ALL. Mis à part LANG et LC_ALL, chacune de ces variables d'environnement ne concerne qu'une facette particulière de la locale.

LC_MESSAGES concerne les chaînes de caractères traduites par gettext(3). LC_COLLATE concerne l'ordre lexicographique des caractères de telle sorte, qu'en français "é" est inférieur à "f". LC_NUMERIC concerne l'affichage des valeurs numériques et LC_TIME concerne l'affichage des dates et heures.

LC_ALL et LANG concernent tous les paramètres simultanément. Néammoins, LANG a une priorité inférieure aux paramètres spécifiques tandis que LC_ALL a une priorité supérieure à tous les autres.

Ainsi, si LANG=fr_FR.UTF-8 et LC_MESSAGES=en_US.UTF-8, la locale des messages est américaine. Par contre, si on rajoute LC_ALL=de_DE.UTF-8, ce dernier écrase les deux autres paramètres.

Les éléments de dialogue standard de GNOME respectent cette règle, par contre, AbiWord, je ne sais pourquoi, donne la priorité à LANG sur LC_ALL. Ainsi, la ligne de commande:

$ LC_ALL=C LANG=fr_FR.UTF-8 abiword

Donne de magnifiques mélanges anglais-français.

Mais, même en mode français pur, un certain nombre d'éléments n'ont pas été traduits:

L'existence de modules complémentaires non traduits par défaut, empire les choses:

Certaines traductions sont en mauvais français:

Ou avec un mode différent pour deux éléments adjacents, celui là étant liée à l'utilisation du même identifiant pour le menu "Insert" et le bouton "Insert":

Évidemment, l'option de surlignement des fautes d'ortographe en contient une!

Certaines formulations sont, pour le moins dire, étranges:

En fait, cette option annule toutes les modifications non enregistrées, alors qu'à en croire la traduction, elle ne ferait absolument rien!

Geek->Humain

Je ne peux m'empêcher de critiquer aussi UNIX pour ses messages d'erreurs parfois obscurs.

Par exemple, l'erreur ETXTBUSY est traduite en "Text file busy", qui, comme le comprendront tous les Geeks, est provoquée par la tentative d'écriture de données sur un fichier exécutable en cours d'exécution. Je suppose que "text file" veut dire ".text section" ce qui nous amène au problème suivant: Pourquoi la section de code binaire d'un exécutable porte-t-elle le nom ".text" ?