其他复杂性：租户应该能够编辑本地化内容。因此，如果托管应用程序有10个租户，每个租户支持5种语言，我们最终可能会有50个单位的翻译内容。
鉴于上述情况，请建议理想的方法。
下面列出的是过去使用的方法（对于我的其他应用程序）以及它们现在不相关的原因：
选项1： ASP.Net资源文件
问题： 每个可本地化资源（.aspx页面）只创建一个语言文件。因此，每个租户翻译都不可能有一个Home.aspx.resx文件。 虽然可以修改resx密钥以包含TenantId（lblFirstName_44）并存储在同一个resx文件中，但是这样很难维护，我们最终可能会得到大文件。
选项2： 在专用数据库表（标签，消息，MenuItems）中存储多语言内容
问题： 这在过去很有效（在最终用户需要动态更新可本地化内容的情况下）。早期的解决方案在很大程度上依赖于缓存数据，在多租户解决方案的情况下，每个租户需要对每页进行大量缓存。缓存也可以按内容类型（Labels，Messages，MenuItems）进行
另一种方法可能是实现自定义资源提供程序（通过构建.Net的现有提供程序）
选项3： 第三方开源解决方案，如FairlyLocal
问题： 虽然实现起来非常简单，但是与.resx文件有相同的缺点 - 不是为了允许最终用户修改内容和维护同一文件的多个版本（租户）而设计的。
注意：如果没有找到其他解决方案，我们可能会选择选项2
答案 0 :(得分：0)
我会选择第二种选择。特别是因为您的资源条目可能会被修改，所以不能像您所说的那样选择resex文件。
。您可以轻松找到一个好的资源提供者，例如westwind或写一个自定义提供者。
答案 1 :(得分：0)
第一个选项（将可翻译文本存储到资源文件中）已经完成。这将导致完全无法控制的混乱。
第二个选项（使用数据库）是最有前途的，只需编写自己的资源提供程序，实现数据库逻辑就可以了。在多租户的情况下，您还需要提供有效的上下文（基于URL？）和回退机制（因此，如果找不到此租户的资源键，它将使用默认字符串）但这些都是轻微的烦恼
对于第三方解决方案，我没有听说过可以在您的上下文中使用的解决方案。您可能必须实现与数据库解决方案几乎相同数量的代码（以支持多租户），但最终会依赖某些供应商 - 这对我来说似乎不那么灵活（只是想想你会怎么做）修复bug ...）。
答案 2 :(得分：0)
听起来可扩展和可维护的唯一选项是将本地化文本存储在数据库中。映射（例如图像）的资源类型可能有点复杂，但仍然是比其他两个更好的解决方案。
这让我很奇怪，为什么微软没有想到解决这个挑战，特别是他们的Azure计划。