越来越多的App开始出海，随之而来必然会遇到的一个问题就是多语言。有的同学会说了，多语言，那不是很简单吗?

确实，要在App中支持多语言非常简单，是个研发就会做。不过当你的App支持的语言越来越多时，你就会发现，支持多语言这个事情变得非常麻烦。

原始阶段

多语言对于出海虽然必不可少，但在公司刚开始出海时，大概率是没有什么精力花费在怎么去优化多语言开发的流程的。毕竟这个事情看起来很简单，假设我们只多支持一种语言的话，这个麻烦的上升程度也有限。

此时的整个工作流程大概如下：

1. 产品从需求中提取文案给到翻译

2. 翻译们翻译完成之后给回产品

3. 产品通知研发们进行文案替换

4. 研发手动替换文案

5. 后期文案回归（测试or翻译进行校对）

有些公司则是研发和翻译直接对接（2,3步骤）。整个过程看起来似乎还好，但中间的几个步骤对于人力的消耗并不小。

1. 前三步骤当中，产品或研发需要一直去跟进翻译进度。

2. 由于没有地方统一记录这些翻译文案，会导致一些文案重复翻译，浪费人力。

3. 第四步当中，由研发手动替换文案费时费力，容易出错。当支持的语言变多时，这个工作量和出错的概率也会随之上升。

4. 由于手动替换的不可靠性，后续也需要人力去进一步校对文案的正确与否。

5. 当线上文案需要替换时，需要重复该流程。

这些小问题就像鞋子里的一颗细沙，虽不至于直接让你无法前行，但却会影响你能走多远，走多快。

自动化&平台化

知道了问题的所在，我们就可以开始着手去设计解决方案。

首先, 我们先对问题进行一下分类，发现可以归为两大类，一是流程性问题，二是重复性工作问题。

对于重复性工作，我们可以通过自动化手段来解决:

首先很容易就可以想到并实施的一个点是通过脚本等自动化工具自动进行文案的替换，这样就可以节省研发手动复制粘贴的时间。

同时通过工具替换文案大大提高了可靠性，后续的校验可以简单地只查看文案是否过长导致截断，不需要再校验内容的正确性。

这一步并不复杂，而且收益极大，也是后续优化的基础，建议至少要完成这一步。

流程性问题，通过平台来进行管理:

以文案的自动化替换为基础，我们可以进一步进行扩展，通过一个平台来管理所有的翻译文案，并进行流程上的优化。

那平台要具备什么样的能力呢?

1. 唯一标识一个文案

2. 记录每一个SDK所使用到的文案

3. 文案搜索

4. 流程的自动流转

在具备了这些能力之后，我们的工作流程就变成了如下的步骤：

1. 产品在平台提交需要翻译的文案（指明负责研发）

2. 平台自动给每个文案生产一个key, 并分发给翻译

3. 翻译进行文案翻译（可复用以前翻译过的文案）,并在平台上提交

4. 平台自动通知对应研发，研发通过自动化工具替换文案

5. 后续的文案长度的检查

整个流程中，由于平台的存在，每个人只需要关注自身部分的工作，不再需要和其他角色进行繁琐的对接和进度跟进。同时通过自动化工具，文案的正确性有了极大的提高。

非主要流程的优化:

上述流程是对于需求开发阶段的优化，但除此之外，我们可能会面临的一个情况就是，线上的翻译文案需要变更。

需要变更的原因可能很多，也许是文案错误（自动化加平台也并不能完全保证正确）。也许是翻译文案不符合当地习惯。但显然，重复一遍开发过程的流程，略微繁琐。

开发过程中，需要研发介入的原因主要在于两方面：

1. 文案的使用

2. 文案需要提交到哪个SDK需要研发确定

在文案变更的情况下，显然研发的工作并不是必要的。平台可以记录使用到该文案的SDK, 文案的使用并不需要变更。

因此流程可以进一步优化：

1. 产品或翻译在平台上提交修改（需求可能来自前线运营）

2. 平台直接给所有的使用到该文案的SDK提交文案变更

文案动态化

说到文案变更，那就会有一个时效问题。在上面提到的解决方案当中，我们只对工作进行了简化，但还是得跟随下一次发版。

大部分情况下，这一点时间差并不是什么大问题，但当某些翻译涉及到一些文化差异，政治问题时，问题可能会很严重。

如何对文案实时进行变更呢？从端上的角度来说，方案并不复杂。

1. App启动后去拉取文案配置文件

2. Hook NSBundle以下方法，返回配置的最新文案

- （NSString *）localizedStringForKey:（NSString *）key 
                              value:（NSString *）value 
                              table:（NSString *）tableName;

但这个配置文件从何而来呢，最简单的方式就是手动配置，而这导致的一个问题就是，每个版本需要配置哪些文案呢？

1. 我们可以选择简单粗暴的方式，所有版本共用一份配置，这样导致的问题就是已经修复的一些文案还是通过配置化下发了。

2. 针对不同版本来配置，但带来的一个问题是，确定每个版本需要配置的文案会导致额外的工作量。

显然我们会更偏向于只下发所需文案，对于这个文案确认工作，我们可以通过一些自动化功能去优化。当有文案变更时，整个配置文案生成的过程大致如下:

平台文案发生变更时

1. 文案发生变更

2. 获取当前线上App最新版本

3. 生成配置规则，小于等于当前线上版本的都需要下发该文案

App新版本上线时

1. App新版本上线

2. 通知文案平台

3. 文案平台获取上一个版本的配置

4. 文案平台检查最新版本中修复的文案，并从最新版本的配置中删除

这样就可以让文案变更立即生效，同时也免去了手动配置文案的痛苦折磨。