delphi - 由志愿翻译人员本地化 Delphi 2009 应用程序的流程？

Question

我有一个免费科学应用程序，近 100 个国家/地区的数千人正在使用该应用程序。许多人主动提出免费翻译。现在，D2009 使这一切变得更加容易(通过集成和外部本地化工具，以及 native Unicode 支持)，我希望在几种语言中实现这一点，并稳步添加尽可能多的用户精力支持的语言。

我想我会分发一个电子表格，其中包含要翻译的字符串列表(数十个但不是数百个)，让他们返回它，并比较 2-3 个用户以相同语言提交的内容，然后努力解决分歧通过协商一致。然后，我将使用集成翻译环境合并本地化内容，并分发本地化更新。

有人将翻译委托(delegate)给用户吗？有任何陷阱，D2009 特有的还是其他的？

编辑:有人比较过 D2009 和 dxgettext 中内置的本地化支持吗？

Answer 1

我从来都不喜欢免费软件或开源应用程序的专有本地化工具。使用dxgettext ，德尔福端口 GNU gettext对我来说看起来是一个更好的选择:

• 集成到程序中(甚至比其开发晚得多)很容易。
• 可翻译字符串的提取可以通过命令行程序完成，因此可以轻松引入自动构建中。
• 只需创建一个具有正确结构的新目录，将空翻译文件复制到其中，然后开始翻译字符串即可添加新翻译。这是每个用户都可以自己做的事情，无需让原作者参与创建新的翻译。这个过程还可以带来即时的满足感 - 一旦程序重新启动，新的翻译就会立即显示。
• 更改现有翻译甚至比创建新翻译更容易。因此，如果用户发现拼写或其他错误或需要改进翻译，他们可以轻松更正它们并将更改发送给作者。
• 新的程序版本可以使用旧的翻译，系统可以非常优雅地降级 - 新的和未翻译的字符串只是显示为未修改。
• 仅使用记事本即可进行翻译，但也有多种免费工具可用于创建和管理翻译文件；请参阅 dxgettext 页面上的链接。它们本身已本地化，并且比电子表格还有一些优势:
  • 可以显示字符串在源代码中的位置(当然，仅对开源应用有意义)。
  • 显示已翻译字符串的百分比。
  • 对已翻译字符串的修改也会突出显示。
• 整个系统成熟且面向 future - 我已经在 Delphi 4 程序中使用了 dxgettext，即使对于 Delphi 2009 也不需要进行任何更改 - 翻译文件一直是 UTF-8 编码。

一旦您拥有多种语言，使用电子表格进行翻译对我来说似乎不是一个可行的解决方案。假设一个新的程序版本添加了 2 个新字符串并仅稍微更改了 10 个字符串 - 您是否不需要在所有几十个电子表格文件中添加新字符串并突出显示更改的字符串，然后将它们再次发送给翻译人员？使用 dxgettext，您只需将更改后的 po 文件邮寄给所有人。

编辑:

有一个关于 dxgettext 和库可能存在的问题的有趣评论。我从未经历过这种情况，因为我已经完全停止使用资源字符串。我们的节目大部分是德语，只有少数是英语或翻译成多种语言。

我们的内部库在所有可翻译字符串周围使用“_(...)”。有针对每个项目设置的定义 ENGLISH 和 USEGETTEXT。如果定义了 ENGLISH 或 USEGETTEXT，则将英语文本编译到 DCU 中，否则将德语文本编译到 DCU 中。如果 USEGETTEXT 未定义，“_()”将编译为按原样返回其参数的函数，否则使用 dxgettext 翻译查找。