Перекладайте шаблони Elementor & Divi, не порушуючи макетів

Ви все зробили правильно. Придбали преміум-тему, знайшли файл .po, ретельно переклали його та завантажили .mo до папки з мовами. Рядки в заголовку теми оновлюються коректно. Футер відображається іспанською. Ваш WooCommerce checkout локалізовано. Але потім ви відкриваєте головну сторінку, і кожен заголовок, кнопка та текстовий блок, створені за допомогою Elementor, все ще англійською.

Ви перевіряєте файл .po. Бачите англійські рядки в коді. Перекладаєте знову. Нічого не змінюється. Очищаєте кеш. Нічого не змінюється. Ви переконуєте себе, що щось зламалося, доки хтось на форумі м'яко не вказує: Elementor (як і Divi, Beaver Builder та Bricks) не зберігає вміст у файлах .po. Ніколи цього не робив. Ви боролися з проблемою, яку неможливо вирішити за допомогою підходу, який ви використовуєте.

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

Чому Elementor та Divi не використовують файли .po

Файли .po зберігають рядки, які знаходяться в коді — виклики __( 'Shop', 'mytheme' ), розкидані по PHP-шаблонах. Інструмент збірки WP-CLI може витягувати ці рядки в шаблон .pot, перекладачі працюють з файлами .po, а скомпільовані файли .mo завантажуються під час виконання.

Вміст конструкторів сторінок відрізняється. Коли ви вводите «Welcome to our store» у віджет заголовка Elementor, цей текст не знаходиться в жодному PHP-файлі. Він зберігається як JSON (Elementor) або фрагмент шорткоду (Divi) у таблиці wp_postmeta, пов'язаній з дописом, куди ви його помістили.

Де насправді зберігається вміст конструкторів сторінок

Elementor зберігає дерево віджетів кожної сторінки в postmeta під ключем _elementor_data. Відкрийте будь-який допис у базі даних, і ви знайдете JSON-масив, що описує кожен розділ, стовпець та віджет, з вбудованими налаштуваннями та вмістом:

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi зберігає вміст своїх сторінок як шорткоди, вбудовані в post_content:

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder та Oxygen дотримуються тієї ж схеми зі своїм власним форматом. Жоден з цих типів вмісту ніколи не зачіпається файлами .po / .mo.

Що ж таки знаходиться у файлах .po

Сам плагін конструктора сторінок має рядки інтерфейсу користувача — мітки кнопок в редакторі, повідомлення про помилки, адміністративні сповіщення. Вони знаходяться у файлах .po і перекладаються вашими файлами .mo у wp-content/languages/plugins/. Ось чому люди зазвичай плутаються: вони перекладають рядки «Elementor» і бачать інтерфейс редактора іспанською, але фактичний вміст, який вони створили за допомогою цих віджетів, залишається англійською.

Ця відмінність також є основною причиною половини запитів у нашому посібнику з усунення несправностей, пов'язаних з відсутністю перекладів — читач очікує, що файли .mo впливатимуть на вміст, який вони бачать на фронтенді, але вміст знаходиться в базі даних, а не в коді.

Що файли .po насправді покривають на сайті з конструктором сторінок

Дозвольте провести чітку межу між цими двома, щоб ви точно знали, що обробляє кожен тип файлу.

Файли .po / .mo перекладають

• Рядки шаблонів теми: get_template_part, жорстко закодований текст у header.php, footer.php, functions.php.
• Рядки інтерфейсу плагінів: WooCommerce checkout, адміністративні мітки Yoast, мітки полів Contact Form 7.
• Інтерфейс плагінів конструкторів сторінок: кнопки редактора Elementor, повідомлення про підтвердження збереження Divi.
• Динамічні рядки, які плагіни виводять на фронтенд: WooCommerce «Add to cart», «Out of stock», підсумки кошика.

Файли .po / .mo НЕ перекладають

• Текст заголовків, абзаців, кнопок, введений у віджети Elementor.
• Підписи зображень, ефекти наведення, заголовки акордеонів всередині модулів Divi.
• Вміст у багаторазових шаблонах, глобальних розділах, збережених блоках.
• Мітки користувацького CSS або вбудовані скрипти всередині віджетів конструктора.

