Locales are used by and other locale-aware programs or libraries for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards.
Locale names are typically of the form
language[_territory][.codeset][@modifier], where language is an ISO 639 language code, territory is an ISO 3166 country code, and codeset is a character set or encoding identifier like ISO-8859-1 or UTF-8. See .
For a list of enabled locales, run:
$ locale -a
Before a locale can be enabled on the system, it must be generated. This can be achieved by uncommenting applicable entries in
/etc/locale.gen, and running locale-gen. Equivalently, commenting entries disables their respective locales. While making changes, consider any localisations required by other users on the system, as well as specific #Variables.
For example, uncomment
en_US.UTF-8 UTF-8 for American-English:
... #en_SG ISO-8859-1 en_US.UTF-8 UTF-8 #en_US ISO-8859-1 ...
Save the file, and generate the locale:
Setting the locale
To display the currently set locale and its related environmental settings, type:
The locale to be used, chosen among the previously generated ones, is set in
locale.conf files. Each of these files must contain a new-line separated list of environment variable assignments, having the same format as output by locale.
To list available locales which have been previously generated, run:
$ localedef --list-archive
$ localectl list-locales
Setting the system locale
To set the system locale, write the
LANG variable to
en_US.UTF-8 belongs to the first column of an uncommented entry in
# localectl set-locale LANG=en_US.UTF-8
See #Variables and for details.
Overriding system locale per user session
The system-wide locale can be overridden in each user session by creating or editing
The precedence of these
locale.conf files is defined in
- This can also allow keeping the logs in
/var/log/in English while using the local language in the user environment.
- You can create a
/etc/skel/.config/locale.conffile so that any new users added using useradd and the
-moption will have
Make locale changes immediate
Once system and user
locale.conf files have been created or edited, their new values will take effect for new sessions at login. To have the current environment use the new settings unset
LANG and source
$ unset LANG $ source /etc/profile.d/locale.sh
LANGvariable has to be unset first, otherwise
locale.shwill not update the values from
locale.conf. Only new and changed variables will be updated; variables removed from
locale.confwill still be set in the session.
Locale variables can also be defined with the standard methods as explained in Environment variables.
For example, in order to test or debug a particular application during development, it could be launched with something like:
$ LANG=C ./my_application.sh
Similarly, to set the locale for all processes run from the current shell (for example, during system installation):
$ export LANG=C
locale.conf files support the following environment variables.
Full meaning of the above
LC_* variables can be found on manpage , whereas details of their definition are described on .
LANG: default locale
The locale set for this variable will be used for all the
LC_* variables that are not explicitly set.
LC_MESSAGES(user interface for message translation) variable to
LANGUAGE: fallback locales
Programs which use
LANGUAGE option in addition to the usual variables. This allows users to specify a list of locales that will be used in that order. If a translation for the preferred locale is unavailable, another from a similar locale will be used instead of the default. For example, an Australian user might want to fall back to British rather than US spelling:
en_US, but instead make it the default locale, which is
C. If in
LANGUAGEa non-English locale is placed after English, e.g.
LANGUAGE=en_US:en:es_ES, then applications may choose the secondary locale despite English strings being available. The solution is to always explicitly place the
Clocale after English. E.g.
LC_TIME: date and time format
LC_TIME is set to
en_US.UTF-8, for example, the date format will be "MM/DD/YYYY". If wanting to use the the ISO 8601 date format of "YYYY-MM-DD" use:
2.29 fixed a bug,
en_US.UTF-8 started showing in 12-hour format, as was intended. If wanting to use 24-hour format, use
LC_TIMEwith versions 57 to 84 (Bug 1429578).
This variable governs the collation rules used for sorting and regular expressions.
Setting the value to
C can for example make the ls command sort dotfiles first, followed by uppercase and lowercase filenames:
See also .
To get around potential issues, Arch used to set
/etc/profile, but this method is now deprecated.
The locale set for this variable will always override
LANG and all the other
LC_* variables, whether they are set or not. If
LC_ALL is set to
C, it will also override
LC_ALL is the only
LC_* variable which cannot be set in
locale.conf files: it is meant to be used only for testing or troubleshooting purposes, for example in
LC_ALL=C, does not override
LANGUAGE. See glibc bug 16621 and gettext bug 62815.
My terminal does not support UTF-8
The following lists some (not all) terminals that support UTF-8:
- VTE-based terminals
- xterm - Run with the argument
-u8or configure resource
Gnome-terminal or rxvt-unicode
You need to launch these applications from a UTF-8 locale or they will drop UTF-8 support. Enable the
en_US.UTF-8 locale (or your local UTF-8 alternative) per the instructions above and set it as the default locale, then reboot.
My system is still using wrong language
It is possible that the environment variables are redefined in other files than
locale.conf. See Environment variables#Defining variables for details.
If you are using a desktop environment, such as GNOME, its language settings may be overriding the settings in
KDE Plasma also allows to change the UI's language through the system settings. If the desktop environment is still using the default language after the modification, deleting the file at
~/.config/plasma-locale-settings.sh) should resolve the issue.
If you are using a display manager in combination with Display manager#Set language for user session., follow the instructions in
LightDM will automatically use to set a user's locale if it is installed. Otherwise, LightDM stores the user session configuration in
~/.dmrc. It is possible that an unwanted locale setting is retrieved from there as well.