SELECT LANGUAGE:

如何做好軟體在地化:軟體在地化過程的 10 大注意事項

在地化與翻譯彼此相輔相成,然而人們卻經常將這兩者混為一談。儘管這兩者確實有部分相同之處,軟體在地化流程實際上要複雜許多。針對特定地區或市場因地制宜調整產品或內容,不僅涉及修改圖片、格式、版面配置等諸多事項,也要滿足其他市場的法規要求、資料合規性、裝置偏好和技術趨勢。

 

由於有太多文化上的細微差異需要考量,這些看似枝微末節的細節往往容易被忽略,然而若要盡量為最多目標客群推出完美產品,這些要素卻非常關鍵。那麼,該從哪裡著手開始?不妨參考以下軟體在地化最佳實務以及應該小心注意的陷阱。

務必擬定策略,以處理在地化事宜。


Do approach localization as a strategy.

 

第一要務就是要清楚了解,軟體在地化對您的全盤目標有何助益。為避免在地化功虧一簣,在分析需求和設計等階段必須特別審慎,同時要確認所有利害關係人都能在目標市場、語言和各自獨特的問題上達成共識。

想在全球獲得成功,您應該擬定策略處理軟體在地化流程,而不是將這個流程視為單一任務。如果您的目標是為全球上市做好準備,您日後無須重新設計就能掌握某個市場的商機並從中受益。

設計時別忘了將在地化納入考量。


 

有利於在地化作業的設計會有助於減少時程延宕和預算超支等問題。這種設計的原始碼和結構,能有效防範以下問題:


  • 原始碼的錯誤重複出現在目標檔案中

  • 可避免的翻譯錯誤

  • 常見的軟體在地化錯誤,包括功能錯誤、顯示錯誤、縮寫錯誤,以及過與不及的在地化作業


訣竅:不妨使用範本來確保一致的品牌能見度。需確保設計已做好在地化的準備嗎?請測試、測試、再測試。您可以進行偽在地化 (Pseudo-localization) 這種 QA 測試,這個實用流程能找出潛在的翻譯問題,例如特殊字元或字串長度造成的使用者介面 (UI) 配置問題,進而降低出錯的風險。

務必建置國際化物件的資料庫。


Do build a library of internationalized objects.

 

請記住:國際化有利於在地化作業的進行。匯集國際化物件並建置資料庫,日後將軟體在地化為多個語言版本時,就能減少重做時間。這類物件包括:


  • 使用者介面設計元素

  • 排序和搜尋功能

  • 多位元字元支援 (亞洲語言)

  • 雙向或由右至左顯示支援 (阿拉伯和希伯來文)

  • 地址、數字、日期和貨幣格式

 

原文不要太長。


 

每種語言的句型結構、單複數規則都不相同,表達概念所需使用的字數也不一樣。為了盡可能減少翻譯問題,原文內容應該要簡明扼要,並具備以下特點:


  • 簡短的句子

  • 盡可能使用標準英文語序

  • 不要使用由許多名詞連續組成的片語 (名詞字串)

  • 不要使用同義詞;同一個概念以同一個詞彙表達

  • 不要使用縮略語;縮略語需要額外翻譯,並會因此失去任何次要的含意


訣竅:除了避免使用同義詞外,也不要把名詞當「動詞」使用。也就是說,不要在不同脈絡下重複使用相同的文字。英文中有很多字可以當名詞用,也可以當動詞用:例如 file、share 和 design 等。請為這類文字決定單一種用法,然後按照決定採行一致的用法。

務必預留文字擴充空間。


Do plan for text expansion.

 

根據估計,英文共有超過 1 百萬個字,而大多數的其他語言則不到 50 萬個字。所以,將英文原文翻譯成其他語言時,字串的長度可能會增加,但也可能會縮短。舉例來說,英文的「Have a nice day!」翻譯成德文是「Ich wünsche Ihnen einen schönen Tag!」,長度增加了 125%。但將英文翻譯至亞洲語言時剛好相反,長度會縮短。

因此,請至少預留 30-35% 的擴充空間,並考慮使用空白字元。同樣地,請盡量讓原文保持簡明扼要,並採用與格式及用字遣詞相關的其他軟體在地化最佳實務。

不要誤用圖示。


 

當然,軟體在地化最佳實務並不只聚焦在文字溝通上。對不同文化而言,同樣的視覺素材也會有不同的含意。使用沒有文字的圖示有其好處,它們耗費的翻譯心力較少,有助於降低成本。但請謹記,不是所有符號都是全球通用或意義中立的。

例如,許多其他文化就無法理解美式郵筒代表的意思。因此,請務必做好研究調查工作,並避免使用手、腳、動物和其他可能有意料之外或令人反感意義的影像。

務必使用 UTF-8 編碼。


Do use UTF-8 encoding.

 

大多數的現代技術,都預設使用 UTF-8 這種最常見的 Unicode 格式。知名的資訊處理專家 Ken Lunde 博士形容 UTF-8 是「世界第一個智慧型字元編碼」。Unicode 不但是所有主要軟硬體公司支援的編碼,也是 XML、Java 與 Javascript 等標準要求使用的編碼。使用 UTF-8 可確保所有語言的翻譯都能輕易正確地顯示出來,尤其是亞洲的 CJKV (中文、日文、韓文和越南文) 語言。

不要將文字或標點符號寫死在程式碼內。


 

在準備進行在地化時,任何「寫死」的文字 (英文為 Hardcoded text,意思就是嵌入原始碼中的文字) 都必須要擷取出來,才能進行翻譯。雖然您的語言服務供應商 (LSP) 可以執行語法分析器,然後找出這些可翻譯的文字,但最好還是在設計之時,就儘量減少這種做法。您應該使用單獨的資源檔案 (像是標題、產品名稱和錯誤訊息等文字資源) 並另外批註資源,藉以減少翻譯錯誤。

訣竅:有些人為了方便,會用預留位置以寫死的字詞或片語順序串接不同的字串,以減少字串的長度。然而,不同語言的語序和文法規則並不相同,這麼做往往會導致誤譯以及在地化字串錯誤。而解決這個問題最簡單的辦法,就是儘量不要這麼做。

務必諮詢在地化專家。


Do consult with a localization expert.

 

您的 LSP 除了能就 Android、iOS 與 Windows 開發工作提供相對應的在地化檢查清單,還可提出精闢見解與最佳化的流程,協助您節省時間與金錢,並降低重做機率。在展開軟體在地化流程之前,不妨向您的供應商提出具體問題,確保雙方能順利成功地合作。

訣竅:請記得為 LSP 提供您的「請勿翻譯」(Do-Not-Translate,DNT) 之內容的列表,避免在地化過度或在地化不及的狀況發生。若未正確翻譯的字串剛好對程式相當重要,過與不及都可能對程式碼的功能運作造成影響。

要超越期望,不因達成期望而滿足。

說到底,每一個小細節都應該要審慎處理。從最簡單的行動應用程式,到複雜的多使用者系統,在地化都是推動軟體銷售與接受度的關鍵所在。

不妨以 80-20 法則做為您「全球在地化」心力的衡量標準,也就是以 80 比 20 的比例來迎合全球與在地客戶行為。透過深刻了解在地市場,並將文化敏感度納入設計與開發流程,您不僅能滿足使用者的期望,更可提升他們的體驗。若能在開發軟體時就特意做好邁向全球的準備,自然就可以進一步追求全球市場的大商機。

如要深入了解軟體在地化作業的詳細資訊,歡迎立即與 Lionbridge 業務代表聯絡

  • #blog_posts
  • #translation_localization

Sophia Eakins
AUTHOR
Sophia Eakins