GNU/Linux 的 I18N 環境的發展，到了glibc-2.2 系列正式問世后，才算完全成熟。它不僅完全支持 Unicode 環境，同時在 I18N 與 L10N 方面還擁有許多先進的特色述如下:
◆1. glibc 內部的編碼轉換系統 (iconv) 擁有共同的「基底字集」，該基底字集采用 UCS4 編碼，目前仍持續擴編當中，理論上將可以函蓋世界上所有已知的編碼系統的轉換對應。透過基底字集，可以達到完善的轉碼機制。同時，由于在各語系下其多字節編碼轉成寬字符時，其實就是轉成 UCS4，這在將來 Unicode通行時，將有利于數據的處理。

◆2. glibc 內部擁有數量龐大的編碼轉換表，大部分是各編碼系統與 UCS4 的轉換用，也有一些是用于不同編碼間直接轉換。所有的轉換表皆采動態模塊加載的方式供應用程序使用，故只有在需要時系統才會自動加載所需的轉換表來執行，使用完畢后可以卸下，不會浪費內存空間。

◆3. glibc 擁有完整的 I18N 過程調用接口，以及完整的 Unicode 輸出入與處理的呼叫接口。

◆4. 在地區環境方面，glibc 將「字集」與「編碼」的概念分開。一個地區環境資料庫有一個明確的字集，代表這個地區語文可能會使用到的所有文字符號，而這個字集可以自由選擇一個編碼系統來套用。例如我們臺灣地區的字集包含所有的中文字 (簡繁體都有)，如果我們選用 Big5 編碼，則地區環境數據庫名稱就是 zh_TW.Big5；若我們選用 EUC-TW 編碼，則名稱就是 zh_TW.euctw；當然我們甚至可以選用 GB2312 或 Unicode 等編碼來套用。

然而，由于各編碼所能包含的字數是固定的，同時它們也只能包含特定的字集，因此，僅管我們的中文字集包含了所有的中文字，但一旦選定編碼系統后，其所能使用的中文字自然僅限于該編碼系統所包含的范圍。因此，假如我們選用Big5，就表示在此環境下無法使用簡體字；反之若選用GB2312 亦然。

◆5. glibc 中各地區環境預設的編碼系統與傳統的 UNIX 系統稍有不同。所謂的「預設編碼系統」指的是在 "_" 這樣的地區環境數據庫名稱中，所采用的編碼系統。傳統的 UNIX 系統中所采用的預設編碼系統多半是依照官方或業界的標準，例如在臺灣地區就是 EUC-TW。而在 glibc 中，則是以當地最廣泛流通的編碼系統做為預設。

更進一步地，glibc 會自動將未登錄的編碼系統名稱，改以其地區環境的預設編碼系統來取代。例如我們將語系環境設定為 zh_TW.euctw，由于 "euctw"在 glibc 內部已有登錄，故它就會采用 EUC-TW 做為此環境下的編碼系統。萬一我們將語系環境設定為 zh_TW.unknown，由于 "unknown" 一字沒有登錄，故glibc 會自動以 zh_TW 預設的編碼系統 Big5 來取代。

◆6. 在訊息顯示方面，各應用程序的訊息翻譯只需依各語文地區分別保留一份即可，不需要分別為不同的編碼系統都保留一份。以臺灣地區中文為例，我們只需要一份 zh_TW 的訊息即可，至于它是用 Big5 寫成的，或 EUC-TW 寫成的都沒關系。假如它原來是以 Big5 寫成的，但我們卻希望以 EUC-TW 來顯示時，glibc會自動為我們做好轉碼的工作。

也許有人會問，那我們只需要保留一份 zh (即中文) 的訊息就好了嘛，這樣豈不是兩岸三地都可使用了？然而這么做并不恰當，原因是兩岸三地因歷史背景與文化的隔閡，各自發展成獨特的語文，或稱「地區性方言」，對同一個句子的翻譯，可能兩岸三地的翻法都各自不同。故我們不能單純用轉碼的方式，直接將臺灣地區的翻譯轉成簡體字供對岸使用，而必須為他們分別保留一份他們自己的訊息翻譯。

◆7. 在訊息翻譯的維護工作，以及系統函式的呼叫接口上，各 UNIX 系統的實作方式都不盡相同。而在 glibc (或所有的 GNU 系統、程序) 中，則統一使用 GNUgettext，以方便程序撰寫以及后續的翻譯維護。

◆8. 在地區環境數據庫中，除了上述那幾個傳統的類別之外，新一代的 glibc-2.2還擴增了以下的類別:

LC_PAPER,
LC_NAME,
LC_ADDRESS,
LC_TELEPHONE,
LC_MEASUREMENT,
LC_IDENTIFICATION

這些是根據 ISO/IEC JTC1/SC22/WG20 N690 (1999/06) 的新規范而來，用以描述更多的地區性慣例，如住址格式、電話號碼格式、抬頭稱位 .... 等等。