2007年05月16日

 

开发国际化的软件要解决不同语言文化下的用户界面、字符串资源、日期货币显示格式等的本地化问题,除了日期货币等不同国度的显示格式外,都是关于维护一个资源集合的问题。集合中有针对不同语言文化的资源,包括用户界面的显示内容与方式,翻译好的字符串资源,声音资源,图片资源等。其实日期货币格式也是一个集合,只不过系统不是做为一个资源集合的方式来支持。

.NET为本地化工作提供了许多便利。例如Form有一个Bool属性Localizable,打开后可以为Form选择不同的Language属性,从而VisualStudio自动建立此Form在不同Language下的资源文件。当Form在设计期时,通过切换不同的Language属性就可以设计各个本地化版本。VisualStudio还可以识别不同Language下的规范命名,自动将各个Language版本的资源分别编译生成为一个个的Satlite Assembly,并生成在正确的资源搜索路径上,而且为Form生成的C#代码,可以在启动时根据线程环境选择正确的资源,并且在初始化界面元素时使用资源中的内容。基本代码如下:

System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(Main));//自动完成根据环境加载正确资源,支持Fallback

resources.ApplyResources(this.button1, "button1");//所有的界面元素都会使用资源进行初始化

resources.ApplyResources(this, "$this");

 

而没有打开LocalizableForm初始化代码如下:

this.Text = "Form1";

 

.NETSDK中还提供了WinRes.exe,实现在VisualStudio之外对Form的各个本地化版本进行翻译、修改。

 

以上的内容在微软文档及参考书中都可以找到,但是如何实现软件中的非Form元素资源的本地化呢?

第一个想到的办法,就是在某个FormRES资源文件中加入其它类型资源,如字符串资源等,但由于这些RES都是由VisualStudio自动生成的,在下次修改Form再次生成时,手工加入的内容不会被保存。

第二个是使用VisualStudio为每个项目自动生成的一个Resource文件,位置在项目文件夹下Properties文件夹内,文件名是Resources.resx。但这如果加入其它语言文化的文件呢?手工方式可以是使用资源编译器编译手工编辑好的资源文件,再使用ALAssemblyLink)将其链接成一个SateliteAssembly。有没有自动办法呢?

在解决方案管理器中无法向Properties文件夹添加文件,所以只能手工添加,方法是先将Resources.resx复制重命名为类似Resources.zh-CN.resx的本地化资源文件名,再手工修改项目文件,如果使用C#就是扩展名为csproj的文件,加入以下内容:

<EmbeddedResource Include="Properties\Resources.zh-CN.resx">

<SubType>Designer</SubType>

</EmbeddedResource>

重新打开项目后,在解决方案管理器中就可以看到新加入的资源文件了,而且可以打开编辑。分别在Resources.resxResources.zh-CN.resx中添加一个字符串资源,内容分别为英文和中文,运行程序后可以看到已经根据环境显示本地化字符串了。而且支持Fallback,即删除Resources.zh-CN.resx中的对应字符串后,程序会自动显示Resources.resx中的内容。

 

这样就可以在程序开发过程中,根据默认的资源开展本地化工作,将内容保存到对应的资源文件中,VisualStudio会自动将规范命名的资源文件生成对应的SateliteAssembly

 

VisualStudio还为Resources.resx自动配置成生成StronglyTyped类,这个类只要生成一次就行了,使用它访问资源会自动支持多个SateliteAssembly

2007年03月28日

 

今天走在路上,想着一个使用配置文件保存对象配置的问题,突然冒出这么个想法:把读取到的配置保存在一个对象中,这个对象的类就叫Pill,这个对象就叫RedPill,然后被配置的对象有一个方法叫做EatPill,将Pill类的对象做为参数。

这样当被配置的对象Eat不同的Pill时,就可以具有不同的能力。

Blue pill or red pill?What’s your choise?

2006年11月24日

年轻时喜欢变化,喜欢新鲜事物,对技术演变接受速度快,总体体验是刺激、兴奋,而且有足够的精力去沉浸,去探索,在不断学习的过程中,内心不断获得满足感。还记得刚开始学习写程序,使用汇编,通过调用BIOS,在一台386电脑屏幕上打印出一行字符,现在看起来微不足道的一件事,当时却兴奋不已,可以控制这机器的感觉真好,从此走进这片新天地。有那么多东西可以学习,与机器交互的过程单纯而愉快,经常独自研究到深夜。一本Undocumented DOSC的启动代码,谈到DOS内部机制,读完后感觉掌握了很多流行商业软件的关键技术,Cutting Edge的感觉真好。


现在InternetUndocment很少见,Overdocument则随处可见。


这时Windows开始进入视野了,DOS开始被称为一种小型操作系统,原来让人欣喜若狂的技巧突然无用武之地,最喜欢读的书成了Undocmented WindowsUnauthorized Windows95。那个时代真有意思,那么多Windowsdocuments,但真正让我理解Windows内部机制却是两本UndocumentedUnauthorized的书。原来高级的“菜单”、“按钮”技术成了基本配置,“常驻内存”被并行运行的程序代替。平台升级了,原来的很多问题不再是问题,但真想写软件时问题却一点没减少。


因为不喜欢MFC那种简陋地开发方式,转向VBDelphi这种RAD开发环境,学会在VB中操作指针后不满意VB生成的庞大执行文件,转向使用DelphiDOS时代我就在TCTP之间选择了TP,我属于喜欢PASCAL那类。学习过CC++,但用得最多的还是PASCAL


这时候.Net出现了,原来还在比较VCLMFC谁优谁劣,突然发现Microsoft竟然把类似VCL一样的类库集成到操作系统中去了。免费就可以下到.Net Framework SDK,免费就可以得到所有的编译器和整套的类库。使用Delphi成了隔靴搔痒,于是开始学习C#


现在.Net Framwork3.0Vista已在眼前,面对WPFWCFWWFLINQAtlas这一连串眼花缭乱的技术,感觉窒息。


了解原理,了解机制,不等于可以开发出有用的软件。但技术演变给我的时间好像只够理解它而不是开始利用它。也许让自己成为Evangelist更适合一些,而不是Developer


 

本篇文章使用aigaogao Blog软件发布, “我的Blog要备份”

2004年03月15日

今天读了李维的《Borland传奇》的前四章,虽然我对Borland的产品也有特殊的感情,但越读越佩服Microsoft。在Borland和Microsoft在开发工具市场上竞争的十几年里,Borland有取得领先的时候,甚至有打得Microsoft一时无法翻身(Borland C++3.1、Delphi)的时候,这也就是它“传奇”的地方,但一时的辉煌总是被错误的决策打散,相反Microsoft总是不断地取得成功,成功后加以筑固,给竞争对手的空间越来越小。书中Borland里的R&D人员很多都是悲剧英雄,而Microsoft更象是君临天下的统治者。现在Anders、Chuck、Blake都已去了Microsoft,我为他们感到高兴,相信未来会有更多更好的技术诞生于他们的手中。


在C++的战役中MFC为Microsoft最终的胜利起到了重要的作用,Delphi也是凭借VCL打出了一片天下,而在.Net平台C#语言、编译器、FCL尽在Microsoft掌握之中,Borland只剩ALM这个唯一的悬念,不过也是行动迟缓且雷声大雨点小,Borland又到了生死一线的时候。虽然我很喜欢Microsoft现在的开发平台,但也并不希望Borland消失。没有竞争的环境,Microsoft也不能取得现在的成绩。


从技术人员的眼中看Microsoft的一些做法可能不太光明正大,比如派人去竞争对手的技术研讨会上提问关键技术,模仿对手的产品,价格战,大规模的挖角,但只要不违反规则,一样可以取得成功。一个公司最重要的首先是能获得赢利得以生存,谁也不希望“光明正大”地从市场中消失。

今天在BOB大叔的BLOG中看到一篇


Web Services? What has the industry been smoking?


引发了二十余条评论,其中还夹杂着数条关于什么是Aconym什么是Initialism辨论,看来“执着”是Technology Geeks共同特征;-)。


在我看来,在纸上谈论一种技术是否有效,是否有存在的价值是没有意义的。如果能找到适用的地方,而且使用后效果还不错,那就能证明它的价值,否则相反。某种技术所能解决的问题也有一定的范围,应用它就不能超出这一范围。不同的技术背景、不同的应用领域的评判者会得出不同的结论。


在看过这些评论后我还有两点与所讨论的技术无关的感受,一是即便是Bob大叔这样的权威人士提出的观点也并不都是附和的声音,反对意见不少且都很中恳,看完后我也觉得Bob大叔有点偏执了,Web Service在现实中已得到广泛的运用这本身就说明了它存在的合理之处;二是在这些评论中大多都是就事论事,客观的分析问题,或提供其它的相关材料,基本没有进行人身攻击的。既不迷信权威又不乱扔板砖,非常好的技术氛围。


在Robert L.Class的《Facts and Fallacies of Software Engineering》书中提到有两种人:Academics和Practitioner,前一类可以说是学院派,后一类是实践派。两者都可能提出新的思想、新的方法,不同的是前者往往来自理论研究及小范围的实验,后者来自大量的实践。如果考虑将他们的思想运用到实际中去,那后者的更直接、更好用,而前者的需要经过一段时间的打磨、一定程度的调整;如果考虑在这一领域中有所突破,那往往是来自前者,因为这些思想和观点不受当前环境的束缚。做为工程技术人员对后者会更容易接受些,因为它可以直接运用到实际工作中去,而“象牙塔”中的东西离我们有一定的距离,但也不能轻易否定它的价值。


不管是新的开发方法还是新的软件技术,包括正在开发的软件在测试或投入运用前都可以认为是一种理论上成立的东西,正确与否还有待实践的检验。这种检验往往是需要一定代价的,如果有人已经为此付出了代价就不应该再重蹈覆辙。


这就显示了信息的重要性,全面、及时、准确的信息收集是非常有价值的工作。权威人士的BLOG,对某一专业领域是非常好的信息来源。