對于一名游戲開發者來說，本土化總是不能出現在適當的時候。不管我們是否在一開始進行設置，因為我們認為這是正確的方法，但是緊隨其后游戲便遭遇了失敗?；蛘呒词褂螒虮憩F得不錯，我們也必須嘗試著明確如何將其放置在之后的過程。我已經將這個問題放在之后的問題集分類中：如果這是你所面對的問題，那么這便是你需要為此花錢去解決的問題。

最近我參與了一個為本土化提供資金的項目，我們的任務比想象中復雜得多。雖然存在一種簡單的方法，但卻沒有什么好的建議，所以這個任務暫時被擱置了。是使用unity獲得了整個資產渠道，但是獲得游戲翻譯仍然不是件簡單的工作。我仍然需要完成我的資源，資產以及關于文本的所有場景搜索，然后對它們進行重組并參考一些實用內容從而給予當前語言的相關翻譯。我知道自己可以做得更好，對吧？

在Transfluent我認識了Jani，對于使用一種工具而更輕松地利用unity的資產渠道獲得游戲翻譯這一點我們具有類似的想法。他已經通過獲得一個基本的編輯翻譯工具而完成了第一傳。因為它遭遇了許多第二層和第三層問題，所以第一傳是非常好的出發點。然而，與許多unity圖形用戶界面編輯窗口一樣，即時模式的使用將會以某種方式倒向代碼結構并傾向于創造好幾千行內容的文件。所以這是推動我們吸取某些教訓的一個很好的起點。

本土化的障礙：

1.提取文本并將其放在數據儲存區進行翻譯

2.刪除任何關于文本的簡單引用（在場景和預制件中）并用純粹的腳本控制文本進行替代

3.基于某種形式用字符串替代任何串并置（“hello”+“world”）以及動態文本（如來自用戶“hello there”+用戶名的文本）

4.重新將儲存于數據儲存區的文本整合到你所選擇的UI解決方法中

5.找到一種方法去使用翻譯器翻譯你的數據—-這通常包含進入“藍屋”（如：不創造一款游戲）

6.檢查你的游戲是否已經翻譯了所有內容—-使用一種你懂的“外語”并且仍然能夠用于導航至各種理想選擇。例如：Facebook的“英語（盜版）

7.在發現短語未翻譯時獲得新的翻譯內容

什么是正確的：

1.隱藏unity的所有OnGUI和GUILayout功能。這有時候看似瘋狂，但這將以創造一個非常簡單的方法去獲得一個帶有許多靜態文本且能夠更快速地進行翻譯的UnGUI游戲告終。也許還有些功能較為模糊，就像輸入內容是否應該是自動翻譯的，但只要那些內容屬于異常情況，這便能夠幫助你輕松地翻譯游戲。

2.對textmeshes，場景和預制件進行資產掃描。它將找到你的文本并對其進行翻譯。我認為GameSpecificMigration中的黑名單機制可以得到完善。

3.簡單的儲存格式。最初，我將數據格式與專用格式綁定在一起，認為這么做會方便許多。ScriptableObjects是并未存在于場景中的基本游戲對象。它們將在運行時間中獲得同意的優化，并在與別人合作時呈現出YAML合并友好型特質。確保界面就像一本簡單的詞典，并且在處理之后出現的各種簡單任務上允許更多靈活性的出現。

4.“逆向”語言—-這是檢查你的游戲的一種簡單的方法，以此確保你能夠翻譯自己所作出的大多數決定。

5.“捕獲模式”—-能夠貫穿你的游戲而運行，作為一種尋找二手手游賬號轉讓資源翻譯的方法，而不是從代碼中將文本復制到翻譯數據庫，這似乎比較不容易出錯且更容易更新。你也可以選擇其它方法，但這種模式能夠帶給你幫助。

6.編輯窗口邏輯/視圖分離。拆分“視圖”邏輯，就像通過“應用”邏輯呈現文本，如上傳，命令翻譯。基于strangeioc的中介模式，我越來越習慣這種方法。是否想要上傳你自己完成的新翻譯內容？當然。那么在編輯窗口呢？也要。

7.測試—-測試能夠幫助我避免沉浸于某些愚蠢的內容，如脫機以及計劃停運。它們將幫助我在前進的過程中核實設計和數據格式，因為如果我不能單獨測試它，它便很容易崩潰。盡管我以前使用過nunitlite，不過Unity的測試工具剛剛出現，并且是一個很棒且較為完善的工具，基于Jenkins（游戲邦注：是基于Java開發的一種持續集成工具，用于監控秩序重復的工作），我能夠自動操作測試，從而在代碼損壞某些內容時立即獲得反饋。

未知：（例如“已知的未知”）

1.基于OnLocalize支持的運行時間。顯然我們需要一種方法去告知代理語言發生了改變，所以我決定使用Unity向客戶發送信息。這并不是我經常做的某些事，但卻是我發現其它類似的中間件成功使用過的一種模式。

2.標記化。我認為這將以積極的結果告終，而這更多地取決于KISS原則的功勞。最簡單的解決方法只是隱藏字符串。格式以及在“Hello，{0}”格式中使用字符串看似是最正確的方法。事實證明，關于翻譯存在許多細微差別，可能會讓屏幕截圖變得更有效（也有可能變得更糟糕）。

未來的工作：

1.編輯器的支持。翻譯你的編輯工具EditorGUILayout和EditorGUI似乎是有效的。我認為所有需要完整的本土化編輯工具的內容在某種程度上都將連接隱藏的editorguilayout和editorgui與一個特定的TranslationUtilityInstance。我不認為這具有挑戰性，但是我也不確定是否真的需要這樣的內容。

2.確保文本“看起來”是合理的，并且如果翻譯內容需要提前運行的話，提供給翻譯器一個更棒的提示。這與在獲取模式中發送屏幕截圖一樣簡單。

3.更深入的整合—-支持在各種框架上自動換行以及規格調整。

4.支持更多UI框架—-它們帶有許多相關聯的不同挑戰。

5.中間件整合—-整合搭配fungus和其它工具鏈意味著能夠更輕松地創造游戲。擁有像fungus以及其它故事/游戲創造支持工具真的很酷。

6.更多資產掃描。創造更多支持自動轉移的文本。思考：本土化playmaker文本。資產掃描器的設置是為了幫助解決編輯器腳本撰寫的粘滯位問題，ICustomProcessors只是處理GameObjects將功能延伸向全新的腳本類型。

隨著越來越多人使用工具，我們的目標便是根據新識別的用例而繼續完善它。

總結

以上是生活随笔為你收集整理的Unity开发者如何有效地进行本土化的全部內容，希望文章能夠幫你解決所遇到的問題。

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