编写 Win32 多语言用户界面应用程序
Windows 2000 针对全球市场制定了新的增强支持标准,提供了许多国际化功能,例如完全支持 Unicode、预设支持数百种语言以及用于从右向左语言的镜像技术。在 Microsoft Systems Journal (MSJ) 中已经发表了多篇文章来说明如何针对 Windows 2000 来编写 Unicode、复杂脚本以及镜像的应用程序。
Windows 2000 多语言用户界面(也称为 MUI)是 Windows 2000 中一个最有用的国际化功能,它允许用户将系统的用户界面 (UI) 语言设置并更改为 Windows 2000 已发布的任何本地化语言。
本文将介绍如何在您的应用程序中提供可切换的 UI 功能。在本文中,您将:
-
了解为什么应该考虑投资编写多语言应用程序。
-
查看三种不同的多语言用户界面实现方式示例。
-
寻找建议的最佳方法及指导原则和代码示例。
本页内容
为什么要费力编写多语言应用程序?
有多种原因导致需要编写多语言应用程序。最明显的原因当然是通过打入国际市场(毕竟现在已经进入了互联网时代)来增加收入和提高软件销售量,此外还有两个有力的观点:
-
发布单一的二进制文件。通过向所有平台(和所有不同的语言版本)发布一个核心功能二进制文件来尽可能减少开发的繁琐程度和成本,从而避免对每种语言的源代码都分别提供编译条件和维护。Microsoft Windows 2000、Microsoft Office 2000 和 Microsoft Internet Explorer 5.0 均为单一的二进制文件 – 例如,美国英语、日语和阿拉伯语版本的 Windows 2000 均随附了相同的核心 gdi32.dll。未来 Service Pack 中对此模块的潜在更新可应用到所有语言,而无需任何其他技术方面的工作。
-
避免成为自身的竞争者。延迟发布不同语言版本的软件可能会严重影响客户的部署,并进而影响您的收入。在发布了应用程序的英语版 1.0 后,让客户等上几个月再发布德语版 1.0 似乎也没什么大不了的。但许多客户在部署之前,会一直等待应用程序首个更新的发布。如向原始版本的发布增量添加更新的发布增量,对客户部署的延误将远远超出您的预计。确保应用程序为多语言应用程序有助于避免出现这种情况。
为什么采用 Unicode?
必须要知道,无论使用哪种方法来发布本地化产品,应用程序都必须完全支持 Unicode。通过实现 Unicode 支持,您将不必再操心应用程序运行平台的语言和代码页支持问题。Unicode 是一种 16 位字符的编码,可表示全球各地常用的大多数语言,这明显不同于旧的 8 位字符编码(例如 ANSI,它将语言支持限制为大约 220 个不同字符)。支持 Unicode 的应用程序可处理和显示其中任意一种语言的字符。要了解有关实现 Unicode 和发布将要在 Windows 9x 和 Windows NT 上运行的单一二进制文件的详细信息,请参阅有关使用 Microsoft Layer for Unicode 开发应用程序的文章。.
Windows 2000 通过系统区域设置(从“区域选项”控制面板配置,如图 1 所示)选项来支持传统的 ANSI 应用程序。这意味着基于 ANSI 的应用程序的行为完全取决于系统设置(图 2)。更好的一种方法是全面采用 Unicode 字符编码。
图 1:系统区域设置是通过区域选项控制面板中的设置默认值…按钮来配置的。 |
图 2:在系统区域设置与应用程序语言不匹配的 Windows 2000 系统上运行的 ANSI 本地化消息框。 |
实现多语言用户界面
通常有三种方法可用来实现多语言用户界面二进制:
-
依赖于语言的二进制文件和内置资源
-
一个核心二进制文件和一个国际化资源 DLL
-
一个核心二进制文件和一个与每种目标语言对应的资源 DLL
图 3 展示了使用上述每种方法针对英语、德语和日语的国际化应用程序进行的文件分发。
依赖于语言的二进制文件
一个核心二进制文件和一个国际化资源 DLL
基于语言的附属 DLL
图 3:文件分发比较
以下部分将介绍每种实现的优点、缺点以及技术限制。下面是一个重要的假设:无论用户界面的语言是什么,都会发布一个核心二进制文件并且应用程序的核心功能均相同。这应该是多语言用户界面所有实现中的终极目标。
方法 1:依赖于语言的二进制文件
此传统方法包括编译一个二进制文件,既有源代码又有资源。每种目标语言都需要一个单独的二进制文件。
方法 1(依赖于语言的二进制文件)的优缺点总结 | |
优点 | 缺点 |
|
|
依赖于语言的二进制文件的缺点使得此方法现已被淘汰。以下介绍的两种方法更适合于需要切换 UI 的应用程序。
方法 2:适用于所有语言的一个资源 DLL
此方法的主要思想是将资源从源代码中分离出来,创建一个包含所有目标语言的全部本地化资源的仅资源 DLL。相同资源 ID 的多个副本在不同语言标记下的 RC 文件中定义。在以下示例中,针对法语和英语定义了字符串 ID IDS_ENUMSTRTEST。
// French (France) resources
#ifdef _WIN32LANGUAGE LANG_FRENCH, SUBLANG_FRENCH
#pragma code_page(1252)
#endif //_WIN32
// String Table
STRINGTABLE DISCARDABLE
BEGINIDS_ENUMSTRTEST "Cette phrase est en français...(France)"
END
#endif // French (France) resources
// English (U.S.) resources
#ifdef _WIN32
LANGUAGE LANG_ENGLISH,SUBLANG_ENGLISH_US
#pragma code_page(1252)
#endif _win32
// String TableSTRINGTABLE DISCARDABLE
BEGINIDS_ENUMSTRTEST "This is an English string...(USA)"
END
#endif // English (U.S.) resources
为了在运行时访问资源,因此通过 LoadLibrary API 加载了资源 DLL。然后,可使用 EnumResourceLanguages 来查找给定控件/资源的可用语言列表,使用 FindResourceEx 来确定具有指定类型、名称和语言的资源的位置。要显示给定的语言,接下来只需选择 DLL 中正确的资源即可。可通过重新加载新选择的资源并刷新客户端区域来实现语言的切换。
必须注意,Windows 资源加载程序始终使用默认的当前用户区域设置(线程区域设置会继承当前登录用户的用户区域设置 – 请参阅图 1)。GetThreadLocale 允许查询线程区域设置。在此方法中,加载 API 的预定义资源(LoadIcon、LoadString、LoadCursor…)始终返回与此区域设置相关的资源。例如,在以上资源示例中,如果系统区域设置被设为英语 (0x0409),将无法使用 LoadString 来加载法语资源。但实际并非完全如此:线程区域设置在创建线程时被继承后,将独立于用户区域设置,这意味着在这种情况下,可使用 SetThreadLocale 将线程区域设置改为法语 (0x040C),然后可调用 LoadString 来获取法语字符串。
// if our thread locale is English to start with…
g_hInst = LoadLibrary(_TEXT(“intl_res.dll”));
LoadString(g_hInst, IDS_ENUMSTRTEST,g_szTemp, MAX_STR);
// g_szTemp would then point to the English resources
// changing our thread locale to French.
// Always make sure that French is in fact one of the
// valid languages returned by EnumResourceLanguages()
// Save a copy of the current thread-locale to set back later
Lcid = GetThreadLocale();SetThreadLocale(MAKELCID(0x040c, SORT_DEFAULT));
LoadString(g_hInst, IDS_ENUMSTRTEST, g_szTemp, MAX_STR);
// g_szTemp would then point to the French resources
在此要注意的是,如果线程区域设置与当前选择的用户区域设置相同,系统的资源加载程序将默认使用语言 ID 0(中立)。如果所需的资源被定义为中立语言,则会返回此值。否则将会枚举所有语言资源(以语言 ID 顺序),并返回首个匹配的资源 ID(不论其语言是什么)。
可举例来说明此问题,比如在美国英语和法国法语资源中,用户区域设置被设为日语,则:原始线程区域设置将是日语 (0x0411)。如果找不到字符串 ID 且枚举时英语 (0x0409) 在法语 (0x40C) 之前,则首次调用 LoadString 时会在 0x0411 版本后返回英语资源。接下来,如果用户区域设置首先是法语:原始线程区域设置将是法语 (0x040C)。由于用户区域设置和线程区域设置匹配,因此系统资源加载程序将使用语言 ID 0 并开始枚举资源,然后再次返回英语版本!
对此的最佳解决方法是首先放弃更改线程区域设置。可通过调用 FindResourceEx 从多语言资源文件中手动加载资源。另一种解决方法是在所有者定义的语言标记中定义资源。在以上的 RC 示例中,英语部分定义为:
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
这将防止线程区域设置被切换回美国英语。但是,将资源定义为:
LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL
将保证 SetThreadLocale 调用的成功,因为此语言 ID 没有匹配的用户区域设置,仍可继续使用预定义的资源加载程序 API。
方法 2(适用于所有语言的一个资源 DLL)的优缺点总结 | |
优点 | 缺点 |
|
|
方法 3:每种目标语言一个资源 DLL
这是先前技术的扩展。现在不是在单个 DLL 中包含所有语言,而是针对每种语言创建一个单独的 DLL。Microsoft Office 2000、Microsoft Internet Explorer 5.x 和 Microsoft Windows 2000 使用的都是这种方法。每种产品的实现不同,此方法的名称也各异,但附属 DLL 是这种方法的常用名称。
此方法会再一次用到要通过 LoadLibrary API 加载的资源 DLL。但这一次,必须选择适当的语言 DLL。通常应假设 Windows UI 语言是用户的首选语言,应用程序可通过加载此语言资源来启动。接下来,当用户选择另一种语言时,可释放当前语言并加载新语言。当然,此方法会使用新加载的资源重新创建窗口并初始化对话框。
系统 UI 语言的检测在不同版本的 Windows 中其处理方式也互不相同:
-
在 Windows 2000 中,可利用 GetUserDefaultUILanguage API 来查找当前用户的 UI 语言(请注意,在 Windows 2000 多语言版本中,可以有选择了不同 UI 语言的不同用户)。
-
在 Windows 95、Windows 98 和 Windows 98 SE 中,UI 语言存储在注册表的以下位置:HKCU\Control Panel\Desktop\ResourceLocale。此注册表项将以十六进制形式返回 UI 的语言 ID (LangID),例如,英语是 00000409。
-
在 Windows NT 3.5x 和 Windows NT 4.0 中,由于缺少相关的 API 和一致的注册表项,因此检查操作系统语言的最安全方式是检查 NTDLL.DLL 的版本戳记。此文件的语言与用户界面的语言相同。同样,唯一例外情况是阿拉伯语、希伯来语和泰语,这时版本戳记可帮助您检测启用的操作系统。具体步骤如下:
-
加载 ntdll.dll 文件
-
枚举版本戳记资源中的语言
-
如果有多种语言可用,它将是非美国英语语言
-
如果仅找到美国英语,则可能仍需要处理启用的语言,并且应该对活动代码页进行检查。
-
由于语言检测 API 和注册表项会返回 UI 语言的 LangID,因此对附属 DLL 进行相应命名会非常有用:不要将英语文件命名为 res_eng.dll 或 res_en.dll,而应使用 res409.dll。
以下代码示例显示了如何在 Windows 2000 中检测 UI 语言并加载正确的资源 DLL:
wLangId = GetUserDefaultUILanguage();
_stprintf(g_tcsTemp, _TEXT("res%x.dll"), wLangId);
if((hRes = LoadLibrary(g_tcsTemp)) == NULL)
{
// we didn't find the desired language satellite DLL, lets go with English (default).
hRes = LoadLibrary(_TEXT("res409.dll"));
}
如果未能加载相应的语言 DLL(例如,在应用程序中仅支持操作系统语言的一个子集),唯一的解决方案是假设系统中存在默认/首选语言 DLL。
另一种可能的方法是将英语(或默认语言)资源包括到可执行主文件中并发布其他语言的附属 DLL(方法 1 和 3 的混合)。由于此方法并无实际优点况且英语毕竟只是另一本地化语言,因此不再详细讨论此技术。
方法 3(每种目标语言一个资源 DLL)的优缺点总结 | |
优点 | 缺点 |
|
|
摘要
编写单一二进制代码是实现真正的全球通用产品的第一步,并且有助于降低开发和支持成本。实现多语言用户界面以允许用户在所有支持的语言之间切换,是达成令全球客户满意的下一个逻辑步骤。通过编写识别 Unicode 的代码和创建语言资源的附属 DLL,即可达成这些目标,轻松程度可能会超出您的想像。
术语表
线程区域设置 - 给定线程所处的区域设置。是在创建时从当前用户区域设置继承来的,可以在运行时改为有效的任何区域设置(按线程)。通过调用 NLS API,可使用此区域设置来格式化数字、日期、时间...
系统区域设置 - 并非真正的区域设置。可决定将要支持哪个脚本非 Unicode 应用程序。因此,在应用程序角度来看,它是系统模拟出来的区域设置。系统区域设置的作用范围是整个系统,因此适用于所有用户。更改系统区域设置需要重新启动。
UI 语言 - 操作系统显示其菜单、帮助文件和对话框时所使用的语言。
用户区域设置 - 格式化日期、货币、数字等项目时用户的首选项。用户区域设置是针对每个用户设置的,无需重新启动或注销/登录。