Web 应用程序的多语言支持

引言

在分析需求后，也许最重要的任务是分析实施功能的风险。在实施某个功能之前，通过对成本和结果进行有根据的猜测，我们可以避免日后出现许多问题。

在 irqnine（我的个人网站）的新版本中，最复杂的功能之一就是多语言支持。尽管 irqnine 可能在未来不需要多种语言，但这是一种很好的实践，可以增加系统的价值。实施多语言支持需要考虑的问题包括：

• 国际化支持。国际化是为了使应用程序能够本地化而进行的活动。需要考虑的问题包括识别不通用的控件标签，例如链接菜单或文章内容。
• 本地化支持。本地化是为了将应用程序适配到某个地区而进行的活动。这又可以细分为两个类别——界面本地化和内容本地化。
• 界面本地化。界面本地化是为了确保资源能够以高保真度翻译成另一种语言而进行的活动。需要此操作的资源示例包括按钮标签、文章文本、文章作者姓名等。
• 内容本地化。内容本地化是指发布对特定地区高度相关，但在其他地区不相关的能力。例如，越南的新闻网站将发布对越南以外地区不感兴趣的新闻。然而，这并不是一个多语言问题，而是使应用程序多语言化的一个结果。
• 翻译保真度。尽管翻译人员非常聪明，但有些内容根本无法翻译。诗歌可以直译，但其呈现的语境几乎总是完全丢失。v6 应该考虑到这一点，并允许内容创建者指定翻译是否准确，如果不准确，则指定作品的原始创作语言。此外，懂作品创作语言的多语言用户可能选择以原始语言查看该资源。
• 搜索引擎兼容性。大多数搜索引擎不使用 cookie。因此，为了让搜索引擎能够访问某个资源的各种可用语言，必须有一个文本 URL 指向这些语言，而不是根据用户的个性化设置生成语言。将会话 ID 包含在 URL 中会与 v6 的可读和可共享 URL 要求相冲突。
• 目标受众。解决方案的选择取决于系统的目标受众。吸引来自英语国家的网站很可能首先从英语系统开始。之后，会发现该网站吸引了大量中国用户。管理层随后决定支持中文，但可能会逐步推出支持。例如，所有用户界面元素将首先本地化。然后，中国用户经常访问的资源将按受欢迎程度排序进行本地化。
• 性能。性能是设计系统的约束之一。如果响应速度慢或运行成本过高，那么杀手级功能可能没有实际用处。
• 可扩展性。多语言支持中的可扩展性通常是指支持附加语言所需的工作。这对性能、可维护性和可扩展性等其他要求都有影响。
• 易于实现。由于我是一个单人软件公司，因此我不必花费过多资源来开发此功能非常重要。
• 其他。在任何系统的任何功能中，其他问题都是标准的——可用性、安全性、可维护性、可访问性、可扩展性和可靠性。

我将讨论支持多种语言的各种方法以及它们如何处理上述一些问题。

多站点方法

这种方法可能是最常用的。每个支持的语言都必须有一个应用程序域（无论是 .NET 意义上运行在同一进程中的独立应用程序域，还是在单独的进程中，或者完全是不同的位置）。用户必须在实际进入系统之前决定使用哪种语言。

分离应用程序域和数据存储意味着系统还可以支持本地化内容。越南的新闻网站将能够包含仅与越南居民相关的内容。由于不同应用程序域拥有唯一的 URL（例如 vi.news.com），因此搜索引擎可以轻松地聚合不同语言的内容。

该系统简单且性能良好，但很难混合资源的语言。例如，一个德国人母语是德语，但也读英语，并且倾向于德语内容（如果可用）。他正在查看的资源仅提供英文版。在这种方法中，他唯一的选择是以英语查看整个网站，将所有资源显示为英语，包括用户界面元素和最初是德语且有德语版的作品的超链接标题。

虽然这并非特别有问题，但更好的系统是以英语显示内容，如果可用，其余部分（用户界面、超链接标题）以德语显示。为了在多站点方法中支持这一点，应用程序不仅必须访问德语数据库，还必须首先确定该资源是否以德语提供。此外，当用户被转移到德语网站时，应用程序无法在没有复杂的远程处理解决方案¹ 的情况下转移用户的会话状态。

优点

• 结构简单，易于实现。系统只需要了解国际化。
• 高性能。在访问资源之前，不会向用户显示语言。
• 支持完全本地化——语言和内容的本地化；甚至是系统的物理位置。
• 自然支持分布式部署——但不支持协作。
• 完全的搜索引擎兼容性。

