万字复盘：多语言产品设计实践

一、多语言基础

1、多语言基本概念

产品在发展过程中，为了适配外国业务或是外国用户，将产品多语言化，是一个必经之路。在产品多语言化方向，有 4 条路径，简称“GILT”，即 Globalization、Internationalization、Localization、Translation，不同的路径对应着企业产品不同的发展阶段。

1）全球化 - G11N

全球化，简称 "G11N"（Globalization）。 在技术层面，全球化代表的是一套从产品、研发到全球营销落地的完整产品与服务流程，从国际视野出发，关注从产品研发管理、市场营销、售后服务，乃至国际贸易等各个环节的相互关联和整体布局，在一定程度上包含了“国际化”和“本地化”的内容，含义更加广泛，商业属性明显；从操作层面，全球化涉及的具体内容包括不限于供应链条、渠道合作、售后服务、仓储物流、特许经营、合规通关等等。 优秀的全球化实践是为了向不同地区的用户提供更好的“客户旅程（Customer Journey）”体验，美国的诸多优质企业在全球化方面表现出色，如苹果公司（Apple）、麦当劳公司（McDonald’s）、亚马逊公司（Amazon）、网飞公司（Netflix）、优衣库（UNIQLO）。以苹果公司为例，它雇用全球人才设计研发电子硬件和软件产品，整合世界范围内的供应链及代加工工厂资源，为其生产品牌产品，然后在世界各国进行产品市场营销和具有当地特色的渠道和物流合作，为消费者提供产品售卖和售后支持等服务。 全球化的好处是显而易见的，充分提升了世界各地资源的利用率，对全球经济也有正面影响。全球化为企业扩展全球市场提供了方向和途径，但是对公司产品及其品牌的综合实力也是一种极大的考验。

2）国际化 - I18N

国际化，简称“I18N”（Internationalization）。 国际化是指企业产品在不依赖或受限于特定区域，可以在世界不同地区正常运行，不出现严重影响产品使用的错误，比如常见的软件乱码、界面错位、数据结构不支持等等。 优秀的国际化产品，能够让产品在移植到其他区域时能够快速而健壮的使用，其初衷也是设计合理的多语言产品结构，服务能够覆盖更多的国家，这就需要在国际化设计过程中将“多语言资源”与“技术逻辑实现”相分离，便于本地化服务（如产品、营销等）的快速落地。优秀的国际化软件产品可以实现使用同一套代码逻辑在不同国家或地区进行发布和应用，如 Google 搜索、Facebook 等，并不需要每到一个新地区就重新开发一个新版本。

3）本地化 - L10N

本地化，简称“L10N”（Localization）。 本地化，往往在国际化之后进行，指产品进入特定地区或国家时进行特殊优化的过程，如提供该地区或国家的语言、文字，或其他本地化服务等，以适配当地文化习惯与社会习惯，从而便于本地化业务的正常开展，如 iPhone 的 Siri 助手提供的功能服务。简单来说，本地化过程是将一种产品或服务进行改造适配，使之能够适应特定地域的过程。需要注意的是，设计本地化的产品，应该将对象或概念用当地所习惯的语言或方式来表达。

本地化和国际化是相辅相成的两个关联过程，一个产品在具备国际化的内核与架构之后，本地化相关的工作才能得以展开，产品服务本地化过程中，需要注意的基本要点（包括但不限于）有：

• 语言

翻译是本地化流程中最基础的一个环节，但除了最基本的语言转译之外，还有诸多影响因素也会直接影响到产品本地化的成败。比如对书写和阅读顺序的考虑，我们常见的中英文都是 LTR（left-to-right，从左往右的阅读顺序），但是在面对诸如阿拉伯语、波斯语、希伯来语为代表的语言时，产品设计与开发人员必须考虑到 RTL（right-to-left，从右往左的阅读顺序）的阅读习惯，从而提前做好设计上的镜面对称调整。

• 文化本地化

文化因素，是产品本地化过程中不得不考虑的因素，极其重要。文化如果不匹配，那么产品想要落地就成了天方夜谭。比如在我国传统的投资观念中，红色代表上涨和发展，绿色代表下跌和衰退，而在一些欧美国家则是恰恰相反，且不同国家投资理财理念和认知都不同，如果欧美理财 App 直接移植到中国来，那这款产品极有可能失败。关于文化的理论框架介绍，见附 2。

• 功能本地化

功能上的本地化调整，也往往会决定一个产品在一个特定市场内的表现。如一款带有支付功能的App 产品进入中国，但是只支持Apple Pay，而不支持支付宝和微信支付，或只支持Visa和Mastercard，但不支持银联，相信一定会在支付环节劝退大部分中国用户；同样的，如果欧美用户在一个社交平台上想要分享内容时，只能选择微博和微信，那这款产品的功能无论在本土表现多么优秀出色，在海外也一定会遭遇失败。

• 合规

除了软件方面的本地化适配之外，几乎所有产品都必须要做大量合规性的准备工作以适应不同地域的各种标准和规范。比如我们生活中常见的港版产品，配的都是英制的三脚插头，需要搭配适配器才能使用；比如苹果原来宣称在新推出的产品包装盒中将不再标配电源适配器或者EarPods耳机，当时一直被人所诟病，但 iPhone 12 发布后法国成为了例外，原因是法国法律规定在法国销售的每一部智能手机都需要附送耳机（或免提套件），以方便人们在拨打电话时选择免提通话从而降低电磁波辐射。因此为了符合法国的这一市场准入要求，法国版的 iPhone 12 将附带其他版本已经取消的earPods。

以麦当劳（McDonald’s）为例，介绍这家企业在全球化、国际化、本地化方面的表现。

全球化：麦当劳在超过 100 个国家和地区建立了超过 3w+ 个门店餐厅；

国际化：麦当劳在拟定菜单时，需要采用当地的食材，并根据当地的口味习惯与饮食风格来指定菜单，这边是国际化策略中的一环；

本地化：在中国，麦当劳优先支持微信和支付宝支付；在印度，麦当劳不提供肉类餐厅，因为印度大部分人不吃牛肉或猪肉；在以色列，安息日和犹太节日，麦当劳不营业；

4）翻译 - T9N

