Delphi 2009应用程序由志愿者翻译器进行本地化的过程？ [英] Process for localization of Delphi 2009 app by volunteer translators?

问题描述

我有一个免费的科学应用程序，被近千个国家的数千人使用。许多人提出免费翻译。现在，D2009使这更简单（通过集成和外部本地化工具，加上本机Unicode支持），我想使这种情况发生在几种语言中，并稳步增加用户能量将支持的数量。

我想我将分发一个包含字符串列表（几十个但不是数百个）的电子表格来翻译，并将其返回，并将来自2-3个用户的相同语言的提交进行比较然后以协商一致方式解决差异。然后，我将使用集成翻译环境并入本地化，并分发本地化的更新。

有没有人将翻译委托给用户？有没有人比较D2009和dxgettext内置的本地化支持？

解决方案

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

• 集成到该程序（甚至比它的开发更迟）很容易。


• 可以通过命令行程序来提取可翻译的字符串，因此很容易将其引入自动化构建。 b $ b
• 可以通过创建具有正确结构的新目录，将空的翻译文件复制到其中，并开始翻译字符串，可以添加新的翻译。这是每个用户可以为自己做的事情，没有必要让原作者参与创建新的翻译。这个过程也有即时的满足 - 一旦程序重新启动，新的翻译将立即显示。


• 更改现有的翻译比创建一个新的翻译更容易。因此，如果用户发现拼写错误或其他错误或翻译需要改进，他们可以轻松地对其进行更正，并将更改发送给作者。


• 新版本的程序版本与旧翻译一起使用，系统非常优雅地降级 - 新的和未翻译的字符串不会被修改。


• 只能使用记事本进行翻译，但也有几种免费的创建和管理翻译文件的工具;请参阅dxgettext页面上的链接。它们本地化，并且比电子表格有一些优势：
  
  
  
  
  • 可以显示源代码中字符串的位置（仅适用于
  
  
  • 显示翻译字符串的百分比。
  
  
  • 已经翻译的字符串的修改也被突出显示。 >
    


• 整个系统是成熟和面向未来的 - 我已经使用dxgettext进行Delphi 4程序，并且Delphi 2009甚至不需要进行任何更改 - 翻译文件一直是UTF-8编码。

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

编辑：

关于dxgettext和library可能出现的问题，有一个有趣的评论。我从来没有体验过，因为我已经停止使用资源字符串。我们的计划的最大部分是德语，只有少数是英文或翻译成几种语言。

我们的内部库使用_（...）围绕所有可翻译的字符串。根据每个项目定义了 ENGLISH 和 USEGETTEXT 。如果 ENGLISH 或 USEGETTEXT 被定义，那么英文文本被编译成DCU，否则德语文本被编译成DCU。如果 USEGETTEXT 未定义_（）被编译为按原样返回其参数的函数，否则将使用dxgettext翻译查找。

I have a freeware scientific app that is used by thousands of people in nearly 100 countries. Many have offered to translate for free. Now that D2009 makes this easier (with integrated and external localization tools, plus native Unicode support) I'd like to make this happen for a few languages and steadily add as many as user energy will support.

I'm thinking that I'll distribute a spreadsheet with a list of strings (dozens but not hundreds) to be translated, have them return it, and compare submissions in the same language from 2-3 users then work to resolve discrepancies by consensus. Then I'll incorporate the localizations using the Integrated Translation Environment, and distribute localized updates.

Has anyone delegated translation to users? Any gotchas, D2009-specific or otherwise?

EDIT: Has anyone compared the localization support built into D2009 versus dxgettext?

解决方案

I have never been a friend of proprietary localization tools for Freeware or Open Source applications. Using dxgettext, the Delphi port of GNU gettext looks like a much better option to me:

• Integration into the program (even much later than its development) is easy.
• Extraction of translatable strings can be done by command line programs and is therefore easily introduced into an automated build.
• A new translation can be added simply by creating a new directory with the correct structure, copying the empty translation file into it, and starting to translate the strings. This is something each user can do for themselves, there's no need to involve the original author for creation of a new translation. There is also instant gratification with this process - once the program is restarted the new translations are shown immediately.
• Changing an existing translation is even easier than creating a new one. Thus if a user finds spelling or other errors or needs for improvement in the translation they can correct them easily and send the changes to the author.
• New program versions work with old translations, the system degrades very gracefully - new and untranslated strings are simply shown unmodified.
• Translations can be made using only notepad, but there are several free tools for creating and managing translation files too; see the links on the dxgettext page. They are localized themselves, and have some advantages over a spreadsheet as well:
  • The location of the strings in the source code can be shown (makes sense only for Open Source apps, of course).
  • The percentage of translated strings is shown.
  • Modifications to already translated strings are highlighted too.
• The whole system is mature and future-proof - I have used dxgettext for Delphi 4 programs, and there should be no changes necessary for Delphi 2009 even - translation files have always been UTF-8 encoded.

Using a spreadsheet for the translation doesn't seem a workable solution to me once you have more than a few languages. Suppose a new program version adds 2 new strings and changes 10 strings only slightly - wouldn't you need to add the new strings to and highlight the changed strings in all of the several dozen spreadsheet files and send them again to your translators? Using dxgettext you just mail the changed po file to all of them.

Edit:

There is an interesting comment about the problems there may be with dxgettext and libraries. I did never experience this, as I have stopped using resource strings altogether. The biggest part of our programs are in German, and only a few are in English or translated into several languages.

Our internal libraries use "_(...)" around all translatable strings. There are defines ENGLISH and USEGETTEXT that are set on a per-project basis. If ENGLISH or USEGETTEXT are defined, then the English texts are compiled into the DCUs, else the German text is compiled into the DCUs. If USEGETTEXT is not defined "_()" is compiled as a function that returns its parameter as-is, else the dxgettext translation lookup is used.

这篇关于Delphi 2009应用程序由志愿者翻译器进行本地化的过程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！