本地化語彙

每個地區經常都有一些各自的特殊慣用語，在生活習慣上也都有一些小差異。城鄉之間的差異也會造成生活習慣的不同。例如都會區裡的小餐館，常見要客人點完菜先付款，但城郊的小餐館通常你吃完要走再結帳，不急！

本來嘛，一群人在一個區域裡共同生活，本來就會逐漸發展出特有的互動方式，語言文字也是這樣逐漸產生。這個鄉可能大家在廟會時很熱情，隔壁鄉可能是在普渡時擴大慶祝。習慣也是會改變的，雖然現今法規規定車輛應等禮讓行人先行通行過斑馬線，在都會區裡，你行人可以比較放心的走，到了鄉下，你可得更加小心有無車輛。

至於語彙呢？想像我今天一早出門，遇上鄰居，「嘿，早安！」到了早餐店：「老闆，包子一個，米漿一杯，帶走。」到了公司，看見警衛：「早！」中午時，到了麥當勞：「我要一號餐，外帶。」 下午到了 7-Eleven 買咖啡：「中熱拿，不要糖！」傍晚口渴，到飲料店：「綠茶一杯，無糖，去冰。」這裡出現類似的語彙有「早安 / 早」、「帶走 / 外帶」、「不要糖 / 無糖」等等。這些用語都是當地慣用 / 通用的，所以不管你怎麼說，大家都很容易的可以懂。

如果你在路上遇見個路人，問你「請問，要到 101 ，打車過去快還是搭公車？」我告訴你，這路人八成是個大陸人，因為「打車」不是說去敲打車子，是叫一部計程車。在台灣也會用「打」字，例如「打電話」、「打卡」，為什麼你就不會懷疑這是在講要把電話打壞，要把卡片打壞？因為我們習慣那麼講。但我們不講「打車」！

「大口吃遍台灣」的主持人阿松，他在點小吃時，常常會錯用量詞，例如「老闆，那個湯，我要一個，裡面用。」雖然量詞本來就不好學，一個、一碗、一份、一杯、一瓶、一張、一箱、一桶........有時確實講「一個」最快，即使聽起來很奇怪。這就好像用英語你要說 one cup, one meal, one beer, one cloth....基本上大家都懂，你不太需要去執著什麼 one piece of xxxx 之類的。

語彙差異在網路遊戲上也造成一些小困擾，例如最近很熱門的星海爭霸，台灣伺服器上有很多來自中國大陸的玩家，於是就有台灣玩家指出兩邊語彙跟講法的不一樣，例如：

中國大陸用語	台灣用語
造房子	建房子
出2隊機槍兵	生2隊機槍兵
來2隊小狗	來2隊小蟲

再談簡轉繁可行與否

上一篇用英文寫了簡轉繁的可行與否，這裡再次談到簡轉繁的可行性。其實十多年前台灣的電腦普及率遠高於對岸，當時中文化產品少，很多網友熱心進行軟體翻譯，甚至組成了 cpatch 組織，共同研討軟體中文化技術，只可惜當時 open source 的翻譯記憶庫技術與資源相當少，因此大家多半各自為政。待對岸的電腦越來越普及，以及網路涵蓋率越來越高後，對岸的中文化（簡中）產品相對的也多了很多，接著難免就會看到台灣有人簡單的用所謂的簡轉繁技術將簡中翻譯檔案直接轉成繁中，有些人還會花點心思修正辭彙，諸如將「默認」修正成「預設」，後來也有工具可以將常見的辭彙直接轉換，但針對語句則通常不會加以修飾。舉例來說，「Set Program Access and Defaults」這串文字的簡中翻譯為「设置程序访问和默认」，假設用 MS Word 內建的簡轉繁會得到這樣的結果「設置程式訪問和預設」，但該句的正式繁中翻譯為「設定程式存取與預設值」。我們把這些翻譯排列一下：
原　文：Set Program Access and Defaults
簡　中：设置程序访问和默认
簡轉繁：設置程式訪問和預設
繁　中：設定程式存取與預設值

