设计以人为本的国际化（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