如何从0到1进行国际化/本土化设计落地-Part 2

Stay Woke

2.4 数字，时间，货币，单位本文为第二部分内容，想了解社会文化模型，用户习惯，设备使用，地方设计模式，翻译注意事项等等内容请查看

2.4 数字，时间，货币，单位

2.4.1 数字

尽管全世界大部分地区都知道西方阿拉伯数字（0123456789），但是在一些国家依然保留使用本国数字的习惯，比如伊朗，阿富汗，尼泊尔，而埃及、苏丹和阿联酋，西方阿拉伯数字和东方阿拉伯数字并用。幸运的是西方阿拉伯数字变得越来越流行，连保守的沙特阿拉伯也开始慢慢接受它。

2.4.2 时间和日期

时间

不同区域使用时间格式习惯不一样。尽管UTC是通用的，但需注意时区转换，地区时间显示习惯是12小时制，还是24小时制，还有美国的冬令时和夏令时转换。

日期

不同国家地区有不同的时间显示方式。例如

中国：YYYY/MM/DD

美国：MM/DD/YYYY

英国：DD/MM/YYYY

或者有些格式把YYYY简化成YY。那么09/10/11在中国是09年10月11日，在美国是11年9月10日，在英国是11年10月9日。

日历

尽管世界上大部分地区都能理解公历，但是由于有些国家不使用西方阿拉伯数字，周几的排序不一致，节日也因国家而异，所以在设计时需要注意，特别是旅行类App, 节假日出行与日历联动性大。

2.4.3 货币

货币格式错误将会让用户对价格产生疑惑，这对产品来说是个致命错误。货币的格式在本地化产品中，需要注意三点：货币本身，该货币使用的地区，该货币使用的语言。处理货币符号和货币代码时候，需要整理归类去处理。以下举例一些常见格式问题：

注意货币符号的格式。货币符号是在数字的前面还是后面，数字与货币符号间是否有空格。每个国家显示方式不一样，例如：

美国（符号在前，不带空格） $399

比利时（符号在后，带空格） 399 €

荷兰（符号在前，带空格） € 399

在使用相同货币符号的国家，容易混淆货币价值。比如美国和加拿大，中国和日本，当一个加拿大人在一个美国网站购物时，如果看到$1099.99，他可能产生疑惑，不清楚这个价格到底是加元还是美元，这种情况下就可以加上货币代码，例如：

$1,099.29 USD

$1,099.29 CAD

这个方法会导致文案冗长，我的解决办法是在空间小的页面去掉货币代码，但是确保用户在一个闭环操作中，第一次见到和最后一次见到价格时，价格带上货币代码。

不是所有货币都能使用货币代码。比如欧元货币代码是独一无二的符号，欧元如果使用货币代码的格式是 1.099,29 € EUR，这里“EUR”是多余的。再比如瑞士法郎没有货币符号，CLDR建议使用货币代码作为货币符号。如果一个产品统一都使用货币代码，这意味着他们看到的瑞士价格是1.099,29 CHF CHF。

注意分割符号。比如在德国货币的格式里 , 和 . 是相反的，而法语里并不需要千位分割符号，所以英语的1,099.29 €，德语的格式应为1.099,29 €，法语的格式则是1099,29 €。

货币的格式应该跟着语言变化，而不是地域。如果用户在德国，使用欧元，但是使用英语浏览，那么他看到的格式是英语格式 1,099.29 €，而不是德语格式1.099,29 €

推荐工具 International Number Formats

这个地址可以帮你查询大部分国家的货币格式。

推荐工具 CLDR

如果你的产品业务涉及国家众多，那么协各种数据格式会非常麻烦，建议使用CLDR实现。CLDR是一个庞大的格式化样式数据库，包含了日期、数字、货币、语言、复数、性别、键盘布局等等内容，每年更新两次。但它并不是权威，每个人都可以添加数据到库并投票。由于它不断变化的特性，建议自行定义CLDR。

2.4.4 度量单位

在度量衡单位方面，绝大多数国家使用国际通用单位“米，千克，秒”制。但有少数国家保持特有单位，比如美国采用英制单位，如英里，英寸，加仑，盎司等。

