FOSS 本地化/附錄 A:關鍵概念
前言 — 致謝 — 引言 — 亞太地區本地化工作 — 建議 — 附錄 A:關鍵概念 — 附錄 B:技術方面 — 進一步閱讀 — 資源和工具 — 詞彙表 — 關於作者 — 關於 APDIP — 關於 IOSN
本附錄簡要介紹了本地化的關鍵概念,以便那些有興趣將其語言的 FOSS 本地化的人,能夠對所需知識有一個廣泛的瞭解。下一個附錄提供了開始所需的技術細節。
當兩個或多個實體互動時,共同約定至關重要。汽車駕駛員必須遵守交通規則以防止事故。人們需要關於語言和手勢的共同約定來進行交流。同樣,軟體需要標準和協議才能無縫地互操作。在軟體工程方面,在實現之前需要建立程式各個部分之間的契約。對於由來自不同背景的眾多獨立開發人員開發的系統,這些契約最為重要,對於跨平臺互操作性也至關重要。
標準為全世界所有計算系統提供了這樣的契約。軟體開發人員需要遵守這些約定以防止誤解。因此,標準化應該是任何軟體開發的第一個步驟,包括本地化。
為了開始本地化,研究相關標準並將其貫穿整個專案是一個好主意。如今,已經開發了許多國際標準和規範來涵蓋世界各地的語言。如果這些不符合專案的需要,可以考慮參與標準化活動。
- ISO/IEC JTC1(國際標準化組織和國際電工委員會聯合技術委員會 1)
- 一個關於資訊科技國際標準的聯合技術委員會。該委員會下設許多關於不同類別的分委員會(SC),這些分委員會又組成了工作組(WG)來處理標準的子類別。例如,ISO/IEC JTC1/SC2/WG2 是通用編碼字元集(UCS)的工作組。但是,標準化過程以封閉的方式進行。如果國家標準機構是 ISO/IEC 成員,則可以提出專案的相關要求。否則,可能需要聯絡各個委員會。他們可能會要求以專家身份參與。JTC1/SC2(編碼字元集)的資訊在 http://anubis.dkuug.dk/JTC1/SC22 釋出。有關 JTC1/SC22(程式語言、其環境和系統軟體介面)的資訊可以在 http://anubis.dkuug.dk/JTC1/SC22 找到。
- Unicode 聯盟:
- 一個致力於通用字元集的非營利組織。它與 ISO/IEC JTC1 分委員會密切相關。其網站位於 http://www.unicode.org,並提供貢獻渠道。
- 自由標準組織
- 一個致力於透過開發和推廣標準來加速 FOSS 使用的非營利組織。其網站位於 http://www.freestandards.org。它對參與開放。在它的保護傘下,有許多工作組,包括用於國際化(http://www.openi18n.org)的 OpenI18N。
但是,請注意,國家鍵盤對映和輸入/輸出方法等問題並不在上述標準中涵蓋。國家標準機構應該定義這些標準,或統一不同供應商使用的現有解決方案,以便使用者能夠從一致性中受益。
字元是表示任何特定語言文字資料的最基本單位。在數學術語中,字元集定義了語言中使用的所有字元的集合。在資訊科技術語中,字元集必須根據某些約定(稱為編碼)在儲存中以位元組的形式編碼。這些約定必須由資料傳送者和接收者共同同意,以便資訊保持完整和準確。
在 1970 年代,大多數程式使用的字元集由英語字母、十進位制數字和一些標點符號組成。最廣泛使用的編碼是 7 位ASCII(美國資訊交換標準程式碼),其中最多可以表示 128 個字元,這足以滿足英語的需要。但是,當需要在計算機中使用非英語語言時,定義了其他編碼。內碼表的概念被設計為對ASCII的增強,透過新增字元作為第二個 7 位半,總共形成一個 8 位程式碼表。供應商為裝飾目的和拉丁語重音符號定義了幾個內碼表。一些非歐洲語言透過這種策略新增,例如希伯來語和泰語。國家標準為字元編碼定義了標準。
傳統的編碼系統不適合具有大型字元集和特殊複雜性的亞洲語言。例如,漢語、日語和韓語(CJK)使用的漢字編碼,其總數尚未確定,其複雜程度要高得多。必須定義大量的內碼表才能涵蓋它們。此外,與其他單位元組編碼的相容性是另一個重大挑戰。這最終導致了一些用於 CJK 的多位元組編碼。
然而,擁有大量編碼標準需要支援對軟體開發人員來說是一個問題。因此,一群供應商同意共同努力,定義一個涵蓋世界上所有語言字元的單一字元集,以便開發人員有一個單一的參考點,使用者有一個單一的編碼。因此,Unicode 聯盟成立了。世界上的主要語言被新增到程式碼表中。後來,ISO 和 IEC 共同組成了 JTC1/SC2/WG2 來標準化程式碼表,該程式碼表以 ISO/IEC 10646 的形式釋出。Unicode 也是工作組的成員,與 ISO 成員國的標準機構一起。Unicode 和 ISO/IEC 10646 是同步的,因此程式碼表相同。但是,Unicode 還提供額外的實現指南,例如字元屬性、渲染、編輯、字串排序等。
如今,許多應用程式已遷移到Unicode,並從支援新語言的明確定義中受益。Unicode 使用者能夠以自己的語言交換資訊,特別是在網際網路上,沒有相容性問題。
一旦定義了指令碼的字元集和編碼,使其在系統上生效的第一步就是顯示它。在螢幕上渲染文字需要一些資源來描述字元的形狀,即字型,還需要一些過程來根據指令碼約定渲染字元影像。這個過程稱為輸出方法。本節將嘗試涵蓋這些要求的重要方面。
字型是指一套字元集的字形。字形是字元或字元序列的視覺形式。區分字元和字形概念非常重要。對於某些文字系統,一個字元可能有多個變體,具體取決於上下文。在這種情況下,字型可能包含每個字元的多個字形,以便文字渲染器可以動態選擇合適的字形。另一方面,諸如英文文字中的“ff”之類的連字概念也允許將某些字元序列繪製在一起。這引入了另一種將多個字元對映到單個字形的對映方式。
點陣圖字型和向量字型
[edit | edit source]原則上,描述字型中的字形有兩種方法:點陣圖和向量。點陣圖字型透過將畫素直接繪製到確定大小的二維網格上,來描述字形形狀,而向量字型則使用線和曲線繪製指令來描述字形輪廓。換句話說,點陣圖字型是為特定大小設計的,而向量字型是為所有大小設計的。從點陣圖字型渲染的字形的質量在放大時始終會下降,而從向量字型渲染的字形的質量則不會。然而,由於有限的畫素用於擬合曲線,因此向量字型在低解析度裝置(例如計算機螢幕)中以較小的尺寸渲染時往往效果不佳。在這種情況下,點陣圖字型可能更精確。
但是,字型技術已經解決了低解析度下的質量問題。例如
- 提示,儲存在字型中的額外指南資訊,供光柵化器以保留正確字形形狀的方式擬合曲線。
- 抗鋸齒,光柵化器的功能,使用一些人類感知的錯覺(例如使用灰度級和彩色子畫素)來模擬不匹配的畫素,從而產生“平滑曲線”的感覺。
這些可以提高小尺寸向量字型的質量。此外,現代桌上型電腦對點陣圖字型的需求正在逐漸減少。
字型格式
[edit | edit source]目前,X 視窗系統 for GNU/Linux 桌面支援多種字型格式。
BDF 字型
[edit | edit source]BDF(點陣圖分佈格式)是 X Consortium 的一種點陣圖字型格式,用於以既可讀又可機器讀的形式交換字型。它的內容實際上是純文字。
PCF 字型
[edit | edit source]PCF(可移植編譯格式)只是 BDF 格式的編譯形式。它是二進位制的,因此,只有機器可讀。將 BDF 編譯成 PCF 的實用程式是 bdftopcf。雖然 BDF 字型可以直接安裝到 X 視窗系統中,但它們通常被編譯以獲得更好的效能。
Type 1 字型
[edit | edit source]Type 1是由Adobe制定的向量字型標準,並得到其Postscript標準的支援。因此,它在大多數UNIX和GNU/Linux中得到了很好的支援,透過X 視窗系統和Ghostscript。因此,它是傳統UNIX列印的推薦格式。
TrueType 字型
[edit | edit source]TrueType是由蘋果開發的向量字型標準,也用於Microsoft Windows。隨著 Windows 的發展,它的普及程度也越來越高。XFree86在 FreeType 庫的幫助下也支援 TrueType 字型。Ghostscript也支援 TrueType。因此,它成為GNU/Linux桌面字型的一種潛在選擇。
OpenType 字型
[edit | edit source]最近,Adobe和Microsoft同意建立一種新的字型標準,該標準涵蓋 Type 1 和 TrueType 技術,並進行了一些增強以滿足世界各地不同文字系統的需求。結果是OpenType。
一個OpenType字型可以用Type 1或TrueType樣條線來描述字形輪廓。此外,還添加了用於將組合標記定位到基字元或其他標記的相對字形定位資訊(即 GPOS 表),以及一些字形替換規則(即 GSUB 表),使其足夠靈活,可以繪製各種語言的字元。
輸出方法
[edit | edit source]輸出方法是在輸出裝置上繪製文字的過程。它將文字字串轉換為給定字型的正確定位的字形序列。對於簡單的例子,如英語,字元到字形的對映可能是直觀的。但對於其他文字系統,輸出方法則更加複雜。有些可能是使用組合標記,有些以非從左到右的方向書寫,有些使用單個字元的字形變體,有些需要重新排序字元,等等。
使用傳統的字型技術,處理複雜文字系統的資訊不會儲存在字型中。因此,輸出方法承受著負擔。但對於OpenType字型,所有規則都儲存在其中,輸出方法只需要能夠讀取和應用這些規則。
輸出方法在不同的實現中定義。對於 X 視窗,它被稱為X 輸出方法 (XOM)。對於GTK+,它使用一個名為Pango的單獨模組。對於Qt,它透過一些類實現輸出方法。現代渲染引擎現在能夠使用OpenType字型。因此,在輸出方法實現中繪製文字有兩種方法。如果您使用的是TrueType或 Type 1 字型,並且您的文字系統在基於拉丁語的語言之上存在一些複雜性,您需要提供一種輸出方法,該方法知道如何處理和排版您的文字系統的字元。否則,您可以使用包含描述字形替換和定位規則的 OpenType 表的 OpenType 字型。
輸入方法的設計和實現涉及許多因素。字元集的大小和輸入裝置的功能差異越大,輸入方法就越複雜。例如,使用 104 鍵鍵盤輸入英文字元非常簡單(大多是一對一 - 也就是說,一個按鍵產生一個字元),而使用手機鍵盤輸入英文則需要更多步驟。對於字元集龐大的語言,例如中日韓,即使使用 PC 鍵盤,字元輸入也非常複雜。
因此,分析和設計是輸入方法建立的重要階段。第一步是列出輸入所需的全部字元(不是字形),包括數字和標點符號。下一步是決定是否可以將其與可用按鍵一一對應,還是需要一些組合(如歐洲重音符號)或轉換(如中日韓羅馬字輸入)機制,其中需要多個按鍵才能輸入某些字元。
當為文字決定了輸入方案後,就可以設計鍵盤佈局。好的鍵盤佈局應該透過將最常用的字元放在主行,其餘字元放在上行和下行來幫助使用者。如果文字沒有大小寫概念(非拉丁文字幾乎都是如此),則可以將罕見的字元放在 shift 位置。
然後,實現輸入方法需要兩個主要步驟。首先,建立一個鍵盤佈局對映。這通常是一個簡單的步驟,因為存在現有的鍵盤對映可供參考。然後,如果需要,第二步是根據鍵盤對映編寫輸入方法。一般來說,這意味著編寫一個輸入方法模組來插入系統框架。
區域設定是由國際化(I18N)的概念引入的,其中建立了通用框架,以便軟體可以調整其行為以滿足不同母語、文化規範和編碼字元集的要求,而無需修改或重新編譯。
在這些框架內,區域設定用於描述特定的文化。使用者可以配置他們的系統來選擇他們的區域設定。程式將載入相應的預定義區域設定定義來完成國際化功能。因此,要使國際化軟體支援新語言或文化,必須建立一個區域設定定義並填寫所需資訊,這樣就可以在不觸碰軟體程式碼的情況下完成操作。
根據POSIX,[1] 一些 C 庫函式,例如日期和時間格式、字串排序、數值和貨幣格式,都依賴於區域設定。ISO/IEC 14652 在 POSIX 區域設定規範中添加了更多功能,併為紙張尺寸、測量單位、地址和電話格式以及人名定義了新的類別。 GNU C 庫已經實現了所有這些類別。因此,可以透過它來描述文化規範。
區域設定定義在第 41-42 頁進行了詳細討論。
翻譯程式中的訊息,包括選單、對話方塊、按鈕標籤、錯誤訊息等,可以確保不熟悉英語的本地使用者可以使用該軟體。這項任務只有在輸入方法、輸出方法和字型完成後才能完成 - 否則翻譯後的訊息將變得毫無用處。
有許多訊息翻譯框架可用,但基本概念相同。訊息被提取到一個工作檔案中以供翻譯,並編譯成一個雜湊表。當程式執行時,它會根據區域設定載入相應的翻譯資料。然後,快速查詢訊息以進行翻譯,以便在使用者介面中使用。
翻譯是一項勞動密集型任務。翻譯大量的訊息需要時間,這就是為什麼它總是由一組人完成的原因。在組建團隊時,確保所有成員在程式的所有部分中使用一致的術語。因此,在論壇中透過密切討論合作以及從集體做出的決定中構建詞彙資料庫至關重要。有時,翻譯人員需要執行程式才能檢視訊息周圍的上下文,以便找到適當的翻譯。其他時候,翻譯人員需要調查原始碼以找到條件訊息,例如錯誤訊息。逐個字面翻譯每條訊息,不執行程式,往往會導致無法理解的輸出。
與其他 FOSS 開發活動一樣,翻譯也是一項長期承諾。每個新版本通常都會引入新的訊息。即使當前版本中的所有訊息都已完成,也需要在下一個版本釋出之前檢查新訊息。在版本釋出之前,通常會有一個字串凍結期,在此期間不允許在程式碼庫中新增新的字串,併為翻譯人員分配適當的時間段。訊息翻譯過程的技術方面在第 45 頁進行了討論。
在計劃在GNU/Linux桌面中啟用一種語言之前,需要清楚地瞭解其結構概述。GNU/Linux 桌面由相互疊加的子系統層組成。每一層都有自己的區域設定相關操作。因此,要完全啟用一種語言,就需要在所有層面上進行操作。這些層,從下往上,依次為(參見圖 1)

