Как настроить автоматический перевод контента на WordPress-сайте и не облажаться

Хотя WordPress-сервисов для автоматизации перевода предостаточно, иногда разработчики вынуждены продолжать работать вручную. Этот кейс — о том, что нужно не упираться в принятое решение до последнего, а включаться в ситуацию клиента.

Наш клиент — производитель сигнализаций для дома — обслуживает Америку и Канаду. Его основной сайт работает на английском, но так как в Канаде есть франкоговорящие провинции, а в Америке — штаты с многочисленным испаноговорящим населением, у сайта три языковые версии.

Нашей задачей было перевести тексты основного сайта с английского на французский и испанский и настроить систему управления переводами для дальнейшей работы интернет-магазина.

Хотя WordPress-сервисов для автоматизации перевода предостаточно, иногда разработчики вынуждены продолжать работать вручную. Этот кейс — о том, что не все проблемы клиента решаются техническим путем и что нужно не упираться в принятое решение до последнего, а включаться в его ситуацию.

Магазин клиента был собран при помощи Elementor — плагина-конструктора сайтов на WordPress. Простые страницы, например, контентного типа, можно собрать без проблем из дефолтных блоков, но для более замысловатых страниц нужно создавать кастомные секции.

Когда приходит время переводить тексты на сайте, дефолтные блоки автоматически разбиваются на элементы, приспособленные для перевода по отдельности. (Разработчики называют их «строками», см. картинку). По окончании работ они «склеиваются» с помощью Elementor обратно в цельный блок и перевод обновляется.

Кастомные секции требуют большей подготовки. Содержимое таких секций необходимо предварительно описать в специальном XML-файле, чтобы подготовить к переводу. Дефолтные секции по такому принципу уже описали разработчики Elementor, а кастомные необходимо было описать нам самим.

В документе разработчик прописывает, из каких элементов состоит структура секции и какие из них надо переводить. К примеру, разработанный нами виджет — это слайдер. Слайдер может содержать бесконечное количество слайдов. На каждом слайде есть картинка, заголовок и кусочек текста. Заголовок и текст отмечаются как переводимые элементы этой секции.

Далее XML-файл добавляется в настройки плагина WordPress Multilingual Plugin (WPML), который разбивает переводимый контент на «строки». О нем — в следующем разделе.

Управлять переводом страницы WordPress-сайта можно с помощью многоязычных плагинов. Мы остановили выбор на самом популярном — WPML. Плагин помогает администраторам сайта управлять заказами на перевод, взаимодействовать с переводчиками из агентств и управлять языковыми версиями страниц.

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

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

Процесс выглядит так. Из текстов на перевод формируется XML-документ, который отправляется в сервис. При отправке единице текста назначается ID. Специалист сервиса переводит тексты, помечает их готовыми, и документ отправляется назад, на сайт.

Управлять переводами на разные языки можно из редактора перевода. Он выглядит вот так:

Готовый перевод должен автоматически встроиться на сайт, но система не всегда срабатывает чётко.

Сперва мы попробовали настроить управление переводом через такой переводческий сервис, но постоянно происходили технические сбои, которые затягивали процесс.

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

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

В данном случае нам была важнее гибкость, нежели приверженность технологиям. И вот почему.

Клиент запустил маркетинговую кампанию. Он оплатил рекламу в соцсетях, заказал интеграции у блогеров и делал всё, чтобы привлечь трафик на сайт, но из-за сбоя перевод не отображался на страницах. На чьей стороне происходила ошибка выяснить не получалось, рекламные деньги уходили.

В таком случае важнее просто сделать так, чтобы сайт заработал, и сделать это быстро. По этой причине мы не стали перебирать другие плагины, а прибегли к ручному труду. Их выбор и подключение потребовали бы необоснованной траты времени.

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

Оптимальным вариантом стал следующий алгоритм. Сотрудникам компании, владеющим разными языками, создали админские аккаунты. Когда в текст на основной странице на английском вносятся правки, админы получают уведомление с указанием конкретной «строки» изменений. Они заходят в редактор перевода и оттуда правят испанскую или французскую версию текста. Этот вариант клиент предпочёл автоматизации.

После того как плагин установлен на сайт, стоит внимательно следить за тем, как администраторы сайта вносят правки в контент страниц на разных языках.

При создании новой языковой версии страницы WPML формирует веб-страницу, идентичную оригинальной по структуре, но с добавленным языковым префиксом, например, https://www.alarmsandbeyond.com/es.

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

При этом у пользователя есть возможность закрыть уведомление и продолжить вносить правки в страницу напрямую. В этом случае связь между страницами на разных языках нарушается и они больше не синхронизируются. Теперь админ уже не будет получать уведомления о том, что тексты на оригинальной странице изменились и каких «строк» коснулись изменения. Остаётся только вручную сверять контент на языковых версиях, что неизменно приводит к пропущенным правкам.

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

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