漢語語區本地化之路

bluebat
·
·
IPFS
·

2015-10-22 Hacking Thursday 誰來晚餐 講稿

我與軟體訊息翻譯的第一次接觸,要追溯到在 DOS 上使用中文系統的時期,利用當時熱門工具程式 PC-Tools 內附的十六進位編輯器,把軟體裡的英文訊息改為 Big5 編碼的中文訊息。那時網際網路還不普及,改出來的東西衹能自己欣賞。後來靠著 BBS 的興起,才開始有了所謂本地化版本的出現與流通。但是隨之而來的電腦病毒散佈以及違反使用授權問題,使得軟體訊息本地化這件事,似乎衹能是少數人孤獨從事的嗜好。

直到出現了同時支援多種語言的自由軟體,終於為這份隱晦的工作帶來了一線曙光。辛苦的成果不再需要藏在自己的硬碟裡,可以大方地拿出來展示。衹要採用了合乎自由軟體精神的授權方式,也不需要耽心自己的心血是否會被商業公司霸佔。甚至能夠藉由商業行為的推廣與散佈,在既有的基礎上不斷加以改進,讓更多人能夠一齊分享。

在國外唸書時體驗過 HPUX, SUNOS, NEXT 這些 Unix 類的作業系統,才發現在 GNU/Linux 系統上具有管理者身分的感覺實在太棒了。當時在國外是流行 SUSE Linux,起初衹有零星地編輯一些輸入法對照表,或是舊式的訊息翻譯檔給自己使用。還記得開始學習編譯程式的動機,就是為了要修改 C/C++ 軟體中內嵌的英文訊息,好讓程式執行時能夠看到成果。

回國後主要使用 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 函式庫。原始程式碼衹需依照各自程式語言介面呼叫它,並使用特定指令將訊息包裝起來。利用隨附的工具產生訊息範本檔之後,各語區的翻譯者衹要依照範本格式與內容,翻譯出對應的訊息檔,再提交給原作者就算完成工作。而使用者衹需稍微了解相關工具程式的用法,以及放置檔案的適當目錄,就可以自行加入翻譯訊息檔,而不需要去修改或重新編譯原始程式。

雖然必須先完成基礎的國際化工作之後,才能開始本地化工作,但是同時也必須依賴本地化工作來吸引更多不同語言、地區的使用者,才有機會提出更多需求以刺激國際化工作的完善。這樣的相互影響,在我的參與經驗中也屢見不鮮。隨著翻譯數量的累積,我體認到用來指稱我們目前所用語言的「繁體中文」,並不是適當的代表名詞,而衹是一個從當年 DOS 環境下的倚天中文系統,所遺留下來的習慣稱呼。

首先,「某某文」通常指的是以符號將「某某語」表現出來的形式,它僅能代表一種符號化的結果,而不足以代表語言本身。再者,「中文」並不是一個嚴謹的學術名詞,而是有點像「美語」(或是誇張一點的類比:美文)這樣的說法,其中攙雜了政治區域的因素,衹適合在日常口語中使用。

當我們檢視所用語言的分類時,會發現它是屬於漢藏語系-漢語族的一員。以往漢語被認為是單一語言,因此早期在制訂 ISO639 語言代碼標準時也採用了這個觀點,將漢語編為單一的代碼,並使用了不適當的 zh(表示中文)來做為語言縮寫。

繁體/簡體的稱呼也不是一個適當的分類方式,首先「體」這個概念是由書法而來,現代則衍生為描述一種字形外觀的設計,和漢字本身筆畫的多寡與結構並無太大關係。而使用繁/簡來形容兩者之間的差異也過於粗淺,無法確切地顯示出兩者的不同。至於「正體」則是更糟的說法,不僅帶有過多的主觀意識,而且如果真的以客觀的使用者人數來比較,反而會得到不同的結論。

英文是以 Traditional Chinese 與 Simplified Chinese 來區分,我們當然不必全盤接受外文的說法,但是有時參考局外人的觀點反而能更清楚地表達自已熟悉的概念。因此我目前偏好「傳統字漢語」與「簡化字漢語」,而非單純地直譯為「傳統漢語」與「簡化漢語」。

至於本地化工作未來的發展,在基礎的部分需要重新檢視漢語語區的設定,因為在以往資訊流通速度緩慢的時代,方言還能靠著地理上的分隔,在特定族群之中被保存下來。但是隨著網路世界的興起,少數主要語言在新環境中迅速取得了極大的優勢,而多數次要語言在網路世界中則完全被忽視。對於漢語中非官方的方言來說,即使以其中之一為母語的使用者人數,都超過世界上大多數其他語言,卻依然面臨著數位滅絕的危險,而自由軟體也許是延續它們存在的惟一機會。

在人工智能的翻譯工具尚未取代翻譯者之前,更好的機器翻譯,一直是許多關心翻譯進度的人所尋求的解決方案。它的目的並不在於完全取代翻譯者,而是希望能夠扮演前置處理的角色。藉由與字典檔案的比對,儘量減輕翻譯者必須熟記所有字彙的壓力,轉而將注意力集中於文法的正確與敘述的通順,同時加快翻譯的速度並維持用詞的一致。

當然最要緊的還是需要有人參與,我們無法要求每位軟體作者都是自然語言的天才,能夠提供軟體的所有語言版本。因此對於以非英語為母語的電腦使用者而言,這也是一件無法假手他人的任務。如果看得懂英文介面的我們不去做這件事,那麼還有誰可以幫助看不懂英文介面的本地語言使用者呢?

CC BY-NC-ND 2.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!

bluebat曾以開發小組主管或專案經理的身分,在開放原始碼相關業務的公司任職多年,主要負責套件打包與系統整合的工作。同時熱衷於自由軟體的本地化,長期參與 GNU 翻譯計畫,並製作一些漢語相關的國際化套件。
  • 来自作者
  • 相关推荐

【讀者勘誤】《盲眼鐘錶匠》作者:Richard Dawkins 譯者:王道還

【讀者勘誤】《拿破崙的鈕扣》作者:Penny Le Couteur, Jay Burreson 譯者:洪乃容

【讀者勘誤】《解開生命之謎》作者: Jim Al-Khalili, Johnjoe McFadden 譯者: 王志宏、吳育慧、吳育碩