Директор по локализации, Evernote
0,0
рейтинг
19 октября 2015 в 09:56

Управление → Serge — решение для непрерывной локализации от Evernote

Сегодня я хочу рассказать вам о проекте, над которым я работал (и продолжаю работать) в Evernote с 2008 года, и которое несколько дней назад стало Свободным ПО.



Для многих разработчиков локализация ассоциируется с дополнительным пластом проблем: как поддерживать локализованные ресурсы в актуальном состоянии? А что если языков не 2-3, а 20-30? Как вовремя отправлять новые строки на перевод? А что если во время перевода разработка ушла вперед, и каких-то строк уже нет, а есть новые? Как мержить присланные переводчиками файлы ресурсов? Не секрет, что из-за этого многие просто забивают на локализацию или стараются отложить ее на потом.

Сейчас у Evernote более 150 млн пользователей по всему миру, более 70% этих пользователей находятся за пределами США, каждый месяц мы переводим по 15 тыс. новых слов в 40 с лишним проектах на более чем 26 языков, и выпускаем новые релизы наших продуктов одновременно на всех языках. При этом на техническую поддержку всей этой системы требуется один человек, и то изредка.

Как нам это удается?


Когда сервис Evernote только начинал развиваться, у нас было большое желание делать компанию международной с самого начала. Это требовало оперативной локализации приложений Evernote подо все платформы на большой перечень языков. И при этом мы хотели сделать этот процесс максимально прозрачным для разработчиков. Поэтому в 2008 году, мы начали создавать платформу, которая бы упростила и автоматизировала процесс локализации, сделала бы этот процесс непрерывным.

И вот семь лет спустя эта платформа, которую мы назвали Serge (String Extraction and Resource Generation Engine), стала доступной для каждого.

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

Как эта штука работает?


Serge — это приложение командной строки, которое принимает в качестве входного параметра команду и один или несколько конфигурационных файлов. Каждый конфигурационный файл описывает один проект локализации (с каким удаленным репозиторием синхронизироваться, как общаться с сервером переводов, в какой локальной директории и по какой маске сканировать файлы, каким парсером их обрабатывать, как именовать файлы, отправляемые на перевод, где и в какой кодировке создавать локализованные файлы, какие дополнительные плагины использовать и т.д.).

Вот что происходит, когда Serge запускает команду sync для каждого конфигурационного файла:



  1. (pull) выкачиваются изменения из удаленного репозитория с файлами ресурсов;
  2. (pull-ts) выкачиваются переводы из сервера переводов (обновляются локальные файлы);
  3. (localize) происходит, собственно, локализация:
    1. файлы ресурсов парсятся; сведения о файлах и строках попадают во внутреннюю базу;
    2. файлы с переводами парсятся; переводы попадают во внутреннюю базу;
    3. файлы с переводами обновляются в соответствии с изменившейся структурой исходных файлов ресурсов;
    4. файлы ресурсов обновляются в соответствии с изменениями в переводах;
  4. (push-ts) обновленные файлы с переводами выгружаются на сервер переводов;
  5. (push) обновленные локализованные файлы ресурсов выгружаются во внешний репозиторий.

Непрерывная локализация достигается тем, что как только Serge проходит этот цикл для каждого конфигурационного файла, цикл можно запускать снова. В случае с Evernote весь цикл по всем проектам занимает порядка 15 минут. Это значит, что как только инженер закоммитил какое-то изменение в файл ресурсов, в течение 15 минут приходит коммит от локализационного робота, симметрично меняющий все локализованные копии этого ресурса; когда переводчик добавляет перевод или изменяет существующий, в течение 15 минут его изменение коммитится в репозиторий. Эти изменения вызывают запуск CI-билда и последующее автоматическое тестирование, что позволяет максимально быстро выявлять ошибки, связанные с интернационализацией и локализацией, осуществлять перевод параллельно с разработкой продукта.

Архитектура Serge построена на плагинах. Serge поддерживает несколько видов систем контроля версий, более 20 форматов файлов, а также плагины, меняющие поведение системы (например, пре- и постпроцессинг локализованных файлов, возможность задавать список языков для перевода прямо в файле и т.д.). На сайте Serge находится документация по продукту, плагинам, установке и настройке.

Мы очень надеемся, что открытие исходников Serge позволит как индивидуальным разработчикам, так и большим компаниям, по-новому взглянуть на процесс локализации и тесно интегрировать локализацию в цикл разработки. Ну и, разумеется, будем рады комментариям, пожеланиям и сообщениям об ошибках.

