Design.ru.md

Почему получилось то, что получилось

Проблема

Есть несколько проектов:

• мобильное приложение на Android
• мобильное приложение на iOS
• настольное приложение для Mac OS X
• настольное приложение для Windows
• веб-приложение на Ruby on Rails
• маркетинговые сайты на Middleman

Они используют следующие механизмы перевода:

• Android (Java properties XML) (наследие Java)
• файлы Localizable.strings для iOS и Mac OS X, так же сделали локализацию Windows через них (собственное довольно старое изобретение)
• файлы .yml (зачем еще и эти изобрели свой формат понятно, но всё равно печально) для Ruby on Rails и Middleman

Все они поддерживают несколько языков:

• русский
• английский
• польский
• французский

Команда, в основном, знает русский и английский. Причем, русский лучше. Остальное отдается на перевод переводчикам. Они переводят с русского или английского варианта.

Переводчики обычно технически не особенно подкованны. Им нужны простые программы, чтобы сделать свою работу.

Каждая же из систем предлагает свой вариант формата файлов для перевода.

Напрямую с ними переводчикам крайне сложно и неудобно работать. Более того, полученный перевод, скорее всего, содержит ошибки форматирования. Так же разработка идет достаточно интенсивно, нужно достаточно часто (скажем, раз в неделю) допереводить новые строки.

Так же не хотелось бы вводить дополнительных людей, которые бы стояли между переводчиками и программистами.

1. Используем одну программу для переводчиков ============================================= Желательно, чтобы переводчики работали в программе, а не с файлами напрямую. Так не будет синтаксических ошибок в файлах.

Желательно, чтобы программа была одна, а не несколько, чтобы иметь общую базу переводов. Да и обучать было бы проще.

Желательно, чтобы программа была как под Windows, так и под другие ОС. Мало ли чем будут пользоваться переводчики.

2. Используем один формат ========================= Из желания использовать одну программу приходим к решению использовать один формат для переводов. Т.к. программ, поддерживающих все и разные не найдено.

Соответственно, нужно будет обеспечить конвертацию форматов в обе стороны.

3. PO (Gettext) спасает день ============================ Формат .po довольно популярен и достаточно прост. Все найденные редакторы его поддерживают. Его так же поддерживают различные online-редакторы (при необходимости).

Как альтернатива можно было использовать .xlf .xliff Localisation Interchange File Format, но никаких преимуществ относительно .po не увидел.

Теоритических преград для портирования из необходимых исходных форматов в обе стороны нет.

Стоит отметить, что большинство форматов основаны на первичных ключах вида "main_window.options_group.first_name.hint". PO-файлы переводят фразы с одного языка на другой. При этом изначально разработчики делают перевод хотя бы на русский язык. Но этот перевод так же хотелось бы исправлять нетехническими людьми. К счастью, есть механизм в .po файле и для задачи ключей (msgctxt). Это поможет правильно сделать обратный экспорт в любом случае.

Но при изменении русского и английского текста старый перевод будет отображаться как неиспользуемый, а новая фраза как непереведенная. Такие правки лучше исправлять людьми, т.к. улучшенный исходный текст часто будет приводить и к более точному переведенному тексту.

4. Так какие же именно программы для редактирования переводов? ================================= Проще всего в установке и использовании, бесплатный, достаточный по функционалу http://poedit.net . Более навороченный Lokalize из проекта KDE. Можно использовать и другие варианты при необходимости.

5. Как хранить переводы? ======================== Переводчики народ не очень технически грамотный. Научить их обращаться с Git проблематично. Поэтому можно сделать общую папку в сервисе Dropbox (или аналогичном, их тысячи).

6. Как структурировать папку переводов? ======================================= На первом уровне шаблоны (.pot-файлы, .po-файлы без перевода) или переводы. На втором код языка, чтобы один язык можно было отдельно распространять. Затем название приложения, а уже внутри сами файлы переводов. Шаблоны на 2-х языках (рус. и англ.) в разные папки шаблонов, т.к. с них переводят. Пример: Templates/ ru/ editor-windows/ main.pot en/ editor-windows/ main.pot Translations/ ru editor-windows/ main.po //перевод с русского на русский, для исправлений текстов нетехническими людьми en editor-windows/ main.po //перевод с русского на английский, для исправлений текстов нетехническими людьми fr editor-windows/ main.po //перевод с английского на французский sp editor-windows/ main.po //перевод с русского на испанский

Такой вариант позволяет без конфликтов разным людям обновлять разные папки. По сути, над отдельной папкой (точнее файлом) не работает на запись более одного человека.

Это достигается односторонним потоком данных: src --(developer)--> pot --(translator)--> po --(developer)--> src Как исключение, если редактор, установленный у переводчика не поддерживает удобное добавление новых строк из обновленного pot-файла, то при обновлении pot-файла могут обновляться и соотв. po-файлы.

Естественно, если было бы несколько переводчиков на один язык, то пришлось бы использовать Git или другим способом координировать их работу.

7. Не ограничиваем программистов ================================ Программисты могут использовать любой удобный для их проекта формат файлов перевода. Хранить файлы у себя в проекте в любом месте и под любым именем. Иметь столько файлов переводов сколько им удобно. Одному файлу исходному будет соответствовать 1 файл pot и по кол-ву языков файлы po.

8. Как создавать файлы переводов? ================================= Под каждый формат нужна утила конвертирования (она может быть и одна, и несколько). Нужно их или найти, или написать свои.

Разработчик у себя в проекте создает shell-скрипт или другим образом 2 задачи:

• на импорт переводов (копирование из папки Dropbox соотв. .po-файлов и конвертирование в нативный формат)
• на экспорт переводов (экспорт в .pot-формат и копирвание в папку шаблонов)

Gem 18n-po содержит библиотеку для простого написания собственных скриптов, т.к. при большом количестве исходных файлов и языков перевода появляется много однотипных задач.

Получается схема работы (пример):

• разработчик экспортирует перевод из нативного формата в файлы example.pot и example_dialogs.pot, они помещаются в папку Templates/ru/example/ в Dropbox
• переводчик на английский в редакторе открывает эти файлы, переводит и кладет файлы example.po и example_dialogs.po в папку Translations/en/example/
• разработчик example (или переводчик у которого настроен запуск) запускает конвертацию из переводов в шаблоны Templates/en/example. Аналогично и с русским языком, если его исправляли. В этот же момент для удобства можно сделать merge из pot в po файлы (если такое делается, то организационно нужно согласовать так, чтобы в это время файлы переводов этого приложения ни одним из переводчиков не обновлялись). Это шел-скрипт без параметров (для простоты запуска).
• переводчики на другие языки открывают шаблоны на русском или английском и переводят. Файлы .po кладут в папку своего языка и приложения. Если перевод уже был, то при обновлении .pot-файла редакторы сами заметят, что появились новые строки. Если редактор менее навороченный, то в п.1 при экспорте переводов нужно так же запустить утилиту из пакета gettext по слиянию переводов. При этом в .po файлах появятся непереведенне строки.
• разработчик запускает импорт переводов. Файлы из Dropbox переводятся в нативный формат и помещаются в нужные места в проекте.

9. Что делать с уже существующими переводами в нативном формате? ================================================================ Основная утила i18n-po поддерживает импорт/экспорт во все стороны. Разово пишем команды для фомирования исходных po-файлов.

10. Так как помещать новые непереведенные строки из .pot файлов в .po файлы? ============================================================================ В идеале это делает редактор. Иначе стандартный пакет для работы с файлами .po -- gettext -- содержит утилиту для этого. Через PO-редактор Catalog > Update from POT-file. Утила из gettext: msgmerge --update example.po example.pot

11. Как конвертировать перевод в Android .xml формат из .po? =========================================================== Пришлось свою утилу писать. Опубликована как i18n-po gem.

12. Как конвертировать перевод в .strings формат из .po? ======================================================== Пришлось свою утилу писать. Опубликована как i18n-po gem.

13. Как конвертировать перевод в .yml формат из .po? ==================================================== Пришлось свою утилу писать. Опубликована как i18n-po gem.

14. Как конвертировать перевод в .po формат из Android .xml? =========================================================== Пришлось свою утилу писать. Опубликована как i18n-po gem.

15. Как конвертировать перевод в .po формат из .strings? =========================================================== Пришлось свою утилу писать. Опубликована как i18n-po gem.

16. Как конвертировать перевод в .po формат из .yml? =========================================================== Пришлось свою утилу писать. Опубликована как i18n-po gem.

17. Что из всего этого бекапить? ================================ Скрипты импорта/экспорта бекапятся как часть исходников. pot-файлы на ключах восстанавливаются из исходников. Нативные переводы восстанавливаются из .po-файлов, но не наоборот (такие утилы вне проекта, хотя и возможны). Поэтому нужно бекапить всю папку Dropbox, остальное не обязательно. Папку для бекапов можно добавлять в отдельный git-репозитарий, тогда будет бекапиться по процессу бекапа исходных текстов.

18. Нужен конвертор yml <--> po? ================================ Да. Причем нужна поддержка нескольких .yml-файлов (может генерироваться и несколько соотв. .po-файлов). И поддержка множественных форм. Конвертация в обе стороны. Проектов, которые бы удовлетворяли всем требованиям не было найдено.

19. Как добавлять новый язык? ============================= Переводчики могут независимо из pot-файлов сделать po-файлы с переводом на новый язык. Программисты добавляют всю инфраструктуру вокруг нового языка самостоятельно: возможность его выбора, создание папок для файлов (для Apple и Android), сконвертированных из po, добавление нового языка в Locfile.

Как итог: какие сторонние программы использовались?

1. poeditor.net
2. Dropbox
3. Gettext
4. Скрипты для автоматизации консольных команд
5. Собственный gem i18n-po для конвертаций из формата в формат и общая часть скриптов автоматизации

Что делать, если захочется статистику и прочее?

Искать утилы для .po-файлов. Наверняка такое уже есть. Например, конвертация .po-файла в .pot: msgfilter -i main.po -o main.pot --keep-header sed -e 's/.*//g;/^$/d'

Особенности реализации конвертации из Rails (.yml)

Редакторы не поддерживают конструкции вида %{count}. Для plural сообщений используется автоматическая конвертация в C-format: %d <--> %{count}. В остальных случаях ничего не делается.