# 最精简有效的 glibc locales 设定

## EricHsu

 *更新 wrote:*   

> 
> 
>  2006-05-15: 更正 - locale.gen 格式与 locales.buid 不同, 请参看这个 howto, 所有支持的 locales 可以在 /usr/share/i18n/SUPPORTED 中找到 - 格式要按这个文章里的写法, 所以现在的 locale.gen 应为:
> 
> ```
> ...

 

最精简有效的 glibc locales 设定

By EricHsu

- begin.200412211044

经过昨天一天实验, 把 glibc 重装了 4 次, 得出如下获得最精简 glibc locales 设置的方法 (下面是步骤, 没耐心了解其原因的朋友直接照做就可以, 有兴趣问个为什么的, 我会在步骤后面给出详细解释. 另, 条件所限, 仅针对简体中文用户):

一. 步骤

 确保 emerge glibc 时, useflags 中有 userlocales

要让 glibc 在 emerge 时仅生成我们所需的 locales, 那么必须设置 userlocales useflag:

```

# echo "sys-libs/glibc userlocales" >> /etc/portage/package.use

```

emerge -pv glibc 时应看到:

 *Quote:*   

> 
> 
> [ebuild   R   ] sys-libs/glibc-2.3.4.20041102  -build -debug -erandom -hardened -multilib +nls -nomalloccheck +nptl +nptlonly -pic +userlocales 0 kB
> 
> 

 

 编辑 /etc/locales.build, 仅设置如下 5 行, 其余一律注释掉:

```

en_US/ISO-8859-1

en_US.UTF-8/UTF-8

zh_CN/GB18030

zh_CN.GB2312/GB2312

zh_CN.UTF-8/UTF-8

```

 安装 glibc

```

# emerge --oneshot glibc

```

 设置系统的 LC_ALL 为 zh_CN

编辑 /etc/env.d/99local, 如果没有这个文件就自己创建, 添加一行:

```

LC_ALL=zh_CN

```

然后运行:

```

# env-update 

```

 注销, 重新登录, GB18030 字符集里的中文字都应该能正常显示, 测试:

 创建一个文件名包含这两个字 (攞, 離) 的空文件, 应能正常显示:

```

$ touch 攞離.txt

$ ls -l

-rwxrwx---  1 root users       0 12月 21 11:04 攞離.txt

```

 在网页中的 flash 里右键, flash 的菜单选项中的中文应正常显示

 让仅支持 gb2312/utf8 的程序正常工作

 仅支持 gb2312 的 bittornado

```

$ echo $LC_ALL

zh_CN

$ btdownloadgui.py

段错误

$ LC_ALL=zh_CN.gb2312 btdownloadgui.py

(正常运作)

```

 仅支持 utf8 的 gxmame

```

$ echo $LC_ALL

zh_CN

$ gxmame

(大量错误输出:

(gxmame.original:7583): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()

且界面所有中文变成空白)

$ LC_ALL=zh_CN.utf8 gxmame

(正常运作)

```

二. 解释

 只有在 useflags 中设置了 userlocales 后, /etc/locales.build 这个文件才会起作用, 否则, emerge glibc 默认将生成所有 locales

 /etc/locales.build 的解释:

 *Quote:*   

> 
> 
> # 必不可少的英文支持
> 
> en_US/ISO-8859-1
> ...

 

对于 /etc/locales.build 的格式 (每一行为 <locale>/<charmap>) 有时会让人迷惑, 比如会看到 de_DE@euro/ISO-8859-15 这样的, 又会看到 en_US.UTF-8/UTF-8... 我当时就一直不理解为什么会有个 "@" 符号? 什么时候该用 "."? 其实很简单, 

 在 /usr/share/i18n/locale 目录中, 就有一个 de_DE@euro 的文件, 所以这个 locale 就等于 de_DE@euro, "@" 符号与格式无关! 

 至于 ".", 这个不好解释, 可以理解为有生成 "子 locale" 的意思, 唯一要保证的是, "." 后的内容必须是 /usr/share/i18n/charmaps 中存在的 charmap. 例如 /usr/share/i18n/charmap 中有 GB18030.gz, GB2312.gz, GBK.gz, 那么我们就可以 zh_CN.GB18030/GB18030, zh_CN.GB2312/GB2312, zh_CN.GBK/GBK

经过实验发现, 每个 locale 项会在 /usr/lib/locale 下生成一个同名的目录, 例如, 如上配置, 我们将在 /usr/lib/locale 下得到如下目录:

```

