谈谈多语言设计(一)之客户端多语言与服务端多语言

  2017年的一个风口就是移动互联网的出海,很多公司都战略性地在海外做起了互联网商业化,最近也是接触了一些国际的项目,用户散落在各个国家地区,刚开始大部分是由客户端进行多语言的适配,后来由于产品觉得灵活性太差,于是把部分功能移到服务端来实现,但是发现无论是客户端实现还是服务端实现都存在一些弊端。

我们先思考一下以下几个问题:

  1. 完全由服务端实现多语言有什么弊端?

对于大部分应用场景,多语言都可以在服务端实现,但有一种情况不适合使用服务端多语言。比如目标用户语言非唯一,IM群发,推送等业务场景,虽然大部分消息推送服务可以按用户属性或者标签进行推送,服务端可以分开推送来实现,但是对于用户群推地域很分散的应用显然不是很合适。

  1. 完全由客户端实现多语言由什么弊端?

大部分情况下都是采用的客户端写多语言配置进行适配,不管是android 还是iOS 还是常见的前端框架都是支持i18n的配置。这种方式有个缺点就是灵活性比较差,修改文案必须发包。

  1. 对于移动应用多语言是该客户端做还是服务端做,如何找到一个平衡点?

无论是客户端多语言还是服务端多语言都有各自的优劣,主要还是看应用场景。
个人认为对于移动应用的多语言,应该把两者结合起来使用。对于UI等相对固定的部分采用客户端多语言。对于变动比较大的部分,采用服务端进行多语言的处理,比如名称,描述这些可能会根据运营场景进行调整的信息。

  1. 为什么不采用服务端生成配置客户端加载配置的方式?

这种方式是一种比较灵活的方式,但是对于协议的定义不是很友好(key必须唯一,势必导致接口的返回体变大),而且无论是客户端还是服务端解析也比较耗资源,接口可读性比较差。而且把业务跟多语言的耦合太重,无论是客户端和服务端在编码的时候应该把多语言与业务解构,即便没有多语言部分也不影响业务的执行。

  1. 如果将客户端多语言和服务端多语言结合使用,怎么规范比较适合?

    简单来说,就是以下几点:

    • UI部分由客户端实现多语言
    • 所有客户端主动向服务端拉取的由服务端实现
    • 对于群发等应用场景,由服务端生成语言包,客户端在一定时机拉取并加载到应用中。