资源（.resx）文件是否存在任何性能问题或警告？

Question

资源文件似乎非常适合标签和消息的本地化，但它们是否完美？

例如：

1. 如果有大量资源，是否有更好的解决方案？像.resx文件中的100,000个字符串一样？ （理论上，我实际上没有这个问题）
2. 这是存储其他类型数据的好方法，例如图像，图标，音频文件，常规文件等吗？
3. 将.resx文件存储在独立项目中以便于更新/编译是最佳做法吗？
4. 使用.resx文件时是否还有其他问题？

Answer 1

  

1.如果有大量资源，是否有更好的解决方案？像.resx文件中的100,000个字符串一样？ （理论上，我实际上没有这个问题）

我使用Alfresco作为Java项目的替代内容存储库。 RESX文件，从维护的角度来看（因为编码问题，我猜）可能真的很臭。

  

2.这是存储其他类型数据的好方法，例如图像，图标，音频文件，常规文件等吗？

我看到它与图像一起工作......但就是这样。 （不确定与其他媒体/文件）

  

3.将.resx文件存储在独立项目中以便于更新/编译是最佳做法吗？

我没有，但您可以在实际网站上编辑resx文件，然后编辑将完成，我相信。当然，这是它在开发中的工作方式（我认为除了全球resx）

  

4.使用.resx文件时是否还有其他问题？

除了非常讨厌维护之外，以及visual studio不提供与他们合作的最佳工具......没有。

Answer 2

我最近使用了一个包含500万字符串（正常长度，就像这句话）的.resx文件，在不同的DLLS中编译，大小约为1 GB。它仍然可以在Azure Web项目中正常工作。

加载时间未知，可能只有几秒左右，因为它总是可以分阶段加热，我从来没有注意到它。

Answer 3

我们一直在相对较大的.NET Windows Forms应用程序上使用资源文件（超过500种不同的表单，每个表单大约20个资源字符串），我们对.resx文件中的资源没有性能问题。 我们使用Babylon.NET作为管理翻译的工具（仅为翻译人员提供免费版本）。 您没有指定您的项目是Web应用程序还是桌面应用程序。资源文件为桌面应用程序提供的一个功能是能够使用其他工具本地化控制位置和大小，这是不可能的（除非您使用具有自动调整大小的DevExpress布局控件）。

Answer 4

我遇到了资源文件的两个问题，包括翻译器（人）的性能，而不是字符串查找的速度。

  

监督办公室的销售人员   翻译人员做不到的   应对编辑XML或学习任何   新工具。

所以他们只是使用Excel来编辑翻译。因此，我们可能已将已翻译的字符串存储为CVS文件，因此无需将已翻译的字符串复制到资源文件中。

  

需要进行新的构建   需要任何翻译的效果。

如果翻译的字符串存储为CSV文件，我们可以将它们缓存在ASP.NET缓存中。然后，对翻译的任何更改都会显示在下一页加载中。

---

因此，我们可以使用资源提供程序的自定义实现并保持标准的ASP.NET资源查找系统。或者只是忽略标准资源查找系统，如果它对您的情况没有帮助 - 这取决于您的页面的编写方式。

---

您可能会在某些时候发现您希望能够覆盖单个客户的字符串，如果是这样，您将需要一个多阶段查找系统。否则，每次发布新版本的系统时，都必须将客户的自定义字符串与已翻译的字符串合并。

Answer 5

第4点。
我一直在为我们网站上的所有字符串使用.resx文件，这些字符串必须本地化为多种语言，并且没有任何重大问题。

您需要考虑的一件事是，您是否希望此文本可搜索。对于我工作的一些站点，有一些需要搜索的本地化资源，所以我必须将它们保存在数据库中。但是，当我选择时，我更喜欢.resx文件，原因与上述类似。

Answer 6

我将简单地补充一点，您应该寻找资源提供者（提供者模型，如成员资​​格提供者）的自定义实现（或您拥有），以将您的资源存储在数据库中。这就是我们为CMS做的，它非常有用。

当我们第一次查找示例时，我们发现 Creating a Data Driven ASP.NET Localization Resource Provider and Editor 。

Answer 7

以下是我对资源文件的看法：

1. 我认为如果有大量的字符串，那么使用数据库可能是允许搜索和排序数据的最佳方法。在资源表中考虑多种语言可能不会太困难，速度应该最快。

2. 我认为这是存储静态资源的好方法，也可能是客户端可能更改的内容。对于动态资源，单独使用数据库或与文件系统结合使用可能更好。我认为在新的SQL Server中有一种新类型，它是使用数据库和文件系统的最佳组合。

3. 我在另一个问题中读到（不知道是哪个）在外部项目中使用资源文件是一种很好的做法，因为在资源发生变化时你不必重新编译整个项目。只需重新编译资源项目。这也允许客户进行（相当）简单的编辑，他们只需要为资源项目“源代码”，而不需要你的其他真实代码（API代码等）。

   < / LI>

4. 我没有充分利用资源文件来声明其可靠性，可扩展性或使用它们时可能遇到的任何潜在问题。

Answer 8

从未发现resx资源有任何问题，它们已被完美地缓存。我们已经在WinForms，asp.net mvc，wpf等中使用了它们。

您应该做的一件事是使用Visual Studio的Microsoft MAT（多语言应用工具包）扩展。

您可以控制翻译，将其导出以发送给翻译人员（例如，未锁定的翻译），再次导入它们并对其进行验证或评论，回收现有翻译（为您节省很多时间！）

，它与行业标准xlf格式兼容！

如果您使用Azure api进行注册，您甚至可以自动翻译资源（您有几千个单词，天蓝色每月免费赠送）。 请参阅：https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/1167898-microsoft-translator-moves-to-the-azure-portal

您甚至可以查看项目中已经完成了多少工作：

哦，它带有一个方便的编辑器，您的翻译也可以使用！

开始使用：

1. 安装MAT Visual Studio扩展
2. 转到您在Visual Studio中的项目
3. 单击属性->打开AssemblyInfo.cs
4. 添加此属性：[assembly：System.Resources.NeutralResourcesLanguage（“ en”）]
5. 在解决方案资源管理器中选择项目，然后在Visual Studio中选择[工具]-> [多语言应用工具包]-> [启用选择]
6. 这将为您的项目添加一个新文件夹“ MultilingualResources”
7. 右键单击您的项目-> [多语言应用工具包]-> [添加翻译语言...]->选择要翻译的语言（例如荷兰语）。
8. 在“ MultilingualResources”文件夹中，您将看到一个新文件“ .... nl.xlf”，双击它，它将用“多语言编辑器”打开。 （如果不是右键单击鼠标，然后将默认的“打开方式”更改为多语言编辑器）

现在，您只需将字符串添加到默认的Resources.resx文件中（该语言应与在AssemblyInfo.cs中添加的“ NeutralResourcesLanguage”相同）。 对于不要将翻译添加字符串到... nl.resx文件的翻译，您可以使用MultiLingualResources文件夹中的.xlf文件。

（完成大量翻译后，可能需要重新构建，以便翻译的.xlf文件更新翻译的.resx文件）

在哪里获得它：

• 反馈：https://multilingualapptoolkit.uservoice.com/
• Visual Studio扩展：https://marketplace.visualstudio.com/items?itemName=MultilingualAppToolkit.MultilingualAppToolkit-18308
• 知识库：https://multilingualapptoolkit.uservoice.com/knowledgebase
管理该项目的Cameron（Microsoft）的
• github：https://github.com/TheMATDude