数据|海外产品的多语言方案解析( 二 )

文章插图
图示4. 固定文案 – 安卓App可以将翻译文案写入到xml文件中
更细节一些，如图示4所示，安卓客户端可以将翻译文案写入到XML文件中，这一类是便是上边提到的最基础的『固定文案』的实现方式，属于第一种纯本地的填充方式。另外稍微灵活一些的方式便是通过服务端下发『固定文案』来实现，相比第一种本地填充的方式，第二种好处是可以不通过发版就实现文案修订。

文章插图
图示5. 配置文案 – 往往通过后台运营配置实现
图示5（图为仅Demo需要，不包含额外的后台细节）为笔者推演出的Google Play编辑团队需要配置编辑推荐专题时，所需要给予的后台配置页面的展示形态，即上文中提到的第三种方式（远程+后台运营配置）中的配置端样式。公司内的编辑或者内容运营只需要将准备好的文案与图片材料填充进入对应语言的表单即可，最终按语言下发到对应语言的用户手中进行浏览。这种形式的好处在于相比第二种更进一步的文案修订灵活性，同时也会支持到运营活动的开展。
特别注意无论哪种填充方式，前端数据展现前都必须要先确定用户语言（可以通过提取用户系统语言来锁定）来根据语言调取对应的数据进行展示哦。
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端用户虽然有创建和修改权限，但是填充内容的提交也往往会有审核和举报机制覆盖，平台运营参与监控。
二、多语言数据的覆盖与输出为什么第二部分需要展开谈产品多语言方案的覆盖与输出逻辑？实际上，全球化产品当中一个比较常见的多语言方案实现阻碍，就是尽管产品多语言框架可以架设，做好数据的分类，但是有许多位置的文案是较难实现数据覆盖的。虽然上方聊了数据，但如果数据的供应有缺陷，此时往往需要一些产品逻辑或者功能来保障数据在输出到用户时，是有较好的使用体验的。