WPML Compatibility Test Tools - Плагин WordPress

Руководство по проверке совместимости с WPML Compatibility Test Tools

WPML Compatibility Test Tools - это практический инструмент для разработчика WordPress, которому нужно проверить, насколько тема, плагин, блоки, виджеты и пользовательские поля готовы к переводу через WPML. В официальной документации WPML этот же инструмент сейчас называется Multilingual Tools, поэтому дальше в руководстве используется оба названия: заданное название продукта и официальное название интерфейса.

Здесь не будет повторения общей карточки продукта. Вместо этого разберём рабочий процесс: что подготовить до установки, где искать основные разделы Multilingual Tools, как сгенерировать тестовые переводы, как собрать wpml-config.xml, как проверить публичную часть сайта и что делать, если часть строк не попала в переводчик.

Инструмент особенно полезен не владельцу обычного сайта, а тому, кто отвечает за совместимость продукта: автору плагина, разработчику темы, интегратору Elementor-виджетов, команде поддержки или агентству, которое передаёт клиенту мультиязычный WordPress-сайт. Главная ценность плагина - не автоматический перевод, а быстрое обнаружение мест, которые WPML не сможет корректно перевести без конфигурации.

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

Для каких задач нужен этот инструмент

Обычный пользователь WPML переводит страницы, записи, меню, строки темы и настройки плагинов. Разработчик продукта решает другую задачу: убедиться, что его код вообще даёт WPML достаточно информации. Если текст жёстко прописан в шаблоне без gettext-функции, если пользовательское поле содержит ссылку или идентификатор записи, если Elementor-виджет хранит настройки в сложном массиве, переводчик может не увидеть нужные данные или перевести лишнее.

WPML Compatibility Test Tools закрывает промежуток между «мой продукт вроде работает на одном языке» и «мой продукт корректно ведёт себя на сайте с несколькими языками». Он помогает пройти не только визуальную проверку, но и конфигурационную: понять, какие типы записей нужно переводить, какие поля копировать, какие строки брать из wp_options, какие шорткоды и блоки зарегистрировать в конфигурационном файле.

Что именно можно проверить

По официальным материалам Multilingual Tools умеет добавлять языковую информацию к дубликатам записей, автоматически генерировать тестовые переводы строк, помогать с настройками пользовательских полей и генерировать языковой конфигурационный файл wpml-config.xml. Это не заменяет ручной аудит кода, но даёт быстрый способ увидеть, какие элементы остаются без языкового префикса после тестового дублирования.

• Строки, которые должны быть обёрнуты в gettext-функции WordPress.
• Пользовательские типы записей и таксономии, которые нужно переводить или показывать с fallback на исходный язык.
• Пользовательские поля, где нужно выбрать Translate, Copy, Copy once или игнорирование.
• Тексты из таблицы wp_options, например настройки виджетов, заголовки, сообщения и фрагменты из панели параметров темы.
• Шорткоды, Gutenberg-блоки и Elementor-виджеты, которым нужна XML-регистрация.

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

Кому подходит WPML Compatibility Test Tools, а кому он будет лишним

Инструмент полезен там, где мультиязычность нужно не просто включить, а доказать. Разработчик темы может использовать его перед релизом, чтобы проверить шаблоны, параметры внешнего вида и пользовательские поля. Автор плагина может подготовить wpml-config.xml, который будет лежать в корне продукта и избавит пользователей от ручной настройки. Агентство может прогнать клиентский сайт на копии перед запуском дополнительных языков.

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

Подходящие сценарии

• Вы разрабатываете WordPress-плагин и хотите понять, какие настройки должны попасть в wpml-config.xml.
• Вы сделали тему с опциями, пользовательскими типами записей, блоками или виджетами и готовите её к использованию на многоязычных сайтах.
• Вы интегрируете кастомные Elementor-виджеты или Gutenberg-блоки и хотите проверить, видит ли WPML нужные поля.
• Вы сопровождаете сайт клиента и пытаетесь понять, почему часть интерфейса переводится, а часть остаётся на исходном языке.

Когда лучше выбрать другой подход

