那麼，要用甚麼方法才能讓系統支援上面的基本要求呢？
最直接的方式，是修改程式，讓每個程式都支援中文的使用。例如，很多人使用的中文 cpine 郵件程式就是由英文版 pine 改出來的，還有像讓整個 X 視窗都能顯示中文的 CXWin 程式，以及 cxterm 終端機程式等，都是由英文版的程式改來的。這些程式對中文的支援很好，也都受到了大家的歡迎愛用。然而，一旦離開了這些程式後就無法再用中文了。整個 GNU/Linux 少說有上千個程式套件，而且還在不斷增加當中。如果想要全面中文化，就必須一一對這些程式進行修改。更糟的是，一旦修改過的程式推出了新版，修改的工作就得再做一次，造成人力和資源的嚴重浪費。由此可見，這個方法進行中文化是一條行不通的道路。
第二種想法，是使用外掛式的中文環境。這種做法其實並不新奇，早在 DOS 時代的倚天中文或是英文版 Windows 下的雙橋中文便是這樣的系統。在 Linux 中只要利用 LD_PRELOAD 的機制，就可在程式執行時動態的將原本不支援中文的函式替換成支援中文的函式，結果就可以讓不支援中文的程式變得可以顯示中文跟接受中文輸入了。例如 CLE v0.8 使用的 xa+cv 或是 TurboLinux 裡面使用的 zhWinPro 都是屬於這類的程式。這種方式來提供中文的支援很簡單也很靈活，也不需要去修改程式的原始碼並重新編譯，可是這個方法卻沒辦法讓應用程式對中文作正確的「處理」，例如編輯文字時在中文字上面按一次刪除鍵卻還是只能刪除半個中文，這是因為在應用程式內部仍然是把一個中文字當成兩個英文字來看待，這顯然是不正確的。這個方式也不支援使用靜態連結函式庫的程式，還常常會造成系統的不穩定。因此大家已經理解到這個方式無法解決根本問題，漸漸地捨棄這種外掛的方式。
這樣說來，難道中文化的問題是個死胡同，永遠無解？難道不能讓程式設計師寫出來的程式原本就支援中文嗎？可是剛剛不是才說了，大多數的程式都是外國人寫的，他們不懂中文，如何讓寫出來的程式能夠「懂」中文呢？這個問題的答案，便是「國際化」。
國際化的英文名稱是 InternationalizatioN，因為在第一個字母 I 與最後一個字母 N 之間有 18 個字母，所以通常簡稱為 I18N。I18N 是一種觀念跟目標，這個想法是要提供一個架構，讓同樣的程式碼可以適用在各種語文習慣跟編碼系統上面，程式設計人員只要利用這個架構的機制跟準則撰寫程式，就可以在不需重新編譯程式的情況下，自然的支援各國的語言。
國際化架構設計的基本原則，是把程式中跟語言相關的部份獨立出來，例如編碼系統、數字、日期、排序、貨幣的格式，以及翻譯的訊息等等。這些跟語文環境有相關的資料，稱為「區域環境資料庫」(locale database)。把這些資料分離出來以後，就可以定義一個跟語文編碼無關的介面給程式設計師使用，在設計程式時不必考慮對特定語文提供支援的細節，而是在程式執行時才依使用者所選擇的區域環境(locale)聯繫到不同的資料庫，提供該語文的支援。
I18N 只是提供可能用來支援中文的大架構。要能夠使用中文，還必須要在這個架構裡面加入對中文語言的支援才可以。在國際化架構之下加入對某種特定語言支援的動作稱為「本地化」或「區域化」，英文稱為 LocalizatioN，因為 L 跟 N 之間有 10 個英文字母，也常簡稱為 L10N。一般的「中文化」是泛指為應用程式加上中文支援的過程。而在國際化的架構下指的中文化，就是在裡面加入中文區域化支援的工作。
在全球化的風潮下，許多自由軟體的開發者已逐漸體認到，要讓一種基礎程式碼適用於全世界，而英文不過是另一種語言罷了。因此國際化的工作正積極的展開，例如 Free Standards Group 在今年八月發表的 LI18NUX2000 Linux 作業系統全球化規格13，按照此規格開發的應用程式便可望能同步支援多國語言。我們認為，透過國際化架構進行中文區域化的支援，才是建構中文環境的正途，是一勞永逸解決中文化問題的根本辦法。
當前在 GNU/Linux 上提供中文支援的國際化架構可說是已經大致完備，底層程式庫的中文區域化工作也都大致完成了。在這個架構之上已經可以提供一個不錯的中文環境可以用。這都要感謝一些國際性程式開發組織有心重視亞洲語系使用者的需求，和長久以來許多自由軟體作者的默默貢獻。因為有這許多前人不計報酬的努力，我們才能享受當前的中文環境。