Categories

工作態度 (1)    方法論 (5)    本土化 (9)    危機管理 (2)    死亡 (1)    自我成長 (1)    自我管理 (3)    決策管理 (1)    版本 (1)    社會 (2)    品管 (3)    風險管理 (1)    效能 問題 (1)    時間管理 (5)    專案 (10)    教育 (1)    產能 (1)    產業 (5)    軟體 (4)    測試 (10)    閒聊 (14)    溝通 (4)    道德 (1)    漫談 (23)    管理 (1)    機器翻譯 (1)    簡轉繁 (2)    翻譯 (8)    booksore (1)    Chinese (1)    Flash (1)    G11N (1)    I18N (3)    Industry (1)    L10N (8)    politics (1)    Project Management (6)    Revision (1)    Software (3)    Testing (4)    Time Management (1)    Translation (4)    UI Design (1)   

2007年11月9日

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

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 句不會異動的字串一再的進行重新翻譯(自翻譯記憶庫自動比對)。

0 Comments: