我想我会分发一个电子表格,其中包含要翻译的字符串列表(数十个但不是数百个),让它们返回它,并用2-3个用户比较相同语言的提交,然后通过共识来解决差异.然后,我将使用集成翻译环境合并本地化,并分发本地化更新.
有没有人将翻译委托给用户？任何陷阱,D2009特定或其他？
编辑：有没有人比较D2009和dxgettext内置的本地化支持？
解决方法
>集成到程序中(甚至比它的开发晚得多)很容易.
>可翻译字符串的提取可以通过命令行程序完成,因此很容易引入自动构建.
>只需创建具有正确结构的新目录,将空翻译文件复制到其中,然后开始翻译字符串,即可添加新翻译.这是每个用户可以为自己做的事情,没有必要让原作者参与创建新的翻译.此过程也立即得到满足 – 一旦重新启动程序,将立即显示新的翻译.
>更改现有翻译比创建新翻译更容易.因此,如果用户发现拼写或其他错误或需要改进翻译,他们可以轻松地纠正它们并将更改发送给作者.
>新的程序版本使用旧的翻译,系统非常优雅地降级 – 新的和未翻译的字符串只是未经修改地显示.
>只能使用记事本进行翻译,但也有一些免费工具可用于创建和管理翻译文件;查看dxgettext页面上的链接.它们本身就是本地化的,并且在电子表格方面也有一些优势：
>可以显示源代码中字符串的位置(当然,仅对开源应用程序有意义).
>显示已翻译字符串的百分比.
>也会突出显示对已翻译字符串的修改.
>整个系统已经成熟并且面向未来 – 我已经将dxgettext用于Delphi 4程序,并且Delphi 2009甚至不需要进行任何更改 – 翻译文件一直是UTF-8编码的.
一旦您拥有多种语言,使用电子表格进行翻译对我来说似乎不是一个可行的解决方案.假设一个新程序版本添加了2个新字符串并且仅稍微更改了10个字符串 – 您是否需要添加新字符串并突出显示所有数十个电子表格文件中已更改的字符串并将它们再次发送给您的翻译人员？使用dxgettext,您只需将更改的po文件邮寄给所有这些文件.
编辑：
关于dxgettext和库可能存在的问题,有一个有趣的评论.我从未体验过这一点,因为我已经完全停止使用资源字符串.我们课程的最大部分是德语,只有少数是英语或翻译成多种语言.
我们的内部库在所有可翻译字符串周围使用“_(…)”.有基于每个项目设置的ENGLISH和USEGETTEXT定义.如果定义了ENGLISH或USEGETTEXT,则将英文文本编译到DCU中,否则将德语文本编译到DCU中.如果未定义USEGETTEXT,则“_()”被编译为按原样返回其参数的函数,否则使用dxgettext转换查找.