Chapitre 8. I18N et L10N

Table des matières

8.1. Les paramètres linguistiques (« locale »)
8.1.1. Justification de l’utilisation d’UTF-8 dans les paramètres linguistiques
8.1.2. Reconfiguration des paramètres linguistiques
8.1.3. Coder les noms de fichiers
8.1.4. Messages et documentation traduits
8.1.5. Effet des paramètres linguistiques
8.2. L’entrée clavier
8.2.1. The keyboard input for Linux console and X Window
8.2.2. The keyboard input for Wayland
8.2.3. Prise en charge de la méthode d’entrée avec iBus
8.2.4. Un exemple pour le japonais
8.3. L’affichage de sortie
8.4. East Asian Ambiguous Character Width Characters

Le multilinguisme (M17N) ou la gestion de la langue natale (« Native Language Support ») d’un logiciel applicatif est réalisé en deux étapes :

[Astuce] Astuce

There are 17, 18, or 10 letters between "m" and "n", "i" and "n", or "l" and "n" in multilingualization, internationalization, and localization which correspond to M17N, I18N, and L10N. See Introduction to i18n for details.

The behavior of programs supporting internationalization are configured by the environment variable "$LANG" to support localization. Actual support of locale dependent features by the libc library requires to install locales or locales-all packages. The locales package requires to be initialized properly.

If neither locales or locales-all package are installed, support of locale features are lost and system uses US English messages and handles data as ASCII. This behavior is the same way as "$LANG" is set by "LANG=", "LANG=C", or "LANG=POSIX".

The modern software such as GNOME and KDE are multilingualized. They are internationalized by making them handle UTF-8 data and localized by providing their translated messages through the gettext(1) infrastructure. Translated messages may be provided as separate localization packages.

The current Debian desktop GUI system normally sets the locale under GUI environment as "LANG=xx_YY.UTF-8". Here, "xx" is ISO 639 language codes and "YY" is ISO 3166 country codes. These values are set by the desktop configuration GUI dialogue and change the program behavior. See Section 1.5.2, « La variable « $LANG » »

The simplest representation of the text data is ASCII which is sufficient for English and uses less than 127 characters (representable with 7 bits).

Même le texte anglais en texte brut peut contenir des caractères non-ASCII, par exemple les guillemets apostrophes culbutés gauches et droits ne sont pas disponibles en ASCII.

“double quoted text” is not "double quoted ASCII"
‘single quoted text’ is not 'single quoted ASCII'

In order to support more characters, many character sets and encoding systems have been used to support many languages (see Tableau 11.2, « Liste de valeurs de codage et leur utilisation »).

Unicode character set can represent practically all characters known to human with 21 bit code point range (i.e., 0 to 10FFFF in hexadecimal notation).

Text encoding system UTF-8 fits Unicode code points into a sensible 8 bit data stream mostly compatible with the ASCII data processing system. This makes UTF-8 the modern preferred choice. UTF stands for Unicode Transformation Format. When ASCII plain text data is converted to UTF-8 one, it has exactly the same content and size as the original ASCII one. So you loose nothing by deploying UTF-8 locale.

Under UTF-8 locale with the compatible application program, you can display and edit any foreign language text data as long as required fonts and input methods are installed and enabled. For example under "LANG=fr_FR.UTF-8" locale, gedit(1) (text editor for the GNOME Desktop) can display and edit Chinese character text data while presenting menus in French.

[Astuce] Astuce

Both the new standard "en_US.UTF-8" locale and the old standard "C"/"POSIX" locale use the standard US English message, they have subtle differences in sorting order etc. If you want to handle not only ASCII characters but also handle all UTF-8 encoded characters gracefully while maintaining the old "C" local behavior, use the non-standard "C.UTF-8" locale on Debian.

[Note] Note

Certains programmes utilisent davantage de mémoire lors de l’utilisation de I18N. Cela parce qu’ils sont codés avec l’utilisation interne d’UTF-32(UCS4) pour la prise en compte d’Unicode afin d’optimiser la vitesse, ils utilisent 4 octets pour chaque caractère ASCII indépendamment de la « locale » sélectionnée. De nouveau, il n’y a rien à perdre en mettant en œuvre des paramètres linguistiques UTF-8.

Pour les échanges de données entre plateformes (consultez Section 10.1.7, « Périphériques d’enregistrement amovibles »), il vous faudra peut-être monter certains systèmes de fichiers ayant un codage particulier. Par exemple, , la commande mount(8) pour un système de fichiers vfat suppose que l’on utilise CP437 si on l’utilise sans option. Vous devrez fournir les options explicites à mount pour utiliser des noms de fichiers codés en UTF-8 ou en CP932.

[Note] Note