也許有人看出來這個例子其實是簡繁辭彙對應不夠完整，例如「设置/設定」、「访问/存取」，沒關係，我們再來看多一點例子：
原　文：You do not have permission to set program access and defaults.
簡　中：您没有权限设置程序访问和默认值。
簡轉繁：您沒有許可權設置程式訪問和預設值。
繁　中：您沒有設定程式存取及預設值的權限。

後面這個例子明顯看出翻譯的風格不一樣，誰優誰劣也許見仁見智，但很明顯的至少在這個例子中，繁中的原生翻譯將原文重組過後才生出繁中的翻譯，do not have sth1 to do sth2 翻譯後將 to do sth2 變成動名詞，尾巴附加所有格然後接上 sth1 。簡中的翻譯比較是直譯原文。其實兩岸普遍來說翻譯的風格迥異，
看習慣台灣翻譯的人也許看到已經簡轉繁附帶辭彙轉換完成後的簡中翻譯，會感到不習慣，甚至感到難以閱讀。實際上有多少比例的人會有這樣的感受，我沒能做統計，不曉得有無這樣的統計存在，我只能推論有一定比例的人會有這樣的感受。

如果以英文來推演，原本的 You do not have permission to set program access and defaults. 換個說法也可以說成 You are not permitted to set program access and defaults. 或是 You cannot set program access and defaults due to you do not have required permission. 其實意思都相當接近，只是說法不一樣。繁中與簡中的翻譯大致上也是意思相近，但說法不一樣。

當一個產品或是一本書交給同一個譯者來進行翻譯，風格會保持一致。好的翻譯風格，其實也會影響其他譯者，那麼久而久之同一個環境的某部份翻譯作品的翻譯風格多少會比較接近。簡轉繁就好似換了一批作者或是譯者，文句的敘述方式完全迥異，看倌們真能習慣嗎？

我戲稱，若是簡轉繁產品越來越多，也許以後我會考慮直接購買英文版產品，而不再購買中文版產品了。

機器翻譯的技術瓶頸

今天在搜尋一些資訊時，從 Google 找到一個微軟的 KB 連結，於是連過去看了一下，好幾段文字讓我看了實在很頭痛，在這裡貼出來跟大家分享一下：

當您使用的東亞的 ClearType 字型，在 Microsoft Office Word 2007 時，您無法使用所提供的字型，內部前置字元。 使用東亞 ClearType 字型會格式化文字會有太多文字行之間的空間。

如果要解決這個問題，在 Word 2007 文件中請包含只 Meiryo JhengHei，或是 YaHei 的字型，請依照下列步驟執行]：

我去找了原文看了一下，看看各位看倌會不會覺得總算恍然大悟：

When you use an East Asian ClearType font in Microsoft Office Word 2007, you cannot use the internal leading that is provided by the font. The text that is formatted to use the East Asian ClearType font has too much space between the lines of text.

To work around this problem in Word 2007 documents that contain only Meiryo, JhengHei, or YaHei fonts, follow these steps:

我來把它們排成表格，並且對照 Google 的機器翻譯看看

Source	MSDN KB	Google Translate
When you use an East Asian ClearType font in Microsoft Office Word 2007, you cannot use the internal leading that is provided by the font. The text that is formatted to use the East Asian ClearType font has too much space between the lines of text.	當您使用的東亞的 ClearType 字型，在 Microsoft Office Word 2007 時，您無法使用所提供的字型，內部前置字元。 使用東亞 ClearType 字型會格式化文字會有太多文字行之間的空間。	當您使用東亞ClearType字體在Microsoft Office Word 2007 ，您不能使用內部領導所提供的字體。的案文是格式化為使用東亞ClearType字體太多空間之間的行文字。
To work around this problem in Word 2007 documents that contain only Meiryo, JhengHei, or YaHei fonts, follow these steps:	如果要解決這個問題，在 Word 2007 文件中請包含只 Meiryo JhengHei，或是 YaHei 的字型，請依照下列步驟執行]：	要變通解決此問題在Word 2007中的文件只包含Meiryo ， JhengHei ，或YaHei字體，請按照下列步驟操作：

