我們能夠寫出這篇文章，得益於我們客戶提出的五花八門眾多問題——我的遊戲哪裡有問題？本地化做到這種程度還不夠嗎？應該如何解決呢？
在引入新遊戲時，不少人會採取一些投機取巧的方法。如果您無意循序漸進地增長，這甚至堪稱是一個高明的策略。
然而，期待已久的本地化版本一切就緒之後，大多數遊戲開發商才開始思考如何才能吸引更多海外玩家。自家遊戲在更多國家發行後，他們遲早會提出幾個與本地化相關的點子。
首先我們要確立——本地化翻譯定義：將用戶介面翻譯為目標語言，並根據文化、宗教和政治因素進行調整，從而迎合某個國家或地區的市場需求。
我們要強調的是，本地化翻譯是為了「詮釋」，而非「改編」。
舉個例子，某個遊戲說了一個關於英語民間故事角色的笑話，翻譯成德文時，本地化翻譯的處理方法應該是用德國知名笑話予以代替。然而，如果用戶介面的空間不足以容納文字量較大的德文文本，就得耗費更多的心思另謀他法。
另一個體現本地化涉及之廣的例子，則是數字的翻譯。比如說，在美式英語中，有時要求用單詞來表達數字，不能用阿拉伯數字。至於其他地區的本地化，可能需要注意數詞與名詞的複數單數形式保持一致。例如在俄文中，單複數還存在一些特殊情況，而日語和中文則沒有複數形式。然而，如果數字和文字是以硬編碼形式存在於遊戲的靜態圖像中，僅僅翻譯是不夠的。
這兩種情況還只是冰山一角——進行本地化流程時，您還會遇到各種各樣與本地化無關的問題。有些人稱之為偽本地化或國際化錯誤——也就是一些本可預測和避免，但需要開發人員耗費諸多心力與時間才能解決的問題。
這就是為何 Alconost 公司會為開發人員列出一份規則，讓他們在專案啟動時遵行這些建議，使開發流程更為輕鬆容易，及早為本地化打好基礎。
1. 提前選擇本地化翻譯語言
正如我們之前 APP 本地化工作流程專題文章所述，行動清單的第一項就是「評估您的潛力」。我們將在這裡重複一遍。
您可能會反對說，在一款遊戲真正上線之前，您不可能預見到所有潛在的市場語言。嗯，這在一定程度上是正確的：您得先用非本地化翻譯版本做個測試，看看用戶的回應。然後，您再進行本地化翻譯。然而，您無需每次都按這個步驟行事。
首先，您的遊戲可能帶有太多文化和地域方面的禁忌，如果未進行本地化。即使遊戲內容精彩好玩、敘事一流，您的遊戲亦會被拒之門外。
那麼在開始之前，預測有希望的語言環境的最佳方法是什麼？
-
分析競品的本地化。一般而言，如果競爭對手的遊戲在某個市場發現了藍海，您也有很大的機會在該市場獲得成功。
-
按風格評估本地化。例如，如果您是獨立開發者，正在考慮發行一款復古風格的 Roguelike 遊戲，您可以觀察成功的同類遊戲，確定哪些市場的前景看好——例如，《地痞街區》，已經翻譯為七種語言，外加英文。另外一種辦法，則是從地域角度進行分析。比如說，電子遊戲是日本文化不可分割的一環，那麼開發初期，您可能就要將日本列為目標市場了。
-
研究遊戲本地化需求最強烈的那門語言。說到這裡，您可能想看看我們之前在「遊戲本地化的最佳語言」一文中的研究報告。
然而，我們的「0 號規則」是盡可能將英文作為遊戲的來源語言。我們建議您在開發的第一天起，應考慮在兩種語言環境進行開發。
兩個「預設」語言環境應該是英文和您的母語 (如果不是英文的話)。這種方法有幾個不可否認的好處：首先，以後可以使用英文作為原文資料，將您的遊戲翻譯成新的語言。這有助於確保一致性。第二，一開始就準備兩種語言，這會讓您提前認識到本地化前期工作的所有陷阱。到時遊戲擴展到 20 種語言，您就會非常熟練了。
2. 為目標語言調整介面
在設計介面元素時，人們一般會為其他語言文本留出 30% 空間 (甚至更多，如果能做到的話)。這對短字串 (功能表選項、UI 等) 尤為有用。
然而，我們還有更好的方法。如果您已經考慮到了規則 1，並具有初步的目標語言列表，那麼我告訴您一個好方法：為最棘手的語言設計介面。
例如，德文的文字量一般都會比英文多平均 30%，俄文則是 10%。阿拉伯文也是這種情況。另一方面，繁體中文的佔用空間一般比英文少 30%。
再說到位元組，一個拉丁文字母等於一個位元組，但西瑞爾文和阿拉伯文是兩個。您在規劃資料存儲時，亦需要考量到這一點。
3. 請勿將字串直接嵌入代碼中
轉換文本進行本地化，會導致這些硬編碼字串丟失。記住這條本地化規則：每一個可本地化的字串皆應該是可編輯，請勿觸及任何代碼。
實際上，為了本地化而做的這些工程皆可歸結為「國際化」，簡稱「i18n」——係指讓產品無需進行大幅變更，就能適應不同的語言和地區的需要。從程式角度而言，就是在不修改內部代碼的情況下，能根據不同語言及地區顯示相應介面。
另一個重要的技巧，則是避免用較小的單一單詞組成欄位。為 StackExchange 做出貢獻的 Google 程式師，為我們提供了如下一則典型範例：
- String currency = Locale::getCurrencyString() + money.toString(); // creates $123
這就體現出了一個問題——其他語言可能會將幣種符號放在數字後面。
您可以使用需要本地化的格式化字串。例如：
- String format = Locale::get(“currency format”); // returns “${0}” in English String currency = String::Format(format, money.toString());
後一種方法允許本地化人員在實際格式化字串中重新排列單詞。
4. 請記住，時間、日期、計量單位和數字也需要翻譯
作為上一條規則的延伸，我們想明確指出，數字方面的資訊亦需提取自代碼以進行翻譯。因此，也不能硬編碼。
您還需要準備好重新設計介面上的數字。例如，遊戲時間線上的計時，也應該進行本土化作業。原因是，西方國家大多是單向性時間模式。，也就是說，他們習慣用一條延伸的線表示時間的流動，而亞洲國家則喜歡多樣性時間模式，以圓圈表示時間。
更不用說，不同語言的日期格式、計量單位各不相同了。
所以我們的建議是：進行本地化作業時，要做好準備，考慮好每一個細節。
5. 使用預留位置和格式化控制項，並使其易於存取
涉及本地化和文本編輯時，使用預留位置，有時也是不錯的選擇。但如果不提供預留位置的存取權限，它很有可能成為一把雙刃劍。
這個問題牽涉到不同語種的不同語序。所以我們的建議是：讓您的預留位置成為短語的一部分。如此一來，就能在上下文插入該預留位置。舉個小例子進行對比一下：
反面範例：“Mommy ate ” + %num + ” apples.”
正面範例：“Mommy ate %num apples.”
對預留位置的簡短描述，亦會有很大助益。這樣一來，當預留位置被認為是與前面的文字有不當關聯或不相關時，就能避免疑惑。
6. 避免往圖片裡加文字
如果您的遊戲中有圖片，記得也要進行翻譯，尤其是那種帶有文字的圖片。這就意味著您要從頭設計圖片。
有時，重新設計圖片和創意素材是個好主意。如此一來，您就能根據目標市場的需求，對元素做出相應調整。然而，如果您只是單純替換翻譯文本，那就完全是浪費時間了。
7. 使用正確的編碼和字型
如果您需要某些與您字串類迥異的特殊字元，例如 “spécîål”，難免會出現編碼問題。如果您的目標語言在經過本地化處理後，卻出現了編碼不相符的情況，可能需要耗費諸多心力與時間，刪除這些可怕的字元，例如 ��� 這等字元。
字型方面也會出現同樣的問題。特別是某些花哨的遊戲字型只涵蓋了某些語言的字形。結果就是，您可能得為不同的語言挑選不同的字型。在選擇字型時，請注意這一點。否則，遊戲中可能會出現一堆方框 (□□□) 而不是文字。
我們建議您盡量使用 Unicode 而非 ASCII。UTF-8 是最常用、而且是空間利用率最高的編碼。所以，請確保您的輸入檔未出現編碼錯誤。
關於這一點，我們就先講到這裡了。關於編碼的詳盡教學課程，請見 Alconost 另一篇尋找 “mojibakes” 文章。
8. 如果已經為本地化做好準備，您可以試試偽翻譯
當您將上面所述技術事宜皆準備就緒，您即可試運行看看。網路上有很多實用偽本地化工具，可以將您的介面模仿成外語介面，包括調整文本長度、檢查編碼和硬編碼字串。
基本上，這些工具都會執行一個模仿目標語言的腳本，並生成測試版本。之後的常規流程，必須將該測試版本作為非本地化版本進行 QA 測試。
這種提前測試並非靈丹妙藥，不過的確大有助益。而對於開發者而言，這也是一件很有趣的事。
9. 及早製作術語表
術語表是遊戲內專有詞彙和概念的整合，在整個遊戲必須保持前後一致。這些詞彙主要包括物品、人物名稱、器物和屬性狀態。
保持術語翻譯一致是至關重要之事。試想一下，如果某個遊戲物品有時被翻譯為「藥水」 (potion)，有時卻被翻譯為「靈藥」 (elixir) ——您無意間為玩家徒增了邏輯難題。
10. 準備好提供上下文
與提供詞彙表同樣重要的是，確保本地化團隊得以取得他們需要的所有上下文。從我們經驗來看，譯者、本地化專案經理和遊戲開發者之間的充分交流，有助於語境的建立。
我們意識到，要請開發團隊 24 小時待命有一定難度。然而，在本地化階段，我們的建議是指定一個代表作為您的連絡人——錯誤或模糊不清的語境，確實會對本地化的最終結果產生顯著負面影響。
除此之外，本地化工作流程平台主要是根據客戶的喜好予以選擇。這麼做，是為了確保溝通的便利和高效率。
充分的準備工作，最終會讓您獲得豐碩的成果。
我們希望這些簡單的規則、建議，能對您的遊戲開發有所助益。祝您能夠馬到成功，讓玩家們沉浸於無邊的遊戲樂趣！