翻译，简称“T9N”（Translation）。 国际化有一个分支方向是只处理语言，简称“M17N”（Multilingualization），即仅支持语言层面的多样化，这个过程便涉及到语言的翻译。比如企业微信支持：简体中文、繁體中文、English

2、多语言产品设计的意义

多语言设计的意义在于能够让产品或服务更好地适应全球化的市场需求。随着世界经济的发展，越来越多的企业和组织面临着自家的产品需要跨越不同国家和地区的文化、语言差异的挑战。多语言设计可以帮助这些企业和组织更好地与不同语言和文化背景的客户和用户进行沟通和交流，从而提高产品或服务的用户体验和在市场上的竞争力。一般来说，产品设计支持语言能力，可以带来以下好处：

1）扩大市场覆盖面

通过提供多语言支持，产品或服务可以覆盖更广泛的市场，吸引更多的潜在客户和用户。对于 C 端市场来说，可以吸引更多普通用户，转化更多潜在的跨国消费者；对于 B 端产品来说，来自不同国家、文化、背景的职场同事相互协作，已日趋寻常，支持多语言能力，帮助产品覆盖更多企业客户。

2）提高用户满意度

针对不同语言和文化背景的用户提供本地化的用户体验，可以提高用户满意度、忠诚度、复购率等。

3）改善沟通效率

多语言设计可以消除语言障碍，提高与不同语言和文化背景的人士之间的沟通效率和质量。

4）提升品牌形象

提供多语言支持可以表明企业和组织对全球化市场的重视，并为其赢得更好的品牌形象和声誉。

3、多语言设计的挑战

多语言产品设计颇具挑战的事，涉及到多个方面。

1）文化差异

不同语言和文化之间存在差异，这些差异可能会对产品设计产生影响。例如，在某些文化中，颜色可能有不同的含义，而在有些文化中，符号的含义也不尽相同。比如，“👌”这个“OK”的手势，在中国以及大多数西方国家都会被理解为“肯定”或“同意”的意思，但在巴西和土耳其等地，这个手势是冒犯的象征，代表着不雅的含义。因此，多语言产品设计需要考虑到这些文化差异，以确保产品在不同文化中的适用性和可接受性。在实际落地过程中，需尽量避免存在争议的文化标识或符号。

2）多语言产品设计

多语言产品的界面设计必须保持更加通用，用户切换语言时，前后体感需控制在合理范围内的差异。多语言产品设计，往往会涉及诸多注意事项，比如：

• 文字长度的差异
• 符号含义的差异
• 汇率的差异
• 不同的语法和语言结构差异
• ……

这些往往会直接带来布局和设计问题，是多语言设计过程中不可忽视的挑战。

3）翻译和本地化

产品文案的内容翻译、管理，以及本地化实践往往会伴随着高昂的时间成本和费用成本。产品本地化需要考虑到特定地区和国家的文化、语言和习惯用法等因素。

4）维护和更新

当产品需要进行更新和维护时，需要考虑到不同语言和文化之间的差异。如果产品更新或修复仅适用于某些语言或文化，那么可能会导致其他语言或文化中出现问题。因此，在维护和更新产品时，需要考虑到多语言的情况。

4、 系统多语言和应用多语言

本文主要介绍的是针对应用而言，开发的多语言项目。但是对于终端系统来说，本身往往也是支持多语言的，比如iOS、Android 等。这两者之间的区别可以从以下几方面予以了解：

1）配置方法

系统多语言是基于手机操作系统的语言设置，当在手机的系统设置中更改语言后，所有支持这种语言的应用都会更改到这种语言。而App内置的多语言是基于每个单独应用的设置，可以在应用的设置中更改语言，而这个更改只影响这个应用。

2）覆盖范围

系统多语言可以影响手机中所有支持的应用和手机界面的语言。然而，App内置的多语言只影响特定的应用程序。

3）灵活性

对于用户来说，App内置的多语言提供了更高的灵活性。如果用户针对某 App 更喜欢区别于其他应用的语言，那么App内置的多语言则会更加灵活友好。

4）开发难度

对于开发者来说，系统多语言通常更简单，因为这是由操作系统自动处理的，开发者只需要在代码中指定不同语言的资源即可，这个开发过程会涉及相关的资源分离，比如文本字符串、日期、时间格式等（如果没有做资源分离，那么系统多语言对App 应用就不会生效）。而App内置的多语言则需要开发者自行设计语言切换的逻辑。

5、多语言项目的产品设计流程

1）确定目标客户和目标语言

多语言产品的目标客户是基于公司的产品战略来决定的。常见的目标客户有 2 类：

• 直接面向海外市场，直接提供国际化的产品服务，比如字节的 TikTok和 DIDI 海外版
• 立足国内，基于一个产品主体，同时为国内外的用户提供服务，比如支付宝

无论是 C 端还是 B 端领域，国内的多语言产品项目，更多的是属于第 2 类。多余没有多语言产品项目的团队，在语种的支持方面，建议优先实践对英语的支持。

2）设计产品文案

在设计产品时，需要针对多语言进行针对化的设计调整，包括页面布局、按钮标签、菜单项、提示信息、错误信息等。针对多语言产品，其中需要注意的事项非常多，在后文详细介绍页面和文案设计过程中，其他语言与中文的区别。

3）翻译与本地化

确定目标语言后，需要将对应的中文翻译成目标语言，这个过程有条件的团队可以使用专业的翻译管理平台，没条件的团队可以直接外包给翻译机构，市面上有很多专门给国内产品做多语种翻译的公司和组织。无论是哪种方式，首先都需要将产品中的中文梳理出来，这个环节需要产品和研发协作输出，后文在多语言实现逻辑章节会详细介绍。

本地化，则是指目标语言在对应的目标市场和目标客户所在的文化背景下进行合适的调整和修改，以保证自家产品语言的表达对多语言和文化的尊重，同时保证产品在目标市场中的可用性和易用性。

4）多语言功能实现

一般来说，多语言功能在用户侧的最终呈现，是用户在产品上切换语种的时候，产品界面就会切换到对应的语言。这个过程涉及多语言文案的管理、多语言文件的管理与加载，甚至包括多语言文件的热更新。同样地，这些环节会在多语言实现逻辑章节会详细介绍。