Ось чому документація авторів тем щодо перекладу є технічно правильною, але часто марною для кінцевих користувачів. Наш посібник як локалізувати будь-яку тему WordPress, навіть якщо ви не розробник ретельно висвітлює сторону теми — ця публікація починається там, де та закінчується.

Два шляхи локалізації конструкторів сторінок

Існує рівно два способи перекладу вмісту конструкторів сторінок, і обидва мають свої компроміси.

Шлях перший: Дублювання сторінок для кожної мови

Використовуйте багатомовний плагін, такий як WPML, Polylang або TranslatePress. Він створює копію кожної сторінки для кожної мови. В Elementor ви дублюєте весь макет і замінюєте текст на кожній копії. У Divi ви копіюєте фрагмент шорткоду і перекладаєте текст між тегами.

Плюси: Кожна мова може мати незалежно розроблені макети (корисно, коли перекладений текст довший і порушує ваш оригінальний дизайн). Повна сумісність з візуальним редактором конструктора сторінок.

Мінуси: Лінійне масштабування — 5 мов означає 5-кратну роботу над макетом. Будь-яка зміна дизайну повинна бути застосована 5 разів. База даних швидко зростає. Кешування стає складнішим.

Шлях другий: Рівень перекладу рядків

Деякі плагіни (Polylang Pro, модуль WPML String Translation, TranslatePress) можуть виводити окремі рядки всередині віджетів конструктора сторінок для перекладу, а потім замінювати їх під час рендерингу. Ви підтримуєте один макет, а плагін перекладає рядки на місці.

Плюси: Єдине джерело істини для макета. Зміни дизайну застосовуються скрізь.

Мінуси: Менша гнучкість, коли перекладений текст значно змінює довжину. Деякі віджети (складні з вкладеним вмістом, динамічними списками, формами) не виводять рядки чисто. Вартість продуктивності за кожен рендеринг.

Наше порівняння Polylang vs WPML vs TranslatePress детальніше охоплює компроміси кожного плагіна.

Збереження розмітки віджетів під час перекладу

Незалежно від обраного шляху, перекладений вміст повинен зберігати структурну розмітку конструктора. Якщо ваш перекладач видаляє шорткод Elementor, замінює атрибут даних або змінює порядок вкладених тегів, віджет відобразиться некоректно.

Небезпечні зони Elementor

Віджети Elementor вбудовують шорткоди та динамічні теги в текстові налаштування. Поле заголовка віджета може містити:

Welcome to <strong>our</strong> [user_name] store

Цей [user_name] — це динамічний тег — Elementor замінює його на ім'я зареєстрованого користувача під час рендерингу. Якщо переклад пошкоджує його, користувачам відображається буквальний «[user_name]».

Іконки всередині кнопок використовують атрибути класів, які не повинні перекладатися. Альтернативний текст зображення зберігається окремо від URL зображення. Макети стовпців використовують налаштування, специфічні для контрольних точок (title_mobile, title_tablet), які потребують індивідуальної обробки.

Вкладення шорткодів Divi

Шорткоди Divi вкладаються глибоко: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Перекладач, який обробляє фрагмент як звичайний текст, закодує квадратні дужки, перекладе значення атрибутів або втратить закриваючі теги. Будь-яка з цих дій пошкоджує модуль, і Divi відмовляється його відображати.

Безпечний шаблон

Для обох конструкторів переклад повинен:

1. Аналізувати формат віджета (JSON для Elementor, AST шорткоду для Divi).
2. Проходити по дереву, ідентифікуючи лише видимі користувачеві текстові поля.
3. Заблокувати шорткоди, динамічні теги, HTML-атрибути та вбудований CSS.
4. Надсилати перекладачеві лише текстові поверхні з контекстом.
5. Повторно вставляти перекладений текст в оригінальну структуру.

Це той самий принцип, який наш движок застосовує до файлів .po. Посібник з перекладу файлів .po без порушення змінних коду детально розглядає шаблони %s та плейсхолдерів — еквівалентом для конструкторів сторінок є шорткоди та динамічні теги.

Гібридний робочий процес, який дійсно працює