Если проблема только в переводе .po и .mo файлов, чаще подойдёт Loco Translate или команда wp i18n make-pot. Если нужно полностью управлять многоязычным сайтом, нужен сам WPML, а не тестовый addon. Если продукт не связан с WPML и команда принципиально поддерживает другую систему мультиязычности, стоит смотреть документацию этой системы.

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

Что проверить перед установкой на тестовую копию

Подготовка важнее самой установки. Если открыть инструмент на случайной копии сайта без понимания, что именно проверяется, результат получится шумным: WPML покажет много строк, настроек и полей, но будет трудно отличить реальные проблемы от тестовых артефактов. Сначала нужно определить объект проверки: один плагин, одна тема, конкретный набор блоков, страница с Elementor-виджетами или сценарий WooCommerce.

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

Минимальные зависимости

Официальный репозиторий Multilingual Tools указывает зависимости от WPML Multilingual CMS и WPML String Translation. Документация по Gutenberg-блокам и Elementor-виджетам также требует активного WPML String Translation, потому что именно там появляются зарегистрированные строки и поля. Если этих компонентов нет, тест будет неполным: часть интерфейса может открыться, но проверка строк и XML-конфигурации потеряет смысл.

Данные для проверки

Заполняйте тестовый контент не словом test, а заметными строками: заголовок блока, подпись кнопки, текст карточки, описание товара, подпись изображения, значение поля, пункт меню. Это позволит быстро увидеть на публичной части сайта, какие элементы получили языковой префикс, а какие остались исходными. Пустые поля не дают полезного результата: генераторы XML не всегда могут понять, что нужно регистрировать, если в поле нет данных.

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

Установка и первичная проверка в админ-панели

Установка выполняется как у обычного WordPress-плагина: загрузите архив, перейдите в Plugins, нажмите Add New, затем Upload Plugin, установите и активируйте. Если вы берёте файл из GitHub-репозитория OnTheGoSystems, убедитесь, что это релиз или архив плагина, а не случайная папка исходного кода без нужной структуры. В админ-панели после активации должен появиться раздел Multilingual Tools.

Первый экран, который стоит открыть, - Multilingual Tools -> Overview. Официальная документация описывает его как место, где видно сводку текущего языкового конфигурационного файла. Для разработчика это не просто информационная страница: она помогает понять, загружается ли конфигурация вообще, есть ли ошибки в XML и какие настройки уже применяются.

Порядок первого запуска

1. Проверьте, что WPML уже настроен хотя бы с одним дополнительным языком.
2. Активируйте только те плагины, которые нужны для тестового сценария.
3. Откройте WPML -> Theme and plugins localization и просканируйте тему или плагин на строки.
4. Откройте Multilingual Tools -> Overview и проверьте, есть ли ошибки конфигурации.
5. Перейдите в Multilingual Tools -> Settings и выберите элементы, к которым нужно добавить языковую информацию при дублировании.

Не спешите сразу генерировать конфигурационный файл. Сначала нужно понять, видит ли WPML базовые gettext-строки. Если строка не обёрнута в __(), _e(), esc_html__() или другую подходящую функцию WordPress, XML-конфигурация не исправит сам факт жёстко прошитого текста. Она помогает описать данные, поля и структуры, но не превращает неподготовленный код в переводимый.

Быстрая проверка после установки: если раздел Multilingual Tools не появился, проверьте активность WPML-компонентов и права пользователя. Если раздел есть, но данные пустые, сначала просканируйте тему или плагин в WPML -> Theme and plugins localization.

Настройка Multilingual Tools после установки

Настройка инструмента состоит из нескольких рабочих зон. Не все они нужны в каждом проекте. Для простого плагина со строками интерфейса достаточно сканирования и проверки строк. Для темы с настройками, кастомными типами и полями важнее генератор wpml-config.xml. Для Elementor-виджетов и Gutenberg-блоков нужен отдельный сценарий с заполненной тестовой страницей.

Раздел Overview

Overview полезен как контрольная точка. Здесь вы смотрите, какие правила уже загружены и нет ли очевидных проблем с конфигурацией. Если тема или плагин уже содержит wpml-config.xml, раздел помогает убедиться, что WPML его видит. Если конфигурация размещена удалённо или переопределяется через настройки WPML, здесь можно заметить несоответствие до того, как тестировать публичную часть.

