如何完成支持全球語言的UI設計？微信高手總結了8500字干貨！

讓應用支持全球的各種語言是一項挑戰。兼容不同的語言形態、語法、數據格式需從設計層面就開始考量。遺憾的是，我們很容易忽略使用其他語言或文字系統的用戶，從而使得體驗受損，甚至造成用戶流失。

設計支持全球語言的 UI 的重要性主要體現在以下 3 個方面：

①提升用戶體驗

支持本地語言的 UI 能提升用戶粘性，這對于提升用戶體驗和用戶增長非常重要。

②提升品牌全球影響力

通過支持全球語言，可以打造更具全球影響力的品牌，提升品牌的全球認知度。

③推動科技向善

引導大家關注處于文化弱勢困境的群體，讓所有人均可平等地享受科技帶來的便捷，實現「為所有人設計」的目標。

可見，設計支持全球語言的 UI 是至關重要的。因此，我們建議將支持全球語言納入到日常設計的考量范圍內。

本文將從文本翻譯、文本排版、數據格式等 3 個方面，帶領讀者對多樣的語言環境進行初步了解，并介紹相應的最佳設計實踐。

更多干貨：

一、文本翻譯

文本翻譯是支持多語言的第一步，也是最為重要的一步。通常，這部分工作主要都由專職的翻譯人員來完成。但為了保證翻譯質量，我們還需盡可能做到以下 4 點：

1. 分離文本、代碼
2. 分離文本、圖像
3. 添加文本注釋
4. 創建翻譯指南

1. 分離文本、代碼

將需要本地化的 UI 文本從代碼中分離出來，以獨立的資源文件方式存放，以備交付給本地化人員進行本地化處理。

我們可以在 Xcode 中使用 string catalog 來管理 UI 文本。

2. 分離文本、圖像

對于包含文本的圖像，為每個語言都提供一個獨立的素材，不僅成本高，還會增加應用的內存占用。因此，UI 文本應與文本分離。

我們可以將這類圖像上的文本與圖像本身分層，以達到簡單替換字符串即可完成翻譯的效果。

3. 添加文本注釋

為 UI 文本添加注釋（comments）可以為翻譯人員提供必要的信息，從而協助他們翻譯出清晰且自然的譯文。

注釋可以包含以下 2 類內容：

①顯示位置

描述文本會顯示在什么 UI 元素上，例如：

Text("收藏", comment: "按鈕")
Text("收藏", comment: "導航欄標題")

②上下文

在上面的案例中，盡管已知曉文本的顯示位置，但翻譯人員可能還是無法知曉「收藏」的具體含義。其可能是「Add to Favorites」，也可能是「Favorites」。因此，注釋有時還需要添加上下文，如：

Text("收藏", comment: "按鈕: 收藏此項目")
Text("收藏", comment: "按鈕: 前往已收藏項的列表")

4. 創建翻譯指南

通過以上設計策略，翻譯的準確性已有所保證。但為了讓譯文更清晰、自然，我們還需創建翻譯指南。例如，淘寶的翻譯人員就需要從翻譯指南中了解「親」這一用詞的來源及含義。

翻譯指南主要包括以下 2 部份內容：

①風格指南（Style Guide）

風格指南包含了產品的行文語氣、寫作風格、句子結構、拼寫等規則。其并非充滿語言規則的語法手冊，而是幫助翻譯人員產出更佳譯文的工具。

②術語表（Glossary）

術語表包含了產品經過考量的特定翻譯，以幫助翻譯人員保證翻譯的一致性。

二、文本排版

不同的語言有不同的展現形式。因此，我們需要提供能靈活變化以優雅展示內容的 UI。

制定文本排版策略應主要考慮以下 5 點：

1. 字符形態
2. 詞匯分隔
3. 文本長度
4. 文本強調
5. 縮寫

1. 字符形態

不同的語言通常使用不同的字符（glyph），其可以被分為以下 3 類：

①English-like

用于歐洲、非洲的大部分語言（如英語、希臘語、西里爾語、希伯來語、亞美尼亞語、格魯吉亞語等）的字符類型。

②Tall

用于南亞、東南亞語言（如阿拉伯語、印地語、泰盧固語、泰語、越南語等）的字符類型。

③Dense

用于中文、日文、朝鮮文的字符類型。

與拉丁字母的相比，tall、dense 類型的字符在視覺上顯得更復雜，如：

1. 一些語言會在字符上方、下方添加重音符號（diacritic marks）、變音符號（accent marks）。如法語中的「père」。
2. 泰語的元音字母（vowels）寫在輔音字母（consonants）的上方、下方、左側、右側。如「??????????」。

