|
这篇稿子早在半年前就开始在头脑中酝酿了，但是却迟迟没有下笔。原因有二：一是这个命题实在太大，微软甚至有一个庞大的机构和部门在负责国际化 Internationalization、全球化Globalization和本地化LocalizationŒ的工作，并且在MSDN上长期在线解决相关的问题。况且由于杂志本身的篇幅所限和我们需要重点阐述易用性的出发点，我们只能要么对其做大而全的乃至长篇大论的叙述，要么Focus在某些具体的点面来做透彻深入的说明；其二是希望能够开辟技术类杂志新的文风，因为就个人的体验来说，是很少能够坚持把一篇掺杂着各色代码和充斥着行业术语的文章坚持看到最后的，相信读者也不见得喜欢吧！－ 因为如果在内容中不能很好的突出文章要意，也许这本身就是种不友好的用户体验吧！但是最后经过和编辑欧阳和泰稳的交流，还是决定暂时从几个主要的方面做个重点的说明，以点带面，抛砖引玉，便于对一些还不是很清楚国际化多语言软件产品战略意义和正确实施方式的软件企业、工程师们，能够快速的了解国际化软件产品的设计和开发方法，同时也希望借此提高大家对于多语言带来的易用性问题的认识。
首先我们先明确几个概念和观点： 第一， 从具体技术实现角度来讲，到目前为止，国际化多语言软件的最优化解决方案是双字节甚至多字节Unicode的编码和界面支持。
第二， 从具体执行和管理角度来讲，多语言和本地化不仅仅只是简单的静态翻译。多语言和本地化过程是一个庞大的系统工程，需要由多方面、跨学科的团队进行（如可用性专家、本地化工程师、专业翻译人员，集成项目经理，发布测试管理，界面工程师等）。
第三， 从易用性测试和产品架构设计角度讲，良好的多语言和本地化支持是一个重要的可用性检测指标，因为它体现了我们产品界面中出现的文字和字符是否具有相当的可读性和一致性水平 － 即是否清晰可读、可见能够正确表述功能和传达给用户有用的信息，并且符合用户的操作和认知习惯。 什么Unicode? 为什么要使用Unicode进行多语言和本地化? 
目前，Unicode的技术标准已经广泛的被IT工业领域的巨头如Apple、HP、IBM、Microsoft、Oracle、SAP、SUN，Sybase、Unisys等许多知名公司广泛采用和推广；从开发语言和平台角度讲也有越来越多的脚本和编程语言开始支持支持这一标准，如：XML，JAVA，JavaScript，LDAP，CORBA，WML等。同时它也被越来越多的主流操作系统内置，如：Windows XP。这里需要说明的是，它的出现意味是一个划时代的产品的来临，因为微软从这一刻起第一次真正把国际多语言版本操作系统全球同步发布！
国际化、全球化主要是为了实现一个最终目的，全球产品的可用性！－ 即在产品的各种不同语言的版本中为用户提供一致的外观、风格和功能和用户体验。因为随着世界的不断变化，国际文化之间的大融合，国内外企业之间的并购和合作，国内公司跨国业务的发展等，这些企业用户都希望在世界的任何角落都能够有一致的人机交互使用体验，快速获取商业价值。这里包括用户母语和外来语言的融会贯通，企业文化之间的无缝对接！
应用场景一
比如说联想在收购了IBM个人P C部门之后，国内的销售总监需要在第一时间了解在美国研发部门的最新产品情况和性能指标现状，那么频繁的实时沟通和企业内部文件交换便必不可少，但是如果企业沟通软件出现了软件界面上或者中英文文字由于不可读造成互相不兼容，那么可想而知后果是什么，这可能导致一个季度的预算和销售都可能会受到影响，数以千万资金可能遭受损失…
应用场景二
当前欧美市场上普遍流通的软件产品大多数属于国际化软件产品，而我们国内自主研发的软件产品却大多还没有考虑或很少考虑产品国际化问题和支持多语言版本，但是欧美市场上的软件产品、尤其的企业应用软件又大多根据西方的标准和作业习惯进行开发和定制，那么国内的企业是不是一定要“娶”一个“洋媳妇”而找罪受呢？最直接的案例便是如同十年前盛行的ERP一般，但是和产出不成正比、周期工期冗长，最终导致严重整合问题；或者买了个看似成熟的国外中间件进行二次开发，但是又有多少企业的市场变化能够等到软件整合的“功德圆满”？这其间抛开企业自身开发成本和项目管理不说，单就一个本地化问题就足够让人头疼，因为本地化并不仅仅是界面和语言上的本地化，还应该包括用户体验的量身定做，而买来的半成品却往往不会为我们考虑这些！
那么既然市场需求如此巨大和强烈却很少有人试水一跳？这里原因当然很多：一是国内软件企业的项目管理水平相对还比较低和缺少国际化的眼光：很少企业愿意放弃目前短期项目和直接的利益去做些长远的规划，所以我们纵然有着世界上数量最为庞大优秀的技术人才群体和资源成本优势，观悉近代计算机和软件发明和世界性通用标准的拟定，以至于在全球范围内取得广泛影响的软件产品我们几乎还没有；二是归其原因并不是专业技术人才的缺少，而是缺乏对于远景有规划能力并且可以洞悉国际形式、拥有资本运做能力的产品创业型企业，而放弃了自己做大做强的机会。
软件国际化和多语言的最高境界就是很好的本地化。近年来随着国际化和本地化需求的不断出现和生产力水平的提高，但是国外大型国际化软件常常需要发布几十种语言的本地化版本，但是对于亚洲表形意字体的处理，显然我们国内的研发企业更有有利，因此我国自主研发或者开发海外项目支持多语言的软件和产品本地化都具有非常大的发展潜力。并且可喜的是，我国的一些软件本地化公司凭借为欧美国软件公司长时间提供中文软件本地化服务，并且已经与客户形成了互相信赖的客户关系和取得了长足的经验，所以国内软件企业自主研发的国际化和本地化软件产品无疑会在近年开始展露头脚，融合于国际化的趋势之中，成为未来的中坚力量。
多语言迫切需求的产生和广泛应用－唐骏和MS Dr International？ 那么软件产品的国际化和多语言的历史有多久了呢？以我们最为熟知的国际化软件产品成功典范－“微软制造”为例，在微软最早提出windows软件平台国际化和本地化的观点的人究竟是谁呢？几经追溯，我们发现了一些有趣的结果，那就是身为国人并且曾经担任微软中国区总裁的唐骏先生对于Windows多语言和本地化、尤其是亚洲表形表意版本（韩文、中文和日文等）做出的贡献；另外就是在Windows国际化应用开发领域久负盛名的神秘人物Dr. International（后来查证为Nadine Kano博士）。首先让我们深入了解一下具体的细节，以下是引自微软前中国区总裁唐骏先生自己的一段自述： “1993年4月，唐骏博士后毕业，用卖专利的8万美元开了三家公司：一家做软件、一家做文化经纪、一家做法律事务服务。后来当唐骏已经有几十万美元身价的时候，他突然关闭所有公司，决定去微软做程序员每年领几万美元的年薪。但是他后来说“我发现我的企业做不大，我做事情就喜欢将事情做大。”随即唐骏从洛杉矶跑到西雅图对微软说，“只要让我进微软，让我干什么都行。”随后他被分到Windows NT开发组做程序员，当时正值1994年。（这个日期和Dr International出版Developing International Software第一版的时间几乎吻合，不知道具体两者之间是否存在必然的联系?）” “微软当年开发多语言版本的原有思路是：先开发英文版，然后再将英文版移植到其他语言版本中去，所以当时移植一个中文版甚至需要几十个工程师花一年半到两年时间！刚进微软几个月的唐骏一开始便觉得这种办法很愚蠢。在他看来，Windows在开发的时候，就应该基于双字节，这样其他语言的版本软件就可以和英文版几乎同时推出了。微软总部当时采纳了唐骏的建议，NT工作组的700多名程序员要么听唐骏讲解《如何写国际版本的操作系统》，要么看唐骏写的《国际版操作系统开发手册》。这此之后，唐骏又直接负责 Windows日文、韩文和中文版的开发，带领有30多人的团队。虽然刚开始的时候Windows3.1中文版比英文版晚了一年半，到了后来，中文版和英文版几乎可以同时推出！…” 注意，这里唐骏提到的是双字节，已经不是普通意义上的单字节ASCII码，而且虽然当时Unicode在1991年就已经发明和出现，但是一直都没有在大型的系统和软件产品中得到普遍应用，而唐骏恰逢1994年进入微软，所以按照这个时间推断唐骏的自述显然是有一定说服力的，那么唐骏也很有可能是在微软较早考虑运用Unicode技术提供全球同步多语言版本的人之一。同时也可能为Microsoft Press出版社出版的Developing International Software一书做出过很大的贡献，这也就难怪他会获得微软授予唐骏最高荣誉——比尔盖茨总裁杰出奖两次之多了。 后者就是微软官方网站http://www.microsoft.com/globaldev/default.mspx的“坐诊”博士International十几年来一直兢兢业业的回答关于本地化和国际化的问题，而对于他的贡献大家如果有兴趣的话可以认真的阅读他的著作和到网络上查看，但是至于与唐骏的渊源就无从考证了。
从具体技术实现角度来讲，具体的集成方式都有哪些?
虽然我现在已经不是职业的程序员，但是使用Delphi开发新产品的快速交互原形一直是我最爱，因为它有着丰富灵活的语法和强大的可视化编程界面，并且提供可插入式的第三方支持控件，这可能也是Delphi得以被普遍认可和应用的主要原因。这里先来介绍一下由TntWare提供的Delphi第三方插件TnTUnicode Controls来迅速快捷的开发多语言应用。
 图表 1成功的安装TnTUnicode控件后Delphi的界面上会出现上面的操作板 但是不幸的是，Windows平台对于Unicode的支持是非常有限的，所以利用Windows API封装的控件也不能脱离厄运，目前只支持一些32-bit和64-bit的主流操作系统，如Windows NT/2000/XP/2003等。以下是利用TnTUnicode开发的同一个应用程序的对话框在不同的操作平台上的体现：
