痛点：

通常我们为了让软件支持多语言，会使用 .NET 自带的资源文件来存储不同的语言资源，在程序中加载和调用，但是对于大型工程或者团队开发，包括不断演进的版本，会让多语言开发十分的麻烦，存在许多不可控的因素，比如以下几点：

1）过去的资源调用方式主要是以字符串作为key来获取，而开发人员在获取资源时，可能出现拼写错误；
2）修订资源文件时，对原有资源文件标识进行了修改，而未能同步到程序的各处；
3）修订资源文件时，误删原有资源条目，或删除误认为已不在使用中但确仍在某处需要的条目。
4）无法得知某条资源文本的使用情况：是否在使用，是否在多处使用。
5）增加语言资源时，难以保证各语种资源完全同步，尤其在是资源数量较大，修订次数较多时；

如果使用字符串作为key的方式来调用资源，以上问题都无法在项目编译时作静态检查，也就是说出了错误很难发现。

此外还有两个问题，让开发过程中处理资源文件十分的麻烦：

1）在 VisualStudio 中直接编辑资源文件，只能一个文件一个文件的单独编辑，比如中文和英文两个资源文件，我需要打开两个独立的窗口分别编辑，要来回切换，并且最最重要的是，VisualStudio 不会去检查你的两个资源文件中的条目，是不是一一对应的，它们之前没有什么联系和映射之类的关系，其中一个资源文件中多了一条或少了一条，或是KEY不小写拼写错了，都是不知道的；

2）没有好的与翻译人员协调的方法，如资源的导入、导出、自动检查；没有好的办法把语言资源交给翻译人员，并导回来，而且在导回来时，几千条甚至更多的资源条目，有没有疏漏，误删除，没有办法知道。

分析与构想：

我们分析 .NET 自带的资源机制，其在将资源存储在资源文件中后，会生成一个对应的 Designer.cs 文件，如果有多个语言版本的资源文件，就生成多个对应的 Designer.cs，但就是没有将他们抽象起来。

当时我想，如果能够用接口（Interface）把不同的资源文件的实体类，约束起来，在程序中使用时，放弃 Language.Get("key") 这种方式，而是转而使用接口来调用，就可以解决上面1到5点的问题，形成如下结构：

技术分享

那么在代码中，就完全解决了上文中1~5的问题。

对比，引用一个不存在的资源条目：

技术分享

好了，核心需求就解决了。

那么对于用户界面的部分，怎么样加载资源呢？其实相当简单，并不需要开发人员一个一个去设置，在WinForm中，只需要写一个公共类，检索UI上符合指定格式的字符，将其替换为当前资源即可，如：

技术分享

如果是 WPF 项目，直接使用静态资源绑定即可，比 WinForm 更加简单。

还剩两个可用性的问题：

第1个，怎样又好又快的同时编辑多个版本的语言资源？

对于 Visual Studio ，多个不同的资源文件是分别编辑的，问题上文已经说明：我需要要来回切换分别编辑，并且最最重要的是，VisualStudio 不会去检查你的两个资源文件中的条目，是不是一一对应的。

技术分享

所以我在写 SailingEase .NET Resources Tool 时，把不同的资源文件编辑集中到了一起，在一个画面中同时编辑多个不同的资源文件，当我添加一个新的资源文件条目时，只要操作一次即可，不用打开每个资源文件添加一遍（真的很麻烦）：

技术分享

第2个问题：怎样与翻译人员协作

上文提到了，想到的最好的方式是导入导出 Excel，并且在导回来时，能效验一下，这个并不复杂：

我在软件中添加一个区域，比如“德语”，软件会自动生成一个德语的资源列表，这一列的内容现在是空白的，我可以把当前的资源，连同原语言版本（如中文），导出Excel，交给翻译：

技术分享

导出的 Excel 中，包括中原语言（如中文），还包括了 Comments，这样翻译人员在翻译时，有参照有备注，就很方便，翻译完毕后，再回到软件中导入即可。

技术分享

提高效率的辅助功能：

资源行复制：

例如，A项目包含“中文”、“英文”，B项目包含“英文”、“法文”，那么从A项目向B项目中复制资源行时，能够自动将A项目中的英文资源粘贴到B项目的英文资源中，中文资源则被忽略。哪怕两个项目只是区域信息的顺序不同，亦能自动匹配。

技术分享

实时错误检查：

有问题的资源会实时标注出来，在生成的时候会给出提示：

技术分享

Visual Studio 里如果复制资源行的Key是重复的，会不断的弹框强制你先改掉，不然光标就移不走，但实际上做多语言编辑的时候，我有时需要一连复制很多行，然后再修改它们的Key，这就很讨厌了，所以我自己写这个工具的时候，就允许在有错误的时候光标移走，也不强制必须先改掉，而是给出标注，只是在生成代码的时候，阻止生成。

Visual Studio 中的错误提示：

技术分享