设计字符串本地化的最佳方式 [英] Best way to design for localization of strings

问题描述

这是一个普遍的问题，开放的意见。我一直在想出一个好的方式来设计一个Windows MFC应用程序和相关实用程序的字符串资源的本地化。我的愿望清单是：

This is kinda a general question, open for opinions. I've been trying to come up with a good way to design for localization of string resources for a Windows MFC application and related utilities. My wishlist is:

• 必须在代码中保留字符串字面值（而不是用宏#define resource ID替换）仍然可读。


• 必须允许本地化的字符串资源（duh）


• 不得强加额外的运行时环境限制（例如：


• 应该是可调试的


• 应生成可通过常用工具编辑的资源文件（即：通用格式）


• 不应使用复制/粘贴注释块来保留代码中的文字字符串，非同步的可能性


• 很高兴允许静态（编译时）检查每个注释字符串是否在资源文件中


• 允许跨语言资源字符串池（对于各种语言的组件，例如：native C ++和.NET）很好。

• Must preserve string literals in code (as opposed to replacing with macro #define resource ID's), so that the messages are still readable inline
• Must allow localized string resources (duh)
• Must not impose additional run-time environment restrictions (eg: dependency on .NET, etc.)
• Should have minimal obtrusion into existing code (the less modification the better)
• Should be debuggable
• Should generate resource files which are editable by common tools (ie: common format)
• Should not use copy/paste comment blocks to preserve literal strings in code, or anything else which creates the potential for de-synchronization
• Would be nice to allow static (compile-time) checking that every "notated" string is in the resource file(s)
• Would be nice to allow cross-language resource string pooling (for components in various languages, eg: native C++ and .NET)

除了静态检查，我有一种方法在一定程度上满足了我所有的愿望清单，但我不得不开发一些自定义代码来实现它（和它有限制）。我想知道是否有人以特别好的方式解决了这个问题。

I have a way which fulfills all my wishlist to some extent except for static checking, but I have had to develop a bit of custom code to achieve it (and it has limitations). I'm wondering if anyone has solved this problem in a particularly good way.

编辑：
我目前的解决方案如下：

The solution I currently have looks like this:

ShowMessage( RESTRING( _T("Some string") ) );
ShowMessage( RESTRING( _T("Some string with variable %1"), sNonTranslatedStringVariable ) );

然后我有一个自定义的实用程序来解析从'RESTRING'块中的字符串，转换为用于本地化的.resx文件，以及单独的C＃COM对象，用于通过回退从本地化资源文件加载它们。如果C＃对象不可用（或不能加载），我回退到代码中的字符串。宏扩展为调用COM对象并执行格式化等的模板类。

I then have a custom utility to parse out the strings from within the 'RESTRING' blocks and put them into a .resx file for localization, and a separate C# COM object to load them from localized resource files with fallback. If the C# object is not available (or cannot load), I fallback to the string in the code. The macro expands to a template class which calls the COM object and does the formatting, etc.

无论如何，我想添加我现在参考。

Anyway, I thought it would be useful to add what I have now for reference.

推荐答案

我们使用英语字符串作为ID。

We use the English string as the ID.

如果从国际资源对象（从安装的I18N dll加载）失败，我们默认为ID字符串。

If it fails the look up from the international resource object (loaded from the I18N dll installed) then we default to the ID string.

代码看起来像：

doAction(I18N.get("Press OK to continue"));

作为构建过程的一部分，我们有一个perl脚本来解析字符串常量的所有源。它构建应用程序中所有字符串的临时文件，然后将它们与每个本地中的资源字符串进行比较，以查看它们是否存在。任何缺少的字符串都会生成一封发送给相应翻译小组的电子邮件。

As part of the build processes we have a perl script that parses all source for string constants. It builds a temp file of all strings in the application and then compares these against the resource strings in each local to see if they exists. Any missing strings generates an e-mail to the appropriate translation team.

我们可以为每个本地用户分配多个dll。 dll的名称基于RFC 3066

language [_territory] ​​[。codeset] [@ modifier]

We can have multiple dll for each local. The name of the dll is based on RFC 3066
language[_territory][.codeset][@modifier]

我们尝试并提取区域设置

We try and extract the locale from the machine and be as specific as possible when loading the I18N dll but fallback to less specific local variations if the more specific version is not present.

示例：

在英国：如果本地是 en_GB.UTF-8

（我使用的术语dll松散不在特定Windows感觉）。

In the UK: If the local was en_GB.UTF-8
(I use the term dll loosely not in the specific windows sense).

首先查找 I18N.en_GB.UTF-8 dll。如果此dll不存在，则可返回 I18N.en_GB 。如果此dll不存在，则可以追溯到 I18N.en 如果此dll不存在，则 I18N.default

First look for the I18N.en_GB.UTF-8 dll. If this dll does not exist fall back to I18N.en_GB. If this dll does not exist fall back to I18N.en If this dll does not exist fall beck to I18N.default

此规则的唯一例外是：
简体中文（zh_CN），其中备用版本是美国英语（en_US）。如果机器不支持简体中文，则不太可能支持全中文。

The only exception to this rule is: Simplified Chinese (zh_CN) where the fallback is US English (en_US). If the machine does not support simplified Chinese then it is unlikely to support full Chinese.

这篇关于设计字符串本地化的最佳方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！