隨著國內游戲行業的迅速發展以及競爭的加劇，越來越多的游戲產品開始沖出國門，走向世界。對于國內已經成功上線運營的產品，一般來說發布海外產品不會遇到什么技術上的的瓶頸，常常出現的是發布遲緩、bug頻出、版本管理混亂等問題。

本文試圖總結游戲國際化的一些經驗，主要關于版本管理和文本翻譯這兩個方面，不討論跨國運營或部署，不討論針對不同文化和習慣的本地化等問題。

1、不要為每個語言版本建立單獨分支。

通常項目開始做國際化版本時已經有了一個比較穩定的中文版，開始做國際化版本時為了保證中文版的穩定，常常會新建一個國際化版本分支交給專人去維護，這樣一來就掉進了一個大坑。

看起來分支和主干互不影響，能最靈活地應對國際化的特殊需求。實際上主干上開發的新功能最后總是要發布到國際化版本上的，分支上做的修改越多做代碼合并的工作量就越大，往往到后來靠一個人就忙不過來了，干脆成立新的項目組獨立開發國際化版本——這樣無疑是人力資源的極大浪費。

所以合理的做法是不建立分支，開發一個多語言版本的游戲，而不是多個獨立的游戲。

2、盡量不要針對不同地區寫特殊代碼。

不同語言版本都會有一些特殊的需求，再加上由于設計的問題可能產生某些語言版本上的特殊bug，在不開分支的情況下，開發人員很容易就掉進了第二個坑：在代碼中編寫大量針對不同地區的特殊代碼。

很顯然大量的特殊處理代碼會削弱代碼的可維護性，特別是多加一個語言版本時需要到打大量補丁，進一步使代碼變得混亂不堪。

所以不到萬不得已，盡量不要針對不同地區寫特殊代碼，而是使用統一的機制來解決不同版本的差異性。比如不同地區上線不同的運營活動，選擇使用配置文件進行控制就比在代碼中寫死更恰當；比如UI中的文本在某些語言版本中顯示不全，與其針對不同語言設置不同的文本框長度，不如統一將文本框拉至合理的長度，當然做成動態改變文本框長度就更好了。

3、源代碼中不能出現漢字或直接用于顯示的字符串。

把用于顯示的字符串放進統一的字典文件不僅使游戲翻譯更簡單，也便于策劃進行維護，即使不考慮做國際化版本也是很有必要的。手機靚號轉讓平臺只是很多程序員的自控能力比較弱，或者說保持代碼可維護的意識比較弱，經常為了一時的快就繞過這個約束，帶來不必要的麻煩。

4、服務器代碼或配置中不能出現漢字或直接用于顯示的字符串。

游戲中的一些文本其實是服務器生成發往客戶端的，例如系統郵件、系統公告等。最佳實踐是把服務器做成是語言無關的，服務器發給客戶端的是字典Key，客戶端根據自己的語言解析后拼裝好文本并顯示。

這樣一來就不需要針對不同的語言版本打不同的服務器版本了，還可以實現多個語言版本連接同一臺服務器。

舉例說明，現在我們需要系統公告恭喜玩家Alice晉升至等級排行榜第1名，中文客戶端有如下字典配置：NoticeRank -> 恭喜玩家#user晉升至#rankName第#rank名，LevelRank -> 等級排行榜，服務器發給客戶端的消息類似于{Message:"NoticeRank", user:"Alice", rankName:"#LevelRank", rank:"1"}，客戶端從字典中取出當前語言的文本，再把參數替換進去生成最終顯示用的文字。

5、盡量不要使用帶文字的圖片。

有時候游戲中為了實現特殊的美術效果，常常把文字直接畫在圖片資源中，其實這種做法對國際化特別不友好，容易在翻譯時遺漏，而且重新制作各種語言的不同圖片也增加美術的工作量，還會給資源打包帶來一些麻煩，所以建議盡量避免。

如果不得不使用帶文字的圖片，有以下幾點建議供參考：

開發中使用文檔記錄所有圖片中的文字，并與字典文件一齊交給翻譯人員，避免遺漏。

