我想到了三種方法來創建和維護.NET項目中的資源WinForms使用Visual Studio 2008.（我相信應該有超過三個）在開始實施我們的產品國際化之前，我需要確定一個。這是一個很好的方式來維護國際化資源在.net
就我個人而言，我不喜歡第一種方法，因爲它創建了大量的資源文件。我們在這種方法中唯一的優勢是我們不需要手動設置UI元素中的文本。
我喜歡第二種和第三種方法，因爲它們易於維護，並且只需要處理一組資源。所以沒有字符串和消息的重複。易於翻譯也。
你的想法是什麼？請分享。
如果應用程序國際化意味着不僅僅是翻譯文本片段，還應該與第一個文件一起進行。您可以創建附屬程序集來部署不同的文化。通過這種方式，您不僅可以本地化文本，還可以對圖像，控件佈局等進行本地化。這就是Microsoft推薦它的方式，並且他們有充分的理由採用這種方法。
我發現最簡單的國際化方法是在電子表格或製表符分隔的文件中簡單地維護應用程序中的所有不同文本片段（標籤，按鈕，表格標題等）的列表排序，然後將此文件發送給譯員，以便爲每種語言添加（在每個語言的附加列中）所有翻譯。
然後，您可以在每個表單的Load事件中調用一個簡單的方法（這些表單都用英語維護），它會遞歸地遍歷表單上的所有控件，並將它們的Text屬性更改爲翻譯的值，無論您使用哪種語言將應用翻譯成。該語言可以通過編程方式確定（我忘記了在.Net命名空間中的位置），也可以在應用程序首次啓動時有一個簡單的語言選擇對話框（第二種方法的優點是可以將您的應用程序轉換爲用戶希望的任何語言，而無需爲所有Windows設置語言 - 這對於信息亭應用程序特別有用）。
在我看來，創建和維護每種表單的所有不同的國際化版本是一個很大的麻煩，儘管它在翻譯文本值與英文版本的大小差別很大時很有用。
個人而言，我更喜歡第一種方法，因爲上下文（在您的情況下，表單）對於翻譯者完美地完成他的工作非常重要。在第二種和第三種方法中，上下文已經消失，因爲它只是一個字符串列表。
是的，第一種方法可能是一個痛苦的維護，但至少你的應用程序將被翻譯correclty。
譯者是否有能力在設計師中看到表格？如果他們這樣做，他們將有上下文。否則，即使採用第一種方法，他們也不知道在什麼情況下使用哪個詞。 – ashtee 2009-09-08 19:26:27
我們使用翻譯公司的外部翻譯，所以他們不能在設計師中看到表格。所以，我們正在努力爲他們提供儘可能多的信息（截圖，用戶手冊等）。 – 2009-09-08 19:44:32
我傾向於使用VS創建項目並提供默認的資源集合，但通過SDK工具winres.exe，resgen.exe和al.exe在Visual Studio之外維護任何其他資源。
您可以將資源維護在一個相對簡單的每個文化夾一個文件夾的文件夾結構中，只需要一個或兩個批處理文件即可將資源構建到附屬程序集中。這爲您提供了將VS解決方案保留至核心產品的優勢，並且可以在事後完成所有本地化。
我個人喜歡添加一個項目.Resources。 接下來，我啓用Microsoft MAT（https://developer.microsoft.com/en-us/windows/develop/multilingual-app-toolkit）並通過MAT管理我的所有翻譯。
這種方式，您還可以回收從其他解決方案的翻譯，節省您的時間;-)
注意，在兩個不同的上下文中的字符串可以在如此具有一種巨大的資源文件，以避免重複的字符串另一種語言翻譯不同沒有必要爭論。 – 2009-09-03 18:26:57
很高興知道你的.Net部分是什麼意思？ Asp.Net，WinForms或WPF？ WPF獲得了一些非常好的本地化功能，而其他功能則沒有。 – cwap 2009-09-03 18:30:04