Раздел Settings

В Settings выбираются элементы, к которым Multilingual Tools будет добавлять языковую информацию при дублировании. Официальный сценарий предлагает прокрутить до блока Add language information to post duplicate, отметить нужные элементы и сохранить настройки. Практически это означает: вы заранее решаете, где хотите увидеть языковой префикс, чтобы потом сравнить исходную и дублированную версию страницы.

Если тестируете пользовательские поля, включайте только те поля, которые реально выводятся на странице. Если включить всё подряд, можно получить много шума и потратить время на элементы, которые пользователь никогда не видит. Если тестируете строковые источники, используйте выпадающий список в Auto generate strings translations, выберите нужные источники и нажмите Generate strings translations.

Раздел Configuration File

Configuration File нужен для генерации wpml-config.xml. Именно этот файл сообщает WPML, как обрабатывать данные продукта: переводить тип записи, копировать числовое поле, переводить подпись, зарегистрировать текст из wp_options, обработать шорткод или указать блок Gutenberg. Готовый XML нельзя принимать вслепую. Его нужно прочитать, убрать служебные поля и протестировать через WPML -> Settings -> Custom XML Configuration.

Какие значения выбирать для пользовательских полей

Официальная документация WPML различает четыре базовых действия для пользовательских полей. Translate подходит для текста, который должен отличаться по языкам. Copy подходит для чисел, идентификаторов и технических значений, которые должны синхронизироваться. Copy once удобно для значения, которое нужно скопировать при создании перевода, но потом разрешить менять отдельно. Игнорирование подходит для служебных полей, которые не должны попадать в перевод.

Как безопасно откатить спорную настройку

Если после сохранения XML часть страницы стала вести себя неверно, не меняйте сразу код продукта. Сначала удалите или закомментируйте спорный фрагмент в Custom XML Configuration, сохраните настройки и обновите тестовую страницу. Затем повторите перевод или сделайте небольшое изменение исходного контента, чтобы WPML заново пересобрал доступные поля в редакторе. Такой откат безопаснее, чем правка файлов темы или плагина прямо в рабочем коде.

Проверка строк, полей и wpml-config.xml в реальном цикле

Рабочий цикл состоит из пяти этапов: подготовить строки, просканировать продукт, выбрать элементы для теста, создать дубликат через WPML и проверить публичную часть. Важно пройти цикл целиком. Если остановиться на генерации XML, можно пропустить ошибку вывода. Если смотреть только публичную часть без XML, трудно понять, почему одно поле переводится, а другое нет.

Сначала проверьте код на gettext. WordPress и WPML сходятся в базовом правиле: пользовательский текст в PHP должен быть передан через функции интернационализации, а текстовый домен должен соответствовать продукту. Пример ниже не является готовой правкой для этого плагина, но показывает безопасный принцип для собственного кода темы или расширения.

<?php
echo esc_html__( 'Book a consultation', 'my-plugin' );
?>

Такой фрагмент не требует правки ядра WordPress или WPML. Его место - собственный плагин, дочерняя тема или исходный код продукта, который вы поддерживаете. После изменения нужно снова просканировать тему или плагин в WPML -> Theme and plugins localization, затем проверить появление строки в WPML -> String Translation.

Тест через дублирование контента

Официальный сценарий предлагает использовать WPML -> Translation Dashboard, выбрать контент и отправить его как дубликат. Multilingual Tools добавит языковой префикс к выбранным элементам. После этого откройте публичную часть сайта и переключите язык. Если текст получил префикс, значит он прошёл через механизм перевода или копирования. Если часть текста осталась исходной, именно она требует настройки или исправления кода.

Генерация и проверка XML

Для wpml-config.xml держите простое правило: генератор даёт черновик, а разработчик принимает решение. В черновике могут оказаться технические поля, логические флаги, идентификаторы или служебные значения, которые нельзя отдавать переводчику. Удаляйте всё, что не должно меняться по языкам, и оставляйте только контентные элементы, ссылки, подписи, заголовки, описания и те идентификаторы, для которых WPML умеет подобрать перевод.

Хорошая проверка XML - это не отсутствие ошибки сохранения, а появление правильных полей в Advanced Translation Editor и корректный результат на публичной странице. Поэтому после сохранения конфигурации обязательно откройте перевод заново, посмотрите набор полей в редакторе и проверьте страницу как посетитель.

Особые сценарии: Gutenberg-блоки, Elementor-виджеты и шорткоды

Именно в этих сценариях инструмент становится особенно полезным. Стандартные записи и поля WPML умеет обрабатывать предсказуемо, а вот конструкторы и кастомные блоки часто хранят данные в JSON, массиве метаполя или HTML-разметке. Поэтому WPML должен знать, какие ключи, атрибуты и ссылки нужно переводить, а какие лучше оставить как есть.

Кастомные Gutenberg-блоки

Документация WPML по Gutenberg-блокам рекомендует создать страницу, добавить нужные блоки, заполнить все поля, опубликовать страницу и затем взять сгенерированный XML из секции WPML: Gutenberg Blocks. Это важно: если поле не заполнено, генератор может не понять, что его нужно включить. Для изображений нужно отдельно учитывать подписи, альтернативный текст и ссылки, если они должны отличаться по языкам.

После генерации XML его вставляют в WPML -> Settings -> Custom XML Configuration, сохраняют, затем делают небольшое изменение на странице и открывают перевод через языковую панель. Если поля блока появились в редакторе, регистрация работает. Если появились лишние технические значения, XML нужно почистить.

Кастомные Elementor-виджеты

Для Elementor официальная документация описывает WPML - Config Generator for Elementor. Он читает значение _elementor_data, преобразует его в массив и помогает получить XML для полей виджета. Здесь особенно важно заполнить все опции виджета перед тестом, потому что незадействованные параметры могут не попасть в черновой код.

Дополнительные инспекционные блоки полезны при диагностике: WPML Config XML, RAW value from _elementor_data, Array generated from _elementor_data и Extracted Widgets from _elementor_data. Если ваш виджет не отображается в извлечённых элементах, проблема может быть не в переводчике, а в том, как виджет хранит данные или регистрирует свои настройки.

Шорткоды и тексты внутри атрибутов

Шорткод может содержать видимый текст в атрибутах или выводить жёстко прописанную строку в PHP. Для первого случая помогает регистрация шорткода в wpml-config.xml; для второго нужна gettext-обёртка в коде. Не смешивайте эти причины. Если текст задан прямо внутри функции шорткода, XML не исправит его без подготовки исходного кода.

Практический пример: проверяем плагин с карточкой услуги

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

Цель

Нужно добиться, чтобы заголовок, описание и текст кнопки были доступны в переводчике WPML, цена и цвет копировались без ручного перевода, а связанная страница корректно подменялась на перевод при отображении публичной части. После проверки должен получиться чистый фрагмент wpml-config.xml, который можно перенести в продукт.

Подготовка

1. Создайте копию сайта и активируйте WPML, WPML String Translation, проверяемый плагин и Multilingual Tools.
2. Создайте тестовую карточку услуги с уникальными строками: названием, описанием, текстом кнопки и ссылкой.
3. Убедитесь, что шорткод или блок выведен на отдельной странице.
4. Просканируйте плагин в WPML -> Theme and plugins localization.

Шаги проверки

1. Откройте Multilingual Tools -> Settings и выберите элементы, которые хотите пометить языковой информацией при дублировании.
2. Если есть строки из настроек плагина, выберите нужный источник в Auto generate strings translations и нажмите Generate strings translations.
3. Откройте WPML -> Translation Dashboard, выберите тестовую страницу и создайте дубликат на втором языке.
4. Перейдите на публичную часть сайта, переключите язык и проверьте карточку услуги.
5. Если часть элементов не получила языковой префикс, вернитесь к генератору конфигурации и настройкам полей.

Ожидаемый результат и нюанс

В идеальном результате видимые текстовые элементы получают языковой признак или появляются в переводчике, числовые и служебные поля не требуют перевода, а ссылка ведёт на языковую версию связанной страницы. Если кнопка или подпись осталась без префикса, проверьте два места: зарегистрирован ли текст как строка и не хранится ли он внутри массива или JSON-поля, которое нужно описать в XML.

Мини-итог практического примера: сначала докажите, что WPML видит данные, затем решайте, как именно их переводить. Ошибка многих проверок - сразу писать большой XML, не убедившись, что тестовая страница покрывает все реальные элементы продукта.

Как проверить результат после настройки

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

Редактор перевода

Откройте перевод тестовой страницы через языковую панель. В Advanced Translation Editor должны быть только те поля, которые человеку действительно нужно переводить. Не должно быть технических ключей, цветовых флагов, случайных идентификаторов, пустых настроек и логических переключателей. Если они появились, это сигнал очистить XML до передачи пользователям.

Публичная часть сайта

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

Повторяемость после обновления

Сделайте небольшое изменение в исходной записи, например поменяйте текст кнопки или значение поля, затем обновите перевод. Если поле должно синхронизироваться, проверьте, что оно обновилось. Если поле должно переводиться отдельно, убедитесь, что перевод не перезаписался исходным значением. Так вы увидите, правильно ли выбрали Translate, Copy или Copy once.

Частые проблемы и диагностика без риска для сайта

Проблемы совместимости с WPML часто выглядят одинаково: текст не переводится, ссылка ведёт не туда, поле пропало из редактора или на странице виден исходный язык. Но причины разные. Ниже собраны симптомы, которые логично проверять именно при работе с Multilingual Tools и языковой конфигурацией.

Строка не появляется в String Translation

Симптом: текст виден на странице, но после сканирования темы или плагина его нет в WPML -> String Translation. Возможная причина - строка не обёрнута в gettext-функцию WordPress, текстовый домен отличается от домена продукта или строка создаётся динамически так, что сканер её не видит. Проверьте исходный код и используйте документацию WordPress по интернационализации. Исправление делайте только в своём коде, дочерней теме или поддерживаемом расширении.

Поле появилось в редакторе, но его не надо переводить

Симптом: в редакторе перевода видно техническое поле, числовой параметр, цвет, идентификатор или служебный ключ. Причина обычно в слишком широком XML. Уберите поле из конфигурации или измените действие на Copy, если оно должно синхронизироваться. Откат простой: удалите спорный фрагмент из Custom XML Configuration, сохраните и повторите тест.

Ссылка или идентификатор остаётся от исходного языка

Симптом: переведённая карточка ведёт на исходную запись, товар или страницу. Причина может быть в том, что идентификатор хранится как обычное поле и WPML не знает, что его нужно конвертировать. В документации WPML для пользовательских полей и Gutenberg-блоков описаны атрибуты для объявления post-ids и taxonomy-ids. Используйте их только для полей, где действительно лежат идентификаторы объектов WordPress.

Генератор Elementor не видит кастомный виджет

Симптом: страница создана через Elementor, но в секции генератора нет нужного виджета или поля. Проверьте, добавлен ли виджет на страницу, заполнены ли все его настройки и опубликована ли страница. Затем смотрите диагностические блоки RAW value from _elementor_data и Extracted Widgets from _elementor_data. Если виджет отсутствует в извлечённых данных, сначала разберитесь с хранением данных виджета, а не с WPML-переводом.

XML сохраняется, но результат на странице не меняется

Симптом: ошибок в Custom XML Configuration нет, но публичная часть не показывает ожидаемый перевод. Проверьте кеш, обновление исходной записи, повторное открытие перевода и то, откуда шаблон берёт данные. Если продукт кэширует собственный вывод или хранит собранную разметку отдельно, может потребоваться очистка кеша продукта или пересохранение тестовой страницы.

Доступ к XML или файлу блокируется сервером

В поддержке WPML встречается сценарий, где доступ к XML через Multilingual Tools возвращал ошибку доступа. Там рекомендовалось временно оставить только нужные WPML-компоненты, переключиться на стандартную тему и проверить на локальном сервере, чтобы исключить влияние защиты, прав файлов или хостинга. Для тестового инструмента это разумный путь: сначала изолировать среду, затем искать конкретную причину.

