Alconost CEO:手遊本地化需要注意的10條規則
圖源網路
本文作者是Alconost的CEO。Alconost是一家為應用、遊戲、以及其它軟體提供本地化服務的公司,業務涉及70多種語言。Alconost還為Google Play和App Store製作廣告、教育視訊,還有圖片、解說詞和預告片等等。
我們能夠寫出這篇文章,得益於我們客戶提出的不計其數的問題——我的遊戲哪裡有問題?本地化做到這種程度還不夠嗎?應該如何解決呢?
在剛開始做遊戲時,很多人都會採取最省錢最省時間的方法。如果你不打算循序漸進地增長,這甚至還算得上是一個高效的策略。
然而,期待已久的本地化版本一切就緒之後,大多數遊戲開發商才開始思考如何才能吸引更多海外玩家。自己的遊戲在更多國家發行後,或早或晚他們就會提出幾個與本地化相關的點子。
首先我們要明確——本地化的意思是將使用者介面翻譯成目標語言,並根據文化、宗教和政治因素進行調整,從而迎合某個國家或地區的市場需求。
要強調的是,本地化是為了“解釋”,而不是“改變”。
舉個例子,某遊戲中包含了一個關於英語民間故事角色的笑話,翻譯成德語時,本地化的處理方法應該是用在一個在德國廣為人知的笑話來代替。但是,如果使用者介面中沒有足夠的空間來容納文字量較大的德文文字,有時就需額外花費更多精力。
另一個體現本地化涉及之廣的例子是數字的翻譯。比如說,在美式英語中,有些時候就要求用單詞來表達數字,不能用阿拉伯數字。其他地區的本地化可能需要注意數詞與名詞的複數單數形式保持一致。例如在俄語中,單複數還存在一些特殊情況,而日語和漢語中則沒有複數形式。但是,如果數字和文字是以硬編碼的形式存在於遊戲的靜態影像中,僅僅翻譯是不夠的。
這兩種情況還只是冰山一角——在本地化過程中,你還會遇到各種各樣跟本地化無關的問題。有些人稱之為偽本地化或者國際化錯誤——指的是一些本可以預測和避免,但需要開發人員花費很多精力才能解決的問題。
這就是為什麼Alconost公司為開發人員羅列出了一份規則,讓他們在專案啟動時就按照這些建議走,以便在開發過程中可以輕鬆一些,為本地化早早打好基礎。
1.提前選擇本地化語言
我們之前寫過一篇關於APP本地化工作流程的文章,行動清單的第一項就是“評估你的潛能”,我們現在也要做這件事。
你可能會反對說,在一款遊戲真正上線之前,你不可能預見到所有潛在的市場。嗯,這在一定程度上是正確的:你得先用非本地化版本做個測試,看看使用者的反響,然後你再進行本地化。但是,你並不用每次都按這個步驟來。
首先,你的遊戲可能包含了太多文化和地域方面的禁忌,如果沒有本地化,即使遊戲敘事一流,你的遊戲也會被拒之門外。
所以在遊戲製作開始之前,預測潛在市場的最好辦法是什麼?
分析競品的本地化。一般來說,如果競爭對手的遊戲在某一市場上找到了肥沃的土壤,那麼你也有很大的機會那裡獲得成功。
從遊戲型別角度出發,評估一下本地化的效果。例如,如果你是一個獨立開發者,正在考慮發行一款復古風格的roguelike遊戲,你可以通過觀察成功的同類遊戲來確定哪些市場是比較有前景的——比如說《地痞街區》,已經被本地化成七種語言,外加英語。另外一種辦法就是從地域角度去分析。比如說電子遊戲是日本文化中不可分割的一部分,那麼開發初期你可能就要把日本列為目標市場了。
研究本地化需求最強烈的那門語言。說到這裡,你可能想看看我們之前在 “Best Languages for Game Localization”[1]一文中的研究報告。
我們的“0號規則”是儘可能地將英語作為遊戲的源語言。我們建議在開發的第一天起,就要考慮兩個本地化方向。這兩個“預設”方向就是英語和你的母語(如果不是英語的話)。這種方法有幾個無可爭辯的好處:第一,以後可以將英文作為源語言翻譯,這有助於確保遊戲的一致性。第二,一開始就準備兩種語言,這會讓你提前認識到本地化前期工作中的所有陷阱。到時遊戲擴充套件到20種語言,你就會熟練很多了。
2.為目標語言調整介面
在設計介面元素時,人們一般會為其它語言文字留出30%的空間(甚至更多,如果能夠做到的話)。這對短字串尤其有用(選單選項、UI等)。
但是,我們還有更好的方法。如果你已經考慮到了規則1,並且有了一個初步的目標語言列表,那麼我告訴你一個很有幫助的方法:為最棘手的語言設計介面。
就比如說,德語的文字量一般都會比英語多平均30%,俄語是10%。阿拉伯語也是這種情況。另一方面,繁體中文所佔用的空間一般比英文少30%。
再說到位元組,一個拉丁文字母等於一個位元組,但西里爾文和阿拉伯文是兩個,你在規劃資料儲存時也需要考慮到這一點。
3.不要把字串直接嵌入到程式碼中
轉換文字進行本地化,會導致這些硬編碼字串丟失。記住這條本地化規則:每一個可本地化的字串都應該是可編輯的,不要觸及任何程式碼。
實際上,為了本地化而做的這些工程都可以被歸結為“國際化”,簡稱“i18n”——指讓產品無需做大的改變就能夠適應不同的語言和地區的需要。從程式角度來說,就是在不修改內部程式碼的情況下,能根據不同語言及地區顯示相應的介面。
另一個重要的技巧是避免用簡單的單片語成欄位。某位谷歌程式設計師給我們提供了這樣一個典型例子:
- 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是最常用的,而且是空間利用率最高的編碼。所以,請確保你的輸入檔案沒有出現編碼錯誤。
關於這一點,我們就先講到這裡了。詳細的編碼教程,你可以看看“Where Do Mojibakes Come From? A Smart Guide to Encodings”這篇文章[2]。
8.如果已經為本地化做好準備,你可以試試偽翻譯
當你把上面所講的技術方面的事都搞定了,你可以試執行看看。網路上有很多很棒的偽本地化工具,可以將你的介面模仿成外語介面,包括調整文字長度、檢查編碼和硬編碼字串。
這些工具基本上都會執行一個模仿目標語言的指令碼,並生成一個測試版本,然後必須在常規流程中作為非本地化版本進行QA測試。
這種提前測試並不是什麼靈丹妙藥,但是的確很有幫助。而對於開發者來說也是一件很有趣的事。
9.早點製作術語表
術語表是遊戲內專有詞彙和概念的整合,在遊戲中必須保持前後一致。這些詞彙主要包括物品、人物名稱、器物和屬性狀態。
保持術語翻譯一致是非常重要的,試想一下,如果某個遊戲內的東西在一個地方被翻譯成 “藥水”(potion),在另一個地方被翻譯成 “靈藥”(elixir)——你在無意中為玩家制造了額外的邏輯難題。
圖源網路
10.準備好提供上下文
確保本地化團隊有充足的上下文資訊可以參考,這一點的重要性不亞於製作術語表。從我們的經驗來看,譯員、本地化專案經理和遊戲開發者之間的充分交流有助於語境的建立。
我們意識到要讓開發團隊做到24小時待機是很難的。然而在本地化階段,我們的建議是指定一個代表作為聯絡人——錯誤或模糊不清的語境確實會對本地化的最終結果產生很大影響。
除此之外,本地化工作流平臺主要是根據客戶的喜好來選擇的,這樣是為了最大程度地保證溝通的便利和高效。
充分的準備工作最終會讓你看到好的結果。
我們希望這些簡單的規則、建議能對你的遊戲開發有所幫助。祝你能夠取得輝煌成功,讓玩家們沉浸其中!
引用文獻:
[1]Best Languages for Game Localization
https://medium.com/@Alconost/best-languages-for-game-translation-836c467db417
[1]Where Do Mojibakes Come From? A Smart Guide to Encodings
https://medium.com/swlh/where-do-mojibakes-come-from-a-smart-guide-to-encodings-fa96de357123
原作者:Alexander Murauski
譯者:Willow Wu
來源:遊戲邦編譯
原譯文:
https://gameanalytics.com/blog/10-rules-mobile-game-localization.html
相關文章
- Python命名規則是什麼?需要注意哪些事項?Python
- Codd的ER模型12條規則模型
- 開發60條規則
- 關於遊戲本地化的13條建議遊戲
- [譯] 設計研究的 9 條規則
- Salesforce架構的10條原則Salesforce架構
- 判斷條件為空時需要注意
- 20條IPTables防火牆規則用法!防火牆
- 網站效能優化:雅虎35條軍規及其可測的23條規則網站優化
- 10個需要注意的SQL問題SQL
- 【外貿建站規則】外貿網站建站流程有哪些?需要注意什麼? (上)網站
- 【外貿建站規則】外貿網站建站流程有哪些?需要注意什麼? (下)網站
- 解決問題的三條規則 | Yonatan Zunger
- 遊戲設計的11條原則遊戲設計
- 【小白學演算法】10.遞迴的呼叫機制、使用時要注意的規則演算法遞迴
- 網站建設需要注意哪些設計原則網站
- 手遊開發者談遊戲營收模式設計中的最重要規則遊戲營收模式
- RationalDMIS7.1 定義校驗規需要注意的地方
- 建立堡壘機的原則有哪些?需要注意哪些方面?
- 為PC和主機遊戲製作手遊版本,你需要注意些什麼?遊戲
- 資料架構需要遵守哪些規則呢?架構
- SQL稽核 | SQLE 如何開發一條自定義的規則SQL
- 重構複雜條件的規則設計模式 - levelup設計模式
- 正確使用資料架構的五條規則 - infoworld架構
- 提高遊戲留存的14條黃金法則遊戲
- 遊戲UI設計的3條重要原則遊戲UI
- 請問模型的欄位的高階的驗證規則和自動完成規則怎麼填,我需要用自己的規則怎麼弄模型
- 寫給工程師的10條精進原則工程師
- Oracle vs PostgreSQL,研發注意事項(10)- PostgreSQL資料型別轉換規則#2OracleSQL資料型別
- 10.使用隱含規則
- $.ajax(),$.get(),$.post()的區別,以及一些引數注意規則
- Laravel 8.55 新新增了條件驗證規則Laravel
- 寫出一手爛程式碼的19條準則
- 微信小程式開發需要注意的一些規範微信小程式
- 遊戲規則的制訂者就真的懂得“規則”與“樂趣”間的關係嗎?遊戲
- 每個遊戲都需要的十大元素(上):目標、規則、互動、翻盤遊戲
- 寫給前端工程師的10條實用原則前端工程師
- Go 需要注意的坑Go