Localization/Guide/de

Zeitzonen
Damit die Systemzeit stets gültig ist, ist es notwendig die Zeitzone des aktuellen Standorts im System zu konfigurieren. Die Anleitungen für Systems auf Basis von OpenRC und systemd finden sich im Artikel zu system time.

Was sind Locales?
Eine Locale ist Satz von Informationen die von den meisten Programmen zum setzen von landes- oder sprachspezifischen Einstellungen genutzt werden. Die Locales und ihre Daten sind Teil der Systembibliotheken und sind meist unter gespeichert. Ein Lokalenname folgt dem Schema  wobei   ein zwei- oder dreibuchstabiger Sprachcode nach ISO-369 und   ein Ländercode nach ISO-3166 ist. Varianten von Localen werden durch zusätzliche Endungen unterschieden, etwa  oder. Mehr Informationen finden sie in der Wikipedia und den dort angegebenen Quellen.

Umgebungsvariablen für Locale
Die einzelnen Variablen steuern verschiedene Aspekte der Lokalisierung. Jede Variable kann auf einen Localenname wie oben beschrieben gesetzt werden. Die folgende Tabelle fasst die Bedeutung der einzelnen Variablen zusammen:

Für gewöhnlich setzen die meisten Nutzer die LANG Konfigurationsvariable lediglich global.

Erzeugen bestimmter locales
Die meisten Benutzer werden wahrscheinlich ein oder zwei Locale auf ihrem System benutzen. Wenn weitere locale installiert werden sollen, sind diese in anzugeben.

Der nächste Schritt ist die Ausführung von. Die erzeugt alle in aufgezählten Locale und schreibt diese in das Archiv unter.

Die Verfügbarkeit der Locales kann man mit dem Befehl überprüfen.

Der Inhalt von kann durch den Befehl  angezeigt werden.

Eine ungefilterte Anzeige bekommt man durch das Kommando.

OpenRC
Bei der Benutzung von OpenRC werden die Locale Einstellungen in Umgebungsvariablen gespeichert, die systemweit in und benutzerspezifisch in  eingestellt werden. Weitere Einzelheiten finden sich im Artikel zu UTF-8. Die Systemeinstellungen  werden durch  beeinflusst. Im folgenden Beispiel wird der Wert der Variablen LANG  auf den wert   gesetzt:

Natürlich ist es auch möglich die Datei von Hand zu editieren und die Sprachvariable zu verändern.

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

Für eine nutzerspezifische Sprachvariable:

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

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 :

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 ]