资源文件似乎非常适合本地化标签和消息，但它们是否完美？
例如：
- 如果有大量资源（例如100,000个字符串在.resx文件中），是否有更好的解决方案？（从理论上讲，我实际上没有这个问题）
- 对于存储其他类型的数据（例如图像、图标、音频文件、常规文件等），这是一个好的方法吗？
- 将.resx文件存储在独立项目中以便更轻松地进行更新/编译，这是最佳实践吗？
- 在使用.resx文件时，是否遇到过其他任何问题？
资源(.resx)文件存在性能问题或需要注意的地方吗？
15
- John B
2
目前还没有，但我将要开展一个项目，该项目将依赖资源文件来本地化其标签和消息。只是想确保没有任何重大注意事项或更好的替代方案。 - John B
如果我有成千上万的字符串，我会使用数据库来存储这些信息。在我达到数千甚至数十万时，我很可能已经在使用数据库了。 - Chris Marisic
9个回答
6
1. 如果有大量资源，例如.resx文件中的100,000个字符串，是否有更好的解决方案？（理论上，我实际上没有这个问题）
我在Java项目中使用Alfresco作为替代内容库。由于编码问题，从维护的角度来看，RESX文件可能会非常麻烦。
2. 这是存储其他类型数据（如图像、图标、音频文件、常规文件等）的好方法吗？
我见过它可以用于图像...但仅限于此。 （不确定其他媒体/文件）
3. 将.resx文件存储在独立的项目中以便更轻松地更新/编译是否是最佳实践？
我不这样做，但是您可以在现场编辑resx文件，然后我认为编辑将通过。 当然，在开发中也是这样工作的（除全局resx外，我想）
4. 在使用.resx文件时，您遇到的其他问题有哪些？
除了维护起来非常恼人以及Visual Studio没有提供最整洁的工具来处理它们之外...没有。
- Scott Schulthess
1
如果您想要对其进行控制，请安装免费的Microsoft MAT（Visual Studio多语言应用程序工具包）扩展插件;-) - juFo
5
我最近使用了一个具有500万个字符串（像这个句子一样普通长度）的.resx文件，编译在不同的DLL中，大约大小为1GB。它仍然可以在Azure Web项目中正常运行。
加载时间未知，可能是几秒钟左右，因为它总是可以分阶段预热，我从未注意到它。
- Eric Yin
2
感谢您的反馈。听到成功故事总是很好的。 - John B
我不建议这样做，这是一个愚蠢的解决方案，部署时间很长。我猜最终他们会将其移动到Azure表存储中。但它可以批准大的资源文件工作。 - Eric Yin
3
我曾经遇到过两个与资源文件相关的问题，都是关于翻译人员的性能，而不是字符串查找的速度。
在海外办事处做翻译的销售人员无法编辑XML或学习任何新工具，因此他们只使用Excel来编辑翻译。因此，我们可以将翻译后的字符串存储为CVS文件，从而避免将翻译后的字符串复制到资源文件中。
每次更改翻译后的字符串都需要进行新的构建才能看到效果。
如果将翻译后的字符串存储为CSV文件，则可以将它们缓存在ASP.NET缓存中。然后，对翻译的任何更改都会在下一次页面加载时显示出来。
因此，我们可以使用资源提供程序的自定义实现，并保持标准的ASP.NET资源查找系统。如果标准资源查找系统在您的情况下没有帮助，那么就可以忽略它-这取决于您的页面是如何编写的。
如果您希望能够覆盖单个客户的字符串，那么您需要一个多级查找系统。否则，您必须每次发布新版本系统时将客户的自定义字符串与翻译后的字符串合并。
在海外办事处做翻译的销售人员无法编辑XML或学习任何新工具，因此他们只使用Excel来编辑翻译。因此，我们可以将翻译后的字符串存储为CVS文件，从而避免将翻译后的字符串复制到资源文件中。
每次更改翻译后的字符串都需要进行新的构建才能看到效果。
如果将翻译后的字符串存储为CSV文件，则可以将它们缓存在ASP.NET缓存中。然后，对翻译的任何更改都会在下一次页面加载时显示出来。
因此，我们可以使用资源提供程序的自定义实现，并保持标准的ASP.NET资源查找系统。如果标准资源查找系统在您的情况下没有帮助，那么就可以忽略它-这取决于您的页面是如何编写的。
如果您希望能够覆盖单个客户的字符串，那么您需要一个多级查找系统。否则，您必须每次发布新版本系统时将客户的自定义字符串与翻译后的字符串合并。
- Ian Ringrose
4
@SkippyFire，“外部.resx编辑器工具”的问题在于翻译人员必须学会如何使用它。 - Ian Ringrose
1兄弟，resgen工具可以将resx转换为键=值文本文件，这对翻译人员来说非常简单。然后，您可以使用resgen将键=值文件转换回xml resx文件。 - Andrew Arnott
有一个简单的免费工具，我记不得名字了，它以类似电子表格的方式打开resx文件。真的没有什么需要学习的。 - Pete
@Pete，但是这个工具必须被安装，而且在我的经验中，翻译通常是由当地销售办公室的“销售人员”完成的。他们不擅长学习如何使用新软件，无论它有多容易使用。 - Ian Ringrose
3
我们在一个相对较大的.NET Windows Forms应用程序中使用资源文件（超过500个不同的表单，每个表单大约20个资源字符串），并且我们在.resx文件中使用资源时没有性能问题。
我们使用Babylon.NET作为管理翻译的工具（有一个专门针对翻译人员的免费版本）。
您没有说明您的项目是Web还是桌面应用程序。资源文件为桌面应用程序提供的一个功能是能够本地化控件位置和大小，这在其他工具中（除非您使用类似DevExpress布局控件的自动调整大小）是不可能的。
- dcarapic
3
我从未遇到过与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
你甚至可以看到项目中已经完成了多少工作：
另外，它还配备了一个方便的编辑器，您的翻译人员也可以使用！
开始操作：
- 安装MAT Visual Studio扩展
- 在Visual Studio中打开您的项目
- 单击属性 --> 打开AssemblyInfo.cs
- 添加此属性：[assembly: System.Resources.NeutralResourcesLanguage("en")]
- 在解决方案资源管理器中选择您的项目，然后在Visual Studio中转到[工具] --> [多语言应用程序工具包] --> [启用选择]
- 这将向您的项目添加一个名为“MultilingualResources”的新文件夹
- 右键单击您的项目 --> [多语言应用程序工具包] --> [添加翻译语言…] --> 选择您要翻译的语言（例如荷兰语）。
- 在“MultilingualResources”文件夹中，您将看到一个名为“....nl.xlf”的新文件，请双击它，它将使用多语言编辑器打开。（如果没有，请右键单击并将默认的“打开方式”更改为多语言编辑器）
现在你只需要将字符串添加到默认的Resources.resx文件中（语言应与AssemblyInfo.cs中添加的“NeutralResourcesLanguage”相同）。 对于翻译，您不需要将字符串添加到...nl.resx文件中，而是使用位于MultiLingualResources文件夹中的.xlf文件进行工作。
（在完成大量翻译后，可能需要重新构建，以便已翻译的.xlf文件更新已翻译的.resx文件）
获取位置：
- juFo
1
关于第四点。
我一直在使用.resx文件来存储我们网站上需要本地化到多种语言的所有字符串，并且没有遇到任何重大问题。
你需要考虑的一件事是，如果你想让这些文本可以被搜索到。对于我所工作的一些网站，有一些需要进行本地化的资源需要被搜索，因此我必须将它们保留在数据库中。然而，当我有选择时，出于类似上述原因，我更喜欢使用.resx文件。
- Matthew Manela
1
我想强调的是，你应该寻找自定义实现（或自己实现）资源提供程序（类似成员资格提供程序的提供程序模型），将你的资源存储在数据库中。这就是我们为我们的CMS所做的，非常有用。
当我们最初寻找示例时，我们发现了Creating a Data Driven ASP.NET Localization Resource Provider and Editor。
当我们最初寻找示例时，我们发现了Creating a Data Driven ASP.NET Localization Resource Provider and Editor。
- W3Max
2
1为什么要将这些不变的资源存储在数据库中？这似乎很快就会遇到可扩展性问题。 - UpTheCreek
@Sosh，谁说资源是“不变的”？相反，资源就像任何其他内容一样，不断变化，您可能希望使用基于Web的界面来管理它们，以便非技术人员也能够这样做。而关于可扩展性的问题可以通过多种方式处理...我不知道在数据库中存储数据必然意味着可扩展性问题... - W3Max
0
以下是我对资源文件的看法：
如果有大量字符串需要处理，我会认为使用数据库可能是最好的方法，以便搜索和排序数据。在资源表中考虑多种语言可能不太困难，而且速度应该很快。
我认为这是存储静态资源或可能由客户端更改的内容的良好方法。至于动态资源，最好使用数据库，单独使用或与文件系统结合使用。我认为在新的SQL Server中，有一种新类型是使用数据库和文件系统的最佳混合。
我在另一个问题中读到（不知道是哪个问题），在外部项目中使用资源文件是一个好习惯，因为当资源发生变化时，您不必重新编译整个项目。只需重新编译资源项目即可。这也允许客户进行（相当）容易的编辑，他们只需要“源代码”资源项目，而不是您的其他真实代码（API代码等）。
我没有使用过资源文件，无法对它们的可靠性、可扩展性或可能在使用它们时遇到的任何潜在问题做出任何声明。
- John B
0
在放弃使用自定义正则表达式语言替换字符串的代理服务器后，我在 .net razor 页面应用程序中使用资源文件。
我们放弃了代理方法，因为它更适合大型字符串（段落），对于所有动态片段和其他内容，它非常棘手。
到目前为止，我没有遇到任何问题，而且速度比代理服务器快。我将所有目标页面、注释、名称、英文和所有其他可用语言存储在数据库中...添加新语言的新列非常简单。
到目前为止，我们在多个 resx 文件中有约 5k 条条目。
然后，我使用构建器进程创建所有的 resx 文件，并在更新时将它们放置在正确的本地和全局文件夹中。
为翻译人员构建一个简单的界面来搜索页面、语言、注释、名称等并进行更新非常容易。我们选择不在更改时自动重建 resx 文件，但如果您信任您的翻译人员，您可以这样做 ;)
我们还允许翻译人员添加要翻译的新片段/文本，但迄今为止，我们还没有想出如何自动包含它们，并且必须手动替换源文件中的字符串并重新编译。
对于编辑 resx 文件，我使用了 zeta。
https://www.zeta-resource-editor.com/index.html
这个工具可以一次性打开所有语言文件，并且突出显示占位符的差异和缺失的翻译。您可以在同一行上编辑所有语言，并一次性保存所有文件。虽然我们现在不再使用它，因为所有内容都在数据库中，但我们仍然推荐使用。
- Rolf Herbert
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接