我从来都不是免费软件或开源应用程序的专有本地化工具的朋友。使用dxgettext,GNU gettext的 Delphi 端口对我来说似乎是一个更好的选择:
- 集成到程序中(甚至比它的开发晚得多)很容易。
- 可翻译字符串的提取可以通过命令行程序完成,因此很容易引入到自动构建中。
- 只需创建一个具有正确结构的新目录,将空的翻译文件复制到其中,然后开始翻译字符串,就可以添加新的翻译。这是每个用户都可以自己做的事情,不需要原作者参与创建新的翻译。这个过程也有即时的满足感——一旦程序重新启动,新的翻译就会立即显示出来。
- 更改现有翻译比创建新翻译更容易。因此,如果用户发现拼写或其他错误或需要改进翻译,他们可以轻松地更正它们并将更改发送给作者。
- 新的程序版本与旧的翻译一起工作,系统非常优雅地降级 - 新的和未翻译的字符串简单地显示为未修改。
- 只能使用记事本进行翻译,但也有一些免费工具可用于创建和管理翻译文件;请参阅 dxgettext 页面上的链接。它们本身是本地化的,并且与电子表格相比也有一些优势:
- 可以显示源代码中字符串的位置(当然,仅对开源应用程序有意义)。
- 显示已翻译字符串的百分比。
- 对已翻译字符串的修改也会突出显示。
- 整个系统成熟且面向未来——我在 Delphi 4 程序中使用了 dxgettext,甚至对于 Delphi 2009 也不应该进行任何更改——翻译文件一直是 UTF-8 编码的。
一旦您拥有多种语言,使用电子表格进行翻译对我来说似乎不是一个可行的解决方案。假设一个新的程序版本添加了 2 个新字符串并仅稍微更改了 10 个字符串 - 您是否不需要在所有几十个电子表格文件中添加新字符串并突出显示更改的字符串,然后再次将它们发送给您的翻译人员?使用 dxgettext 您只需将更改后的 po 文件邮寄给所有人。
编辑:
关于 dxgettext 和库可能存在的问题,有一个有趣的评论。我从来没有遇到过这种情况,因为我已经完全停止使用资源字符串了。我们的课程大部分是德语,只有少数是英语或翻译成多种语言。
我们的内部库在所有可翻译字符串周围使用“_(...)”。有定义ENGLISH
,并且USEGETTEXT
是在每个项目的基础上设置的。如果定义ENGLISH
或USEGETTEXT
,则将英文文本编译到 DCU 中,否则将德语文本编译到 DCU 中。如果USEGETTEXT
未定义“_()”被编译为按原样返回其参数的函数,否则使用 dxgettext 翻译查找。