不僅如此，tall 類型的字符還容易出現文本被裁切的現象。

可見，應為使用較為復雜的字符的文本提供更大的行高、行間距，或更大的字號，以確保可讀性。

我們也可以利用 UIKit 的「dynamic line-height adjustments」，以自動優化 tall 類型的字符的行高。

2. 詞匯分隔

詞匯分隔指的是，用特定的符號或空格將不同的詞或詞組分隔開來，使其更易于理解。例如，在英語中，我們通常在單詞之間使用空格來分隔它們。

對于沒有明顯的詞匯分隔的語言（如漢語、日語），一個單詞常常被拆分到 2 行中。當此現象出現在標題文本中時，拆分的單詞會增加讀者的識別、理解成本。

為確保良好的可讀性，應盡可能避免在標題中拆分單詞。

我們也可以利用 UIKit 的「improved line breaking」，以自動優化漢語、日語、韓語的換行行為。

3. 文本長度

將內容翻譯成不同語言時，譯文的長度可能會有非常大的變化。

以下是「200 次瀏覽」中的「次瀏覽」在翻譯成不同語言后的長度變化：

可見，翻譯后的 UI 文本可能會面臨顯示空間不足或頁面空白過多的問題。

以下是從英語翻譯到歐洲語言的平均預期擴展率：

可見，較短的文本字段更易受到文本擴展的影響。

值得注意的是，文本擴展關注的是「文本長度」的變化，而不是「字符數」的變化。因為，漢語、日語的字符所需的水平空間一般都比拉丁字母大得多。例如，英文中的「desktop」在日文中寫為「デスクトップ」，雖然日文的字符數少了 1 個，但所需的水平空間卻大了很多。

①設計策略

以英語為基準，按以下表格提供的比率來設定顯示空間。

優先縱向排布含文本圖層的元素。

若需要水平排布元素，盡可能減少每一行的元素數量。

水平排列的元素可以通過自適應向垂直方向擴展。在 Figma 中，將 auto layout 的 direction 設為「warp」。

對于文本溢出的場景，可按需選擇省略、換行、折疊（漸進展示）、滾動（跑馬燈效果）等策略

1. 若選用省略的策略，需要評估省略號前展示的內容是否可被理解。在 Figma 中，為文本圖層開啟「truncate text」。
2. 若選用換行的策略，需要進一步明確極限行數，以保證容器高度可控。在 Figma 中，為文本圖層開啟「truncate text」并設定「max lines」。
3. 若選用滾動的策略，需要評估是否會過度吸引注意力。

4. 文本強調

一些語言不適合使用粗體（bold）和斜體（italics）來強調文本。例如，中文、日文可以通過加粗來進行強調，卻通常不用斜體，因為它們缺乏斜體字形。

此外，一些語言不適合使用下劃線，如字符自帶基線的天城文。

可見，應慎用粗體、斜體、下劃線等字符樣式。

5. 縮寫

避免使用縮寫來規避文本擴展的影響。因為，對于許多語言（如阿拉伯語、俄語），縮寫并不常見。此外，縮寫本身常常就是難以理解的。

三、讀寫方向

不同的語言通常使用不同的讀寫方向，其一般被分為以下 2 類：

①LTR Languages

全稱為「left-to-right languages」。如基于拉丁字母（如英語、法語等）、西里爾字母（如俄語、保加利亞語等）、方塊字（如漢語、日語等）的語言。

②RTL Languages

全稱為「right-to-left languages」。如阿拉伯語、波斯語、烏爾都語、希伯來語、意第緒語、迪維西語等語言。

此外，還有中文、日文、韓文的傳統垂直讀寫方向。對此，本文暫不展開討論。

支持多讀寫方向不僅僅是簡單地更改對齊方式、進行鏡像翻轉。我們需要將 UI 元素分為以下 3 類來分別處理：

1. Mirrored

其包含 2 類：

①需要鏡像翻轉整體的元素類型，例如：

傳達水平方向的圖標

需要鏡像翻轉布局的元素類型，例如：

①含圖標的列表項

②導航欄按鈕

③按鈕組

對于需要鏡像翻轉布局的元素類型，應使用 leading、trailing 屬性來描述布局，而不再使用左側、右側：

1. leading 指的是更接近讀寫起點的一側，對于 LTR languages 來說是左側，對于 RTL languages 來說就是右側。
2. trailing 指的是更接近讀寫終點的一側，對于 LTR languages 來說是右側，對于 RTL languages 來說就是左側。

使用這組屬性后，設備會依據語言的讀寫方向來自動轉譯頁面布局，以實現正確的讀寫方向。