这里需要注意的是，多语言产品的测试和上线是产品开发过程中必不可少的重要环节，其目的是确保产品的质量和稳定性，并使产品能够顺利地上线和被用户使用。在多语言产品能力发布前，需要经过彻底的测试，包括界面测试、功能测试、兼容性测试，甚至本地化测试。

• 界面测试：测试产品在多语言切换过程中，界面内容是否可以正常展示，是否出现显示异常
• 功能测试：对产品的各项功能进行测试，以确保其符合需求和设计
• 兼容性测试：测试产品在不同的浏览器、操作系统和设备上的兼容性，以保证可以正常使用
• 本地化测试：多语言切换过程中，产品是否满足目标客户的社会习惯、文化背景等

在上线发布过程中，如有必要，需考虑一些几方面

• 服务器和域名：需要选择适合不同地区的服务器和域名，以提高产品的访问速度和稳定性
• CDN加速：多语言产品往往会服务于国内外客户，为了提高国内外用户的访问速度，可以使用CDN加速服务
• SEO优化：如果产品上线发布到对应语种的境外应用市场，建议针对不同语言和地区的搜索引擎进行优化，提高产品在各个地区的搜索排名
• 域名解析：针对不同地区和语言环境进行域名解析，以确保产品能够准确地被访问，比如微软官网地址“www.microsoft.com/zh-cn” ，后面的“zh-cn”指的便是中国地区。

5）多语言项目维护

多语言项目不是一个一劳永逸的工作，团队将产品的多语言能力发布后，后续是需要持续维护的，包括随着产品迭代，不断优化调整和新增对应的文案内容，更新本地化信息，同时也包括即时处理多语言问题和用户的反馈。

说明：由于每个公司的业务结构与配合模式的差异性，多语言项目的开展流程也不尽相同。更常见的情况，公司产品的多语言项目，可能不是一个单独的部门或组织可以全部搞定的，需要与产品相关的各个业务或者部门共同参与进来，在多语言项目实现的各个环节去贡献自己应有的职责。

6、多语言项目的文案管理流程

多语言产品的文案管理是指对产品中的文字内容进行翻译和管理，以适应不同语言环境下的用户需求。上文提到，文案内容的翻译可以使用专业的翻译管理平台，常见的提供多语言管理和翻译服务的专业平台有：Transifex、Crowdin、Lokalise、Phrase，或者外包给专业的翻译机构。一般来说，在设计多语言产品的文案管理流程时，需要考虑以下步骤：

1）文案梳理

将产品中所有涉及到目标语种的原语种（中文）内容，全部梳理出来。如果是与翻译机构合作，文案一般梳理沉淀到 Excel 中，翻译机构会提供模版，己方也可以基于模版扩展部分自己所需要的字段列。

2）文案审核

需要注意的是，对于新的文案内容（即增量文案内容），需要进行审核以确保其符合产品的标准和要求。

3）翻译与校对

对于需要翻译的文案内容，需要找到专业的翻译人员进行翻译，并进行翻译质量的检查。如果使用专业的翻译管理平台，其实需要较多的人力资源介入，并且需保证这些人员的高度协同；国内企业，更常见的是外包给专业的翻译机构。翻译完成后，需要进行校对以确保翻译的准确性和流畅度。

4）文案交付

翻译机构翻译完成后，将内容交付给产品团队。产品团队需要基于交付的文案做二次微调，以满足产品本身的语境和调性。将调整后的文案内容导入多语言管理平台。

5）应用更新

导出最新的多语言文件（一般一个语种对应一个文件），并通过技术调用，应用到产品中。

说明：

• 在与国内翻译机构合作的过程中，一般是按照千字收费标准（300-1000 元/千字），机构内有国内从事英语翻译的员工，也有国外目标母语的员工，在翻译和校对过程，对应的服务和费用不同。翻译合作项目开始前，需缴纳一定的定金，交付完成后，缴纳尾款以及开具发票。
• 考虑到单个词汇或句子，翻译成目标语言，往往有多重方式。这里强烈建议己方产品团队，基于公司产品的业务场景和产品调性，将翻译机构提供的翻译内容做二次微调后，再予以应用。
• 产品团队内部需提供一个多语种文案管理平台，一方面，用于管理多语言翻译文案，且可以基于该平台对多语言文件进行导出，从而应用到产品中。另一方面，对于部分重复的增量内容的翻译，可以直接在该平台上搜索并复用对应的译文，提升产品迭代效率的同时，也可以降低翻译成本。

二、多语言产品及界面设计

不同国家和地区的产品设计，其逻辑往往不尽相同，接下来，从元素设计、习惯设计和界面设计等三方面予以介绍。

1、多语言元素设计

常见地，相同的母语文案，在翻译成其他语言时，文案的长度是不一样的，这会导致类似 button 错位和长度显示异常的问题。下面，从数字体系、语言文字、语言顺序、姓名称谓、账号注册、日期时间、电话区号、货币数字、邮政编码、发票报销、税率制度、度量单位、数据隐私以及合规许可等多方面多多语言产品设计过程中的元素注意实现予以详细介绍。

1) 数字体系

世界上数字体系不仅仅有阿拉伯数字体系「0 - 9」，还有很多其他的数字体系正在被使用，不过即便存在使用其他数字体系的地区，由于阿拉伯数字体系被广泛使用，如今各国家和地区也都能理解「0 - 9」的数字概念。

数字体系

2) 语言文字

语言支持

英语是世界第一大语言，国内产品国际化的第一步，便是支持英文，有助于在第一时间覆盖最广泛的区域，并且规避一些全球化的问题。。而实际上，在用户切换语言的能力支持方面，往往会提供两种选择：1）跟随系统设置；2）能够在应用内部自主选择界面语言。

跟随系统设置是一个较为保险的方案，Facebook、Google等产品一般都选这个方案。但一般产品难以覆盖足够多的语言种类，从用户的角度来看，一旦系统语言未匹配成功，还有自行更改为用户第二语言的可能，这样更为灵活。

语言与国旗

与货币符号一样，一个国家的语言和国旗也不是一一对应关系。美国和英国都说英语，英语和哪个国家的国旗相关联呢？类似地，葡萄牙和巴西都说葡萄牙语。因此，尽管在选择效率上会有所提升，产品国际化设计过程中，也必须要将语种与国旗分离，否则容易较差的用户体验感问题。

大小写

在产品支持多语言过程中，需要考虑各语言体系下文字大小写导致的语义差别。举例说明：

• 在俄语中，一周中的名称不能首字母大写，如果将「星期三 среда」首字母大写，含义就变为「环境 Cреда」；
• 英语中的“瓷器：china”与“中国：China”；

除了上面由于大小写导致的语义差别外，在大小写方面，还需要考虑以下三方面的问题：

• 某些语言的大写字母与小写字母不是一一对应的。例如，希腊语中的 Σ 的小写形式根据位置的不同，有两种书写形式： σ 或 ς。
• 有些字符根据语言不同，有不同的大小写映射关系。例如，英语中 i 对应的大写是 I ，但在土耳其语中却各有其大小写： ı 与 I、i 与 İ，如果对 i 进行大写转换，那么一定要先判断语言类型，再进行转换。
• 大多数非拉丁字母不适用小写和大写的概念。例如，汉字、谚文、泰文、阿拉伯字母等，如果强制对这类文字进行大小写转换，可能导致意外的字符或乱码出现。

因此，为了防止出现类似的问题或者错误，如果涉及到程序转换大小写的情况，一定要先判断语言类型。

字体

在多语言设计过程中，界面文字尽量采用系统默认匹配的字体，防止用户出现预设字体缺失的情况。

另外，不是所有的字体都内含了粗体和斜体，虽然部分软件或系统提供了算法加粗或倾斜，但效果较差，部分语言的强制粗体或斜体也会导致可读性下降，如中文的斜体会降低可读性。所以，在设计产品时，建议少用或不用粗体和斜体。在一些特殊情况下，如一定需要将特殊字体进行展示，建议将特殊字体转换为图片的方式进行展示，如 banner 图中的部分营销字体。

除了粗体和斜体，在国际化过程中，同样不建议直接大面积使用下划线。因为下划线原本是应用于网页的超链接，不推荐应用于移动端产品；除此之外，下划线会与某些语种文字相冲突，比如天城文 (天城文常用于印地语、梵语、尼泊尔语等) 天然内含文字基线。

标点符号

首先，需要说明的是标点符号并不是国际各地区通用的，下面从几个方面予以阐述：

• 地区标点符号

不同国家或地区，对同一符号的表示往往不尽相同。比如双引号：

• 中国大陆地区：“ ”
• 中国港澳地区：『 』
• 英语地区：" "
• 德语地区：,, "
• 语言标点样式

某些标点在不同语言中样式不同，如逗号：

• 简体中文 U + 3001（居左下）
• 繁体中文 U + 3001（居中）
• 英文 U + 002C
• 阿拉伯文 U + 060C
• 标点使用方法

某些标点使用方法不同，如西班牙文中的叹号和问号需前后使用：

• ¡Hola!
• ¿Qué edad tienes?
• 某些标点不能放置于行首或行尾，如中文里逗号不在行首，前引号不在行尾；
• 某些语言不使用空格作为词间间隔，如中文、日文、泰文；
• 某些语言基本不使用或是很少使用标点符号，如泰文、天城文、文言文等。

总的来说，在产品支持多语言过程中，需要就标点符号制定本地化的适配策略。

3) 语言顺序

我们常见的语言顺序都是从左往右（LTR，left-to-right），即便有图标和文字结合的情况下，也是图标位于最左侧，然后是从左往右的文字

在世界大部分地区，如亚洲和欧美等诸多地区，都是遵循的 LTR 语言顺序；与之不同的是，在中东地区，存在多个国家的官方语言是遵循 RTL（Right to Left，从右到左）的书写和阅读逻辑，这些国家语言包括：阿拉伯语、希伯来语、波斯语、乌尔都语、意第绪语、迪维西语，如下图所示：

这些语言的普遍特征有：

• 句子从右到左阅读
• 事件发展顺序从右到左进行
• 左箭头 “←” 表示向前运动，右箭头 “→” 代表向后运动，比如返回的 icon 就需要放在右边

中东地区石油经济强劲，使用这些语言的人口数量也是相当大，如果产品需要在中东地区做本地化，则 RTL 的语言问题是不可避免的。

4) 姓名称谓

在国际化时，人名的构成顺序，应尊重“原名序”（本地语呈现的原初顺序）。人名结构的顺序，应按用户当地习俗真实的顺序，以当地语言书写。

目前，名字的顺序分为两类：东方序和西方序。下面从“顺序”和“结构”两个方面来介绍名字。

• 顺序维度：首名(first name)、中名(middle name)、末名(last name)；
• 结构维度：姓氏(family name)、名(forename，有本名/父名/教名)；

首名(first name)：东方序为姓(family name)，西方序为名(given name)；

末名(last name)：东方序为名(given name)，西方序为姓(family name)；

东方序常见为“先姓后名”，主要在亚洲和部分非洲地区，匈牙利也是遵循“先姓后名”（这个比较特殊）。西方序常见为“先名后姓”，主要在西欧、美洲、澳大利亚、新西兰等国家使用使用。

• “姓 + 名”，如汉族、朝鲜族、日本人名、越南人名、匈牙利人名
• “名 + 姓” or “名 + 中间名 + 姓”，如欧美人名
• “昵称 + 本名 + 别号 + 父名 + 族名”，如阿拉伯人名
• “类汉姓 + 名 + 姓 + 氏”，如满族人名

为了表达尊重，一般在国际化过程中，可以不对人名进行翻译，使用用户原本的名字即可（前提是产品逻辑支持），但是不同的人名，其文字长度不一样，这会给页面空间提出一定的要求，具体在页面设计章节进行阐述。若用户给自己取了本地化的姓名后，则可以直接使用即可。不过，在翻译的时候，尤其要注意，切忌直接机翻，举几个错误的示例（出现这种情况的历史原因是英国早期普遍以职业为姓）：

• Baker：贝克 vs 面包师
• Carpenter：卡彭特 vs 木匠
• Smith：史密斯 vs 铁匠
• Toper：托伯 vs 酒鬼
• Tailor：泰勒 vs 裁缝

5) 账号注册