注意保留圖片源文件，便于快速替換。

體驗降級，對品質要求不高的版本可以考慮直接退化成使用系統文字，減少工作量。

一些常見的游戲術語可以退化成統一使用英文。比如表示暴擊的Critical，表示力量的Str.。

訂制資源打包腳本，針對不同的語言版本打包不同資源。

6、設計結構化的字典配置，減少冗余。

結構化的意思是不同的字典詞條有層次上的區別，不同的詞條是可以互相引用的。

例如上文提到的系統公告中，NoticeRank詞條就引用了LevelRank詞條。假如不支持詞條互相引用，這個功能就需要恭喜玩家#user晉升至等級排行榜第#rank名，恭喜玩家#user晉升至戰斗力排行榜第#rank名，恭喜玩家#user晉升至聲望排行榜第#rank名等等多條幾乎完全重復的詞條。

使用結構化的字典配置至少有3點好處。

首先易于維護。考慮一下我們想把公告中的恭喜換成祝賀，非結構化的工作量就大了幾倍。再考慮如果把字典拆分成幾份交給不同的翻譯人員同時翻譯，很容易同一術語出現幾種不同譯法。

其次是更不容易犯錯，以前有個項目中角色叫做“英雄”，而實際我們在討論功能時用的詞是“武將”，策劃在配置文本時很容易誤用，于是游戲中一會兒是“英雄”一會兒是“武將”，特別混亂。如果所有詞條都引用同一個Hero詞條就不存在這個問題了。

第三點就是省錢——通常翻譯都是按行或字數收費的。

7、不要使用%d、%s等標識文本中的變量。

很多程序員想當然地讓策劃使用%d、%s來標記變量，生成文本時直接使用sprintf函數。這里有個很大的陷阱就是sprintf是依賴于參數的次序的。

比如文本玩家%s對玩家%s造成了%d點傷害，可能在其他語言中語序變成玩家%s被玩家%s造成了%d點傷害，按照原本的次序填入參數后意思完全反過來了。甚至語序可能變成玩家%s將%d點傷害施加于玩家%s，程序在運行時試圖將數字填入%s，導致內存訪問越界程序崩潰。

考慮到語序的問題，上面的字典應該配置成玩家#1對玩家#2造成了#3點傷害。更好的做法是使用有意義的變量名：玩家#attacker對玩家#defender造成#damage點傷害。

8、注意多義詞。

曾經玩過一個漢化版的小游戲，這個游戲第1關的標題處顯示的是“1級”，顯然原因是Level在英語中同時有“關卡”和“等級”的意思，原版游戲中這兩處同時使用了Level這個詞條。

所以我們要留意中文里的多義詞，當兩個詞條中的同一詞匯意義不同時，不能引用同一詞條。比如“注冊登陸”中的“登陸”和“搶灘登陸”中的“登陸”就要分開。（好吧其實應該是“注冊登錄”不過這不是重點……）

9、留意UI中文字的長度問題。

UI中文字長度是國際化中的常見問題了，上文也有提到，這里再提供幾個思路供參考：

涉及大段文字時，UI上的設計不要依賴于當前語言版本的文本長度，最好使用帶滾動的文本區域。

UI的設計不要太緊湊，為國際化后文本的長度變化預留一定的空間。

使用文檔記錄UI對文本長度的限制，與字典一并提供給翻譯人員。如“雜貨店”正常應譯為”grocery”，但若是限制在6字符內翻譯為”store”也沒問題，若是只有4字符的空間還可以用”shop”。

體驗降級，使用簡單的統一機制解決文本顯示不全的問題，比如按鈕文字顯示不全時自動循環橫向滾動。

總結

總的來說，游戲國際化并沒有技術上的難點，主要是考驗團隊的管理規劃和繞坑的能力，最重要的是預判可能遇到的問題，提前想好應對措施并嚴格執行。

總結

以上是生活随笔為你收集整理的从技术角度谈游戏国际化的一些建议：版本管理和文本翻译的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。