Процесс локализации приложения Delphi 2009 добровольными переводчиками?

Question

У меня есть бесплатное научное приложение, которым пользуются тысячи людей почти в 100 странах. Многие предложили перевести бесплатно. Теперь, когда D2009 делает это проще (с интегрированными и внешними инструментами локализации, плюс встроенная поддержка Unicode), я хотел бы сделать это для нескольких языков и постоянно добавлять столько, сколько будет поддерживать пользовательская энергия.

Я думаю, что распространю электронную таблицу со списком строк (десятки, но не сотни), которые нужно перевести, попросить их вернуть ее и сравнить заявки на 2-3 языка на том же языке от 2-3 пользователей, а затем решить их расхождения по консенсусу. Затем я включу локализации, используя интегрированную среду перевода, и распространю локализованные обновления.

Кто-нибудь делегировал перевод пользователям? Есть ошибки, специфичные для D2009 или нет?

РЕДАКТИРОВАТЬ: Кто-нибудь сравнивал встроенную в D2009 поддержку локализации с dxgettext?

Answer 1

Я никогда не был другом проприетарных инструментов локализации для бесплатных или открытых приложений.Используя dxgettext , Delphi-порт GNU gettext выглядит для меня намного лучшим вариантом:

• Интеграция в программу (даже намного позже, чем ее разработка)) легко.
• Извлечение переводимых строк может быть выполнено программами командной строки и поэтому легко вводится в автоматизированную сборку.
• Новый перевод можно добавить, просто создав новый каталог справильная структура, копирование пустого файла перевода в него и начало перевода строк.Это то, что каждый пользователь может сделать для себя, нет необходимости привлекать оригинального автора для создания нового перевода.Этот процесс также мгновенно доставляет удовольствие - после перезапуска программы новые переводы показываются немедленно.
• Изменить существующий перевод даже проще, чем создать новый.Таким образом, если пользователь обнаруживает орфографические или другие ошибки или нуждается в улучшении перевода, он может легко исправить их и отправить изменения автору.
• Новые версии программ работают со старыми переводами, система очень изящно ухудшается - новыеа непереведенные строки просто отображаются неизмененными.
• Переводы могут быть выполнены с использованием только блокнота, но есть также несколько бесплатных инструментов для создания и управления файлами переводов;см. ссылки на странице dxgettext.Они сами локализованы и имеют некоторые преимущества по сравнению с электронной таблицей:
  • Расположение строк в исходном коде может быть показано (конечно, имеет смысл только для приложений с открытым исходным кодом).
  • Показан процент переведенных строк.
  • Также выделены изменения в уже переведенных строках.
• Вся система зрелая и рассчитана на будущее - я использовалdxgettext для программ на Delphi 4, и не должно быть никаких изменений, необходимых даже для Delphi 2009 - файлы перевода всегда были в кодировке UTF-8.

Использование электронной таблицы для перевода не представляется возможным решениемдля меня, если у вас есть несколько языков.Предположим, что новая версия программы добавляет 2 новые строки и лишь незначительно меняет 10 строк - не нужно ли добавлять новые строки и выделять измененные строки во всех нескольких десятках файлов электронных таблиц и отправлять их снова вашим переводчикам?Используя dxgettext, вы просто отправляете по почте измененный po-файл всем им.

Edit:

Есть интересный комментарий о проблемах, которые могут возникнуть с dxgettext и библиотеками.Я никогда не сталкивался с этим, так как я полностью прекратил использование строк ресурсов.Большая часть наших программ написана на немецком языке, и только некоторые из них на английском языке или переведены на несколько языков.

Наши внутренние библиотеки используют "_ (...)" вокруг всех переводимых строк.Есть определения ENGLISH и USEGETTEXT, которые устанавливаются для каждого проекта.Если определены ENGLISH или USEGETTEXT, то тексты на английском языке компилируются в DCU, иначе текст на немецком языке компилируется в DCU.Если USEGETTEXT не определено, «_ ()» компилируется как функция, которая возвращает свой параметр «как есть», иначе используется поиск перевода dxgettext.

Answer 2

У меня есть ... Могут быть проблемы.

• строка сама по себе ничего не значит, ей нужен контекст.
• Следствие, для одной и той же строки может потребоваться более одного перевода.
• экранная недвижимость: остерегайтесь различной длины в зависимости от языка, например, французский, как правило, более многословен, чем английский.
• Если вы не владеете данным языком, вы не сможете оценить расхождения.

Answer 3

Как вы уже упоминали, D2009 поставляется с инструментами локализации. Почему бы просто не использовать их? AFAIK вы можете распространять внешним менеджером переводов (etm.exe). Вам нужно что-нибудь еще?

Кроме того, локализация - это больше, чем просто перевод текста. ETM также поддерживает перевод ресурсов .dfm.

Answer 4

Я использовал TsiLang Translation Suite , чтобы позволить конечным пользователям переводить. Я изменил код, чтобы разрешить шифрование, чтобы, если кто-то действительно хорошо работает, он мог защитить свое имя от файла перевода, но в целом идея заключается в том, что люди могут делиться своими переводами и добавлять / редактировать любую небольшую часть, которую они пожелают. Учитывая, что все это происходит внутри приложения и с мгновенной видимостью, оно работает очень хорошо.

Answer 5

Для полноты, вот еще один инструмент локализации Delphi под названием Delphi Localizer Я недавно обнаружил, что он выглядит хорошо разработанным и отшлифованным. Инструмент является бесплатным для коммерческого использования, за исключением правительственных проектов (не совсем понятно, почему исключение).

FWIW В прошлом я использовал TsiLang Translation Suite и сейчас работаю над другим проектом с использованием инструментов локализации, поставляемых с DevExpress VCL. Последний прекрасно интегрируется как со своими компонентами, так и со сторонними компонентами.