VC++ 10 MFC：进行本地化的正确方法是什么
我是一名 .NET 人员，必须在 MFC 应用程序上做一些工作。该应用程序是一个 VS2008 MFC 可执行文件，我已将其转换为 VS2010。最初的开发人员通过在应用程序命令行上指定包含键值对的 .txt 文件的名称来进行本地化。已安装的可执行文件快捷方式会根据安装应用程序的国家/地区指定不同的 .txt 文件。如果您直接运行 .exe，这当然不起作用。对我来说，这似乎是一种奇怪的做事方式。
我想以正确的 MFC 方式执行此操作，但我很难在 Google 上找到明确的答案。我的理解是 .rc 文件中的字符串表应该用于此本地化？这是 MFC 当前的最佳实践吗？
关于字符串表，我读到实践是为不同的语言创建多个字符串表。 MFC应用程序如何选择使用哪种语言？它是基于机器当前的语言设置还是我可以控制它（我们可能希望由我们也在构建的 Wix .msi 安装程序指定语言）？
我还读到，在 MFC 应用程序中嵌入所有资源已经不再受欢迎，现在您应该编译单独的资源 .dll？这是真的吗？我要调查一下如何做到这一点...
最后，我是否必须做一些特殊的事情才能让 MFC 支持 Unicode，或者默认情况下 MFC 是 Unicode 吗？
谢谢
I am a .NET guy who is having to do some work on an MFC app. The app is a VS2008 MFC executable which I have converted to VS2010. The original developers did localisation by specifying the name of a .txt file with key value pairs in it on the applications command line. Installed shortcuts to the executable specify a different .txt file depending on which country the app is being installed in. This of course does not work if you just run the .exe directly. This seems like a weird way to do things to me.
I want to do this the propper MFC way, but I am having difficulty finding definitive answers on Google. My understanding is that the String Table in the .rc file should be used for this localisation? Is this the current best practice for MFC?
With respect to the String Table I have read that the practice is to create multiple string tables each for a different language. How do MFC applications choose which language to use? Is it based on the machines current language settings or can I control this (it may be that we want the language to be specified by the Wix .msi installer we are also building)?
I have also read that embedding all resource inside an MFC application has fallen out of favor and that now you should compile seperate resource .dlls? Is this is true ill investigate how to do it...
Finally, do I have to do something special to get MFC to support Unicode or is MFC Unicode by default?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个想法是所有可本地化的项目都应该存储在资源中。标准 UI 对象（例如菜单和对话框）会自动存储在其中（资源），但字符串文字（例如：错误消息、消息框提示等）等项目应从源代码提取到字符串表。我的这篇简短的 codeproject 文章 演示了如何轻松地从字符串表中提取字符串你的代码。
注意：您的资源脚本 (.rc) 中应该只有一个字符串表。
从那时起，您可以转换资源并创建资源 DLL（也称为卫星 DLL）。这个想法是为每种语言保留 .rc 文件的不同副本。每个翻译都被编译成一个无代码 DLL，充当资源的容器。
我的另一篇 codeproject 文章可让您根据系统设置轻松加载资源 DLL 或用户首选项：代码会在资源 DLL 中查找最适合用户设置的可用语言（基于用户的 UI 语言和区域设置）。该代码还可以让您轻松构建包含所有可用语言的菜单。这样，您的用户就可以覆盖默认选择。
免责声明：我的广告如下。请随意跳过:-)
关于资源的翻译、翻译的管理和资源 DLL 的创建，您可能需要查看 应用翻译器。
AD 结束 :-)
关于 Unicode，MFC 附带了 ANSI 和 Unicode 版本的代码。您可以选择构建 ANSI 还是 Unicode 应用程序：只需在项目设置的第一页中进行选择即可。当然，如果您是从头开始，那么您绝对应该使用 Unicode。但是，如果遗留原因迫使您保留 ANSI/MBCS，请不要太担心：它不会阻止您本地化您的应用程序。
The idea is that all localizable items should be stored in resources. Standard UI objects such as menus and dialogs are automatically stored in there (resources) for you but items such as string literals (eg: error messages, messagebox prompts,...) should be pulled from source code to the string table. This short codeproject article of mine demonstrates how to easily pull strings from the string table in your code.
Note: You should have only one string table in your resource script (.rc).
From there on, you can translate your resources and create resource DLLs (aka satellite DLLs). The idea is that you keep a different copy of the .rc file(s) for each language. Each translation is compiled into a codeless DLL that acts as a container for the resources.
This other codeproject article of mine lets you easily load resource DLLs according to system settings or user preferences: The code looks among your resource DLLs which available language best matches user settings (based on user's UI language and regional settings). The code also lets you easily build a menu with all available languages. That way, your user can override the default choice.
DISCLAIMER: My ad follows. Feel free to skip :-)
Regarding the translation of resources, the management of translations and the creation of resource DLLs, you may want to check out appTranslator.
END OF AD :-)
Regarding Unicode, MFC ships with ANSI and Unicode versions of the code. It's up to you to choose if you want to build an ANSI or a Unicode app: Just make your pick in the first page of project settings. Of course, if you are startgin from scratch, you should definitely go Unicode. But if legacy reasons force you to stay ANSI/MBCS, don't worry to much: It won't prevent you from localizing your app.
几年前，当我必须在 MFC 中使用多种语言时，我们使用单独的资源 DLL。您所需要做的就是调用一次 switch 来处理资源函数将使用的资源，从那时起一切都是自动的。
您需要做的不仅仅是更改琴弦。特别是对话框中会有字符串，如果这些字符串在翻译后变得太长，您可能需要更改布局。
Years ago when I had to work with multiple languages in MFC, we used separate resource DLLs. All you need do is make one call to switch which handle the resource functions would use and all was automatic from that point forward.
You need to do more than just change the strings. Dialogs in particular will have strings inside of them, and you may need to change the layout if those strings become too long after translation.