图表 2 Windows 2000或者以上可以正确的显示多语言 
图表 3 Windows 95/98/Me操作系统环境下无法正常的显示多语言
这无疑意味着如果使用目前利用Windows API开发的多语言国际化软件产品可能会牺牲一些Windows 95/98/Me的用户，但是不论如何，我们已经尽可能满足了用户中的80%以上，而且从未来的趋势来看，这种取舍也是必须的 － 如果花很大力气去解决一个被几乎淘汰了的低版本平台问题，也是得不偿失的，毕竟微软也在鼓励用户不断升级。对于这一点感兴趣的朋友可以看看目前主流的几个Unicode应用，如现在炙手可热的VoIP产品Skype就是使用TnTUnicode开发支持多语言的国际化软件，在Windows XP使用环境中，我们甚至可以自己增加本地化的语种，但是在Windows 98环境下界面可就不堪设想了。 
图表 4 Delphi开发设计支持Unicode的对话框
VC.net中的内置编译器对于多语言的支持
图表 5 在VC.net编译器中内置的Unicode支持
在Microsoft的.net开发环境中对于Unicode的支持更为深入和集成，只需要在项目的编译设置中选择相应的字符集设置－Use Unicode Character Set就可以自动引入Unicode的支持，在这里就不再详细的叙述。而对于多语言具体的开发设计方案则可以查阅下面的内容。 产品开发设计中的多语言和本地化解决方案和策略 在应用程序和软件国际化产品设计中实现多语言界面，即MUI（Mutli- Language User Interface）的方案可能有很多种，但是基本上每种解决方法都基本是下面这几种方法的变种： 为每个语言版本编译一个相应的二进制资源文件，从形态上看是一个完整Execute文件。
设计开发一个支持并包含多语言资源的动态链接库（DLL）但并不涉及程序核心代码的二进制文件。
对应每种语言版本都设计开发一个或一组相对应的资源动态链接库（DLL）并不涉及程序核心代码的二进制文件。 解决方案一描述和示意图 这种方法是在Unicode标准出现之前所普遍采用的传统的多语言解决方案，也就是当时唐骏所提出的认为比较愚蠢的方法。因为它需要对不同的语言版本进行翻译之后，单独对于特定语言版本应用程序进行文字资源翻译和重新编译工作，这样的做法对于一个小型的工程和应用尚且需要非常大的工作量并且会占用大量的磁盘空间。最重要的是还会带来版本的维护问题：如果一个翻译字符串发生了改变就需要对全部的工程重新编译，那么可想而知对于当时庞大的Windows NT来说意味着什么。
 解决方案二描述和示意图 上一种方法最大的不利之处就是需要大量的重复工作和耗费大量的人力和物力，而本方法的主要思想是把界面文字资源和与核心代码无关的资源相分离，尽量减少多语言资源对于功能代码的影响，而对于语言的切换在DLL中做适当的Code Page的切换处理，这样一来就可以有对于核心代码并不了解的本地化工程师，甚至是经过培训的翻译人员维护这个DLL，把注意力和焦点集中到界面语言和语法问题，相对减低了成本和减少了工作的失误。但是这种方法并非没有缺点：这种方法需要实现就把语言资源和核心代码分离的很好，但是对于一个正在成长中的软件产品显然是不现实的，而且可能会给程序员带来一定的困扰。 
