關于全球化設計的系列設計文章。主要分為以下三個部分：

• 快速入門，聊聊幾個最常見的全球化設計問題，感受一下基礎概念。
• 國際化設計，設計一個健壯的國際化產品需要的詳細注意事項，避免踩坑。
• 本地化設計，按照幾大地區進行基礎情況、市場情況、文化情況進行簡介，當你需要為一個新的國家/地區進行設計時，有助于快速了解區域情況。

上期回顧：《全球化設計系列！從這四個方面快速入門全球化設計》

• 本篇文章與快速入門的內容會有重疊，前篇著重普及入門，本篇著重系統化深入思考。
• 本篇文章與快速入門不同，是動態更新的最佳實踐。
• 本篇文章著重于產品設計部分，開發和運營方面僅提及必要的部分。

國際化設計

Internationalization，簡稱「i18n」，是指產品不依賴于特定區域，能夠在各區域下正常運行，不出現嚴重影響使用的錯誤。常見如軟件亂碼、界面錯位、數據結構不支持等等。

優秀的國際化產品，能夠讓產品在移植到其他區域時能夠快速而健壯的使用，例如 Google 搜索、Facebook 并不需要到一個新地區就重新開發一個版本。

如果你投身于全球化的產品設計，主要需要從 5 個大方面進行思考：

• 語言文字
• 用戶界面
• 文化差異
• 地區標準
• 開發技術

即便你正在設計一款不那么全球化的產品，思考這些問題仍能夠使你的產品更健壯。

一. 語言文字

支持目標市場的語言文字是進入該市場的先決條件，雖然某些市場只需要丟一個英文版本就萬事大吉，但這還遠遠不夠。

主要問題有：

• 如何理解語言、文字、區域的概念？
• 如何設計選擇語言的機制？
• 在語言前面加上國旗圖標是好的選擇嗎？
• 如何設計 RTL 語言（如阿拉伯語、希伯來語）的用戶界面？
• 某些語言有不熟悉的文法體系，比如復數、陰陽性該如何處理？
• 標點符號不是國際通用的？
• 在某些文字體系中，難以對內容進行排序或首字母分組。

語言、文字、區域

語言、文字和區域是三種不同的概念，比如：

• 漢語，采用簡體漢字書寫，用于中國大陸
• 葡萄牙語，采用拉丁字母書寫，用于巴西
• 英語，采用拉丁字母書寫，用于美國
• 印地語，采用天城文書寫，用于印度

了解這些有助于避免發生一些低級錯誤，以及理解語言方面的最佳實踐——語言識別標簽：

• zh-Hans-CN
• zh-Hant-HK
• pt-BR
• en-US
• hi-IN

在介紹各個區域本地化時將描述標簽選擇方法。

在設計產品時需要考慮兩個部分的本地化展示：

• 界面文字，如「登錄、評論、首頁」等用于產品功能的文字，它們相對穩定。
• 內容文字，如「塞爾達傳說曠野之息出官中了！買爆！」等由用戶或媒體發布內容的文字，它們一般不受控制。

△ 界面文字為中文，內容文字為英文

1. 界面文字

最主要的是界面文字，能夠以該文字顯示界面，一般就可以宣稱支持對應的語言了。

毫無疑問的，支持國際化的第一步是支持英文。

最佳實踐 1.1.1

請把英文作為產品無法匹配語言時的默認語言，也應當以英文版本為基本款進行設計。

這有助于你在第一時間覆蓋最廣泛的區域，并且規避一些全球化的問題。

在用戶切換語言的機制方面有兩種選擇：

• 跟隨系統設置。
• 能夠在應用內部自主選擇界面語言。

跟隨系統設置是一個較為保險的方案，Facebook、Google等產品一般都選這個方案。

但一般產品難以覆蓋足夠廣的語言，并且從用戶的角度來看，一旦系統語言未匹配，還有自行更改為用戶第二語言的可能，這樣更為靈活。

最佳實踐 1.1.2

應用內自主更換語言更能滿足設計和用戶的需求。

