Клієнт виходить з України на Польщу і питає: «Ввімкнемо плагін перекладу – і можна продавати?» Не зовсім так. Переклад тексту – це, мабуть, п’ята частина роботи. Решта – валюта, спосіб оплати, який реально працює в тій країні, юридичні сторінки, що відповідають місцевому законодавству, і пошукова видача, яка показує правильну мовну версію правильному відвідувачу, а не карає сайт за дублікати.
Ця стаття – про те, як усе це виглядає технічно: які є підходи залежно від платформи, як побудувати URL-структуру, навіщо возитися з hreflang і що саме забувають перекласти найчастіше.
Коли справа не тільки в мові
Уявімо магазин одягу, що продає в Україні й починає відправляти замовлення в Німеччину. Мало перекласти картки товарів німецькою. У Німеччині покупці звикли платити через Klarna чи SOFORT, а не карткою одним кліком, як звикли в Україні. Ціни там показують з ПДВ, включеним у ціну, – і це не побажання, а вимога. Термін повернення товару – 14 днів за законом ЄС, і якщо на сайті написано інше, це вже проблема з юристами, не з копірайтингом.
Мультимовність – це радше локалізація ринку, де мова лише найпомітніша частина. Валюта, платіжні методи, доставка, повернення, показ цін – усе це міняється разом з мовою, хоч технічно й лежить в інших налаштуваннях.
Технічні підходи залежно від платформи
Тут все залежить від того, на чому побудований магазин.
WordPress: Polylang або WPML
Для WooCommerce найчастіше беруть Polylang або WPML. Різниця приблизно така: Polylang простіший і безкоштовний у базовій версії, але переклад товарів доводиться синхронізувати вручну або через додаткові модулі. WPML дорожчий, зате має String Translation і роботу з ACF-полями з коробки, що для магазину з купою кастомних атрибутів товару часто вирішує справу. Обидва плагіни створюють окремий пост для кожної мовної версії сторінки й пов’язують їх між собою – саме це дає можливість показувати перемикач мов і правильні hreflang-теги.
Нюанс, який часто пропускають: категорії, теги й атрибути товарів теж потрібно перекладати окремо, вони не підтягуються автоматично з перекладу самого товару.
OpenCart: мовні пакети з коробки
В OpenCart мультимовність вбудована в ядро – сторонній плагін не потрібен. Встановлюєш мовний пакет через Extensions, додаєш мову в Localisation → Languages, і кожен товар, категорія чи інформаційна сторінка отримує окремі поля для кожної підключеної мови просто у формі редагування. Мінус у тому, що валюти й мови в OpenCart – не одне й те саме: валюту треба налаштовувати окремо в Localisation → Currencies, і без ручного зв’язування з мовою покупець з Німеччини цілком може побачити грн замість євро.
Laravel або кастомна розробка
Тут мультимовність – вже інженерна задача, а не налаштування плагіна. Локаль зазвичай визначається з префіксу URL через middleware (route group з параметром {locale}), тексти інтерфейсу лежать у файлах resources/lang, а контент товарів – окремими полями в базі (наприклад name_ua, name_en, name_de або окрема таблиця перекладів). Плюс такого підходу – повний контроль над тим, що і як перекладається, включно з логікою показу цін і валют по країнах. Мінус – усе це треба спроєктувати заздалегідь: додати мультимовність в готовий кастомний магазин заднім числом набагато дорожче, ніж закласти її на старті.
URL-структура: піддиректорії, піддомени чи окремі домени
Є три варіанти, і вибір впливає на SEO більше, ніж здається на перший погляд.
- Піддиректорії (shop.com/ua/, shop.com/en/) – найпростіший варіант технічно, весь авторитет домену працює на всі мовні версії одразу. Саме це використовують Polylang і WPML за замовчуванням.
- Піддомени (ua.shop.com, en.shop.com) – зручно, якщо мовні версії обслуговують різні команди чи навіть різні системи, але Google частково сприймає піддомени як окремі сайти, тож вагу доведеться нарощувати для кожного окремо.
- Окремі домени (shop.ua, shop.de) – максимальна довіра локальної аудиторії, людям звичніше купувати на місцевій зоні, але це й окреме SEO-просування, окремі беклінки, окрема репутація з нуля для кожного домену.
Для більшості магазинів, що виходять на дві-три нові мови без окремого бюджету на просування кожної як самостійного сайту, піддиректорії – розумний дефолт. Окремі домени виправдані, коли на ринку є юридична вимога до локальної реєстрації бізнесу – така історія трапляється, наприклад, при виході в деякі країни Близького Сходу.
hreflang: навіщо це Google і що ламається без нього
Без hreflang Google бачить дві сторінки з дуже схожим контентом різними мовами і сам вирішує, яку показати користувачу з Варшави – угадує нечасто. Гірше – це може розцінюватися як дублювання контенту, навіть коли дублікату по суті немає, просто різні мови.
Тег hreflang в head сторінки каже пошуковику: ось ця сторінка українською, а ось її аналог польською, показуй кожному свою. Виглядає це приблизно так:
<link rel=”alternate” hreflang=”uk” href=”https://shop.com/ua/product” />
<link rel=”alternate” hreflang=”pl” href=”https://shop.com/pl/product” />
<link rel=”alternate” hreflang=”x-default” href=”https://shop.com/” />
Polylang і WPML генерують ці теги автоматично, тому в WordPress найчастіша причина поломки – не сам плагін, а кешування сторінки статичним кешем, який після додавання нової мови ще якийсь час віддає стару версію head без оновлених тегів. У кастомних рішеннях hreflang треба прописувати вручну для кожної пари сторінок – і саме тут найлегше забути одну мовну версію під час додавання нового товару: картка виходить без пари, посилання hreflang веде в нікуди.
Що насправді потрібно перекласти
Тексти на сторінках товарів – очевидна частина. Менш очевидна:
- Meta title і meta description для кожної мовної версії – якщо залишити українські мета-теги на англійській сторінці, Google просто гірше зрозуміє, про що вона.
- Alt-тексти зображень – впливають і на SEO, і на доступність для людей зі скринрідерами.
- Листи з підтвердженням замовлення, зміною статусу доставки, скидом пароля – покупець з Німеччини, який отримав лист українською після оформлення замовлення, довіри це не додає.
- Сторінки checkout: назви полів форми, повідомлення про помилки валідації, кнопки оплати.
- Юридичні сторінки – умови повернення, політика конфіденційності, публічна оферта. Тут мало просто перекласти, треба ще перевірити, чи відповідає зміст місцевому законодавству.
Типові помилки
Найчастіша – перекласти все машинним перекладачем і залишити так. Для внутрішньої документації це нормально, для публічного сайту, що продає, – ні: носій мови одразу відчує неприродні формулювання, а в юридичних текстах машинний переклад може просто спотворити зміст пункту про повернення коштів.
Друга – забути про checkout. Буває так: картки товарів перекладені бездоганно, а кнопка оплати й поля форми – досі мовою оригіналу. Покупець доходить до кінця воронки і губиться саме там, де мало відбутися замовлення.
Третя – hreflang, що вказує сам на себе або на неіснуючу сторінку. Трапляється, коли переклад товару видаляють, а посилання на нього з інших мовних версій залишається.
І остання, менш технічна: запускати нову мовну версію без жодного, хоча б побіжного, рев’ю носієм мови. Автоматичний переклад плюс п’ятнадцять хвилин людини, яка реально говорить цією мовою, – і половина незручностей зникає ще до запуску.
Читайте також: Скільки коштує кастомний інтернет-магазин на Laravel в Україні: від чого залежить ціна; Як відкрити інтернет-магазин в Україні: повний гайд для початківців.