由于国家环境和社会发展阶段不同，西方国家拥有了相对完整的 PC 互联网时代，所以几乎每个人都有一个邮箱，且有高频查阅邮箱的习惯，他们的诸多产品账号注册也都是基于邮箱进行的。

进入移动互联网时代后，国外产品在进行国际化时，依然保留了邮箱的注册方式，在不同的国家也会针对性增加手机号的方式（需要与国际区号结合）。中国进入 PC 互联网时代相对较晚，使用邮箱的比例不高，尤其是没有受过高等教育的群体。进入移动互联网后，国内手机短时间内迅速普及，手机号几乎人手一个，国内的大量应用开启了手机号注册账号的阶段，也有部分产品提供了邮箱注册的逻辑。不同国家的产品账号注册，考虑用户的使用习惯和便捷程度，采用的是因地制宜的策略。

在产品国际化过程中，建议支持“邮箱 + 手机号”的组合注册方式。邮箱的注册逻辑比较统一，不做赘述。手机号注册，需要企业对接对应国家或地区的网络运营商资源，且需要考虑相关地区的基站信号覆盖。

6) 日期时间

日期

世界上绝大部分地区都能理解限行的公历历法，产品日期数据以公历为即可，但是不同的地区有不同的记录和呈现方式，这是需要注意的，比如：

• 年/月/日 - YYYY/MM/DD
• 日/月/年 - DD/MM/YYYY
• 月/日/年 - MM/DD/YYYY

时间

产品在国际化过程中，需要有完备的通用时间体系，考虑时间的同事还需考虑到时区。通用的方法是采用世界标准时间，即 UTC 时间（Universal Time Coordinated），然后在本地化过程进行时间换算，主要有两点：

• 采用通用的 API 进行时间处理
• 统一使用基于 UTC 的时钟进行后端运算，将结果转换为用户前台本地时间展示

不过还有一点需要注意，世界各地的每周休息日可能不同，每周的第一天也可能不同，产品如果涉及到日历排班等相关服务，则需要重点考虑。

7) 电话区号

国际电话区号是根据国际电信联盟（ITU）的 E.123 和 E.164 标准分配而来，拨打国际电话号码的顺序为：国际冠码 - 国际电话区号 - 封闭电话号码。

国际冠码是电话区号前面的前缀“+”，这个“+”也可以用“00”来代替，即国际冠码就是“+”或“00”，比如我的完整电话号码为：+ 86 187 **** 2721 或 00 86 187 **** 2721，其中“86”是中国的国际电话区号。这里需要说明的是，“00”是 ITU 推荐的国际冠码，被包括中国大陆在内的多数国家所采用，也有许多国家采用其他的国际冠码。

国际电话区号则是按照区域分配的，如下图所示，一个颜色块代表一个区域，区号的第一个数字与地区是一一对应的，中国的国际电话区号是“86”，第一个数字是“8”，代表东亚及部分东南亚地区。

在产品国际化过程中，需要涉及到用户填写手机号，是无法强迫用户记住或理解自己国家的国际冠码和区号的，常见的方式是与国旗做关联映射，实现国际冠码和区号自动补全，而用户只需要填写自己国内的封闭手机号即可。

8) 货币数字

不同国家，其货币符号和货币汇率也不相同，在构建国际化策略时，数字与货币的产品显示逻辑是极其重要的。主要包括以下五个方面：

标点符号

当货币金额较大时，为了方便阅读小数点前后的数字，往往会对数字进行分组，国际上语言里最常见的数字读法是千位分位，写法的分组也是在千位数上。 如果当地习俗是用句点（“.”）作小数点，千位的分号一般是逗号（“,”）或空格；如果习俗里小数点是逗号，千位分号一般是句点或空格。比如，中国使用“,”作为千分位间隔，“.”作为小数点，而德国恰好相反，举例如下：

• ￥1,234.50：1234 元 + 0.5 元
• €1.234,50：1234 欧元 + 0.5 欧元

正是因为这一点，产品国际化过程中，需要针对货币的显示逻辑进行合理优化。不过，为了避免混淆或者歧义，国际标准建议，国际度量衡局更是要求使用空格来进行千位数分组，而不是小数点或句点。

货币符号

目前常见的货币符号有：

• $：元，如美元、澳元
• £：镑，由英国及其自治领土所用
• Fr：法郎，并多由法语圈国家采用
• Kr：克朗，多由北欧国家采用
• €：欧元，注意，使用欧元的国家未必位于欧元区
• Rs：卢比，使用国家多为英国于南亚的前保护国或殖民地
• Sh：先令，使用国家多为英国在东非的前殖民地
• 其他：￥、₩(韩元、朝鲜元)、RM(令吉，马来西亚)、…

在国际化过程中，货币符号是很容易犯错的一点，主要原因是货币符号和国家并不是一一对应的关系。举几个小案例：

• ￥：中国、日本
• $：美国、巴拿马、荷兰、……
• €：德国、葡萄牙、芬兰、希腊、……
• ₩：韩国、朝鲜

很多产品在国际化的时候，把货币符号与国家或者国旗对应起来了，如葡萄牙用户在选择本国结算货币类型时，只能选择“🇩🇪 €”或“Germany €”，这便是失败的设计，且容易引起政治问题。

因此，在表示一个国家的货币时，不建议直接使用货币符号，建议货币采用 ISO 4217 标准定义的代号，或者采用国家名称，如人民币可以采用由 ISO 4217 定义的“CNY”。

辅助单位

货币辅助单位是区别于本币却又与本币存在转换和计算关系的本国货币计算单位，比如 0.5 元 = 5 角 = 50 分，这里的“角”和“分”都是货币辅助单位，在进行产品国际化时，尽量换算成本币计算，又比如 80 撒丹应该记作 0.8 泰铢。

符号与数字

不同的货币，其符号与数字金额的位置也不尽相同，比如很多英语国家，会习惯把货币符号放在金额前面，如£50.00，不过也有许多国家把货币符号放在金额后面，如 50.00Fr，这个也是国际化过程中需要注意的。

货币结算

当一个产品同时服务于多个国家用户时，在产品上提供一个不同国家货币显示的机制，是用户的刚需，其底层逻辑便是货币基于实时的汇率换算。