但是要避免一些迷之問題：

△ 怎么切成中文？Language 是什么意思？

最佳實踐 1.1.3

不要采用旗幟圖標指示語言。

△ 我是葡萄牙人，只能選擇巴西國旗的葡萄牙語？

存在有幾個問題：

• 難以讓旗幟和語言一對一映射；
• 用戶可能被迫需要選擇一個他國前綴的選項；
• 可能引起地緣政治的爭議；
• 旗幟可能隨著時間的發展而被替換，有更換成本。

雖然旗幟圖標在選擇效率上會略有提高，但仍然不建議使用。

但也有例外：

• 當本質上是選擇區域時，例如 Apple 官網。

2. 內容文字

在國際化方面，產品的內容文字由用戶自由決定，一般不受限制也沒有必要限制。從運營角度，可以考慮按照地域進行內容劃分隔離，以便更有效地傳播內容。

當然也可以像 Facebook、Twitter 或是 Google Play 一樣提供內容輔助翻譯。

點擊「翻譯自英文」后，系統會將內容翻譯為本地語言提供。

或者由用戶自行選擇內容來源。

△ Twitter 可自行更改內容源

3. 書寫順序

最佳實踐 1.2.1

全球化的產品應當能正確處理 RTL 語言。

△ 阿拉伯語示例文本

RTL（Right to Left，從右到左）語言指的是從右側向左側書寫的語言。

這些語言包括：

• 阿拉伯語
• 希伯來語
• 波斯語
• 烏爾都語
• 意第緒語
• 迪維西語

語言的普遍特征有：

• 句子從右到左閱讀
• 事件發展順序從右到左進行
• 左箭頭 ← 表示向前運動，右箭頭 → 代表向后運動

使用這些語言的人口數量相當大，特別是在波斯灣地區由于石油經濟發展特別迅速。對于面對中東地區出海的產品，是不能回避的問題。

針對 RTL 語言的通用設計原則有：

• 在代碼中聲明 RTL
• 將整體界面左右鏡像
• 左右箭頭代表的前后含義相反
• 涉及方向的圖標需要鏡像
• 文本資源基本右對齊
• 不進行鏡像的有，不傳達方向的圖標，如 Email；LTR 數字、不需翻譯的外文；圖像、時鐘、擬物、禁止符

至于某種特定的語言情況，會在對應的本地化部分提及。

4. 文法

復數與陰陽性

相信你已經了解了英語的復數情況，1 book 與 2 books 的單詞形式不同。如果每一個涉及數量的單詞都使用 if 來判斷實在是過于繁瑣，更何況還有更復雜的復數情況：

△ 俄語名詞變格表

完美匹配世界上所有語言的文法幾乎是一項不可能完成的任務，不信來看 Language Plural Rules ，這里記錄了絕大部分常用語言的復數、序數以及數字范圍規則。

好在系統平臺已經提供了相當完善的接口，配合本地化團隊可以滿足文法需求。

最佳實踐 1.3.1

優先調用系統級的本地化字符串處理函數進行處理。

請聯系你的開發人員查看以下本地化字符串文檔：

• iOS：Localizing Your App - Handling Noun Plurals and Units of Measurement
• Android：字符串資源 | Android Developers

概括來說，需要本地化團隊將對應的復數變化情況全部列出來，程序會根據接口獲取到數字所對應的語言復數情況。

<item quantity="one">%d song found.</item>

<item quantity="other">%d songs found.</item>

如果你的產品實在是不愿意在這方面投入資源，也有一些取巧的方法：

最佳實踐 1.3.2

勉強也可接受復數無關的界面排版模式，如 Message (10) 或者 10 book(s) 等。

不推薦。但如果完全不處理復數和陰陽性問題，將缺失語言本地化的重要一環。

大小寫

語言之間具有各種細微的差別，雖然看上去微不足道，但卻可能對產品和功能設計產生巨大影響。例如，在俄語中，一周中的名稱不能首字母大寫，如果將「星期三 среда」首字母大寫，含義就變為「環境 Cреда」，將「星期日 воскресенье」變為「復活 Воскресение」；或是英語中的「瓷器 china」與「中國 China」。