缺点

• 语言在单独的应用程序域中支持。用户会话状态在语言之间共享很复杂，并会产生性能开销。
• 维护量高。在一个应用程序域中的更改（配置、新版本代码）必须在其他应用程序域中复制。
• 不可扩展。支持 n 种语言需要 n 个应用程序域。
• 用户无法在另一种语言中找到匹配的资源。
• 需要跟踪不同语言的不同内容。

适用于

• 内容静态的网站，或者在网站启动前需要翻译的内容，而不是频繁和持续地进行翻译。例如，加拿大政府网站支持英语和法语。
• 支持的语言数量稳定的网站。例如，加拿大政府网站支持法语和英语，这相对来说是足够的。

上下文感知多站点方法

维基百科² 拥有出色的多语言支持。每篇文章都链接到所有可用语言中的相应文章。这实际上是多站点风格的扩展。

然而，维基百科的本地化工作不仅仅是语言翻译；它也是文化上的。有各种因素决定文章的语气，主要是由于文化偏见。例如，一篇关于帝国中国的英文文章可能会讨论“中国本土”，但这样一个敏感的词在中国版本中根本不会被提及。

此外，维基百科的风格没有默认语言。每种语言的网站都是独立发展的，并且只有在（通常是）事后才相互链接。这非常适合维基百科的模型，因为信息的增长取决于受众对重要性的看法，这偶尔会产生文化上不兼容的概念。irqnine 的方向是高保真度，追求直接翻译。

优点

• 用户能够找到资源的各种语言版本。
• 适用于独立发展的网站。

缺点

• 并非所有资源都已翻译。多种语言资源之间的临时关系。

适用于

• 维基百科！需要本地化内容不仅仅是在资源之间进行翻译的网站。

上下文多站点方法

这种方法通过强制规定原始资源与同一资源的翻译之间存在牢固的关系来解决上述松散耦合问题。每个资源在所有本地化数据存储中都将具有唯一的标识符，使用户和内容创建者能够找到绝对相关的翻译。

优点

• 同一资源的翻译之间有牢固的联系。

缺点

• 实现可能很复杂。
• 性能开销可能很高。
• 所有语言都提供每个资源，意味着要么必须本地化所有资源，要么不能有本地化内容。
• 应用程序域显示且仅显示本地化语言的保证意味着站点运营商必须拥有足够的人员来为每个新资源本地化所有可用语言。

适用于

• 内容高度审核的网站。

镜像方法

与将每种语言分离到不同的应用程序域中不同，所有语言网站都合并到一个应用程序域中。这立即解决了会话状态共享问题。用户的语言偏好存储在服务器上，允许系统确定向用户显示的语言。

如果首选语言不可用，系统会通知用户该语言不可用，并可能提供替代语言。

与多站点方法相比，需要检查所有可用语言与首选语言的比较会产生 O(n) 的性能命中——其中 n 是可用语言的数量——而多站点方法是 O(1)。数据存储在关系数据库中，每种支持的语言都在一个单独的表中，并且每种语言在规范化表中占据一行。因此，一张包含关键字所有语言的表将有 n 行，其中 n 是可用语言的数量。然而，空间使用与多站点解决方案大致相当，后者需要 n 个数据存储来支持所有可用语言。

站点运营商还必须识别需要翻译的元素，例如链接菜单。用于创建网站链接菜单时出错的英文消息对任何用户几乎都没有用。为了至少不向用户显示错误消息，系统可以通过复制稳定语言集中的资源并通知站点运营商哪些资源需要本地化来自动执行添加语言支持所需的任务。

优点

• 一个应用程序域支持所有语言。没有因多站点方法而导致的问题。
• 允许本地化内容。
• 原始内容与翻译之间有牢固的关系。
• 允许增量更新。

缺点

• 集中的数据存储——不可扩展。
• 选择用户语言和确定可用语言的性能开销可能不理想。
• 用户体验下降；用户看到异常。没有自动重定向到更友好的资源。
• 增量更新需要识别必须翻译的资源。

默认镜像

通过指定特定资源的默认语言，如果资源无法以首选语言提供，用户将看到以默认语言提供的资源。

这假设访问该网站的用户理解默认语言。最初以一种语言开始并扩展到支持其他语言的网站是这种方法的首选。对其他语言的支持可以是部分的。

