一般系统后端国际化处理包含两个方面：系统层面和数据层面，本文会从这两方面简单的说一下各自的国际化实现思路。
系统层面
系统层面需要做国际化处理的一般是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层可以在框架中直接处理，使用者只需要按规定设计字段即可
网友评论