eric@gentux ~ $  ls /usr/lib/locale/

en_US  en_US.utf8  ru_RU  zh_CN  zh_CN.gb2312  zh_CN.utf8

```

(注, ru_RU 里面的内容为空, 我删掉过, 但是 emerge glibc 时又会生成, 忽略之)

每个目录恰好与 /etc/locales.build 中的 locales 一一对应.

 为何要设置 LC_ALL=zh_CN?

其实最新的一些程序大都支持 locales 如 zh_CN.GBK, zh_CN.GB18030, zh_CN.UTF-8, 但是, 有些程序还是仅支持到 GB2312, 它们在 GBK, GB18030, UTF-8 下会运作不正常. 例如, 浏览器的 flash 插件的仅在 LC_ALL=zh_CN 的情况下, 其右键菜单才能正常显示中文, 在 LC_ALL=zh_CN.GBK 下, 右键菜单空白. 总之, 通过 LC_ALL=zh_CN 设置系统的 locale 为 zh_CN 将最大限度让新老程序的中文都运作正常. 而又因为 /usr/lib/locale/zh_CN 下的 LC_* 文件的内容都是使用 /usr/share/i18n/charmaps 里的 GB18030.gz 这一目前最全 (?) 的中文码表来生成的, 因此, 这又让所有程序覆盖了最全 (?) 的中文字符, 系统将可以正常处理 GB18030 字符集范围以内的所有中文字符 (当然, 还是有限制, 有些生僻的中文字符还是显示成方块, 那是因为字体文件本身的限制造成的, 如果我没记错的话, simsun 仅支持到 GBK 字符集, 不过已经绝对够用了. 如果还非要显示所有字符, 那就设法找个支持 GB18030 字符集的字体吧, 好像有个 simsun-18030).

三. 实验记录

实验前, glibc 是安装系统是装的, 当时没有设置 userlocales 这一 useflags, 因此 glibc 安装过程中生成了所有的 locales.

 第一次:

 /etc/locales.build

```

en_US/ISO-8859-1

en_US.UTF-8/UTF-8

zh_CN/GB2312

zh_CN/GBK

zh_CN/GB18030

zh_CN.UTF8/UTF-8

```

注意, 上面有两个错误:

 不能同时写 zh_CN/GB2312, zh_CN/GBK, zh_CN/GB18030, 这会让 glibc 往 /usr/lib/locale/zh_CN 目录里逐个生成 GB2312, GBK, GB18030 的 LC_* 文件, 结果是: 最终只剩 GB18030 - GBK 覆盖了 GB2312, 接着 GB18030 覆盖了 GBK.

 应该是 zh_CN.UTF-8 而非 zh_CN.UTF8, emerge 完才发现-_-#

 echo $LC_ALL

```

zh_CN

```

 locale -a

```

C

en_US

en_US.utf8

POSIX

zh_CN

zh_CN.utf8

```

 ls /usr/lib/locale

```

en_US  en_US.utf8  ru_RU  zh_CN  zh_CN.utf8

```

 问题:

 bittornado 默认 LC_ALL 下段错误, export LC_ALL=zh_CN.GB2312 后再运行, 则提示 GB2312 不是系统支持的 locale (因为之前的那个互相覆盖... locale -a 中可以看出系统中只有 GB18030 和 UTF-8 ), 自动 fallback 回 C locale, 含中文信息的 torrent 显示乱码.

 第二次:

 /etc/locales.build

```

en_US/ISO-8859-1

en_US.UTF-8/UTF-8

zh_CN/GB2312

zh_CN.GBK/GBK

zh_CN.GB18030/GB18030

zh_CN.UTF-8/UTF-8

```

 echo $LC_ALL

```

zh_CN

```

 locale -a

```

C

en_US

en_US.utf8

POSIX

zh_CN

zh_CN.gb18030

zh_CN.gbk

zh_CN.utf8

```

 ls /usr/lib/locale

```

en_US  en_US.utf8  ru_RU  zh_CN  zh_CN.gb18030  zh_CN.gbk  zh_CN.utf8

```

 问题:

 在 LC_ALL=zh_CN 的情况下, 含这两个字 (攞, 離) 的文件名显示为 \224{... 这样的乱码. 这是因为 /usr/lib/locale/zh_CN 下的 LC_* 文件内容仅以 GB2312 码表生成, 因此无法覆盖超过 GB2312 字符集的字符.

 在设置 LC_ALL=zh_CN.GBK 之后, 上述二字显示正常, 说明 GBK 字符集覆盖了这些字. 但是这时在浏览器中, flash 右键, 菜单为空白, 所有中文在 GBK 下都无法正常显示.

 在设置 LC_ALL=zh_CN.UTF8 之后, 上述二字显示正常, 说明 GB18030 字符集覆盖了这些字. 但是这时在浏览器中, flash 右键, 菜单成为英文.

 第三次:

 /etc/locales.build

```

en_US/ISO-8859-1

en_US.UTF-8/UTF-8

zh_CN/GB18030

zh_CN.UTF-8/UTF-8

```

 echo $LC_ALL

```

zh_CN

```

 locale -a

```

C

en_US

en_US.utf8

POSIX

zh_CN

zh_CN.utf8

```

 ls /usr/lib/locale

```

en_US  en_US.utf8  ru_RU  zh_CN  zh_CN.utf8

```

 问题:

 由于 zh_CN 下的 LC_* 是用 GB18030 生成的, 在把系统 LC_ALL 设置为 zh_CN 之后, 同时获得了最大限度覆盖所有中文字符以及让新老程序尽可能支持中文的好处 (如 flash 右键菜单显示正常). 可是这时 bittornado 会出现如第一次时的情况, 段错误, 以及自动 fallback 回 C locale 以致中文乱码的问题. 主要因为系统中没有 zh_CN.GB2312 的 locale 可以给它使用.

 第四次:

 /etc/locales.build

```

en_US/ISO-8859-1

en_US.UTF-8/UTF-8

zh_CN/GB18030

zh_CN.GB2312/GB2312

zh_CN.UTF-8/UTF-8

```

 echo $LC_ALL

```

zh_CN

```

 locale -a

```

C

en_US

en_US.utf8

POSIX

zh_CN

zh_CN.gb2312

zh_CN.utf8

```

 ls /usr/lib/locale

```

en_US  en_US.utf8  ru_RU  zh_CN  zh_CN.gb2312  zh_CN.utf8

