Chapter 8. I18N and L10N

Table of Contents

8.1. The locale
8.1.1. Rationale for UTF-8 locale
8.1.2. The reconfiguration of the locale
8.1.3. Filename encoding
8.1.4. Localized messages and translated documentation
8.1.5. Effects of the locale
8.2. The keyboard input
8.2.1. The keyboard input for Linux console and X Window
8.2.2. The keyboard input for Wayland
8.2.3. The input method support with IBus
8.2.4. An example for Japanese
8.3. The display output
8.4. East Asian Ambiguous Character Width Characters

Multilingualization (M17N) or Native Language Support for an application software is done in 2 steps.

[Tip] Tip

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, “The "$LANG" variable”

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

Even plain English text may contain non-ASCII characters, e.g. slightly curly left and right quotation marks are not available in 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 Table 11.2, “List of encoding values and their usage”).

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.

[Tip] Tip

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

Some programs consume more memory after supporting I18N. This is because they are coded to use UTF-32(UCS4) internally to support Unicode for speed optimization and consume 4 bytes per each ASCII character data independent of locale selected. Again, you loose nothing by deploying UTF-8 locale.

For cross platform data exchanges (see Section 10.1.7, “Removable storage device”), you may need to mount some filesystem with particular encodings. For example, mount(8) for vfat filesystem assumes CP437 if used without option. You need to provide explicit mount option to use UTF-8 or CP932 for filenames.

[Note] Note

When auto-mounting a hot-pluggable USB memory stick under modern desktop environment such as GNOME, you may provide such mount option by right clicking the icon on the desktop, click "Drive" tab, click to expand "Setting", and entering "utf8" to "Mount options:". The next time this memory stick is mounted, mount with UTF-8 is enabled.

[Note] Note

If you are upgrading system or moving disk drives from older non-UTF-8 system, file names with non-ASCII characters may be encoded in the historic and deprecated encodings such as ISO-8859-1 or eucJP. Please seek help of text conversion tools to convert them to UTF-8. See Section 11.1, “Text data conversion tools”.

Samba uses Unicode for newer clients (Windows NT, 200x, XP) but uses CP850 for older clients (DOS and Windows 9x/Me) as default. This default for older clients can be changed using "dos charset" in the "/etc/samba/smb.conf" file, e.g., to CP932 for Japanese.

Translations exist for many of the text messages and documents that are displayed in the Debian system, such as error messages, standard program output, menus, and manual pages. GNU gettext(1) command tool chain is used as the backend tool for most translation activities.

Under "Tasks" → "Localization" aptitude(8) provides an extensive list of useful binary packages which add localized messages to applications and provide translated documentation.

For example, you can obtain the localized message for manpage by installing the manpages-LANG package. To read the Italian-language manpage for programname from "/usr/share/man/it/", execute as the following.

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".

The sort order of characters with sort(1) is affected by the language choice of the locale. Spanish and English locale sort differently.

The date format of ls(1) is affected by the locale. The date format of "LANG=C ls -l" and "LANG=en_US.UTF-8" are different (see Section 9.3.4, “Customized display of time and date”).

Number punctuation are different for locales. For example, in English locale, one thousand point one is displayed as "1,000.1" while in German locale, it is displayed as "1.000,1". You may see this difference in spreadsheet program.

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.

Since GNOME Desktop Environment recommends "ibus" via "gnome-shell", "ibus" is the good choice for input method.

Multilingual input to the application is processed as:

Keyboard                                       Application
   |                                                 ^
   |                                                 |
   +-> Linux kernel ->  Input method (ibus)  -> Gtk, Qt, X, Wayland
                          +-- Engine--+

The list of IBus and its engine packages are the following.


[Note] Note

For Chinese, "fcitx5" may be an alternative input method framework. For Emacs aficionados, "uim" may be an alternative. Either cases, you may need to do extra manual configuration with im-config. Some old classic input methods such as "kinput2" may still exist in Debian repository but are not recommended for the modern environment.

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 (Chapter 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: Set environment export NCURSES_NO_UTF8_ACS=0.