Re: Passage en langue anglaise
On Tue, Aug 08, 2006 at 10:01:00AM +0200, Vincent Lefevre wrote:
[...]
> Mais le fait que en* soit ignoré bien que l'exécutable contienne
> les messages en anglais, est-ce que cela te paraît normal, du point
> de vue de l'utilisateur? Y aurait-il une raison pour laquelle un
> utilisateur aurait besoin d'utiliser LANGUAGE=en:fr?
Hmmm, je ne comprends pas ta question.
La variable LANGUAGE est une extension GNU, utilisée notamment par
GNU gettext et GNU libc ; elle sert lors de l'affichage des chaines
issues des catalogues gettext, c'est-à-dire
/usr/share/locale/<locale>/LC_MESSAGES/<domaine>.mo
Cela explique les interrogations de Mike concernant la commande date :
celle-ci utilise les définitions fournies dans la locale actuelle, et
pas LC_MESSAGES/coreutils.mo, pour afficher la date, le contenu de
LANGUAGE n'a donc aucune influence dans ce cas très précis.
Pour le vérifier :
$ LC_ALL=fr_FR.UTF-8 LANGUAGE=en strace -e open cp
[...]
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
cp: missing file operand
Try `cp --help' for more information.
$ LC_ALL=fr_FR.UTF-8 LANGUAGE=en strace -e open date
[...]
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
open("/etc/localtime", O_RDONLY) = 3
mardi 8 août 2006, 21:36:41 (UTC+0200)
Maintenant que le cas de date est élucidé, revenons à nos moutons :
$ LC_ALL=fr_FR.UTF-8 LANGUAGE=en_US:fr_FR strace -e open cp
[...]
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr_FR/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 3
cp: opérande fichier manquant
Pour en savoir davantage, faites: « cp --help ».
On peut déjà tirer plusieurs conclusions de cet exemple :
- Avec LANGUAGE=en_US:fr_FR, les catalogues sont cherchées dans l'ordre
dans les sous-répertoires en_US, en, fr_FR et fr ; ainsi mettre
LANGUAGE=en_US:en:fr_FR:fr donnera un résultat strictement identique.
- Comme les catalogues en_US et en n'existent pas, on a des messages
en français.
- Avec LANGUAGE=fr_CA:fr_CH, on ne verra le catalogue fr_CH que si fr
n'existe pas.
- Le contenu du catalogue fr est codé en ISO-8859-1, et doit donc être
converti en UTF-8.
La forme complète d'une locale est
<langue>_<territoire>.<jeu de caractères>@<modificateur>
Tu peux regarder avec
$ LC_ALL=fr_FR.UTF-8 LANGUAGE=en_US.UTF-8@boldquot strace -e open cp
dans quel ordre exact sont cherchés les catalogues, et comparer les
sorties de
$ LC_ALL=fr_FR.UTF-8 LANGUAGE=en@boldquot gettext --help
$ LC_ALL=fr_FR.UTF-8 LANGUAGE=en gettext --help
pour voir à quoi sert le catalogue en@boldquot
> > > Enfin, sur une de mes machines, /usr/share/locale/en_US/LC_MESSAGES/
> > > contient tout de même gcalctool.mo et /usr/share/locale/en/LC_MESSAGES/
> > > contient xmms.mo (mais rien d'autre).
> >
> > Cela a un sens si ces fichiers contiennent des caractères non-ASCII,
>
> Obtient-on quelque chose de différent en définissant LANGUAGE=en (par
> exemple) et en ne définissant pas de langue (e.g. LANG=C), notamment
> si les fichiers contiennent des caractères non-ASCII?
Si LANG=C (ou est une locale qui n'existe pas, ce qui est équivalent),
le contenu de LANGUAGE est ignoré, les messages originaux sont écrits.
Je ne connais pas la raison exacte, mais c'est fait exprès d'après les
commentaires dans les sources.
Denis
Reply to: