我们使用 resx 文件来本地化我们的 Web 应用程序。当只有一个页面使用某个短语时，我们通常会创建本地 resx 文件（映射到特定页面），而当多个页面需要该短语时，我们会创建全局 resx 文件。
但是全局 resx 文件的好处是它们是一个类，您可以像调用类的属性一样调用这些短语：
资源.UI.iNotFound
所以我在想 - 为什么有本地 resx 文件？为什么不为整个应用程序使用一个全局 resx 文件，这样可以避免调用不存在的短语导致运行时错误？
我敢肯定有一个很好的答案，我只是不知道它是什么......
我一直在寻找指导方针，并在MSDN中找到了这个：
在全局和本地资源文件之间进行选择
您可以在 Web 应用程序中使用全局和本地资源文件的任意组合。通常，当您希望在页面之间共享资源时，您将资源添加到全局资源文件中。当您想以编程方式访问文件时，全局资源文件中的资源也是强类型的。
但是，如果您在其中存储所有本地化资源，全局资源文件可能会变得很大。如果多个开发人员在不同的页面上工作但在一个资源文件中，则全局资源文件也可能更难管理。
本地资源文件使管理单个 ASP.NET 网页的资源变得更加容易。但是您不能在页面之间共享资源。此外，如果您有许多必须本地化为多种语言的页面，您可能会创建许多本地资源文件。如果站点很大，包含许多文件夹和语言，本地资源可以快速扩展应用程序域中的程序集数量。
当您更改本地或全局默认资源文件时，ASP.NET 会重新编译资源并重新启动 ASP.NET 应用程序。这可能会影响您网站的整体性能。如果添加附属资源文件，它不会导致重新编译资源，但 ASP.NET 应用程序将重新启动。
因此，似乎真的要由编程团队来权衡每种方法的优缺点，然后选择对他们有利的方法。
Joe90 - 我不得不说，根据我的经验，我不能同意管理分散在整个项目中的大量本地资源文件比管理一个全局资源文件更容易。没有什么可以阻止一次又一次地重复相同的翻译，而且它们很难追踪。访问全局资源文件非常容易在团队内进行协调，多个用户可以一眼看出他们所需的翻译是否已经完成。
我从与 Lea 完全相同的策略开始 - 即从本地资源文件开始，然后将其移动到全局资源文件，如果它被多次引用。这很快就变成了管理的麻烦，我现在每次都使用全局资源文件。
微软似乎没有关于最佳实践是什么，甚至这两种方法是如何实现的明确指导方针，因此我们可以冒险猜测！
我猜比较/回报是本地资源文件只需要重新编译它们相关的文件，而更改全局资源文件似乎需要重新编译整个网站 - 会话状态等的固有损失。因此需要在更新期间使站点脱机以确保安全。
我的开发团队至少有 10 名开发人员开发一个产品，我们为每个站点使用一个全局 resx。
在我看来，合并这个大 resx 文件的问题应该不是问题。
如果您有 10 个开发人员自己在网站上设置语言，您如何在网站上获得统一的表达方式？开发人员往往擅长代码而不是语法表达。（我自己就是一名开发人员。）
语言专家应该编辑 resx 文件并为开发人员锁定它！
全球资源文件是最好的翻译方法。关键是使用命名约定，例如字符串名称的前几个字母的页面名称缩写，以便您可以轻松地在每个网页的基础上找到资源。试图在多个页面中重复使用许多短语会给翻译者带来更多的困惑。
您可以根据需要定义可重复使用的短语，例如 Yes、No、BTN_OK、BTN_Cancel、QTN_AreYouSure 等，方法是使用缺少页面命名约定（前几个字母没有页面名称缩写）。您的大部分 RESX 行将特定于每个页面，您不应专注于尝试尽可能多地重用。在需要时使用文本查找/替换可以在几分钟内小心地更改整个文件中的一个短语。