Questão Locale no Debian 7 não muda


Então eu tentei todas as coisas que eu poderia fazer no Google, mas as configurações do local ainda não foram alteradas (tipo, você vai ver o que eu 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 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 que localidade está definido, 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 letão no calendário do Gnome e vejo a entrada nas configurações de região e idioma "Latvia". Mas se eu tentar executar o Libre Calc, ele reconhecerá o ponto como separador decimal em vez de coma (que é definido em locais letão).

Então, o que mais eu posso / deveria fazer para habilitar totalmente as localidades do Latvian 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'.


0


origem




Respostas:


Algumas coisas variadas:

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

  2. O ponto de /etc/default/locale é fazer um par de variáveis ​​de ambiente aparecem em um processo que inicia a sessão de login de um usuário.

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

    • Através de consoles virtuais - aquelas telas textuais que apresentam a você Login: prompt que você normalmente vê em um sistema sem o sistema X Window ou ao pressionar Ctrl-Alt-F1 ao trabalhar em um Xplay.
    • Via X Window "gerenciador de exibição" - aquela 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 geralmente passa pelo chamado PAM camada, que tem sua configuração sob /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 lá.

    O que eu estou levando você para, é 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. Desde a /etc/default/locale só define um monte de variáveis ​​de ambiente, eles podem ser anulados.

    O que eu estou levando você, se isso supor que você faça o 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 isso existe 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 sobrescritas.

    As cascas sem login também lêem scrits de inicialização (bash~/.bashrc) e esses scripts podem alterar as variáveis ​​de ambiente também.

    Então, por favor, verifique se você não tem overriddes no que quer 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 ele está sendo configurado depende do seu tipo.

  4. Se a interação de seu código PHP com seu backend de banco de dados depender da localidade ativa que o processo PHP vê, seu projeto está seriamente danificado e você deve se concentrar em consertá-lo em vez de em sua localidade. 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 determinados grupos de usuários com diferentes preferências culturais, etc. Isso certamente não inclui a interação com servidores de banco de dados. 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 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.


4



Muito obrigado por essa resposta descritiva. Você realmente me leva a corrigir o pensamento de que está em algum lugar substituído (embora eu não tenha achado onde está) e acabei editando ~/.bashrc com isso: export LC_ALL=lv_LV.UTF-8 e agora quando escrevo $ locale mostra um correto. Sobre a parte PHP - sim, a localidade do usuário não deve (e não é) afetar a comunicação com o banco de dados. E na verdade eu tive outro problema com isso, mas essa é uma nova história. Obrigado pela ajuda! - Sergey Zubov


Primeiro, você definitivamente deveria 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=

0



Eu esqueci de mencionar que eu usei dpkg-reconfigure locales também, mas não alterou localidade de usuários em vez disso, como você mostra afetado apenas sob su localidade. Mas obrigado pela sua ajuda. - Sergey Zubov
@SergeyZubov: ele define localidade do sistema, no entanto, existem vários lugares onde pode ser substituído por um usuário específico (em ~/.profile por exemplo). - barti_ddu