MUI 基本概念说明
MUI 的先决条件
为 Windows Vista 及更高版本生成 MUI 兼容应用程序的基本先决条件是按照 Windows 全球化准则设计应用程序。
将源代码与特定于语言的资源分离
MUI 技术的基本前提之一是将应用程序源代码与特定于语言的资源分离，以便更有效地在应用程序中实现多语言方案。 代码和资源分离是通过不同机制实现的，并且随着时间的推移，在不同程度上实现了，如以下各节所述。 每种方法在生成、部署和维护应用程序方面提供了不同程度的灵活性。
建议针对符合 MUI 的应用程序的解决方案是此处概述的最后一种方法，即将应用程序源代码和资源的物理分离，资源本身进一步细分为每个受支持语言的一个文件，以便在生成、部署和维护方面具有最大的灵活性。
早期：代码和资源一起生活
最初，本地化应用程序是通过编辑源代码并更改资源 (通常是代码本身中) 字符串并重新编译应用程序来创建的。 这意味着，若要生成本地化版本，必须复制原始源代码， (源代码中的元素) 资源转换文本，然后重新编译代码。 下图显示了应用程序代码，其中包含需要本地化的文本。
虽然此方法允许创建本地化应用程序，但它也有明显的缺点：
- 它需要多个版本的源代码，至少一个版本用于源语言，每个目标语言对应一个版本。 这在同步应用程序的不同语言版本时会产生重大问题。 特别是，当需要在代码中修复缺陷时，需要在源代码的每个副本中修复缺陷， (每种语言) 一个。
- 它还极易出错，因为它需要本地化人员（不是开发人员）对源代码进行修改，从而在代码完整性方面产生相当大的风险。
这些缺点的组合使得这一提议非常低效，需要更好的模型。
以逻辑方式分隔代码和可本地化资源
与上述模型相较，一个显著改进是应用程序的代码和可本地化资源的逻辑分离。 这会将代码与资源隔离开来，并确保在通过本地化更改资源时代码保持不变。 从实现的角度来看，字符串和其他用户界面元素存储在资源文件中，这些文件相对容易转换，在逻辑上与代码部分分开。
理想情况下，添加对任何给定语言的支持都非常简单，只需将可本地化的资源翻译成这种新语言，并使用这些翻译的资源创建新的应用程序本地化版本，而无需任何代码修改。 下图演示了如何在应用程序中以逻辑方式分隔代码和可本地化资源。
此模型可以更轻松地创建应用程序的本地化版本，并且与以前的模型相比，这是一个重大改进。 此模型通过使用资源管理工具实现，多年来一直非常成功，目前仍被许多应用程序普遍使用。 但是，它确实有明显的缺点：
- 虽然在逻辑上是分开的，但代码和本地化资源仍以物理方式联接在一个可执行文件中。 特别是，可维护性仍然存在问题，因为所有语言版本中相同的代码缺陷 (相同，) 需要每种语言的修补程序。 因此，如果以 20 种语言交付应用程序，则需要针对每种语言) 发出 20 次服务修补程序 (一次，即使代码仅修复一次。
- 此模型未充分支持多语言应用程序的分发和使用。 在 OEM 和企业方案中，这可能是一个重大问题。 例如，如果要在两个使用不同语言的用户之间共享计算机，则需要使用此模型安装两次应用程序，然后需要启用某种机制，以便在两个安装之间交替。 这假定没有其他依赖项阻止实现此方案。 下图显示了需要两个修补程序的单个代码缺陷示例。
很明显，虽然此模型在某些情况下效果良好，但它对多语言应用程序及其部署的限制可能会非常成问题。
此模型可缓解一些多语言应用程序问题的一个变体是可本地化资源包含一组不同语言资源的模型。 此模型具有一个通用代码库和多个资源，适用于同一应用程序中的不同语言。 例如，应用程序可以在同一包中随附英语、德语、法语、西班牙语、荷兰语和意大利语。 下图显示了包含多种语言资源的应用程序。
当需要修复代码缺陷时，此模型可以更轻松地为应用程序提供服务（这是一种改进），但在支持其他语言时，它并没有比以前的模型改进。 在这种情况下，仍需要发布新版本的应用程序 (，并且由于需要确保所有语言资源在同一分发) 中同步，因此该版本可能很复杂。
以物理方式分隔代码和资源
下一个进化步骤是以物理方式分隔代码和资源。 在此模型中，资源从代码中抽象出来，并在不同的实现文件中以物理方式分隔。 具体而言，这意味着代码可以真正独立于语言;实际上，应用程序的所有本地化版本都附带相同的物理代码。 下图演示了代码和可本地化资源必须以物理方式分隔。
与前面的方法相比，此方法具有几个优点：
- 大大简化了多语言解决方案的部署。 添加对任何给定语言的支持只需为此特定语言传送和安装一组新的语言资源。 当语言资源并非全部同时可用时，这一点尤其重要。 使用此模型，可以使用一组核心语言部署应用程序，并随时间推移增加支持的语言数量，而无需修改或重新部署实际代码。 回退机制进一步扩展了这一优势，该机制允许使用给定语言对应用程序和系统组件进行部分本地化，方法是确保在此首选语言中找不到的资源“回退”到用户也理解的另一种语言。 总体而言，此模型有助于减轻全球公司在部署多种语言应用程序时面临的巨大负担，因为它能够以更有效的方式实现单一映像部署。
- 可维护性得到改进。 代码缺陷只需修复和部署一次，因为代码完全独立于本地化。 使用此模型时，如果更改与 UI 无关，则对代码缺陷进行更正，比之前的任何模型都简单且经济高效。
动态加载特定于语言的资源
在 物理上将源代码与特定于语言的资源分开，并为应用程序生成非特定语言的核心二进制文件的 MUI 基本概念基本上设置了一个体系结构，该体系结构有利于基于用户和系统语言设置实现特定于语言的资源的动态加载。
捆绑到非特定语言核心二进制文件中的应用程序源代码可以利用 Windows 平台中的 MUI API，为给定上下文抽象选择适当的显示用户界面语言。 MUI 通过以下方式支持这一点：
- 基于系统、用户和应用程序级、用户级和系统级设置构造显示用户界面语言的优先级列表。
- 实现一种回退机制，该机制根据本地化资源的可用性从此优先语言列表中选择适当的候选项。
动态加载具有优先回退的用户界面资源的好处包括：
- 它允许使用给定语言对应用程序和系统组件进行部分本地化，因为在此首选语言中找不到的资源将自动回退到优先级列表中的下一种语言。
- 它支持从一种语言动态切换到另一种语言等方案。
- 它允许为 OEM 和企业创建涵盖一组语言的区域或全球单一部署映像。
生成 MUI 应用程序
前面的部分概述了将源代码与特定于语言的资源分开的选项，以及利用核心 Windows 平台 API 动态加载本地化资源所带来的好处。 虽然这些是指南，但还应指出，对于开发适用于 Windows 平台的 MUI 应用程序，没有具体的规范性方法。
应用程序开发人员可以选择如何处理各种用户界面语言设置、资源创建选项和资源加载方法。 开发人员可以评估本文档中提供的准则，并选择符合其要求和开发环境的组合。
下表总结了可供希望为 Windows 平台创建 MUI 应用程序的应用程序开发人员使用的不同设计选项。
| 用户界面语言设置 | 创建资源 | 资源加载 |
|---|---|---|
| 遵循操作系统中的 UI 语言设置${REMOVE}$ |
拆分资源二进制 (MUI 资源技术中的单一语言) -或- 非拆分资源二进制文件中的多种语言 |
应用程序调用标准资源加载函数。 资源以与操作系统设置匹配的语言返回。 |
| 特定于应用程序的资源机制 |
应用程序调用 MUI API 从操作系统中检索线程首选 UI 语言或进程首选 UI 语言，并使用这些设置加载其自己的资源。 |
|
| 特定于应用程序的 UI 语言设置${REMOVE}$ |
拆分资源二进制文件中的单种语言 -或- 非拆分资源二进制文件中的多种语言 |
应用程序调用 MUI API 来设置特定于应用程序的 UI 语言或进程首选的 UI 语言，然后调用标准资源加载函数。 资源以应用程序或系统语言设置的语言返回。 -或- 应用程序以特定语言探测资源，并从检索到的二进制数据中处理自己的资源提取。 |
| 特定于应用程序的资源机制 |
应用程序管理自己的资源加载。 |