VC++；10 MFC：本地化的正确方法是什么

我是一个.NET的家伙，必须在MFC应用程序上做一些工作。该应用程序是一个VS2008 MFC可执行文件，我已将其转换为VS2010。最初的开发人员通过在应用程序命令行上指定包含键值对的.txt文件名来进行本地化。可执行文件的已安装快捷方式根据安装应用的国家/地区指定不同的.txt文件。如果直接运行.exe，这当然不起作用。这对我来说似乎是一种奇怪的方式

我想用propper MFC的方式来做这件事，但是我很难在谷歌上找到明确的答案。我的理解是.rc文件中的字符串表应该用于此本地化？这是MFC当前的最佳实践吗

关于字符串表，我读到实践是为不同的语言创建多个字符串表。MFC应用程序如何选择使用哪种语言？它是基于机器当前的语言设置还是我可以控制它（可能是我们希望由我们正在构建的Wix.msi安装程序指定语言）

我还读到，在MFC应用程序中嵌入所有资源已经不再受欢迎，现在您应该编译单独的resource.dll？这是真的吗？我会调查怎么做

最后，我是否需要做一些特殊的事情来让MFC支持Unicode，或者默认情况下MFC是Unicode

---

谢谢

几年前，当我不得不在MFC中使用多种语言时，我们使用了单独的资源DLL。您所需要做的就是调用switch来处理将使用的资源函数，从那时起，所有这些都是自动的

---

您需要做的不仅仅是更改字符串。对话框中尤其会有字符串，如果这些字符串在翻译后变得太长，您可能需要更改布局。

我们的想法是所有可本地化的项目都应该存储在资源中。菜单和对话框等标准UI对象会自动存储在其中（参考资料），但字符串文字（例如：错误消息、messagebox提示等）等项应该从源代码中提取到字符串表中。我的这篇短文演示了如何在代码中轻松地从字符串表中提取字符串

注意：资源脚本（.rc）中应该只有一个字符串表

从那时起，您可以转换资源并创建资源DLL（也称为卫星DLL）。这样做的目的是为每种语言保留一个不同的.rc文件副本。每个翻译都被编译成一个无代码DLL，作为资源的容器

我的代码允许您根据系统设置或用户首选项轻松加载资源DLL：代码在资源DLL中查找与用户设置最匹配的可用语言（基于用户的UI语言和区域设置）。该代码还允许您轻松构建包含所有可用语言的菜单。这样，用户就可以覆盖默认选择

免责声明：我的广告如下。请随意跳过：-）

关于资源的翻译、翻译的管理和资源DLL的创建，您可能需要签出

广告结束：-）

---

关于Unicode，MFC附带ANSI和Unicode版本的代码。您可以选择是构建ANSI应用程序还是Unicode应用程序：只需在项目设置的第一页进行选择。当然，如果你是从零开始的，你肯定应该使用Unicode。但是，如果传统原因迫使您保留ANSI/MBCS，不要太担心：这不会阻止您对应用程序进行本地化。

MFC和Unicode是独立的，您可以使用其中一个而不用另一个。如果您使用向导构建项目，Unicode将是选项之一（应为默认设置）。否则，您可以在项目设置中找到它。另一篇CP文章：那么，MFC不提供将字符串与对话框分开的方法？@OneWorld它不仅仅是MFC，用于创建对话框的Windows API依赖于带有嵌入字符串的对话框资源。