产品在发展过程中，为了适配外国业务或是外国用户，将产品多语言化，是一个必经之路。在产品多语言化方向，有4条路径，简称“GILT”，即Globalization、Internationalization、Localization、Translation，不同的路径对应着企业产品不同的发展阶段。
1）全球化-G11N
2）国际化-I18N
国际化，简称“I18N”（Internationalization）。国际化是指企业产品在不依赖或受限于特定区域，可以在世界不同地区正常运行，不出现严重影响产品使用的错误，比如常见的软件乱码、界面错位、数据结构不支持等等。优秀的国际化产品，能够让产品在移植到其他区域时能够快速而健壮的使用，其初衷也是设计合理的多语言产品结构，服务能够覆盖更多的国家，这就需要在国际化设计过程中将“多语言资源”与“技术逻辑实现”相分离，便于本地化服务（如产品、营销等）的快速落地。优秀的国际化软件产品可以实现使用同一套代码逻辑在不同国家或地区进行发布和应用，如Google搜索、Facebook等，并不需要每到一个新地区就重新开发一个新版本。
3）本地化-L10N
本地化，简称“L10N”（Localization）。本地化，往往在国际化之后进行，指产品进入特定地区或国家时进行特殊优化的过程，如提供该地区或国家的语言、文字，或其他本地化服务等，以适配当地文化习惯与社会习惯，从而便于本地化业务的正常开展，如iPhone的Siri助手提供的功能服务。简单来说，本地化过程是将一种产品或服务进行改造适配，使之能够适应特定地域的过程。需要注意的是，设计本地化的产品，应该将对象或概念用当地所习惯的语言或方式来表达。
翻译是本地化流程中最基础的一个环节，但除了最基本的语言转译之外，还有诸多影响因素也会直接影响到产品本地化的成败。比如对书写和阅读顺序的考虑，我们常见的中英文都是LTR（left-to-right，从左往右的阅读顺序），但是在面对诸如阿拉伯语、波斯语、希伯来语为代表的语言时，产品设计与开发人员必须考虑到RTL（right-to-left，从右往左的阅读顺序）的阅读习惯，从而提前做好设计上的镜面对称调整。
文化因素，是产品本地化过程中不得不考虑的因素，极其重要。文化如果不匹配，那么产品想要落地就成了天方夜谭。比如在我国传统的投资观念中，红色代表上涨和发展，绿色代表下跌和衰退，而在一些欧美国家则是恰恰相反，且不同国家投资理财理念和认知都不同，如果欧美理财App直接移植到中国来，那这款产品极有可能失败。关于文化的理论框架介绍，见附2。
以麦当劳（McDonald’s）为例，介绍这家企业在全球化、国际化、本地化方面的表现。
全球化：麦当劳在超过100个国家和地区建立了超过3w+个门店餐厅；
国际化：麦当劳在拟定菜单时，需要采用当地的食材，并根据当地的口味习惯与饮食风格来指定菜单，这边是国际化策略中的一环；
4）翻译-T9N
多语言设计的意义在于能够让产品或服务更好地适应全球化的市场需求。随着世界经济的发展，越来越多的企业和组织面临着自家的产品需要跨越不同国家和地区的文化、语言差异的挑战。多语言设计可以帮助这些企业和组织更好地与不同语言和文化背景的客户和用户进行沟通和交流，从而提高产品或服务的用户体验和在市场上的竞争力。一般来说，产品设计支持语言能力，可以带来以下好处：
1）扩大市场覆盖面
通过提供多语言支持，产品或服务可以覆盖更广泛的市场，吸引更多的潜在客户和用户。对于C端市场来说，可以吸引更多普通用户，转化更多潜在的跨国消费者；对于B端产品来说，来自不同国家、文化、背景的职场同事相互协作，已日趋寻常，支持多语言能力，帮助产品覆盖更多企业客户。
2）提高用户满意度
针对不同语言和文化背景的用户提供本地化的用户体验，可以提高用户满意度、忠诚度、复购率等。
3）改善沟通效率
多语言设计可以消除语言障碍，提高与不同语言和文化背景的人士之间的沟通效率和质量。
4）提升品牌形象
提供多语言支持可以表明企业和组织对全球化市场的重视，并为其赢得更好的品牌形象和声誉。
多语言产品设计颇具挑战的事，涉及到多个方面。
1）文化差异
不同语言和文化之间存在差异，这些差异可能会对产品设计产生影响。例如，在某些文化中，颜色可能有不同的含义，而在有些文化中，符号的含义也不尽相同。比如，“”这个“OK”的手势，在中国以及大多数西方国家都会被理解为“肯定”或“同意”的意思，但在巴西和土耳其等地，这个手势是冒犯的象征，代表着不雅的含义。因此，多语言产品设计需要考虑到这些文化差异，以确保产品在不同文化中的适用性和可接受性。在实际落地过程中，需尽量避免存在争议的文化标识或符号。
2）多语言产品设计
多语言产品的界面设计必须保持更加通用，用户切换语言时，前后体感需控制在合理范围内的差异。多语言产品设计，往往会涉及诸多注意事项，比如：
这些往往会直接带来布局和设计问题，是多语言设计过程中不可忽视的挑战。
3）翻译和本地化
4）维护和更新
当产品需要进行更新和维护时，需要考虑到不同语言和文化之间的差异。如果产品更新或修复仅适用于某些语言或文化，那么可能会导致其他语言或文化中出现问题。因此，在维护和更新产品时，需要考虑到多语言的情况。
本文主要介绍的是针对应用而言，开发的多语言项目。但是对于终端系统来说，本身往往也是支持多语言的，比如iOS、Android等。这两者之间的区别可以从以下几方面予以了解：
1）配置方法
系统多语言是基于手机操作系统的语言设置，当在手机的系统设置中更改语言后，所有支持这种语言的应用都会更改到这种语言。而App内置的多语言是基于每个单独应用的设置，可以在应用的设置中更改语言，而这个更改只影响这个应用。
2）覆盖范围
系统多语言可以影响手机中所有支持的应用和手机界面的语言。然而，App内置的多语言只影响特定的应用程序。
3）灵活性
对于用户来说，App内置的多语言提供了更高的灵活性。如果用户针对某App更喜欢区别于其他应用的语言，那么App内置的多语言则会更加灵活友好。
4）开发难度
1）确定目标客户和目标语言
多语言产品的目标客户是基于公司的产品战略来决定的。常见的目标客户有2类：
无论是C端还是B端领域，国内的多语言产品项目，更多的是属于第2类。多余没有多语言产品项目的团队，在语种的支持方面，建议优先实践对英语的支持。
2）设计产品文案
在设计产品时，需要针对多语言进行针对化的设计调整，包括页面布局、按钮标签、菜单项、提示信息、错误信息等。针对多语言产品，其中需要注意的事项非常多，在后文详细介绍页面和文案设计过程中，其他语言与中文的区别。
3）翻译与本地化
确定目标语言后，需要将对应的中文翻译成目标语言，这个过程有条件的团队可以使用专业的翻译管理平台，没条件的团队可以直接外包给翻译机构，市面上有很多专门给国内产品做多语种翻译的公司和组织。无论是哪种方式，首先都需要将产品中的中文梳理出来，这个环节需要产品和研发协作输出，后文在多语言实现逻辑章节会详细介绍。
本地化，则是指目标语言在对应的目标市场和目标客户所在的文化背景下进行合适的调整和修改，以保证自家产品语言的表达对多语言和文化的尊重，同时保证产品在目标市场中的可用性和易用性。
4）多语言功能实现
一般来说，多语言功能在用户侧的最终呈现，是用户在产品上切换语种的时候，产品界面就会切换到对应的语言。这个过程涉及多语言文案的管理、多语言文件的管理与加载，甚至包括多语言文件的热更新。同样地，这些环节会在多语言实现逻辑章节会详细介绍。
这里需要注意的是，多语言产品的测试和上线是产品开发过程中必不可少的重要环节，其目的是确保产品的质量和稳定性，并使产品能够顺利地上线和被用户使用。在多语言产品能力发布前，需要经过彻底的测试，包括界面测试、功能测试、兼容性测试，甚至本地化测试。
在上线发布过程中，如有必要，需考虑一些几方面
5）多语言项目维护
多语言项目不是一个一劳永逸的工作，团队将产品的多语言能力发布后，后续是需要持续维护的，包括随着产品迭代，不断优化调整和新增对应的文案内容，更新本地化信息，同时也包括即时处理多语言问题和用户的反馈。
多语言产品的文案管理是指对产品中的文字内容进行翻译和管理，以适应不同语言环境下的用户需求。上文提到，文案内容的翻译可以使用专业的翻译管理平台，常见的提供多语言管理和翻译服务的专业平台有：Transifex、Crowdin、Lokalise、Phrase，或者外包给专业的翻译机构。一般来说，在设计多语言产品的文案管理流程时，需要考虑以下步骤：
1）文案梳理
将产品中所有涉及到目标语种的原语种（中文）内容，全部梳理出来。如果是与翻译机构合作，文案一般梳理沉淀到Excel中，翻译机构会提供模版，己方也可以基于模版扩展部分自己所需要的字段列。
2）文案审核
需要注意的是，对于新的文案内容（即增量文案内容），需要进行审核以确保其符合产品的标准和要求。
3）翻译与校对
对于需要翻译的文案内容，需要找到专业的翻译人员进行翻译，并进行翻译质量的检查。如果使用专业的翻译管理平台，其实需要较多的人力资源介入，并且需保证这些人员的高度协同；国内企业，更常见的是外包给专业的翻译机构。翻译完成后，需要进行校对以确保翻译的准确性和流畅度。
4）文案交付
翻译机构翻译完成后，将内容交付给产品团队。产品团队需要基于交付的文案做二次微调，以满足产品本身的语境和调性。将调整后的文案内容导入多语言管理平台。
5）应用更新
导出最新的多语言文件（一般一个语种对应一个文件），并通过技术调用，应用到产品中。
说明：
不同国家和地区的产品设计，其逻辑往往不尽相同，接下来，从元素设计、习惯设计和界面设计等三方面予以介绍。
1)数字体系
世界上数字体系不仅仅有阿拉伯数字体系「0-9」，还有很多其他的数字体系正在被使用，不过即便存在使用其他数字体系的地区，由于阿拉伯数字体系被广泛使用，如今各国家和地区也都能理解「0-9」的数字概念。
数字体系
2)语言文字
语言支持
跟随系统设置是一个较为保险的方案，Facebook、Google等产品一般都选这个方案。但一般产品难以覆盖足够多的语言种类，从用户的角度来看，一旦系统语言未匹配成功，还有自行更改为用户第二语言的可能，这样更为灵活。
语言与国旗
大小写
在产品支持多语言过程中，需要考虑各语言体系下文字大小写导致的语义差别。举例说明：
除了上面由于大小写导致的语义差别外，在大小写方面，还需要考虑以下三方面的问题：
因此，为了防止出现类似的问题或者错误，如果涉及到程序转换大小写的情况，一定要先判断语言类型。
字体
在多语言设计过程中，界面文字尽量采用系统默认匹配的字体，防止用户出现预设字体缺失的情况。
另外，不是所有的字体都内含了粗体和斜体，虽然部分软件或系统提供了算法加粗或倾斜，但效果较差，部分语言的强制粗体或斜体也会导致可读性下降，如中文的斜体会降低可读性。所以，在设计产品时，建议少用或不用粗体和斜体。在一些特殊情况下，如一定需要将特殊字体进行展示，建议将特殊字体转换为图片的方式进行展示，如banner图中的部分营销字体。
除了粗体和斜体，在国际化过程中，同样不建议直接大面积使用下划线。因为下划线原本是应用于网页的超链接，不推荐应用于移动端产品；除此之外，下划线会与某些语种文字相冲突，比如天城文(天城文常用于印地语、梵语、尼泊尔语等)天然内含文字基线。
标点符号
首先，需要说明的是标点符号并不是国际各地区通用的，下面从几个方面予以阐述：
不同国家或地区，对同一符号的表示往往不尽相同。比如双引号：
某些标点在不同语言中样式不同，如逗号：
某些标点使用方法不同，如西班牙文中的叹号和问号需前后使用：
总的来说，在产品支持多语言过程中，需要就标点符号制定本地化的适配策略。
3)语言顺序
我们常见的语言顺序都是从左往右（LTR，left-to-right），即便有图标和文字结合的情况下，也是图标位于最左侧，然后是从左往右的文字
在世界大部分地区，如亚洲和欧美等诸多地区，都是遵循的LTR语言顺序；与之不同的是，在中东地区，存在多个国家的官方语言是遵循RTL（RighttoLeft，从右到左）的书写和阅读逻辑，这些国家语言包括：阿拉伯语、希伯来语、波斯语、乌尔都语、意第绪语、迪维西语，如下图所示：
这些语言的普遍特征有：
中东地区石油经济强劲，使用这些语言的人口数量也是相当大，如果产品需要在中东地区做本地化，则RTL的语言问题是不可避免的。
4)姓名称谓
在国际化时，人名的构成顺序，应尊重“原名序”（本地语呈现的原初顺序）。人名结构的顺序，应按用户当地习俗真实的顺序，以当地语言书写。
目前，名字的顺序分为两类：东方序和西方序。下面从“顺序”和“结构”两个方面来介绍名字。
首名(firstname)：东方序为姓(familyname)，西方序为名(givenname)；
末名(lastname)：东方序为名(givenname)，西方序为姓(familyname)；
东方序常见为“先姓后名”，主要在亚洲和部分非洲地区，匈牙利也是遵循“先姓后名”（这个比较特殊）。西方序常见为“先名后姓”，主要在西欧、美洲、澳大利亚、新西兰等国家使用使用。
为了表达尊重，一般在国际化过程中，可以不对人名进行翻译，使用用户原本的名字即可（前提是产品逻辑支持），但是不同的人名，其文字长度不一样，这会给页面空间提出一定的要求，具体在页面设计章节进行阐述。若用户给自己取了本地化的姓名后，则可以直接使用即可。不过，在翻译的时候，尤其要注意，切忌直接机翻，举几个错误的示例（出现这种情况的历史原因是英国早期普遍以职业为姓）：
5)账号注册
日期
世界上绝大部分地区都能理解限行的公历历法，产品日期数据以公历为即可，但是不同的地区有不同的记录和呈现方式，这是需要注意的，比如：
在产品国际化过程中，需要涉及到用户填写手机号，是无法强迫用户记住或理解自己国家的国际冠码和区号的，常见的方式是与国旗做关联映射，实现国际冠码和区号自动补全，而用户只需要填写自己国内的封闭手机号即可。
8)货币数字
不同国家，其货币符号和货币汇率也不相同，在构建国际化策略时，数字与货币的产品显示逻辑是极其重要的。主要包括以下五个方面：
当货币金额较大时，为了方便阅读小数点前后的数字，往往会对数字进行分组，国际上语言里最常见的数字读法是千位分位，写法的分组也是在千位数上。如果当地习俗是用句点（“.”）作小数点，千位的分号一般是逗号（“,”）或空格；如果习俗里小数点是逗号，千位分号一般是句点或空格。比如，中国使用“,”作为千分位间隔，“.”作为小数点，而德国恰好相反，举例如下：
正是因为这一点，产品国际化过程中，需要针对货币的显示逻辑进行合理优化。不过，为了避免混淆或者歧义，国际标准建议，国际度量衡局更是要求使用空格来进行千位数分组，而不是小数点或句点。
货币符号
目前常见的货币符号有：
在国际化过程中，货币符号是很容易犯错的一点，主要原因是货币符号和国家并不是一一对应的关系。举几个小案例：
很多产品在国际化的时候，把货币符号与国家或者国旗对应起来了，如葡萄牙用户在选择本国结算货币类型时，只能选择“€”或“Germany€”，这便是失败的设计，且容易引起政治问题?/p>
因此，在表示一个国家的货币时，不建议直接使用货币符号，建议货币采用ISO4217标准定义的代号，或者采用国家名称，如人民币可以采用由ISO4217定义的“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)合规许可
除了数据隐私，在国际化和本地化过程中，商标、知识产权、市场许可是进入一个目标市场必须考虑的法律问题。根据产品或服务的业务形态，需要考虑细分场景的法律规章。
进入目标市场涉及到的合规性问题，是企业市场部门的职责。在前期调研和沟通过程中，确定获取当地运营所需要的各类知识产权和市场许可，了解并遵循当地市场的法律要求，在出现问题时及时与政府交涉。
1)使用习惯
同样场景或领域的产品，不同国家用户的使用习惯不同，在做产品国际化过程中，需要根据产品需求制定灵活的方案以适应不同背景的用户群体。
(1)以Airbnb为例介绍不同背景用户在预订民宿房源的不同产品逻辑
国内出行，大部分用户对于民宿的接纳和包容度尚不及酒店，还是习惯于预订酒店的思维逻辑；而欧美地区用户对民宿的概念已经植根于生活，他们的民宿体系也相对更加成熟和完善。不同文化背景的用户，其行为习惯的不同导致同一款产品在设计逻辑上也不尽相同。
(2)以Amazon为例介绍中美地区不同用户浏览电商网站的习惯
如下图所示，Amazon美国地区的产品设计，首页是以商品卡片流的方式呈现的，降低了多余信息输入和干扰；Amazon中国地区的产品设计，首页是以Banner区+品类入口+商品或主题推荐的方式呈现，和国内大部分电商App布局一致，符合国人喜欢“逛”，喜欢在不同的类目中去选择自己想要的商品的诉求。
3)偏好习惯
不同国家或地区对颜色、角色、风格喜好不相同，不同领域产品在国际化策略中，产品逻辑不同：
1)界面多语言
界面多语言是指页面中各模块固定的文字或说明支持多语言显示，比如：首页-Home、设置-Setting、账户-Account、推荐-Recommendation、筛选-Filter、排序-Sort、工作台-Work、语言-Language、通用-General、…这部分文字显示往往需与系统设置的语种保持同步。
在界面多语中，往往需要专业翻译机构针对不同语种进行翻译，并由以对应语种为母语的专业人员进行核查一遍。这里需要注意的是，尽量使用官方无歧义的措辞，少用俚语、地区方言等。
除此之外，也要谨防一些界面文字翻译不彻底从而导致的“不伦不类”的情况，即一个页面存在多种语言（文字图标logo除外）：
2)内容多语言
内容多语言往往指非常显或者动态生成的内容支持多语言，具体展示语种同步系统设置，常见的有：
3)多语言布局
空间布局
不同语种环境下，在表达相同意思时，语言文字的长度和空间占比也是不同的。国际化过程中最常见的问题便是翻译后的文字和预留空间之间的矛盾，这将导致某些语言的界面不可用或者难以使用，或者是文字正常了界面却乱了，如下图所示：
面对以上情况，常见的解决方法有三种：
参考：基于汉字长度的文字预留空间（如下表）
文字与组件
涉及到文字与组件的组合时，建议采用将文字与组件分隔的排版方式，不建议将文字与组件进行混合拼接，如下图所示：
接下来，聚焦于国内产品在已有产品服务的基础上新增其他语种，对多语言产品的实现予以介绍。
1)梳理确定范围
构建产品多语言能力的第一步就是需要确定需要支持多语言的文案范围。如果从0开始设计产品，在确定需要支持多语言能力之后，在每一次迭代中，需要基于产品设计文档，将涉及到支持多语言的文案内容梳理出来，用于后续翻译。如果从现有产品开始规划多语言能力，这个过程的文案梳理会相对复杂。
**存量文案：**存量文案，是之前产品中已有的功能中需要翻译的文案内容。盘点存量文案范围，需要产品和研发共同协作。
**增量文案：**增量文案，是未来进行产品迭代所涉及到的功能中所包含的文案内容。
在梳理前，先创建一个文案表格，建议包含以下几列：
文案表格主要用于前期文案管理和翻译项目的协作，在这个基础上，我们可以开始梳理范围。考虑到不是从0开始设计产品，建议直接由产品研发共同参与，完成文案的收集工作。
**产品经理梳理：**产品同学先将各页面可见的文案梳理出来。
**研发梳理：**技术人员是通过代码检查的方式，找出那些直接硬编码在代码中的文本。这些文本可能在页面中不可见或者是被忽略的文案，但在产品实际使用时却会被用户看到，因此也是需要梳理的对象。关于文案收集，市面上有一些相对成熟的检查工具，可以批量检查并导出代码中的硬编码字符串，比如IDE（如AndroidStudio或Xcode）的检查工具，或者使用正则表达式遍历搜索。
梳理出来的文案，录入文案表中。上述产品研发配合梳理，可以覆盖绝大部分的文案内容，对于极少数文案内容，可以通过后期的测试环境或者线上使用反馈予以覆盖。
2**)文案翻译**
文案翻译，常见的方式有3种：
将翻译完的多语言文本内容同样录入文案表对应的列中。
3**)文案审查**
这部分主要是将翻译完成的文案内容，基于产品的风格和文化，做一些微调，主要包括长度、用词方式等方面，以更好更恰当的适配产品表达。这部分工作主要有公司的产品和设计团队完成。
将文案翻译完成之后，需要为每一段文案分配一个唯一的Key（键值），用于在代码中引用这段文案。需要注意的是，同一段文案对应的多个语种内容，共用同一个Key，其主要作用是标记文案的唯一性，且不建议修改。
设置Key的时候，需要遵守一定的规范：
多语言管理中台工具，是一个管理多语言文案的中心，可以借助开源工具或者自研。其主要作用有：
1）管理多语种、多语言文案以及对应的Key值
允许将完成翻译的文案内容批量导入管理系统中，并支持编辑、添加、删除多语言键值对等操作。
2）翻译工具
可以引入机器翻译的能力，比如Google、百度、ChatGPT等能力。这样，后续迭代过程中的新增文案，可以结合机器翻译和存量文案的翻译方式及风格，实现翻译工作在产研内部的自闭环。当然，更严谨的方式，依然是借助专业的平台或者机构服务。
3）生成各类语种的多语言文件
基于管理的多语言内容资源，生成团队所需要的多语言文件(通常是JSON或XML格式)，并由研发导入到代码工程中，以便发布后，实现多语言调用。多语言JSON文件是一个包含Key和对应语种文案的键对值组合，下面是一个简单的English示例。
json复制代码{ "en":{ "welcome_message":"Welcometoourapp!", "login_button":"Login", "signup_button":"Signup" }}4）提供调用服务
5）版本管理
可以管理多语言文件的历史版本，这样可以方便查看以前版本的翻译，并可以回滚到以前的翻译版本。
多语言切换的实现路径：切换语言→确定Key→判断语种→请求并显示译文。
1）Key的导入
代码通过调用Key值来访问多语言文案资源的前提是在代码对应的模块得知道调用哪个Key，即调用之前，需要将对应的Key传入正确的代码位置，这个工作由研发主导，往往需要手动地在代码中一个个地替换硬编码的字符串为对应的多语言Key引用。考虑到需要在大量的代码位置插入对应的多语言Key，为了提高效率和准确性，下方是一些建议：
使用自动化工具
有些IDE（如AndroidStudio、VisualStudioCode等）提供了一些自动化工具，通过使用这些专门的工具来扫描并查找代码中硬编码的字符串，并将其替换为本地化Key的引用，这个是较为常用的方式。在实践中，开发者在需要显示这段文本的地方，使用本地化库提供的函数或者方法，传入这个Key。例如，在Android中，可以使用“getString(key)”方法。
模块化和复用
如果应用有一些通用的文案，如"确定"、"取消"等，则可以为这些文案定义一些通用的Key，然后在多个地方复用。这样，就可以减少在代码中插入Key的次数。当然，诚如上文所说，这样做的前提是这部分文案内容基本不调整。
设计好的代码结构
一个设计好的代码结构可以更容易地进行本地化。例如，可以将所有的文案都放在一些集中的位置，如专门的文案管理类中，而不是分散在各处的逻辑代码中。
逐步替换
如果应用文案内容非常庞大，一次性进行全面的替换可能会很困难，则可以考虑逐步替换，按照优先级，先替换最重要或者最常见的部分，然后逐步扩大范围。
2）多语言文案的显示原理
多语言文案的显示原理是当用户切换语言时，程序代码开始运行，系统会根据当前的语言设置，从多语言文件中查找这个Key对应的文本。如果找到了，就显示这个文本；如果没有找到，通常会显示原语言内容，比如中文对应的文案。
在多语言实践过程中，有两种方式实现对多语言文案内容的调用，分别是非热更新方式和热更新方式。
非热更新方式
非热更新的方式，其实是文件传入的方式，这需要将多语言文件导入对应的代码模块，这样便可以基于Key去调用对应的多语言资源。如果多语言内容有更新，这种方式往往需要通过应用发版的方式，对多语言能力进行迭代。
热更新方式
多语言文件的热更新一般需要远程服务器和本地的配合，下面是一般的实现原理和逻辑：