分别尝试过2种多语言的实现方式:1.文件、2.资源包。
一、简要说一下实现过程
1、文本
主要是以文本形式存储key-value键值对,然后用工具类Localizer负责加载对应的文件:en-US或zh-CN
_Confirm=Confirm //en-US
_Confirm=提示 //zh-CN
MessageBox.Show(Localizer.Instance["_Confirm"]); //使用的时候
2、资源包
这是微软默认的实现方式,主要是生成对应的资源包*.resources.dll,并通过ApplyResources加载。
//在设计器->属性里,设置
Localizable = true;
Language = 英语(美国);
改完之后,会自动生成一个form.en-US.resx,编译后生成对应的资源包*.resource.dll。
//使用的时候
var res = new ComponentResourceManager(form.GetType());
res.ApplyResources(form, "$this");
foreach (var ctl in form.Controls) {
res.ApplyResources(ctl, ctl.Name);
}
二、做个对比
1、文本 | 2、资源包 | |
---|---|---|
功能 | 只能支持文本和位置,但位置调整很不方便,暂不支持图片(需要序列化),无法支持动态列 | 能很好的支持文本、位置、图片,且调整方便,无法支持动态列 |
子系统的工作量 | 是资源包的3倍,en-US/zh-CN都要手写,子类里要覆写LanguageChanged事件 | 只需新增其他语言如en-US,默认的语言不用动,也不用覆写事件 |
不实现该功能时,对子系统的影响 | 必须正确实现所有key-value,否则界面上会显示key值 | 无 |
容错性(子系统实现有误时,系统是否会出错) | 低,子系统必须正确实现所有key-value,如果遗漏,界面上会出现不正确的描述。界面变更时,也容易产生遗漏 | 高,如果有遗漏,就显示默认语言 |
灵活性(发布后是否可以任意修改) | 高,子系统甚至用户都可以随时修改不合适的翻译,不需要再次编译 | 低,每次修改后都必须重新编译生成并发布 |
可维护性 | 不需要针对新的控件做特殊处理 | 需要针对新的控件如Dx等补充相应的ApplyResources代码,需要逐步完善 |
适用范围 | 较广,语言无关 | 只针对.net下的应用,因为有一整套自动生成代码、资源本地化工具、类库的支持 |
三、小结
以.net的应该来说,推荐使用方式2,功能全面也很方便,毕竟功能和工作量才是我们关心的大头,还是印证了那句话,微软的东西要用就用全套。
作者:AlexanderYao
出处:http://alexanderyao.cnblogs.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。