另外，当产品涉及货币结算时，需要对不同货币的结算逻辑予以支持，比如需要产品本身支持不同币种的结算，需要对接对应地区的支付结算服务商，需要对接地区银行等。

9) 邮政编码

邮政编码，又称邮编区号，是国家或地区为达到邮件分拣自动化和邮政网络数字化，加快邮件快递速度，而把全国进行划分的方式。邮政编码，最早由乌克兰发明，于 1932 年 12 月启用，三年后废弃，后来德国将其再次采用。全球大部分国家或地区的邮政系统都使用邮政编码，也有少数例外，如爱尔兰、巴拿马、牙买加、我国香港都不使用邮政编码。在全球范围内，一些网站产品在做信息登记时，必须输入邮政编码，如果没有，可以用“全 0”代替。

软件产品在国际化过程中，若涉及与邮政编码相关的服务（如物流等），如果邮政编码是个必要数据，则建议提供邮政编码产品查询工具。

10) 发票报销

境外的发票不像国内一样是需要正规的税务监制的发票，有时候就是一张购物小票，或是一张收据，然后凭借小票或收据进行报销。基于此需求，美国诞生了公司 Expensify（已于 2021 年 11 月在纳斯达克上市），这是一家面向企业的费用管理服务平台，支持通过网站及移动应用导入费用清单，Expensify 如今也集成到明星创业公司 Brex 产品中。

在中国，由于特殊国情(比如纳税人基数巨大)，税务局通过“以票管税”等控制手段以实现避免偷税漏税，这个过程中便诞生了发票。发票，是中国特有的一个产物。

在产品国际化过程中，国内的发票模式不适合移植出去，但是如果仅在语言而非业务层面支持发票的国际化，则需要仔细斟酌相关专业名词，因为国外用户对中国的发票逻辑相对陌生。

11) 税率制度

税法在很多国家都是很复杂且不相同的，在同一个国家和地区税收负担对不同群体也是不同的。如果涉及到税率方面的产品，在国际化过程中需支持不同的税率制度。

12) 度量单位

在计量单位方面，以“米 - 千克 - 秒”制为基础的国际单位制应用于绝大部分国家地区，仅美国地区使用美式英制单位，如英里、英寸、加仑、盎司。

13) 数据隐私

各个国家和地区对用户隐私数据安全有着越来越严格的标准。

产品在进入其他国家地区时，企业法务需对其数据隐私法律法规做针对性的深入了解，并在产品逻辑中予以体现，以便准入对应的国家和地区。最好的方式是从底层架构便开始考虑数据隐私保护，并遵循当地法律法规，灵活调整。

另外，随着用户被不断的教育，产品向客户索要不必要的系统权限，是容易遭受用户抵制的，不利于产品的长期发展。

14) 合规许可

除了数据隐私，在国际化和本地化过程中，商标、知识产权、市场许可是进入一个目标市场必须考虑的法律问题。根据产品或服务的业务形态，需要考虑细分场景的法律规章。

进入目标市场涉及到的合规性问题，是企业市场部门的职责。在前期调研和沟通过程中，确定获取当地运营所需要的各类知识产权和市场许可，了解并遵循当地市场的法律要求，在出现问题时及时与政府交涉。

2、多语言习惯设计

1) 使用习惯

同样场景或领域的产品，不同国家用户的使用习惯不同，在做产品国际化过程中，需要根据产品需求制定灵活的方案以适应不同背景的用户群体。

(1) 以 Airbnb 为例介绍不同背景用户在预订民宿房源的不同产品逻辑

• 中国逻辑：打开 Airbnb → 输入目的地/日期/人数 → 搜索房源
• 欧美逻辑：打开 Airbnb → 选择出行方式 → 输入日期 → 出行人数 → 搜索房源

国内出行，大部分用户对于民宿的接纳和包容度尚不及酒店，还是习惯于预订酒店的思维逻辑；而欧美地区用户对民宿的概念已经植根于生活，他们的民宿体系也相对更加成熟和完善。不同文化背景的用户，其行为习惯的不同导致同一款产品在设计逻辑上也不尽相同。

(2) 以 Amazon 为例介绍中美地区不同用户浏览电商网站的习惯

如下图所示，Amazon 美国地区的产品设计，首页是以商品卡片流的方式呈现的，降低了多余信息输入和干扰；Amazon 中国地区的产品设计，首页是以Banner区 + 品类入口 + 商品或主题推荐的方式呈现，和国内大部分电商 App 布局一致，符合国人喜欢“逛”，喜欢在不同的类目中去选择自己想要的商品的诉求。

2) 分享习惯

不同国家用户在分享习惯与国内的可用分享媒体或渠道相关。比较常见的有：

• 国内：微信、QQ、微博、朋友圈
• 日韩：Line、KaoKao Talk
• 欧美/东南亚：Facebook、Snapchat、Twitter、LinkedIn、Instagram、WhatsApp、Telegram

3) 偏好习惯

不同国家或地区对颜色、角色、风格喜好不相同，不同领域产品在国际化策略中，产品逻辑不同：

• 对于跨境电商来说，售卖的商品具有地域特色；
• 对于报销产品来说，报销逻辑具有地区差异性；
• 对于软件App 来说，默认头像风格也不相同；

3、多语言界面设计

1) 界面多语言

界面多语言是指页面中各模块固定的文字或说明支持多语言显示，比如：首页 - Home、设置 - Setting、账户 - Account、推荐 - Recommendation、筛选 - Filter、排序 - Sort、工作台 - Work、语言 - Language、通用 - General、… 这部分文字显示往往需与系统设置的语种保持同步。

在界面多语中，往往需要专业翻译机构针对不同语种进行翻译，并由以对应语种为母语的专业人员进行核查一遍。这里需要注意的是，尽量使用官方无歧义的措辞，少用俚语、地区方言等。

除此之外，也要谨防一些界面文字翻译不彻底从而导致的“不伦不类”的情况，即一个页面存在多种语言（文字图标 logo 除外）：

2) 内容多语言

内容多语言往往指非常显或者动态生成的内容支持多语言，具体展示语种同步系统设置，常见的有：

• 弹框
• 消息通知，包括站内通知、站外推送
• 评论

3) 多语言布局

空间布局

