Locale no Debian 7 não muda

Question

Então eu tentei todas as coisas que eu pude fazer no Google, mas as configurações de localidade ainda não foram alteradas (você verá o que quero dizer).

Para iniciar o local desejado (lv_LV.UTF-8) está disponível no sistema:

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

Eu tentei definir a localidade com sudo update-locale lv_LV.UTF-8

Também tentou definir manualmente em /etc/default/locale e /etc/environment sem sorte:

LANG=lv_LV.UTF-8
LC_MESSAGES=POSIX

Se eu verificar qual localidade está definida, obtenho:

$ 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=

Então, o que realmente funciona é que eu recebo texto em letão no calendário do Gnome e vejo a entrada nas configurações de região e idioma "Letônia". Mas se eu tentar executar o Libre Calc, ele reconhecerá o ponto como separador decimal em vez de coma (que é definido em locais letões).

Então, o que mais eu posso / deveria fazer para habilitar totalmente as localidades da Letônia no Debian? Basicamente eu preciso disso, porque quando eu faço inserções no banco de dados do projeto PHP, ele culpa que, por exemplo, '1,25' é um número inválido e deve ser '1,25', mas no servidor de produção aceita vice-versa: deve ser '1,25' e não '1,25'.

    

Answer 1

Algumas coisas variadas:

1. Esqueça sobre /etc/environment - a Debian mudou para usando /etc/default/locale em Etch (4.0).

2. O ponto de /etc/default/locale é fazer com que algumas variáveis de ambiente apareçam em um processo que inicie a sessão de login de um usuário.

   Agora existem várias maneiras de entrar em um sistema Debian; para citar alguns:

   • Por meio de consoles virtuais - as telas textuais que apresentam o prompt Login: que você normalmente vê em um sistema sem o sistema X Window ou ao pressionar Ctrl - Alt - F1 ao trabalhar em um Xplay.
   • O "gerenciador de exibição" do Via X Window - essa coisa gráfica que permite ao usuário fornecer suas credenciais de autenticação e, em seguida, inicia o servidor X Window executando algum tipo de ambiente de área de trabalho para eles.
   • Via SSH.

   (Pode haver outros, mas isso está além do ponto.)

   O que importa aqui é que a criação da sessão do usuário em sistemas baseados em Linux normalmente passa pela chamada camada PAM , que tem sua configuração em /etc/pam . Agora se você fizer

   $ grep -r locale /etc/pam.d
   

   você verá que o arquivo /etc/default/locale está sendo lido em alguns lugares.

   O que eu estou levando você, é que para realmente "ver" as configurações de localidade alteradas, você tem que criar outra sessão de login - não importa como você faz isso. Digamos, faça logon em outro console virtual ou saia da sua sessão de desktop X e faça login novamente.

3. Como /etc/default/locale apenas define um monte de variáveis de ambiente, elas podem ser substituídas.

   O que eu estou levando você, se isso supor que você faça login em um console virtual; no final, seu shell de login é executado e mostra seu prompt. Mas quando o shell é iniciado, ele lê seus scripts de inicialização. Por exemplo, bash , quando executado como um shell de login, lê ~/.bash_profile se existir ou /etc/bash_profile se o primeiro falhar. Seu local ~/.bash_profile pode conter algo como

   export LANG=en_US
   

   … e viola - você tem suas configurações de ambiente substituídas.

   Non-login shells também lêem scrits de inicialização ( bash reads ~/.bashrc ) e esses scripts também podem alterar as variáveis de ambiente.

   Então, por favor, verifique se você não tem overriddes em qualquer coisa que inicie sua sessão. Observe que é difícil obter ponteiros mais precisos, porque há muitas maneiras de obter uma sessão de trabalho em um sistema Debian, e a maneira como ela está sendo configurada depende de seu tipo.

4. Se a interação do seu código PHP com o backend do seu banco de dados depende da localidade ativa que o processo do PHP vê, seu projeto está seriamente danificado e você deve se concentrar em consertá-lo em vez do local. Caso contrário, isso vai te morder no pescoço, mais cedo ou mais tarde.

   Todo o conceito de configurações de localidade existe somente para o software se comunicar com o usuário - de uma maneira natural a grupos específicos de usuários com diferentes preferências culturais etc. Isso certamente não inclui interação com banco de dados servidores. Ou seja, as configurações de localidade podem (e devem) ser usadas quando você analisa o que seu usuário digitou, digamos, um formulário da Web, mas quando você fornece esses dados a um back-end de banco de dados, os dados já devem estar normalizados - no seu caso < em> tem que ser números de ponto flutuante, não suas representações de string. E use consultas SQL parametrizadas, se aplicável e possível.

Answer 2

Primeiro, você deve definitivamente ler o post @kostix.

Pessoalmente, estou reconfigurando locales com dpkg-reconfigure locales no Debian.

Por exemplo:

$ 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=