locale
specific information.
Synopsis
locale [
-a ⎪ -m]
locale [
-ck ] name...
add an example, a script, a trick and tips
examples
source
Why "LANG=C"? (not D or E or F)
In the C programming language, the locale name
C “specifies the minimal environment for C
translation” (C99 §7.11.1.1; the principle has been the same
since at least the 1980s). As most operating systems are written
in C, especially the unix-inspired ones where locales are set
through the LANG and LC_xxx environment
variables, C ends up being the name of a “safe”
locale everywhere.
POSIX specifies that both C and
POSIX must be valid locale names, with the same
neutral settings.
source
Linux - Forcing 24-hour locale?
Locales can be set for various components separately, so you can
set LC_TIME to either
"en_GB.utf-8" (Great Britain) or
"C" (no locale at all).
(Don't forget /etc/locale.gen.)
source
LANG and LANGUAGE environment variable in Debian based systems
Have a look at the manpage locale(7): it describes
that LANG is a fallback setting, while
LC_ALL overrides all separate LC_*
settings.
source
UTF-8 locale portability (and ssh)
It's an interesting question, but I think there may be a
misconception in there about how variables are set up. When a
secure shell session is initiated (ssh remotehost),
what happens at the other end is an instantiation of a new shell
with a separate environment. That is a fancy way of saying that
the server starts a fresh shell. That new shell may or may not be
configured with the same locale as your original local shell.
E.g
geee: ~
$ echo `locale |grep LANG` :: `date`
LANG=en_US.UTF-8 :: Mon Dec 3 07:04:00 CET 2012
$ ssh flode
flode: ~
$ echo `locale |grep LANG` :: `date`
LANG=nb_NO.UTF-8 LANGUAGE=nb_NO.UTF-8 :: ma. 03. des. 06:59:33 +0100 2012
In order to demonstrate this, I set up the locale on the remote
shell for Norwegian by adding the following lines to the
~/.bash_profile file:
export LANG=nb_NO.UTF-8
export LANGUAGE=nb_NO.UTF-8
export LC_ALL=nb_NO.UTF-8
Similarly, you will have to set up the environment on the
remote shell to do the same. Of course, other shells
read different startup files such as ~/.zprofile for the Z shell.
The misconception I suspected lay in that the local variables
(settings) are in no way forwarded. The remote shell has its own
settings. In order to list the available languages on the remote
host, be it a minimalistic BusyBox shell or a full-blown GNU OS,
use the locale command with the -a
switch (as noted in the question). Any of the printed lines may
be used as a locale setting for that environment.
As for the first question, the default locale that any shell
starts with is usually configured in a central place such as
/etc/profile. Most login shells read this file on startup.
source
Is it safe to remove /usr/share/locale if 'locales' package is removed
I just removed the directory on a test-box here(tm), and didn't
notice any issues. Reinstalling locales will
re-create the directory.
source
Debian 5.0 belocs-locales vs locales
I found the answer:
Getting locale changes into upstream glibc is unnecessarily
hard. The glibc maintainer (correctly) requires proof of the
correctness of a change before it's included, but the onus of
demonstrating that change falls to the glibc package
maintainers. The package maintainers are frequently not
qualified to provide this proof, and cannot answer upstreams
questions to the needed degree of satisfaction. The glibc
upstream maintainer also has a well deserved reputation for
being difficult to approach with changes.
For this reason, we should switch to the belocs locale
packages, which are separate from glibc and more easily
maintained.
source
How to define a custom locale?
Use of the gregorian calendar is hard-coded in glibc: https://github.com/rbdixon/glibc/blob/master/time/offtime.c#L58
So anything that uses the C library ("system") routines -
gmtime_r, localtime_r and so on - to
convert between seconds-since-the-epoch and broken-down-date
format, will stick to the "standard" calendar (365 days in a
year, Gregorian leap-year formula, 7 days per week...).
For code you write yourself, you could use the ICU Project's
libraries and provide your own non-Gergorian calendar
specification in the Unicode
Common Locale Data Repository XML format.
I'm pretty sure you don't want to do that.
source
Changing Ubuntu locale settings by GUI crashes the accounts-daemon
It turns out that my "~/.pam_environment" config is not being
read at all. I've than made a workaround by setting these in my
~/.profile file:
export LC_COLLATE="C"
export LANG="en_US.UTF-8"
export LC_ALL="pt_BR.UTF-8"
Though using LC_ALL is not recommended in the "locale" man entry.
The only cause I could find googli'n arount for .pam_environment
being ignored is home dir. encription usyng ecryptfs - and that's
not my case.
Anyway, its working, so let it be.
source
Kubuntu KDE Language Mixup
It sounds like, if they aren't being renamed back properly, you
might need to reinstall. Otherwise can I suggest perhaps moving
your .kde directory to "reset" all your settings temporarily and
see if that works.
source
Why "LANG=C"? (not D or E or F)
In the C
programming language, the locale name C
“specifies the minimal environment for C translation” (C99
§7.11.1.1; the principle has been the same since at least the
1980s). As most operating systems are written in C, especially
the unix-inspired ones where locales are set through the
LANG and LC_xxx environment variables,
C ends up being the name of a “safe” locale
everywhere.
POSIX specifies that both C and
POSIX must be valid locale names, with the same
neutral settings.
source
Changing keyboard layout
In the terminal try
su - gnome-keyboard-properties
OR
if the default Gmone2 system /administration / keyboard
source
How to use LC_MESSAGES=C with gcc every time?
Create an alias in your shell.
alias gcc="LC_MESSAGES=C \gcc"
source
Use a modern locale, but retain asciibetical sorting?
Put
export LC_COLLATE=C
in your ~/.profile or ~/.bash_profile. The traditional location
is ~/.profile, but some distributions now use other files for
setting the environment before starting your window manager.
description
The
locale program writes information about the current
locale environment, or all locales, to standard output.
When invoked
without arguments, locale summarizes the current
locale environment for each locale category defined by the
LC_* environment variables.
-a,
--all-locales
Write names of available locales.
-m,
--charmaps
Write names of available charmaps.
Output
Format:
-c,
--category-name
Write names of selected categories.
-k,
--keyword-name
Write names and values of selected keywords.
environment variables
These environment variables affect each locale categories for all
locale-aware programs:
LC_CTYPE
Character classification and case conversion.
LC_COLLATE
Collation order.
LC_TIME
Date and time formats.
LC_NUMERIC
Non-monetary numeric formats.
LC_MONETARY
Monetary formats.
LC_MESSAGES
Formats of informative and diagnostic messages and
interactive responses.
LC_PAPER
Paper size.
LC_NAME
Name formats.
LC_ADDRESS
Address formats and location information.
LC_TELEPHONE
Telephone number formats.
LC_MEASUREMENT
Measurement units (Metric or Other).
LC_IDENTIFICATION
Metadata about the locale information.
This environment variable can switch against multiple locale
database:
LOCPATH
The directory where locale data is stored. By default, /usr/lib/locale is used.
files
/usr/share/i18n/SUPPORTED
List of supported values (and their associated encoding) for the
locale name. This representation is recommended over
--all-locales one, due being the system wide supported
values.
see also
locale,
locale, setlocale
author
locale was written by
Ulrich Drepper for the GNU C Library.
This manpage was written by Joel Klecker
<espy[:at:]debian[:dot:]org> for the Debian GNU/Linux system, and
expanded by Alastair McKinstry
<mckinstry[:at:]computer[:dot:]org>