差異版本翻譯

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

翻譯領域裏藉由電腦輔助翻譯軟體（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 的概念再次加回目標語言中。

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