主要有以下情況：

• 某些語言的大寫字母與小寫字母不是一一對應的。例如，德語 ? 的大寫形式在印刷時代曾經是 SS（終于在 2017 年 6 月正式將單字符 ? 加入官方正字法中）或是希臘語中的 Σ 的小寫形式根據位置有兩種書寫形式 σ 或 ?。
• 有些字符根據語言不同，有不同的大小寫映射關系。典型的是英語中 i 對應的大寫是 I ，但在土耳其語中卻各有其大小寫： ? 與 I、i 與 ?，如果對 i 進行大寫轉換，那么一定要先判斷語言類型，再進行轉換。
• 大多數非拉丁字母不適用小寫和大寫的概念。例如漢字、諺文、泰文、阿拉伯字母等，如果強制對這類文字進行大小寫轉換，可能導致意外的字符或亂碼出現。

最佳實踐 1.3.3

不能僅用大小寫來傳達某種必要信息，例如，可供交互的按鈕還需要其他樣式標明。

△ Material Design 中要求按鈕將字母全部大寫，并同時要求其他語言需要用色彩進行區別。

最佳實踐 1.3.4

如果涉及到程序轉換大小寫的情況，務必需要先判斷語言類型。

5.?標點符號

△ 思源宋體在各語言下的問號

即便是代表同一含義的標點，在不同語言中可能有不同的展示形式或排版要求。特別是在不同語言情況下，對于標點的排版要求可能大相徑庭。

△ 逗號

某些標點在不同語言中樣式不同，如逗號：

• 簡體中文 U + 3001（居左下）
• 繁體中文 U + 3001（居中）
• 英文 U + 002C
• 阿拉伯文 U + 060C

某些標點使用方法不同，如西班牙文中的嘆號和問號需前后使用：

• ?Hola!
• ?Qué edad tienes?

某些標點不能放置于行首或行尾，如中文里逗號不在行首，前引號不在行尾；

某些語言不使用空格作為間隔，如中文、日文、天城文一般不用空格；

某些語言基本不使用或是很少使用標點符號，如泰文、天城文、文言文等。

最佳實踐 1.4.1

注意將標點符號轉換為本地方案，并特別注意換行時的標點位置。

總的來說，本節主要考驗的是本地化團隊。

△ 阿拉伯文 問號

6. 內容組織

由于語言大多使用不同的字符，將導致傳統的分類和排序出現意外情況。

△ iOS 日語、俄語通訊錄界面示例

請注意右側的快速預覽，在不同語言版本下，會根據各自語言情況進行調用。

換句話說，在涉及到字符排序或者首字母分組的情況下，不能僅考慮「A-Z」的規則。

最佳實踐 1.5.1

在排序和組織內容方面，請確保使用 Unicode 的規范化處理方式。

此外，還需額外注意以下影響因素：

• 多音字，如中文
• 變音符號、標記等，如法文、阿拉伯文等
• 多語言同時使用時，同一字符的不同代表含義

留個小問題：如何排序 ? ? ? ? ξ ж ほ ? ? ？

二. 用戶界面

在具體的界面設計上，設計師需要面對極其復雜的兼容性問題，考慮如何健壯地應用文字、圖片、視頻、組件等。

主要問題有：

• 本地化團隊難以處理嵌入式圖片、視頻中的文字。
• 由于文字長度不同、語法語序調整，組件變化幅度較大。
• 不同語言的文字形式長度相差較大，導致版式錯亂。
• 用戶有可能缺失預設的字體。
• 復雜文字很難找到小字號的字體。

1. 圖文分離

雖然我們可以為所有地區各自定制一個獨立的版本，但國際化設計的本意就是使一個設計結構能夠盡可能多的服務更廣泛的地區。

為了便于本地化團隊進行本地化處理，設計和開發應當將「本地資源」與「邏輯實現」相分隔，替換本地資源時必須不會影響系統邏輯。

△ 某產品的雙語版本，本地化資源易替換

