如何用两周的时间搞定25 门外语?

写在前面

语言，是一把钥匙。对于 App 来说，从理性的角度来看，增加一门外语的支持，可能是打开一个新市场的开端。特别对于苹果这种生态，内部会产生一些流量，只要有合适的外国语对应，说不定会承载到一些自然流量。

另外，有两个现象，以供参考:

1. 一个 App，它可能在国内可以通过多个关键字在 App Store 里被搜索到了，但是，在其它国家的 App Store 区内，则不一定，甚至直接搜索 App 的名字，都不一定有结果。

2. 如果一个 App，它都是英文的状态，名称、介绍，进入 App 之后也全是英文，那么，即使它被国内区的 App Store 的官方编辑推荐了，产生的用户流量会有很大的限制。

简而言之:

1. 语言是一把钥匙，也是一堵墙。

2. 自然的流量，不是说“什么都不动”自己就会发生，而是“动了些什么”才会自己发生。

困难所在

对于一个 App 来说，特别是工具性的，语言只是最外面的一层皮囊，内部驱动的代码逻辑，它们比如叫 Swift、JavaScript，都是统一的语言。从这个角度来说，如果可以克服国别语言，对于 App 的新用户流量来说，将会是性价比最高的尝试之一。

但这并不容易，虽然现在机器翻译的水平越来越高了，但更多也局限于“弄懂大概意思”的层面，如果在 App 里直接使用机翻，那么，可能 App 在使用的过程中，会非常诡异，甚至体验还不如直接保留原始的英文支持。总之，还是需要一定的人力资源在后面支撑。比如，我们从 App Store 上来看，除了苹果自家的 App 外，微软的 Office 对应了 32 个语言，而国产的 WPS 则还只对应到了 13 门语言。WPS 已经不是小的产品了，还有一个例子，是 XMind，它对应了 12 门语言，从产品的发展史来看，XMind 其实反而是更国际化的产品。

对于一个大公司而言，或者对于一个本身盈利也极大依赖于国际市场的公司而言，肯定也知道多对应一门语言的性价比，但为什么不做呢？其实还是很困难的。那么，对于个人开发者来说，那么就更困难了。一般充其量再扩充上几门外语，或许自己略懂，或者刚好朋友帮忙。还有因为 App 保持了对“文本描述”的极简的依赖，而比较容易借助外包来控制翻译的质量。

总之，这是很困难的。面对未知的世界，很可能会弄巧成拙。

一种可行性的出现

我是看到 https://applelocalization.com/ 之后，决定将 Metion 的多国语言给处理了。如果是重度视觉系的 App，对于文本语言的依赖会比较小，那么，做多国语言的对应反而会容易很多。Metion 不好处理的地方，是在于涉及到的文本语言太多了，光直接可见的菜单项都有近百项。https://applelocalization.com/ 的思路很简单、很有才，就是把苹果自己系统内的，以及官方做过的各种 App 的 i18n 数据都提取出来，然后查询匹配。它对应的源码也位于 Github，https://github.com/kishikawakatsumi/applelocalization-web，你也可以直接在它的网站上查询，一开始我也是如此，但这样查询的行为效率太低，另外，整个数据库似乎查询的性能也不太行，有一天，这网站的后端服务直接 crash 了。便另外把苹果的这些 i18n 数据，自己重新提取，生成了一个很大的文本文件，然后直接查询匹配，反而效率飙升了。

https://applelocalization.com/ 的思路其实很朴素，但提供了一个全新的视角。不同的 App 其实也会共享不少相同的术语，当一个现成的数据、条目库存在了，并且数量足够多，那么，我们大概率是能把自己 App 里的条目，在这个数据库里匹配到。前面有几篇文章，虚虚实实，我们在探讨产品哲学，它在实践层体现出来的方法论，就是寻找杠杆系统。是的，这次，我们也找到了一个杠杆系统了。

根据我实际使用情况，AppleLocalization 大概能解决 80% 的条目匹配率。80% 是一个很高的比率了，换句话说，只要花一些时间，我们可以让自己的 App 在额外近 30 种语言中，有 80% 的概率看起来像当地的语言。这里的 80% 主要是指短语翻译，App 里的短语翻译是很困难的，因为上下文环境的缺失，太容易歧义了。而 App 里的主要结构性，与用户交互的点，又都是偏向于短语的。

如果这部分，可以达到 80% 了，那么，整个 App 在其它语言中打开，应该看起来不会很奇怪。我们可以反过来证明这个现象，就是原始不提供中文，而是通过 AppleLocalization 现有库里的条目匹配到的中文，效果如何呢？大概率，我们自己看中文的效果，就跟泰国人看到泰文的效果是接近了。

一些实践

虽然 AppleLocalization 的条目录足够多，但总有遇到不能匹配的，那么，可以尝试把两个条目合并。比如 Insert + Current Date = Insert Current Date，虽然换一种语言，可能这种“动宾结构”看起来是不 native (原生) 的，但基本意思应该是能看懂的。

KGS Driver.brailledriver/com.apple.scrod.braille.driver.kgs.70657 -> Insert

Photos.app/namingCurrentDate -> Current Date

KGS Driver.brailledriver/com.apple.scrod.braille.driver.kgs.70657 + Photos.app/namingCurrentDate -> Insert Current Date

也不总是有效的。比如 White Noise (白噪音)，这个就不好弄了，可能最终会翻译成“白色噪音音乐”，就有些奇怪。即使奇怪，但也是能看明白的，但这种情况，是可以具体条目具体优化的。

当然，这部分的逻辑是纯代码自动对应的，需要自己手工做的，就是原始条目的梳理，之后，就是交给代码去处理了。因为要匹配额外近 30 门语言，手工能提供的就是源 (input)，不可能是 output，不然这个工作量是恐怖的，而且出错的概率会很高。

这个过程中，我们还是需要不断对结果进行校验的。虽然源自于苹果的原始翻译资料，但是，不用语言之间的翻译人员，未必能精准理解 App 的涵义，即使，是来自于苹果自己团队的翻译人员。比如 line 是一个多义词(线条、行)，这是容易理解的，不容易理解是在具体的上下文场景中，比如 code，它在 iOS 内置的 Message 中的概念，应该是指“验证码”，简体中文翻译为 代码、繁体(台湾)翻译的是 验证码，而繁体(香港)翻译的又是 代码。还有比如 “History”，翻译为 历史 是很好理解的，但也不尽然正确，因为如果是 Safari 浏览器，它可能会被认为是 浏览历史。而在其它上下文中，“History”就应该是“历史(版本)”，但是就还是有被翻译为“浏览历史”的，估计翻译人员沿袭了 Safari 里的翻译。这些，都需要我们在后续去发现和修正的。

继续补全

有些条目，在 AppleLocalization 现成的库里找不到的，但是略微调整下，就能用的，那么就改 App 内原始的文案。还有些，通过简单的文本拼接，也不好处理的，那么，就使用 Text Text (more) 这种 () 的补全，相当于两个部分各自对应 i18n，整个文本可以分解成两个意象，而不需要特别的自然语法保证了。还有一些，虽然有些奇怪，但是用了，也是能懂的，比如 Git 在 Pull 和 Push 时发现没有内容变化，提示用了苹果现成的 This user's data doesn't need to be transferred，在 Git 这个使用的上下文环境中，有些脱离感，但意思也不能说不对。权衡之下，即使我们重新换一个文案，最终通过机器翻译成其它 25 门语言，意思还不一定能比这个更好呢。

还有些情况，就是削足适履，也是巧妇难为无米之炊。更多的是一些句子型的提示消息，那么我们会先考虑下面两种思路:

1. 这个提示信息能不能在 App 内去掉？

2. 这个提示信息能不能拆解掉，或者某一段比较难翻译的删掉，但是把它们化解成其它界面元素，那么翻译的需求就会降低一些，有些还会从原来的“长语翻译”变成“短语翻译”就能匹配现成库了。

剩下的，条目数考虑，可能只剩 20% 左右了，但从文本长度考虑，可能又是占 80% 的，那么，我们需要使用机器翻译了。主要使用下面两个工具:

1. https://deepl.com/

2. https://translate.google.com/

对了，在进入“机翻”之前，我还另外使用 https://i18ns.com/ 扩充了一些短语翻译，来补全的 AppleLocalization 的不充分匹配。比如 Zen Mode (禅模式) 这个短语，在苹果原生的翻译库中，是不存在的，如果直接“机翻”，准确率如何我们不清楚，这时使用  https://i18ns.com/ 作为补全，精准度就会提高很多。当然，最终也是运行代码的方式，把所有结果跟 AppleLocalization 里提取的条目，进行合并。

