cpploverr

常用链接

统计

最新评论

delphi中国际化的几种方案及比较(转)

delphi中国际化的几种方案及比较(转)

随着全球化程度加深,软件越来越像蒲公英,到处飘散、扎根。这其中要解决的是不同语言的显示问题。我们当然希望一套程序,可以不修改代码就可以支持不同的语言,不要去维护很多的版本。

        首先要谈到的一个问题是乱码问题,因为delphi win32到11.x版还是不支持unicode,所以一般使用Ansi码,有这样几种情况会显示乱码:

使用的语言文字与系统当前设定的语言不一样;比如简体版QQ在繁体操作系统(或简体操作系统的区域设置中“非Unicode程序的语言”设定为繁体)就是乱码。即使改变Font.Charset,某些元件仍然会出现乱码,如StatusBar。因此,在越南文版的windows显示越南文,在伊朗文版的windows显示伊朗文,不要在越南文版windows显示伊朗文,在伊朗文版windows显示越南文,这样就能确保没有乱码问题。好在一般这样的错位用法也不多见。
系统没有安装你要显示的语言的语言包;
        如果你要保证完全无乱码,必须考虑使用unicode码,使用成套的支持unicode的元件,如tnt,但它在UI变现上比较单一,你不可能不使用别的元件。

        言归正传,首先,看看哪些地方的字串需要实现多语言,并来看看各种实现方法的优劣。
            1、界面上的元件,如TButton的Caption;
            2、主动弹出的消息,如ShowMessage('Are you sure?'),Raise Exception.Create('Error!');
            3、例外错误举发的报告信息,如f/0引起的exception;
            4、第3方元件包内部的上述字串;

        实现多语言的方法很多,列举一二:
            1、delphi自带的Resource生成工具
                此工具把专案的dfm文件里的所有字串以及pas中定义为ResourceString的字串列举出来,按不同的语言编译成不同的Resource,专案编译前先选语言,每种语言编译成一个exe。

                这个工具使用很不方便,不是一个完整的解决方案,跟Borland的Midas的demo一样(TClientDataSet通过ProviderName连接到RemoteDatamodule的TDataSetProvider,实际开发Erp系统时,谁会放100个TDataSetProvider连接到100个TDataSet?),只是一个原理尚通的示范。

               首先,由于dfm本身也是资源文件的一部分,因此每次修改都要“Update Resource DLLs...”,如修改Button1为Button2,如果你忘了,运行时就会报“找不到资源Button1的错误”;提供的字典编辑画面中,出了字串,还有Left/Top等资料;字典不能重用,在一个模组翻译了,在第2个模组还要再翻译相同的词。

               其次,每种语言一个exe/bpl,如果你的系统是Package切割,bpl也是每种语言一个,还要小心别把不同语言的bpl组合在了一起,到时候一个画面显示中文,一个显示德文(有一个可能是乱码)就惨了。

               再次,在作bpl组装的系统时,第3方元件如果没有提供多语言的方案,你就需要修改第3方元件,但一般我们不这样干,因为第3方元件会随时更新,难道每次人家更新你也再更新人家。

               因此,一般都没有人使用Delphi本身提供的这个方案(除了作demo)。

            2、Resource dll方式

               用单独的ResourceDll,用LoadResString等函数获得翻译字串,但你要到处写这个函数来一一替换,特别是Form上的字串,噢,会累死人。字典可以重用。
            3、网上讨论很多的ini文件方式
                此方法是写个替换的引擎,在运行时从ini文件读取语言字串来替换画面元件的显示文字。这个方法比第一种进步很多,不需要每种语言编译一个exe了,只要提供不同的ini文件就好;画面修改时如果ini没有同步更新也不会出现致命错误,最多就是某个文字没有转换;引擎也提供了字串转换函数,因此也可以处理主动弹出的消息。这个方法在文件格式上有三种不同的实现:
                (1)、[编号]=[字串]
                      每个字串从1开始编号,1,2,3,4......,很麻烦,代码要修改,当然运行时切换语言没问题。
                (2)、[元件.属性]=[字串]
                      这种实现把元件instance一一对应,用RTTI来判断属性,替换很精确,也可以运行时切换语言。不足之处是,略显呆板,多个元件相同的字串会多次列出;没有扩展性,表现TListView的Columns等复杂元件时比较吃力。
                (3)、[旧字串]=[新字串]
                      不管元件的instance,ini是纯粹的语言对照表,或者叫字典,扩展性、运行时切换语言可能在引擎里。不足之处是不能处理一词多义。

                总的说来,这种方式有很大进步,但为了用ini文件,大家还要费力的破解64k的限制,更专业的方式是使用自定义的文件格式。
                在简单性方面,无疑是这种自定义的转换引擎,[旧字串]=[新字串]的文件格式来得方便,借助字典管理工具,字典文件可以重复使用,也可以提供给专业翻译公司翻译。那么剩下的问题在引擎上,如何方便,最好用户不写一行代码;如何扩展性强,支持任意的第三方元件;如何有弹性,同一个画面有多种语言的文字,同一个词可以转换成不同的意思......

            4、给每个元件类继承一个子类,在子类的Loaded方法里转换文字。由于要处理的都是叶级元件(虽然TLabel、TPanel都是从TCustomControl来,但不能只处理TCustomControl),工作量比较大;对旧有程序除了换元件无能为力。

            5、为每个元件类注册一个转换函数,引擎遍历Container,为每个元件找到血源最近的转换函数,调用这个函数转换这个元件的文字。这样可以不必处理叶结点,只需在恰当的元件层上注册函数;不必改动旧有程序。設計時Form上只需要放一個轉換元件,這個元件在Loaded后開始掃描Form上的元件,從for I:=0 to ComponentCount-1或從for i:=0 to ControlCount-1遞歸,找到一個元件就去查找其血緣最近的註冊函數,然後調用這個函數替換其文字。因爲註冊函數是額外加上去的,所以不會動到舊的代碼,對任意第方元件都可以擴展支持,且也不用去修改人家第3方元件的代碼。

        我认为第5种方法很优雅,看起来比较干净。用GOF的设计模式来套,这属于Mediator pattern(中介者模式)。多年前,我们使用一个叫TXPMenu的元件来获得XP风格的界面,也是感觉到它很干净,一个元件就搞定一切,不用TLabel换成TFlatLabel,TButton换成TFlatButton......我记得《程序员》上还有文章专门称赞这个元件。但那个元件没有使用中介者模式,不能很好的扩展对第3方元件的支持。

        最后,我们畅想一下,如果我是Borland,如何在Delphi里完整支援多语言。Delphi提供了一个区块定义的关键字“ResourceString”,在这个区块定义的字串常量,编译器会把它编译在exe文件的资源区,运行时用LoadStringA这个Windows API来读取,因此有些外部转换工具可以直接从exe文件读取这些资源字串,再写入转换后的字串;内嵌的转换引擎也可以拦截这个API函数来转换文字。但是如果exe里的字串资源化不彻底,就无能为力,这个不彻底恰恰来自Delphi的DFM文件,Delphi把DFM文件整个作为一项资源放在exe里,其上的字串就没法决定是否要don`t resource(Delphi源码里很多常量字串都有这个提示)了。

        如果除了string,widestring,ansistring等等这些数据类型,delphi增加一种数据类型multistring,然后修改vcl元件定义(拜托Borland连同Unicode一起解决了吧),像TLabel.Caption定义成MultiString,对MultiString类型,有一种专门的处理方法,如类似ResourceString用LoadString API来处理,每次读取就转换一次,但应该比这个内容更多,比如要传出instance,然后提供一个全局的ApplicationMulti元件,类似ApplicationEvent,让外面能捕捉到。至于字典,只能外部用户提供(当然可以制定一个标准格式让delphi人都可以共享交换)。

       此法看起来可行,但还有个效率问题要考虑,(1)每次读取都转换,对频繁draw的东西效率低;(2)比如一个ToolBar有好多的ToolButton,批次更新时一般都会用BeginUpdate/EndUpdate,vcl如何告知后代来提高这种效率。(补记:效率看起来不是问题,对多次字串更改导致频繁draw,其实元件自己已经会用beginupdate/endupdate处理,外部不会涉及)

---
本文章使用“国华软件”出品的博客内容离线管理软件MultiBlogWriter撰写并发布

posted on 2010-01-14 07:47 cpploverr 阅读(763) 评论(1)  编辑 收藏 引用

评论

# re: delphi中国际化的几种方案及比较(转) 2010-01-14 12:28 陈梓瀚(vczh)

一个方法是
1:把一种语言的文字写进资源。
2:当你决定release压盘之前,让一堆翻译的人去改exe,变成很多种语言。
3:压盘。

第二个方法:使用makefile,每次编译的时候都产生所有语言的版本。  回复  更多评论   


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理