最佳實踐 2.1.1

不要將文字直接嵌入圖片或視頻媒體中，應當分別以較小個體進行存儲，便于替換。

一般來說，圖片上的文字建議采用分層展示，也就是可以在不替換圖片的情況下，通過簡單替換字符串即可滿足需求。

特別的，此處的文字可以為柵格后的圖像（如上圖中的 LUNA ），在這里更關心在最小的影響下替換資源。

如果是特別為某個地區進行的本地化圖片，那不妨嵌入，沒有大礙。

最佳實踐 2.1.2

不建議復用同一資源，某些本地化資源也許并不能一一對應。

簡化的例子，「我」在英語中對應幾種說法：I / me / myself，也許在中文界面可以使用同一字符串，但對應的英語情況可能需要進行分別考慮。

△ 圖標之小，也需要替換

同時需要注意，盡量不要在圖標上直接應用文字，不但替換繁瑣，還有長度等限制。

2. 組件分離

通過拆解語句構成的用戶表單，在不同語言的文法系統下可能無法應用。

△ 請拒絕將組件與語句組合拼接

最佳實踐 2.2.1

文字與組件必須分隔排版，不使用基于語言元素的拼接組件。

△ 左側：組件與文字混排 右側：組件與文字分離

△ 某游戲的本地化問題

3. 文字占位空間

在國際化過程中最常見的問題是翻譯后的文字和預留空間之間的矛盾。

最佳實踐 2.3.1

為所有文字預留足夠的空間，并且設置溢出情況下的處理方法。

需要處理的問題：

• 定寬組件上的文字過長
• 變寬組件本身由于變化導致錯位
• 文字換行導致的錯位

直接縮寫或采用省略號「…」的方案并不友好。

最佳實踐 2.3.2

盡量采用簡潔的描述，并且提醒本地化團隊節約使用空間或設置限制。

△ 以漢字為參考，建議預留的長度

4. 字體字型

要避免用戶缺失產品預設的字體。

最佳實踐 2.4.1

界面文字盡量采用系統默認匹配的字體。

△ iOS 與 Android 常用字體

如果有必要，可以將特殊字體的文字轉換為圖像進行展示。

不是所有的字體都內含了粗體和斜體，雖然部分軟件或系統提供了算法加粗或傾斜，但效果較差。設計師并不能確保本地化后的文字是否有足夠品質的粗體和斜體，另外部分語言的強制粗體或斜體會導致可讀性下降，如不應當使用中文的斜體。

所以在設計原生版本時，也要少用粗體和斜體。

而下劃線除了推薦應用于網頁超鏈接中，本身就不太建議用于移動產品，更大的問題是不適合某些類型的文字，如內含基線的天城文。

最佳實踐 2.4.2

少用、慎用粗體、斜體、下劃線等樣式。

對于拉丁語系設計師來說，需要注意東亞文字 CJKV 一般由于字形復雜而難以找到較小字號的字體，通常 12 號是最低尺寸。

三. 文化差異

完全掌握理解各國家地區的文化既不現實也不經濟，在這里列出一些通用的設計限制框架。

主要問題有：

• 宗教、節日、文化、手勢的含義差異較大
• 涉及到僅母語者/當地人才能理解的內容
• 容易忽略各地圖標、圖像、顏色、文化隱喻的不同
• 某些含義可能無法在另一種文化中簡單的表達出來
• 涉及民族、地緣、宗教、政治的信息容易產生沖突
• 注意色情、暴力、癮品內容
• 用戶濫用平臺功能發布禁忌內容
• 當地法律法規或道德文化對隱私要求很高

1. 隱喻

有很多社會習俗、語言習慣是外鄉人不易理解的，能夠理解并熟練表達這些內容是能融入當地文化的表現。如果是一個本地化的版本，強力推薦你的產品這樣做；但在基礎的國際化版本下，則不建議使用。

△ John Doe 對于非母語使用者，一般不能 Get 到

