Хабрахабр

[Из песочницы] Как устроена локализация в Netflix — перевод

Привет, Хабр! Представляю вашему вниманию перевод материала «Localization Technologies at Netflix», написанного командой Netflix про внутренние процессы локализации и программы, разработанные специально для этого.

image

Программа локализации в Netflix базируется на трех принципах: безупречная лингвистика, гармоничная атмосфера в коллективе и передовые технологии.

Работать в Netflix — значит быть первопроходцем. Мы не боимся экспериментировать и пробовать новые процессы и инструменты, выступать против общепринятых в локализации норм — благодаря этому мы продвинулись так далеко!

В этой статье мы рассказываем о двух технологиях, которые приведут нас к МИРОВОМУ господству… Подробнее под катом.

Netflix Global String Repository

Netflix достиг успеха не потому, что мы делаем качественный контент, а потому, как мы подаем этот контент. Большая часть успеха — это интуитивно понятный, простой в использовании и локализованный пользовательский интерфейс (UI). Netflix доступен на разных платформах: веб-версия, Apple iOS, Google Android, Sony PlayStation, Microsoft Xbox, в телевизорах Sony, Panasonic и так далее. У каждой из этих платформ свои требования к интернализации, что представляет собой серьезный вызов для нашей команды.

Вот примеры, когда требуется локализация UI:

  • добавление нового языка
  • добавление новых функций
  • изменения в уже существующих текстах и данных

Перевод текста для UI — не автоматизированный процесс; во время перевода менеджеры по локализации работают вместе с командой разработки для того, чтобы четко понимать, к чему относится та или иная строка, на какие языки ее нужно перевести и к какому сроку нужно предоставить локализованные файлы. Все становится намного сложнее, когда несколько фич разрабатываются параллельно и ведутся в разных ветках Git.

Для некоторых устройств требуется получить подтверждение от третьей стороны (например, от Apple). После того, как перевод выполнен, приложение собирают, тестируют и размещают на платформе. Особенно неприятными являются случаи экстренного внесения правок. Все это провоцирует нежелательную задержку сроков.

Что, если нам не нужно будет больше пересобирать билды каждый раз, когда вносятся правки в текст? Но что, если сделать процесс локализации открытым для всех стейкхолдеров — и для команды разработки, и для локализаторов?

Мы интегрировали Global String Repository в техпроцесс локализации, таким образом, они взаимно дополняют друг друга. Для решения этих проблем мы разработали глобальное хранилище строк UI, которое называется Global String Repository; здесь хранятся локализованные строки, которые подставляются в среду для выполнения кода.

В пакете локализации хранятся все данные по строкам на всех языках. Global String Repository разделяет пакеты локализации и пространство имен (заполнители). Во время разработки используются стандартные заполнители. Заполнители — это плейс-холдеры для пакетов, над которыми работает команда. Рабочий процесс выглядит так:

  1. Разработчик вносит изменения в английскую версию строки в пакете (в пространстве имен–заполнителей)
  2. Автоматически запускается процесс перевода
  3. Лингвисты завершают перевод
  4. Переводчики делают комплекты в заполнителях доступными

Когда происходит интеграция с Global String Repository, есть два типа поведения приложения:

  • Во время исполнения: позволяет быстро вносить изменения в UI
  • Во время сборки: использование Global String Repository отдельно для локализации, а пакеты с данными — со сборкой (билдом)

Global String Repository делает возможной интеграцию на этапе сборки предоставляя доступ к локализованным данным через REST API.

Для приложений, которые интегрируются во время исполнения, это критически важная часть. Мы открываем Global String Repository через API Netflix, таким образом к нему применяются те же самые масштабирование и требования, что и к метаданным других API. У нас 60 миллионов пользователей, которые запускают Netflix на разных устройствах, поэтому Global String Repository является приоритетной задачей.

Микросервис — это веб-приложение на Java (выполненное в Apache Cassandra и ElasticSearch), которое размещено в трех регионах AWS. Как и у Netflix, у Global String Repository микросервисная архитектура. Мы собираем статистические данные для каждого запроса к API.

Интерфейс Global String Repository разработан на Node.js, Bootstrap и Backbone и размещен в AWS.

На стороне пользователя Global String Repository использует REST API для получения данных и предлагает клиент Java со встроенным кэшированием.