Deepl 的最终翻译质量，实际情况来看，是高于 Google 翻译的，但是 Google 能够翻译的语言是超过 Deepl 的，像韩语、泰语这些，Deepl 目前并不支持。所以，交替着使用，Deepl 能翻译的，就用 Deepl，不能的，就用 Google。

还有很重要的一点，就是尽可能避免手工操作。大概原因:

1. 手工再怎么小心，也还是容易出错的。

2. 工作量是在太大了。

3. 被翻译的源内容，并不是一成不变的，而是可能变化；但变化出现的时候，一次性再手工去对应 25 门外语？这样的变动成本很难接受。

所以在“机翻”的过程，也是使用了代码的方式，尽可能是整个过程自动化进行。只是，这部分的代码，会比较冗余，很多细节看起来就是 dirty code，但没有关系，能解决问题就行，毕竟自己用而已。Deepl 是有 API 提供的，Google 的翻译好像没有官方的 API 对应，可以请求其网页来模拟 API，短句还行，长句可能不行，我在这个时候，是在代码程序里做了一个等待输入的过程，然后自己手工在 Google 翻译的网站上操作，再粘贴回来，让程序继续运行，相当于半手工操作。另外，很重要的一点，注意做缓存的逻辑，一般我们假设相同的源文本，对应的某个语言，其翻译结果是固定的，那么，这时就需要做缓存了，可以避免下次网络请求的发生，可以有效提高整个程序自动对应的效率，还有就是可以节省 API 请求的用量，Deepl 的 API，免费的开发者账户是有每个月总量的限制，付费的则是按需支付。

“机翻”过程的代码对应，主要并不是使用代码去调用翻译的接口，而是自动修正翻译的结果。在我的实践过程中，修正部分的代码，占了整体的 70% 左右，有些特定源文案有固定格式的，也会有个校验过程，并且逐行判断，保证一定的固有格式。另外，我们在这个过程中，也会不断修正英语源文本，尽可能避免一些长句，改为短句，原来有语法上省略的，尽可能还原到完整的状态，比如  xx deleted 还原为 when xx is deleted 或者单纯加一个 when 上去 when xx deleted 也会更容易让机器翻译理解原始文本。我们也会避免使用一些特定语，如果使用了，也会想办法在代码中去校验结果中，特定语是否被错误翻译了，比如很多时候，我会把 Metion 改为 App。

一些放弃

像阿拉伯语、希伯来语，最开始也是在处理的，后来发觉，它们似乎是排版倾向于从右到左的，加上自身的语言从图形的角度来看，比较复杂，便就放弃了支持。还有印度的印地语，也是类似的原因，放弃了支持。并非尽可能支持外语，而是苹果默认提供的、苹果 App Store 下有默认指定的本地化语言 (可能分别对应了不同区域的 App Store 市场)，才做尽可能的支持。

还有 App 内置的文档，也删除了近半。有些需要通过文档说明的，如果不太重要的就删除掉。如果界面里重新整理能覆盖掉的，也删除掉，典型的比如 Metion 内原来关于“同步”的说明，这些通过产品自身设计的调整，降低了原有文档的必要性。留下的内置帮助文档，也不是全部都进行了翻译。有些可能原文格式比较复杂，机翻基本上会破坏这个结构；还有些作为文档有必要，但被翻译的必要性似乎又是可以没有的。

写在最后

还是重复之前的那句: 产品哲学，它在实践层体现出来的方法论，就是寻找杠杆系统。这次多国语言的支持，也是找到了一个新的支点，让独立开发者，可以撬动某种可能性。

但是，杠杆系统出现了，并不意味着一切都将轻松。反而是更加的不轻松。脏活累活，将随处可见。如果以本文为例，后续的问题还有很多，都是强劳动力驱动的。比如对应各个国家语言的 App Store 的介绍，以及 App Store 上 App 的图片介绍。App Store 上一个 iOS 的 App (还不包括 Mac)，起码需要三种规格尺寸的图片，如果有 5 张介绍图，那么，一个国家语言，就要对应 3 * 5 = 15 张图片，如果 30 个国家，那么就是 450 张图片。如果再算上一个 Mac 端，就是 600 张图片了，关键这些图片，都需要自己一张张做出来。

产品哲学的意义，是拨开迷雾。但迷雾后面，该是什么，还是什么。

或许这次的杠杆还不够“哲学”，反而有很强的实战性，会让人不容易跟“产品哲学”关联起来。下次，我们还会有个例子，来说明。从根子里使用杠杆撬动的时候，有些神奇，终究是会发生的。