痛點：

通常我們為了讓軟件支持多語言，會使用 .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 中的錯誤提示：