本地化似乎衹能是一件少數人在昏暗的電腦桌前從事的嗜好。 直到出現了同時支援多種語言的自由軟體，終於為這份隱晦的工作帶來了一線曙光。辛苦的成果不再需要藏在自己的硬碟裡，可以大方地拿出來展示。衹要採用了合乎自由軟體精神的授權 方式，也不需要耽心自己的心血是否會被商業公司霸佔。甚至能夠藉由商業行為的推廣與散佈，在既有的基礎上不斷加以改進，讓更多人能夠一齊分享。 在國外唸書時體驗過 HPUX,SUNOS,NEXT 這些 Unix 類的作業系統，才發現在 Linux 上具有管理者身分的感覺實在太棒了。當時在國外是流行 SUSE Linux ，起初衹有零星地編輯一些輸入法 對照表，或是舊式的訊息翻譯檔給自己使用。還記得開始學習編譯程式的動機，就是為了要修改軟體中的英文訊息。 回國後主要使用 Fedora Linux ，曾經有一段很長的時間參加 TOSSUG 社群聚會。等到加入了 GNU Translation Project 翻譯計畫 ( 簡稱 TP) 之後，才開始有系統地翻譯各類軟體訊息。後來從鄭 原真 (ycheng) 手中接下了 TP zh_TW 小組協調人的工作，但是慚愧衹能在原有的基礎上勉力維持，直到最近才移交給新任的曾政嘉 (zerng07) ，相信他能夠帶來一番新氣象。 大多數的常用軟體都歸屬於某個軟體開發組織，也許是某個發行版或是某種桌面環境，它們都有各自的翻譯管理機制，通常需要先加入特定的郵遞論壇或是登錄網站，而提交翻譯檔的方式 也各有不同。譬如 TP 的特色就是加入時希望你簽署棄權書，但是提交時衹要通過機器人審查即可。 建議有興趣的人，先在一般性的郵遞論壇詢問一下，像是 zh-l10n,chinese-l10n ，或是直接聯絡翻譯計畫的語言小組協調人，像是 GNOME 的廖昭雄 (pesder) 、 KDE 的翁佳驥 (franklin) 或是 MATE 的黃柏諺 (osiris) 。 另外很多小眾軟體都由程式開發者自行維護翻譯檔，而翻譯者也必須自行測試該軟體是否完整支援本地化，以及使用什麼樣的翻譯檔格式。有的是直接寄到作者信箱，有的是寄到專屬的郵 遞論壇，也有可能是透過 github 來提交。 近來出現一個中立的協同翻譯網路服務 transifex ，它不隸屬於任何軟體開發組織，但提供多組織、多專案、多語言、多檔案格式、多存取方式的管理介面，獲得了許多獨立軟體的採用，甚 至連某些大型軟體開發計畫都移到了 transifex ，讓它代為管理翻譯的部分。 至於參與翻譯計畫需要的知識與技能，制式的回答是必須具備英語、漢語、專業三方面的知識，技能則是必須熟悉想要翻譯的軟體，但是達到這種標準的人恐怕不會來做這件事。以我個人 的觀點來說，必須要具備的衹有熱情，以及使用文書編輯器打字的技能而已。從前曾經有人呼籲，不要去翻譯不熟悉的軟體，其實根本不用理會它，儘管去做就是了。看不下去的人就請自 己出來收拾善後吧。 在商用的作業系統中，廠商是用「多國語言支援」來描述可以讓不同語言、不同地區的使用者都能方便地依照本地的習慣來操作系統的功能。而在自由軟體中，根據任務性質的不同，我們 將它區分為著重於系統架構與軟體相容的國際化工作 ( 英文是 internationalization 簡稱 i18n) ，以及著重於軟體訊息翻譯的本地化工作 ( 英文是 localization 簡稱 L10n) 。 自由軟體作業系統的多國語言支援是基於 GLIBC 中的「語區 (locale) 」概念，如同等一下將會提到的，「語系」是一種語言分類的層級，不適合再拿來使用。 而 locale 主要是由語言與地區 的設定所組成，因此我偏好使用「語區」這個譯詞。 目前最廣為使用的本地化方案則是透過 gettext 函式庫。原始程式碼衹需依照程式語言介面呼叫這個函式庫，並使用特定指令將訊息包裝起來。利用隨附的工具產生訊息範本檔之後，各語區 的翻譯者衹要依照範本格式與內容，翻譯出對應的訊息檔，再提交給原作者就好。而使用者衹需稍微了解相關工具程式的用法，以及放置檔案的適當目錄，就可以自行加入翻譯訊息檔，而 不需要去修改或重新編譯原始程式。 雖然必須先完成基礎的國際化工作之後，才能開始本地化工作，但是同時也必須依賴本地化工作來吸引更多不同語言、地區的使用者，才有機會提出更多需求以刺激國際化工作的完善。這 樣的相互影響，在我的參與經驗中也得到了驗證。在翻譯的過程中，我發覺到用來指稱我們目前所用語言的「繁體中文」，並不是一個適當的代表名詞，衹是一個從當年倚天中文系統所遺 留下來的習慣稱呼。 首先，「某某文」通常指的是以符號將「某某語」表現出來的形式，它衹能代表一種符號化的結果，而不足以代表語言本身。再者，「中文」並不是一個嚴謹的學術名詞，而是有點像是 「美語」 ( 或是誇張一點的類比：美文 ) 這樣的說法，其中攙雜了政治區域的因素，衹適合在日常口語中使用。 當我們檢視所用語言的分類時，會發現它是屬於漢藏語系、漢語族的一員。以往漢語被認為是單一語言，因此早期在制訂 iso639 語言代碼標準時也採用了這個觀點，而將漢語編為單一的代 碼，並使用了不適當的 zh( 表示中文 ) 來做為語言縮寫。 繁體 / 簡體的稱呼也不是一個適當的分類方式，首先「體」這個概念是由書法而來，現代則衍生為描述一種字形外觀的設計，和漢字本身筆畫的多寡與結構並無太大關係。而使用繁 / 簡來形 容兩者之間的差異也過於粗淺，無法確切地顯示出兩者的不同。至於「正體」則是更糟的說法，不僅帶有過多的主觀意識，而且如果真的以客觀的使用者人數來比較，反而會得到不同的結 論。 英文是以 traditional chinese 與 simplified chinese 來區分，我們當然不必全盤接受外文的說法，但是有時參考局外人的觀點反而能更清楚地表達自已熟悉的概念。因此我目前偏好「傳統字漢 語」與「簡化字漢語」而非單純地直譯為「傳統漢語」與「簡化漢語」。 至於本地化工作未來的發展，在基礎的部分需要重新檢視漢語語區的設定，因為在以往資訊流通速度緩慢的時代，方言還能靠著地理上的分隔，在特定族群之中被保存下來。但是隨著網路 世界的興起，少數主要語言在新環境中迅速取得了極大的優勢，而多數次要語言在網路世界中則完全被忽視。對於漢語中次要的方言來說，即使以其中之一為母語的使用者人數，都超過世 界上大多數其他語言，卻同樣面臨著數位滅絕的危險，而自由軟體也許是延續它們存在的惟一機會。 在翻譯的工具方面，更好的機器翻譯，一直是許多關心翻譯進度的人所尋求的解決方案。它的目的並不在於完全取代翻譯者，而是希望能夠扮演前置處理的角色。藉由與字典檔案的比對， 儘量減輕翻譯者必須熟記所有字彙的壓力，轉而將注意力集中於文法的正確與敘述的通順，同時加快翻譯的速度並維持用詞的一致。 當然最重要還是需要有人參與，我們無法要求每位軟體作者都是自然語言的天才，能夠提供軟體的所有語言版本。因此對於以非英語為母語的電腦使用者而言，這也是一件無法假手他人的 任務。如果看得懂英文介面的我們不去做這件事，那麼還有誰可以幫助看不懂英文介面的本地語言使用者呢？ 無投影片講稿 無投影片講稿
bluebat
mongodb
akmur
jnunemaker
tmm1
revolveconf
ddemaree
sonatard
aki_iinuma
shlominoach
lynnandtonic
chrislema
bcantrill
![趙惟倫 <[email protected]> 2015 年 10 月 22 日 漢語語區本地化之路 漢語語區本地化之路](https://files.speakerdeck.com/presentations/e76e1c4fdd5a423bb5ac99a04802ae0c/slide_0.jpg){kind=link}