例如 John Doe 或 Lorem Ipsum，或是更常見的 The quick brown fox jumps over the lazy dog. 都是作為拉丁語系設計師常用的內容，類似的，他們可能并不能理解「小明」「小強」「河蟹」「江湖」「桃花源」等用語。

最佳實踐 3.1.1

避免使用冷幽默、雙關、熟語、俚語等過于本地化的內容，少用術語、縮略語。

在圖形、圖像、色彩方面，設計師常用的隱喻也許并不能奏效，經常會有意外。使用異國文化、圖形圖像時注意收集本地化團隊建議。

△ 除了美國，世界上大部分郵箱不像這樣

最佳實踐 3.1.2

盡量采用各大平臺原生的標準圖標，或基于標準圖標進行重設計。

盡量采用通用的圖形圖像，讓本地化團隊有一定權限針對當地版本去更改，這樣的方案會更合適。

有一個配色小技巧，對于完全陌生文化的國家地區，可以參考其旗幟的配色。

在社會主義熏陶下成長的設計師可能很難意識到宗教力量對這個世界的影響，在中國，自稱無神論、不信教和信教的比例大約占被調查人數的 67%、23%、9%。如下圖所示，中國認為宗教占自己生活中重要地位的被調查者僅有 3 %。

△ 宗教是否在你生活中占有非常重要的地位，PEW 研究中心

而在世界大量國家地區中，宗教都占據了重要社會位置，再者有宗教派別引起的沖突，例如印度與巴基斯坦等。

舉例來說，「Merry Christmas！」有可能是一句冒犯的祝福，特別是對于猶太民族。在海外由于不確定他人的信仰是否和你相同，民眾通常會說「Happy Holiday！」，僅僅在非常確信對方信仰的前提下使用前者。

最佳實踐 3.1.3

避免使用宗教、神話相關的內容、標志、符號等。

身體和手勢從古就用于溝通信息，不幸的是和語言一樣，在不同文化中代表的含義有所不同。即便是豎拇指、V字剪刀手這類在本文化中正面含義的手勢，在其他文化中可能代表非常粗魯或否定的含義。

△ OK 手勢，在很多區域代表負面含義

最佳實踐 3.1.4

避免使用身體、手勢來表示含義。

2. 禁忌

第一個需要注意的是將所有的「國家 Country」改為「國家/地區 Country/Region」，同時不要使用旗幟作為圖標（見最佳實踐 1.1.3）。

在世界各個文化中，一般都有禁忌的內容，總體來說主要是宗教、民族、文化、習俗、地緣政治相關的內容。

最佳實踐 3.2.1

盡量避免涉及民族、地緣、宗教、政治的敏感信息，注意收集本地化團隊的建議。

△ 瑪麗安·米爾札哈尼，伊朗女性數學家。由于卓著的數學成就，逝世后破例在伊朗刊登不戴頭巾照。

△ 《Fight of Gods（諸神之戰）》操縱世界各地的神話人物進行格斗，在馬來西亞以「不符合當地宗教與種族團結法律」為由被禁。

在大多數國家地區，成人內容都將受到不同程度的限制，而和欲望相關的內容在不同地區的開放程度不一。

最佳實踐 3.2.2

不要使用色情、暴力相關內容，需注意賭博、癮品等內容。

對于內容生產的產品來說，需要采取措施對內容進行篩選過濾。

3.隱私

重點指明日本、韓國、美國、歐盟國家對于數據隱私問題特別看重。

• 日本

早在 1996 年，日本開始電子化政府運動時就開始著重保護數據隱私，在幾年間不斷完善和維護，在 2005 年《個人信息保護法》開始全面實施。

以致在社會風氣方面，一般民眾也非常注重數據隱私保護，具有極強的意識。

△ 游戲「陰陽師」日本上線后因隱私問題遭到抵制

• 歐盟

目前歐盟已經要求必須經用戶許可才能使用 Cookie 進行跟蹤。

經過 4 年的準備和討論，歐盟議會于 2016 年 4 月 14日批準通過《一般數據保護條例》，在 2018 年 5 月 25 日正式實施，屆時不滿足數據隱私要求的公司將面臨千萬歐元級別的重罰。以目前情況來看，達到歐盟要求的產品屈指可數。

