志愿者翻译Delphi2009应用程序的本地化过程?

我从来不是免费软件或开源应用程序专有本地化工具的朋友。使用 dxgettext ,Delphi端口 GNU gettext 我觉得这是个更好的选择:

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

如果你有多种语言,使用电子表格进行翻译对我来说似乎不是一个可行的解决方案。假设一个新的程序版本增加了2个新字符串,只稍微改变了10个字符串——难道不需要在所有几十个电子表格文件中添加新字符串并突出显示更改的字符串,然后再将它们发送给翻译人员吗?使用dxgetext,您只需将更改后的po文件发送给所有这些文件。

编辑:

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

我们的内部库在所有可翻译字符串周围使用“(…)”。有一些定义 ENGLISH 和 USEGETTEXT 按每个项目设置。如果 英语 或 UE文本 定义后,英语文本编译到DCU中,否则德语文本编译到DCU中。如果 UE文本 未定义“u()”编译为按原样返回其参数的函数,否则将使用dxGetText转换查找。

我有。。。可能会有一些挑战。

• 字符串本身并不重要,它需要上下文。
• 必然地,同一个字符串可能需要有多个转换。
• 屏幕房地产:注意根据语言长度的不同,例如,法语往往比英语更冗长。
• 除非你精通某种语言,否则你将无法评估这些差异。

我已经用过 TsiLang Translation Suite 使最终用户能够翻译。我修改了代码以允许加密,这样如果有人做得很好,他们就可以保护自己的名字不受翻译文件的影响,但总的来说,他们的想法是,人们可以共享他们的翻译,并添加/编辑他们想要的任何小部分。考虑到这一切都发生在应用程序中,并且具有即时的可视性,它工作得非常好。

正如您所提到的,D2009附带了本地化工具。为什么不简单地使用它们呢?afaik您可以分发外部翻译管理器(etm.exe)。你还需要什么吗?

此外,本地化不仅仅是翻译文本。ETM还支持.dfm资源的翻译。

为了完整性,这里还有一个Delphi本地化工具,叫做 Delphi Localizer 我最近发现它的设计和抛光都很好。除政府项目外,该工具可免费用于商业用途(不清楚为什么会出现例外)。

我以前使用过tsilang翻译套件,现在正在使用devexpress vcl附带的本地化工具进行另一个项目。后者与它们的组件以及第三方组件完美集成。