2. Universal

指無需處理的元素類型，例如：

①不傳達水平方向的圖標

②含右手操作含義的圖標

③映射物理實體的圖標

④圖標中的斜杠

⑤媒體進度條

⑥非 RTL 的文本

⑦數據圖（X 軸、Y 軸的位置始終不變）

值得注意的是，盡管 RTL 的本文一般使用右對齊，但若文本中穿插有 LTR 語言的段落，此段落仍需保持左對齊，以提高可讀性。

3. Dedicated

指需要為每個讀寫方向分別提供設計的元素類型。

四、語法

對于 UI 中的文本，符合諸如單復數、陰陽性等語法規則是至關重要的。對于靜態文本，可以由專業的翻譯人員來維護；而對于動態生成的文本，則需要從代碼層面來進行「語法自適應」。

語法自適應主要需處理以下 5 點：

1. 標點符號

不同的語言可能有不同的標點符號規則，例如：

①樣式不同

②位置不同

③某些語言很少使用標點符號

2. 大小寫

不同的語言可能有不同的大小寫規則，例如：

①某些語言會使用大小寫區分含義

②某些語言沒有大小寫的概念（如漢語、泰語、阿拉伯語等）

3. 復數

不同的語言可能有不同的處理名詞復數形式的規則（pluralization），例如：

①英語僅有 one、other 兩種復數形式。

②俄語則擁有更豐富的復數形式。

?4. 語法性別

語法性別（grammatical gender）指的是，名詞、形容詞、代詞等詞性可能會根據所指代的實體的性別（包括 feminine、masculine、neutral）而有所不同。

例如，在西班牙語的外賣點單頁中，「份量（tama?o）」的選項應符合用戶所選菜品的陰陽性：

1. 咖啡（cafe）是陽性的。因此，小份的咖啡應寫為「cafe peque?o」。
2. 沙拉（ensalada）是陰性的。因此，小份的沙拉應寫為「ensalada peque?a」，而不是「ensalada peque?o」

5. 并列結構

并列結構（parallel structure）指的是，在句子中由多個名詞、形容詞、副詞等成分并列放置的結構。

不同的語言可能有不同的并列結構，例如，在英語中，并列結構成分間僅需在插入逗號或「and」即可；但在西班牙語中，「and」一詞需根據上下文變為「y」或「e」。

6. 語境敏感性

人們通常會根據對象、話題、場合、文化背景等因素來變化措辭，以生成準確、得體的表達。例如，在漢語中，下級到訪用「拜訪」，而上級到訪則改用「蒞臨」。

在 UI 中，影響措辭的常見因素為設備類型。設備類型對 UI 文本的影響主要體現以下 2 方面：

①措辭變化

在 iPhone 上，一段文案可能會寫為「輕觸這里」；而在 iMac 上，這段文案則應寫為「點擊這里」。

②文案體量

在 iPad 上，一段文案可能會寫為「Greetings and Salutations!」，而在 Apple Watch 上，這段文案則可能被縮寫為「Hello!」。

iOS、macOS、Android 平臺均在代碼層面提供了語法自適應的解決方案。例如：

1. 在 Apple 的平臺中，我們可以使用 NSInflectionRule 來自動處理英語復數、時態變化。
2. 在 Android 中，我們可以使用 Grammatical Inflection API。

五、數據格式

世界上有著多樣的數據格式：表示溫度的華氏度、攝氏度，表示長度的中國傳統度量衡、國際單位制。UI 中的數據格式應以用戶期望的形式顯示。

1. 單位制

不同的國家和地區可能有不同的單位制。例如，在美國用的英尺（feet）到法國需轉換為米（meter）。

世界上較為通用的單位制有以下 3 種：

1. 國際單位制（SI）。適用于絕大部分國家和地區。
2. 英制（Imperial Units）。主要用于英國民間、利比里亞、緬甸。
3. 美式英制。普遍用于美國。

2. 數字

不同的國家和地區可能有不同的數字類型、書寫格式，例如：

其差異主要在于以下 3 點：

①數字符號（Numeric Notation）

例如，阿拉伯數字符號的「123」，在爪哇語數字符號（Javanese）中寫為的「? ? ?」。

在 iOS 的鎖屏設置中，就提供了多種數字類型供選擇。

②十進制分隔符（Decimal Separation）

例如，十進制分隔符在瑞士通常為逗號「,」，但在中國為點「.」。

③數字分組（Number Grouping）

為了更容易閱讀位數較大的數字，人們常常會為數字進行分組。在歐洲，通常為三位數一組，但在中國、日本、韓國，則為四位數一組。

