随着全球化浪潮的席卷和深化，中国企业可以说是前赴后继地加入出海大军当中，其中不乏像tiktok之类的产品在海外做得风生水起，与此同时大家也在花费越来越多的时间精力，关注并研究如何去做好一个全球化的产品。但是无论是专做出海还是做全球市场覆盖，一定程度上都会面临一部分在纯国内市场中很少去面临的问题。特别是当产品一次性面向了多个国家多个语种的用户时，将会面临来自不同政治环境、文化环境、商业环境的挑战。
不过今天我们暂且撇开其他问题，先来看一看在产品常见挑战中，当一个全球产品在面向全球用户时，如何能去为用户尽量做好产品的多语言服务？笔者就拿有一定复杂度的平台型产品（google play）为例子，来和大家来聊一聊。
思考如下问题：
这里我们先尝试以google play的截图做个例子，当大家第一眼看到图示1里的这张图的时候，可以尝试快速地想一下，这里google play团队是如何做该产品在不同语言设置下的多语言展现的？
图示1. google play商店多页面截图
可以这样看待，其实所有你在截图中可以看到的事物都是一种数据，无论是文字数据还是图片数据甚至是视频数据，但其数据的填充链条（来源链），却是有多种情况的，来充分保障不同语言用户能尽量去看到对应语言的数据。
一、多语言数据分类
不同语言的数据来源的情况虽多，但是我们总归是可以做一下分类。某类数据，其实在这个产品的大框架之内可以分类成为：
那么下边我们就两类数据的细节情况做一下深入介绍。
1. 产品独管型数据
产品独管型数据，指的是完全由产品官方进行掌控的数据，这里数据的修改是无法经由b端或者c端用户参与修改的。
图示2. google play的商店正版威斯尼斯人8206下载安装首页不同语言环境下的展现（左为西班牙语，右为繁体中文）
根据图示2其实可以看见，同一个位置（例如左边上方的”descubrir juegos recomendados”对比右边的”發掘推薦的遊戲”），在不同语言环境下google play会映射出对应语言文案，而这些文案往往相对固定，文案的生产一般由产品所属公司团队内部直接供应。这一类文案其实就是比较常见的ui界面上属于固定性质的ui文案与ui用图，其创建与修改均只有平台官方有权限改动，无论b端用户和c端用户均不参与到文案数据的创建编辑工作中，分类上就可以对应地称为产品独管型的数据。
图示3. 产品独管型数据&混管型数据对比举例
那么这类产品独管的数据，一般以何种方式做的填充实现呢？比较常见三种方式：
- 纯本地：直接以纯数据文件的形式附带在app本地文件中的，可以说是非常纯粹的ui类文案填充
- 纯远程：文案数据是储存在服务器上远程下发给app，这种跟第一种比较接近
- 远程 运营配置能力：文案数据同样是远程下发，但是增加了后台运营配置页面，往往相比前两种文案数据在修改上对于运营来说更加快速灵活，一般应用于运营类配置数据
图示4. 固定文案 – 安卓app可以将翻译文案写入到xml文件中
更细节一些，如图示4所示，安卓客户端可以将翻译文案写入到xml文件中，这一类是便是上边提到的最基础的『固定文案』的实现方式，属于第一种纯本地的填充方式。另外稍微灵活一些的方式便是通过服务端下发『固定文案』来实现，相比第一种本地填充的方式，第二种好处是可以不通过发版就实现文案修订。
图示5. 配置文案 – 往往通过后台运营配置实现
图示5（图为仅demo需要，不包含额外的后台细节）为笔者推演出的google play编辑团队需要配置编辑推荐专题时，所需要给予的后台配置页面的展示形态，即上文中提到的第三种方式（远程 后台运营配置）中的配置端样式。公司内的编辑或者内容运营只需要将准备好的文案与图片材料填充进入对应语言的表单即可，最终按语言下发到对应语言的用户手中进行浏览。这种形式的好处在于相比第二种更进一步的文案修订灵活性，同时也会支持到运营活动的开展。
特别注意无论哪种填充方式，前端数据展现前都必须要先确定用户语言（可以通过提取用户系统语言来锁定）来根据语言调取对应的数据进行展示哦。
2. 产品混管型数据
产品混管型数据，指的是数据本身的创造与修改，除了公司的运营团队（这里的名称为泛指，同样包含公司其他被赋予权限的角色）本身可以做到之外，权力是同样开放给b端或者c端用户的。那么根据实际参与方的类别，我们可以将数据填充类别分为如下：
- 平台运营 & b端用户参与
- 平台运营 & c端用户参与
然后我们再来根据分类深入分析差异。
平台运营 & b端用户：
图示6. google play console当中的多语言配置项
运营团队或者b端用户同时有权限修改的，但同时其他角色例如c端用户无权修改的数据，比较常见的就是平台商品的各项数据例如名称、简介、截图等等，可以参见图示6所示的google play console的app详情数据填充（商品在google play当中就是一个app，）。实际上，这些字段在谷歌的官方人员后台（虽然我们看不见），是会有对应的编辑位置的，谷歌官方工作人员作为平台方，需要有能力在必要时候进行干预修改。
需要注意的是，b端用户虽然有创建和修改权限，但是填充内容的提交往往会有审核和举报机制覆盖，平台运营参与监控，保障不会出现平台政策允许范围之外的事物。
平台运营 & c端用户：
图示7. google play当中的应用评价创建页和浏览部分
运营团队或者c端用户同时有权限创建和修改的，但一般b端用户无权限参与创建和修改的数据，比较常见的就是社区内容数据（例如帖子）。如果要在google play中寻找一个相对近似的案例，笔者认为应用评价（app review）应该算一个比较好的样板，仍然可以参见图示。实际上这类ugc内容，在多语言覆盖方面是较难做到完美供应的，同时需要利用产品逻辑进行语言对语言的内容下发。如果平台希望a语言用户能看懂b语言用户的内容，往往需要额外的支持例如第三方翻译组件。
同样的，c端用户虽然有创建和修改权限，但是填充内容的提交也往往会有审核和举报机制覆盖，平台运营参与监控。
二、多语言数据的覆盖与输出
为什么第二部分需要展开谈产品多语言方案的覆盖与输出逻辑？实际上，全球化产品当中一个比较常见的多语言方案实现阻碍，就是尽管产品多语言框架可以架设，做好数据的分类，但是有许多位置的文案是较难实现数据覆盖的。虽然上方聊了数据，但如果数据的供应有缺陷，此时往往需要一些产品逻辑或者功能来保障数据在输出到用户时，是有较好的使用体验的。
图示8. google play中也会出现的语言割裂现象
特别是产品混管型的数据，无论参与方是b端用户或者c端用户，其实都较难实现全语言的数据覆盖。比如google play支持的40 全球主要语言，要实现面向如此多语种的数据覆盖，人力财力等各方面资源其实都较为有限。就会导致如图8所示，尽管ui界面上对应输出了当时笔者使用的西班牙语，但实际上游戏简介等位置仍然使用着繁体中文和英文。在google play当中，其实有相当量级的这样的产品，是不乏看见一些简介文案语言与gp的ui语言之间直接割裂的。
那么既然谈了现象，应该如何尝试解决呢？一般来说可以从四个角度切入：
1. 公司内资源拉动
公司内资源拉动是指纯粹的内容团队组织语言翻译工作，一般是在做特别重要的语言数据覆盖时会采用的方案。比如产品战略方向是特别注重日语和韩语的，那么往往会招聘对应语言的翻译人员进入公司工作，此时的翻译质量往往能得到较高质量的保障。
此时一个常见的拓展是翻译工作接入外包公司，公司付费购买质量相对可控的翻译文本，而自己的团队内部有一定人员面向外包公司做对接和质量管理。
2. b端资源拉动
b端资源拉动，指的是当涉及数据是有b端用户参与操控的时候，产品官方可以通过适当的提示、讲解、激励性质的方案或者直接打通翻译服务来促进b端用户自行填充足够的多语言材料，来达到拉动语言数据覆盖的目的。
图示9、google play console中直接提供了翻译服务的接入
3. c端资源拉动
c端资源拉动，一般较为常见的方案是语言志愿者社区的建立。这样做的好处往往是在成本上花费的代价较少，但对应的代价是翻译质量的控制变得更为复杂，可以说一部分志愿者可能会有精妙绝伦的翻译，但一部分志愿者可能也会给出令人吐槽的翻译结果，一些对此无力做到全面控制的团队需要衡量这一方面的弊端，必要的时候有所舍弃。
图示10、steam的多语言数据覆盖选择了借助用户志愿者的力量（https://translation.steampowered.com/）
4. 智能威尼斯37266的解决方案
c端智能威尼斯37266的解决方案，指的是自动翻译服务，比如google translate。如图示11所见，google play内置了自家的翻译服务来提升阅读体验。值得一提的是，google translate的翻译质量，在欧洲各大语言之间翻译笔者认为已经做到相当高的质量（比如英语-法语等之间互译），但是不同语系之间的语言互译质量还有待提高（比如英语-汉语之间的互译），这本身与语系当中的语法逻辑和词汇组成有关，需要持续的时间和资源投入提升翻译质量，不在这里多赘述。
图示11. google play调用了自家的google translate来弥补多语言数据的不足
这里需要补充一点的是，产品逻辑上要注意，当没有对应语言文案展示给用户时，尽量保障流行语言（例如英语）作为打底语言，提高文案的可读性。
三、归纳与结语
在介绍完上边的概念之后，我们可以尝试用思维导图对产品多语言方案进行梳理，可以得到如下图示。
那么，在这样的一个框架梳理下，全球化产品的多语言铺设方面就相对清晰了。
不过海外产品其实进攻的市场类型丰富多样，而今天我们尝试使用的案例google play并不代表了所有的产品类型，例如一般的工具类产品的多语言翻译方案会在这个基础上简化许多（由于一般不需要b端用户和c端用户参与生产内容资料），相信大家在实际面对相关项目时可以灵活应变。
最后，希望本文能够在实际工作中更多帮助到在海外市场深耕的各位产品小伙伴，感谢阅读！