志愿者翻译Delphi 2009应用程序的本地化过程？

Question

我有一个免费的科学应用程序，被近100个国家的数千人使用。许多人提供免费翻译。现在D2009让这件事变得更容易了(通过集成的和外部的本地化工具，再加上本机Unicode支持)，我想让几种语言都能做到这一点，并稳定地增加尽可能多的用户精力支持。

我在想，我会分发一个电子表格，里面有需要翻译的字符串列表(几十个，而不是几百个)，让他们返回它，然后比较2-3个用户以相同语言提交的内容，然后通过共识来解决差异。然后，我将使用集成翻译环境合并本地化，并分发本地化更新。

有没有人委托翻译给用户？有什么问题吗，是D2009特定的还是其他的？

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

Answer 1

我从来不是免费软件或开源应用程序的专有本地化工具的朋友。使用dxgettext，GNU gettext的Delphi移植对我来说是一个更好的选择：

• 集成到程序中(甚至比它的开发时间晚得多)是可翻译字符串的easy.
• Extraction，可以由命令行程序完成，因此很容易引入到自动构建中。
• 只需创建一个具有正确结构的新目录，将空翻译文件复制到其中，然后开始翻译字符串，就可以添加新的翻译。这是每个用户都可以为自己做的事情，不需要让原作者参与创建新的翻译。这个过程也有即时的满足感-一旦程序重新启动，新的翻译就会显示immediately.
• Changing现有的翻译甚至比创建新的翻译更容易。因此，如果用户在翻译中发现拼写或其他错误或需要改进，他们可以很容易地更正它们，并将更改发送给作者。
• 新程序版本与旧翻译一起工作，系统降级非常优雅-新的和未翻译的字符串只是显示unmodified.
• Translations可以使用记事本，但也有几个创建和管理翻译文件的免费工具；请参阅dxgettext页面上的链接。它们本身就是本地化的，并且与电子表格相比也有一些优势:突出显示源代码中字符串的位置(当然，这只对开源应用程序有意义)。too.

shown.

• Modifications of
• string is

​

• 整个系统是成熟的，面向未来的-我已经为Delphi4程序使用了dxgettext，对于Delphi2009应该没有必要改变-翻译文件一直是UTF-8编码的。

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

编辑：

关于dxgettext和库可能存在的问题，有一个有趣的评论。我从来没有经历过这种情况，因为我已经完全停止使用资源字符串。我们的大部分程序都是用德语编写的，只有很少一部分是用英语编写的，或者被翻译成了几种语言。

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

Answer 2

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

一个字符串本身并不意味着什么，它需要一个context.

• corollary，相同的字符串可能需要多个translation.

• screen空间:注意长度的变化取决于语言，例如，法语往往比英语更冗长(
• )。除非你精通一门特定的语言，否则你将无法评估discrepancies.

Answer 3

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