多语言的2种实现方式对比
2015-05-19 10:20
253 查看
分别尝试过2种多语言的实现方式:1.文件、2.资源包。
改完之后,会自动生成一个form.en-US.resx,编译后生成对应的资源包*.resource.dll。
一、简要说一下实现过程
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,功能全面也很方便,毕竟功能和工作量才是我们关心的大头,还是印证了那句话,微软的东西要用就用全套。相关文章推荐
- android 2种切换语言方式:应用内切换和随系统而切换 代码实现重启应用
- Spring mvc (四) [继承MultiActionController实现以方法为单位的controller][配置2种请求的指定方式]
- iOS中多线程的实现方式及对比
- 关于db2数据库的自增实现的2种方式
- 菜鸟也疯狂,易语言自绘控件__按钮篇,用所有者自绘方式实现
- 栈(2种语言实现 c/java)
- android应用开发揭秘examples_04-13笔记(Menu的2种实现方式)
- Go语言使用组合的方式实现多继承的方法
- 下划线转驼峰,3种实现方式效率对比
- Go语言使用组合的方式实现多继承
- Java两种方式实现多线程对比
- 分布式锁的三种实现方式及对比分析
- ListView的Adapter的三种实现方式及性能对比
- 命令式语言和声明式语言对比——JavaScript实现快速排序为例
- dojo EnhancedGrid的两种实现方式对比
- Servlet实现文件上传 2种上传方式@ MultipartConfig
- python与Java线程实现方式的对比
- php gettext方式实现UTF-8国际化多语言(i18n)
- 生成大量随机字符串不同实现方式的效率对比
- 多线程基础1-线程2种方式、2方式实现购票、join、yield