【数据|海外产品的多语言方案解析( 二 )】_傻大方

按关键词阅读：

特别注意无论哪种填充方式，前端数据展现前都必须要先确定用户语言（可以通过提取用户系统语言来锁定）来根据语言调取对应的数据进行展示哦。
2. 产品混管型数据产品混管型数据，指的是数据本身的创造与修改，除了公司的运营团队（这里的名称为泛指，同样包含公司其他被赋予权限的角色）本身可以做到之外，权力是同样开放给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端资源拉动，一般较为常见的方案是语言志愿者社区的建立。这样做的好处往往是在成本上花费的代价较少，但对应的代价是翻译质量的控制变得更为复杂，可以说一部分志愿者可能会有精妙绝伦的翻译，但一部分志愿者可能也会给出令人吐槽的翻译结果，一些对此无力做到全面控制的团队需要衡量这一方面的弊端，必要的时候有所舍弃。