本地化測試

.com《localization testing》

---kiki翻譯於2005/8/12

在本文中，我們講述了在編碼階段期間所能夠做的事情和為了使發現問題最有效，你應該將你的本地化測試力量集中在何處等問題。

翻譯應用程式的資源和測試**與開發平行進行通常是一種較好的方法。這有助於在過程的早期揭露**，功能設計中的問題，因為那時做變更相對還是比較容易的。

這也可以幫助決定什麼時候「凍結」使用者介面和功能設計。越快越好。設想一下每次使用者介面發生變更時，都不得不重新翻譯的情況。而且ui

記住晚期的變更會給本地化產品的發布帶來顯著又昂貴的費用和延期。

到什麼地方查詢問題

發現沒有為本地化正確設計的源**是很普通的事。最極端的案例是硬編碼的字串，常量和在**中的字元。包含需要被本地化的硬編碼元素的檔案通常很難處理。翻譯不能有效地翻譯那些是由開發者編寫的源**檔案，

特別是如果**正在不斷地開發過程中。

大多數翻譯不是程式設計師，並且可能會刪除掉重要的細節，

例如結束的引號或分號，或者和翻譯字串一樣翻譯程式關鍵字，這將導致開發人員要花格外的時間去修復這些型別的問題。

乙個典型的解決這種問題的辦法是將所有可本地化的專案分離到乙個或多個檔案中，這樣可以使本地化變得更容易管理。例如，對於基於

windows

的應用程式，最簡單的方法就是使用「資源（

resource

）」檔案。它們很容易編輯，而且你不需要重現編譯源**。

此外，所有本地化的檔案，

不管它們包含**還是使用者介面元素，都可以放在乙個單獨的目錄下，這樣翻譯只需要訪問包含本地語言檔案的和其負責的已本地化檔案的目錄

以下列出了通常需要本地化和應該是可本地化檔案中一部分的要素。

測試

從表面上看起來很簡單，但是測試已本地化的產品需要注意一些並非所有的測試小組都準備的細節。

如果測試在產品生命週期的早些時候就開始測試，那麼已本地化的產品會乙個更好的成功機會。為了迅速的發布它然後移到本地化版本上，乙個常見的錯誤是集中全部的測試力量在國內的產品上。

所有版本的早期測試經常能發現會影響本地化版本存在於核心**裡的嚴重的缺陷。

這將為早期測試做計畫以確保開發部門在整個專案中重視國際化和地方化問題而不是把那些憂慮當作追悔。

在測試已本地化的軟體時，考慮不同的測試的層次。

最初，集中測試在本地作業系統上程式的安裝和卸裝；正文串在對話方塊中是否合適；糾正貨幣，時間等等，遵循的格式；並且所有的正文串都是目標語言。測試過程中乙個關鍵組成部分是保證「最終」的本地化產品功能和需求的一致。

更高階的功能性測試將集中在拼寫的正確性，語法，排序等等。注意到這需要一定的語言學水平，這類測試通常要求一名說母語的人（

native speaker

）來執行測試。

兩個層次的組合是最好的選擇。

另乙個與測試有關的問題是要清楚決定修復或不修復乙個只發生在產品的本地化版本中的缺陷的影響。如果英文版本接近於發布，那麼只有試著推遲修復這類缺陷直到國內產品發揮之後。這裡的風險是將積累很多的國際化缺陷，留下很多未解決的變化不得不合併到下一產品發布。

本地化測試檢查清單（checklist）

以下列出的是一些需要在本地化軟體過程中特別注意的地方。外觀

國際化硬體

/軟體場景

印刷文件