志愿翻译员本地化Delphi 2009应用程序的流程是什么？

Question

志愿翻译员本地化Delphi 2009应用程序的流程是什么？

delphilocalizationinternationalizationdelphi-2009translation

7

我有一个免费的科学应用程序，被近100个国家的数千人使用。很多人愿意免费翻译。现在，由于D2009具备了集成和外部本地化工具以及本地Unicode支持，我想为几种语言实现本地化，并随着用户的支持逐步添加更多语言。

我考虑分发一个包含需要翻译的字符串列表（几十个而不是几百个）的电子表格，让他们返回并比较同一语言的2-3个用户的提交，然后通过共识解决差异。然后，我将使用集成的翻译环境来整合本地化，并分发本地化更新。

有人将翻译委托给用户吗？有任何陷阱，特别是与D2009相关的或其他方面的？

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

- Argalatyr

5个回答

4

我有一个需要翻译的问题，与IT技术有关。以下是一些需要注意的挑战：

一个字符串本身并没有太多意义，它需要上下文。
同样一个字符串可能需要有多个翻译。
屏幕空间：要注意不同语言的长度差异，例如，法语往往比英语更冗长。
除非你精通某种语言，否则你无法评估其中的差异。

- Francesca

1

谢谢 - 这些很有用。由于大多数字符串都带有解释性提示文本，并且这些提示文本也需要翻译，因此我考虑在电子表格的成对列中提供它们。一箭双雕，不是吗？ - Argalatyr

2

我使用了TsiLang翻译套件来启用最终用户进行翻译。我修改了代码以允许加密，这样如果有人做得非常好，他们可以保护自己的名字不被翻译文件泄露，但总体上的想法是人们可以分享他们的翻译，并添加/编辑任何他们希望的小部分。由于所有操作都在应用程序内完成，并且具有即时可见性，因此它运作得非常顺畅。

- mj2008

2

正如您所提到的，D2009自带本地化工具。为什么不直接使用它们呢？据我所知，您可以分发外部翻译管理器（etm.exe）。您需要其他什么吗？

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

- Ondrej Kelle

我很想知道别人对此的看法。我被D2009工具所吸引。关于dxgettext有一些优点，但听听那些尝试过两者的人的意见会很有帮助。 - Argalatyr

@Argalatyr：我尝试过ETM，但我认为它非常糟糕。我永远不会将其提供给非程序员进行翻译，因为可翻译的字符串被所有（甚至非字符串）属性淹没了。如果一些好心人将alClient翻译成alKlient怎么办？UI也不适合翻译，它更多地面向项目管理而不是文本编辑。并不是因为某些东西在Delphi盒子里就一定很好。 - mghie

@TOndrej：调整所有DFM以进行翻译的目的仅是因为VCL没有适当的动态控件布局方式来适应不断变化的文本宽度。这使得开发人员/翻译人员承担了负担，而代码本应能够自行处理。 - mghie

@mghie：在某些情况下，您还必须考虑非文本的区域特定资源，例如图像、声音等。即使使用动态布局，仅文本是不足够的。 - Ondrej Kelle

一个有效的观点。我还没有处理过图像、声音和其他类似资源，但是区域设置子目录也是放置它们的完美位置 - 我认为这是 dxgettext 方法的另一个优点。 - mghie

1

为了完整性，这里有另一个Delphi本地化工具Delphi Localizer，我最近发现它看起来设计得非常好且精致。该工具可用于商业用途，但政府项目除外（不太确定为什么会有这个例外）。

顺带一提，我过去使用过TsiLang翻译套件，并且目前正在使用DevExpress VCL附带的本地化工具进行另一个项目。后者与他们的组件以及第三方组件很好地集成在一起。

- David Taylor

不兼容Delphi 2009，遗憾，看起来很好用且更易于使用的dxGetText。 - none

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mghie · Accepted Answer

我从来不喜欢为免费软件或开源应用程序使用专有的本地化工具。对我来说，使用dxgettext，这是GNU gettext的Delphi版本，看起来是一个更好的选择:

即使在程序开发后很久，将其集成到程序中也很容易。
可通过命令行程序提取可翻译的字符串，因此很容易引入自动化构建。
只需创建具有正确结构的新目录，将空白翻译文件复制到其中，并开始翻译字符串，就可以简单地添加新的翻译。每个用户都可以为自己完成此操作，无需涉及原始作者创建新的翻译。此过程还具有即时满足感-一旦重新启动程序，新的翻译立即显示。
更改现有翻译甚至比创建新翻译更容易。因此，如果用户发现拼写或其他错误或需要改进翻译，则可以轻松纠正它们并将更改发送给作者。
新的程序版本与旧的翻译一起工作，系统会非常优雅地降级-新的和未翻译的字符串仅以未修改的形式显示。
翻译可以使用记事本进行，但也有几个免费的工具可用于创建和管理翻译文件；请参见dxgettext页面上的链接。它们本身也是本地化的，并且与电子表格相比具有一些优点：
- 可以显示源代码中字符串的位置（当然，仅适用于开源应用程序）。
- 显示已翻译字符串的百分比。
- 已翻译字符串的修改也会被突出显示。
整个系统都是成熟且具备未来性的-我已经将dxgettext用于Delphi 4程序，甚至对于Delphi 2009也不需要进行任何更改-翻译文件始终以UTF-8编码。

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

编辑：

有一个有关dxgettext和库存在问题上的有趣评论。我从未经历过这种情况，因为我已经完全停止使用资源字符串。我们程序的大部分都是德语，只有少数是英语或翻译成多种语言。

我们的内部库在所有可翻译的字符串周围使用“_（...）”。有定义ENGLISH和USEGETTEXT，这些定义是按项目设置的。如果定义了ENGLISH或USEGETTEXT，则英文文本将编译到DCU中，否则德文文本将编译到DCU中。如果未定义USEGETTEXT，“_（）”将被编译为返回其参数的函数，否则将使用dxgettext翻译查找。