對于一名游戲開發(fā)者來說，本土化總是不能出現(xiàn)在適當?shù)臅r候。不管我們是否在一開始進行設置，因為我們認為這是正確的方法，但是緊隨其后游戲便遭遇了失敗。或者即使游戲表現(xiàn)得不錯，我們也必須嘗試著明確如何將其放置在之后的過程。我已經(jīng)將這個問題放在之后的問題集分類中：如果這是你所面對的問題，那么這便是你需要為此花錢去解決的問題。

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

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

本土化的障礙：

1.提取文本并將其放在數(shù)據(jù)儲存區(qū)進行翻譯

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

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

4.重新將儲存于數(shù)據(jù)儲存區(qū)的文本整合到你所選擇的UI解決方法中

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

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

7.在發(fā)現(xiàn)短語未翻譯時獲得新的翻譯內(nèi)容

什么是正確的：

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

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

3.簡單的儲存格式。最初，我將數(shù)據(jù)格式與專用格式綁定在一起，認為這么做會方便許多。ScriptableObjects是并未存在于場景中的基本游戲?qū)ο蟆Ｋ鼈儗⒃谶\行時間中獲得同意的優(yōu)化，并在與別人合作時呈現(xiàn)出YAML合并友好型特質(zhì)。確保界面就像一本簡單的詞典，并且在處理之后出現(xiàn)的各種簡單任務上允許更多靈活性的出現(xiàn)。

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

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

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

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

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

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

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

未來的工作：

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

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

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

4.支持更多UI框架—-它們帶有許多相關聯(lián)的不同挑戰(zhàn)。

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

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。