.resx vs database与自定义解决方案,用于提供本地化/全球化

Question

在我的办公室,我们就本地化/全球化以及如何处理它进行了长期的辩论.一方推动内置于ASP.NET的资源(.resx)文件路由,一方面推动数据库驱动的解决方案.第三组相信推出自定义解决方案.

当然,每种方法都有其独特的优点和缺点 - 我们一遍又一遍地讨论它,而没有达成真正的共识.

所以,我向社区提出这个问题:根据您的经验,随着应用程序的增长,哪种方法可以提供以下最佳组合:

1. 可维护性
2. 可扩展性
3. 性能/可扩展性

除了建议之外,我们还对任何可能有助于简化问题的开源项目感兴趣.谢谢!

Answer 1

Rick Strahl(一个MS MVP)有一个很棒的工具包,用于通过数据库管理本地化 - 提供通过受控环境按需更新和修改的功能,并为您完成大量繁重工作.Histoolkit提供以下功能:

数据驱动的本地化资源提供者

• 数据库驱动的本地化允许您将资源存储在SQL Server数据库中.
• 基于Interactive Web的Resource Adminstration提供基于Web的实时管理,可以在应用程序运行时编辑和更新资源
• 资源编辑控件将图标与每个可本地化控件相关联,并允许直接跳转到管理表单,并选择当前资源ID和区域设置.
• Resx Import and Export允许您导入现有的Resx资源,使用数据驱动的提供程序以交互方式编辑它们,然后将它们作为Resx资源导出.
• 本地化实用程序,如JavaScript资源处理程序,用于嵌入本地化脚本值等功能.

他还在这里很好地总结了这些问题(我在这里粘贴了一些好东西 - 不是我自己的工作!)

Resx或不Resx

.NET中的默认资源存储机制使用基于Resx的资源.Resx是指XML文件的文件扩展名,用作.NET本机资源的原始输入.虽然XML是您在Visual Studio和.Resx文件中看到的输入存储格式,但最终的资源格式是二进制格式(.Resources),它由编译器编译成.NET程序集.这些编译的资源既可以与二进制程序集中的代码一起存储,也可以单独存储在资源附属程序集中,其唯一目的是提供资源.通常在.NET中,Invariant文化资源嵌入到基本程序集中,其中包含存储在特定于文化的子目录中的附属程序集中的任何其他文化.

如果您正在使用Visual Studio,则资源编译过程非常自动 - 当您将.Resx文件添加到项目时,VS.NET会自动编译资源并将它们嵌入到程序集中,并创建附属程序集以及所需的目录结构.每个受支持的语言环境.ASP.NET 2.0通过进一步自动化资源服务模型并自动编译找到App_GlobalResources和App_LocalResources的Resx资源,并使用特定于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),以便从包括数据库之外的任何位置提供资源.

Answer 2

您可能知道,本地化.Net应用程序的默认方法(实际上是行业最佳实践)使用资源文件(在本例中为.resx).如果要使用数据库,则必须编写自己的ResourceManager.

从这一点来看,答案应该是显而易见的:使用标准并且不要重新发明轮子.

您可能想知道为什么通过资源文件进行本地化成为行业标准.嗯,有很多原因(这里提到太多),其中大多数都是关于本地化过程.关键的一点是,为数据库驱动的本地化更新(即修复或安装)翻译非常困难.想想你需要安装它 - 一些SQL脚本.你知道如果你发送这个翻译会发生什么吗？甚至错误地更新它？这些类型的文件使用起来不是很安全(并且它们往往非常大),所以要么你需要创建某种类型的生成器(使用类似资源的文件作为输入,这完全符合目的...... )或者你需要非常小心(并祈祷翻译不会破坏文件).

也就是说,数据库驱动的本地化有时是唯一明智的做事方式 - 这就是当你需要实现所谓的动态本地化时,即允许用户翻译内容或以多种语言添加内容.
对于静态本地化(典型方案),请使用资源文件.