与上下文多站点方法一样，确保基础语言可用的保证意味着内容创建者必须精通基础语言，或者有翻译人员将内容创建者 的内容翻译成基础语言。此外，本地化内容（例如，班加罗尔的汽车销售广告）必须翻译成基础语言，即使印度以外的人都不会感兴趣。

优点

• 允许自动“涓流”模型。所有资源都有基础语言，并逐步支持其他语言。
• 改善用户体验；用户无论如何都能看到相关内容。

缺点

• 假设用户理解默认语言。
• 没有本地化内容，或者内容变得通用。

自适应镜像

默认镜像可以扩展以支持具有多语言能力的用户。例如，一个德国人（DE）母语是德语，但也懂法语（FR），但英语（EN）很少。然后他会将他的语言偏好设置为 {DE, FR, EN}。尽管该网站的默认语言是 EN 且资源以 EN 提供，但该内容也以 DE 提供。在这种情况下，系统向用户显示 DE，从而改善用户体验。

如果同一用户请求一个可用性为 {VI, EN} 的资源，系统将以 EN 显示该资源，因为它在偏好列表中，并且知道用户能够查看 EN 内容，但无法完全查看 VI 内容。

这确实会降低性能，因为每次资源调用都必须经过最坏情况复杂度为 O(mn) 的决策算法，其中 m 是首选语言的数量，n 是可用语言的数量。

优点

• 首选语言中的资源首先显示给用户。
• 如果首选语言不可用，仍然向用户显示默认语言。

缺点

• 更大的性能开销 - O(mn)。然而，在考虑性能成本、功能吸引力以及整体系统成本时，这可能微不足道。

分布式镜像

一些站点运营商可能还需要将镜像放置在理想的位置，例如将服务器和数据存储设在日本以支持日语版本。这是最复杂的方法，需要扎实的分布式计算知识。由于 irqnine 在不久的将来（如果可能的话）不会这样做，因此不考虑这种方法。

混合

总而言之，多站点解决方案易于构建和部署，但难以发布内容。语言的混合会变得非常复杂。镜像方法更难构建，但通过将语言混合以满足用户的偏好来改善用户体验。理想的解决方案是让系统适应部署的环境，利用两者的优缺点。

irqnine 的要求是支持语言混合而不产生过多的性能开销。此外，对于不需要支持多种语言的网站，系统应该能够像不支持多语言的网站一样运行。

最直接的解决方案是找到支持最低要求的方法，并通过启用其他功能来优化性能。通过移除自适应功能，可以将语言确定算法简化为 O(n)。

但实际上，需要超过两种首选语言（其中一种是默认语言）的用户数量非常少。在这种情况下，支持自适应镜像是有益的，因为我们可以最大限度地提高用户灵活性，而不会产生巨大的性能损失。

对于不需要多语言支持的网站，该功能可以完全禁用。

通过将语言选择算法设计为类并使用策略设计模式，站点运营商无需重新编译任何代码或产生大量性能开销即可禁用多语言支持。

如果内容本地化很重要，并且维护两个应用程序域的成本可以接受，运营商可以根据需要创建任意数量的带有禁用多语言支持的站点。

这不幸地会遇到多站点解决方案固有的问题，即用户会话状态无法共享、不支持链接等。

最后，对于需要多语言支持和资源之间临时关系（ad hoc relations）的网站，站点运营商可以禁用默认设置。

从以前支持默认设置的站点切换到不支持默认设置的配置可能会对用户体验产生负面影响，因为用户会看到一个替代的语言选择屏幕，而不是之前的行为，即显示默认语言。解决此问题的一种方法是将默认语言添加到所有用户的语言偏好列表的底部，但无法理解默认语言的用户将无法继续。因此，最好让用户选择加入（opt in）而不是选择退出（opt out），在必要时将所需的语言输入列表中。

最终想法

国际化和本地化是一个复杂的问题。.NET Framework 自动化了全球化应用程序中的许多任务，例如资源库和自动用户语言选择。但是，本地化内容的后端支持仍然落在了开发者的肩上，因此在决定找到正确的解决方案并实施它之前，需要对该主题有非常透彻的理解。

脚注

1. ASP.NET 支持通过状态服务器和 SQL Server 状态服务进行进程外会话状态。这旨在支持 Web 场场景，而不是多语言网站——但可以用于此目的。
2. 维基百科最终可能使用了“镜像方法”中讨论的解决方案，但这里仅用作示例。然而，一个明显的迹象是，当一个人登录 en.wikipedia.org 时，转到 zh.wikipedia.org 并不会自动登录用户。这表明用户会话状态在这两个站点之间没有共享。