ASP.Net 多租户 SaaS 应用程序中的本地化 (i18N)
问题场景：
在基于 SaaS 的应用程序中实施 ASP.Net 本地化。
额外的复杂性：租户应该能够编辑本地化内容。因此，如果托管应用程序有 10 个租户，每个租户支持 5 种语言，我们最终可能会得到 50 个翻译内容单元。
请就上述场景提出理想的方法。
下面列出的是过去使用的方法（对于我的其他应用程序）以及为什么它们现在不相关：
选项 1： ASP.Net资源文件
问题： 每个可本地化资源（.aspx 页面）仅创建一种语言文件。因此，不可能为每个租户翻译拥有一个 Home.aspx.resx 文件。 虽然可以修改 resx 键以包含 TenantId (lblFirstName_44) 并存储在同一个 resx 文件中，但这将很难维护，并且我们最终可能会得到大文件。
选项 2： 将多语言内容存储在专用数据库表中（标签、消息、菜单项）
问题： 这在过去很有效（在最终用户需要动态更新可本地化内容的情况下）。早期的解决方案严重依赖缓存数据，在多租户解决方案的情况下，数据需要每个租户的每页进行大量缓存。缓存也可以按内容类型（标签、消息、菜单项）进行。
另一种方法可以是实现自定义资源提供程序（通过构建.Net 的现有提供程序）
选项 3： FairlyLocal 等第三方开源解决
方案问题： 尽管实现起来非常简单，但它具有与 .resx 文件相同的缺点 - 其设计目的不是允许最终用户修改内容并维护同一文件的多个版本（租户方面）。
注意：如果找不到其他解决方案，我们可能会选择选项 2
Problem scenario:
Implement ASP.Net localization in a SaaS based application.
Additional complexity: The tenant should be able to edit the localized content. Thus, if the hosted application has 10 tenants with each supporting 5 languages, we could end up with 50 units of translation content.
Please suggest on what would be an ideal approach given the above scenario.
Listed below, are approaches used in the past (for my other applications) and why they are not relevant now:
Option 1:
ASP.Net resource files
Problem:
Only one language file is created per localizable resource (.aspx page). Hence, it is not possible to have one Home.aspx.resx file for each of the tenant translations.
Though the resx keys can be modified to contain the TenantId (lblFirstName_44) and stored in the same resx file, but then this would be difficult to maintain and we could end up with large files.
Option 2:
Storing multilingual content in dedicated database tables (Labels, Messages, MenuItems)
Problem:
This has worked well in the past (in scenarios where the end user requires dynamic update of localizable content). The earlier solution relied heavily on cached data, in case of a multi-tenant solution the data would require extensive caching per page – per tenant. The caching could also be done per content type (Labels, Messages, MenuItems)
An alternate approach could be to implement a custom resource provider (by building on .Net’s existing provider)
Option 3:
Third party open source solutions like FairlyLocal
Problem:
Although very simple to implement, suffers from the same drawback as .resx files – not designed for allowing the end user to modify the content and to maintain multiple versions (tenant-wise) of same file.
Note: In case of not finding another solution, we would probably go with Option 2
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会选择第二个选择。特别是由于您的资源条目可能会被修改，因此 resex 文件不是您所说的一个选项。
。您可以轻松找到一个好的资源提供程序，例如 westwind 或编写一个自定义提供程序。
I'd go for the second option. Especially since your resource entries are subject to modifications, resex files are not an option as you have said.
. You can easily find a good resource provider such as westwind one or write a custom provider.
第一个选项（将可翻译文本存储到资源文件中）已经过时了。这将导致完全无法管理的混乱。
第二种选择（使用数据库）是最有前途的，只需编写自己的资源提供程序，实现数据库逻辑即可完成。在多租户的情况下，您还需要提供有效的上下文（基于 URL？）和回退机制（因此，如果找不到该租户的资源密钥，它将使用默认字符串），但这些都是小麻烦。
至于第三方解决方案，我还没有听说过可以在您的环境中使用的解决方案。您可能必须实现与数据库解决方案几乎相同数量的代码（以支持多租户），但您最终会依赖于某些供应商 - 这对我来说似乎不太灵活（想想您会如何修复错误...）。
The first option (storing translatable texts into resource files) is out. This would result in totally unmanageable mess.
The second option (using Database) is the most promising, just write your own Resource Provider, implement DB logic and you are done. In case of multi-tenancy, you would also need to provide valid context (based on URL?) and fall-back mechanism (so if the resource key is not found for this tenant, it would use default string) but these are minor annoyances.
As for third-party solutions I haven't heard of one that could be used in your context. You would probably have to implement almost the same amount of code as in case of DB solution (to support multi-tenancy) but you would end up with having a dependency on some vendor - this seems less flexible to me (just think how you would fix bugs...).
听起来可扩展且可维护的唯一选择是将本地化文本存储在数据库中。资源类型的映射可能有点复杂（例如图像），但仍然是比其他两种更好的解决方案。
这让我想知道，微软为什么没有专门通过他们的 Azure 计划来想出解决这一挑战的方法。
The only option that sounds scalable and maintainable is to store localized text in database. Resource type could be a bit complicated to map (such as images) but still a better solution than either of the other two.
It makes me wonder, how come Microsoft did not think of a solution to this challenge specially with their Azure initiative.