不同语种环境下，在表达相同意思时，语言文字的长度和空间占比也是不同的。国际化过程中最常见的问题便是翻译后的文字和预留空间之间的矛盾，这将导致某些语言的界面不可用或者难以使用，或者是文字正常了界面却乱了，如下图所示：

面对以上情况，常见的解决方法有三种：

• 预留足够的空间，并设置文字溢出情况的处理方法(不建议直接采用缩写或者“…”方式)
• 转换表达方式，进行简洁化处理（以不产生歧义为前提）
• 重新设计页面/模块/元素布局

参考：基于汉字长度的文字预留空间（如下表）

文字与组件

涉及到文字与组件的组合时，建议采用将文字与组件分隔的排版方式，不建议将文字与组件进行混合拼接，如下图所示：

三、多语言产品实现

上文介绍了多语言产品设计的相关背景和注意事项。产品支持多语言，包括了国际化和本地化，整体来说，这是一个相当复杂的工程。

接下来，聚焦于国内产品在已有产品服务的基础上新增其他语种，对多语言产品的实现予以介绍。

1、多语言文案翻译

1) 梳理确定范围

构建产品多语言能力的第一步就是需要确定需要支持多语言的文案范围。如果从 0 开始设计产品，在确定需要支持多语言能力之后，在每一次迭代中，需要基于产品设计文档，将涉及到支持多语言的文案内容梳理出来，用于后续翻译。如果从现有产品开始规划多语言能力，这个过程的文案梳理会相对复杂。

**存量文案：**存量文案，是之前产品中已有的功能中需要翻译的文案内容。盘点存量文案范围，需要产品和研发共同协作。

**增量文案：**增量文案，是未来进行产品迭代所涉及到的功能中所包含的文案内容。

在梳理前，先创建一个文案表格，建议包含以下几列：

• Key：默认为空，后期赋值并绑定
• 中文：文案本身的内容，对于我们来说就是中文要翻译的内容
• 文案目标语言：即需要翻译成的目标语言，比如 English，如果要支持多种语言，则需要多列。这一列内容，需要翻译人员输入
• 文案路径：文案所在的页面路径，同时可存储于多语言文案管理平台中 (后文详细介绍)，该列是非必要的，只是为了便于文案管理
• 文案环境：建议贴上文案所在页面的截图，以便了解该文案的语境，帮助更好的翻译，该列同样是非必要的，目的是帮助翻译人员更好的理解和翻译文案

文案表格主要用于前期文案管理和翻译项目的协作，在这个基础上，我们可以开始梳理范围。考虑到不是从 0 开始设计产品，建议直接由产品研发共同参与，完成文案的收集工作。

**产品经理梳理：**产品同学先将各页面可见的文案梳理出来。

**研发梳理：**技术人员是通过代码检查的方式，找出那些直接硬编码在代码中的文本。这些文本可能在页面中不可见或者是被忽略的文案，但在产品实际使用时却会被用户看到，因此也是需要梳理的对象。关于文案收集，市面上有一些相对成熟的检查工具，可以批量检查并导出代码中的硬编码字符串，比如 IDE （如Android Studio或Xcode）的检查工具，或者使用正则表达式遍历搜索。

梳理出来的文案，录入文案表中。上述产品研发配合梳理，可以覆盖绝大部分的文案内容，对于极少数文案内容，可以通过后期的测试环境或者线上使用反馈予以覆盖。

2**) 文案翻译**

文案翻译，常见的方式有 3 种：

• 翻译平台服务：使用专业的翻译管理平台，比如Transifex、Crowdin、OneSky等
• 翻译机构合作：与翻译公司或者机构开展翻译项目合作，当然如果公司有足够的资源，可以构建自己的翻译服务团队
• 机器翻译：使用 Google、百度、ChatGPT 等方式实现翻译。对于前期的大量存量文案翻译工作，不建议这种方式，后期产品的迭代可以结合已翻译的文本风格和机器翻译的方式进行翻译，有利于节省成本。

将翻译完的多语言文本内容同样录入文案表对应的列中。

3**) 文案审查**

这部分主要是将翻译完成的文案内容，基于产品的风格和文化，做一些微调，主要包括长度、用词方式等方面，以更好更恰当的适配产品表达。这部分工作主要有公司的产品和设计团队完成。

2、 多语言文本 Key 的设置

将文案翻译完成之后，需要为每一段文案分配一个唯一的Key（键值），用于在代码中引用这段文案。需要注意的是，同一段文案对应的多个语种内容，共用同一个 Key，其主要作用是标记文案的唯一性，且不建议修改。

设置 Key 的时候，需要遵守一定的规范：

• 唯一性：每一个Key都应该是唯一的，不能重复。这是最基本的要求。一段文案对应一个唯一的Key，用户在应用内切换语种时，通过 Key 可以找到对应的文案。
• 描述性：好的 Key 应该能够描述这段文案的含义或者用途，尽量避免使用过于抽象或者无意义的Key。这样不仅可以帮助产品和研发更好地理解这段文案的用途，也可以在某种程度上方便翻译人员理解文案的含义。比如一个按钮的文案是“提交”，那么这个文案的 Key 可以是 "submit_button"。
• 结构性：如果一个界面或者功能有很多相关的文案，那么可以考虑为这些文案的Key设置一个共同的前缀，表示它们的归属或者关系。例如，如果一个登录界面有用户名、密码、登录按钮等文案，那么这些文案的Key可以分 是"login_username"、"login_password"、"login_button"等。
• 语言和字符限制：通常，Key 的字符集限制为ASCII字符，且不含特殊字符。至于长度，一般没有硬性规定，但出于易读性和管理的考虑，不建议设置过长的Key。
• 避免使用文案内容作为Key：据调研，一些早期的多语言实践中，直接使用英文文案作为Key，如 “submit”：“提交”。这种做法在文案需要修改时会带来问题，因为一旦英文文案改变，Key也需要改变，这将导致代码中所有引用这个Key的地方都需要修改。所以，现代的多语言项目中，通常不推荐使用文案内容作为Key，而单独设置 Key 值，即便这个 Key 值恰好和文案的英文译文一致。