- C 庫
- C 是開發GNU/Linux應用程式的最低級別程式語言。其他語言依賴 C 庫來呼叫作業系統核心。
- X 視窗
- 在大多數UNIX系統中,圖形環境由X 視窗系統提供。這是一個客戶端-伺服器系統。X 伺服器是提供服務以控制硬體裝置(如顯示卡、顯示器、鍵盤、滑鼠或平板電腦)以及將使用者輸入事件從裝置傳遞到客戶端的代理。X 客戶端是 GUI 應用程式,它們請求 X 伺服器在螢幕上繪製圖形物件,並透過 X 伺服器提供的事件接受使用者輸入。請注意,使用這種架構,X 客戶端和伺服器可以在網路中的不同機器上。在這種情況下,X 伺服器是使用者操作的機器,而 X 客戶端可以在同一臺機器上執行,也可以在網路中的遠端機器上執行。
- 工具包
- 使用低階 Xlib 編寫程式既繁瑣,而且當所有應用程式都根據自己的偏好繪製選單和按鈕時,會導致 GUI 不一致。一些庫被開發為中間層,以幫助減少這兩個問題。在 X 術語中,這些庫被稱為工具包。它們提供的 GUI 元件,例如按鈕、文字輸入等,被稱為小部件。過去開發了許多歷史悠久的工具包,要麼由 X Consortium 本身開發,如 X Toolkit 和 Athena 小部件集(Xaw),要麼由供應商開發,如來自 Sun 的 XView、來自 Open Group 的 Motif 等。在 FOSS 領域,最廣泛採用的工具包是 GTK+ (The GIMP Toolkit)[2] 和 Qt.[3]
- 桌面環境
- 工具包幫助開發人員在一組程式中建立一致的外觀和感覺。但是要建立一個完整的桌面,應用程式需要更緊密地協同工作,以形成一個方便的工作場所。桌面環境的概念是為了提供應用程式之間的通用約定、資源共享和通訊而發明的。在 UNIX 平臺上建立的第一個桌面環境是 Open Group 的 CDE (Common Desktop Environment),它基於其 Motif 工具包。但它是專有的。GNU/Linux 的第一個 FOSS 桌面環境是KDE (K Desktop Environment),[4] 基於 TrollTech 的 Qt 工具包。然而,由於當時 Qt 的一些許可條件,一些開發人員不喜歡它。因此,建立了第二個,稱為 GNOME (GNU Network Object Modelling Environment),[5] 基於 GTK+。如今,儘管 Qt 的許可問題已得到解決,但 GNOME 仍在不斷發展,並獲得更多供應商和社群的支援。因此,KDE 和 GNOME 成為 GNU/Linux 和其他 FOSS 作業系統(如 FreeBSD)上使用最廣泛的桌面。
每個元件都是國際化的,允許對不同的區域設定進行本地實現
- GNU C 庫
- 根據 POSIX 和 ISO/IEC 14652 進行國際化。
- XFree86(以及一般的 X 視窗)
- 這一層面的國際化包括描述字型集和字元程式碼轉換的 X 本地化 (XLC); 用於文字輸入過程的 X 輸入法 (XIM),其中 X 鍵盤擴充套件 (XKB) 用於描述鍵盤對映; 以及用於文字渲染的 X 輸出法 (XOM)。 對於 XOM,它是在 GTK+ 和 Qt 已經透過各自的解決方案處理了渲染之後才實施的。 因此,XOM 是否仍然有必要值得懷疑。
- GTK+
- 對於 GTK+ 2,國際化框架已以模組化方式定義。 它有自己的輸入法框架,稱為 GTK+ IM,其中輸入法模組可以根據使用者命令動態插入。 GTK+ 2 中的文字渲染由一個單獨的通用文字佈局引擎處理,稱為 Pango。 Pango 可用於任何需要渲染多語言文字的應用程式,而不僅僅用於 GTK。
- Qt
- Qt 3 中的國際化以最小化方式完成。 它完全依賴於 XIM 進行所有文字輸入,並使用 QComplexText C++ 類處理文字渲染,該類完全依賴於來自 Unicode.org 的 Unicode 資料進行字元屬性。 對於桌面環境層,即 GNOME 和 KDE,除了 GTK+ 和 Qt 提供的之外,沒有額外的國際化。
- ↑ POSIX 是可移植作業系統規範的縮寫
- ↑ GTK+,‘GTK+ – The GIMP Toolkit’; 可從 http://www.gtk.org 獲取。
- ↑ 3 TrollTech,‘TrollTech – The Creator of Qt – The multi-platform C++ GUI/API’; 可從 http://www.trolltech.com 獲取。
- ↑ KDE,‘KDE Homepage – Conquer your Desktop!’; 可從 http://www.kde.org 獲取。
- ↑ GNOME,‘GNOME: The Free Software Desktop Project’; 可從 http://www.gnome.org 獲取。