ASP.Net本地化（Satellite程序集与自定义ResourceProvider的DB）

Question

我正在寻找最佳解决方案，以便在不部署/构建现有代码库的情况下轻松地将新语言添加到asp.net网站。

根据我的研究，似乎你可以动态编译资源文件到Satellite程序集，但我不确定如何使应用程序使用这些DLL一旦生成？

我看到的另一个选项是将翻译存储在数据库中，并编写自定义ResourceProvider，以便可以使用内置的本地化方法，同时抽象实际的实现（在本例中是数据库）。 p>

无论哪种方式，此站点的前端都是相同的（meta：控件的resourcekey等）。

但我正在努力决定哪种方法最容易保养。例如，发布一个新的Satellite程序集是否会重新启动应用程序池，或者是否可以很好地检查所有内容？

修改

翻译将由第三方API提供，因此人员维护质量并不重要。由于收到的答案，我想我会加上这个。

Answer 1

使用Asp.Net（目前），您不必自己编译，只需部署resx文件（到App_LocalResources或App_GlobalResources文件夹），Asp.Net将负责将它们编译为Satellite Assemblies。那很酷。

使用数据库方法，您将面临同步问题的风险：您如何知道给定的资源字符串是否已翻译？此外，纠正它们并不是很容易（对于翻译/本地化工程师）。而且无论如何你都需要准备“安装”脚本。如果这是你要给翻译的话，祝你好运。你会面临大量的过度翻译，你必须纠正它们（手动？）。

Resx文件（简单的XML）更容易验证（根据给定的XSD，它是有效的XML，或者不是）。此外，它是标准技术，您不需要自己实施任何东西。这就是为什么，我会推荐它。

---

修改

数据库驱动资源的另一个问题可能是字符编码。您需要创建自己的翻译工具包。我的经验是，结果可能是几种不同的编码。特别是，如果要使用纯文本文件。另一方面，XML文件的默认编码是UTF-8 ......

Answer 2

<强> RESX

在mit Windows窗体和Web窗体应用程序中有大约30多种语言（this one，如果我允许放置链接），我最终在App_LocalResources中使用简单的RESX文件取得了最大的成功。

我发现虽然在VS.NET中编译速度极慢，但是稍微修改了一下方法：

1. VS.NET解决方案中只有英文RESX文件。
2. 网站的影子结构只包含 所有语言的App_LocalResources，包括单独文件夹中的英文，VS.NET不可见。
3. 编写一个简单的CMD脚本，将真正的英语资源复制到单独的文件夹中。
4. 使用我的免费工具Zeta Resource Editor实际翻译单独的文件夹。
5. 有一个发布脚本，可以将真实的网络文件（如ASPX，ASAX，MASTER等）复制到网站上，并将资源复制到网站上。

这种方法使编译速度非常快，并且仍然允许我将编译和翻译分开。

缺点是实时Web应用程序的第一次调用编译的时间相当长，直到现在，我都没有办法加速这个/预编译（尽管我确实认为 可能）。

<强>数据库

我还做了一些在数据库和自定义<%#...%>块中进行本地化的项目来加载语言。

今天，我会反对这一点，因为它是非标准的。虽然编译速度可能同样快，但无论是涉及1种还是50种语言。

第三方工具

你也可以拿一个商业产品来做翻译，如果我能买得起，我也很有可能做到这一点。

只是我的两分......