Для більшості команд практичною відповіддю є поєднання обох підходів.

Крок 1: Перекладіть інтерфейс теми та плагінів за допомогою файлів .po

Експортуйте файли .pot з вашої теми та ключових плагінів (WooCommerce, Yoast, UI конструктора сторінок). Перекладіть їх один раз за допомогою хмарного перекладача, який поважає формат .po. Завантажте скомпільовані файли .mo до wp-content/languages/. Це дозволяє обробити 80% рядків інтерфейсу вашого сайту з майже нульовим поточним обслуговуванням.

Крок 2: Виберіть багатомовний плагін для динамічного вмісту

Встановіть Polylang або WPML для вмісту дописів, сторінок та продуктів. Налаштуйте структуру URL (/es/, /fr/) та теги hreflang. Це надасть вам інфраструктуру для вмісту бази даних для кожної мови.

Крок 3: Вибірково дублюйте шаблони конструктора сторінок

Для високотрафікових цільових сторінок, головних сторінок та ключового маркетингового контенту дублюйте сторінку кожною мовою та перекладайте віджети вручну. Ви отримуєте повний контроль над дизайном там, де це важливо.

Крок 4: Використовуйте переклад рядків для повторюваних блоків

Для глобальних розділів, багаторазових шаблонів та CTA у футері, які з'являються на кожній сторінці, використовуйте функцію перекладу рядків вашого багатомовного плагіна. Оновлюйте в одному місці, замінюйте під час рендерингу.

Крок 5: Проведіть перевірку якості

Перекладений вміст конструктора сторінок повинен відображатися без зсувів макета. Довші мови (німецька, російська) можуть порушувати ширину кнопок. Коротші мови (китайська, японська) залишають незручні пробіли. Тестуйте кожен шаблон для кожної мови перед запуском.

Поширені підводні камені та як їх уникнути

Кілька пасток, які зустрічаються в кожному проекті локалізації конструктора сторінок.

Альтернативний текст зображення не перекладається

Elementor та Divi зберігають альтернативний текст для кожного екземпляра віджета, а не в Медіатеці. Переклад оригінального зображення не перекладає альтернативний текст у кожному віджеті, який його використовує. Оновлюйте альтернативний текст на кожній дубльованій сторінці.

Форми та користувацькі поля

Контактні форми, вбудовані у віджети конструкторів сторінок, мають власні рядки (мітки, плейсхолдери, повідомлення про валідацію). Дивіться наш посібник з перекладу Gravity Forms та Contact Form 7 для сторони форм.

Глобальні віджети та шаблони

Зміни в глобальному шаблоні поширюються на кожну сторінку, яка його використовує, включаючи перекладені копії. Це може бути корисним або катастрофічним залежно від того, чи хочете ви спільний або окремий вміст. Вирішуйте це явно для кожного шаблону.

Закінчення терміну дії кешу перекладу

Конструктори сторінок агресивно кешують відрендерений HTML. Після перекладу очистіть всі кеші, включаючи кеш CSS Elementor (Elementor > Tools > Regenerate CSS) та статичний кеш CSS Divi.

Збираємо все докупи

Переклад сайту, створеного за допомогою Elementor або Divi, не складніший, ніж переклад статичної теми — він просто вимагає правильної ментальної моделі. Рядки теми та плагінів знаходяться у файлах .po і передаються через файли .mo. Вміст конструктора сторінок знаходиться в базі даних і передається через багатомовні плагіни або ручне дублювання. Змішування цих двох шляхів є найпоширенішим джерелом розчарування «чому мої переклади не працюють».

Робочий процес, який приносить успіх, є нудним: статичні файли .mo для всього, що знаходиться в коді, багатомовний плагін для вмісту сторінок та ручне курування для цінних цільових сторінок. Жоден інструмент не обробляє всі три, і той, хто обіцяє вам інше, щось вам продає.

Готові перекласти файли .po вашої теми та плагінів, не порушуючи розмітки віджетів? Спробуйте SimplePoTranslate безкоштовно — кредитна картка не потрібна. Завантажте .po, завантажте безпечні переклади, помістіть до wp-content/languages/.