从0到1的产品国际化设计指南：工作流篇

一、背景

国际化(internationalization)通常缩写为"i18n"，这是因为在这个单词中，"i`和'n之间有18个字母。这种缩写方法在技术领域非常常见，因为它可以大大减少长单词的长度，同时保持其易识别性。其他类似的缩写这种缩写方法不仅仅用于国际化，还有其他一些长单词也采用了类似的缩写方法。例如：

1. L10n：本地化(Localization)，L和n之间有10个字母。
2. a11y：无障碍(Accessibility)，a和y之间有11个字母。

为什么使用这种缩写?

1. 简洁：缩写可以大大减少长单词的长度，使得代码和文档更加简洁。
2. 易读：在技术文档和代码中，长单词可能会让人困惑或增加阅读难度。缩写可以让内容更加易读和易理解。
3. 通用性：这些缩写在技术社区中已经被广泛接受和使用，大家都能明白其含义。

下面是一段关于"本地化"与"国际化"非常生动的解释：

国际化与本地化的关系类似于势能与动能的关系。国际化提供了适应本地市场的潜力，而本地化则将这种潜力转化为现实。没有国际化，本地化就没有发挥作用的余地。没有本地化，国际化就只是一种有待实现的潜力。

更多干货：

二、目标

业务上以最低成本完成翻译工作，独立的国际化版本 islands 在应用商店上架

以最高复用性、最大通用性，完成出海诉求，做好本地化支持（泰国TH、越南VN、新加坡SG、马来西亚MY）

三、解决方案

1. 国际化包含哪些工作呢？

前端

一个所见即所得的翻译后台

设计

1. 翻译工作流
2. 跨部门工作流 i18n 工作流，产品、设计 ? 客户端 ?后端

客户端工作

1. 确保支持unicode编码，这样文字不会乱码
2. 代码和资源文件（界面词）的分离，如果代码和资源文件混在一起，即所谓“硬编码”，单纯将其中的界面词替换成另一种语言将造成一系列的问题
3. Key 的实时更新

未来本地化包含哪些工作？

1. 确保可以通过选择或者读取系统设置来正确显示各类本地化的元素
2. 支持本地的格式，如日期、时间、日历、数字、地址等方面的格式
3. 游戏、软件厂商的国际化问题

看其他公司的经验，本地化团队，说起国际化，大多挺无奈。对于刚出海的公司，开发团队基本没有国际化意识，导致本地化团队在发售deadline已经很紧的情况下，还要和各种无法预测的突发情况作斗争，比如：

1. 硬编码无规律地夹在代码中，无法通过自动化手段抽取，只能手动修改，一个语言还好，若是多语言版本发布，只能熬夜修改
2. 不知为何，产品经理将界面文案竖着写，海外版得重新设计（见过竖着写的英文吗？）
3. 游戏文案多处用文言文，很难翻译，硬翻出来不仅贵，效果也不好，还常常导致爆框
4. 为图省事，人物对话由占位符拼接而成，比如一句话就是仨占位符<PH1><PH3><PH2>，没法翻译等等
5. 本地化团队只能不断和开发团队沟通，提升他们的国际化意识，而这并不容易。

有统计显示，本地化阶段发现国际化错误再修改，比开发阶段修正，要多7-8倍的成本。而若到了维护阶段再回头修改，则要多15倍左右的成本

四、问题 & 复盘

而基于以上方案，总归会在第一次落地时候遇到不少坑，可以结合本次经验，从两个角度具体展开一些典型问题。

1. 工作流如何以最低成本实现半个月内上线 MVP 版本？
2. 设计系统未来将如何从国际化无缝衔接到本土化？

本篇文章将从工作流的角度展开，希望能够给予你一些启发。期待你的收获和反馈。

五、工作流

1. 多部门工作流

此部分具体细节可留言询问，不过多做展开，因各公司协作流程不同，找到适合你们公司设计和研发协作高效的方式最重要

2. 翻译工作流

R - 查询 key

重要！加之前先检查下是不是已有了，短期内以国内功能迭代为准，则直接中文搜索即可

U - 修改 key

C - 新增 key

操作如下，添加简单，但这一步最考验多人协作带来的“熵增效应”，具体如何判断是否要加看最开始的流程图即可

接下来，展开说说，当你确定要新增了，新增流程里几个判断的依据：

前端、后端判断条件

不以翻译人意志为转移，需要翻译人反向去了解实际前后端如何实现这部分，一般做业务设计时不需要反向了解。

但！此时需要，比如复杂的 FSM(状态机)

组件、业务判断条件

是否全局通用这个条件无非是在收敛唯一性，比如取消按钮不会建 N 次，考验抽象能力以及增前先查的好习惯。

根目录判断条件（设计系统、数据库结构）

已有根目录满足，那么直接根据需求在根目录下通过“.”符号新建子目录结构，比如 10_Order.Address.xx。

鼓励 (key) 前的中文用设计稿中文，给设计、产品等角色查找用的。

英文 key 用英文缩写，key 短一点，没必要直译，可以 xxxContents 来解释 PlaceHolder，给前端角色查找用的。

若根目录不满足，找 @负责工作流的设计师  建个合适的文件结构。

该角色的判断依据是根据 数据库结构 or 设计系统结构 来决定要不要新建根目录。

3. 问题复盘

粗心大意

App 最关键的部分是 - key，自检重新绑定部分

禁符号 and 空格

括号中文 or 丢失

Key 丢失

驼峰

脑子要转一下

三方翻译直接 copy 了一些不可见字符

Key 重复

解决方案

MVP 版本上线之后，Lemon 会迭代成新版，只保留英文 key 展示。

新增操作以后也以英文搜索为主。

并且添加相同 key 不允许通过。

这样就能杜绝完全重复的 key 却是 2 个中文意思的情况，以上能解决 一、二里大部分问题，但粗心本身造就的问题，还是需要操作人自身严谨性提升。

Key 更改 OR 删除

解决方案

随着 mvp 版本上线后，后续版本，禁止删 key。

若需要更改，以新增更改为手段，废弃的 key 可以标记为不维护 ，需要和负责人同步。

产品文案

解决方案

需要对应产品/设计负责人明确自己的场景，不要看到一个想当然拍脑袋决定，要有溯源全场景覆盖没问题，再更新。

本篇我们总结了在搭建国际化工作流中出现的几个常见的问题以及相应的解决方法。搭建一个好的工作流不仅能够提升开发与迭代效率，避免重复工作，还能降低成本与风险，避免 “踩坑” 损失。

在下周的文章中，我们将从设计系统的角度讲述如何在国际化的大背景下实现本地化，实现从“粗放适配”到“精准运营”的升级。