在 ASP.NET 中使用 SQL 代替 RESX 文件进行本地化
我正在考虑开发以下内容，但想知道它是否已经存在：
我需要一个基于 SQL 的解决方案来为 asp.net 站点分配和管理本地化文本值，而不是使用 RESX 文件。这有助于维护网站上的文本，而无需在需要更新时将其删除以进行部署。
谢谢。
I'm thinking of developing the following but wondering if it already exists out there:
I need a SQL based solution for assigning and managing localization text values for an asp.net site instead of using RESX files. This helps maintain text on the site without having to take it down for deployment whenever an update is required.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我们实际上沿着这条路走下去，最终得到了一个非常非常慢的网站 - 放弃基于 SQL 的翻译机制并使用 ASP.NET 资源给我们带来了显着的性能提升。所以我真的不能建议你做同样的事情......（是的 - 我们正在缓存和优化吞吐量和一切 - 基于 SQL 的东西仍然明显慢）。
一分钱一分货 - 基于 SQL 的方法在能够即时“翻译”以及修复拼写错误等方面更加灵活。但最终，在我们的应用程序（Webforms，当时的 .NET 2.0）中，使用资源被证明是唯一可行的方法。
We actually went down that path, and ended up with a really really slow web site - ripping out the SQL-based translation mechanism and using the ASP.NET resources gave us a significant performance boost. So I can't really recommend you do that same thing.... (and yes - we were caching and optimizing for throughput and everything - and the SQL based stuff was still significantly slower).
You get what you pay for - the SQL based approach was more flexible in terms of being able to "translate" on the fly, and fix typos and stuff. But in the end, in our app (Webforms, .NET 2.0 at that time), using resources proved to be the only viable way to go.
我们做到了这一点（基于 SQL 的翻译），我们对结果非常满意！我们为翻译机构开发了一个界面，用于在线更新页面。作为副作用，该解决方案开始充当内容管理系统。如果缓存数据，性能就不是问题。缺点是，我们在解决方案上投入了数百个小时。 （我猜大约 600 小时，但我可以检查一下。）。
We did this (SQL-Based Translation) and we are really happy with the result! We developed an interface for translation-agencies to perform the updates to the page online. As a side effect, the solution started to serve as content-management system. If you cache your data, performance is not an issue. The downside is, that we invested multiple hundreds of hours into our solution. (I would guess sth. arround 600 hours, but I could check.).
我们最终得到了一个混合解决方案，用户可以将内容编辑到数据库中，但应用程序随后创建一个手动部署的 .resx。
您还可以完全绕过服务器翻译，并在客户端上用 jQuery 进行翻译，这是我成功使用的方法。
We ended up with a hybrid solution where users could edit content into a database but the application then created a .resx which was deployed manually.
You could also bypass the server translation altogether and do translation in jQuery on the client which is an approach I have used successfully.
我不确定网站是否会重启，但至少使用.NET MVC很方便，而且我没有注意到重启问题，如果出现的话，需要多久更新一次resx文件？对于更大的项目，我使用创建一个包含多个项目的解决方案，其中一个用于本地化，如下所示：
然后，在 Web 项目中，我添加对本地化项目的引用，并像
@MyApp.Localization.Model.Customer.CustomerName
@MyApp.Localization.Page 一样使用它。 About.PageTitle
@MyApp.Localization.File1.Paragraph1
每次更改翻译文本时，我都会上传更新的 .dll 或复制 .resx 文件。
注意：您需要将 resx 文件设置为 PUBLIC，以便可以作为强类型进行访问。
I'm not sure about the website restart, but at least using .NET MVC is very convenient and I haven't noticed that restart problem, and, if occurs, how often you need to update the resx files? For bigger projects I use to create a solution with multiple projects, one for the localization, something like this:
Then in the Web project I add a reference to the Localization project, and use it like
@MyApp.Localization.Model.Customer.CustomerName
@MyApp.Localization.Page.About.PageTitle
@MyApp.Localization.File1.Paragraph1
Everytime I change the translated text, I either upload an updated .dll or copy the .resx files.
NOTE: You need to set your resx files to PUBLIC, so can be accessed as strongly typed.
我创建了一个基于 SQL 的翻译方案。但我仅在请求时加载给定页面所需的翻译，并且仅加载该特定页面的翻译。
当页面重新加载并在会话期间缓存时，它们会被加载到字典对象中。然后就是根据查找进行文本替换。
几乎所有内容都是动态生成的，并且包括必须翻译的用户定义内容，因此灵活性是关键。
性能相当快，检索所有数据的 SQL 查询需要更长的时间（相对而言）。
I created a SQL based translation scheme. But I only load the needed translations for a given page when it is requested, and just the ones for that particular page.
Those get loaded into a dictionary object when the page reloads and cached during the session. Then is just does text replacement based off a lookup on that.
Pretty much all of it is dynamically generated, and includes user defined content that must be translated, so the flexibility is key.
Performance is quite fast, the SQL queries to retrieve all the data take much longer (relatively speaking).