我正在寻找最好的解决方案，以便在不部署/构建现有代码库的情况下，轻松地向asp.net网站添加新语言。
根据我的研究，你似乎可以将资源文件动态编译成卫星程序集，但我不确定如何使应用程序在生成后使用这些DLL？
我看到的另一种选择是将翻译存储在数据库中，并编写一个自定义ResourceProvider，以便可以使用内置的本地化方法，同时抽象实际实现(在本例中为数据库(。
无论哪种方式，该网站的前端都是相同的(控件的meta:resourcekey等(。
但我正在努力决定哪种方法最容易维护。例如，发布一个新的Satellite Assembly会重新启动应用程序池吗？还是一切都很顺利？
编辑
翻译将由第三方API提供，因此人工维护质量并不重要。由于收到的答复，我想我会补充这一点。
带Asp。Net(目前(，您不必自己编译，只需部署resx文件(到App_LocalResources或App_GlobalResources文件夹(和Asp。Net将负责将它们编译成卫星组件。太酷了。
使用数据库方法，您将面临同步问题的风险：您将如何知道给定的资源字符串是否被翻译？此外，纠正它们也不是很容易(对于翻译/本地化工程师来说(。无论如何，您都需要准备"安装"脚本。如果这就是你要给翻译的，祝你好运。你会面临大量的过度翻译，你必须(手动？(纠正它们。
Resx文件(是简单的XML(更容易验证(就给定的XSD而言，它要么是有效的XML，要么不是(。此外，这是标准技术，您不需要自己实现任何东西。这就是为什么，我推荐它。
编辑
数据库驱动资源的另一个问题可能是字符编码。您需要创建自己的翻译工具包。我的经验是，结果可能是几种不同的编码。特别是，如果您想使用纯文本文件。另一方面，XML文件的默认编码是UTF-8…
RESX
在mit Windows Forms和Web Forms应用程序中有大约30多种语言(如果允许我放置链接的话，这一种(，我终于在App_LocalResources中使用了简单的RESX文件，取得了最大的成功。
不过，我发现在VS.NET中编译速度非常慢，所以有一个稍微修改过的方法：
- 在VS.NET解决方案中只有英文RESX文件
- 有一个网站的影子结构，只有所有语言的
App_LocalResources，包括单独文件夹中的英语，对VS.NET不可见 - 编写一个简单的CMD脚本，将真实的英文资源复制到单独的文件夹中
- 使用我的免费工具Zeta资源编辑器在单独的文件夹中进行实际翻译
- 有一个发布脚本，可以将真实的网络文件(如ASPX、ASAX、MASTER等(复制到网站，也可以将资源复制到网站
这种方法使编译非常快速，并且仍然允许我将编译和翻译分开。
缺点是，实时web应用程序的第一次调用编译的时间相当长，直到现在，我还想不出加速/预编译的方法(尽管我确实相信这是可能的(。
数据库
我还做了一些数据库本地化项目和自定义<%#...%>块来加载语言。
今天，我会投反对票，因为这是不标准的。尽管编译可能同样快，无论涉及1种还是50种语言。
第三方工具
你也可以找一个商业产品来做翻译，如果我能负担得起的话，我很可能也会这样做。
只有我的两分钱。。。