值得注意的是使用习惯。即使在同一个国家，也会使用不同单位去测量同一维度的。比如，英国测量身高用英尺（Feet)+英寸（Inche)，测量地理距离用英里（Mile)，测量纸张用的是米制单位（metric）。

另外，即使同样使用英制单位的美国和英国，在同一个单位下，表示的量也不一样，比如，美国的Cup和英国的Cup表示的量就不一样。

2.5 个人信息表单设计

个人信息表单是在国际化和本土化项目中是变化比较多的内容。如果是在特定国家做表单，输入框尽可能和所填写内容长度相匹配是最优的体验设计方案，因为同一个地区的相同字段信息长度是可以预估的。在国际化表单中，内容，长度和顺序，都是不可预估的。下面根据实际情况归纳4个表单设计方案：

2.5.1 特定表单

适用于产品只服务于特定国家，或者产品数据能高度确保用户IP地址正确的情况下，选择当地常用表单格式，是最高效的方法。缺点：IP地址不能保证100%正确，用户也可能使用VPN，或者用户在另外一个国家操作。这几种情况下特定格式就不能满足用户需求。特定表单格式如下图：

2.5.2 可变换表单

适用于用户的IP地址已被确定，或者用户之前访问过你的网站或已选择过国家地区，在进入表单后，默认格式是该地区惯用格式。但是用户依然有选择变更国家地区的权利，变换国家后，表单格式会跟着地点变换。注意这种情况下，用户已填写的内容在变国家后不可删除。下图中当地区从加拿大改成香港后，姓名，省份，区域，城市，邮编的占位符文案都需要改变，并且城市从填空改成选择。

2.5.3 通用表单

通用表单指的是使用一个表单覆盖所有地区。这种表单的兼容性很高，这就需要合并一些相关性强的输入框，而且同一个输入框需要多个提示文案。用户有选择更改国家的权利，但是表单的格式不会根据用户的选择而改变。缺点：用户输入的内容格式多种多样，导致后台数据容易出错，并难以筛选排查。这种表单不能限制字符数量，不能强制用户填写州/省/区域和邮政编码，因为并不是所有国家都有这些内容，可以在后台做判断。

2.5.4 自动输入表单

使用Google Places 自动填写表单，可以建立在上述三种表单之上。下图案例建立在通用表单格式上，保留用户选择国家的权利，并把州/省/区域做成下拉列表，城市和详细地址自动联想输入，地址输入完成后邮编自动填写，电话号码区域代码也随国家而变。使用Gooogle places必须保留用户编辑权利，因为即使是Google也没办法覆盖全世界的地址并保证不出错。

另外值得注意的是，有些注重隐私的国家，给出过多的联想填写提示，用户会觉得你在侵犯他们的隐私。这时候易用性和用户感受就需要一个敏感的平衡。

推荐工具 Google Places

2.6 名字和称谓

名字和称谓出现的情景一般为两种，一个是表单填写，二是页面上或邮箱上的称谓。文化的多样性同时也导致了名字格式的多样性，要为每种名字格式做出完美的适配设计是十分困难的。这里提供几个方向的思路。

2.6.1 常见名字格式

首先了解下世界上常见的几种的名字的格式，例如：

先名后姓。中间可能有中间名，中间名缩写。这些国家有美国，英国等。
先姓后名。这些国家有中国，日本，韩国，匈牙利等。
父系名字。名字+父亲的名字，没有家族姓氏。这样的名字一般以名的首字母为序列排序。这些国家有冰岛，南印度，马来西亚，印度尼西亚等。
多姓名字。名字+父姓+母姓，名字+母姓+父姓，名字+多个祖先名字。这些多为西语国家，包括不说西班牙语的但被西班牙殖民过的国家，比如菲律宾(注意：不限于名字，在设计其他个人信息的格式时，也需要注意200年内被殖民过的国家地区，可能会跟同大区的其他国家使用不一样的格式）。
名字格式根据性别变化。性别不一样后缀就不一样。比如冰岛。俄国使用类似的名字比如名字+父亲衍生名+姓，但是姓会根据性别而改变后缀拼写。
婚后女士改变姓氏。随夫姓的比如美国，俄国，日本等。
混合名字。一些国家有复杂的起名系统，名字加入了头衔，地理位置，家族信息，种姓，宗教信息等。比如印度和阿拉伯等。
特殊称谓。有些地区的人不喜欢被叫真名，比如泰国人一般有昵称，德国和日本会在姓氏前加上职称为正式称呼，越南人用名+先生/女生作为正式称呼等。

2.6.2 常用名字表单格式

综上所述，在设计姓名表单时，可以根据数据储存要求，归纳为以下几种格式：

不需要分开储存名字和姓氏，给一个足够空间的全名输入框，如下：

需要分开储存名字和姓氏，提供两个输入框，但注意不同文化的姓和名的排序有可能不一样，所以需要用Family name, Other/given names 代替First name, Last name，以免引起歧义。

兼容多种文化，表单格式为一个全名输入框加一个代称输入框，这样做可以在不同姓名排序，或者没有姓氏的文化中，抽取代称首字母进行筛选排序，又可以避免有些人不乐意被直呼名字，也满足了类似泰国的昵称文化的需求。

除此之外的情景，比如带重音的拉丁名字，会出现同字不同音的日本名字，可以增加音译拉丁文表单；婚后女士改名，可以增加曾用名表单；名字里有单个字母，标点符号的，可以兼容填写;多星名字可以增加延展名字表单；多文化背景国家（如新加坡）使用多种类型表单等等。这些场景在普通产品出海中的需求中并不多见，严格的名字表单多数用于政府型产品。

2.7 联系方式

2.7.1 电话号码

每个国家地区的电话号码格式不一样，大多数国家都使用西方阿拉伯数字。如果用全部涉及国家使用同一套方案，不建议有格式区分。但为了提高用户体验，在落地本土化页面时，按照每个国家习惯的方式去展示，是最接近完美的做法。例如：

法国是按照两个数字一组展示，比如：01 23 45 67 89

英国是把数字分成3组展示，比如：01234 567 789

另外注意出海产品需要把国家代码加到号码前面，比如 +1 是美国电话，+44 是英国电话。

电话号码里有可能包含国家代码，地区分号，在特定地区把字段分开填写有助于提示和统计，但是在国际化表单设计时，建议设计一个整体的输入框，并给出区域代码提示。

2.7.2 地址

地址的使用场景一般是输入表单和已输入完成展示。在2.5.3通用表单中已经给出了国际化地址表单的统一设计方案。当你的产品可以按照特定表单去设计，这里总结出几个设计地址表单常见问题。

根据本地区惯用地址格式设计输入框顺序，比如美国从小到大，日本从大到小。通用表单一般按照从小到大设计。

注意专用名词，比如每个国家对省/州/县，邮政编码的称呼不一样，比如澳大利亚，加拿大。

没有省份的国家，可以去掉相应的输入框，比如德国。

当地址中的街道公寓单元楼层不知道如何分段，并且不是自动填写时，最好给出范例提示。

国家地区的填写方式分为3种类型：普通国家-只需输入国家名称，合众国-需要输入合众国+具体国家名字，比如United Kingdom-Scotland）, 自治区-只需输入自治区名字。

2.7.3 邮政编码

除了上文提到的邮政编码的称呼在每个国家地区可能不一样之外，邮政编码的属性分为3种类型：有邮编，比如加拿大；有邮编不强制使用，比如中国；没有邮编，比如阿拉伯。

Universal Postal Union 可以查询世界上每个国家地区的联系方式的格式，并介绍了格式里每行字段代表的意义。在设计表单前，可以先到这个网站查询该地区的具体联系方式格式。

推荐工具 Universal Postal Union

2.8 右向左设计

世界上大多数语言都是从左向右（LTR）阅读，也有一些语言是从右向左（RTL）阅读。比如作为全球第四大流行语言的阿拉伯语，60%的阿拉伯语使用者更倾向于使用阿拉伯语浏览网站。RTL语言有包括阿拉伯语，希伯来语，普什图语，波斯语，信德语，叙利亚语，迪维希语，乌尔都语，意第绪语等。从右向左（RTL）的语言环境中，阅读和书写会从右向左完成，这种改变会影响网站的结构，部分内容需要进行镜像处理。（这部分内容主要参考Material Design)

2.8.1 镜像元素

需要镜像的元素