如何翻译（国际化、本地化）应用程序？答案

【问题标题】：How to translate (internationalize, localize) application?如何翻译（国际化、本地化）应用程序？
【发布时间】：2012-08-31 23:20:30
【问题描述】：

我需要在delphi 上翻译一个应用程序。现在俄语界面中的所有字符串。有什么工具可以快速查找、解析字符串常量的所有段落？

人们如何翻译大型应用程序？

【问题讨论】：

在stackoverflow.com/questions/14456480 列出了另外一种自制解决方案

标签： delphi localization internationalization

【解决方案1】：

GetText应该可以，在http://dxgettext.po.dk/documentation/how-to搜索“extract”

如果您只需要翻译 GUI 和源中的 resourcestring，并且不需要翻译 Pascal 源中的内联字符串常量，那么您可以尝试 Delphi 内置方法。然而论坛说 ITE 有问题。但至少这是官方的 Delphi 方式。

如http://www.gunsmoker.ru/2010/06/delphi-ite-integrated-translation.html 的源表中所示，需要使用 ITM 手动准备翻译源

我记得我为 JediVCL 团队翻译了 Polaris 文本 - 所以他们做了一些提取。但我认为他们只是将所有字符 > #127 提取到一个文本文件中 - 没有结构，有常量和 cmets，都在一起。尽管如此，还是有一些组件，尽管我怀疑它是否可以按您需要的方式使用：http://wiki.delphi-jedi.org/wiki/JVCL_Help:TJvTranslator

还有商业工具。但我不知道他们的功能是否会帮助您完成初始提取和翻译任务。当您需要将大型应用程序翻译成多种语言时，它们可能会有很大帮助，但当您需要进行一次性转换时则不会。但也许我错了，如果您愿意，请查看他们的试用版。根据评论，这些套房被认为是最好的商业套房：

TsiLang 套件http://www.tsilang.com/?siteid2=7
科尔日定位器http://devtools.korzh.com/localization-delphi/

【讨论】：

FWIW：dxgettext 似乎没有得到维护。在东京不行。网站上的链接已损坏； svn repo 的链接也坏了。我不认为我会在我今天开始的项目中使用它。

【解决方案2】：

首先，我建议将所有可本地化的字符串常量移动到其单元文件中的资源字符串部分。即

raise Exception.Create('Error: что-то пошло не так (in Russian language)');

将转换为

resourcestring
  rsSomeErrorMessage = 'Error: что-то пошло не так (in Russian language)';
...
raise Exception.Create(rsSomeErrorMessage);

More about Resource Strings.

可以通过使用 corespondent Delphi IDE refactoring command 或使用第三方实用程序（如 ModelMaker Tools）来加速此过程。

然后您可以使用任何可用的本地化工具来翻译甚至国际化您的程序。我推荐my Delphi localizer - 它是免费的。

【讨论】：

Kryvich，你有你的应用程序可用的完整源代码吗？看起来它会做我想做的事。

【解决方案3】：

基本上，你有两种方法

基于资源的本地化工具（Delphi ITE、Multilizer 等）
基于数据库的本地化工具（GetText、TsiLang 等）

前者利用 Windows 资源支持，当应用程序启动时，资源加载可以重定向到存储在 DLL 中的不同资源。优点是可以本地化整个表单，包括图像、颜色、控件大小等，而不仅仅是字符串。此外，无需更改代码。缺点是最终用户本地化通常是不可能的，并且在不重新启动应用程序的情况下更改语言可能会比较棘手。 Microsoft 应用程序，包括 Windows 本身，都使用这种技术。它将适用于任何将字符串正确存储到资源和 dfms 中的 Delphi 库。

后者将字符串存储在外部“数据库”中（甚至可以是文本文件...）。优点通常是用户可以添加/修改翻译，并且更容易即时切换语言。缺点是这种技术更具侵入性（它必须挂钩字符串加载/显示）并且可能需要更改代码，工具通常仅限于字符串本地化并且不提供更广泛的控制（图像，大小等），并且可能不会使用无法正确挂钩的未知控件/库。通常跨平台应用程序使用这种技术，因为并非所有操作系统都支持类似 Windows 的资源。

您应该选择最适合您和您的应用程序的技术。此外，一些工具简化了与外部翻译的协作，而另一些则没有。我更喜欢基于资源的方法，因为它不需要更改代码，也不会将我绑定到给定的库。

【讨论】：

这个答案描述了 l10n。但我相信目前 topicstarter 的主要问题是 i18n。后来他会来到 l10n 阶段，但现在 - “快速查找工具，为字符串常量解析所有通行证” - 他需要 i18n 工具。
OP 应该从一开始就采用最适合其需求的解决方案。如果他使用类似 GetText 的东西并相应地修改他的代码，然后他发现它不符合他的需要，他将不得不恢复更改并重新开始。好的库已经将字符串存储在资源字符串中，因此无需解析它们。他必须解析自己的代码以查找嵌入的字符串并将它们移动到常量或更好的资源字符串。良好的本地化工具能够解析文件以找出需要本地化的字符串。一个常见的大错误是相信翻译字符串就足够了。
因为他提到的图书馆有俄语字符串，而不是英语 - 我的结论是它从来不是为 i18n 设计的，也不是你所说的“好图书馆”:-)
当您从英语转到俄语时，我可以说出两个常见的障碍。 1：GUI 应按比例缩放，因为通常俄语单词较长。 2：英语只有单复数形式：1 apple or many apples。任何名词的规则几乎都是一样的。在俄语中，这里会有两个复数词尾，并且对于不同的词类它们会有所不同。此外，当您使用参数化字符串（如 Format functin）时，您必须重新排序参数。我不记得西班牙语了，但它比俄语有更多的动词结尾，但这与时态有关，几乎不会受到 l10n 的影响
真的没有必要改变 Format() 参数 - 只需在格式字符串中使用正确的索引（应该存储在资源字符串中......）。无论如何，您不必实现自动翻译 - 所以复数或动词不是问题，特别是如果您不尝试对应用程序的不同部分使用相同的条目。保留不同的字符串标识符，除非您确定它们完全相同。这也是为什么让您看到上下文进行翻译的工具比那些只为您提供上下文之外的字符串列表的工具更好的原因。

【解决方案4】：

我们正在使用 dxgettext（用于 Delphi 和 C++ Builder 的 GNUGettext）和 Gorm（来自同一作者）。请注意，大多数工具都要求您使用英语作为主要语言并仅从该语言进行翻译。 dxgettext 允许其他语言，但肯定会有未知的问题。做好准备，将大型应用程序国际化将比您当前想象的要多。

【讨论】：