一、前言:
最近这个话题大家吵得有点厉害，大家都希望 Linux 能在中文方面有所进步，各家有
各家的说法，莫衷一是。由於我最近常与 CLE 的 group 有联系，同时也正在写一些与
中文相关的程式，因此我大略说一下「我们正在做什麽」，让大家参考。

我希望大家能将这篇文章当做技术性文章来读，不要再有情绪化的批评，必境我们要的
是 solution, 情绪化的批评对我们实在没有帮助。除此之外，我的观点可能有错，也
可能过份乐观，也欢迎大家能就技术方面给予我指教。

二、 I18N 与 locale:

要将 Linux 中文化，朝著标准走才是长远之计。各位如果有见过近代商业版的 UNIX
就会晓得，它们「中文化」之彻底，令人惊叹，诸如中文选单、中文讯息 .... 您能想
像得到，或说只能在 Win95/98/NT OS/2 .... 等上头才见得到的 中文环境，它们都
有。然而，它们的中文并不是像目前 Linux 上常见到的那样，由一堆程式七拼八凑出
来的，它们全部都是遵循一个标准: I18N 。

I18N 是 InternationalizatioN (国际化) 的缩写，第一个字 I 与最後一个字 N 之间
有 18 的字母，故名。 I18N 并不是只有表面上将 X Window 「国际化」而已，它是□
基在最底层的 libc 上。 libc 必须要有 locale 的支援，才能向 I18N 起步。

什麽是 locale? 简单说就是一组「地区语言」的资讯。它包括了 (详见 man
setlocale):


LC_CTYPE: 字元定义
LC_MESSAGES: 讯息显示
LC_TIME: 时间显示格式
LC_NUMERIC: 数字显示格式
LC_MONETARY: 货币显示格式
LC_COLLATE: 字母顺序与字串比较
其中，与一般使用者最有关系的，是 LC_CTYPE 与 LC_MESSAGES 。 LC_CTYPE 直接关
系到某些字元或内码在目前的 locale 下是否可印? 要如何转换? 对应到那一个字?
.... 等等。 LC_MESSAGES 则关系到软体的讯息输出是什麽样的语文。真正完整的
locale 支援，是当我们在 shell prompt 下，直接设好环境变数，则我们马上就能切
换到那个语文了。例如:

bash: export LC_CTYPE=zh_TW.Big5

有了 locale 的「协定」，使得任何地区的语文，只要在加入适当的 locale data 之
後， libc 就能正确地处理它了，而我们的「中文」当然也不例外。由於前人与 CLE
group 的努力，目前我们已有自己的 locale data 了。有安装 CLE 的朋友可以到
/usr/share/locale 下看看， zh_TW.Big5 就是我们的 locale data, 虽然还不够完
整，但已能 work。

目前 Linux 对於 locale 的支援如何? 可以大概地说，西方语系差不多没问题了，但
东方语系还有不少问题。如果您的 Linux 系统是用 libc5 (例如 Slackware) 的话，
那差不多可以说支援得相当差，几乎只能靠「七拼八凑」的方法来有限度地使用中文。
如果是用 libc6 (glibc2) 的话，那就有相当的 locale 支援了。

然而，目前大部分使用 glibc2 的系统都是 glibc-2.0.7, 这一版对东方语系的支援还
不够好，特别是 LC_CTYPE ，它无法辨认、转换我们的 Big5 码，必须要等到
glibc-2.1 以後，才能完全解决这些问题。但这并不是说使用 glibc-2.0.7 的广大使
用者都没希望了，事实上有一个 libwcsmbs 的套件，它可以将 glibc 中有问题的部分
取代掉，让我们的 LC_CTYPE 部分可以「几乎 90% 正确」地工作。而这个套件就是目
前 CLE 的标准之一，也是很重要的一个部分，虽然大家可能感受不到它的存在。

最近 glibc-2.1 的 pre-release 已经出来，我个人已做过初步测试， LC_CTYPE 在我
们的 locale 下已经正常，虽然仍有其他问题存在，但这已是一个好消息，我预计在未
来的一年内，等大部分的 Linux distribution 都换装了 glibc-2.1 之後，我们就有
了最底层的「中文化」条件。

三、 X Window 的部分:

接著我们来看看上层， X Window 的「中文化」 (或「国际化」)。 X11R6 也有一个
locale 的目录，放在 /usr/X11R6/lib/X11/locale □头，如果是装 CLE 的朋友，就
会见到一个 zh_TW.Big5 的目录，那就是我们的 XLC Locale data。在「标准」的情况
下， XLC Locale 必须架构在 libc locale 之上运作，它□头除了定义一些字元对
应，最重要的是内码与字型的对应。以我们的 locale 为例，我们需要两种字型，一是
「半形 (单位元)」，显示 ASCII 码用，另一是「全形 (双位元)」用来显示中文。举
一个例子，像以下这一串字:

这是一个 abcd .... 测试字串 string! ＯＫ！

那些要用全形显示? 那些要用半形显示? 这必须靠 libc 的 LC_CTYPE 来判断。因此，
LC_CTYPE 如果挂掉，可以说什麽都没辄。

我相信，有了上述的「配备」後，基本的 I18N 环境就已经具备了。但一定有人会问:
「看起来 CLE 在上述所说的都没问题，为什麽还是到处都不是中文?」 没错，那是因
为目前 Linux 上大部分的程式还不是用 I18N 的标准而写的。例如大家常用的
Netscape, xcin, crxvt .... 等等，它们都是用「自己」的招术来处理中文，这也就
是为什麽 xcin 只能在 crxvt 上输入，为什麽我们要靠 CXWin 来看中文 .... 等等。
这些都不是正解，只是暂时的一个手段，最後都是要放弃的。

目前，有越来越多程式将朝向 I18N 来发展，而我们目前最需要的工作，就是弄 I18N
的 zh_TW.Big5 部分。举个例子，目前 CLE group 正忙於 GNOME 的中文化，它算是目
前 I18N 化相当彻底的一个 X Disktop / Window Manager, Platin 预计在下一版的
CLE 就是以 GNOME 为主，只要将其中的讯息都翻译成中文，做好 LC_MESSAGES 的工
作，未来在 GNOME 中，将不需要依靠 CXWin, 打开後就到处都是中文。

其他的 GNU 软体也是，有另一组人马正将一些常见指令如 ls, cp 等的讯息中文化，
并将结果回报给 GNU, 期望未来新版的 GNU 软体中，中文讯息就是标准的一部分，我
们不再需要每次人家更新版就急急忙忙地做 patch 了。

中文输入就比较复杂，除了上述的 I18N 以外，还有一个 XIM (X Input Method) 协
定。我们必须要有 XIM server 来取代目前的 xcin, 而且还要 X Window 的应用程式
能够遵循 XIM 协定，才能做到 "Chinese Input Anywhere"。目