基本上可以發現只要英文包含有子句時，也就是以 which, that, what, where 等所領頭的子句時，機器翻譯的結果往往令人丈二金剛摸不著腦袋。雖然確實英文的子句在現實生活中也很長令人聽不太懂，即使是英語系國家的人，對於冗長的子句仍就會感到困擾，那麼機器翻譯無法將具有子句的英文翻譯的通順，似乎不能太過苛責？

不過我倒是懷疑一些公司的資訊採用機器翻譯的結果，究竟能為使用者帶來多少幫助？雖然多數的關鍵字被翻譯出來了，文意也大概可以理解，但某些句子還是得要琢磨很久，我甚至有時會嘗試把句子反過來翻譯回英文，然後再去猜可能是什麼意思。

為什麼多語言軟體要做偽本地化(Pesudo-Localization)

即使軟體的國際化、全球化、本地化已經提倡了相當多年，產業的分分合合（在決定自己做、到決定外包、到再次的決定拿回來自己做）也發生了幾次，但是依舊有為數不少的新加入者，或是從未涉足這塊領域的公司，對於軟體的多語化一問三不知，於是，其軟體的多語化，依舊是十年前的土法煉鋼。

為什麼將要進行多語化的軟體產品，建議要做偽本地化(Pseudo-Localization)？一個大學同學最近問了我這個問題，我想了想，我大概有近三年沒有回答過這類的問題了。不過，事實上我也驚覺我現今周遭的同事似乎有不少人也不了解這問題的答案，更有甚者，對於何謂偽本地化全然不知。或許也難免，當分工過於精細時，如果沒有機會碰觸到這一塊的領域，相當大的機會不會聽過這個詞，也自然不會知道其為何謂。

偽本地化其實是希望能夠解決以下幾件事情：
1. 驗證產品的 UI 確實有被適度的拉寬長度以適合語彙較長的語言，例如德文或是挪威文
2. 藉由偽本地化的技術，順勢驗證產品的各個控制元件是否可以正常顯示歐語的延伸字元（例如：ä ü ö é 等）、東亞（中、日、韓）、以及中東語係文字等。
3. 驗證產品是否會因為過度翻譯，或是因為翻譯的不一致，卻導致產品功能無法正常運作
4. 驗證是否尚有未抽取出的字串因而導致未完全的翻譯

同學問我，那翻譯後不就也知道上述的問題了嗎？理論上是沒錯，但是其實往往為時已晚。很多的狀況下，產品開始進行翻譯時，也就是程式以進入功能異動的凍結時期，甚至產品以進入 beta 或是 RC 階段了，若是此時才發現因為翻譯導致產品功能錯誤，其結果往往是部份的翻譯回復為英文不進行翻譯，然後使用者便拿到一份中英混雜的產品。

不過話說回來，有進行偽本地化的軟體商或是軟體專案，似乎仍舊是相當稀少。
看來幾個強調可以為軟體進行偽本地化工程的翻譯工具，還真難從這些軟體廠商身上賺到錢，也難怪接連的被併購....

Ready for Localization?

Is your software or document ready for localization?
It usually is not that simple to localize anything. Giving you "Hello world" and ask you to localized it into several languages might already have some problems to be resolved first before localizing it.

People who speak English may not be aware of that the nouns have gender in several languages. People who wrote technical document in German might not be aware of that other people might not be able to know how to translate it properly due to it's too specific in a particular area.

