Как мы сделали расширение для локализации контента онлайн-продукта
Здравствуйте. Я Евгений, разработчик интерфейсов в «Яндекс.Практикуме». Основная задача этого проекта — помощь в овладении начальными навыками программирования. Главный плюс сервиса — простота и доступность подачи образовательного материала.
Проблематика
Наш сервис расширяется, мы недавно запустились на рынке США, и перед этим у нас возникла необходимость перевода контента на английский язык.
Когда онлайн-сервисы хотят адаптировать свои продукты на другие языки, они сталкиваются с проблемой: качество переведённого текста хромает, так как переводчики не понимают, где на сайте будет тот или иной абзац, что он описывает и к какому блоку относится. Это может негативно влиять на качество переводов в целом.
Мы решили немного помочь им в этом, а именно прикладывать к каждому переводу изображение с переводом в интерфейсе. Сейчас это выглядит для переводчиков так:
Поиск решения
При решении данной проблемы на ум приходило несколько вариантов:
- Вручную «скринить» интерфейс, выделять переводы и загружать на сервис переводов. Это самое простое и скучное решение. Подойдёт для небольшого количества переводов в проекте, но явно не наш вариант, так как на данный момент у нас около 3200 ключей.
- Написать автоматическую «скриншотилку» с использованием Selenium или чего-то похожего. Это хороший вариант с точки зрения полной автоматизации, но для реализации потребовалось бы много времени, также данное решение не универсально.
- Полуавтоматическая «скриншотилка» на основе Chrome Extension. Использование метода captureVisibleTab даёт возможность делать скриншот активной вкладки в формате Base64. Основная идея: пока тестировщик проходит полный регресс нашего приложения, расширение фотографирует все ключи, которые появляются на экране.
Из всех вариантов мы выбрали третий, потому что на его реализацию требовалось относительно небольшое количество времени, а также в дальнейшем его можно применять в других проектах.
Чтобы всё заработало, необходимо подготовить проект и написать само расширение.
Подготовка проекта
Подготовить проект необходимо для того, чтобы между расширением и страницей стала возможна коммуникация. Расширению нужно уметь находить на экране переводы. Для этого у него должен быть доступ к полному списку переводов и их ключей на странице. Реализовали это через localStorage, так как из расширения есть доступ к данному объекту.
Подготовка проекта заключается в том, чтобы пополнять localStorage переводами. Все переводы прилетают в приложение с сервера, и казалось, что простым решением будет просто добавлять все переводы в localStorage. Но некоторые из них представляют из себя шаблонные строки.
- Пример шаблонной строки: {index} Курс.
- Возможное значение этого перевода на странице: 1 Курс.
Так как на странице нам нужно находить конкретные значения переводов, пришлось искать другие пути. Для интернационализации в проекте используется библиотека react-intl, и для решения этой проблемы мы добавили немного магии WebPack. В конфигурации сборщика добавили следующий код:
При запуске сборки с переменной окружения screenshot_mode добавляем плагин NormalModuleReplacementPlugin, который просто заменит весь код в импортах с react-intl на components/intl. В components/intl/index.js делаем подмену IntlProvider.
В самом IntlProvider подменяем метод getChildContext.
Это нужно для переопределения метода formatMessage. Все трансформации переводов проходят через него. Тут мы ловим все значения текстов, которые попадут в DOM, и складываем их в localStorage.
Первая часть работы готова. Теперь в localStorage будут находиться актуальные переводы.
Пишем расширение
Следующим этапом нужно было написать само расширение. Основной алгоритм его работы:
- Получаем из localStorage все переводы в виде «ключ:значение».
- Фильтруем переводы от тех, на которые уже были сделаны скриншоты.
- Через XPath ищем по всему документу DOM-элементы, в которых находятся переводы.
- Делаем дополнительные проверки DOM-элементов. Необходимо убедиться, что DOM-элемент виден на странице в данный момент, чтобы мы могли сделать хороший скриншот. Проверки состоят из двух этапов: проверка, что DOM-элемент входит в границы видимой области документа, и проверка свойств opacity, display, visibility у элемента и его предков.
- После всех фильтраций формируем массив объектов «ключ:DOM-элемент» и запускаем процесс скрининга.
- На данном этапе мы по очереди подсвечиваем элементы на странице, делаем скриншот и убираем подсветку. Данные скриншотов складываем в локальное хранилище расширения вида «ключ:картинка» в формате Base64.
- После завершения скрининга возвращаемся в первому пункту.
Алгоритм цикличный и выполняется постоянно, потому что при прохождении регресса на странице браузера могут появляться новые элементы с переводами, которые не были видны либо были динамически добавлены в DOM.
Это был первый опыт создания расширений, и гайды от Google помогали во всём разобраться. Ниже описаны основные проблемы, с которыми столкнулись при разработке.
Проблемы при создании расширения
Первая проблема, которая возникла при создании расширения, — это недоступность объекта window из контентных скриптов, куда планировалось сохранять переводы изначально. В итоге решили использовать localStorage для этих целей.
Большое количество изображений занимает много места в локальном хранилище расширения. Чтобы не упереться в ограничение 5 Мбайт, нужно добавить в манифест разрешение unlimitedStorage.
При разработке расширений для Chrome сталкиваешься с различными видами скриптов. У каждого типа скриптов свои доступы к Chrome Extension API.
Например, доступ к документу осуществляется только через content_scripts. Контентные скрипты встраиваются в страницу на определённых доменах, которые настраиваются в манифесте. Всё бы хорошо, но делать скриншоты из контентных скриптов нельзя.
Для этого используются background_scripts. Для коммуникации между разными видами скриптов существуют методы chrome.runtime.sendMessage для отправки сообщений и chrome.runtime.onMessage.addListener для получения. Popup.html и popup.js используются для создания интерфейса расширения при клике на иконку.
К расширению был написан небольшой интерфейс, в котором можно отслеживать количество сделанных скриншотов.
При клике на кнопку «Показать» формируется блок с ключами, и при клике на каждый ключ формируется сделанное изображение. Можно скачать все скрины одним архивом, а можно посмотреть отдельные изображения и удалить их из хранилища, чтобы переснять.
Что делать с картинками дальше
Все картинки выкачиваются в формате JPEG с именами, соответствующими ключам переводов. Остаётся только загрузить все эти картинки на статику и прогнать скрипт, который подставит ссылки на картинки в контекст каждого перевода.
Open source
Код расширения на Github. Там же описаны его возможные настройки. Пользуйтесь на здоровье!