志愿翻译人员对Delphi 2009应用程序进行本地化的流程?

Arg*_*tyr 7 delphi translation localization delphi-2009 internationalization

我有一个免费软件科学应用程序,被近100个国家的数千人使用.许多人提出免费翻译.既然D2009让这更容易(使用集成和外部本地化工具,再加上本机Unicode支持),我想让这种情况发生在几种语言中,并且稳定地增加用户能量将支持的数量.

我想我会发布一个电子表格,其中包含要翻译的字符串列表(数十个但不是数百个),让它们返回,然后用2-3个用户比较同一语言的提交,然后通过共识来解决差异.然后,我将使用集成翻译环境合并本地化,并分发本地化更新.

有没有人将翻译委托给用户?任何陷阱,D2009特定的或其他?

编辑:有没有人比较D2009和dxgettext内置的本地化支持?

mgh*_*hie 6

我从未成为免费软件或开源应用程序的专有本地化工具的朋友.使用dxgettext,GNU gettext的Delphi端口看起来对我来说是一个更好的选择:

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

一旦您拥有多种语言,使用电子表格进行翻译对我来说似乎不是一个可行的解决方案.假设一个新的程序版本增加了2个新的字符串,并改变10串仅略 - 你不会需要新的字符串添加到并强调改变的字符串中的所有数十个电子表格文件,并再次将它们发送到你的翻译?使用dxgettext,您只需将更改的po文件邮寄给所有这些文件.

编辑:

关于dxgettext和库可能存在的问题,有一个有趣的评论.我从未体验过这一点,因为我已经完全停止使用资源字符串.我们课程的最大部分是德语,只有少数是英语或翻译成多种语言.

我们的内部库在所有可翻译字符串周围使用"_(...)".有定义ENGLISH,USEGETTEXT并且是基于每个项目设置的.如果ENGLISHUSEGETTEXT已定义,则将英文文本编译到DCU中,否则将德语文本编译到DCU中.如果USEGETTEXT未定义"_()"被编译为按原样返回其参数的函数,则使用dxgettext转换查找.

  • 我也赞成dxgettext.但是,当你的项目进展顺利时,你可能会发现一些问题:通常,翻译是全局的,这意味着有时翻译适合程序某个地方的短语,可能不适合在不同的地方.对库的支持也不明显:我已经开始为每个库使用"域",但这意味着我不能在那里使用资源字符串,因为那时我将不得不再次全局注册域.但总的来说我真的很喜欢dxgettext. (3认同)