5. What will we be talking
about?
The problem of localization process
General solution: online translation service Smartling
Solution for Drupal: integration with online service
Contrib module TMGMT: Translation management Tool
How to prepare Drupal 8 and setup TMGMT for working with Smartling
Smartling integration modules:
TMGMT Smartling
TMGMT Extension Suite: features
7. The problem of localization
process
Copy/Paste driven translation process
8. The problem of localization
process
Copy/Paste driven translation process
What is that string for? What is the context for a given string?
9. The problem of localization
process
Copy/Paste driven translation process
What is that string for? What is the context for a given string?
Too many versions of one translation
20. Core modules
content_translation - allows you to translate your site content,
including pages, taxonomy terms, blocks, etc., into different
languages
21. Core modules
config_translation - allows you to translate text that is part of
the configuration, such as field labels, the text used in Views,
etc
49. Tracking entity changes
How does it work?
Store source entity’s content hash
hook_entity_update() - check if source content is changed
50. Tracking entity changes
How does it work?
Store source entity’s content hash
hook_entity_update() - check if source content is changed
Resend content to Smartling
Всем привет. Меня зовут Павел Лопарев. Сейчас мы будем говорить о проблеме локализации контента и графического интерфейса вообще и в Drupal в частности. Я называю эту проблему “Copy/Paste driven” локализация.
Пару слов о себе. Я Drupal web developer. Немного занимаюсь контрибьютингом, есть несколько своих проектов на d.org (Changed Fields API, Domain ThemeKey etc.) и github (Connector, Drupal permission clicker etc.), кому интересно, заходите, посмотрите.
Работаю я на компанию Smartling. Мы занимаемся разработкой онлайн сервиса переводов, который помогает заказчикам локализовать их продукт. По сути это площадка, где агентства по переводам и заказчики могут эффективно сотрудничать друг с другом.
Небольшой слайд для привлечения внимания. Среди наших клиентов есть фуджифилм, вимео, гопро, слак, британские авиалинии и так далее.
В ходе презентации я затрону такие темы, как:
Проблема процесса локализации
Общее решение данной проблемы
Решение проблемы в частности в друпал: вспомним как подготовить Д8 сайт к мультиязычности, узнаем что такое tmgmt модуль, посмотрим на модули интеграции с Smartling сервисом и узнаем как они работают под под капотом.
Рано или поздно ваш бизнес доходит до такой точки развития, когда Вы понимаете, что без локализации дальнейшей рост невозможен. Тогда перед вами встает задача: перевести Ваш сайт, приложение, что-либо еще на различные целевые языки. Вот как раз здесь и возникает та самая проблема: а как это сделать быстро и правильно?
Первое, что приходит в голову и чем обычно и заканчивается весь процесс локализации - это copy/paste. Что я имею в виду. Например клиент нанял переводчика, дал ему весь контент (в каком либо виде) на перевод и через время его получили обратно. Вроде бы ничего такого, подход вполне рабочий, менеджеры/девелоперы применили переводы на сайте/приложении. Но есть одно но. Проблема в том, что Вам придется придумать, как вручную “хэндлить” весь поток doc/xml (не дай Бог pptx :D)/emal. Такой процесс не приводит ни к чему хорошему. Обычно это заканчивается недовольством клиента, так как весь процесс локализации затягивается из за постоянных ошибок человеческого фактора (применил устаревший перевод, взял перевод не из того файла, не учли, что в письме прислали коррекции к существующему переводу и так далее).
Из первого пункта логично вытекает вторая проблема. Представьте, что вы и есть тот нанятый переводчик. Вам прислали файлы с контентом и попросили “переведи”. Вы говорите “ок” и начинаете заниматься переводом. Проблема в том, что Вы не видите контекст, в котором то или иное предложение было использовано. На самом деле от контекста многое зависит. В данном случае зависит качество перевода.
И как следствие второго пункта вытекает пункт третий: постоянные правки и изменения в переводах. Что вместе с изменением самого исходного контента добавляет еще больше ошибок и итераций в локализации. И все это как снежный ком только набирает обороты и во всем этом все сложнее становится разобраться. Возможно я немного сгустил краски вокруг всего этого процесса, но в целом эти проблемы существуют и их решение действительно упростило бы работу переводчиков и удовлетворило бы потребности заказчика.
Smartling - это онлайн сервис, предоставляющий возможность переводить контент Вашего сайта/приложения/чего-либо еще как вручную (загружая файлы), так и с помощью множества существующих интеграций, использующих API сервиса. В том числе и Drupal интеграция.
Как вы уже поняли, сервис предоставляет API для работы с переводами. Собственно в чем суть этого API. Если говорить утрированно, то все сводится к тому, чтобы отправить в сервис (в определенный проект) некий файл с контентом на перевод на определенный язык. Далее переводчик делает свою работу и система помечает файл как переведенный. Далее вы запрашиваете статус файла и если он был переведен, то скачиваете его и применяете перевод в своем сайте/приложении.
Из коробки предоставляется несколько вариантов взаимодействия с серисом. Первый - это коннекторы. Это модули или плагины для различных CMS/CMF продуктов. Среди них друпал, вордпрес, сайткор, аем и хайбрис.
Следующий способ взаимодействия с сервисом - это GDN (global delivery network). Эта сеть решает задачу локализации сайтов, для которых изначально не было заложено возможности локализации. Работает это следующим образом:
Например вы запрашиваете страницу ua.mysite.com.
Запрос уходит на Ваш сервер через GDN прокси.
GDN получает исходную версию страницы
И каждую строку в полученной странице заменяет на переведенную (поддерживается статический, динамический (ajax) контент).
В итоге пользователь получает переведенную страницу.
MDN - mobile delivery network призван решить проблему зависимости перевода от релиза приложения. При классическом подходе для того, чтобы обновить перевод в приложении вам придется выпустить новый релиз приложения, что в свою очередь означает прохождение всего воркфлоу публикации приложения в магазине приложений, включая задержки н аревью и правки и так далее. С MDN перевод доставляется “по воздуху” сразу же после публикации его в Smartling.
Важно понимать, что файлы, с которыми работает сервис, это всего лишь способ транспортировки контента в сервис. Это не значит, что если вы удалите файл в сервисе, то перевод будет потерян. Такое поведение обеспечивается системой под названием “Translation memory”. Например, если переводчик уже переводил такую фразу, то в следующий раз переводить заново ее не придется. Ему будет предложена строка взятая из TM. Логическим продолжением TM является “Smart Match”. Если ТМ предлагает готовый перевод по полному совпадению, то смарт матч по неким правилам может сказать, что в “принципе совпадение не 100%, но скорее всего для данной строки этот перевод подойдет”. Таким образом ТМ смарт матч экономят время переводчика и деньги клиента.
Говоря о локализации чего-либо важно понимать следующий факт: длина слов в каждом взятом языке разительно отличается от исходной. Для разработчиков и, в особенности, дизайнеров и front-end разработчиков, это значит лишь одно - калейдоскоп багов, Например у вас на сайте есть блок фиксированного размера и вы переводите содержимое этого блока, например, на немецкий язык. В немецком языке слова длиннее, чем в английском, поэтому велика вероятность того, что ваш блок попросту сломается, поедет верстка и он будет выглядеть не очень привлекательно. Поэтому очень важно понимать как будет выглядеть ваш сайт или приложение с переведенным контентом, но до момента его применения, чтобы вовремя пофиксить все выявленные недочеты в дизайне. Это первая проблема, которую решает “Visual context”. О второй я уже говорил - это проблема восприятия переводчиком слов, фраз, предложений вне контекста, так как в разном контексте могут быть совершенно разные переводы.
Давайте перед тем, как рассмотреть TMGMT Smartling модуль, сначала освежим в памяти как настроить мультиязычность в Drupal 8.
В Drupal 8 все необходимые модули для настройки мультиязычности разработчики включили в ядро, а заодно и привели к единому виду API. Что не может не радовать, если вспомнить как это было в Drupal 7.
Все, что нужно, это 4 модуля. Давайте их рассмотрим. Первый, это language. Собственно первое, что нужно сделать, это включить его и добавить те языки, на которые вы планируете переводить ваш контент. Также этот модуль позволяет настроить правила, по которым Drupal поймет на каком же языке вы хотите видеть запрошенную страницу.
Следующий - locale. С помощью него вы сможете переводить пользовательский интерфейс и строки, добавленные в contrib/custom модулях (при условии, что вы используете соответствующий API).
Идем дальше - content_translation. Название говорит само за себя. Позволяет переводить контент, такой как ноды, термины таксономии, блоки и так далее.
Завершает этот список config_translation. В отличии от предыдущего он позволяет переводить текст, содержащийся в конфиг файлах. Например названия полей, текст во вьюхах и тд.
После того, как мы все это поставили и настроили мы должны решить, какие сущности и их поля должны быть переведены. Это делается на странице “Content language and translation”.
Теперь мы готовы к установке TMGMT.
После включения этого модуля вы сможете добавить и настроить translation провайдеры, о которых я говорил ранее. Также стоит отметить, что TMGMT предоставляет свой workflow.
Так как мы не хотим использовать провайдеры по-умолчанию, то ставим tmgmt_smartling, собственно это и есть Smartling интеграция. С его помощью контент загружается на сервис через API и скачивается обратно в Drupal.
Ну и tmgmt_extension_suit - модуль расширения функционала TMGMT. Он предоставляет несколько интересных вещей, но обо всем по порядку.
Это сторонний контриб модуль, который предоставляет набор инструментов для перевода контента из разных источников (сущности, конфиги, строки). С помощью этого модуля перевод может быть осуществлен как вручную так и с помощью translation сервисов.
Сначала,
Первое, о чем хочется сказать, это интерфейс TMGMT. На слайде мы видим много новых вкладок. Основные - это job, job items, settings, providers и sources. TMGMT оперирует такими сущностями как Job и Job item. Job - это как-бы задача на перевод контента. Все это добавляется в Job как Job item. Job item в свою очередь является представлением контента: ноды, какой-либо сущности, конфига или строки. На них держится ядро TMGMT и на них построен workflow переводов. В дальнейшем Job отправляется на перевод через определенный translation provider.
Translation Providers - это по сути плагины, с помощью которых осуществляется сам перевод и получение его обратно в Drupal. Всю обработку событий “Запросить перевод” или “Скачать/импортировать перевод” берут на себя именно эти плагины. Все они делают это по-разному. Одни работают при помощи импорта/экспорта файлов, другие предоставляют интеграцию с 3rd party сервисами. По умолчанию TMGMT предоставляет два провайдера: local и file.
Но самое интересное, что TMGMT предоставляет возможность добавлять свои провайдеры через систему плагинов (кстати, ранее был доклад на эту тему). Это дает возможность за вменяемые сроки писать интеграции к сторонним сервисам. Именно поэтому TMGMT был взят за основу для написания интеграции со Smartling.
Давайте более детально рассмотрим TMGMT Smartling модуль. Его настройки и как это все работает в принципе.
Чтобы начать работу с определенным сервисом, сначала нужно настроить его translation провайдер. Это делается со страницы “Providers” (кстати страницы, что показаны на слайде, привносит TMGMT модуль, это его интерфейс). Каждый провайдер - это отдельный модуль/плагин. Добавляем Smartling провайдер, сохраняем и переходим к его настройке.
Это - форма настроек провайдера. Настроек огромное количество. Как service-specific так и drupal-specific. Но все мы рассматривать не будем, а затронем только первые 4.
API url - ссылка на api сервиса
Project id - идентификатор проекта в Smartling
Key - API ключ вашего Smartling аккаунта
OrgID - идентификатор организации. Используется для матчинга контекста с переводимой строкой
После настройки провайдера мы готовы к процессу локализации.
На слайде показана страница с таблицей всех translatable сущностей на сайте. То есть тех, что мы настроили на странице Content and Language. Собственно сам процесс запроса перевода сводится к тому, чтобы выбрать нужные сущности и засабмитить форму через “Request translation” сабмит.
TMGMT создает для нас пустую джобу и просит выбрать провайдер, с помощью которого мы хотим осуществить перевод, и целевой язык. Здесь стоит обратить внимание, что TMGMT сам по себе не позволяет запрашивать перевод сразу на несколько языков (о том, как мы это решили расскажу чуть позже). На этом участие друпала в переводе закончено. То есть все, что требуется, это отправить в Smartling файл со строками на перевод. И на этом все.
Собственно, теперь ждем, пока переводчики сделают свою работу, после чего можно будет скачать перевод. Сделать это можно со страницы “Manage” конкретного Job.
Пока все звучит довольно хорошо. Но есть одно но. Даже три но.
Первое, конечно же мы будем переводить более чем одну ноду/термин/что-либо еще. Это значит, что мы будем иметь больше одной job и нам надо будет заходить в каждую из них и нажимать “Download Translation”. Это, конечно же, неприемлемо.
второе, если вы изменили исходную сущность, то в Smartling будет уже заведомо не актуальный перевод. Проблема рассинхронизации того, что в друпале и того, что отправлено в ссервис.
И третье, TMGMT не позволяет создавать job на перевод на несколько целевых языков.
Для решения этих проблем нами был написан модуль TMGMT Extension Suite. Давайте посмотрим на него детальнее.
Первая проблема решается с помощью так называемых Bulk Operations. Как вы знаете, в Drupal 8 ядро вошли модули Views и Views UI, плюс к этому еще добавили простую поддержку балк операций для них. Это нечто похоже на VBO модуль, что существует для Drupal 7. Так вот были добавлены эти самые операции для Job. Job можно отменить, удалить, скачать перевод или загрузить исходный контент в батч режиме. Для Job item добавлена операция отправки контекста.
В ходе написания Action плагина для Views коллега столкнулся с одним интересным багом в ядре Drupal 8. Баг заключается в том, что вы не можете просто взять и сделать batch_set внутри Action плагина. Более детально об этом баге можно почитать по ссылке на слайде.
Баг есть, а решения в issue queue до сих пор нет. Однако все же есть небольшой workaround. Он заключается в том, чтобы добавить ConfirmationForm для вашего Action плагина и уже в нем запускать batch_set. Но при таком подходе нам как-то нужно передать выбранные айтемы в таблице в наш Confirmation шаг. К сожалению, ничего лучше, чем передавать массив выбранных айдишников через Temporary Storage (по сути через сессию) ничего не придумано. Детальнее о том, как это реализовать и обойти баг в ядре, можно почитать в корпоративном блоге по ссылке на слайде.
Вернемся ко второй проблеме, которую решает TMGMT Extension Suit модуль - трэкинг изменений в сорс сущности. Этот функционал включается на странице настройки модуля на табе “Translation” - “Track changes of the translatable entities”. По сути с помощью этого механизма обеспечивается такой flow, при котором администратору или контент менеджеру не нужно вручную отсылать сущность на перевод, если ее отредактировали, все сделается автоматически.
Ну и третья проблема решается расширением формы редактирования Job. То есть теперь есть возможность склонировать редактируемую Job на выбранные целевые языки.
Немного поговорим о том, как это все работает под капотом.
Прежде всего используется API SDK для php. То есть чтобы не изобретать велосипед в каждом коннекторе (Drupal 8, Drupal 7, Wordpress etc.) была написана обертка для Smartling API, которая и используется повсеместно. Стоит сказать, что SDK есть и для других популярных языков, таких как Java, Python и Ruby.
Механизм работает следующим образом. Во-первых мы расширили таблицу job_item, а именно добавили колонку для хранения хэша контента сорс сущности. Хэш берется только от тех полей в сущности, которые включены на перевод.
Во-вторых на entity_update хуке мы берем хэш сущности, переданной в хук, и сравниваем его со значением из базы данных. Если значения отличаются, значит сущность была обновлена и нам нужно выполнить следующий шаг.
А именно отправить сущность на перевод.
Сам процесс общения с сервисом асинхронный. То есть построен на QueueWorker плагинах. Очередя обрабатываются по крону.
Всего у нас 4 вида очереди каждая для своих целей. Итак, первая из них - это очередь на загрузку контекста. Так как генерация контекста довольно долгий процесс (занимает несколько секунд), то мы это дело вынесли в очередь. Соответственно, когда пользователь отправляет Job на перевод у нас в очередь попадает один айтем, который значит “сгенерируй контекст для этой джобы и отправь его в сервис”.
Следующие три очереди реализованы уже в Extension модуле. Именно с помощью них обеспечивается механизм continuous переводов.
Вторая очередь обрабатывает те джобы, у которых изменились сорс сущности. Это как раз тот случай, когда пользователь запросил перевод, а потом обновил ноду, например. В этот момент данная джоба добавляется в очередь на аплоад и будет загружена при следующих вызовах крона.
Собственно, с помощью следующей очереди мы можем узнать, готов ли перевод, или нет. В эту очередь айтемы добавляются по крону. По сути туда попадают открытые джобы при определенных условиях.
Если при обработке айтемов из предыдущей очереди API сообщил нам, что перевод готов и его можно скачать, то модуль добавляет атйтем уже в очередь на скачивание.
Таким образом достигается “непрерывный” процесс локализации в друпал.
Спасибо за уделенное время!
Если есть вопросы, задавайте. С радостью на них отвечу.