PolyLingo vs Polylang: в чем разница и когда использовать каждый

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

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

Что такое Polylang (и что это не)

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

Ограничение прямо в описании: это плагин WordPress. У него нет API, который можно вызвать вне WordPress. Он не понимает JSON-файлы локализации, Markdown-файлы контента или HTML-шаблоны в проекте Next.js. Вся его модель предполагает, что контент хранится в базе данных WordPress и рендерится WordPress.

Это не критика. Это просто область применения инструмента.

Что такое PolyLingo

PolyLingo — это API перевода. Вы отправляете ему контент (простой текст, Markdown, JSON или HTML), и он возвращает переведённые версии на всех запрошенных языках в одном запросе. Он не зависит от вашего CMS, фреймворка или настройки деплоя. Работает там, где можно сделать HTTP-запрос.

Основная цель дизайна — сохранение формата. Большинство API перевода построены вокруг предложений: вы отправляете строку, получаете строку обратно. Эта модель быстро ломается, когда у вашего контента есть структура. Вставьте JSON-файл локализации в типичный сервис перевода, и вы получите переведённые имена ключей, повреждённые разделители или проза там, где был объект. PolyLingo считает структуру недоступной для изменений. Меняются только строковые значения; всё остальное возвращается точно так, как было отправлено.

Конкретный пример. Вы отправляете:

{"btn": {"save": "Save", "cancel": "Cancel"}}

Переводчик, ориентированный на предложения, может вернуть:

{"button": {"save": "Guardar", "cancel": "Cancelar"}}

Ключ btn стал button. Это сломает ваше приложение. PolyLingo возвращает:

{"btn": {"save": "Guardar", "cancel": "Cancelar"}}

Ключи не тронуты. Переведены только значения.

Тот же принцип применяется к Markdown (заголовки остаются заголовками, блоки кода остаются без изменений, URL ссылок не меняются) и HTML (теги и атрибуты сохраняются, переводятся только текстовые узлы и соответствующие атрибуты).

Реальная разница: область применения

Проще говоря:

Polylang управляет многоязычным контентом внутри WordPress. Это слой CMS. Он управляет тем, какой пост является испанской версией какого английского поста, генерирует переключатели языков и синхронизирует переводы при обновлении контента.

PolyLingo переводит структурированный контент через API. Это слой перевода. Вы даёте ему контент, он возвращает переводы. Что делать с этими переводами — решаете вы.

Они решают смежные задачи, а не одну и ту же. Поэтому сравнение — не "что лучше", а "какая у меня задача".

Когда использовать Polylang

Ваш сайт работает на WordPress, и вы хотите остаться на WordPress
Вам нужен рабочий процесс управления контентом: редакторы переключаются между языковыми версиями, отслеживание статуса перевода, переключатели языков в теме
Вы не разработчик и хотите решение с интерфейсом
Вы используете WooCommerce и вам нужен перевод продуктов, управляемый внутри WordPress

Polylang отлично справляется со всем этим. Если WordPress — ваша платформа, это правильный инструмент.

Когда использовать PolyLingo

Вы строите на Next.js, Nuxt, SvelteKit, Astro или любом другом фреймворке, не связанном с WordPress
Вы используете headless CMS (Contentful, Sanity, Prismic) и нужно переводить контент при публикации или через webhook
Ваш контент хранится в JSON-файлах локализации, которые нужно переводить без повреждения структуры ключей
Вы мигрируете с WordPress и хотите сохранить свой многоязычный рабочий процесс
У вас есть Markdown-контент (блоги, документация, описания продуктов) и нужны переводы, которые не ломают форматирование
Вы хотите переводить на несколько языков одним API-запросом, а не делать запрос на каждый язык

Эндпоинт /translate PolyLingo принимает массив targets, так что один запрос может вернуть все 36 поддерживаемых языков сразу. Для файла локализации, который нужно перевести на десять языков, это один API-запрос вместо десяти.

А как насчёт миграции с WordPress?

Если вы переносите сайт WordPress на headless или статическую платформу, ваш контент Polylang не переносится автоматически. Переводы хранятся как метаданные постов WordPress и не экспортируются чисто в Markdown или JSON.

Практический путь, который выбирают большинство команд:

Экспортируйте контент WordPress в Markdown или JSON (инструменты вроде wordpress-export-to-markdown справляются с механикой)
Используйте PolyLingo для перевода экспортированного контента на нужные языки
Храните полученные файлы в новой структуре контента вместе с исходным языком

Пакетный эндпоинт PolyLingo (POST /translate/batch) создан именно для этого. Вы можете отправить до 100 элементов контента в одном запросе, каждый с собственным форматом, все с одним набором целевых языков. Для миграции сайта с сотнями страниц — это правильный инструмент.

Сравнение бок о бок

	PolyLingo	Polylang
Работает без WordPress	Да	Нет
Сохранение формата (JSON, Markdown, HTML)	Да	Только контент WordPress
Один запрос — все языки	Да	Нет
Доступ к REST API	Да	Нет
UI управления контентом	UI переводчика (без кода)	Полная админка WordPress
Автоопределение формата контента	Да	Н/Д
Поддержка RTL языков	Да	Да
Оплата по использованию	Да	Бесплатный плагин / фиксированная плата Polylang Pro

Кратко

Если вы на WordPress и остаётесь на WordPress: используйте Polylang. Он создан для этой среды и хорошо в ней работает.

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

Обе инструменты могут сосуществовать. Некоторые команды используют Polylang на основном маркетинговом сайте (который остаётся на WordPress) и PolyLingo для сайта документации, UI веб-приложения или шаблонов email. Рабочий процесс одинаков; стек не обязательно.

Попробуйте

Бесплатный тариф PolyLingo включает 100 000 токенов в месяц. Этого достаточно для нескольких блог-постов на десяти языках или среднего файла локализации на 36 языках. Кредитная карта не требуется.

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# Welcome\n\nTranslate **any format** without breaking the structure.",
    "format": "markdown",
    "targets": ["es", "fr", "de", "ja"]
  }'

Начать перевод бесплатно

PolyLingo против Polylang: в чем разница и когда использовать каждый