Мультиязычный WooCommerce с Polylang: как настроить магазин без путаницы в товарах

Мультиязычный WooCommerce-магазин — это не задача формата «перевести несколько страниц и добавить переключатель языка». В интернет-магазине связаны товары, вариации, категории, атрибуты, цены, остатки, корзина, checkout, письма и URL. Если настроить только тексты, а связи между сущностями оставить без контроля, быстро появляются дубли, разные остатки в переводах и проблемы с навигацией.

Для WordPress один из практичных вариантов — Polylang вместе с Polylang for WooCommerce. В такой архитектуре каждый перевод товара остаётся отдельной записью WordPress, а коммерческие данные, которые должны быть общими, синхронизируются между языковыми версиями.

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

Что именно нужно перевести в WooCommerce

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

• названия и описания товаров;
• короткие описания;
• категории и теги;
• глобальные атрибуты и их значения;
• страницы магазина, корзины, checkout и аккаунта;
• URL и части адресов, если используется перевод slug;
• системные строки темы и плагинов;
• письма WooCommerce;
• меню, хлебные крошки и служебная навигация;
• SEO title и description для каждой языковой версии.

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

Какие данные нельзя дублировать независимо

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

В официальной документации Polylang for WooCommerce указано, что между переводами синхронизируются SKU, цена, налоговые данные, вес, размеры, shipping class и складские остатки. Для вариативных товаров синхронизируются также остатки вариаций и связанные пользовательские атрибуты.

Это ключевой принцип архитектуры:

Почему глобальные атрибуты особенно важны

В WooCommerce атрибуты используются не только для текста в карточке товара. Они участвуют в вариациях и фильтрах. Размер, цвет, объём и другие характеристики лучше создавать как глобальные атрибуты, если они повторяются в каталоге.

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

Официальная документация WooCommerce по категориям, тегам и атрибутам: Managing Product Categories, Tags and Attributes. Документация Polylang по продуктам: Managing WooCommerce Products.

Вариативные товары нужно проверять отдельно

Самые частые ошибки проявляются не на простых товарах, а на товарах с вариациями. Например, футболка имеет размеры S, M и L и несколько цветов. Для каждой комбинации могут быть свои цена, остаток, изображение или статус наличия.

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

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

URL и SEO: отдельная часть задачи

Мультиязычный сайт должен иметь однозначные адреса языковых версий. Обычно используется один из вариантов: директории вида /en/, поддомены или отдельные домены. Конкретная структура зависит от проекта и текущей индексации.

Polylang поддерживает языковые URL и технические SEO-механизмы вроде hreflang. В Pro-версии можно дополнительно управлять переводом slug. Но сам факт наличия hreflang не заменяет нормальную SEO-структуру.

• у каждой языковой страницы должен быть свой title и description;
• категории и карточки не должны создавать хаотичные дубли;
• канонические URL должны соответствовать реальной структуре;
• внутренние ссылки должны вести на язык пользователя;
• sitemap должен содержать корректные индексируемые страницы;
• не стоит машинно переводить URL без проверки смысла и поискового интента.

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

Корзина и checkout должны сохранять язык

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

Polylang for WooCommerce рассчитан на перевод основных страниц WooCommerce и синхронизацию покупательского сценария. Но на реальном проекте обязательно нужно отдельно проверить плагины оплаты, доставки, one-click checkout, кастомные поля и сторонние AJAX-блоки.

Особенно внимательно тестируют:

• checkout blocks или классический checkout;
• платёжные шлюзы;
• доставку и ПВЗ;
• купоны;
• кастомные поля заказа;
• мини-корзину;
• письма клиенту;
• личный кабинет;
• кэширование страниц и AJAX.

Что делать с валютами

Язык и валюта — разные сущности. Русская версия сайта не обязательно означает одну валюту, а английская — другую. Если магазину нужна мультивалютность, её лучше проектировать отдельно и проверять совместимость выбранного валютного решения с Polylang и WooCommerce.

Не стоит привязывать валюту к языку жёстко без бизнес-причины. Пользователь может читать английскую версию, но оплачивать в локальной валюте.

Как переносить существующий магазин на Polylang

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

1. Сделать резервную копию базы и файлов.
2. Проверить версию WordPress, WooCommerce, темы и ключевых плагинов.
3. Составить список типов товаров: simple, variable, grouped, subscriptions и другие расширения.
4. Проверить глобальные атрибуты и категории.
5. Определить языковую URL-структуру.
6. Настроить один тестовый язык и один тестовый товар.
7. Проверить синхронизацию цены, SKU и остатка.
8. Проверить вариации, корзину и checkout.
9. Только после этого переносить основной каталог.

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

Импорт товаров и внешние интеграции

Отдельная зона риска — импорт из CRM, ERP, МойСклад, поставщика или собственного API. Внешняя система обычно не знает о WordPress-переводах. Если интеграция каждый раз создаёт новый товар по названию, мультиязычность быстро приведёт к дублям.

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

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

Как тестировать магазин перед запуском

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

• товар открывается на каждом языке;
• категория содержит правильные товары;
• фильтры используют переведённые атрибуты;
• вариации выбираются без ошибок;
• остатки совпадают между языками;
• цены совпадают там, где должны;
• корзина сохраняет товар при переключении языка;
• checkout остаётся на выбранном языке;
• оплата и доставка работают;
• письмо приходит на правильном языке;
• заказ в админке содержит корректные данные;
• URL не создают дублей и 404.

Когда нужен разработчик, а не только переводчик

Если магазин простой и использует стандартный WooCommerce, большая часть работы действительно выполняется настройками и переводом контента. Но при наличии кастомных карточек, Elementor-шаблонов, фильтров, API, CRM, нестандартного checkout или импортов уже требуется техническая проверка связей.

Задача разработчика — не перевести текст, а сохранить целостность магазина: одну складскую модель, корректные товары и вариации, правильные URL, рабочую корзину, платежи и интеграции.

Если у вас уже есть WooCommerce-магазин и нужно добавить второй или третий язык, можно начать с технического аудита текущей структуры. Я проверю каталог, плагины, атрибуты, вариации, checkout и интеграции и предложу безопасный план внедрения. Подробнее об услуге: WooCommerce-разработка и техническая поддержка WordPress.

Для оценки достаточно прислать ссылку на магазин, список нужных языков и перечень ключевых плагинов через форму связи A.S Groups.