在我的办公室，我们就本地化/全球化以及如何处理它进行了长期的辩论。一方推动内置于ASP.NET的资源（.resx）文件路由，一方面推动数据库驱动的解决方案。第三组相信推出自定义解决方案。
当然，每种方法都有其独特的优点和缺点 - 我们一遍又一遍地讨论它，而没有达成真正的共识。
所以，我向社区提出这个问题：根据您的经验，随着应用程序的增长，哪种方法可以提供以下最佳组合：
除了建议之外，我们还对任何可能有助于简化问题的开源项目感兴趣。谢谢！
答案 0 :(得分：25)
数据驱动的本地化资源提供程序
他也很好地总结了这些问题here（我在这里贴了一些好的东西 - 不是我自己的作品！）
要Resx或不要Resx
.NET中的默认资源存储机制 使用基于Resx的资源。 Resx是指XML的文件扩展名 用作原生资源的原始输入的文件 。净。虽然XML是您在Visual中看到的输入存储格式 Studio和.Resx文件，最终的资源格式是二进制 格式化（.Resources）由。编译成.NET程序集 编译器。这些编译的资源可以与之一起存储 二进制程序集中的代码或资源卫星中的代码 其唯一目的是提供资源的集会。通常在 .NET将Invariant文化资源嵌入到基础中 与存储在卫星组件中的任何其他文化的组装 在文化特定的子目录中。
如果您使用的是Visual Studio 资源编译过程非常自动 - 当你 将.Resx文件添加到项目VS.NET自动编译 资源并将它们嵌入到组件中并创建卫星 程序集以及每个程序集所需的目录结构 支持的语言环境。 ASP.NET 2.0进一步扩展了这个基础流程 自动化资源服务模型并自动编译 找到App_GlobalResources和的Resx资源 App_LocalResources并将它们提供给应用程序 特定于ASP.NET的资源提供程序。资源提供者 从ASP.NET中使资源访问更容易，更一致 应用。
.NET框架本身使用.Resx资源来提供服务 本地化的内容所以工具似乎很自然 框架提供了可供服务的资源创建工具 同样的模型。
Resx运作良好，但不是很灵活 当涉及到实际编辑资源时。工具支持 Visual Studio实际上不足以支持本地化 因为VS不提供交叉引用资源的简便方法 跨多个区域设置。虽然ASP.NET的设计编辑器可以提供帮助 最初为页面上的所有控件生成资源 - 通过 生成本地资源工具 - 它只适用于中的数据 默认的Invariant Culture Resx文件。
Resx资源也是静态的 - 他们毕竟编成了一个集会。如果你想做 更改您需要重新编译以查看这些更改的资源。 ASP.NET 2.0引入了可以存储的全局和本地资源 在服务器上，可以动态更新 - ASP.NET编译器 实际上可以在运行时编译它们。但是，如果你使用了 预编译的Web部署模型资源最终仍然存在 静态且无法在运行时更改。一旦你完成了 编译资源是固定的。
在运行时更改资源 可能看起来不是什么大不了的事，但它可能会非常方便 资源本地化过程。如果你能编辑就不好了 运行时的资源，进行更改，然后实际看到该更改 在UI中立即？
使用数据库资源
这让我把资源存储在一个 数据库。数据库本质上更具动态性，您可以制作 无需重新编译即可更改数据库中的数据 应用。此外，数据库数据更容易共享 多个开发人员和本地化人员因此更容易进行更改 团队环境中的资源。
当你考虑资源时 编辑它基本上是一个数据输入任务 - 你需要查找 单个资源值，查看所有不同的语言变体 然后添加和编辑每个不同语言环境的值。 虽然所有这些都可以使用Resx文件中的XML来完成 直接实际上，为数据库构建前端要容易得多 比散落在各地的XML文件。数据库也给你 在不同视图中显示资源数据的灵活性更高 并且可以轻松地执行批量更新和重命名键之类的操作 和价值观。
好消息是.NET中的资源方案是 没有固定，你可以扩展它们。 .NET和ASP.NET 2.0允许您 创建自定义资源管理器（核心.NET运行时）和资源 提供程序（ASP.NET 2.0）从任何地方（包括out）提供资源 数据库。
答案 1 :(得分：12)
您可能知道，本地化.Net应用程序的默认方法（实际上是行业最佳实践）正在使用资源文件（在本例中为.resx）。如果要使用数据库，则必须编写自己的ResourceManager。
由此，答案应该是显而易见的：使用标准而不是重新发明轮子。
您可能想知道为什么通过资源文件进行本地化成为行业标准。嗯，有很多原因（这里提到太多），其中大多数都是关于本地化过程。关键的一点是，为数据库驱动的本地化更新（即修复或安装）翻译是非常困难的。想想你需要安装它 - 一些SQL脚本。你知道如果你发送这个翻译会发生什么吗？甚至错误地更新它？这些类型的文件使用起来不是很安全（并且它们往往非常大），所以要么你需要创建某种类型的生成器（使用类似资源的文件作为输入，这完全符合目的......或者你需要非常小心（并祈祷翻译不会破坏文件）。
也就是说，数据库驱动的本地化有时是唯一明智的做事方式 - 这就是当您需要实现所谓的动态本地化时，即允许用户翻译内容或以多种语言添加内容。
对于静态本地化（典型方案），请使用资源文件。
答案 2 :(得分：4)
本地化用户界面不应存储在数据库中，最好使用标准的resx方法，因为这样可以灵活地为每个客户端/部署自定义前端的用户界面，而无需更改后端结束或存储有关数据库中每个客户端自定义的大量数据。
关于数据（双语数据或多语种数据）将它们存储在数据库中，并使用适合上下文的任何技术（每种语言的表格，或每种语言的重复列）。
答案 3 :(得分：4)
使用resx是一些静态值的最佳方法，这些静态值不需要通过应用程序的UI进行操作，但如果您的值需要更新，则DB驱动将是最佳选择。对我来说，它仍然是个案基础。但是我在互联网上看到的一个博客使resx文件可以通过用户界面更新.. http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html ..希望这对你有所帮助。
答案 4 :(得分：0)
如上所述，我想补充一些其他见解。
在处理“静态”项目/网站（如Dashboards或其他专注于特定用户组的小型网站）时，我倾向于使用基于.resx的本地化。
在处理大型和更多“动态”项目（如商店，服务产品等）时（特别是内容本地化时 - 不仅仅是标签）我喜欢使用数据库本地化。
当您在大型项目上开发时，每种语言都由另一个人维护，而这个人不一定在您的项目中（特别是在社区项目中）。因此，维护不同的语言变得非常麻烦。 另一方面，为用户提供一些好的/简单的UI来更新他们的语言也是非常耗时的。所以尽量找到适合你项目的好路径。