3. 貨幣值

不同的國家和地區可能有不同的幣種，這帶來了不同的貨幣值表達方式，例如：

其差異主要在于以下 4 點：

①數字不同

詳情請見上文。

②貨幣符號不同

例如，人民幣的符號為「￥」，美元的符號為「$」，歐元的符號為「€」。

③貨幣符號的位置不同

例如，在日本，貨幣符號放在數字前（￥200），而法國則不然（200€）。

④貨幣符號和數值間是否有空格

例如，在美國，貨幣符號和數值之間沒有空格（$200），而荷蘭則不然（€ 399）。

此外，有些幣種的貨幣符號是相同的。例如：

1. 人民幣和日元都用「￥」作為貨幣符號。
2. 美元和加拿大元都用「$」作為貨幣符號。

我們可以使用 ISO 4217 貨幣代碼來解決貨幣符號相同的問題。例如，將一百元的人民幣寫為「CNY 100」，將一百元的日元寫為「JPY 100」。

值得注意的是，「RMB」「軟妹幣」「塊」「米」均非國際通用的人民幣別稱，需避免使用。

4. 時間、日期

不同的國家和地區可能有不同的時間、日期格式，例如：

其差異主要在于以下 4 點：

①順序

大多數歐洲國家使用「DD/MM/YY」格式，美國使用「MM/DD/YY」格式，日本使用「YY/MM/DD」格式。

②分隔符（Separators）

斜杠、破折號、連字符、句點均可能被用作分隔符。

③前導零（Leading Zero）

部份國家和地區會省略前導零，如「2023/6/6」；而其他地區則不然，如「2023/06/06」。

④小時制

12 小時制、24 小時制均可能被使用。

設計策略

①優先使用公歷（Gregorian）

以避免產生歧義。也可以直接在頁面上對如何理解日期進行說明。

②優先使用「YYYY-MM-DD」格式

因為，這是 ISO 8601 推薦使用的較為清晰的格式。

③支持時區、夏令時，以及本地日歷

例如，日本人通常使用皇歷（Imperial calendar）來記錄生日（如平成 31 年 1 月 1 日），泰國人經常使用佛歷（Buddhist calendar）。

5. 電話號碼

不同的國家和地區可能有不同的電話號碼格式，例如：

1. 在法國，電話號碼以 2 個數字為 1 組，如「01 23 45 67 89」。
2. 在英國，電話號碼會被分為 3 組，如「01234 567 789」。

此外，電話號碼里可能還會包含國家代碼（如英國的國家代碼是「+44」）、地區分號（如上海的地區分號是「021」）。

建議將 International Telecommunication Union 的 E.164 standard 用作電話號碼格式的標準。

還可以利用 Google 的 libphonenumber 來自動處理電話號碼格式。

6.? 郵政編碼

不同的國家和地區可能有不同的郵政編碼格式，例如：

1. 中國的郵政編碼由 6 個數字組成。
2. 美國的郵編由 5 個數字組成。
3. 英國的郵編由字母、數字混合而成。

建議將 Universal Postal Union 的 POST*CODE? DataBase 用作郵政編碼格式的標準。

7. 地址

不同的國家和地區可能有不同的地址格式，例如：

1. 在中國、日本，地址的格式通常為宏觀到微觀。
2. 在美國，地址的格式通常為微觀到宏觀。

建議將 Universal Postal Union 的 POST*CODE? DataBase 用作地址格式的標準。

8. 人名

不同的國家和地區可能有不同的姓名格式。其差異主要在于以下 5 點：

①順序

人名的構成順序可能不同。如：

1. 在中國、日本、韓國、匈牙利，人名的順序通常是「姓、名」，且無空格將其分隔。
2. 但在英國，人名的順序通常是「名、姓」，且有空格將其分隔。

②姓氏

人們可能沒有姓氏。

在印度南部、馬來西亞、印度尼西亞的一些文化中，許多人的名字只包含一個名字，沒有任何姓。

夫妻的姓氏可能不同。

雖然在美國、俄羅斯、日本等國家，妻子改用丈夫的姓氏仍然很常見，但隨著女性權益的發展，有越來越多的女性選擇婚后不改姓。此外，甚至還有丈夫婚后改用妻子姓氏的情況。

人們可能有多個姓氏。

例如，在「María José Carre?o Qui?ones」這一西班牙名字中，「Carre?o」「Qui?ones」都是姓氏。這說明此人可能是「Antonio Carre?o Rodríguez」和「María Qui?ones Marqués」的女兒。

多個姓氏的順序可能不同。

