Localization/Guide/en

Time zone
In order to keep the system time properly according to the present location, the timezone needs to be set. Instructions how to do this for OpenRC based systems and systemd based systems can be found in the system time article.

What are locales?
A locale is a set of information that most programs use for determining country and language specific settings. The locales and their data are part of the system library and can be found at on most systems. A locale name is generally named  where   is the two (or three) letter language code (as specified in ISO-639) and   is the two letter country code (as specified in ISO-3166). Variants like  or   are often appended to locale names, e.g.   or. Please explore wikipedia to read more about locales and related articles.

Environment variables for locales
The variables controlling different aspects of locale settings are given in the table below. All of them take one name of a locale in  format given above.

Most typically, users only set the LANG variable globally.

Generating specific locales
Most users will probably only use one or maybe two locales on their system. How additional locales can be specified is explained in the file.

The next step is to run. It will generate all the locales specified in the file and write them to the locale-archive.

Verify that the selected locales are available by running.

The file can be shown by.

Its raw content can be displayed using the command.

OpenRC
When using OpenRC locale settings are stored in environment variables. These are typically set in the (for system-wide settings) and  (for user-specific settings) file. More details can be found in the UTF-8 article. The system wide settings can be managed through. For instance, to set the LANG variable to the  value:

Of course, editing the file manually is possible as well to diversify the locale variables.

It's also possible, and pretty common especially in a more traditional UNIX environment, to leave the global settings unchanged, i.e. in the " " locale. Users can still specify their preferred locale in their own shell RC file:

Another way of configuring system is to leave it in the default C locale, but enable UTF-8 character representation at the same time. This option is achieved using the following settings in :

Using the above snippet, users will be able to see localized file names properly, while not being forced to completely use the selected language.

Once the right locale is set up, be sure to update the environment variables to make the system aware of the change.

For a system-wide default locale:

For a user-specific locale:

After this, kill the X server by pressing ++, log out, then log in as a user.

Now, verify that the changes have taken effect:

systemd
With systemd set the locale with the command. Check the list of available locales with:

Then set the desired locale:

Finally check if the result is good:

OpenRC
The keyboard layout used by the console is set in by the keymap variable. Valid values can be found in. has further subdivisions into layout (,, etc.). Some languages have multiple options - experiment with the various options to decide which one fits the needs best.

systemd
With systemd the keymap layout used for the console can be set using the command. First check the available keymap layouts:

Then set the requested console keymap layout:

Finally check if the console keymap layout was set correctly:

OpenRC
The keyboard layout to be used by the X server is specified in by the XkbLayout option. For details visit the Xorg guide and the article about Keyboard layout switching.

systemd
With systemd the keymap layout for the X11 server can be set using the command. First check the available X11 keymap layouts:

Then set the requested X11 keymap layout:

Finally check if the X11 keymap layout was set correctly:

NLS
For message based localization to work in programs that support it and have the (Native language support) USE flag, compile the programs with this flag set. Message strings are installed in files. Most of the programs using nls also need the gettext library to extract and use localized messages. Of course, Portage will automatically install it when needed.

After enabling the  USE flag some packages might need to be re-emerged:

LINGUAS
There is also an additional USE_EXPAND flag called LINGUAS, which affects the localization files that get installed in gettext-based programs, and decides which GUI language packs should be downloaded and installed for some specific software packages, such as Firefox, Thunderbird, kde-base/kde-l10n or app-office/libreoffice-l10n. The variable takes in space-separated list of language codes, and a suggested place to set it is :

With, most ebuilds would install only the packages' default language but none of the   files. They would also not download and install any of the further language packs. For instance, the currently stable app-office/libreoffice receives further language support through which supports download and installation of the language packs defined in. Since the origin language of libreoffice is, it does not have   flag in. So with, libreoffice still supports.

To see the status of GUI translation, hyphenation, spell checking and other localizations on the language, please refer to the LibreOffice translation web site.

For finer grained control the USE_EXPAND variables can be set per package in :

A list of installed programs making use of the LINGUAS USE_EXPAND flag and their supported languages can be shown as follows:

A list of LINGUAS values that can be used is provided as :

After setting the LINGUAS USE_EXPAND flag it may be necessary to re-emerge some packages:

L10N
Another USE_EXPAND variable called L10N decides which extra localization support will be installed. This is commonly used for downloads of additional language packs by packages. Similar to LINGUAS, the variable takes a space separated list of language tags, and it can be set in :

Note that while the common two letter language codes (like  or  ) are identical in LINGUAS and L10N, more complex entries have a different syntax because L10N uses IETF language tags (aka BCP 47). For example,  and   in LINGUAS become   and   in L10N, respectively.

A list of L10N values that can be used is provided as :

After setting the L10N USE_EXPAND variable it may be necessary to re-emerge some packages:

External resources

 * Locales and Internationalization (gnu.org)
 * Michał Górny:How LINGUAS are thrice wrong!
 * [gentoo-dev [RFC] How to deal with LINGUAS mess? ]
 * [gentoo-dev [RFC] Masterplan for solving LINGUAS problems ]