△ General Data Protection Regulation，一般數據保護條例，歐盟

其他國家地區的隱私情況將在本地化部分提及，在此不贅述。

最佳實踐 3.3.1

從底層架構開始考慮數據隱私保護，并遵照當地法律法規進行調整。

另外是關于移動產品索取用戶系統權限的，用戶對權限的認識逐漸加深，對于非必須的權限將予以抵制。

• 新裝 APP 需要敏感權限，直接降低安裝轉化率。
• 升級 APP 需要新增權限，直接影響升級率。

最佳實踐 3.3.2

盡量少的索取系統權限。

四. 地區標準

由于歷史原因和現實原因，世界各地的標準并不是完全一致的，這為我們的產品設計也提出了復雜的挑戰。

主要問題有：

• 各區域相關標準習慣差異極大，而轉換工具復雜容易出錯
• 各區域歷法、時間概念不同
• 各區域數值、度量衡、相關格式不同
• 各區域貨幣不同，支付結算方式復雜
• 各區域有獨立的商標、知識產權、市場許可等要求

1. iSO 與 CLDR

iSO，國際標準化組織已經盡可能的將標準進行統一，如果不是極其特殊的情況，請務必遵守，這能將你的產品盡可能的兼容各大平臺和其他產品的接口。例如，語言代碼、區域代碼、貨幣名等等。

International Organization for Standardization

△ iSO 國際標準化組織

最佳實踐 4.1.1

務必采用 ISO 系列標準。

CLDR，通用語言環境數據倉庫用于格式化和解析區域的特定模式，已經包含了日期、數字、貨幣、語言、復數、性別、鍵盤布局等等內容，可以大大加快數據格式本地化的過程。

CLDR - Unicode Common Locale Data Repository

最佳實踐 4.1.2

務必優先使用 CLDR 整合的數據倉庫進行本地化處理。

以上工作的一部分已經由 iOS 和 Android 的系統平臺完成了，請確保優先使用。

2. 日歷、日期、時間、時區

好在世界上絕大部分地區都能理解現行公歷，一般產品以公歷為基礎即可。

優秀的本地化產品會根據用戶本地系統的設置進行優化展示，這需要具備完備的通用時間體系。主要有幾點：

• 采用通用的 API 進行時間處理
• 統一使用基于 UTC 的時鐘進行后端運算，將結果轉換為用戶前臺本地時間展示
• 注意時區、夏令時的影響

△ UTC 時區

△ iOS 日語、阿拉伯語日歷

最佳實踐 4.2.1

在采用 UTC 統一時間基礎上，使各地用戶能夠清晰理解所表達的時間。

除此之外，世界各地的每周休息日可能不同，每周的第一天也可能不同。

3. 數值、度量衡

遺憾的是世界上并不僅僅使用 0-9 這套數字體系，還有非常多其他的數字體系正在使用中。

世界上即便使用其他數字的地區，在今天也能理解「0-9」的數字概念。

△ 沙特阿拉伯 車牌示例

△ 伊朗 本土某電商界面示例

最佳實踐 4.3.1

建議使用「0-9」的數字體系，在本地化版本中可以使用本地數字。

數值的常見本地格式還包括：

• 小數點
• 千分位
• 負數
• 百分號
• 縮寫

△ 小數點格式分布

△ 某土耳其語 APP 頁面

最佳實踐 4.3.2

請參考 CLDR 中各區域的格式，不能強行一套方案。

在計量單位方面，以「米-千克-秒制」為基礎的國際單位制應用于絕大部分國家地區。

• 美國，采用美式英制單位，如英里、英寸、加侖、盎司等
• 利比里亞和緬甸，采用英制單位
• 所有其他國家地區，采用國際單位制

△ 注意計量單位

最佳實踐 4.3.3

計量系統應采用國際單位制，僅在美國地區使用美式英制單位。

4. 貨幣

