除了维护起来非常烦人，而且 Visual Studio 没有提供最简洁的工具来使用它们......不。
1. Is there a better solution if there is a huge amount of resources? Like 100,000 strings in a .resx file? (Theoretically, I do not actually have this problem)
I've used Alfresco as an alternative content repository on Java projects. RESX files, from a maintaince standpoint (because of encoding issues I guess) can really stink.
2. Is this a good method for storing the other types of data, such as images, icons, audio files, regular files, etc.?
I've seen it work with images...but that's it. (not sure with other media/files)
3. Is it a best practice to store your .resx files in a stand-alone project for easier updates/compiling?
I don't, but you can edit a resx file on a live site and then edit will go through, I believe. Certainly that's the way it works in development (except for the global resx, I think)
4. Are there any other issues that you have run into when using .resx files?
Besides being really annoying to maintain, and the fact that visual studio doesn't provide the neatest tools for working with them...no.
I recently used a .resx file with 5 million strings (normal length, like this sentence), compiled in different DLLS about 1 GB in size. It still works fine in an Azure web project.
The load time is unknown, maybe few seconds or so, since it always can heat up in stages, I never noticed it.
We have been using resource files on a relatively large .NET Windows Forms application (over 500 various forms, approximately 20 resource strings per form) and we've had no performance issues regarding resources from .resx files. We have used Babylon.NET as a tool for managing translations (has a free version just for translators). You did not specify if your project will be web or desktop application. One functionality that resource files offers for desktop applications is the ability to also localize control positions and size which IMHO is not possible using other tools (unless you are using something like DevExpress layout control which has automatic sizing).
Never seen any problems with resx resources, they are being cached perfectly. We have used them in WinForms, asp.net mvc, wpf, etc...
One thing you should do is use the Microsoft MAT (Multilingual App Toolkit) extension for Visual Studio.
You can control your translations, export them to send to translators (e.g. not the locked translations), import them again and verify them or comment on it, recycle existing translations (saving you a lot of time!)
and it works with the industry standard xlf format!
you can even see how much work already has been done in a project:
Oh and it comes with a handy editor which your translators can also use!
To get started:
install the MAT Visual Studio extension
Go to your project in Visual Studio
Click Properties --> open AssemblyInfo.cs
Add this attribute: [assembly: System.Resources.NeutralResourcesLanguage("en")]
Select your project in Solution Explorer and to in Visual Studio to [Tools] --> [Multilingual App Toolkit] --> [Enable selection]
This will add a new folder "MultilingualResources" to your project
Right mouse click your project --> [Multilingual App Toolkit] --> [Add translation languages…] --> select the language you want to translate (e.g. Dutch).
In the "MultilingualResources" folder you will see a new file "....nl.xlf", double click it, it will open with the Multilingual Editor. (if not right mouse click and change the default "Open With" to the multilingual editor)
Now you only add strings to your default Resources.resx file (the language should be same as the "NeutralResourcesLanguage" you added in AssemblyInfo.cs. For the translations you DONT add strings to the ...nl.resx files, you work with the .xlf files, located in the MultiLingualResources folder.
(after you have done lots of translations, a rebuild might be needed so that the translated .xlf files update the translated .resx files)
I have had two problems with resource files, both about performance of the translators (people), rather than the speed of string lookup.
The sales staff at the oversee office that did the translators could not cope with editing XML or learning any new tool.
So they just used Excel to edit the translations. Therefore, we might as well have stored the translated strings as a CVS file, so avoiding having to copy the translated strings into the resource files.
A new build needs to be done so as to see the effect of any translations.
Once again if the translated strings were stored as a CSV file, we could have cached them in the ASP.NET cache. Then any changes to the translations would show up on the next page load.
So we could have used a custom implementation of the resource provider and keep to the standard ASP.NET resource lookup system. Or just ignore the standard resource lookup system if it does not help in your case – it depends on how your pages are written.
You may find at some point that you wish to be able to override strings for a single customer, if so you will need a multi-stage lookup system. Otherwise, you have to merge the customer’s custom strings with the translated string each time you ship a new version of the system.
For point#4. I have been using .resx files for all strings on our site that must be localized into many languages and haven't had any major issues with them.
The one thing that you need to think about is if you want this text to be searchable. For some of the sites I work on there are some localized resources that need to be searchable so I must keep them in the database. However, when I have the choice I prefer the .resx file for similar reasons mentioned above.
I will simply add that you should look for custom implementations (or do you own) of the resource provider (provider model like the membership provider) to store your resources in a database. That's what we did for our CMS, and it's very useful.
I would assume that if there is a LARGE amount of string, that using a database might be the best method to allow for searching and sorting of the data. It would probably not be too difficult to account for multiple languages in a resource table, and the speed should best fast.
I would think that this is a good method for storing static resources, or things that might be changed by a client. As for dynamic resources, it might be better to use a database, either alone, or in conjunction with the file system. I think in the new SQL Server there is a new type that is an optimal hybrid of using a database and the file system.
I read in another question (don't know which) that using resource files in an external project is a good practice, because you wouldn't have to recompile an entire project when resources change. Just recompile the resource project. This would also allow for (fairly) easy edits to be made by clients, where they would only need to "source code" for the resource project, and not your other real code (API code, etc.).
I have not used resource files enough to make any claims about their reliability, extensibility, or any potential issues that you might have when working with them.
I've been using resource files in a .net razor page app after dumping our previous proxy server that used a custom regular expression language to replace strings as they passed through the proxy.
We dumped the proxy method as it was more suited to large strings (paragraphs) and pretty awkward for all the dynamic fragments and stuff we had.
Had no problem at all and it's faster so far than the proxy server. I store all the target pages, comments, names, en and all other available languages in a DB..trivial to add a new column for a new language.
We have about 5k entries in multiple resx files so far
I then use a builder process to create all the resx files and place them in the correct local and global folders any time something is updated.
Dead easy to build a simple interface for translators to search for pages, languages, comments, names etc and update. We choose not to auto rebuild the resx files on a change but you could if you trust your translators ;)
We also allow translators to add new fragments/text to translate but as yet we've not had any bright ideas on how to include them automatically and have to manually substitute the string in the source file and recompile.
Which can open all your languages in one go and highlights differences in placeholders and also missing translations. You can edit all the languages on one row and save all the files in one go. We don't use it now as everything is in the DB but recommend it.
发布评论
评论（9）
我使用 Alfresco 作为 Java 项目的替代内容存储库。 从维护的角度来看，RESX 文件（我猜是因为编码问题）确实很糟糕。
我见过它与图像一起工作......但仅此而已。 （不确定其他媒体/文件）
我不知道，但我相信您可以在实时网站上编辑 resx 文件，然后编辑就会完成。 当然，这就是它在开发中的工作方式（我认为除了全局 resx 之外）
除了维护起来非常烦人，而且 Visual Studio 没有提供最简洁的工具来使用它们......不。
I've used Alfresco as an alternative content repository on Java projects. RESX files, from a maintaince standpoint (because of encoding issues I guess) can really stink.
I've seen it work with images...but that's it. (not sure with other media/files)
I don't, but you can edit a resx file on a live site and then edit will go through, I believe. Certainly that's the way it works in development (except for the global resx, I think)
Besides being really annoying to maintain, and the fact that visual studio doesn't provide the neatest tools for working with them...no.
我最近使用了一个包含 500 万个字符串（正常长度，就像这句话）的 .resx 文件，在不同的 DLL 中编译，大小约为 1 GB。 它在 Azure Web 项目中仍然运行良好。
加载时间未知，可能几秒钟左右，因为它总是可以阶段性升温，我从来没有注意到它。
I recently used a .resx file with 5 million strings (normal length, like this sentence), compiled in different DLLS about 1 GB in size. It still works fine in an Azure web project.
The load time is unknown, maybe few seconds or so, since it always can heat up in stages, I never noticed it.
我们一直在一个相对较大的 .NET Windows 窗体应用程序（超过 500 个各种窗体，每个窗体大约 20 个资源字符串）上使用资源文件，并且我们没有遇到有关 .resx 文件中的资源的性能问题。
我们使用 Babylon.NET 作为管理翻译的工具（有一个仅供翻译人员使用的免费版本）。
您没有指定您的项目是网络应用程序还是桌面应用程序。 资源文件为桌面应用程序提供的一项功能是能够本地化控件位置和大小，恕我直言，使用其他工具无法实现这一点（除非您使用的是具有自动调整大小功能的 DevExpress 布局控件）。
We have been using resource files on a relatively large .NET Windows Forms application (over 500 various forms, approximately 20 resource strings per form) and we've had no performance issues regarding resources from .resx files.
We have used Babylon.NET as a tool for managing translations (has a free version just for translators).
You did not specify if your project will be web or desktop application. One functionality that resource files offers for desktop applications is the ability to also localize control positions and size which IMHO is not possible using other tools (unless you are using something like DevExpress layout control which has automatic sizing).
从未见过 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 文件（语言应与您的“NeutralResourcesLanguage”相同）添加到 AssemblyInfo.cs 中。
对于不向 ...nl.resx 文件添加字符串的翻译，您可以使用位于 MultiLingualResources 文件夹中的 .xlf 文件。
（完成大量翻译后，可能需要重新构建，以便翻译后的 .xlf 文件更新翻译后的 .resx 文件）
获取位置：
Never seen any problems with resx resources, they are being cached perfectly. We have used them in WinForms, asp.net mvc, wpf, etc...
One thing you should do is use the Microsoft MAT (Multilingual App Toolkit) extension for Visual Studio.
You can control your translations, export them to send to translators (e.g. not the locked translations), import them again and verify them or comment on it, recycle existing translations (saving you a lot of time!)
and it works with the industry standard xlf format!
If you sign up with the Azure api you can even automatically translate resources (you have a few thousand words free of monthly credit on azure).
See: https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/1167898-microsoft-translator-moves-to-the-azure-portal
you can even see how much work already has been done in a project:
Oh and it comes with a handy editor which your translators can also use!
To get started:
Now you only add strings to your default Resources.resx file (the language should be same as the "NeutralResourcesLanguage" you added in AssemblyInfo.cs.
For the translations you DONT add strings to the ...nl.resx files, you work with the .xlf files, located in the MultiLingualResources folder.
(after you have done lots of translations, a rebuild might be needed so that the translated .xlf files update the translated .resx files)
Where to get it:
我在资源文件方面遇到了两个问题，都与翻译（人）的性能有关，而不是与字符串查找的速度有关。
所以他们只是使用 Excel 来编辑翻译。 因此，我们不妨将翻译后的字符串存储为 CVS 文件，从而避免将翻译后的字符串复制到资源文件中。
同样，如果翻译后的字符串存储为 CSV 文件，我们就可以将它们缓存在 ASP.NET 缓存中。 然后，对翻译的任何更改都会显示在下一页加载时。
因此，我们可以使用资源提供程序的自定义实现并保留标准 ASP.NET 资源查找系统。 或者如果标准资源查找系统对您的情况没有帮助，则忽略它 – 这取决于您的页面的编写方式。
您可能会发现在某些时候您希望能够覆盖单个客户的字符串，如果是这样，您将需要一个多级查找系统。 否则，每次发布新版本的系统时，您都必须将客户的自定义字符串与翻译后的字符串合并。
I have had two problems with resource files, both about performance of the translators (people), rather than the speed of string lookup.
So they just used Excel to edit the translations. Therefore, we might as well have stored the translated strings as a CVS file, so avoiding having to copy the translated strings into the resource files.
Once again if the translated strings were stored as a CSV file, we could have cached them in the ASP.NET cache. Then any changes to the translations would show up on the next page load.
So we could have used a custom implementation of the resource provider and keep to the standard ASP.NET resource lookup system. Or just ignore the standard resource lookup system if it does not help in your case – it depends on how your pages are written.
You may find at some point that you wish to be able to override strings for a single customer, if so you will need a multi-stage lookup system. Otherwise, you have to merge the customer’s custom strings with the translated string each time you ship a new version of the system.
对于第 4 点。
我一直在我们网站上的所有字符串中使用 .resx 文件，这些字符串必须本地化为多种语言，并且没有遇到任何重大问题。
您需要考虑的一件事是您是否希望该文本可被搜索。 对于我工作的一些网站，有一些需要可搜索的本地化资源，因此我必须将它们保存在数据库中。 但是，当我有选择时，出于与上述类似的原因，我更喜欢 .resx 文件。
For point#4.
I have been using .resx files for all strings on our site that must be localized into many languages and haven't had any major issues with them.
The one thing that you need to think about is if you want this text to be searchable. For some of the sites I work on there are some localized resources that need to be searchable so I must keep them in the database. However, when I have the choice I prefer the .resx file for similar reasons mentioned above.
我只是补充一点，您应该寻找资源提供者（像会员提供者这样的提供者模型）的自定义实现（或者您拥有）来将您的资源存储在数据库中。 这就是我们为 CMS 所做的，它非常有用。
当我们第一次寻找示例时，我们发现创建数据驱动的 ASP.NET本地化资源提供者和编辑者。
I will simply add that you should look for custom implementations (or do you own) of the resource provider (provider model like the membership provider) to store your resources in a database. That's what we did for our CMS, and it's very useful.
When we first looked for an example back then we found Creating a Data Driven ASP.NET Localization Resource Provider and Editor.
这是我对资源文件的看法：
我假设如果有大量字符串，那么使用数据库可能是允许搜索和排序数据的最佳方法。 在资源表中考虑多种语言可能不会太困难，而且速度最好快。
我认为这是存储静态资源或客户端可能更改的内容的好方法。 对于动态资源，最好单独使用数据库，或者与文件系统结合使用。 我认为在新的 SQL Server 中有一种新类型，它是使用数据库和文件系统的最佳混合体。
我在另一个问题（不知道哪个）中读到，在外部项目中使用资源文件是一种很好的做法，因为当资源发生变化时，您不必重新编译整个项目。 只需重新编译资源项目即可。 这还允许客户进行（相当）简单的编辑，他们只需要资源项目的“源代码”，而不是其他真实的代码（API 代码等）。
我没有充分使用资源文件来对其可靠性、可扩展性或使用它们时可能遇到的任何潜在问题做出任何声明。
Here is my take on resource files:
I would assume that if there is a LARGE amount of string, that using a database might be the best method to allow for searching and sorting of the data. It would probably not be too difficult to account for multiple languages in a resource table, and the speed should best fast.
I would think that this is a good method for storing static resources, or things that might be changed by a client. As for dynamic resources, it might be better to use a database, either alone, or in conjunction with the file system. I think in the new SQL Server there is a new type that is an optimal hybrid of using a database and the file system.
I read in another question (don't know which) that using resource files in an external project is a good practice, because you wouldn't have to recompile an entire project when resources change. Just recompile the resource project. This would also allow for (fairly) easy edits to be made by clients, where they would only need to "source code" for the resource project, and not your other real code (API code, etc.).
I have not used resource files enough to make any claims about their reliability, extensibility, or any potential issues that you might have when working with them.
在转储之前的代理服务器后，我一直在 .net razor 页面应用程序中使用资源文件，该代理服务器使用自定义正则表达式语言来替换通过代理的字符串。
我们放弃了代理方法，因为它更适合大字符串（段落），并且对于我们拥有的所有动态片段和内容来说非常尴尬。
完全没有问题，而且到目前为止比代理服务器更快。 我将所有目标页面、评论、名称、en 和所有其他可用语言存储在数据库中。为新语言添加新列很简单。
到目前为止，我们在多个 resx 文件中有大约 5k 条目，然后
我使用构建器进程来创建所有 resx 文件，并在任何更新内容时将它们放置在正确的本地和全局文件夹中。
为译者构建一个简单的界面来搜索页面、语言、评论、名称等并进行更新非常容易。 我们选择不在更改时自动重建 resx 文件，但如果您信任您的译者，您可以这样做；）
我们还允许译者添加新的片段/文本进行翻译，但到目前为止，我们还没有关于如何包含它们的任何好主意自动，必须手动替换源文件中的字符串并重新编译。
为了编辑 resx 文件，我使用了 zeta，
https://www.zeta-resource- editor.com/index.html
它可以一次性打开您的所有语言，并突出显示占位符的差异以及缺少的翻译。 您可以在一行中编辑所有语言并一次性保存所有文件。 我们现在不使用它，因为所有内容都在数据库中，但推荐它。
I've been using resource files in a .net razor page app after dumping our previous proxy server that used a custom regular expression language to replace strings as they passed through the proxy.
We dumped the proxy method as it was more suited to large strings (paragraphs) and pretty awkward for all the dynamic fragments and stuff we had.
Had no problem at all and it's faster so far than the proxy server. I store all the target pages, comments, names, en and all other available languages in a DB..trivial to add a new column for a new language.
We have about 5k entries in multiple resx files so far
I then use a builder process to create all the resx files and place them in the correct local and global folders any time something is updated.
Dead easy to build a simple interface for translators to search for pages, languages, comments, names etc and update. We choose not to auto rebuild the resx files on a change but you could if you trust your translators ;)
We also allow translators to add new fragments/text to translate but as yet we've not had any bright ideas on how to include them automatically and have to manually substitute the string in the source file and recompile.
For editing resx files I've used zeta,
https://www.zeta-resource-editor.com/index.html
Which can open all your languages in one go and highlights differences in placeholders and also missing translations. You can edit all the languages on one row and save all the files in one go. We don't use it now as everything is in the DB but recommend it.