```

 问题: 迄今暂无!

 小结: 在第三次实验的基础上, 为 /etc/locales.build 中添加了一行 zh_CN.GB2312/GB2312 之后, 系统的 locale 获得迄今最精简最完美的结果:

 系统支持目前最全的中文字符集 GB18030

 由于 LC_ALL=zh_CN, 因此新老程序对中文的支持同样完美

 仅支持 gb2312 (bittornado) 或 utf8 (gxmame) 的程序都有符合它们需要的 locale 以供选择

- end.200412211314

----------

## shyokou

Feel so nice seeing your such good practice  :Smile: 

I think it would be better to ask those authors to update their locale interface for a better internationalized environment.

I also prefer UTF-8 as possible.

----------

## Hauser

Bootstrap之前就設好了locales.build的朋友請注意Bootstrap之後你可能得再次編輯locales.build並重編glibc，請看這個Bug report。不過Bootstrap之前設好locales.build仍是有好處的，因為少了很多locales，glibc會編譯得較快。

----------

## EricHsu

 *shyokou wrote:*   

> Feel so nice seeing your such good practice 
> 
> I think it would be better to ask those authors to update their locale interface for a better internationalized environment.
> 
> I also prefer UTF-8 as possible.

 

Thanks  :Smile: 

UTF-8 应该会是将来的主流, 不过目前还是保留 gb2312 较为恰当, 系统本身则使用 gb18030, 这样可以得到最好的兼容性  :Smile: 

----------

## EricHsu

 *Hauser wrote:*   

> Bootstrap之前設好locales.build仍是有好處的，因為少了很多locales，glibc會編譯得較快。

 

确实, build locales 本身就得不少时间, 且全 build 了能让 glibc 体积大上一倍, 我记得用 quickpkg 打包后, 全 build 的大小 32M 左右, 而现在只有 12M.

----------

## foolbaby

还是把GBK加上吧

xmms好象不支持18030吧

害我折腾了半天,哈哈

----------

## EricHsu

 *foolbaby wrote:*   

> 还是把GBK加上吧
> 
> xmms好象不支持18030吧
> 
> 害我折腾了半天,哈哈

 

你在把 LC_* 设置为 zh_CN 之后, xmms 不支持的 "症状" 是什么? 能否仔细描述一下? xmms 肯定不支持 zh_CN.GB18030, 但它确实支持 zh_CN 以及 zh_CN.GBK. 

而我的方法就是让整个系统的 locale 为 zh_CN.

你是否把 LC_* 或者 LANG 这些变量给设置成了 zh_CN.GB18030?

另外, 如果你是 gnome/gtk 用户, 非常推荐你使用 beep-media-player, 它是基于 xmms 的, 但是图形界面部分全部重写成 gtk2 的 (xmms 还是 gtk1 的程序), 现在的 0.9.7 版非常稳定非常好用, 我机器里已经没有 xmms 了 (所以没法确认你的问题 :Wink:  ), 就是因为 beep-media-player 完全足以取代 xmms, 且界面很舒服, 和现在的 gnome/gtk2 感观完全一致  :Very Happy: 

----------

## linky_fan

不过我倒是遇到过一个很好玩的问题, 用beep-media-player(2004.3+nptl+xfcd4)的playlist下面的add添加曲目的时候, 出现的file,url,dir选择列表直接跑到了画面的左上角, 打开窗口后倒是没什么.还好不影响使用  :Very Happy: 

----------

## akar

謝謝 Eric， 用上了， 這幾天， 發現 Gentoo又快了不少！！

 */etc/locales.build wrote:*   

> 
> 
> en_US/ISO-8859-1
> 
> en_US.UTF-8/UTF-8
> ...

 

還有記得用 localepurge， 以下是要保留的一些locale， 不過我試了之後， 相信我安裝的版本（app-admin/localepurge-0.2-r1）是 大小寫區分的(錯蟲?)。

所以留意當中的兩個紅字部份。

 */etc/locale.nopurge wrote:*   

> 
> 
> en_US
> 
> en_US.iso88591
> ...

 

----------

## EricHsu

 *akar wrote:*   

> 謝謝 Eric， 用上了， 這幾天， 發現 Gentoo又快了不少！！

 

呵呵, 突然变快? 为什么呢?? 我看了你的帖子里的链接, 正把 -O3 改成 -O2 然后重 build 了几个常用的软件, 恩... 快没快没法说... 反正程序是小了一些, 然后呢, 干净启动时空闲内存多了 2M 左右, 嘿嘿...

 *Quote:*   

> 
> 
> 還有記得用 localepurge， 以下是要保留的一些locale， 不過我試了之後， 相信我安裝的版本（app-admin/localepurge-0.2-r1）是 大小寫區分的(錯蟲?)。
> 
> 所以留意當中的兩個紅字部份。
> ...

 

sorry, 没用过 localepurge -_-# 其实我一直也比较迷惑的问题之一就是 charmap 部分的大小写, 好像 zh_CN.gb2312 zh_CN.GB2312 我都见过... 有明白的朋友么? 说说? (大小写并存的情况会不会是历史遗留问题? 也就是说原本就不太规范, 两种写法都有?..)

----------

## Hauser

All those locales supported by glibc can be viewed by unpacking the source, the file is: /var/tmp/portage/glibc-......../work/glibc-........../localedata/SUPPORTED.

----------

## foolbaby

就是播放列表乱码，还有主窗口也是乱码，我将gbk加上就好了

我是将LC全部设为zh_CN了

用惯了xmms，呵呵，有空一定试试bmp

 *EricHsu wrote:*   

>  *foolbaby wrote:*   还是把GBK加上吧
> 
> xmms好象不支持18030吧
> 
> 害我折腾了半天,哈哈 
> ...

 

----------

## EricHsu

 *foolbaby wrote:*   

> 就是播放列表乱码，还有主窗口也是乱码，我将gbk加上就好了
> 
> 我是将LC全部设为zh_CN了
> 
> 用惯了xmms，呵呵，有空一定试试bmp
> ...

 

呵呵, 那在 locales.build 中不妨设置成:

 */etc/locales.build wrote:*   

> 
> 
> en_US/ISO-8859-1
> 
> en_US.UTF-8/UTF-8
> ...

 

然后系统的 locale 还是设置成 zh_CN. 以我所知, 如果设置成 zh_CN.GBK, 那么 flash 插件的邮件菜单中的中文是空白... 遇到过么?

另外, 回帖时请不要 "top post" - 也就是不要在引用内容之上发自己的内容. 尽量在引用内容的下面发, 这样会比较方便阅读  :Wink: 

----------

## EricHsu

 *linky_fan wrote:*   

> 不过我倒是遇到过一个很好玩的问题, 用beep-media-player(2004.3+nptl+xfcd4)的playlist下面的add添加曲目的时候, 出现的file,url,dir选择列表直接跑到了画面的左上角, 打开窗口后倒是没什么.还好不影响使用 

 

beep 之前的版本确实在窗口定位方面有问题! 我第一次用它就火了一把, 然后删掉, 不知你用的是哪个版本? 现在的 0.9.7 非常非常棒, 没有任何问题!  :Very Happy: 

另:

to akar:

我用 localepurge 了! 给我在 /usr/share/locales 下腾出了百多兆空间! 关于 locale.nopurge 里 locale 名的问题, 我觉得大小写只需根据 /usr/share/locales 下你想保留的 locales 目录是怎么写的就在 locale.nopurge 里怎么写  :Smile: 

localepurge 只清除 /usr/share/locales 下的东西.

to Hauser:

谢谢你的信息!

----------

## linky_fan

 *Quote:*   

> 
> 
> linky_fan 写到:
> 
> 不过我倒是遇到过一个很好玩的问题, 用beep-media-player(2004.3+nptl+xfcd4)的playlist下面的add添加曲目的时候, 出现的file,url,dir选择列表直接跑到了画面的左上角, 打开窗口后倒是没什么.还好不影响使用 Very Happy
> ...

 

现在已经换成0.9.7rc2了, 以前用2004.2的时候的问题了, 因为不影响使用的说.  :Wink: 

----------

## akar

 *EricHsu wrote:*   

> 
> 
> 我用 localepurge 了! 给我在 /usr/share/locales 下腾出了百多兆空间! 关于 locale.nopurge 里 locale 名的问题, 我觉得大小写只需根据 /usr/share/locales 下你想保留的 locales 目录是怎么写的就在 locale.nopurge 里怎么写 
> 
> 

 

 :Smile:  對， 概念正確，正是 localepurge想做的。 但要經常使用 localepurge，因為安裝軟件之後，不同的locale的mo又來了，看來localepurge會是我桌面Gentoo的第一個cron工作。

不過大小寫區分的特性在這個小工具localepurge下，我認為是一個缺憾。難道locale的名稱還有大小寫的區分嗎？

 *EricHsu wrote:*   

> 
> 
> localepurge 只清除 /usr/share/locales 下的东西.
> 
> 

 

 :Exclamation:   除了 locales之外， 還有不要 “男人” （MANDELETE）。

----------

## ahaau

怪事，怎么重新生成？

man gvim

Failed to open the message catalog "man" for locale "zh_CN.UTF-8"

(NLSPATH="/usr/share/locale/%L/%N")

----------

## omidxo

最新的glibc-2.3.4.20050125已经不再生成诸如/usr/lib/locale/zh_CN目录，而是以一个locale-archive文件代替。

且由于我的输入法GBK字符输出出了点问题，故将/etc/env.d/99local改为LC_ALL=zh_CN.gb18030。

看来工作还算正常，bittornado也没有“段错误”提示；浏览器的flash插件不知什么时候右键菜单变成E文了，也就不存在“中文空白”的现象了。

----------

## foolbaby

用了20050125之后

我locale -a输出结果变成这样了

C

en_US

en_US.iso88591

en_US.utf8

POSIX

zh_CN

zh_CN.gb18030

zh_CN.gb2312

zh_CN.gbk

zh_CN.utf8

不知道这时候zh_CN对应的码表是哪一个阿

----------

## omidxo

我的/etc/locales.build这样写：

```
en_US/ISO-8859-1