Lors du montage automatique d’un clé USB pouvant être branchée à chaud sur un environnement de bureau moderne comme GNOME, vous pouvez indiquer ces options de montage avec un clic-droit sur l’icône du bureau. Cliquez l’onglet « Drive », cliquez « Paramètres » pour l’étendre et entrez « utf8 » dans « Options de montage ». La prochaine fois que vous monterez cette clé mémoire, le montage avec UTF-8 sera activé.

[Note] Note

Si vous êtes en train de mettre à jour le système ou de déplacer des disques depuis un ancien système qui n’était pas UTF-8, les noms de fichiers avec des caractères non ASCII peuvent être codés avec des codages historiques et obsolètes tels que ISO-8859-1 ou eucJP. Veuillez consulter l’aide des outils de conversion de texte pour les convertir en UTF-8. Consultez Section 11.1, « Outils de conversion de données textuelles ».

Samba utilise Unicode pour les clients les plus récents (Windows NT, 200x, XP) mais utilise par défaut CP850 pour des clients plus anciens (DOS et Windows 9x/Me). Cette valeur par défaut pour les anciens clients peut être modifiée en utilisant « dos charset » dans le fichier « /etc/samba/smb.conf », par exemple, avecCP932 pour le japonais.

Il existe des traductions de nombreux messages et documents affichés par le système Debian, comme les messages d’erreur, la sortie standard des programmes,les menus et les pages de manuel. La GNU gettext(1) command tool chain est utilisé comme outil de base pour la plupart des activités de traduction.

Dans « Tâches » → « Localisation » aptitude(8) fournit une liste exhaustive de paquets binaires utiles qui ajoutent les traductions de messages aux applications et fournissent de la documentation traduite.

Vous pouvez, par exemple, obtenir les messages traduits pour une page de manuel en installant le paquet manpages-LANG. Pour lire la page de manuel de nom_programme en italien depuis « /usr/share/man/it/ », lancez le programme de la manière suivante :

LANG=it_IT.UTF-8 man programname

GNU gettext can accommodate priority list of translation languages with $LANGUAGE environment variable. For example:

 $ export LANGUAGE="pt:pt_BR:es:it:fr"

For more, see info gettext and read the section "The LANGUAGE variable".

L’ordre de tri des caractères avec sort(1) est affecté par le choix de la langue des paramètres linguistiques. Les paramètres linguistiques espagnol et anglais effectuent le tri de manière différente.

Le format de date de ls(1) est affecté par les paramètres linguistiques. Les formats de date de « LANG=C ls -l » et « LANG=en_US.UTF-8 » sont différents (consultez Section 9.3.4, « Affichage personnalisé de la date et de l’heure »).

La ponctuation des nombres est différente selon les paramètres linguistiques.Par exemple, avec les paramètres linguistiques anglais, Mille un est affiché sous la forme « 1,000.1 » alors qu’avec les paramètres linguistiques allemands ce sera « 1.000,1 ». Vous pouvez voir cette différence dans un programme de feuille de calculs.

Each detail feature of "$LANG" environment variable may be overridden by setting "$LC_*" variables. These environment variables can be overridden again by setting "$LC_ALL" variable. See locale(7) manpage for the details. Unless you have strong reason to create complicated configuration, please stay away from them and use only "$LANG" variable set to one of the UTF-8 locales.

For GNOME on Wayland desktop system, Section 8.2.1, « The keyboard input for Linux console and X Window » can't support non-English European languages. IBus was made to support not only Asian languages but also European languages. The package dependency of GNOME Desktop Environment recommends "ibus" via "gnome-shell". The code of "ibus" has been updated to integrate setxkbmap and XKB option functionalities. You need to configure ibus from "GNOME Settings" or "GNOME Tweaks" for the multilingualized keyboard input.

[Note] Note

If ibus is active, your classic X keyboard configuration by the setxkbmap may be overridden by ibus even under classic X-based desktop environment. You can disable installed ibus using im-config to set input method to "None". For more, see Debian Wiki on keyboard.

Linux console can only display limited characters. (You need to use special terminal program such as jfbterm(1) to display non-European languages on the non-GUI console.)

GUI environment (Chapitre 7, GUI System) can display any characters in the UTF-8 as long as required fonts are installed and enabled. (The encoding of the original font data is taken care and transparent to the user.)

Under the East Asian locale, the box drawing, Greek, and Cyrillic characters may be displayed wider than your desired width to cause the unaligned terminal output (see Unicode Standard Annex #11).

You can work around this problem:

  • gnome-terminal: Preferences → Profiles → Profile name → Compatibility → Ambiguous-wide characters → Narrow

  • ncurses : paramètre l'environnement export NCURSES_NO_UTF8_ACS=0.