解决方案三描述和示意图 这种方法应该说是对于上一种方法的自然延伸，而且从实际应用和管理角度应该是最为科学和合理的方式，它并不是把所有的语言包都整个封装在一个资源文件，而是把他们相对物理分开，这样一来便可以针对于大型软件系统不同的模块有针对性的进行多语言处理，并且方便对新的语言版本进行扩展，这基本上就是微软目前解决方案，当然，我们阐述的仅仅是基本的原理，事实上的方案会异常的庞大和复杂，并且非常具体，甚至于对于同一个Message Box的提示语句多语言字符串的处理。 
多语言界面的可用性测试和管理方式 通过正确有效的多语言解决方案开发设计了具体的应用之后，我们还需要经过不断的版本更新，从Beta发布直到正式版本。这里最重要的环节当然是可用性测试，而多语言界面的测试与软件核心功能特性测试并不相同，可以称作国际化测试和本地化测试：如用户界面一致性测试检查和语言翻译质量检视、界面术语和专有名词的一致性等等。因此这里需要有的懂得测试方法的本地化工程师或易用性测试人员，通过严格的、不断的Checklist进行比对和分析，周而复始，迭代完成。由此可见，多语言软件产品是系统的工程，而最终解决的问题却毫无疑问的是界面语言用户体验的一致性，甚至是全球用户体验的一致性！ 
参考书目
http://www.microsoft.com/globaldev/default.mspx Microsoft's global development and computing portal.
Developing International Software, Second Edition (Paperback)
by Dr. International "Developing internationalized products is a continuous balancing act..." (more)
A Practical Guide to Localization (Language International World Directory) (Paperback)
by Bert Esselink
Usability Engineering – International Standard Jakob Nielsen
Case Study: Porting an MFC Application to Unicode Microsoft® Corporation 如您喜欢我们的文章并希望转载，请阅读我们的转载注意事项 |
