.resx 与数据库与提供本地化/全球化的自定义解决方案
在我的办公室，我们对本地化/全球化以及如何处理它进行了长期的争论。一方面推动 ASP.NET 内置的资源 (.resx) 文件路由，一方面推动数据库驱动的解决方案。第三组相信推出定制解决方案。
当然，每种方法都有其独特的优点和缺点 - 我们已经反复讨论过，但从未达成真正的共识。
因此，我向社区提出：根据您的经验，随着应用程序的增长，哪种方法可以提供以下最佳组合：
- 可维护性
- 可扩展性
- 性能/可扩展性
除了建议之外，我们还对任何开源项目感兴趣，这些项目也可能有助于简化问题。谢谢！
At my office, we have had a long-standing debate about Localization/Globalization and how to handle it. One side pushes for the Resource (.resx) file route built in to ASP.NET, one side pushes for a database driven solution. A third group believes in rolling a custom solution.
Of course, each method has its own unique benefits and disadvantages - and we've discussed it over and over, without ever coming to a real consensus.
So, I pose it to the community: in your experience, which method provides the best mix of the following as the application grows:
- Maintainability
- Extensibility
- Performance / Scalability
In addition to just advice, we'd also be interested in any open source projects which might help to simplify the question, as well. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Rick Strahl（MS MVP）有一个很棒的工具包，用于通过数据库管理本地化 - 提供通过受控环境按需更新和修改的能力，并为您完成大部分繁重的工作。 Histoolkit 提供以下功能：
数据驱动本地化 资源提供程序
他还在此处很好地总结了这些问题（我在这里粘贴了一些好的内容 - 不是我的自己的作品！）
Rick Strahl (An MS MVP) has a great tool kit for managing localization via the DB - offer the ability to update and modify on demand through a controlled environment and does much of the heavy lifting for you. Histoolkit offer the following features:
Data Driven Localization Resource Provider
He also summarises the issues very well here (Ive pasted some good bits here - not my own work!)
您可能知道，本地化 .Net 应用程序的默认方法（实际上是行业最佳实践）是使用资源文件（在本例中为 .resx）。如果你想使用数据库，你必须编写自己的ResourceManager。
由此看来，答案应该是显而易见的：使用标准，不要重新发明轮子。
您可能想知道为什么通过资源文件进行本地化成为行业标准。嗯，原因有很多（这里无法一一提及），其中大多数与本地化过程有关。关键是，更新（即修复或安装）数据库驱动的本地化翻译非常困难。想想安装它需要什么 - 一些 SQL 脚本。您知道如果您将其发送出去进行翻译会发生什么吗？或者甚至错误地更新了？这些类型的文件使用起来不太安全（而且它们往往非常大），因此您要么需要创建某种生成器（使用类似资源的文件作为输入，这完全无法实现目的...... ）或者你需要非常小心（并祈祷翻译人员不会破坏文件）。
也就是说，数据库驱动的本地化有时是唯一明智的做法 - 这是当您需要实现所谓的动态本地化时，即允许用户翻译内容或以多种语言添加其内容。
对于静态本地化（典型场景），请使用资源文件。
As you perhaps know, default method (which is actually industry best practice) for Localizing .Net Applications is using resource files (.resx in this case). If you want to use database, you would have to write your own ResourceManager.
From this, the answer should be obvious: use standard and do not reinvent the wheel.
You might be wondering why Localization via resource files became industry-wide standard. Well, there are many reasons (too many to mention here), most of them regard to Localization process. The key one is, it is painfully hard to update (i.e. fix or install) translations for database driven Localization. Just think of what you need to install it - some SQL script. You know what will happen if you send out this for translation? Or even mistakenly update it? These kind of files are not very safe to work with (and they tend to be very large), so either you would need to create some kind of generator (with resource-like file as an input, which totally bits the purpose...) or you would need to be very careful (and pray that a translator won't break the file).
That is to say, database-driven Localization is sometimes the only sensible way of doing things - this is when you need to implement so-called dynamic Localization, that is allow users to translate things or add their contents in multiple languages.
For static Localization (typical scenario) use resource files.
本地化用户界面不应存储在数据库中，最好使用标准 resx 方法，因为这将使您可以灵活地为每个客户端/部署自定义前端用户界面，而无需更改后端或存储数据库中有关每个客户定制的大量数据。
关于数据（双语数据或多语言数据），将它们存储在数据库中，并使用适合上下文的任何技术（每种语言的表格，或每种语言的重复列）。
Localizing user interface should not be stored in database, it is preferable to use the standard resx method because this will give you the flexibility to customize the user interface of front end for each client/deployment, without the need to change the back end or store much data about each client customization in database.
Regarding data (bi-lingual data or multi-lingual data) store them in database and use whatever technique suitable for the context (table per language, or duplicate columns for each language).
对于某些不需要通过应用程序的 UI 操作的静态值，使用 resx 是最佳方法，但如果您的值需要更新，则数据库驱动将是最好的方法。对我来说，这仍然是个案的基础。但是我在互联网上看到的博客之一使 resx 文件可以通过用户界面进行更新。 http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html..希望这对您有帮助。
using resx is the best approach for some static values that needs not to be manipulated via UI of the app but if your values needs to be updated DB driven would be the best for it. For me its still a case to case basis. But one of the blogs I have seen in the internet made the resx files updateable via user interface.. http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html.. hope this would help you.
由于上述所有内容都是正确的，我想添加一些额外的见解。
在处理“静态”项目/网站（例如仪表板或其他小型网站）时，我倾向于使用基于 .resx 的本地化，这些项目/网站专注于特定的用户组。
当从事更大且更“动态”的项目时，例如商店、服务产品等（特别是当内容本地化时 - 不仅仅是标签），我喜欢使用数据库本地化。
当您开发大型项目时，每种语言都由另一个人维护，该人不一定在您的项目中（尤其是在社区项目中）。因此，维护不同的语言变得非常麻烦。
另一方面，为用户提供一些好的/简单的 UI 来更新他们的语言也很耗时。因此，请尝试为您的项目找到一条好的路径。
As all the above are true, I want to add some additional insights.
I tend to use .resx based localisation, when working on "static" projects/websites like Dashboards or other small websites, which are focused on a specific usergroup.
When working on larger and more "dynamic" projects like shops, service-offerings, etc. (esp. when content is localized - not only labels) I like to use database localisation.
When you are developing on larger projects each language is maintained by another person, who is not necessarily in your project (especially in community-projects). Thus maintenance of different languages becomes a real hassle.
On the other side providing users some good/easy UI to update their language is time-consuming as well. So try to find a good path for your project.