MFC的国际化

Question

最后（经过多年的推迟）是时候用英语以外的其他几种语言本地化我的应用程序了。

第一个挑战是将集成设计到我的C ++ / MFC应用程序中，该应用程序具有许多对话框和无数字符串。 我遇到了两种可能的替代实现：

1. 将本地化资源文件编译并部署为DLL
2. 使用本地化版本提取并替换所有字符串。 对于每种语言，都会有一个XML（或简单文本）文件。

我个人选择第二种选择，因为在我看来它更灵活。 这些变化很多但并不难，而且非常重要的是，XML文件很容易为翻译人员修改。

任何建议都非常感谢。

问候，
Cosmin Unguru
http://www.batchphoto.com/

Answer 1

我用不同的语言做了一些长寿的MFC项目。 我强烈建议使用仅限资源的DLL的第一种方法。

原因：

（1）如果用户安装了XCOPY，他总是在主可执行文件中使用默认语言（英语）。

（2）如果你没有翻译所有内容（例如你的发布时间已经迟到或忘记了一些字符串），Windows资源函数如果使用得当，会自动以默认语言返回资源 - 你不必在你自己。

（3）我个人的意见：（a）XML文件中的换行符，制表符，空格是你的痛苦啊。 （b）合并XML文件更糟糕......

（4）不要忘记编码。 它在XML中没问题，但您的翻译人员可能会使用不合适的编辑器并损坏文件。

现在主要原因是：

（5）您将不得不重新排列许多对话框，因为许多字符串比法语或德语更长，而不是英语。 并制作所有静态，按钮，...更大“以防万一”看起来很糟糕。

另一个提示：花一些钱购买一个导入项目/二进制文件并构建翻译数据库的翻译工具。 这将在第一次发布后摊销。

另一个提示（2）：如果可能，发布一个不包含任何更改但只包含多语言功能的发行版。 如果可能的话，将来也会用英语发布您的产品。 然后在一个步骤（每种语言）中进行翻译并发布其他语言。

Answer 2

我对本地化工作很多的人提出了友好的建议：

1. 抓住GNU Gettext，
2. 将所有字符串标记为_（“英语”）。
3. 使用gettext工具xgettext提取所有字符串并编译dictionalries
4. 使用poedit等优秀工具翻译字符串。
5. 在项目中使用gettext，让您的本地化生活更简单！

您也可以将boost::locale用于相同的目的 - 它使用GNU Gettext词典和方法，但提供了不同且功能更强大的运行时，并且对于Windows开发人员来说它具有非常好的插件 - 它支持MFC需要用于普通Unicode支持的宽字符串。

不要使用资源和其他“翻译”工具，这些工具从语言学的角度来看是完全废话（以及开发人员的观点）。

进一步阅读： http ： //cppcms.sourceforge.net/boost_locale/html/tutorial.html

Answer 3

使用DLL资源库是一种相对简单的操作，它不仅可以管理字符串，还可以管理其他资源。 这是它的主要优势，因为i18n 不仅仅是字符串翻译 。

但是，根据您的需要，基于文本的解决方案可能是一个更好的决策，因为它更容易处理 - 资源脚本比xml文件更复杂，特别是对于普通翻译器。

我建议创建自己的抽象层，比如“LoadLocalizedString”等; 通过这种方式，您可以开始只使用文本文件来实现它，然后在透明的方式中根据需要更改为更复杂的东西 - 使您的软件知道的所有努力仍然有效。

Answer 4

在我们的例子中，我们根据语言进行了不同的对话。 资源文件与开发时实现的多个laguages相同。 您基本上可以在现有资源文件上附加不同的语言。 我希望找到自己的方式有所帮助。

Answer 5

DLL选项通常用于此，因为资源加载过程（例如LoadLibrary）已经编写 - 这意味着您不必编写任何解析/加载代码。 虽然XML更易于编辑，但DLL具有更高的安全性（用户将无法轻松编辑它们）并且将允许开发人员（意味着您）有更多时间处理应用程序逻辑而不是编写语言加载系统。

HMODULE hLangDLL = LoadLibrary("text_en.dll");
// more stuff
TCHAR mybuffer[1024] = {0};
LoadString(hLangDLL, IDS_MYSTRING, mybuffer, 1023);

Answer 6

如果它只是正在改变的字符串，那么我同意XML是这里的前进方向，因为你提出的确切原因。 易于其他人编辑，在运行时易于更改语言等。

（在我看来）你选择选项1的唯一原因是，除了字符串以外的东西是否需要不同的图标。

如果它只是文字？ 我说用XML。