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 (for system-wide settings) and  (for user-specific settings). 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.

In some cases users may notice glitchy non-English representation in some applications like Krusader (https://bugs.kde.org/show_bug.cgi?id=371582). Removing or commenting the  line from  should fix the problem.

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 configuration file:

Another way of configuring system is to leave it in the default  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 your 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:

Native Language Support
For message based localization to work in programs that support it and have the  USE flag, compile the programs with this flag set. Message strings are installed in files. Most of the programs using the Native Language Support (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 LINGUAS variable that is used by some gettext-based build systems to control which localization files are built and installed. The variable takes in space-separated list of language codes, and a suggested place to set it is :

Note that there is a large difference between LINGUAS being unset and being set to an empty value: with, most ebuilds would install only the packages' default language but none of the   files.

L10N
A 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 :

To set it per-package, edit and prefix the requested language packs with "l10n_", as shown in the next example:

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)
 * L10N USE_EXPAND variable replacing LINGUAS
 * 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 ]