☰

Debian 7 上的语言环境不会改变

tag-icon • tag-icon linux debian locale
Debian 7 上的语言环境不会改变

因此，我尝试了所有可以通过 Google 搜索到的方法，但语言环境设置仍然没有改变（有点，你会明白我的意思）。

要启动系统，需要先确保系统上有所需的语言环境 (lv_LV.UTF-8)：

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

我尝试使用以下方式设置语言环境sudo update-locale lv_LV.UTF-8

还尝试手动设置/etc/default/locale，但/etc/environment没有成功：

LANG=lv_LV.UTF-8
LC_MESSAGES=POSIX

如果我检查设置了什么语言环境，那么我会得到：

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

所以实际上有效的是，我在 Gnome 日历中获得了拉脱维亚语文本，并在区域和语言设置中看到“拉脱维亚”条目。但如果我尝试运行 Libre Calc，它会将点识别为小数分隔符，而不是逗号（在拉脱维亚语环境中设置）。

那么我还能/应该做什么才能在 Debian 中完全启用拉脱维亚语区域设置？基本上我需要这个，因为当我从 PHP 项目向数据库插入内容时，它会指责例如“1,25”是无效数字，应该是“1.25”，但在生产服务器上它接受反之亦然：应该是“1,25”而不是“1.25”。

答案1

一些各种各样的事情：

  1. 忘记吧— Debian在 Ech (4.0) 中/etc/environment改用了。/etc/default/locale

  2. 目的/etc/default/locale是使几个环境变量出现在一个进程中，启动用户的登录会话。

    现在有多种方法可以登录 Debian 系统；仅举几例：

    • 通过虚拟控制台 — 这些文本屏幕向您显示Login:通常在没有 X Window 系统的系统上看到的提示，或者在 X 显示器上工作时按Ctrl- Alt-时看到的提示。F1
    • 通过 X Window“显示管理器”——这个图形化的东西让用户提供他们的身份验证凭证，然后启动为他们运行某种桌面环境的 X Window 服务器。
    • 通过 SSH。

    （可能还有其他，但这不是重点。）

    这里重要的是，在基于 Linux 的系统上创建用户会话通常要经过所谓的聚丙烯酰胺层，其配置位于 下/etc/pam。现在，如果您执行

    $ grep -r locale /etc/pam.d

    您会看到该文件/etc/default/locale正在几个地方被读取。

    我要告诉您的是，为了真正“看到”更改的区域设置，您必须创建另一个登录会话 — 无论如何操作。例如，登录另一个虚拟控制台，或退出 X 桌面会话并重新登录。

  3. 由于/etc/default/locale只设置了一堆环境变量，它们可能会被覆盖。

    我要告诉你的是，假设你登录虚拟控制台；最终你的登录 shell 会运行并显示它的提示符。但是当 shell 启动时，它会读取它的启动脚本。例如，bash当作为登录 shell 运行时，会读取~/.bash_profile是否存在或/etc/bash_profile前者是否失败。你的本地~/.bash_profile可能包含类似

    export LANG=en_US

    ...然后你的环境设置就被覆盖了。

    非登录 shell 也会读取启动脚本（bashreads ~/.bashrc），并且这些脚本也可能会更改环境变量。

    因此，请仔细检查启动会话时是否没有覆盖。请注意，很难获得更精确的指针，因为在 Debian 系统上有很多方法可以获取工作会话，并且设置方式取决于其类型。

  4. 如果您的 PHP 代码与数据库后端的交互取决于 PHP 进程所看到的活动区域设置，那么您的项目就严重失败了，您最好集中精力修复它，而不是修复您的区域设置。否则，迟早会让您自食恶果。

    区域设置的整个概念仅用于软件与用户— 以自然的方式适应具有不同文化偏好等特定用户群体。这当然不包括与数据库服务器的交互。也就是说，当您解析用户输入的任何内容（例如，Web 表单）时，可能会（并且应该）使用区域设置，但是当您将该数据提供给数据库后端时，数据必须已经标准化 — 在您的情况下，它必须浮点数，而不是它们的字符串表示。如果适用且可能，请使用参数化的 SQL 查询。

答案2

首先，你一定要阅读@kostix 的帖子。

就我个人而言，我正在dpkg-reconfigure locales使用 Debian 重新配置语言环境。

例如：

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

相关内容