Уже летом 2012 года перед командой встала задача — локализация сервиса Lingualeo на португальский язык. При этом это было необходимо сделать так, что что бы это был процесс, масштабируемый на другие языки.
Процесс локализации продукта рождался в Черногории, куда команда Lingualeo выезжала для интенсивной работы над новыми фичами. По первоначальной оценке на локализацию должно было потребоваться всего пару недель разработки перед тем, как систему можно было будет отдать переводчикам. Но, как это часто бывает, оценки оказались сильно оптимистичными, команда “встряла” на 1,5 месяца. Lingualeo прошла через сложный процесс и целый ряд проблем, которых другие могут избежать, прочитав этот пост до конца. Мы попросили Игоря Любимова, Head of localization, почетного ветерана локализации Lingualeo, перессказать сюжет в деталях.
Выбор системы
Для того, чтобы выбрать подходящий инструмент, необходимо было определить, какие задачи он будет решать. Прежде всего, нам было важно, чтобы продукт поддерживал локализацию на нескольких платформах: несколько форматов файлов для веб-сайта, Android-приложение, iOS-приложение, Windows Phone-приложение, а так же нас интересовал API — для тесной интеграции CI-системы и платформы для перевода.
Изначально мы рассматривали старый-добрый Pootle, так как наш бэкэнд был написан на PHP, и для локализации использовали gettext с .po-файлами. Быстро поняли, что это не наш вариант, так как для перевода JSON и прочих файлов приходилось писать кучу конвертеров – Pootle не поддерживал весь необходимый нам “зоопарк” форматов. Плюс, не хотелось хостить платформу для переводов у себя, потому начали искать какое-нибудь SaaS-решение.
Наши критерии для выбора: поддержка всех возможных форматов из коробки, возможность добавления новых строк через API, удобный менеджмент прав пользователей, высокий uptime, короткий срок интеграции, а также возможность запустить crowdsource-локализацию в будущем.
В итоге, мы остановились на простом, но функциональном сервисе WebTranslateIt.com (далее – “WTI”), так как он подходил под все наши требования.
Замечу, что если бы мы выбирали систему сейчас, то остановились бы на Crowdin. Она удобнее и интереснее той, которую мы используем, но не настолько, чтобы инвестировать в рефаткоринг многих частей проекта.
Итак, WebTranslateIt.com. Это небольшая готовая SaaS-платформа, ее создал француз Эдуард Триер (Édouard Brière). 3-4 года назад она стала настоящей находкой для Lingualeo. На тот момент она нам очень понравилась. У нее было хорошее API и она отвечала основному требованию — возможность локализации различных форматов и платформ. Плюс, дружелюбный создатель очень оперативно отвечал на все вопросы и делал доработки специально для нас.
Кстати, мы написали и опубликовали в Open Source библиотеку под composer (PHP) для работы с WebTranslateIt.com: http://ift.tt/1jcKGqg. Ждём ваших пулл-реквестов!
Процесс интеграции
Веб, расширения для браузеров и мобильная версии
Основная задача, которая стояла перед нами, не нагружать разработчиков лишними задачами по обслуживанию локализации, а сделать все возможное для того, чтобы они были заняты непосредственно созданием продукта. Вопросы локализации должны быть вынесены из основоного workflow. Представляли мы себе это так: разработчик пишет новые строки, отправляет в систему (либо одной командой, либо вообще автоматические), а дальше они переводятся на несколько языков и возвращаются в проект, без каких-либо явных усилий разработчика. Мантра “Что может быть автоматизировано, то должно быть автоматизировано” часто проскакивает в разговорах наших разработчиков.
Наши размышления привели нас к созданию специальной утилиты, которая была призвана облегчить жизнь разработчиков. Для веб-сайта мы написали пару консольных утилит.
Первая добавляет новую строку в выбранный файл.
$ wti-add localizationFilename.json uniqueStringKey
Please provide russian text
> Привет, Хабр!
String is added
Иногда это бывает удобно, но наибольшую пользу приносит вторая утилита, которая парсит наши шаблоны, вытаскивает из них строки для локализации, добавляет их в WTI и делает прочую магию. Чтобы утилита правильно понимала, какие строки стоит переводить, а какие — нет, разработчикам надо просто обрамить соответсвующий текст символом @.
Пример для наших клиентских шаблонов:
<!-- someTemplate.jst до локализации -->
<h1>Привет! Я Лео!</h1>
<!-- someTemplate.jst подготовленный к локализации -->
<h1>@Привет! Я Лео!@</h1>
После этого выполняем:
$ wti-parse someTemplate.jst localizationFilename.json
1 string to add found
Please provide key for “Привет! Я Лео!”
> hi_i_am_leo
1 string parsed and added
И в WTI создается новая строка в файле someTemplate.jst с ключом hi_i_am_leo и русским текстом Привет! Я Лео!, а наш шаблон принимает другой вид:
<!-- someTemplate.jst подготовленный к локализации -->
<h1><%=i18n.localizationFilename.hi_i_am_leo%></h1>
Разработчику остается только закомитить изменения, и можно больше не париться о переводах.
Подобные парсеры были сделаны и для всех остальных форматов шаблонов, включая Twig и даже простые PHP-скрипты с бизнес-логикой. В зависимости от расширения файла, используются разные форматы замены плэйсхолдеров.
В своем процессе работы с git-ветками мы придерживаемся правил git-flow. Это позволяет нам связать CI-систему с задачами из Jira, помогает поддерживать порядок в репозитории, да и вообще, это круто. Раз по номеру тикета у нас опредляется ветка, почему бы не использовать её же и для определения строк для локализации? Ответ на вопрос “Какие строки были добавлены в рамках задачи DEV-1940?” снимется сам собой. И мы сделали апгрейд улититы wti-parse – она берет номер текущей ветки и добавляет все строки с дополнительной меткой задачи. В итоге в интерфейсе WTI это выглядит вот так:
Строки добавлены, программист идет дальше делать продукт, больше от него по части переводов ничего не требуется.
Далее, при каждой сборке на нашем CI-сервере, из WTI выгружаются последние версии переводов, и это работает, как часы :)
Курсы
В эту же систему мы интегрировали перевод наших курсов. Курсы – это не интрефейсные строки, их создают контент-менеджеры. Изначально мы пытались делать переводы вручную, через перессылку Word-файлов, но быстро поняли, что это плохая идея: это возможный, но абсолютно не масштабируемый процесс. Вскоре наш конструктор курсов был интегрирован с WTI. И теперь, как только контент–менеджеры Lingualeo производят какие-либо изменения в курсах (добавляют упражнения, изменяют формулировки и т.д.), они тут же отражаются в WTI. Все переводчики получают уведомления, и запускается выше описанный алгоритм. Таким образом, нам не приходится вручную управлять процессом перевода: всё работает автоматически.
Email-рассылки
Как и любой сервис, выстраивающий тесный диалог со своими пользователями, Lingualeo делает различные email-рассылки. Около 13 000 000 пользователей, десятки миллионов отправляемых писем каждый месяц – в нашем случае не было смысла реализовывать всю инфрастуктуру внутри, поэтому мы используем внешнего email-провайдера. Но вот беда: у нашего провайдера нет встроенных механизмов локализации шаблонов писем, и поэтому мы изобрели очередной “велосипед”, скрестив два API — Emarsys (а именно они рассылают все наши письма) и WTI.
Раз в 6 часов несколько скриптов забирают из Emarsys все русские шаблоны писем, выделяют из них строки для локализации, формируют из них файлы для WTI, а из WTI забирают готовые переводы и создают в Emarsys шаблоны на всех нужных языках. А уже в настройках рассылок используются те или иные шаблоны, в зависимости от родного языка пользователя.
Процесс работы с переводчиками
Для одновременного перевода на несколько языков мы придерживаемся следующей схемы работы. Сначала создаем строки на русском, потом переводим на английский язык и с английского уже на остальные языки (турецкий, испанский, португальский, пара испанских диалектов и т.д.).
Мы договорились, что переводчик на английский язык заходит в систему во вторник и четверг с утра. Забирает строки, и в течение нескольких часов готовит все переводы, которые нам нужны. Переводчики на остальные языки заходят в те же самые дни, но вечером. Таким образом, мы в течение суток получаем все переводы. График подстроен под наш цикл релизов для того, чтобы у нас вовремя появлялись новые строки. Конечно, иногда у нас все-таки бывают проблемы, но это случается только в случаях, если разработчик в самый последний момент добавил строки, быстро протестировали фичу, и она на следующий день уже идет в релиз.
Эта система подходит не только для работы с агентствами по переводу, переводчиками фри-лансерами или штатными, но и для использования крауд-сорсинга в переводе. Когда мы запустили проект “Переведи Lingualeo” и пригласили наших пользователей перевести хотя бы несколько строк на знакомые им языки, мы создали лэндинг и интегрировали страничку со статистикой из WTI с сайтом.
Так выглядит форма для перевода фраз:
Интернационализация
В результате проделанной работы, была разработана технологическая платформа и процессы локализации Lingualeo. Всё это работает и для веба и для мобильных приложений и не требует постоянного участия кого-либо из нашей команды. Локализация прозрачна для разработчиков: они просто пишут код, разрабатывают продукт для всех наших рынков. Переводчики делают свою работы независимо от них. Сегодня добавление готовых переводов во все продукты занимает 1-2 дня.
Конечно же, перевод продукта – это лишь часть процесса по подготовке продукта к запуску на новых языковых рынках. Локальные валюты, платежные системы, словари для новых языков, создание специальных курсов, заведение групп в социальных сетях на новых языках – все эти активности также максимально упрощены и автоматизированны. Весь процесс настройки сводится к правке нескольких YML-файлов конфигурации, и требует буквально несколько часов на настройку всего окружения. Но это уже материал для следующей статьи.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий