分别尝试过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,功能全面也很方便，毕竟功能和工作量才是我们关心的大头，还是印证了那句话，微软的东西要用就用全套。