Локализация — это просто!
Игорь Афанасьев @afan
карма
323,1
рейтинг 0,0
Директор по локализации, Evernote
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (20)

  • +1
    На сколько понимаю, локализация — это не только перевод интерфейса на другой язык, но и обуспечение рподдержки национальных стандартов (как-то, формати даты и времени, дробных и многозначных чисел, система мер, вывод на экран символов языка и т.д.). Как это реализуется?
    • 0
      То, что вы описали — это интернационализация. Локализация — это именно перевод строк и корректирование остальных данных вроде форматов времени. Часть данных при этом уже есть в проектах вроде CLDR, так что локализовать их заново не надо.
      • 0
        Интернационализация — это адаптация продукта для потенциального использования практически в любом месте, в то время как локализация — это добавление специальных функций для использования в некотором определённом регионе (тут и тут ). По-моему, это подтверждает мою мысль ;)
    • 0
      Поддержка форматов даты и чисел обычно есть в операционной системе — ничего особенного в рамках локализации тут делать обычно не надо. Разработчикам нужно просто следовать правилам, заданным для их платформы.
  • +3
    А предусмотрен ли какой-то способ борьбы с разницей между длинами строк на разных языках и необходимостью адаптации элементов интерфейса под эти строки?
    • 0
      Сравнивать длину на английском с длиной перевода и маркировать как-то в UI для переводов?
    • 0
      На уровне Serge есть только возможность протаскивать коммаентарии разработчиков из файлов ресурсов на сервер перевода. Уже на самом сервере переводчики видят эти комментарии, а также скриншоты, которые добавляют менеджеры по локализации. Интерфейс наши инженеры разрабатывают таким образом, чтобы он корректно работал с более длинными строками, а тестирование локализованных сборок позволяет нам выявлять косяки и переводить что-то покороче, когда это возможно, или файлить баги на разработчиков, чтобы они где-то переработали интерфейс.
  • 0
    А почему все делается в режиме пребилда файлов, а не в рантайме? Казалось бы, имея центральную базу переводов, всегда можно её локально закэшировать и извлекать переводы во время работы программы/приложения/сайта/сервиса. И тогда можно вообще все переводы обновлять в реальном времени, ничего не пересобирая.

    (Кстати, вопрос залу: а есть ли готовые сервисы, работающие по этому принципу по модели подписки?)
    • 0
      В реальном времени позволяет так делать Facebook. Но это он для себя, естественно. В виде сервисов такого не встречал.
    • 0
      Сервисы такие есть. Qordoba, например. Но, во-первых, это платно (и цены обычно сильно зависят от размера компании). Во-вторых, ни одна уважающая себя компания не будет ставить свой продукт (рантайм) в зависимое положение от стороннего решения. Это усложняет код, делает его более медленным, это делает локализационное решение нестандартным (чего разработчики не любят), это усложняет тестирование. Наконец, зачем что-то делать в рантайме миллионы раз, когда можно сделать один раз статически?
      • 0
        Ну да, так было 15 назад, когда не было AWS, Mandrill, CloudFlare и тысяч других сторонних решений, от которых современные веб-разработчики очень полюбили ставить себя в зависимость. Ну а на вопрос «зачем»… потому что быстро, удобно и позволяет нетехнарям править тексты и моментально видеть результат, например.
        • 0
          Не все, что удобно в разработке, удобно и быстро для конечных пользователей продукта. Динамическая локализация удобна переводчикам (коих у нас около 30), но имеет свои минусы для инженеров (коих у нас сотня) и конечных пользователей (коих миллионы). Одно дело — перенос своих вычислительных мощностей на AWS. Это прозрачно для пользователей, и скорее всего даже призвано ускорить работу. Другое дело — локализация в рантайме (усложнение кода и процесса).
  • +1
    Немного нелепо выглядит сей релиз сугубо внутренней наработки на фоне вливания evernote в pootle, ибо функционал вашего Серёжи практически идентичен translate-toolkit.
    Плюсы использования промежуточной базы на обычном SQL для конвертации форматов — весьма сомнительны на первый взгляд: откат состояний там не предусмотрен, снапшотов нет, то есть никакой защиты от факапов: роллбэк не сделать при плохом вливании, ибо проще сразу базу переналивать. Я так понимаю, что ровно плыть вам помогает именно тот факт, что внутри компании есть «домашние» переводчики и менеджеры локализаций? Опять же, работа с памятью переводов реализована через обычный скрипт, а реалтаймовые матчинги для переводчиков делает вполне себе эластик же, да?
    Получается, что в сухом остатке у вас, вероятно, имееются неплохие парсеры, ибо perl традиционно хорошо работает со строками… ну и всё.

    Из всего этого вытекает вполне себе резонный вопрос: если perl лошадка сдохла, то надо ли с неё слезать? :3 Ну а если без сарказма, то планирует ли компания работать над расширением функционала pootle и соответствующих утилит, или вы таки только с Сережёй дружить будете? :-}

    • +1
      Хорошие вопросы.

      Образно говоря, translate-toolkit по сравнению с Serge — это Arduino по сравнению с iPhone. Мы активно помогаем разрабатывать Pootle, но рассматриваем его лишь как интерфейс для перевода, не более. Serge+Pootle = полноценная опенсорс-платформа для непрерывного перевода. translate-toolkit мы помогать развивать не намерены. Внутри самого Pootle есть также тенденция уйти от зависимости с translate-toolkit.

      Serge не является конвертером форматов в прямом смысле этого слова. И это сильно больше, чем набор парсеров — рекомендую почитать документацию к управляющим плагинам, например. Снапшоты базы и .po-файлов мы делаем — ничего сложного тут нет. База не такая большая — можно делать бэкап хоть после каждого цикла. Elasticsearch — это TM внутри самого Pootle. Serge позволяет использует свою базу как TM, переиспользует известные переводы (сначала пытается находить 100% матчи внутри файла, потом внутри проекта, затем внутри всей базы).

      Помогать развивать функционал Pootle мы, разумеется, продолжим. Есть много идей для улучшения.
      • 0
        Игорь, спасибо за комментарий.
  • +1
    Игорь, спасибо за интересный обзор. Обязательно хочу поэкспериментировать с Serge в своей работе, когда будет время.
    У меня есть несколько вопросов:
    Правильно ли я понимаю, что Pootle у вас является основным внутренним CAT-инструментом? И именно это и послужило одним из драйверов создания Serge? У меня на работе несколько иная схема, где в ядре находится memoQ.

    Описанная вами цепочка работает только на локализации интерфейсов? Пробовали ли вы применить Serge для локализации документации? Была бы интересна такая схема в условиях гибкой разработки документации.
    • 0
      Pootle у вас является основным внутренним CAT-инструментом? И именно это и послужило одним из драйверов создания Serge? У меня на работе несколько иная схема, где в ядре находится memoQ.

      Да, весь перевод издет через Pootle. Драйвером послужило то, что нужна была система между Pootle и системой контроля версий, которая все бы делала полностью автоматически и постоянно. Pootle для этого не подходил, никаких других продуктов для непрерывной локализации не существовало, так что пришлось писать что-то свое.

      Я, по правде говоря, и сейчас не знаю других продуктов для непрерывной локализации. Понятно, что в последнее время появилось много CAT-решений, но когда дело касается интеграции процесса внтури компании с этим CAT-решением, обычно требуется интеграция через API (или через клиент командной строки), или же интеграция происходит по принципу «нажми на кнопку, чтобы загрузить новые строки, нажми другую кнопку, чтобы выгрузить переводы». Что у memoQ в этом плане?

      Описанная вами цепочка работает только на локализации интерфейсов? Пробовали ли вы применить Serge для локализации документации?

      Документация у нас вся хранится в виде статей в Zendesk. Есть еще маркетинговые материалы (блог-посты, описания приложений для app store, release notes), которые хранятся в Google Drive. Как для Zendesk, так и для Google Drive мы применяем похожую схему: есть скрипты синхронизации, который забирают контент из внешнего сервиса, генерят локально XML-файлы по одному на документ и выгружают это в систему контроля версий. Дальше все это переводится с помощью Serge+Pootle, а затем эти же скрипты синхронизации выгружают локализованный контент обратно в Zendesk и Google Drive.

      Если у вас документация хранится уже в системе контроля версий в каком-то пригодном к парсингу формате, то ее можно обрабатывать с помощью Segre безо всяких дополнительных ухищрений. Если интересно, пишите в личку, пообщаемся более предметно.
      • 0
        Спасибо за ответы!
        Что у memoQ в этом плане?

        У memoQ есть приложение Content connector — может забирать файлы из локальной сети, с компа или SVN (вроде бы ещё откуда-то, но я не пробовал).
        ABBYY в своём SmartCAT решили эту задачу через «горячую папку» — система постоянно проверяет, не изменились ли файлы в указанной папке на моём компьютере. Мне кажется, пока не очень изящное решение. Работоспособность не пробовал.
        Transifex позволяет делать непрерывную локализацию своими средствами. У них есть классная статья в блоге, где они рассказывают, как непрерывно локализуют самих себя. К сожалению, сам тоже пока не имел возможности попробовать (корпоративные ограничения).
        • 0
          С Transifex мы с ними общаемся, может быть даже попробуем сделать поддержку Transifex в Serge.

          Формально, поддержки непрерывной локализации в самом Transifex нет. Есть их утилита командной строки, которую можно использовать в своих скриптах. Но добавление новых файлов, удаление старых, начальная выгрузка, конфигурирование на стороне веб-интерфейса — все это надо делать руками. И потом, когда это сделано, можно написать свои кастомные скрипты, которые будут делать VCS push/pull и tx push/pull. И опять же потенциально иметь проблемы с мержем на уровне VCS или же писать скрипты для обхода этого. А Serge позволяет однажды настроить процесс и забыть про ручную работу.

  • 0
    Интересный проект. Забавно только, что на самом сайте нет локализации

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