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:
張貼留言