Imagine if you receive this word "Entropy", how should you translate it properly if there is not enough context to be reference?
"Entropy" is a physic term and widely used in physics, thermodynamic, and some other fancy area such as image processing.
If you are familiar with PhotoShop, then you probably know the term "entropy" appeared there. Translator will need to look up many different areas' dictionaries and might also need to consult some professors in order to translate it properly.

Imagine I now send you "%s Power" and then ask you to translate it into French, the translated result may not be good due to I did not give you enough information. See below examples (translated results from Google Translate):
Maximum Power ==> La puissance d'attaque
Minimum Power ==> Moins d'énergie
Efficient Power ==> Puissance efficace

So, how can you translate it properly if I only give you "%s Power"? If I only give you that, that means it's not ready to be localized. Actually it's an I18N issue that the codes are trying to manipulate strings, which should not happen if you are going to localize it into several languages.

差異版本翻譯

之前提過關於同步翻譯（不是同步口譯）的主題，在這裡繼續提同步翻譯的想法。不過我想到其實有時這也是一種差異版本翻譯的概念。

翻譯領域裏藉由電腦輔助翻譯軟體（Computer-Aided Translation，通常簡稱 CAT）以及翻譯記憶庫（Translation Memory）的技術，可以有很多方式處理新舊版本之間既有翻譯的沿用。

舉例來說，假定以下為檔案A在1.0版時的前10行：
properties.A.01.name=File
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
#
properties.B.06.name=Open
properties.B.07.name=Save
properties.B.08.name=Save as
properties.B.09.name=Close
並且其對應的中文翻譯為：
properties.A.01.name=檔案
properties.A.02.name=編輯
properties.A.03.name=檢視
properties.A.04.name=格式
properties.A.05.name=工具
#
properties.B.06.name=開啟
properties.B.07.name=儲存
properties.B.08.name=儲存為
properties.B.09.name=關閉

當下一個 1.1 版新增了一行，而使得前11行變成下面這樣：
properties.A.01.name=File
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
properties.A.06.name=Insert
#
properties.B.06.name=Open
properties.B.07.name=Save
properties.B.08.name=Save as
properties.B.09.name=Close
我們的目標是既有的翻譯要能夠盡量的被沿用，以程式開發者的角度來看，假使比對 1.0 與 1.1 之間的差異，事實上是在第5 及第 6 行之間被新增了一行，其他部份並沒有異動，理論上在中文的翻譯檔案裏只需要對應的插入這新的第六行的中文對應翻譯即可。於是 1.1 版的中文應如下面所示：
properties.A.01.name=檔案
properties.A.02.name=編輯
properties.A.03.name=檢視
properties.A.04.name=格式
properties.A.05.name=工具
properties.A.06.name=插入
#
properties.B.06.name=開啟
properties.B.07.name=儲存
properties.B.08.name=儲存為
properties.B.09.name=關閉

不過事實上並沒有這麼簡單。版本之間的差異往往不會只有數行的新增這麼單純，複雜時數十行的新增、刪除、以及異動都可能會有，目視差異來進行手動的版本同步將不再可行並且易有疏漏。

不過，暫且沿用上面這較簡單的例子，一些翻譯的技術可以辨識出既有的翻譯對與新的來原是否相符，若相符則可沿用既有的翻譯。

然而，為了使翻譯能夠更精確，能夠處理相同的來源文字在不同地方具有不同的翻譯，部份的技術採用了上下文比對的方法，以滿足來源文字與目標文字一對多對應的需求。

簡單來說英文的 State ，查一查字典，它在不同地方將可能代表了「州」或是「狀態」。在地址輸入的欄位中把 State 翻譯成「狀態」可就不妙了。上下文筆對的方式便可以使翻譯配對能夠有更廣的選擇。

然而，也因為上下文比對的採用，像上面再簡單不過的例子，也可能導致一些既有的翻譯無法被配對而採用。某些上下文筆對的方式，是取前、後一至數行的文字作為參考文字，因此以下的兩個例子會被視為不同的文句（灰色文字表示為參考的上文或下文）：
Ａ：
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
#
Ｂ：
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
properties.A.06.name=Insert

於是，僅僅因為新增了 Insert 這一行到第六行，將可能導致第四行被認為在新的版本裏上下文與舊版不同，而既有的翻譯配對將不會自動被採用（被視為不是完美配對 Perfect Match）。即使它的相符率可能僅僅是降為100%或是99%，但是這也將可能導致額外的工作量增加。

過去提過的同步翻譯，或是協同翻譯的想法，其實是在討論像這種差異版本之間的翻譯應該怎樣來處理較好。以程式開發者的角度來看，當同時有多人在開發同一套程式時，開發人員經常要做的一件工作便是程式合併（code merge）的工作，必須進行版本間的差異比對，然後將自己的版本與另一人的版本、或是與主版本進行合併。

簡單的說，如果過去我曾經複製了檔案Ａ的 1.0 版，一個星期後檔案Ａ異動至 1.1 版，我可以藉由比對 1.0 與 1.1 之間的差異，發現是在第六行新增 Insert 這一筆，則我可以將這差異加入我手上的 1.0 版的第六行位置，而達到與 1.1 版同步的效果。

目前常見的翻譯軟體對於這種差異版本的翻譯沿用技術並不全然是如上述這般，這導致其實我們僅僅需要針對「properties.A.06.name=Insert」這一行進行翻譯，然後加入中文版裏，變得更加複雜。

這問題大致是因為現有的翻譯技術僅是基於翻譯對（Translation Pairs）來進行比對，頂多再加上該翻譯對的前後文作為參考資料，但並沒有真正去記錄檔案版本間的差異。

過去至今已有很多程式版本管控的系統，諸如 RCS (Revision Control System) 、 CVS (Concurrent Versions System) 、 SVN (Sub-Version) 、或是微軟的 Source Safe 等，儘管有些只是單純的版本管控，有些是為了可應付多人同時開發的版本管控，但大體而言都解決了版本間差異的管理。翻譯的技術如也能處理這種版本間的關連性，應該可以為翻譯的效果帶來不錯的改善。

簡而言之，上面提到的例子理想上僅需翻譯「properties.A.06.name=Insert」而得到「properties.A.06.name=插入」後，藉由 code merge 的概念再次加回目標語言中。

如果有次版本開發概念的人應該更容易理解。概念上就好比在程式的主版本支幹上，另行建立一個分枝（建立另一個語言的分枝），每當主支幹有異動時，藉由比對主支幹新舊版本的差異，將差異同步至分枝裏，而達到與主支幹同步的目的。

軟體平行/同步/協同開發下的軟體翻譯工程

6/19/2007

過往比較常見的軟體翻譯工程，普遍鑑於原始版本 (source version) 已經完成或是接近軟體開發的最後階段，才會開始進行軟體的翻譯工程。對於大型商業軟體而言，由於軟體開發週期常，加以引用不少先進軟體開發技術，當軟體開發已達80%左右的完成度時，多數的規格以逼近底定，此時不太會有新功能的引進，因此諸如操作流程、界面、功能呈現等皆不會有大的變化，在這個時期提前開始進行翻譯工程，即使在最終 RC (Release Candidate) 版本仍有外抽字串的變動，也僅是小幅度的變動。


在這種傳統的開發模式，亦即非平行開發 (parallel development) / 同步開發 (concurrent development) / 協同開發 (collaborative development) 的模式下，翻譯工程是基於來源語言 (source language) 是處於穩定狀態下來進行的。因此，即使在軟體完成度僅達 80% 便開始進行翻譯，直至最終軟體邁進 RC1 甚至 RTM 版本，之間的來源語言頂多只會有小幅度的變動，例如低於五次的小改版。

