設計以人爲本的國際化（i18n） 工程方案

需求分析

若是問硅谷的公司跟中國最大的不一樣是什麼，我想答案極可能正如吳軍所言，硅谷公司的產品大多面向全球市場。陳志武說的好，創造財富能力有三個衡量維度：深度，即生產力，一樣的時間提供更好產品或服務的能力；長度，即利用金融槓桿，跨越時間和空間交換價值的能力；廣度，即市場大小，開創跨越地域的市場或者新行業的能力。而國際化，也就是產品和服務在語言和文化上的本地化，正是跨國公司征戰全球市場的戰略要地。

Internationalization 由於字母 i 後面跟了 18 個字母而後以 n 結尾，因此被稱爲 18n，咱們此次設計的 i18n 工程方案主要是解決網站和移動 App 開發過程當中的以下問題：

1. 語言
2. 時間與時區
3. 數字與貨幣

構架設計

語言

邏輯和細節

語言的本質是把消息交付給受衆的媒介，不一樣的語言就是不一樣的媒介，不一樣的媒介面向不一樣的受衆。好比，咱們要對用戶顯示文字：「你好，小麗！」，顯示的過程就是查一下語言表，根據用戶的語言，和當前須要的插值，好比姓名，顯示相應的消息：

Message Codes	Locales	Translations
home.hello	en	Hello, ${username}!
home.hello	zh-CN	你好, ${username}!
home.hello	IW	!${username}, שלום
…	…	…

不一樣語言在細節上略有不一樣，好比一個物品的單數和複數的形式；好比第三人稱，在稱呼上男性和女性的區別。

這些都是簡單的查表沒法應對的問題，須要更復雜的邏輯處理。在代碼中你能夠無腦地使用條件語句去處理這些特例。此外有一些國際化的框架會發明 DSL (domain specific language) 來專門應對這種狀況。以 The project fluent 爲例：

還有一個新手容易忽略的問題是行文的方向。中文和英文等經常使用語言是從左至右的，可是還有一些語言，是從右往左的，好比希伯來文和阿拉伯文。

行文方向的不一樣不只僅會影響到文字自己，還會影響到輸入的方式。中國人若是從右至左輸入會以爲很是的奇怪；而個人一位猶太同事就以爲英文和猶太文混着輸入垂手可得。

還有一種狀況就是佈局。整個 UI 的佈局、視覺元素好比箭頭的方向。均可能會根據語言的方向的不一樣而發生變化。你的 HTML 須要設置好相應的 dir 屬性。

如何肯定用戶的地域？

你可能會問，咱們如何知道用戶當前的語言設置呢？若是是瀏覽器的話。在用戶請求網頁的時候，會有一個 header Accept-Language 標註接受的語言。這些設置來自於用戶的系統語言，以及瀏覽器的設置。移動 App 狀況下，一般都會有獲取 locale 變量或者常量的 API。還有一種方式是根據用戶的IP 或者 GPS 信息知道用戶的位置，而後顯示相應的語言。若是是跨國公司，用戶在註冊的時候，一般會標註出用戶註冊時候的語言習慣、地理區域。

若是用戶想要改換語言，網站的作法各有千秋，移動 App 會有相對固定的 API。網頁有這樣幾種方法：

1. 設置 locale cookie
2. 使用不一樣的子域名
3. 使用專有域名。 Pinterest 有一篇文專門講他們如何用本地化的域名。 研究代表使用本地域名後綴的點擊率會更高。
4. 使用不一樣的路徑
5. 使用 query params。這個作法雖然能用，可是對 SEO 不友好。

新手在作網站的時候容易忘記在 HTML 上標註 lang 標籤。

翻譯管理系統

當你注意到如上種種細節。當心翼翼的實現了文字語言的顯示以後。你會發現，翻譯庫的創建和管理，也是一個麻煩的過程。

一般開發者並不會有多語言的功底。這時候就須要引入外部的翻譯官或者是別人已經創建好的翻譯庫。而這裏的難點在於，翻譯官每每並非技術人員。若是讓他們直接改代碼、或者直接跟開發人員溝通，會極大的增長翻譯的成成本。因此在硅谷的公司，這種提供給翻譯官使用的翻譯管理系統 (translation management system)，每每是有一個團隊專門來作，或者直接採購現有的方案，好比說，閉源收費的 lokalise.co ，或者是開源的 Mozilla Pontoon。翻譯管理系統能夠統一管理翻譯庫、項目、審覈、任務分配。

這樣一來，開發的流程就會變成，首先設計師根據不一樣的語言和文化習慣，在設計的時候標誌出須要注意的地方，好比這個按鈕雖然在英文裏很短，可是在俄文裏面會很是長，要注意不要溢出。而後，開發者開發團隊根據設計的需求實現具體的代碼邏輯，並在翻譯管理系統中提供消息碼、上下文的背景、以及一個開發者熟悉的語言寫成的例子。再而後，翻譯官團隊在管理系統中填上各類語言的翻譯。最後，開發團隊把翻譯庫拉回代碼庫中，發佈到產品中。

