Locale on Debian 7 doesn't change

Question

So I have tried all things that I could Google up but still locale settings aren't changed (kind of, you will see what I mean).

To start off desired locale (lv_LV.UTF-8) is available on the system:

$ locale -a
C
C.UTF-8
en_US.utf8
lv_LV.utf8
POSIX

I have tried to set locale with sudo update-locale lv_LV.UTF-8

Also tried to set manually in /etc/default/locale and /etc/environment with no luck:

LANG=lv_LV.UTF-8
LC_MESSAGES=POSIX

If i check what locale is set then I get:

$ locale
LANG=en_US.utf8
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES=POSIX
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

So what DOES actually work is that I get Latvian text in Gnome calendar and see entry in Region and Language settings "Latvia". But if I try running Libre Calc then it recognizes dot as decimal separator instead of coma (which is set in Latvian locales).

So what else I can/should do to fully enable Latvian locales in Debian? Basically I need this because when I make inserts to database from PHP project it blames that e.g. '1,25' is invalid number and it should be '1.25' but on production server it accepts vice-versa: should be '1,25' and not '1.25'.

Answer 1

A couple of assorted things:

1. Forget about /etc/environment — Debian switched to using /etc/default/locale instead in Etch (4.0).

2. The point of /etc/default/locale is to make a couple of environment variables appear in a process which initiates a user's login session.

   Now there are several ways to log into a Debian system; to name a few:

   • Via virtual consoles — those textual screens presenting you with the Login: prompt you typically see on a system without the X Window system or when pressing Ctrl-Alt-F1 when working on an X diplay.
   • Via X Window "display manager" — that graphical thing which lets the user provide their authentication credentials and then starts the X Window server running some sort of desktop environment for them.
   • Via SSH.

   (There may be others but that's beyond the point.)

   What matters here is that creating the user's session on Linux-based systems typically goes through the so-called PAM layer, which has its configuration under /etc/pam. Now if you do

   $ grep -r locale /etc/pam.d
   

   you'll see that the file /etc/default/locale is being read in a few places there.

   What I'm leading you to, is that in order to actually "see" the changed locale settings, you have to create another login session — no matter how you do it. Say, log on another virtual console, or quit your X desktop session and log back in.

3. Since /etc/default/locale only sets a bunch of environment variables, they may be overridden.

   What I'm leading you to, if that suppose you log in on a virtual console; in the end your login shell is run and shows you its prompt. But when the shell starts up, it reads its startup scrips. For instance, bash, when running as a login shell, reads ~/.bash_profile if that exists or /etc/bash_profile if the former fails. Your local ~/.bash_profile may containg something like

   export LANG=en_US
   

   …and viola — you have your environment settings overridden.

   Non-login shells also read startup scrits (bash reads ~/.bashrc) and these scripts might change the environment variables as well.

   So, please double check you don't have overriddes in whatever starts your session up. Notice that it's hard to get more precise pointers because there are many ways to get a working session on a Debian system, and the way it's being set up depends on its type.

4. If the interaction of your PHP code with your database backend depends on the active locale the PHP process sees, your project is seriously botched and you'd better concentrate on fixing it instead rather than your locale. Otherwise this will bite you in the neck, sooner or later.

   The whole concept of locale settings exists solely for the software to communicate with the user — in a way natural to particular groups of users having different cultural preferences etc. This certainly does not include interaction with database servers. That is, locale settings might (and should) be used when you parse whatever your user entered to, say, a web form, but when you supply that data to a database backend, the data must be already normalized — in your case it has to be floaing-point numbers, not their string representations. And use parameterized SQL queries, if applicable and possible.

Answer 2

First, you should definitely read @kostix post.

Personally, I'm reconfiguring locales with dpkg-reconfigure locales on Debian.

For example:

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ su -
[Password]

# dpkg-reconfigure locales
[Select C.UTF-8 for example]

# exit
$ su -
# locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=