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

 

Localization(from agencypost)

 

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

 

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

 

本土化的障礙：

 

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

 

2.刪除任何關(guān)于文本的簡單引用（在場(chǎng)景和預(yù)制件中）并用純粹的腳本控制文本進(jìn)行替代

 

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

 

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

 

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

 

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

 

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

 

什么是正確的：

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

未來的工作：

 

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

 

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

 

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

 

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

 

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

 

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

 

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