RMB 并不是國際上通用的人民幣縮寫，而是由iSO 4217 定義的 CNY。同樣的，為了避免出現其他標準上或理解上的錯誤，建議統一使用 iSO 標準。

△ 某匯率產品界面

最佳實踐 4.4.1

應使用 iSO 4217 貨幣代碼，配合本地語言使用。

△ 某產品賬單界面

不建議直接使用符號代表貨幣，如「￥」有可能是人民幣，也有可能是日元。

一般建議只使用本幣，輔助貨幣直接換算，如人民幣 5 角應計為 0.5 元，80 撒丹應計為 0.8 泰銖。

5. 其他本地格式

在這里僅列出需要考慮的本地格式列表，詳細內容不再描述。

• 日期、時間、時區、歷法、
• 數字、貨幣
• 姓名規則
• 電話、郵政、地址格式
• 鍵盤
• 印刷、紙張

6. 法律要求

商標、知識產權、市場許可是進入一個目標市場必須考慮的法律問題。

根據產品或服務的業務形態，還需要考慮細分場景的法律規章。

△ 因商標原因，Pokémon 中文譯名定為精靈寶可夢

△ 2017 年 5 月 微信在俄羅斯被禁用

微信遭禁的原因，是其服務商沒有在法律規定的期限內向相關機構提供信息轉播服務組織者的有關數據信息。此外，微信也未在俄相關政府部門進行正式登記。在禁用約一周后解除封鎖。

最佳實踐 4.6.1

與市場部門驗證所有商標聲明，確定獲取當地運營所需要的知識產權和市場許可。

了解并遵循當地市場的法律要求，在出現問題時及時與政府溝通。

五.開發技術

從開發的角度同樣有很多細致復雜的工作，本篇更著重于設計，所以主要是作為產品方需要在開發合作時需注意的方面。

主要問題有：

• 區域性編碼轉換復雜，支持東亞 CJKV 需要額外技術挑戰
• 產品迭代過程中與本地化團隊協調復雜
• 需翻譯的文本難以對應上下文和位置
• 用戶界面隔離的具體實現繁瑣

1. 字符編碼

在字符集方面，不要去碰那些地區使用的字符集，如 Big 5、VISCII 之類的，從代碼到數據都要使用 Unicode 統一編碼。

Unicode Consortium

最佳實踐 5.1.1

務必采用 Unicode 編碼。

△ 「三國志曹操傳 → 瓣B變巨肚」Big5 碼轉 GB 碼導致

△ 字符編碼不匹配

2. 本地化團隊合作

本地化團隊不僅僅是進行當地語言的翻譯工作，而是一個完整的項目工程。

Fly 應該翻譯成什么？

初級的本地化工作就是將一份整理好的待翻譯文檔提交給翻譯團隊，翻譯好再導入到程序內。一是合作復雜，難以快速迭代；二是翻譯難度大，很多文本缺乏上下文難以精確翻譯。

如果可以的話，建議以英語為基礎語料，甚至為部分文本提供相關的備注便于翻譯。

最佳實踐 5.2.1

應該提供一套創建、翻譯、打包的標準流程，在其中能夠識別目前多語言文檔的增刪改情況，并能夠查找文本對應用戶界面的機制。

△ 某產品的本地化工具

建議你與同一個本地化團隊保持長期合作。

3. 用戶界面隔離

為了避免產品的一點修改都需要對整個產品的全部流程全部地區進行調整，請務必將產品的多語言部分與程序主體隔離。

最佳實踐 5.3.1

必須將代碼邏輯層與內容表現層隔離。

△ 將本地文本與可執行代碼隔離

△ 某游戲的本地化資源存儲方案

基于 Key - Value 的多語言文檔目前最為常見和實用。

也可以參考 iOS 本地化（Localizing Your App） 和 Android 本地化（Localizing with Resources）相關內容。

最佳實踐 5.3.2

各國家地區擁有獨立用戶界面資源，包含語言文字，圖標圖像，樣式文檔等內容。

在本地化團隊介入前解決大部分國際化問題，可以先通過偽語言包進行測試。畢竟本地化還是成本很高的。

