一种基于J2EE的WEB系统的国际化方案设计

2015-03-27中国长江三峡集团公司罗惠恒

电子世界 2015年21期

中国长江三峡集团公司李哲罗惠恒周容

1 引言

软件国际化（Inter nat ional ization, 又称I18N），是指在软件设计和文档开发过程中，为了代码设计与功能实现能处理多种语言和文化习俗，从而创建不同语言版本时，不需要重新设计原程序代码的软件工程方法。

软件本地化（Local izat ion，又称L10N），是指将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生成活动。即针对某一地域所支持的编码字符集、语言和地域习惯为软件建立符合本地要求的信息的过程[1]。

主流的J2EE的表现层框架如Spr ing MVC、St r ut s等对国际化或多或少有相应的解决方案。但上述方案并不能适配所有场景，随着RESTFUL风格的兴起，越来越多的数据展示和格式化工作直接交给了前端模板或组件，这需要客户端Javascr ipt(简称JS)脚本国际化的支持。本文介绍了一种针对基于J2EE三层架构[2]WEB项目的多语言解决方案，有效解决了国际化过程中的相关问题。

2 国际化的背景及过程

多语言的网站根据语言的组织方式可以分为有如下的两种构成类型：

(1)单站点类型。不同语言的网站作为一个站点，然后采用各种手段实现页面的多语言。利用如第三方插件翻译、针对不同语言页面分目录、动态内容产生[3]等方式实现国际化。

(2)多站点类型。不同语言的网站作为多个站点，保存在不同的服务器。服务器之间不存在任何联系，即一系列内容相关的网站集合。

采用单站点模式[4]可以有效减少不必要的服务器开销、降低开发及维护成本适用于大多数企业的信息系统建设。由于界面的风格以及展示的功能相对固定，翻译的精细化程度相对较高，采用动态内容产生作的手段可以在保证功能的前提下，有效减少开发前端代码的工作量。

动态内容产生模式进行国际化主要包含两个步骤：一是对语言的解析，二是根据所解析的语言进行本地化内容填充。下面以基于J2EE的三层架构的WEB系统为例对其流程进行说明：

服务器在接收到请求后首先进行语言解析，依据请求中包含的参数确定出响应页面的语言种类。然后依据所解析的语言种类，在不同层次完成国际化的工作。

一部分UI页面直接在表现层的对模板(JSP)进行编译时完成；一部分UI页面通过JS、CSS在客户端浏览器渲染时完成。

3 国际化方案的设计

3.1 语言解析规则的设计

由于JS对于国际化的支持相对Java较弱，所以拟将语言解析放在服务器端完成。J2SE中用地区（l ocal e）的概念代表用户选择的显示语言以及日期、时间、货币等方面的格式化约定，这里选择将该值作为解析的结果。

通常基于MVC的表现层框架都提供了几种默认的地区解析器。例如在Spr ing MVC中,通过拦截器的方式配置地区解析器，默认通过HTTP请求头部解析区域acceptl anguage设置l ocal e。对语言解析的方式可以通过配置id为l ocal eResol ver的bean对象进行修改，实现方式包括：根据session解析、根据cookie解析、固定地区等，当有特殊要求时也可通过自定义方式实现。

图1 语言参数解析流程图

在根据session解析的方式中，标识语言的参数作为session的一个属性保存。该参数会随着会话的结束而丢失。在根据cookie解析的方式中，标识语言的参数会在cookie中长期保存更加符合现实中的应用场景。对于没有采用MVC框架的表现层，可以借鉴框架的结构自定义过滤器（f il ter）来完成对语言的解析工作。

如图1所示，解析完成后，表现层的控制器可以获取该值，并将其关联到对应线程的上下文中传递给业务逻辑层进而完成业务动态数据国际化。

为了实现主动切换语言的功能，需要提供一个服务直接修改地区判据。具体实现可以通过一个控制器修改cookie中的参数。

3.2 服务器端的国际化设计

服务器端的国际化包含两个方面：消息等静态数据的国际化和动态数据的国际化。

基于MVC的表现层框架通常对J2EE中的消息机制进行了加强，已经实现在解析出l ocal e对象后自动加载对应语言名称后缀的消息配置文件的功能。控制器根据请求参数调用不同的视图（JSP）和模型组合并成返回的UI页面。视图中的消息预先定义在不同语言的消息配置文件中，依据l ocal e调用不同的消息配置文件，将其填充进UI页面。

对于没有采用MVC框架的项目，同样可以利用JTSL的消息机制，但须自行完成不同种语言的标签库的加载工作。这里可以通过将这一部分工作直接放在语言解析过滤器中实现，通过代码：Conf ig.set(r equest, Conf ig.FMT_LOCALE,l ocal e)修改JSTL的配置对象Conf ig即可。

动态数据的国际化较为复杂，依赖于业务逻辑层将语言作为参数进行处理。一般需要对数据访问层以及数据库层进行修改。常见的方案是根据语言参数在关系数据库中按照单表或分表方式对不同语言的数据进行存储，可以采用基于AOP的动态数据国际化方案[5]实现。

3.3 客户端的国际化设计

在浏览器进行页面渲染时，JS控件、前端模板(EJS)等对所展示数据进行内容填充、格式化时需要完成国际化操作。

通用的JS控件一般都包含独立的本地化文件，采用多个文件分散管理标签的方式虽然简单，但是没有达到与后台标签的统一管理的目的。因此，可以选择采用在前端实现通用的标签加载器的方式进行改进并达到上述目的，如图2所示。

图2 i18n标签加载器的工作流程

由于语言的解析工作已在服务器端完成，页面在加载时仅需根据l ocal e参数向服务器请求不同的JS、CSS文件。在开始渲染之前，利用一个通用的i18n标签加载器发出Aj ax请求从服务器端获取对应l ocal e的标签文件(.pr oper t ies)，并按照各个UI控件的需求由i18n加载器转换为特定的JS对象供UI组件使用。

此外对于货币、时间等信息的国际化，一部分利用JSTL标签在服务器端处理，还有一部分必须在前端完成处理的利用For mat Js、Moment Js等通用格式化组件进行。

3.4 标签维护方案的设计

由于本方案采用唯一的配置文件管理页面上几乎所有的静态标签（消息），配置文件的体积会随着系统的增大而不断扩大，不利于提高运行和维护的效率。为了解决上述问题，需要建立通用的标签命名规则和标签控制界面。

拟采用统一的命名方式: <应用名>_<标签类型>_<标签名称>。企业内部根据系统名称确定唯一的<应用名>，<标签类型>分为m（message/消息）和l（l abel/标签），<标签名称>尽量采用标签显示值得英文单词驼峰形式（可根据情况选取缩写）。

为了减少标签的数量，规定m类型标签区分大小写，l类型不区分。对l类型的标签的格式化通过设置CSS3的t ext-t r ansf or m或者JS函数进行。

建另外，需要立统一的标签管理页面，并采用如spr ing中提供的动态加载资源文件的模式（Rel oadabl eR esour ceBundl eMessageSour ce）加载消息配置文件。后期用户如果对WEB界面上的任意标签值不满意，可以通过的标签管理界面查询标签并修改，并且能够实时地看到效果，避免用户直接接触到配置文件。