其中，上下文的背景是容易被忽視並且不容易作好的地方。這個須要翻譯的消息在UI界面的什麼地方？用做什麼用途，若是消息太短的話，還應該進一步的解釋這個消息是什麼意思。那麼翻譯官有了這個背景知識以後，就可以更加精準地加上其餘語言的翻譯。若是翻譯官對想要表達的信息。沒法透徹的理解。他們還須要擁有一個提供反饋的渠道，可以找到產品的設計和開發者詢問問題。

這麼多的語言和文字，一般都不是由一個翻譯官來解決的，這一般須要不少個國家語言身份的人一塊兒來爲這個翻譯庫添磚加瓦。整個過程耗時耗力，因此翻譯官一般是有專門的團隊來負責的，好比外包給 smartling。

如今咱們已經有了代碼邏輯和翻譯庫。接下來的問題是：如何把翻譯庫的內容搬到產品中？

具體能夠有不少不一樣的實現方式，最直接的就是，靜態的作法，每次更新的時候。交一個 diff，而後在 merge 到代碼當中。這樣在構建的時候，就會有就已經有了相關的翻譯資料在代碼裏面。

還有一種作法是動態地作。一方面，能夠去遠程的翻譯庫「拉取」內容，這種狀況在網站流量大的時候，可能會有性能問題。可是好處是，翻譯永遠是最新的。另外一方面，想要作優化的話，能夠採起「推送」的方式，每次翻譯庫有新改動，觸發一個 webhook 來把內容推到服務器上。

在我看來，維護翻譯會比添加翻譯更加的繁瑣。我曾經看到一些很大的項目，由於更新翻譯以後沒可以及時的刪除老的翻譯，致使翻譯庫過於的龐大，整個項目變得亂七八糟。這個時候若是有一個好的工具，可以保證數據的一致性。會對清潔的代碼，有很是大的幫助。

阿里巴巴的 Kiwi 國際化全流程解決方案就作了 linter 和 VS Code 插件來幫助你檢查和抽取代碼中的翻譯。

時間和時區

談完了語言，接下來是時間和時區問題。由於是全球化的公司，因此說有不少數據是來自於全球、顯示給全球的用戶的。舉個例子。國際航班在設置開始時間結束時間的時候如何保證這個時間在全局是一致的，而且在不一樣的時區會相應的顯示。這很是的重要。一樣的狀況還應用於一切跟時間有關的事件，好比預約酒店、預約餐館、安排會議。

首先時間有這樣幾種典型的表現形式。

1. 天然語言，好比 07:23:01, 星期一 28, 十月 2019 CST AM/PM
2. Unix timestamp (Int 類型)，好比 1572218668
3. Datetime. 注意 MySQL 存datetime 的時候會根據服務器時區轉化成 UTC 而後存起來，讀取的時候再轉換回來。可是呢，服務器時區通常都是設置成 UTC 的。這種狀況就是，存儲不帶時區，默認 UTC。
4. ISO Date，好比 2019-10-27T23:24:28+00:00，這是帶時區信息的。

我對這些形式沒有大的偏好，你若是有相關經驗，歡迎留言討論。

具體在顯示的時候。有兩個可能出現的轉化，一個是，從服務器存儲的時區轉化成當地時區顯示的形式；另一個是，語言上會由機器代碼轉換成天然語言。後一步流行的作法是使用強大的處理時間和日期的庫，好比 moment.js 和 dayjs。

數字與貨幣

不一樣國家區域對於數值的顯示，實際上是天差地別的。數值中間的逗號和點，在不一樣的國家，有不一樣的含義。

(1000.1).toLocaleString("en")
// => "1,000.1"
(1000.1).toLocaleString("de")
// => "1.000,1"
(1000.1).toLocaleString("ru")
// => "1 000,1"
複製代碼

阿拉伯數字並非在全部區域都通用的，好比 Java 的 String.format 中 一、二、3這種數字在真正的阿拉伯語言裏，使用的數字是١、٢、٣。

價格方面，一樣的貨物，在不一樣的國家地區，是否要顯示成當地貨幣的價值？貨幣的符號是什麼？貨幣可以精確到哪一位？這些問題通通要先作好準備。

總結

本文提到的國際化工具備，翻譯管理系統，開源的 Mozilla Pontoon、閉源收費的 lokalise.co。代碼上的一致性 阿里巴巴 Kiwi 國際化全流程解決方案。UI 顯示上的 moment.js, day.js。

如同一切軟件系統的開發同樣，國際化這件事情沒有銀彈，好的做品都是靠基本功一點一滴磨出來的。

本文首發於硅谷io