Page suivante Page précédente Table des matières

3. Configuration des locales

3.1 Les fichiers et le kernel

Vous pouvez maintenant utiliser n'importe quel caractère Unicode dans les noms de fichiers. Ni le kernel ni aucun utilitaire système ne nécessite de modifications. Ceci parce que les noms de fichiers dans le kernel peuvent être n'importe quoi qui ne contient ni octet nul, ni '/' (utilisé pour délimiter les sous-répertoires). Quand ils sont encodés en utilisant UTF-8, les caractères non-ASCII ne seront jamais encodés en utilisant un octet nul ou un slash. La seule conséquence est que les noms de fichiers et de répertoires occupent plus d'octets qu'ils ne contiennent de caractères. Par exemple, un nom de fichier contenant cinq caractères grecs apparaîtra pour le kernel comme un nom de fichier de 10 octets. Le kernel ne sait pas (et n'a pas besoin de savoir) que ces octets sont affichés en grec.

C'est une théorie générale, qui est vraie tant que vos fichiers restent sur un système Linux. Sur les systèmes de fichiers utilisés depuis d'autres systèmes d'exploitation, mount possède des options pour contrôler la conversion des noms de fichiers de/vers UTF-8 :

Les autres systèmes de fichiers (nfs, smbfs, ncpfs, hpfs, etc.) ne convertissent pas les noms de fichiers. Par conséquent ils accepteront les noms de fichier Unicode encodés en UTF-8 seulement si l'autre système d'exploitation les supporte. Rappelez vous que pour qu'une option de montage soit appliquée aux prochains montages, vous devez l'ajouter à la quatrième colonne de la ligne correspondante dans /etc/fstab.

3.2 Le kernel et les ttys

Les ttys sont en quelque sorte des tubes bidirectionnels entre deux programmes, autorisant des choses comme la répétition (echoing) ou l'édition de la ligne de commande. Quand dans un xterm, vous exécutez la commande "cat" sans arguments, vous pouvez entrer et éditer autant de lignes que vous voulez, elles seront répétées en retour ligne par ligne. Les actions d'édition du kernel ne sont pas correctes, en particulier les touche Backspace et Tab ne seront pas traitées correctement.

Pour résoudre ce problème, vous devez :

Pour que ce changement soit persistant même à travers rlogin et telnet, vous devrez aussi :

3.3 Conversion de données générales

Vous aurez besoin d'un programme pour convertir vos fichiers texte locaux (probablement ISO-8859-1) en UTF-8. L'alternative serait de continuer à utiliser des textes qui utilisent différents encodages sur la même machine, mais ce n'est pas une bonne solution sur le long terme. Un de ces programmes est "iconv", qui est livré avec la glibc-2.1. Tapez simplement 

icon --from-code=ISO-8859-1 --to-code=UTF-8 < vieux_fichier > nouveau_fichier

Voici deux scripts shell très pratiques, appelés  "i2u" i2u.sh (pour conversion de ISO à UTF) et  "u2i" u2i.sh (pour conversion de UTF à ISO). [skip adapt..]

Si vous n'avez pas la glibc-2.1 et iconv installés, vous pouvez utiliser GNU recode 3.5 à la place. "i2u" i2u_recode.sh est "recode ISO-8859-1..UTF-8" "u2i" u2i_recode.sh est "recode UTF-8..ISO-8859-1".
ftp://ftp.iro.umontreal.ca/pub/recode/recode-3.5.tar.gz
ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz
Notes : vous devez utiliser GNU recode 3.5 ou plus. Pour compiler GNU recode sur des plateformes sans glibc-2 (c'est à dire sur toutes les plateformes sauf les systèmes Linux récents), vous devez le configurer avec "--disable-nls", autrement l'édition des liens échouera.

Sinon, vous pouvez aussi utiliser CLISP à la place. Voici "i2u" et "u2i" en version lisp : i2u.lsp et u2i.lsp.
Note : Vous devez avoir une version de CLISP qui date au plus de juillet 1999.
ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz
D'autres programmes de conversion de données existent, mais ils sont moins puissants que GNU recode. Ce sont

3.4 Les variables d'environnement locales

Vous pouvez avoir les variables d'environnement suivantes positionnées, contenant les noms de locales :

LANGUAGE

Remplacement pour LC_MESSAGES. Seulement utilisé par GNU gettext.

LC_ALL

Remplacement pour toute les autres variables LC_* : 

LC_CTYPE, LC_MESSAGES, LC_COLLATE, LC_NUMERIC, LC_MONETARY, LC_TIME

Ce sont des variables individuelles pour : le type des caractères et leur encodage, les messages en langue maternelle, les règles de classement, le format des nombres, le format des montants monétaires, l'affichage de la date et de l'heure.

LANG

Valeur par défaut pour toutes les variables LC_*

(Voir `man 7 locale' pour une description détaillée.)

Chacune des variables LC_* et LANG peuvent contenir un nom de locale de la forme suivante :

language[_territory[.codeset]][@modifier]

Où language est un code de langue ISO 639 (en minuscules), territory est un code de pays ISO 3166 (en majuscules), codeset désigne une table de caractères, et modifier d'autres attributs particuliers (par pour exemple indiquer un dialecte particulier d'une langue, ou une orthographe non standard).

LANGUAGE peut contenir plusieurs noms de locale, séparés par deux points (:).

Pour dire à votre système et à toutes les applications que vous utilisez UTF-8, vous devez ajouter un suffixe d'UTF-8 à vos noms de locales. Par exemple, si vous utilisiez 

LANGUAGE=de:fr:en
LC_CTYPE=de_DE

vous le changeriez en 

LANGUAGE=de.UTF-8:fr.UTF-8:en.UTF-8
LC_CTYPE=de_DE.UTF-8

3.5 Créer les fichiers pour le support des locales

Si vous avez la glibc-2.1 ou glibc-2.1.1 ou glibc-2.1.2 installée, vérifiez d'abord en utilisant "localedef -help" que le répertoire système pour le tables de caractères est /usr/share/i18n/charmaps. Puis appliquez au fichier /usr/share/i18n/charmaps/UTF8 le patch glibc21.diff ou glibc211.diff ou glibc212.diff, respectivement. Puis créez les fichiers de support pour toute les locales UTF-8 que vous voulez utiliser, par exemple : 

$ localedef -v -c -i de_DE -f UTF8 /usr/share/locale/de_DE.UTF-8

Généralement vous n'avez pas besoin de créer des variables appelées "de" ou "fr" sans suffixe pour le code du pays, parce que ces locales sont normalement utilisées seulement par la variable LANGUAGE, et pas par les variables LC_*. De plus LANGUAGE est seulement utilisé en remplacement de LC_MESSAGES.

3.6 Ajouter le support pour la bibliothèque C

La glibc-2.2 supportera les locales multi-octets (de plusieurs octets), en particulier les locales UTF-8 créées plus haut. Mais les glibc-2.1 et 2.1.1 ne la supportent pas réellement. Par conséquent le seul effet réel de la création des fichiers /usr/local/share/de_DE.UTF-8/* ci dessus est que setlocale(LC_ALL,"") retournera "de_DE.UTF-8", conformément à vos variables d'environnement, au lieu d'enlever le suffixe "UTF-8".

Pour ajouter le support pour la locale UTF-8, vous devriez compiler et installer la bibliothèque 'libutf8_plug.so', depuis libutf8-0.5.2.tar.gz. Puis vous pouvez positionner la variable d'environnement LD_PRELOAD pour qu'elle pointe sur la bibliothèque installée : 

export LD_PRELOAD=/usr/local/lib/libutf8_plug.so
Alors, dans chaque programme lancé avec cette variable d'environnement positionnée, les fonctions de libutf8_plug.so seront appelées à la place des originales dans /lib/libc.so.6. Pour plus d'informations sur LS_PRELOAD, voyez "man 8 ld.so".

Tout cela ne sera plus nécessaire quand la glibc-2.2 sortira.

3.7 Conversion des catalogues de messages

Maintenant ajoutons un contenu à ces nouvelles locales. Les commandes /bin/sh suivantes convertiront vos catalogues de messages au format UTF-8. Elles doivent être lancées en tant que root, et nécessitent les programmes 'msgfmt' et 'msgunfmt' de GNU gettext-0.10.35 convert-msgcat.sh.
Ceci non plus ne sera plus nécessaire une fois que la glibc-2.2 sera sortie, parce qu'alors la fonction gettext convertira les chaînes de caractères de façon appropriée depuis la table de caractères du traducteur vers la table de caractères de l'utilisateur, en utilisant soit iconv soit librecode.

Page suivante Page précédente Table des matières