Вот над чем мы работаем сейчас: Несмотря на то, что мы проделали большой путь и активно развиваем Global String Repository, нам есть к чему стремиться.

  • Разрабатываем поддержку строк с числовыми переменными и строки с идентификаторами гендеров
  • Развиваем устойчивость наших технических решений к сбоям
  • Улучшаем процессы масштабирования
  • Поддерживаем экспорт в разные форматы (Android XML, Microsoft .Resx и т.д.)

Global String Repository не имеет привязки к бизнес-домену Netflix, поэтому мы планируем выпустить его как программное обеспечение с открытым исходным кодом.

Hydra

Netflix — глобальный сервис, который поддерживает множество локалей в мириадах различных комбинаций на разных устройствах/UI; ручное тестирование в таком случае не подходит. Раньше команда локализаторов и разработчиков UI тестировала все вручную на разных устройствах — от консолей до iOS и Android; так мы проверяли все строки на соответствие контексту и UI (например, нет ли «обрезания» текста).

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

Например, будучи специалистом по немецкой локализации, вы можете настроить фильтрацию таким образом, что увидите весь путь, который проходят незарегистрированные пользователи на PS3, веб-сайте и Android. Задача Hydra — создание каталога всех возможных вариантов уникального экрана, который будет показывать именно тот экран, который требуется (поиск осуществляется по фильтрам, например, можно выбрать устройство и локали). Эти же экраны можно посмотреть в том темпе, в котором пользователь будет открывать их на своем устройстве.

Работа с экранами в Hydra

Инструмент Hydra не работает с экранами напрямую; он служит для их каталогизации и отображения. Чтобы взять отображение экрана из каталога Hydra, мы используем нашу модель автоматизации UI. С помощью Jenkins CI тесты, управляемые данными, работают параллельно во всех поддерживаемых локалях: так создаются скриншоты, которые публикуются в Hydra с соответствующими метаданными (имя страницы, область функций, платформа UI и один критический фрагмент метаданных, — уникальное экранное определение).

Это позволяет сравнить большее количество экранов в долгосрочной перспективе, так как изображение каждого экрана сравнивается с самим собой. Уникальное экранное определение нужно для того, чтобы составить полный каталог экранов без ложных совпадений. Определение уникального экрана отличается от UI к UI; для браузера это сочетание имени страницы, браузера, разрешения, локальной среды и среды разработки.

Технология

Hydra — это полностековое веб-приложение, размещенное в AWS. Back-end на Java выполняет две основных функции: обрабатывает входящие скриншоты и предоставляет данные для бэк-энда через REST API.

image

Конечные точки REST (REST endpoints) обеспечивают отображение параметров строки запроса на запросы MySQL. Когда автоматизация UI отправляет экран в Hydra, сам файл изображения записывается на S3, что обеспечивает его бесконечное хранение (плюс-минус), а метаданные гораздо меньшего размера записываются в базу данных RDS, чтобы впоследствии запрашивать их через REST API.

Например:

REST/v1/lists/distinctList?item=feature&selectors=uigroup,TVUI;area,signupwizard;locale,da-DK

В этом запросе содержатся параметры для выбора необходимых данных из Базы:

select distinct feature where uigroup = ‘TVUI’ AND area = ‘signupwizard’ AND locale = ‘da-DK’

Содержимое фильтров, а также экраны, которые соответствуют выбранным фильтрам, обеспечиваются вызовами конечных точек REST, упомянутых выше. Фронт-энд JavaScript, который использует knockout.js, позволяет пользователям выбирать фильтры и просматривать экраны, соответствующие этим фильтрам.

Масштабирование приложения

После установки Hydra и запуска автоматизации добавить новые локали так же легко, как добавить одну строку в существующий файл свойств, который отправляется в Data Provider фреймворка testNG. Экраны с новой локалью будут отображаться со следующими работающими сборками Jenkins.

Что дальше?

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

Это позволит переводчику изменить строку, а затем выполнить поиск по ключу и увидеть экраны, на которые повлияло это изменение; так переводчик увидит, как эта строка изменяется в контексте заранее. Еще одна фича — иметь возможность сопоставлять отдельные строки ключей с тем, какие экраны нужно отображать.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть