今天和大家分享一个能力开放平台中的国际化转换的设计。

前后台分离的模式下,前端都是html，js，css等，后台都是提供各种API给各类终端或系统调用。

国际化的元素有：语言，时间，货币符号，税率换算，节假日等

需要国际化的源数据有:

页面： 包括html,js两种主要可能存在国际化元素的文件

API： 目前前后台分离,API返回给前端的大都是JSON格式的数据。

异常：后台API抛出的异常，异常通常有固定的格式。如：异常编码，异常信息，异常信息变量。

数据元素：查询数据库，数据库中返回的数据集中的某些字段需要国际化。

国际化源资源中的元素都是存放的一个key值，在前端实际获取时，根据前端提供的国际化要求进行实时转换。设计图如下：

转换的机制：

页面：前后台分离的情况下，我们站在后端能力提供者的角度，是不需要关心前端的。但是毕竟后台自己的系统也有前端。后端资源都是通过接口提供的包括页面。所以html，js在接口返回给前端前转换。html/js中的国际化内容存放的是一个key值，key的格式是${key}，对应类型的国际化value值配置在数据库，并实时同步到缓存。在html/js资源返回到客户端前插入一个I18n节点事件。把返回的文本中带有${xx}的全部找出来，再根据传入的国际化要求，语言，时间格式，货币符号等等在缓存中匹配，匹配到了，就把${xxx}替换为对应的value值。

API：对API返回的结果中的某些字段做国际化的转换。所有的数据都是通过API与外界交互的，可以说配置API的国际化可以实现所有的国际化的需求，但是毕竟为每个API配置国际化是件繁琐的事情，且配置数据过多，影响性能，所以还有下面的数据配置。API国际化配置的内容有：API名称，返回结果字段的路径，国际化类型和对应的值。例如返回的结果是个JSONArray [{cust:'xxx',subscribe:[{user:'xxx',fee:'xxx'}]},{}],要对fee进行国际化转换，路经配置为cust.fee,国际化类型为currency,值不需要配置，会根据国际化类型解析进行货币的运算和转换。在结果返回给前端前进行转换，如果是能力开放平台只要在返回过程中增加一个I18n事件，API的返回结果经过I18n是先做API名称判断，再对字段路径的值作转换。

异常：对能力开放平台中的异常做国际化转换，只有语言的转换。有一个异常类，包含有异常编码，异常信息，异常参数。根据异常编码配置国际化语言数据。在请求API的过程中如果抛出异常，判断为异常类，根据配置替换异常信息，重新匹配异常参数，形成完整的异常信息返回给前端。

数据元素：配置需要国际化的字段，国际化类型，并配置这些字段关联的表。在请求数据时，在数据操作层对返回的结果做转换。只要有返回结果中有国际化字段，就进行国际化转换。