分享一种后端实现i18n（国际化）的方式

以前在小公司写的项目一般不涉及国际化，所以都没去了解和思考该如何去做，最近的项目中用到了大牛写的某微服务框架，阅读源码的过程中发现其在框架层面就做了一些国际化处理，本文仅简单的记录一下该框架内国际化处理的方式。由于该框架是公司自行研发尚未开源，因此，本文只讲实现思路，不会涉及任何代码。

一般系统后端国际化处理包含两个方面：系统层面和数据层面，本文会从这两方面简单的说一下各自的国际化实现思路。

系统层面

系统层面需要做国际化处理的一般是Messages，也就是后端api返回的正常/异常信息。这里说一下我们的框架针对api的定义：前端调用api时会统一传一个lang的参数来代表当前语言，对于api调用正常的情况下我们一般返回的Message是ok或者success，具体要显示的内容交给前端去写，对于api调用异常时会返回异常信息Message。系统层面的国际化处理主要是对这些Messages进行国际化，国际化的方式大同小异，一般我们是使用两套或者多套properties配置文件将Message以键值对的形式配置在其中，对于不同的语言使用文件名区分，例如messages_zh_CN.properties代表中文。在系统启动时将这些配置文件以Map的形式加载到内存中方便调用。
Message该如何使用？最简单粗暴的方式是在代码中直接调用国际化方法传入properties中的键，返回对应的值。显然这种使用方式不够优雅，作者认为稍微优雅一些的方式是使用自定义异常+全局异常处理来使用，我们可以建一个自定义的本地化业务异常，例如LocaleBizServiceException，异常信息可以是上面所说的properties中的键，为了避免硬编码可以采用常量或者枚举来存键，配合上MVC框架的全局异常捕获，将捕获到的LocaleBizServiceException的异常信息进行国际化处理并返回给前端。
以上系统层面国际化处理基本完成，这种处理方式可以写入框架中，使用者只需要按规定抛出指定异常和异常信息即可。

数据层面

数据层面的国际化一般是为了处理一些系统的数据（不允许或者不建议用户新建的数据），例如系统的角色或者系统的商品、配置等，对于这些数据我们可能需要在数据层面为其做国际化处理。基本实现原理和上诉系统层面国际化相似。首先，我们可以在数据库中新建一张表i18n用于存储国际化内容的键值，该至少包含以下字段：键、值、语言，然后，在业务表中我们可以将需要国际化的字段设计为带i18n前缀，例如i18n_xxx，该字段里存的应该是i18n表中的键。最后，在系统启动时将这些以Map的形式加载到内存中，在dao层进行国际化处理。处理方式大致逻辑为：查询sql执行完毕后根据返回的数据集中是否带有i18n前缀的字段，如果有就从Map中获取这些字段的国际化值并填充进去。如果是框架有dao层代码生成器或者有抽象的dao层可以在框架中直接处理，使用者只需要按规定设计字段即可。