在目前的市場環境下，相信對大多數研發來說，出海已經成為在立項時就不得不考慮的事情；而不是像以前一樣，產品做出來了再看情況。那麼在立項時就需要針對出海考慮諸多問題：玩法類型、題材、畫風、目標市場、語言本地化等等。本文主要針對語言本地化，提出一些在研發過程中的注意事項，以便於在日後實施本地化的過程中能夠儘量避免問題、利於本地化人員理解、提高本地化質量。
超框問題
對研發和本地化人員來說，文本超框是最頭疼的問題。超框的首選解決方案是縮文字；實在沒辦法縮，研發才會考慮調整UI。但是文本不是你想縮，想縮就能縮。而且很多情況屬於「可縮可不縮」的模糊範圍。什麼意思呢？舉個例子：某裝備的描述由該裝備的故事（世界觀部分）和作用（功能部分）組成。如果說裝備描述是80-90中文字，而UI只能顯示下100中文字，那絕大多數語言是顯示不下的。而如果不能調整UI，那麼只能在保證功能描述完整的情況下，對世界觀描述部分進行簡化。還有一種情況是，犧牲一定的語法正確性和採用並不常用的縮寫來縮短文本。玩家結合遊戲能夠勉強看懂，或者猜出來，但是會有一種蹩腳和山寨的感覺。
所以很多情況下「將文字縮短到符合空間長度」存在一定的信息丟失和對精準表達的妥協。你認為世界觀很重要，那麼就要調整UI；你認為不重要，那麼縮減也無所謂。你覺得玩家能看懂就行，有點小錯無所謂，或者只要不超框，界面難看也無所謂，那麼不調整UI也行。
哪些地方不能妥協，哪些地方可以妥協，妥協的度是多少，需要雙方協商和把握。在必須縮文本的情況下，選擇保留哪些信息，捨棄哪些信息，也考驗本地化人員的功力。
更別提很多界面即使文字不超框也很難看。
所以最好的解決方案還是在研發過程中就合理設計UI，避免超框情況的發生。超框問題是本地化中最明顯的坑，但就我們在各種項目中遇到的各種坑來說，它只是冰山一角。下面就說說可能會踩哪些坑，並提供一些怎麼避免這些坑的思路。
UI設計
針對上文提到的超框問題，最好的解決方案是在UI設計的時候就考慮到多語言適配的需求。有哪些要點？我們先看幾個結論：
英文長度越短，翻譯後長度增加的概率和比例都會越高。某些單詞三倍於原英文長度的情況並不少見。
以上數據並不嚴謹，但不影響結論的大致正確。結合資料和我們做項目的經驗，總的來說中文原文翻譯為不同語言的長度為：中文<阿語<韓語<日語≈泰語<英語（中文*130%-200%）<越南語、印尼語、歐洲主要語種<德語（英語*110%-150%）。
特別注意，常規文本的日語長度比英語短。但日語大量的名詞使用假名，這使得一些名詞和短語的長度反而超過英語，設計的時候需要留意。以幾個手遊的名字為例：
Monster Strike
モンスターストライク
Dragon Ball Z Dokkan Battle
ドラゴンボールZ ドッカンバトル
Girls』 Frontline
ドールズフロントライン
Langrisser
ラングリッサー
注意，以上結論是基於統計的概念得出的。對於具體某個文本來說，某種語言比英語究竟是長還是短，不確定性增大。所以最好還是有內部的多語言團隊，在UI設計階段即提供本地化協助。在沒有多語言團隊的情況下，有以下幾點建議：
左右滑動查看，對比英語和德語版本，注意餘量和文字長度的變化。
左右滑動查看，對比中、英、德語版本，注意餘量和文字長度的變化。
如果怕界面太空曠，不想留太多餘量，也可以同時輔以自適應字體大小、字符間距以及自動換行的機制，彌補這種顯示空間上的差異。這樣不至於為個別超長的單詞而將整體的字體縮小，美觀度上也幾乎無影響。
點擊查看大圖，可看出字體大小的差異。
對於較長的文本，留有30%-50%的餘量即可。
紅圈部分，文字底板的長度可以隨著
文字長度而變化。
CR英語版本。對比右圖。
CR德語版本。對比左圖，描述變長，
但懸浮窗高度也增加。
左右滑動查看。
原中文是福字。
多語言的UI設計是非常專業的領域，這裡僅提供一些思路和參考，就不班門弄斧多展開了。
語言包結構和key值
先表達一個觀點：遊戲本地化的過程雖然大部分工作是翻譯，但它絕不僅僅是翻譯。不是你給我文本，我把文本翻譯成對應的語言就完事了這麼簡單一個過程，所以我堅持叫它本地化。如果說純文本的翻譯是連續一維的（文字），影像類的翻譯是連續二維的（文字+影音），那麼遊戲的翻譯就是非連續三維的（文字+場景+遊戲邏輯，且文本被打散）。影像類的字幕，如果只根據文字內容翻譯，那麼會丟失說話人的場景、表情、語氣等信息。而遊戲文字的翻譯，除了文字表面的意思，還要考慮它出現的場景和遊戲邏輯。
場景是文本出現的場景和位置。不同場景甚至導致相同原文不同翻譯，舉例：
我在以前的文章中提到過，不同場景的文本需要不同的大小寫規則（無需額外成本，產品逼格即可靠近歐美產品一步）。
獲得金色英雄。可以是Gained a Golden Hero（玩家獲得了一個金色英雄），也可以是Gain a Golden Hero（成就要求玩家獲得一個金色英雄）。
可以解鎖水瓶座聖衣。可以是Used to unlock Aquarius Cloth.（道具描述，可以用來解鎖水瓶座聖衣），也可以是Aquarius Cloth can be unlocked.（提示，水瓶座聖衣可以解鎖了）。
立即完成，如果是按鈕，那麼應該是INSTANT（全大寫）；如果是彈窗標題，那麼應該是Instant Completetion。
遊戲邏輯是文本和其他文本或功能的邏輯關係。文本的翻譯不僅跟自身內容有關，還決定於這些邏輯關係。舉例：
某模擬經營遊戲有兩個建築「面點屋」和「西餅屋」，不是太好通過直譯區分，其實都是屬於Bakery。進一步看兩個建築生產的東西和信息，其中西餅屋是在更高級解鎖的，生產的東西也更高級，屬於「高配版」的「面點屋」。那麼「面點屋」翻譯為Bakery，「西餅屋」翻譯為Adv. Bakery既說得通，又能一眼看出建築的功能和層級關係。
泛泛之交、相見恨晚、志同道合、肝膽相照、莫逆之交、生死不棄，看著比較像稱號一類的東西，但非常難用簡短的英語直譯。進一步看，是用於表示和好友的親密度。既然是表示層級關係，而不是別的描述性文本，就可以用黑鐵、青銅、白銀、黃金、白金、鑽石的方式來表示。這種情況下，必須知道正確的層級排序才能正確本地化。
只看遊戲文本進行純翻譯，很容易出現問題。有些文本，提前了解遊戲，再加上譯員的遊戲和本地化經驗，能判斷出場景和邏輯；有些文本，則需要研發進一步說明，而這種情況並不少。
但是本地化人員不可能每遇到一條存疑的文本，就和研發溝通，這樣會大大降低效率。那麼建立良好的語言包結構，採用key值來展示它的場景和邏輯就非常重要。具體有以下幾點建議：
儘量把所有文本設計為程序字，而不是圖片文字，尤其是多語言同服的產品。
儘量集中維護文本，不要放在太多文件中，更不要把文本內容直接寫在腳本/程序中。
將專有名詞類、遊戲通用的文本等同類型的文本歸類。例如，所有英雄/技能/道具/關卡等在一起。所有復用程度高的按鈕/彈窗標題/伺服器提示文本在一起，例如：確定，取消，重試，購買；XXX不足，是否使用XXX購買XXX等。
剩下的文本，按照各個功能模塊劃分，將所有屬於同一模塊的文本按一定邏輯順序放在一起。例如抽卡系統中涉及到的所有文本。
結合以上兩點，採用具有邏輯性的key值說明文本的用途。
針對第3點，例如：
lan_hero_1_name
lan_hero_1_des
lan_hero_1_skill1_name
lan_hero_1_skill1__des
lan_hero_1_skill2_name
lan_hero_1_skill2_des
lan_hero_1_ultiskill_name
lan_hero_1_ultiskill_des
很容易看出是id為1的英雄的名字、描述、小技能1及其描述，小技能2及其描述，大技能及其描述。那麼本地化人員就能根據key值基本還原這個英雄的背景、特點和能力類型，在翻譯的時候可以互相參考。
針對第4點，例如：
lan_herodraw_junior_title：招賢納士
lan_herodraw_senior_title：神將降臨
lan_herodraw_junior_btn1：免費
lan_herodraw_junior_btn2：抽一次
lan_herodraw_junior_btn3：抽十次
lan_herodraw_junior_btn4：確定
lan_herodraw_junior_txt1：今日免費次數：{0}/5
lan_herodraw_junior_txt2：{0}後免費
lan_herodraw_junior_popup_title：鑽石抽將
lan_herodraw_junior_popup_btn1：確定
lan_herodraw_junior_popup_btn2：取消
lan_herodraw_junior_popup_txt1：確定花費{0}鑽石進行一次招賢納士？
lan_herodraw_junior_popup_txt2：確定花費{0}鑽石進行一次招賢納士十連抽？
這樣整個功能結構和邏輯關係都比較清晰瞭然。
注意，重複文本在不同場景的翻譯可能不同，不要調用同一條文本，要使用不同的key值區分。例如上文中的「獲得金色英雄」，如果是玩家獲得了英雄，用lan_herodraw_gainhero_msg；如果是任務要求，用lan_ achive_1_req。
另外，也可以在程序端增加根據key值後綴將文本轉換為全大寫的邏輯。比如後綴包含btn的文本不管原文如何，全部轉換為大寫。
當然，即使語言包結構再好，它也只是純文本，無法展現所有信息。這就是為什麼熟悉遊戲和LQA重要的原因。
文本內容原則
以下是關於文本內容的一些具體原則：
例1：完整的句子是「是否花費{0}進行購買？」，不要切割為兩條文本「是否花費」和「進行購買？」再用程序拼接。
例2，原文是「{0}後刷新」，很多研發會在語言包中將變量摘出去，文本只保留「後刷新」。正常的英語翻譯是Refreshes in {0}；變量摘出去之後，根本沒法處理。我看到有些遊戲顯示為類似23:59later refreshes，語法完全錯誤，而且缺乏空格。
以上例子的意思是：不同語言的語序千差萬別。如果一條文本是一個完整的表達，那麼本地化人員可以對語序和其中的變量位置靈活地進行調整；如果文本被切割，拼起來之後可能就有語法錯誤了，特別是變量被摘出去之後，變量的位置本地化人員無法控制。另外還容易造成空格的缺失，因為中文字直接拼接起來就行了，而絕大多數語言單詞之間需要空格。
貨幣。在不同國家運營涉及不同的貨幣和數值，建議所有涉及到的文本不要寫死，在文本中完全以變量的形式體現，由策劃配置。比如「首充6元即可獲得」改為「首充{0}{1}即可獲得」，「累計充值1000元獲得」改為「累計充值{0}{1}獲得」。
折扣。非常奇怪，貌似全世界的語言說打九折都是10% off這樣的邏輯，只有中文是反過來的。所以如果表示折扣的文本，千萬不要將數字和「折」拆開；如果用變量的話，例如{0}折，最好新加一個{0}% off的文本。
周、月。很多研發把周和「一二三四五六七」拆開，這就沒法處理了。除了越南語有著和中文類似的邏輯外（但是越南語周日不是周+數字），其他語言都是跟數字無關的。月份也是類似的情況。籤到特別容易出現這個問題（「{0}月籤到」就沒法處理）。所以語言包中需要將周一到周日，一月到十二月一一列出來。
順序和次數。對於類似「第{0}次」這樣的表達，英語是」1st，2nd，3rd，4th」（尾數1+st，尾數2+nd，尾數3+rd，其他+th）；因為變量有可能是1、2、3、4，所以沒法處理。所以類似文本建議針對尾數為1、2、3和其他分別有一條文本（都是「第{0}次」），並通過key值加以區分和說明。
日期格式。不同國家有yyyy-mm-dd，dd/mm/yyyy，mm/dd/yyyy幾種順序（還有中間的連接符和使用yyyy還是yy的細節差別，可能沒有那麼嚴格了）。所以不要把一個日期拆成「年「、」月「、「日「再和數字拼接，保持文本的完整性讓本地化人員可以自行調整順序；另外由於使用英語的國家的日期格式也不一樣，比如08, 07, 2019對美國來說是8月7日，對大英國協國家來說是7月8日；為了避免歧義，最好調用一月到十二月的英文（Aug 07, 2019），而不是簡單使用數字變量。
大部分國家的阿拉伯數字需要千位分隔符。比如中文1000就可以，英語是1,000，其他國家分割符略有不同。不光是本地化人員需要注意，程序處理數字變量時顯示格式的時候也要注意。
不要用W代表萬，可能會引起誤解；也儘量不要用變量+「十、百、千、萬」表示數字，否則「{0}萬「要改成「{0}0k」，部分本地化人員可能會出錯。
不要用換行符在一個句子內進行強制換行來進行格式的調整（這種情況偶爾會遇到）。中文換行的位置，對於其他語言來說就不適用了。讓程序來處理換行的問題。
術語管理
之前的文章說過術語的重要性（出不出海都要做好的術語管理）。在中文版本開發過程中，就要注意術語的正確使用。術語的使用普遍存在三個問題：
沒有規範名稱。策劃在文案中經常使用業內的通俗說法，或者自己偏好的叫法。例如：明明英雄在遊戲的世界觀中使用了比較高逼格的名字，比如神器使，但是策劃在部分文本中將其稱為英雄；明明是叫使團，但是有的地方叫公會，有的地方叫聯盟。還有英雄<->角色、抽卡<->招募、副本<->關卡、寵物<->寶寶、種族<->陣營等等等等容易搞混的稱呼。
在開發過程中，術語有改動，但是沒有將所有關聯文本中的術語修改為最新。
術語的錯別字，有時候容易造成誤解。之前舉過影舞者/影武者的例子，中文玩家能看出來是錯別字，但是英文經過翻譯之後，就完全是兩個東西了：Shadow Dancer/ Shadow Fighter。
到目前還沒有遇到過術語使用特別規範的項目。經驗豐富，有意識的本地化人員會特別注意以上問題，並且和研發進行確認；如果意識不到位，或者抱著「我就照著原文翻譯又沒有錯」的態度，很容易在翻譯之後把問題放大。
所以最好儘量保證原文的術語正確，這裡提出來一些解決方案供參考：
文本內容的管理
類似於術語，語言包需要注意以下幾點：
錯別字，語句通順，易讀性，是否有歧義等。特別是長段的玩法規則，很容易描述不清。建議策劃寫完文本後給其他人讀一讀，看是否能讀懂或者存在歧義。
功能不斷迭代開發，優化或刪除功能的同時需要對相應的文本進行修改、刪除，否則不光是平白增加翻譯成本的問題，還會給本地化人員造成誤解。
儘量簡潔，兩個原因：玩家也不願意讀大段的文字，減少超框可能性。
總結
可以看到語言本地化的坑還是很多的，經驗、意識和責任心不足的本地化人員很容易忽略這些坑。本地化的質量不僅和譯員相關，和研發提供的語言包的質量也有很大關係。以往更多的是發行會關注本地化的坑，而研發是脫節的，等到產品做出來其實問題已經很多。在開發的時候注意到以上問題，可以打下一個良好的基礎，本地化人員可以避免很多問題，處理的時候也更加遊刃有餘。當然，仍然需要熟悉遊戲和進行遊戲語言測試才能打磨出良好的本地化質量，同時整個本地化過程也需要研發良好的支持和溝通。不要嫌麻煩，誰讓現在出海這麼重要呢？
另外如果目前的語言包可能存在以上的問題，那運營人員/本地化管理人員需要針對以上的坑進行額外的關注。
立項階段的本地化諮詢還不是一個成熟的商業模式，但我們非常有興趣在早期就參與進來。如果有CP有興趣的話，可以聯繫我，我們一起摸索看看。
可能是最懂遊戲的本地化
- 長按識別關注 -
----
無需額外成本，產品逼格即可靠近歐美產品一步
出不出海都要多好的術語管理
立新年Flag的正確姿勢
大哥，要LQA嗎？
本地化沒做好？先檢查下自己有沒有「渣男體質」
遊戲行業寒冬，非資深從業者一咬牙，淪為....
12款出海遊戲本地化評測，您的遊戲是什麼水平？