资源文件似乎非常适合标签和消息的本地化，但它们是否完美？
例如：
【问题讨论】：
标签： c# asp.net resources resx resource-files
在转储之前使用自定义正则表达式语言替换通过代理的字符串的代理服务器后，我一直在 .net razor 页面应用程序中使用资源文件。
我们放弃了代理方法，因为它更适合处理大字符串（段落），并且对于我们拥有的所有动态片段和内容来说非常尴尬。
完全没有问题，到目前为止它比代理服务器快。我将所有目标页面、cmets、名称、en 和所有其他可用语言存储在一个 DB 中..为一种新语言添加一个新列。
到目前为止，我们在多个 resx 文件中有大约 5k 个条目
然后，我使用构建器进程创建所有 resx 文件，并在任何更新时将它们放置在正确的本地和全局文件夹中。
为翻译人员构建一个简单的界面非常容易，可以搜索页面、语言、cmets、名称等并进行更新。我们选择不在更改时自动重建 resx 文件，但如果您信任您的翻译人员，您可以这样做；)
我们还允许翻译人员添加新的片段/文本进行翻译，但目前我们还没有任何关于如何自动包含它们的好主意，并且必须手动替换源文件中的字符串并重新编译。
为了编辑 resx 文件，我使用了 zeta，
https://www.zeta-resource-editor.com/index.html
它可以一次性打开您的所有语言，并突出显示占位符的差异以及缺少的翻译。您可以在一行中编辑所有语言并一次性保存所有文件。我们现在不使用它，因为一切都在数据库中，但推荐它。
【讨论】：
我在资源文件方面遇到了两个问题，都是关于翻译人员（人）的性能，而不是字符串查找的速度。
监督办公室的销售人员 翻译人员无法做到这一点 应对编辑 XML 或学习任何 新工具。
所以他们只是使用 Excel 来编辑翻译。因此，我们不妨将翻译后的字符串存储为 CVS 文件，这样就不必将翻译后的字符串复制到资源文件中。
需要进行新的构建，以便 查看任何翻译的效果。
如果翻译后的字符串存储为 CSV 文件，我们可以将它们缓存在 ASP.NET 缓存中。然后，对翻译的任何更改都会在下一页加载时显示。
所以我们可以使用资源提供程序的自定义实现并保持标准的 ASP.NET 资源查找系统。或者，如果它对您的情况没有帮助，则忽略标准资源查找系统——这取决于您的页面是如何编写的。
您可能会在某些时候发现您希望能够覆盖单个客户的字符串，如果是这样，您将需要一个多阶段查找系统。否则，每次发布新版本的系统时，您都必须将客户的自定义字符串与翻译后的字符串合并。
【讨论】：
从未见过 resx 资源有任何问题，它们被完美地缓存了。我们已经在 WinForms、asp.net mvc、wpf 等中使用过它们......
您应该做的一件事是使用 Visual Studio 的 Microsoft MAT（多语言应用工具包）扩展。
您可以控制您的翻译，将其导出以发送给翻译人员（例如，不是锁定的翻译），再次导入它们并验证它们或对其发表评论，回收现有的翻译（为您节省大量时间！）
它适用于行业标准的 xlf 格式！
如果您使用 Azure api 注册，您甚至可以自动翻译资源（您在 azure 上有几千字的免费每月信用额度）。 见：https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/1167898-microsoft-translator-moves-to-the-azure-portal
您甚至可以看到一个项目已经完成了多少工作：
哦，它带有一个方便的编辑器，您的翻译人员也可以使用它！
开始：
现在您只需将字符串添加到默认 Resources.resx 文件（语言应与您在 AssemblyInfo.cs 中添加的“NeutralResourcesLanguage”相同。 对于您不向 ...nl.resx 文件添加字符串的翻译，您使用位于 MultiLingualResources 文件夹中的 .xlf 文件。
（在您完成大量翻译后，可能需要重新构建，以便翻译后的 .xlf 文件更新翻译后的 .resx 文件）
在哪里获得它：
【讨论】：
1. 如果资源量很大，有没有更好的解决方案？就像 .resx 文件中的 100,000 个字符串一样？ （理论上我其实没有这个问题）
我使用 Alfresco 作为 Java 项目的替代内容存储库。从维护的角度来看，RESX 文件（我猜是因为编码问题）真的很臭。
2. 这是存储其他类型数据（例如图像、图标、音频文件、常规文件等）的好方法吗？
我已经看到它适用于图像......但就是这样。 （不确定其他媒体/文件）
3. 将 .resx 文件存储在独立项目中以便于更新/编译是否是最佳做法？
我没有，但我相信您可以在实时站点上编辑 resx 文件，然后编辑将通过。当然，这就是它在开发中的工作方式（我认为除了全局 resx）
4. 您在使用 .resx 文件时是否遇到过其他问题？
除了维护起来真的很烦人，而且 Visual Studio 没有提供最简洁的工具来处理它们......不。
【讨论】：
我最近使用了一个包含 500 万个字符串（正常长度，如这句话）的 .resx 文件，在不同的 DLLS 中编译，大小约为 1 GB。它在 Azure Web 项目中仍然可以正常工作。
加载时间未知，可能几秒左右，因为它总是可以分阶段升温，我没注意到。
【讨论】：
我将简单地补充一点，您应该寻找资源提供者（提供者模型，如会员提供者）的自定义实现（或您是否拥有），以将您的资源存储在数据库中。这就是我们为 CMS 所做的，它非常有用。
当我们第一次寻找示例时，我们发现 Creating a Data Driven ASP.NET Localization Resource Provider and Editor。
【讨论】：
这是我对资源文件的看法：
我假设如果存在大量字符串，那么使用数据库可能是允许对数据进行搜索和排序的最佳方法。在一个资源表中考虑多种语言可能不会太难，而且速度最好快。
我认为这是存储静态资源或可能由客户端更改的内容的好方法。至于动态资源，最好单独使用数据库，或者与文件系统结合使用。我认为在新的 SQL Server 中有一种新类型，它是使用数据库和文件系统的最佳混合体。
我在另一个问题（不知道是哪个问题）中读到，在外部项目中使用资源文件是一种很好的做法，因为当资源发生变化时，您不必重新编译整个项目。只需重新编译资源项目。这也将允许客户（相当）轻松地进行编辑，他们只需要资源项目的“源代码”，而不是您的其他真实代码（API 代码等）。
我没有充分使用资源文件来对它们的可靠性、可扩展性或您在使用它们时可能遇到的任何潜在问题提出任何声明。
【讨论】：
我们一直在一个相对较大的 .NET Windows 窗体应用程序（超过 500 个不同的窗体，每个窗体大约 20 个资源字符串）上使用资源文件，并且我们没有遇到来自 .resx 文件的资源的性能问题。 我们使用 Babylon.NET 作为管理翻译的工具（有专供翻译人员使用的免费版本）。 您没有指定您的项目是 Web 应用程序还是桌面应用程序。资源文件为桌面应用程序提供的一项功能是还可以本地化控件位置和大小，恕我直言，这是使用其他工具无法实现的（除非您使用的是具有自动调整大小的 DevExpress 布局控件之类的东西）。
【讨论】：
对于第 4 点。
我一直在为我们网站上的所有字符串使用 .resx 文件，这些字符串必须本地化为多种语言，并且没有任何重大问题。
您需要考虑的一件事是您是否希望此文本可搜索。对于我工作的一些网站，有一些本地化资源需要可搜索，因此我必须将它们保存在数据库中。但是，当我有选择时，出于上述类似原因，我更喜欢 .resx 文件。
【讨论】：