在此類來源語言處於一個穩定的狀態下，翻譯工程常見的是在第一次進行全面翻譯，當翻譯完成時，會建立翻譯記憶庫 (translation memory) ，則之後每次的小改版，依舊拿新的來源語言版本來進行翻譯。藉由翻譯記憶庫的對應 (mapping) ，未有變動的字串將可獲得 100% 的對應翻譯，則翻譯僅需針對變動字串以及新字串來進行即可，篇幅以及工作量將會很小。

試想，假設當翻譯工程開始進行，直至最終的 RC 或是 RTM 版本之間，來源語言有太多次的變動，例如多達十次以上的變動，或是週期性的，每週甚至每天皆有一個變動，並且希望翻譯可以盡量跟上來源語言版本，那麼既有的模式便會變得過於煩瑣、擾人、且不太實際。

另一種狀況，若是翻譯工程在軟體開發的很早期便開始進行，例如在軟體開發完成度達到 50% 便開始，加以期間的變動相當頻繁，且希望翻譯的目標語言可以盡量與來源語言版本同步，那麼翻譯工程勢必得思索一個更有效率的方式來進行。

舉一個例子，當第一次進行翻譯時，假定此時是基於 Rev.010 來進行，並且此時來源語言共有 1,000 行（假定每行對應一句來源語言），翻譯進行了一週完成，此時來源語言版本已更新至 Rev.011 ，並且新增/異動了 10 行。姑且以每週會產出一個新的版本 (Revision) 並且預期每週平均會有 10 行的來源語言字串的異動，那麼意味著每週進行一次的翻譯工程，其實只需確保這異動的 10 行能夠同步至翻譯的版本。若採用傳統的模式，則每次皆是進行約 1,000 行的自動翻譯（自翻譯記憶庫找尋已有的對應），然後再找出異動的字串來進行翻譯，以其達到與新的來源語言版本同步。

如果採用另一種方式來進行，即利用比對工具，將 Rev.010 與 Rev.011 之間的差異匯出，只針對差異進行翻譯，然後將翻譯完成的差異，匯入原已翻譯好的目標語言版本 Loc.Rev.010 ，則達到與 Rev.011 同步的結果，因此可稱為 Loc.Rev.011。這樣的模式，僅需要針對差異來進行翻譯，而不須頻繁的針對 990 句不會異動的字串一再的進行重新翻譯（自翻譯記憶庫自動比對）。

To Leverage Translations and Apply Pseudo-Localization

My collegue ask me one localization question:
If the resource file has a great updated, and I have an old version's translation. How to leverage the translation, and also, how to apply pseudo-localization to those the newly added un-translated strings?

OK, here are the steps, seems to be a long list, at least it works.
To leverage translation from old version, you need to:
1. Create a new Catalyst TTK project file
2. Insert the original English RC file which was sent out for translation
3. Save this TTK file (OldRC.ttk)
4. Right-click on Resource.rc in Navigator window, and then select "Import Translations" function
5. Find the translated RC file which was translated from the same version as mentioned in step 2, use it as input file, wait for importing complete.
6. Save thsi OldRC.ttk
7. Create a new TTK project file
8. Insert the latest Resource.rc
9. Save this TTK file (NewRC.ttk)
10. Select from menu Tools -> Leverage Expert
11. Select OldRC.ttk as input file, wait for leveraging complete
12. Save this TTK file.
13. Use Extract function to extract the leveraged Resource.rc

To apply pseudo-localization to newly added un-translated strings:
1. Open the leveraged NewRC.ttk
2. Click from menu Tools -> Extract Terminology -> Glossary
3. Select "Tab Delimited", ,"From untranslated strings", "Include ampersands (hotkeys)", "Exclude locked/frozen strings". Then generate the glossary file.
4. Open the generated glossary file with Excel, there will be two columns of data, delete the second column, then save the file
5. In Catalyst, create a new TTK project file, insert the glossary file, then perform Pseudo translation. Save this TTK file.
6. Open the NewRC.TTK file again, use leverage function to leverage translation from the TTK file created in step 5.
7. Save NewRC.TTK, then extract Resource.rc