A locale defines cultural conventions for a particular language
and region of the world (see Locales in The GNU C Library
Reference Manual). Each locale has a name that typically has the form
fr_LU.utf8 designates the locale for the French language, with
cultural conventions from Luxembourg, and using the UTF-8 encoding.
Usually, you will want to specify the default locale for the machine
locale field of the
The selected locale is automatically added to the locale
definitions known to the system if needed, with its codeset inferred
from its name—e.g.,
bo_CN.utf8 will be assumed to use the
UTF-8 codeset. Additional locale definitions can be specified in
locale-definitions slot of
useful, for instance, if the codeset could not be inferred from the
locale name. The default set of locale definitions includes some widely
used locales, but not all the available locales, in order to save space.
For instance, to add the North Frisian locale for Germany, the value of that field may be:
Likewise, to save space, one might want
list only the locales that are actually used, as in:
The compiled locale definitions are available at
X.Y is the libc
version, which is the default location where the GNU libc provided
by Guix looks for locale data. This can be overridden using the
LOCPATH environment variable (see
LOCPATH and locale packages).
locale-definition form is provided by the
locale) module. Details are given below.
This is the data type of a locale definition.
The name of the locale. See Locale Names in The GNU C Library Reference Manual, for more information on locale names.
The name of the source for that locale. This is typically the
language_territory part of the locale name.
The “character set” or “code set” for that locale, as defined by IANA.
A list of commonly used UTF-8 locales, used as the default
value of the
locale-definitions field of
These locale definitions use the normalized codeset for the part
that follows the dot in the name (see normalized codeset in The GNU C Library Reference Manual). So for
instance it has
uk_UA.utf8 but not, say,
operating-system declarations provide a
to specify the GNU libc packages that are used to compile locale
declarations (see operating-system Reference). “Why would I
care?”, you may ask. Well, it turns out that the binary format of
locale data is occasionally incompatible from one libc version to
For instance, a program linked against libc version 2.21 is unable to
read locale data produced with libc 2.22; worse, that program
aborts instead of simply ignoring the incompatible locale
Similarly, a program linked against libc 2.22 can read most, but not
all, of the locale data from libc 2.21 (specifically,
data is incompatible); thus calls to
setlocale may fail, but
programs will not abort.
The “problem” with Guix is that users have a lot of freedom: They can choose whether and when to upgrade software in their profiles, and might be using a libc version different from the one the system administrator used to build the system-wide locale data.
Fortunately, unprivileged users can also install their own locale data
GUIX_LOCPATH accordingly (see
GUIX_LOCPATH and locale packages).
Still, it is best if the system-wide locale data at
/run/current-system/locale is built for all the libc versions
actually in use on the system, so that all the programs can access
it—this is especially crucial on a multi-user system. To do that, the
administrator can specify several libc packages in the
locale-libcs field of
(use-package-modules base) (operating-system ;; … (locale-libcs (list glibc-2.21 (canonical-package glibc))))
This example would lead to a system containing locale definitions for both libc 2.21 and the current version of libc in /run/current-system/locale.
Versions 2.23 and later of GNU libc will simply skip the incompatible locale data, which is already an improvement.