开发一个完善的国际化应用程序四个建议

http://www.ciotimes.com/export/sites/default/lifecycle2/development/development201003021615.html

开发一个完善的国际化应用程序四个建议
http://www.ciotimes.com 2010-03-03 来源：IT专家网 作者：swing
导读：要开发一个完善的国际化应用程序，具有一定的难度。由于地域因素、语言要求、文化差异等等使得不同的国家对同一个业务也有不同的认识。换句话会说，就是在一个系统中要根据不同国家的需要实现不同的流程与界面。
关键字：开发 程序开发

　　随着网络的发展，地球是平的这个观念逐渐得到验证。这对于信息化管理软件的开发也提出了新的要求。由于企业业务的跨国发展，使得应用程序也必须满足国际化发展的需要。也就是说应用系统需要在全球范围内访问使用。不过从笔者的亲身经历来看，要开发一个完善的国际化应用程序，具有一定的难度。由于地域因素、语言要求、文化差异等等使得不同的国家对同一个业务也有不同的认识。换句话会说，就是在一个系统中要根据不同国家的需要实现不同的流程与界面。这虽然比较简单，只是工作量增加而已。但是难点在于如何将这些不同的流程与界面统一起来。因为他们毕竟是相同的业务，只是表现的形式不同而已。对此笔者有如下四个建议供大家参考。
　　建议一：Java环境中越早考虑国际化需求越好。
　　在其他的一些开发环境中，国际化需求经常是在开发后期才需要考虑的问题。但是笔者认为，对于一个已经接近开发完成的系统进行国际化的过程是一项非常繁琐的工作，需要增加许多额外的二次开发。特别是对于Java开发环境来说，更是如此。
　　这主要是因为国际化工作会影响到J2EE应用程序的每一个层次，即这是一个体系结构方面的问题。有时候为了满足某个国际化需求，还不得不大动干戈，调整系统的体系架构。而调整体系架构之后，又需要额外的测试等等。周而复始，工作量会增加好几倍。故笔者建议，在实现国际化需求的过程中，开发人员最好是在一开始设计开发应用程序的时候就考虑到国际化的需求。如此的话，会将问题简化许多。笔者在建议二中将谈到语言问题，会对这个进行展开。换句话说，在应用系统需要处理多个局部因素的时候，项目设计阶段也就应该定位并分离局部因素之间的依赖性。
　　建议二：多语言环境是国际化软件的基础需求。
　　对于国际化应用系统来说，通常会面对来自不同国家的用户，他们会使用不同的语言。即通常所说的多语言环境。这个说起来简单，但是做起来就比较困难。如系统中涉及到的所用窗口、报表、流程，包括窗口中的内容都需要支持多语言。举一个简单的例子。现在某个企业的应用系统，有三个用户，分别为美国人、日本人与中国人。那么系统就可能需要提供英语、日语、汉语三种语言。为此系统必须要用有不同的界面对应于不同的用户。可是如果为每个语言单独设置界面的话，那么工作量就会随之增加。而且灵活性也不好。如果再增加一个德国用户，难道再为其开发一套界面吗?显然这并不是很好的处理之道。
　　笔者认为，这比较好的方式就是通过字段元素来完成。无论是窗口还是报表，都是有一个个字段构成的。在系统设计的时候，可以在字段之上再增加一个元素层面。也就是说，元素构成字段、字段再组成窗口或者报表。在元素的时候，就对每个字段进行多语言化。如现在有一个字段ProductValue。在元素层面，就给这个字段进行翻译，如分别使用日语、汉语进行关联。然后用户在系统登陆的时候，可以选择自己需要使用的语言环境。等到打开系统之后，相关的界面就会根据用户选择的语言来显示。如果用户选择中文的话，那么相关窗口的内容都是以中文表示的。这主要的功劳就是归根于元素层面的语言定义。
　　这么设计有一个好处，如果要多增加一种语言，如需要增加德语。不需要额外的设计一套界面。而只需要在元素层面对每个字段进行翻译即可。翻译完成之后，导入到系统中。然后在登陆时选择德语，那么相关的界面就会自动以德语显示。笔者认为，至少到目前为止，这种设计方式是比较合理的。不但灵活性高，而且工作量也不大。不过这种方式要求在应用程序设计的时候就需要考虑国际化方面的需要。
　　建议三：根据需要选择合适的字符集。
　　有过Oracle数据库系统部署经验的用户大概都知道，在其安装过程中会让用户选择合适的字符集。如果字符集选择不合适，如在中国大陆使用，选择的是ASCII字符集，那么显示的中文内容就可能会有乱码。故在开发国际化应用程序的时候，为系统选择合适的字符集至关重要。
　　如ASCII字符集是最常见的用来表达美式英语的字符集合。ASCII码中包括大写和小写的罗马字符、阿拉伯数字、标点符号、控制字符和其他的一些符号。虽然其对美式英语很友好，但是却不能够很好的支持其他语言，如汉语或者日语等等。在这方面已经有前车之鉴。如许多早期的互联网协议都是基于7位ASCII编码而实现的，这导致了在很长一段时间内，Web应用系统很难支持美式英语之外的其他语言，包括英国英语。一直到现在，不少开发人员还深受其影响。
　　为了能够让字符集支持尽量多的语言，笔者建议最好采用Unicode字符集。这个字符集采用了21位的代码定义了一个标准化的通用字符集。在Java开发环境中，支持16位的Unicode编码来表示字符和字符串对象。为此使用Java编写的应用程序就可以处理多种语言书写和程序数据，并致词能够一定的基于本地化特性的操作，如进行字符串比较等等。
　　建议四：本地化与国际化之间的均衡。
　　与国际化相对而言，还有一个本地化。本地化就是指将一些国外的软件，进行一定的更改，以适合国内使用。其实从大的方面来讲，这也是国际化需求中的一项内容。到目前为止，任何一个国际化的应用软件，包括Oracle ERP等软件巨头，其开发的系统在国内使用，也有一个本地化的过程。任何开发人员都不能够避免这项工作。现在的问题是，如何让这项本地化的工作变得更加的简单?
　　如对于上面讲到的语言这个例子。如果软件增加了一个德国用户，需要增加德语环境。如果再去设计一套界面显然不合理。而如果只需要对相关的字段进行翻译，然后通过导入工具导入到系统中，就可以完成德语显示的需要。显然这工作量会减少许多。开发人员只需要设计一个语言集的导入工具即可。然后有专业人员对相关元素进行翻译，再导入系统即可。
　　再如流程控制方面。由于文化背景、经济环境的差异，客户进行交易的方式可能是不同的，如业务流程等等。如对于销售订单的交付方式而言，有强制(不管订单对应的生产订单是否完成或者是否有库存)、完成行(只要订单中有一行完成就可以部分交货)、完成订单(必须订单中所有的行完成才可以交货)、付款以后(客户付款后交货)等等。不过的国家、不同的行业对此有不同的需求。此时如果能够结合工作流模块来进行本土化的工作，显然会很便利。因为本土化过程中，不需要进行源代码的开发调整，而只需要对流程进行重定义即可。这就好像是拼图那么简单。
　　所以国际化应用程序并不是说其可以不经过任何修改就可以在不同的国家使用。如果确实需要进行本地化的过程，那么这项工作如果能够变得简单，也是可行的。