底下這篇文章是我最近寫程式的一點點心得，原文已發表於 CLDP 上，包括了 GNU/Linux I18N 的環境簡介與相關的程式寫作簡介。但在此我只摘錄了有 關 GNU/Linux I18N 環境簡介的部分，至於程式寫作部分另有 專文介紹。 希望這篇文章對有興趣的朋友有幫助，能讓大家能早日進入 I18N 的世界 :-))
由於我所知很有限，所以文章中可能有很多錯誤， 因此，希望各位高手能多多給我批評與建議， 或幫忙我將不足之處補齊，讓這篇文章更完美。
在此先謝謝各位。
謝東翰 (Tung-Han Hsieh) <thhsieh@twcpro.phys.ntu.edu.tw>
最近這個話題大家吵得有點厲害，大家都希望 GNU/Linux 能在中文方面有所進 步，各家有各家的說法，莫衷一是。由於我最近常與 CLE 的 group 有聯繫， 同時也正在寫一些與中文相關的程式，因此我大略說一下「我們正在做什麼」， 讓大家參考。
我希望大家能將這篇文章當做技術性文章來讀，不要再有情緒化的批評，畢境 我們要的是 solution, 情緒化的批評對我們實在沒有幫助。除此之外，我的觀 點可能有錯，也可能過份樂觀，也歡迎大家能就技術方面給予我指教。
二、 I18N 與 locale:
要將 GNU/Linux 中文化，朝著標準走才是長遠之計。各位如果有見過近代商業版的 UNIX 就會曉得，它們「中文化」之徹底，令人驚嘆，諸如中文選單、中文訊息 .... 您能想像得到，或說只能在 Win95/98/NT OS/2 .... 等上頭才見得到的 中文環境，它們都有。然而，它們的中文並不是像目前 GNU/Linux 上常見到的那樣， 由一堆程式七拼八湊出來的，它們全部都是遵循一個標準: I18N 。
I18N 是 InternationalizatioN (國際化) 的縮寫，第一個字 I 與最後一個字 N 之間有 18 的字母，故名。 I18N 並不是只有表面上將 X Window 「國際化」 而已，它是奠基在最底層的 libc 上。 libc 必須要有 locale 的支援，才能向 I18N 起步。
什麼是 locale? 簡單說就是一組「地區語言」的資訊。它包括了 (詳見 man setlocale):
其中，與一般使用者最有關係的，是 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。
目前 GNU/Linux 對於 locale 的支援如何? 可以大概地說，西方語系差不多沒問題了， 但東方語系還有不少問題。如果您的 GNU/Linux 系統是用 libc5 (例如 Slackware 7.0.0 以前的版本) 的話，那差不多可以說支援得相當差，幾乎只能靠「七拼八湊」的方 法來有限度地使用中文。如果是用 libc6 (glibc2) 的話，那就有相當的 locale 支援了。
然而，目仍有很多使用 glibc2 的系統都是 glibc-2.0.7, 這一版對東方語系的支 援還不夠好，特別是 LC_CTYPE ，它無法辨認、轉換我們的 Big5 碼，必須要等到 glibc-2.1 以後，才能完全解決這些問題。但這並不是說使用 glibc-2.0.7 的廣 大使用者都沒希望了，事實上有一個 libwcsmbs 的套件，它可以將 glibc 中有問 題的部分取代掉，讓我們的 LC_CTYPE 部分可以「幾乎 90% 正確」地工作。而這個 套件就是 CLE-0.7 的標準之一 (作者按: CLE-0.7 因為仍使用 glibc-2.0.7, 故 必須使用 libwcsmbs 套件。但目前的 CLE-0.8 已採用 glibc-2.1.1, 故不再需要 這個套件了) ，也是很重要的一個部分，雖然大家可能感受不到它的存在。
最近 glibc-2.1.1 已經出來，我個人已做過初步測試， LC_CTYPE 在我們的 locale 下已經正常，雖然仍有其他問題存在，但這已是一個好消息，我 預計在未來的一年內，等大部分的 GNU/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 在上述所說的都沒問題，為什麼還是到處都不是中文?」 沒錯， 那是因為目前 GNU/Linux 上大部分的程式還不是用 I18N 的標準而寫的。例如大家常用 的 Netscape, xcin-2.3, crxvt .... 等等，它們都是用「自己」的招術來處理中文， 這也就是為什麼 xcin-2.3 只能在 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 (xcin-2.3.X), 而且還要 X Window 的應用程式能夠遵循 XIM 協定，才能做到 "Chinese Input Anywhere"。 但麻煩的是遵循 XIM 協定的應用程式仍不多，最著名的就是 GNOME 下的應用程式, xemacs, 以及一些 X11R6 所附的軟體 (如 xedit, 由 Xt 及 Xaw 提供 I18N 支援)。 而目前 XCIN 發展計畫 (http://xcin.linux.org.tw) 所發展中的 xcin-2.5 (ftp://xcin.linux.org.tw/pub/xcin/xcin/xcin-2.5.X.tar.gz) 就是一個 XIM server, 我希望這個軟體能在將來與 「各路人馬」配合，做出一點貢獻。
(作者按: 目前 xcin-2.5.1 已經正式發表了， 它已是滿完整的 XIM server 。而且先前提到的那些缺乏 I18N 與 XIM 支援的常 用軟體，現在都已有支援了，例如 rxvt-2.6, netscape-4.5/6, .... 等，而這些 有支援 I18N 與 XIM 的軟體，包括 GNOME, 也已測試過可以經由 xcin-2.5 正確地輸 入中文了)
因此，「中文化」的工作，並不是那麼簡單地說「因為 GNU/Linux 是免費、沒有人付 錢給程式設計師，所以做不好」，或者說「我們中國人不團結，大家不肯合作發 展程式」，或者說「 GNU/Linux 是 server 導向，不適合做中文」 .... 等等。 GNU/Linux 可以發展中文，而且有很多人正努力地在工作，但是更重要的是，我們還得配合國 外 (或說軟體的原設計者) 的腳步。前面說過，我們要有完整 locale 支援的 libc, 這一切才有希望，我們也需要我們常用的軟體 (如 Netscape, window manager, 甚至 database, office ....) 的設計者覺悟到，真正的標準是 I18N, 是 locale, 是 XIM, 我們才能跟進，將中文化的部分加進去。更重要的一點，我們自己的程式 設計師在寫軟體時，是不是也能遵循 I18N, locale, XIM??
中文化，需要一個標準，而我們希望這個標準，是世界通用的，而不是我們自己七 拼八湊出來的。否則的話，我們永遠都要自己玩自己的，永遠都會事倍功半，永遠 會抱怨「為什麼 GNU/Linux 的中文支援比不上 Win95?」
四、中文列印:
中文列印與上述的關係較小，但也是大家關心的問題之一，在此我也稍作一些說明。
在 UNIX 的世界，就我所知印表機輸出最常見的就是兩個: ASCII 碼與 Postscript, 而 Postscript 就是「圖形列印」的共通語言。因此，當我們要做中文列印，就是要 尋求「圖形列印」的途徑，也就是找一個「能將中文字檔轉成 Postscript 輸出」的 程式」。目前大家常見的，如傳統的 cnprint、 CLE 中能直接使用 TTF 字型的 bg5ps, 或是 ChiTeX, CJK+LaTeX, lyx .... 等等。
在此稍微值得一提的是，架構在 LaTeX 系統上以支援中文排版列印的 CJK 套件 似乎已漸漸成為 Free Software / Open Source 所公 認的標準之一，其原因如下:
我想這一點很值得成為我們未來發展中文列印的一個參考。
作者: 謝東翰 (Tung-Han Hsieh)