Fixing locales

Intro

I was having locale problems. Why? I don't know. But all of a sudden, applications like K3B (see the hack at the end of this article) would complain about locales not being properly set.

For example, viewing a man page in Konsole would generate a warning about "LC_ALL" not being set

So, after reading a zillion webpages, I finally punted and just appended to my ~/.bashrc file and man pages worked again

export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"
export LANGUAGE="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"

I ended up editing /var/lib/locales/supported.d/local

which already had the line

en_US.UTF-8 UTF-8

to which I added the following two lines

en_US ISO-8859-1
en_US.ISO-8859-15 ISO-8859-15

then I did a

sudo dpkg-reconfigure locales

which updated my system

That command seems to regenerate all the locales in /usr/lib/locale/

Documentation

There are a dizzying number of files, programs and settings involved in locale; and worse -- there are differences between distributions on what commands work, how they work; and where the configurations are stored. I suggest that you start off with

man:/locale-gen

to get an idea of what files are involved in your distribution.

For some reason, I do have an archive on my system (in addition to all the independent files) even though I've never issued the gen command with the archive option, and /etc/belocs/locale-gen.conf does not set the default to archive.

All the files in /var/lib/belocs will get updated when you run

sudo dpkg-reconfigure locales

See also

man:locale(1)

from that man page, you learn what

locale
locale -a
locale -m

are

in /etc/default/locale I have these two lines:

LANG="en_US.UTF-8"
LANGUAGE="en_US:en"

in /etc/environment I have

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
LANGUAGE="en_US:en"
LANG="en_US.UTF-8"

in /usr/share/i18n/SUPPORTED there is a very long list of the supported locales. You can take any number of them and add them to your /var/lib/locales/supported.d/local

Hack

Setting environment variables prior to launching an application is one way to work around this problem, but obviously does not solve it on a system-wise basis. I used this command in KMenu to get around the fact that the variable was set system-wide, but didn't get picked up in the application environment:

env LC_ALL='en_US.UTF-8' && k3b %U
# or the simpler
LC_ALL=en_US.UTF-8 k3b %U

and appended to an existing bug report with the workaround information (note that double quotes do not work in the KMenu environment.)