Как подготовить итоговый файл для релиза продукта

После успешного теста у вас должен остаться не только вывод «на тестовой странице всё работает», но и воспроизводимый артефакт: чистый wpml-config.xml, список проверенных сценариев и понимание, какие изменения нужны в коде. Для плагина или темы конфигурационный файл обычно размещают в корневой папке продукта, чтобы WPML мог читать его автоматически. Если вы проверяете клиентский сайт, конфигурацию можно оставить в WPML -> Settings -> Custom XML Configuration, но лучше хранить её вместе с документацией проекта.

Перед переносом в релиз перечитайте XML как интерфейс для будущего переводчика. Всё, что переводчик увидит в редакторе, должно быть понятно и переводимо. Технические поля, флаги состояния, системные массивы и внутренние идентификаторы не должны попадать в редактор без причины. Для ссылок и идентификаторов используйте специальные типы WPML только там, где они действительно соответствуют данным.

Что записать в отчёт о проверке

Хороший итоговый отчёт не должен быть длинным, но он должен позволять другому разработчику повторить тест. Укажите адрес тестовой страницы, список включённых WPML-компонентов, проверяемую тему или плагин, языки, активные элементы Multilingual Tools и краткий результат по каждому типу данных. Отдельно отметьте, какие поля были намеренно исключены из перевода. Через несколько месяцев это сэкономит время, потому что команда не будет заново выяснять, почему служебное поле скопировано, а не переведено.

Сохраняйте не только финальный XML, но и причину выбора каждого важного режима. Например, поле с ценой копируется, потому что это числовое значение; подпись кнопки переводится, потому что её видит посетитель; идентификатор связанной записи копируется с объявлением типа, потому что WPML должен подставить перевод. Такой комментарий можно держать в документации проекта, в pull request или в отдельном файле тестового сценария.

Как передавать результат пользователям или команде поддержки

Если вы автор продукта, включите wpml-config.xml в релиз и добавьте короткую заметку в документацию: какие элементы поддерживаются, какие сценарии проверены, есть ли ограничения для кастомных блоков или виджетов. Если вы работаете над клиентским сайтом, передайте команде поддержки не только файл конфигурации, но и список страниц, на которых проверялась публичная часть. Совместимость с WPML лучше считать проверенным сценарием, а не общей декларацией.

Для сложных продуктов полезно разделить отчёт на базовую и расширенную проверку. Базовая закрывает gettext-строки, пользовательские поля и типы записей. Расширенная проверяет Elementor, Gutenberg, шорткоды, JavaScript-строки, динамические ссылки и повторное обновление перевода. Если после релиза пользователь сообщает, что не переводится конкретный блок, вы сразу увидите, входил ли он в расширенный сценарий или требует отдельной доработки.

Мини-чек-лист перед передачей

• Все пользовательские строки в коде обёрнуты в gettext-функции WordPress с правильным текстовым доменом.
• Пользовательские типы записей и таксономии имеют осознанный режим перевода.
• Поля с текстом переводятся, числа и технические значения копируются или игнорируются.
• Gutenberg-блоки и Elementor-виджеты проверены на заполненной тестовой странице.
• Шорткоды зарегистрированы только для тех атрибутов, где есть видимый текст или переводимая ссылка.
• Публичная часть проверена после переключения языка и после повторного обновления исходного контента.

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

Когда WPML Compatibility Test Tools будет удачным выбором

Инструмент стоит использовать, когда вам нужно не просто перевести сайт, а подготовить WordPress-продукт к предсказуемой работе с WPML. Он особенно силён в проверке конфигурации: помогает увидеть, что попадёт в перевод, что будет копироваться, где нужен wpml-config.xml и какие элементы остаются вне языкового сценария.

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

Если вы работаете с темой, плагином, Elementor-виджетом, Gutenberg-блоком или набором пользовательских полей, начните с копии сайта и маленького, но полного тестового сценария. Так WPML Compatibility Test Tools покажет не абстрактную совместимость, а конкретные места, где ваш продукт готов к переводу или требует доработки.