注意，如果不同的页面有相同的文案内容，在设置 Key 的时候，可以使用同一个 Key，也可以为每个文案单独设置一个 Key，比如登录页和修改密码页都有“密码”，两者可以都使用“password”，也可以前者使用“login_password”而后者使用“change_password”。这种方式可以减少代码冗余，但是如果使用同一个 Key，那么未来这两个文案如果仅其中一个发生了调整，那么对应的 Key 和调整后的文案可能就失去“描述性”关系了。如果使用两个独立的 Key，可以通过加前缀的方式实现，带来弹性灵活好处的同时却也有不够精简的问题。面对这种情况，Key 值的选择策略仁者见仁智者见智。

3、多语言管理平台工具

多语言管理中台工具，是一个管理多语言文案的中心，可以借助开源工具或者自研。其主要作用有：

1）管理多语种、多语言文案以及对应的 Key 值

允许将完成翻译的文案内容批量导入管理系统中，并支持编辑、添加、删除多语言键值对等操作。

2）翻译工具

可以引入机器翻译的能力，比如 Google、百度、ChatGPT 等能力。这样，后续迭代过程中的新增文案，可以结合机器翻译和存量文案的翻译方式及风格，实现翻译工作在产研内部的自闭环。当然，更严谨的方式，依然是借助专业的平台或者机构服务。

3）生成各类语种的多语言文件

基于管理的多语言内容资源，生成团队所需要的多语言文件(通常是 JSON 或 XML 格式)，并由研发导入到代码工程中，以便发布后，实现多语言调用。 多语言 JSON 文件是一个包含 Key 和对应语种文案的键对值组合，下面是一个简单的 English 示例。

json
复制代码
{
	"en":{
		"welcome_message": "Welcome to our app!",
		"login_button": "Login",
		"signup_button": "Sign up"
	}
}

4）提供调用服务

对于多业务多应用的团队和组织，该平台可以提供相关的 API，以允许多个应用直接调用平台内的多语言资源，这样无需每个应用团队都单独维护一套多语言资源，从而提效的同时实现了大幅降本。

5）版本管理

可以管理多语言文件的历史版本，这样可以方便查看以前版本的翻译，并可以回滚到以前的翻译版本。

4、多语言产品实现原理

多语言切换的实现路径：切换语言 → 确定 Key → 判断语种 → 请求并显示译文。

1）Key 的导入

代码通过调用 Key 值来访问多语言文案资源的前提是在代码对应的模块得知道调用哪个 Key，即调用之前，需要将对应的 Key 传入正确的代码位置，这个工作由研发主导，往往需要手动地在代码中一个个地替换硬编码的字符串为对应的多语言 Key 引用。考虑到需要在大量的代码位置插入对应的多语言 Key，为了提高效率和准确性，下方是一些建议：

使用自动化工具

有些IDE（如Android Studio、Visual Studio Code等）提供了一些自动化工具，通过使用这些专门的工具来扫描并查找代码中硬编码的字符串，并将其替换为本地化Key的引用，这个是较为常用的方式。在实践中，开发者在需要显示这段文本的地方，使用本地化库提供的函数或者方法，传入这个Key。例如，在Android中，可以使用 “getString(key)” 方法。

模块化和复用

如果应用有一些通用的文案，如"确定"、"取消"等，则可以为这些文案定义一些通用的Key，然后在多个地方复用。这样，就可以减少在代码中插入Key的次数。当然，诚如上文所说，这样做的前提是这部分文案内容基本不调整。

设计好的代码结构

一个设计好的代码结构可以更容易地进行本地化。例如，可以将所有的文案都放在一些集中的位置，如专门的文案管理类中，而不是分散在各处的逻辑代码中。

逐步替换

如果应用文案内容非常庞大，一次性进行全面的替换可能会很困难，则可以考虑逐步替换，按照优先级，先替换最重要或者最常见的部分，然后逐步扩大范围。

2）多语言文案的显示原理

多语言文案的显示原理是当用户切换语言时，程序代码开始运行，系统会根据当前的语言设置，从多语言文件中查找这个 Key 对应的文本。如果找到了，就显示这个文本；如果没有找到，通常会显示原语言内容，比如中文对应的文案。

在多语言实践过程中，有两种方式实现对多语言文案内容的调用，分别是非热更新方式和热更新方式。

非热更新方式

非热更新的方式，其实是文件传入的方式，这需要将多语言文件导入对应的代码模块，这样便可以基于 Key 去调用对应的多语言资源。如果多语言内容有更新，这种方式往往需要通过应用发版的方式，对多语言能力进行迭代。

热更新方式

多语言文件的热更新一般需要远程服务器和本地的配合，下面是一般的实现原理和逻辑：

• 远程服务器：首先，需要一个远程服务器来存储所有的本地化资源文件。当有新的语言版本发布时，可以上传新的本地化资源文件到服务器。服务器需要能够处理这些上传的文件，并能根据客户端的请求返回相应的文件。
• 本地缓存：在应用程序中，需要一个地方来存储从服务器下载的本地化资源文件。这个地方可以是文件系统，也可以是数据库。在加载本地化资源时，应用程序应该优先使用缓存中的文件，如果缓存中没有找到，再使用默认的本地化资源文件。
• 文件下载：应用程序需要在合适的时机（例如启动时，或者用户手动刷新时）从服务器下载本地化资源文件。下载的文件应该被保存到本地缓存中。
• 文件解析：应用程序需要能够解析从服务器下载的这些文件，并将解析后的数据用于本地化。
• 错误处理：在热更新过程中，可能会遇到各种问题，例如网络错误，文件解析错误等。应用程序需要能够处理这些错误，并在必要时恢复到默认的本地化资源。
• 数据同步：为了避免每次启动应用程序都需要下载所有的本地化资源文件，可能需要一个数据同步机制。只有在服务器上的数据有变化时，才需要下载新的数据。
• 应用热重启：当应用程序从服务器获取到新的多语言文件并存储在本地后，需要在不关闭应用的情况下将新的本地化资源文件加载到内存中，并应用到当前的用户界面上。这可能需要一种特殊的机制来实现 (例如React的Context或者Flutter的InheritedWidget)，因为大多数的UI框架在初始化时只加载一次本地化资源。

---

— END —

你好，我是江同学，5年以上产品经理

职场过来人，有过创业经历，深谙产品逻辑和商业逻辑

专注分享产品知识技能