2

将一个web应用国际化我们首先会想到的是利用struts, spring之类的框架提供的国际化组件来做,
具体来说就是写两个国际化properties文件,一个起名为application_en.properties,另一个起名为application_zh.properties,文件中放的message key。

然后利用请求的头信息或者其他手段获得用户想要的语言版本,根据不同的语言版本从对应的properties文件里提取词条显示给用户。

但是这仅仅是国际化的第一步,而且spring、struts能帮你的也就到此为止了。

前面讲的只是最基础的将页面上的固定或者格式化的文字国际化。其实要将一个web应用国际化总共有一下几个工作要做,每一个都够你喝一壶的了:

  1. 固定文本,格式化文本国际化

  2. 第三方JS国际化

  3. 用户产生数据国际化

  4. 数据展现国际化

  5. 数据查询国际化

  6. UI元素国际化

固定文本、格式化文本国际化

前面已经讲了,就是将你的应用中不变的文本常量支持多个语言版本,比如我们定义一个词条message.hello,在中文环境下我们要显示“你好”,在英文环境下要显示“Hello”。

第三方JS国际化

我们写应用总是会用到一些第三方JS组件吧,那他们的提示信息也需要国际化,比如我们要让form表单验证JS工具在中文下显示“该字段必填”,在英文下显示“This field is required”

有些JS组件带了国际化,有些则没有,而且每个组件国际化的方式又不尽相同,这些你都需要处理。如果运气不好,你可能需要自己修改这些第三方组件的源代码以适应国际化。

用户产生数据国际化

重头戏来了,在前面两个步骤中,我们把程序产生的内容都国际化了,那么用户产生的内容呢?比如一个商品有一个名称字段,那现在国际化了,我们总不见得还是在页面上显示中文吧?

那原先的名称字段就不够用了,因为这个字段只能显示一种语言的文本,那我们是添加字段还是将名称字段抽离出来放到一个国际化表里呢?

这个问题没有固定的答案,我遇到的项目只需要中、英文两种,所以就又添加了一个英文字段,但是如果要求支持的语言很多那这个方式显然就不合适了。

解决了是加表还是加字段的问题后,你会遇到另一个问题,就是哪些数据要补充国际化信息?商品信息需要,用户评论显然不需要。

在这里我倾向于将用户产生的内容分为管理员产生和普通用户产生两种,对于管理员产生的需要在系统各个层面使用的数据是需要国际化的,比如前面讲的商品名称,对于普通用户产生的则不需要,比如对某个商品的评论。

接下来,就是要对原始数据进行补充了,这里没什么神奇的事情发生,就是一堆体力活。

数据展现国际化

原始数据有了国际化信息后,那么我们需要在不同的语言环境下显示对应的字段or数据。就以我遇到的系统为例子,在中文环境下我们使用object.getName(),在英文环境下我们使用object.getEngName()

当你的网站很庞大页面很多的时候,你会觉得修改这个真是一个苦差事。所以你需要自己做一些有用的工具类比如getI18nName(object)返回正确的信息。

当然你还得提供一种fallback机制,如果某个商品英文名称没有填,那么是不是应该显示中文名称?fallback在第一部里有现成的解决方案,但是在这里你只能自己处理了。

数据查询国际化

商品的数据都展现出来了,用户要按照商品名称查询了,那么我们是要在英文环境下只能使用英文查询,还是无论什么语言环境中英文都可以查询?

涉及到具体实现就是构造SQL语句的时候我们是name like ?还是engName like ?还是name like ? or engName like ?的问题了?

UI元素国际化

含有文字的图片、视频等多媒体内容,是不是要提供不同的语言版本?

而且你可能会发现原先中文下挺美观的页面在英文下显得很丑陋,原先4个字的标题变成了长长的英文单词,很多东西都换行了,一切都糟糕透了。

如果你对此很介意,是不是要提供一套不一样的英文版本CSS甚至于页面布局?


chanjarster
4.2k 声望244 粉丝