[源代码] SailingEase .NET Resources Tool （.NET 多语言资源编辑器）

SailingEase WinForm Framework WinForm开发框架开发手册：http://docs.shengxunwei.com/Home/Browser/sewinformfw/

我在2016年10月发过一篇博客，介绍了我写过的一个多语言资源文件编辑器，并且做为免费软件发布给了出来。

陆续收到了一些朋友的反馈，有朋友很热心提了很多建议和关心的话，还有朋友发红包过来，让我很感动。

同时，这也是一个基于 SailingEase Winform Framework 的简单项目，使用了 SailingEase Winform Framework 所提供的模块化、常用控件/组件、自动更新等等诸多功能。

现在将软件在应用层源代码100%通过只读的方式进行开源，你可以通过浏览器进行在线浏览：

http://sourcecode.shengxunwei.com/ssr/

通过源代码，你可以直观的看到软件的具体实现，了解到一个模块化 Winform 应用程序的设计和实现方法，还包括了一个 Winform 的常用控件包，是我当时用 GDI 写成，有兴趣的朋友也可以了解到使用 GDI 编写 Winform 控件的方法和模式，同时可以了解到 SailingEase Winform Framework 的具体应用实例。这个软件的功能模块并不复杂，相信是一个很好的 SailingEase Winform Framework 入门项目。

大部分代码写于2010年左右（7年前），所以有一些考虑不周的地方，高手勿要见笑。

接下来我会通过同样的方式，将过去编写的软件/组件进行开源。

之所以以只读的方式开源，请见谅，不是开源界也会承认：开源!=免费吗? :)

有关 SailingEase Winform Framework，可以参考：

http://www.cnblogs.com/sheng_chao/p/6084144.html

以下是 SailingEase .NET Resources Tool 原博客及软件的详细介绍：

================

这是我2010年左右，写 Winform IDE （http://www.cnblogs.com/sheng_chao/p/4387249.html）项目时延伸出的一个小项目。

最初是以共享软件的形式存在的。

后来忙于其它事情，没有精力再去打理，就被雪藏至今，最近抽了几天时间，把软件里的注册验证相关逻辑都去掉了，以完全免费的形式发布，希望对大家有用。

痛点：

通常我们为了让软件支持多语言，会使用 .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 中的错误提示：