PolyLingo проти Polylang: у чому різниця і коли використовувати кожен
By Robert M
PolyLingo проти 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 веб-додатку або шаблонів електронної пошти. Робочий процес однаковий; стек не обов’язково.
Спробуйте
Безкоштовний рівень 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"]
}'