附錄

最佳實踐清單

1.1.1 請把英文作為產品無法匹配語言時的默認語言，也應當以英文版本為基本款進行設計。

1.1.2 應用內自主更換語言更能滿足設計和用戶的需求。

1.1.3 不要采用旗幟圖標指示語言。

1.2.1 全球化的產品應當能正確處理 RTL 語言。

1.3.1 優先調用系統級的本地化字符串處理函數進行處理。

1.3.2 勉強也可接受復數無關的界面排版模式。

1.3.3 不能僅用大小寫來傳達某種必要信息。

1.3.4 如果涉及到程序轉換大小寫的情況，務必需要先判斷語言類型。

1.4.1 注意將標點符號轉換為本地方案，并特別注意換行時的標點位置。

1.5.1 在排序和組織內容方面，請確保使用 Unicode 的規范化處理方式。

2.1.1 不要將文字直接嵌入圖片或視頻媒體中，應當分別以較小個體進行存儲，便于替換。

2.1.2 不建議復用同一資源，某些本地化資源也許并不能一一對應。

2.2.1 文字與組件必須分隔排版，不使用基于語言元素的拼接組件。

2.3.1 為所有文字預留足夠的空間，并且設置溢出情況下的處理方法。

2.3.2 盡量采用簡潔的描述，并且提醒本地化團隊節約使用空間或設置限制。

2.4.1 界面文字盡量采用系統默認匹配的字體。

2.4.2 少用、慎用粗體、斜體、下劃線等樣式。

3.1.1 避免使用冷幽默、雙關、熟語、俚語等過于本地化的內容，少用術語、縮略語。

3.1.2 盡量采用各大平臺原生的標準圖標，或基于標準圖標進行重設計。

3.1.3 避免使用宗教、神話相關的內容、標志、符號等。

3.1.4 避免使用身體、手勢來表示含義。

3.2.1 盡量避免涉及民族、地緣、宗教、政治的敏感信息，注意收集本地化團隊的建議。

3.2.2 不要使用色情、暴力相關內容，需注意賭博、癮品等內容。

3.3.1 從底層架構開始考慮數據隱私保護，并遵照當地法律法規進行調整。

3.3.2 盡量少的索取系統權限。

4.1.1 務必采用 ISO 系列標準。

4.1.2 務必優先使用 CLDR 整合的數據倉庫進行本地化處理。

4.2.1 在采用 UTC 統一時間基礎上，使各地用戶能夠清晰理解所表達的時間。

4.3.1 建議使用「0-9」的數字體系，在本地化版本中可以使用本地數字。

4.3.2 請參考 CLDR 中各區域的格式，不能強行一套方案。

4.3.3 計量系統應采用國際單位制，僅在美國地區使用美式英制單位。

4.4.1 應使用 ISO 4217 貨幣代碼，配合本地語言使用。

4.6.1 與市場部門驗證所有商標聲明，確定獲取當地運營所需要的知識產權和市場許可。

5.1.1 務必采用 Unicode 編碼。

5.2.1 應該提供一套創建、翻譯、打包的標準流程，在其中能夠識別目前多語言文檔的增刪改情況，并能夠查找文本對應用戶界面的機制。

5.3.1 必須將代碼邏輯層與內容表現層隔離。

5.3.2 各國家地區擁有獨立用戶界面資源，包含語言文字，圖標圖像，樣式文檔等內容。

以上是全球化設計中的國際化問題，還不能說是盡善盡美，加之隨著時間推移還會有新的挑戰或是更優雅的解決方案，會努力進行動態更新。

================明星欄目推薦================

優優教程網： UiiiUiii.com?是優設旗下優質中文教程網站，分享了大量PS、AE、AI、C4D等中文教程，為零基礎設計愛好者也準備了貼心的知識樹專欄。開啟免費自學新篇章，按照我們的專欄一步步學習，一定可以迅速上手并制作出酷炫的視覺效果。

設計導航：國內人氣最高的設計網址導航，設計師必備：http://hao.uisdc.com