例如，西班牙語中，姓氏的順序是「父姓、母姓」；而在巴西的葡萄牙語中，順序為「母姓、父姓」。

多個姓氏之間可能會添加短詞。

如 Carre?o de Qui?ones、Tavares e Silva。

③特殊稱謂

人們可能有與真名無關的特殊稱謂。

例如，在泰國，人們通常有一個常用于非正式場合的昵稱。這個昵稱也常用于向外國人介紹自己，因為它通常只有 1 到 2 個音節，更易于發音。舉個例子，泰國前總理 Thaksin Shinawatra 的昵稱是 Maew（????）。

④詞體變形

相同的姓名可能會根據性別產生詞體變形。

例如，對于「Patronymic」這一冰島名，用于男性時會以 -son 結尾，而用于女性時會以 -dóttir 結尾。

⑤多音字

相同的姓名可能會有不同的發音。

以日本人名為例。日本人名中的漢字（kanji characters）通常有多種發音。這可能使得人們難以確切地知道如何讀一個名字，并且也給給予發音的排序、檢索帶來困難。例如，「東海林賢蔵」這一姓氏可以被讀為「Tōkairin」，也可以讀為「Shōji」。

由此，人們會將日本人名轉換為用羅馬字母拼寫的形式，以便于非日語使用者更好地理解日本人名的發音和拼寫。但轉為羅馬化（kanji romanization）后的日本人名仍有相同發音帶來的問題。例如，「莊司」「莊子」「東海林」「小路」羅馬化后都是「Shōji」。

設計策略

1. 允許輸入特殊字符。應允許用戶輸入連字符、撇號、空格等特殊字符。
2. 允許不填寫姓氏。若將姓氏作為必填項，沒有姓氏的用戶會在此字段中輸入垃圾數據（如「.」或「Mr.」）以勉強完成表格填寫。
3. 支持設置稱呼。在設置個人資料時，建議單獨詢問用戶希望應用如何稱呼他們。例如，對于中國人名「李曉月」，「李女士」「李小姐」「小李」「曉月」都是可能被期望的稱呼。
4. 支持設置發音。鑒于多音字的存在，應支持用戶聲明人名的正確發音。
5. 支持多種排序方式。因為，人們不總是期望按姓氏排序聯系人。例如，泰國、冰島人希望按名字排序。
6. 考慮僅提供一個足夠空間的全名輸入框。因為，來自不同文化的姓名的長度、構成、順序都是不同的。僅要求填寫一個姓名字短能減少大量適配工作，并提升靈活性。

總的來說，我們應盡可能遵循由「Unicode CLDR Project」提供的規范。

值得注意的是，使用相同語言的用戶不一定會使用相同的數據格式。例如：一個生活在德國的以英語為母語的用戶，可能會選擇英語作為語言，選擇德國作為地區。

因此，UI 應支持分別選擇語言、數據格式類型，以支持用戶的多樣化訴求。

六、設計驗收

1. 使用 Pseudolanguages

對于多語言的頁面呈現，我們推薦使用 Pseudolanguages（偽語言）進行驗收。

Pseudolanguages 并不是真實存在的語言，而是一種模擬其他語言的特征和特性的語言。通過在 UI 中使用 pseudolanguages，我們可以測試應用在不同語言環境下的適應性和可用性。

在 Xcode 中，我們可以使用以下 6 種 pseudolanguages 進行驗收：

①Double-Length Pseudolanguage

將文本長度加倍，以測試應用在長文本環境下的效果。

②Right-to-Left Pseudolanguage

將語言方向改成從右往左，以測試應用在從右到左的語言環境下的效果。

③Emotional Pseudolanguage

將文本轉換成 emoji 等利于傳達情感的形式。

④Accented Pseudolanguage

將文本轉換成帶有重音符號（accents）的文本，以測試應用在帶有高低升降調的語言環境下的效果。

⑤Bounded String Pseudolanguage

在字符串兩端加上中括號，以便識別出可能出現截斷的字符串。

⑥Right-to-Left Pseudolanguage With Right-to-Left Strings

將語言方向改成從右往左，并在其中穿插右到左的文本。

以下是將「We love WeChat!」這一語句轉為部份類型的 pseudolanguages 的效果：

2. Checklist

以下 checklist 僅供參考，可以根據實際需求進行調整。

結語

通過全球化的設計，我們將朝著對全球用戶更具同理心的目標邁出重要一步。我們希望能有更多設計師能參與到設計支持全球語言的 UI 的工作中來，讓科技不再限于特定文化。

歡迎關注作者微信公眾號：「We-Design」