en_US.UTF-8/UTF-8

zh_CN/GB18030

zh_CN.GBK/GBK

zh_CN.GB2312/GB2312

zh_CN.UTF-8/UTF-8
```

locale -a输出确实多出了一个：

```
zh_CN.gb18030
```

想必是额外输出的一个local名，对用户而言不无好处。

多次尝试发现，如果用zh_CN的local，输入法fcitc无法输出朱镕基的“镕”字，索性将/etc/env.d/99local留空，在~/.dmrc使用用户级的Language=zh_CN.gbk，除了btdownloadgui.py有“GLib-GObject-WARNING”的错误提示（可能另有原因），一切都还满意，flash右键中文显示也正常。

----------

## wangxiaohu

最近经常用。。所以顶一下。。省得翻页。。

----------

## ppip

这么好的文章应该标记一个 stiky

----------

## richard.xsi

请问在glibc已经编译好的情况下，我用localedef生成的locale和重新编译glibc的那种应该是完全一样的吧？

----------

## EricHsu

 *richard.xsi wrote:*   

> 请问在glibc已经编译好的情况下，我用localedef生成的locale和重新编译glibc的那种应该是完全一样的吧？

 

这个问题我还真不知道, 没有朋友了解么? 给大家讲解讲解   :Question: 

----------

## richard.xsi

 *EricHsu wrote:*   

>  *richard.xsi wrote:*   请问在glibc已经编译好的情况下，我用localedef生成的locale和重新编译glibc的那种应该是完全一样的吧？ 
> 
> 这个问题我还真不知道, 没有朋友了解么? 给大家讲解讲解  

 

我比较过他们的生成的locale相关文件大小都是一样的，可是

打开localdef的verbose之后发现有些错误信息，奇怪。

 :Cool: 

----------

## dragonlinux

17 Apr 2006; Mike Frysinger <vapier@gentoo.org> glibc-2.4-r2.ebuild:

  Kill USE=userlocales and replace with Debian locale-gen #22565.

I try your way but I always got :

#echo "sys-libs/glibc userlocales" >> /etc/portage/package.use

# emerge -pv sys-libs/glibc

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] sys-libs/glibc-2.4-r4  USE="nls nptl nptlonly -build -glibc-compat20 -glibc-omitfp -hardened (-multilib) -profile (-selinux)" 0 kB

Total size of downloads: 0 kB

so does it mean the compiling changed? it will compile according to locale.gen?

----------

## i13m

我记得好几个版本以前,安装glibc的时候,它会把所有locale都安装上,不管能用的上还是用不上的. 但后来呢,glibc会根据用户的需要去选择要安装那些locale. 好比我用zh_CN.UTF-8的话,就不用特地去安装一些我不需要的locale,像it_*,fr_*.

glibc开始支持自定的locale的时候,用户要先把自己需要的locale设定并且放在/etc/locale.build(好像是这个文件),然后当emerge -av glibc的时候,相应的locale会在emerge的过程中产生处. 但前提是要使用userlocales这个glibc's flag, 否则的话glibc还是会生成所有的locale. 此方法可以参照: http://gentoo-wiki.com/HOWTO_Optimise_glibc

而最近的一次的glibc升级呢(具体时间忘记了), 用户可以在安装完glibc这个过程后,使用locale-gen这个命令去生成自己所需要的locale. 前提是要设定好/etc/locale.gen这个文件.

简单的来说,以前如果想要生成特定locale的时候,需要emerge glibc一次.而现在呢,只需要运行一个locale-gen命令就可以了.

在我的记忆中这样来的,如果有错误的话请指出.

----------

## r0bertz

 *i13m wrote:*   

> 我记得好几个版本以前,安装glibc的时候,它会把所有locale都安装上,不管能用的上还是用不上的. 但后来呢,glibc会根据用户的需要去选择要安装那些locale. 好比我用zh_CN.UTF-8的话,就不用特地去安装一些我不需要的locale,像it_*,fr_*.
> 
> glibc开始支持自定的locale的时候,用户要先把自己需要的locale设定并且放在/etc/locale.build(好像是这个文件),然后当emerge -av glibc的时候,相应的locale会在emerge的过程中产生处. 但前提是要使用userlocales这个glibc's flag, 否则的话glibc还是会生成所有的locale. 此方法可以参照: http://gentoo-wiki.com/HOWTO_Optimise_glibc
> 
> 而最近的一次的glibc升级呢(具体时间忘记了), 用户可以在安装完glibc这个过程后,使用locale-gen这个命令去生成自己所需要的locale. 前提是要设定好/etc/locale.gen这个文件.
> ...

 

没看你的上一帖么？

17 Apr 2006; Mike Frysinger <vapier@gentoo.org> glibc-2.4-r2.ebuild:

Kill USE=userlocales and replace with Debian locale-gen #22565.

----------

