DeepL проти Google Translate проти ШІ: Що краще для файлів .po?

Ви експортуєте файл .pot зі свого плагіна WordPress, вставляєте кілька сотень рядків у DeepL або Google Translate, отримуєте акуратний німецький стовпчик, завантажуєте його у свій файл .po, компілюєте та випускаєте. Потім користувач повідомляє, що на сторінці кошика відображається необроблений %1$s замість назви продукту, або, що ще гірше, рядок ціни читається як You have 1 items у кожній мові, оскільки форма множини була втрачена. Якість перекладу була нормальною. Структура перекладу була зруйнована.

Це основна проблема в дебатах DeepL проти Google Translate, коли джерелом є файл gettext .po, а не абзац прози. Обидва сервіси є світовими лідерами у перекладі природних речень. Жоден з них не був розроблений для поваги до плейсхолдерів printf, масиву множини Gettext або розрізнення msgctxt. Вони розглядають %1$s як друкарську помилку, яку потрібно виправити, а двоформову множину як єдине речення для спрощення. Для маркетингових текстів це непомітно. Для локалізації програмного забезпечення це ламає сайти.

Ця публікація порівнює класичний машинний переклад — DeepL та Google Translate — зі ШІ-пайплайном, що враховує контекст і спеціально розроблений для gettext. Ми розглянемо аспекти, які справді важливі для файлів .po: обробка плейсхолдерів, форми множини, контекст, підтримка пакетної обробки файлів та вартість. Якщо ви бажаєте глибше обговорити якість LLM-порівняння, ми розглянули це в статті Якість перекладу ШІ: Gemini проти GPT-4 проти DeepSeek. Тут питання є вужчим і більш практичним: що найкраще для файлів .po?

DeepL проти Google Translate: Для чого вони створені

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

DeepL – Плавний, але сліпий до формату

DeepL широко хвалять за найбільш природне звучання перекладу, особливо для європейських мов. Але він обробляє текст, а не структуру. Якщо ви подасте йому msgid з файлу .po, що містить %1$s ordered %2$s, він перекладе слова навколо плейсхолдерів, часто змінюючи порядок, пробіли або пропускаючи токени — тому що для DeepL це просто дивні символи в реченні.

Google Translate – Широке покриття, та ж сліпа пляма

Google Translate підтримує набагато більше мов і є бюджетним варіантом за замовчуванням для таких плагінів, як GTranslate. Його обробка плейсхолдерів не краща. Обидва механізми мають одне й те ж фундаментальне обмеження: вони оптимізують плавність речення і не мають моделі правил gettext.

Справжнє питання не в якості – а в структурі

Для файлів .po чиста лінгвістична якість є базовою вимогою. Те, що руйнує виробництво, – це структурна цілісність: чи зберігаються змінні, чи залишаються множини багатоформними, чи враховується контекст. Саме тут ШІ-пайплайн, що враховує gettext, випереджає як DeepL, так і Google Translate.

Чому плейсхолдери та множини ламають машинний переклад

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

Спотворення плейсхолдерів та змінних

Рядки WordPress переповнені плейсхолдерами в стилі printf: %s, %d, а також позиційними формами, такими як %1$s та %2$s. Позиційні важливі, оскільки деякі мови змінюють порядок слів у реченні, а числа вказують sprintf, який аргумент куди розмістити. Подивіться, що робить класичний машинний переклад з цим:

// Source string in your .po file
$msg = sprintf( __( '%1$s left a comment on %2$s', 'mytheme' ), $user, $post );

// What DeepL / Google Translate often return (German):
// "%2$s hat einen Kommentar zu %1$s hinterlassen"  <- reordered, OK
// "% 1$ s hat einen Kommentar..."                   <- spaces injected, BROKEN
// "hat einen Kommentar hinterlassen"                <- placeholders dropped, BROKEN

Один вставлений пробіл (% 1$ s) або пропущений токен викликає попередження PHP або виводить необроблений код для ваших користувачів. Ми детально розбираємо цей режим збою в статті як перекладати файли PO без порушення кодових змінних.

Згортання форм множини

Множина Gettext – це не один рядок, а масив, ключований правилом множини для даної мови. Англійська має дві форми; польська – три; арабська – шість. Класичний машинний переклад отримує msgid_plural як два окремі речення і перекладає їх незалежно, без усвідомлення того, що вони повинні залишатися цілісним багатоформним набором. Результатом часто є дублювання однієї форми, тому 1 item та 5 items відображаються ідентично.

msgid "%d item in your cart"
msgid_plural "%d items in your cart"
msgstr[0] ""
msgstr[1] ""
# A gettext-aware pipeline fills BOTH forms correctly with %d preserved.
# DeepL/Google translate each line in isolation and lose the plural relationship.

Контекст (msgctxt) ігнорується

Gettext використовує msgctxt для розрізнення ідентичних рядків – «Post» як іменник проти «Post» як дієслово, або «Order» як іменник проти дієслова в WooCommerce. Класичний машинний переклад ніколи не бачить це поле контексту, тому він вгадує, і вгадує однаково щоразу, незалежно від того, де з'являється рядок.

Збитки посилюються в комерції. Каталог WooCommerce повний коротких, неоднозначних рядків – «Order», «Ship», «Free», «View» – де неправильне трактування призводить до кнопки, яка говорить не те, що потрібно мовою клієнта. Оскільки DeepL та Google Translate перекладають кожен рядок ізольовано, вони не можуть використовувати навколишній контекст, який gettext свідомо кодує. Пайплайн, що враховує формат і читає msgctxt, вирішує саме ці неоднозначності, тому це найважливіше на сторінках магазину, де неправильні переклади коштують реальних продажів.

Підхід ШІ з урахуванням контексту для файлів .po

Спеціально розроблений gettext-пайплайн не просто перекладає слова — він розуміє формат файлу та захищає його структуру. Це відмінність на рівні категорії, і саме тому правильне порівняння — це не DeepL проти Google Translate взагалі, а класичний машинний переклад проти ШІ-робочого процесу, що враховує формат.

Блокування синтаксису захищає кожен токен

Вирішальна техніка – це Блокування синтаксису. Перед тим, як будь-який текст потрапляє до ШІ, кожна змінна (%s, %1$s, {name}), HTML-тег та кодовий токен блокуються та відкладаються. Модель бачить і переписує лише слова, які читаються людиною. Після перекладу заблоковані токени відновлюються на своїх правильних позиціях. Спотворення % 1$ s просто не може статися, тому що ШІ взагалі не торкається плейсхолдера. Це та захисна сітка, якої структурно бракує класичному машинному перекладу – аспект, який ми детальніше розглядаємо в ручний переклад проти ШІ: чи безпечний ШІ для локалізації WordPress.

Повна підтримка множини та контексту

Пайплайн, що враховує gettext, читає msgid_plural як набір і генерує всі необхідні форми для правила множини цільової мови, зберігаючи плейсхолдери недоторканими в усіх них. Він також читає msgctxt і використовує його як контекст, тому «Order» як іменник і «Order» як дієслово перекладаються по-різному та правильно.

Пакетна обробка файлів, а не копіювання-вставка

DeepL та Google Translate – це інструменти типу «встав у вікно» (або API для кожного символу). Хмарний робочий процес для .po файлів приймає весь файл – і за допомогою розумної пакетної обробки (Smart Batching), пакети рядків WooCommerce розміром 10 МБ+ розділяються на частини, перекладаються паралельно та об'єднуються, тоді як підхід копіювання-вставки розвалюється задовго до цього. Ви завантажуєте файл і завантажуєте .po + .mo + більше, замість того, щоб вручну зшивати стовпці.

DeepL проти Google Translate проти ШІ, що враховує Gettext: Вердикт

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

Порівняльна таблиця

Як обрати

Якщо ви перекладаєте допис у блозі або маркетингову сторінку, зверніться до DeepL для збереження тону. Якщо ви перекладаєте файл .po або .pot, призначений для активного сайту WordPress, плавність не є вирішальним фактором – вирішальною є структурна цілісність. ШІ-пайплайн, що враховує gettext, надає вам і те, й інше: високу лінгвістичну якість і плейсхолдери, множини та контекст, які залишаються неушкодженими аж до скомпільованого .mo.

Існує також вартість робочого процесу, яку таблиця недооцінює. Проведення всього плагіна через DeepL або Google Translate означає копіювання стовпців рядків у вікно, вставлення результатів назад і ручну перевірку кожного плейсхолдера – виснажливий, схильний до помилок процес, який погіршується з кожною додатковою мовою. Файловий пайплайн згортає це в одне завантаження та вивантаження і повертає не тільки .po, але й скомпільований .mo та інші формати в одному ZIP-архіві, тому файл, який ви відправляєте, є файлом, виробленим ШІ – без ручного повторного збирання, де можуть з'явитися нові помилки.

Висновок

Чесна відповідь на питання DeepL проти Google Translate для файлів .po полягає в тому, що ви запитуєте про неправильних учасників. Обидва є чудовими перекладачами прози, і обидва структурно сліпі до gettext – вони спотворюють %1$s, спрощують множини та ігнорують msgctxt, тому що вони ніколи не були створені для читання файлу перекладу. Для локалізації програмного забезпечення це різниця між чистим випуском і зламаною сторінкою кошика.

ШІ-пайплайн, що враховує контекст, з Блокуванням синтаксису повністю змінює порівняння. Він відповідає плавності, яку ви очікуєте від DeepL або Google Translate, гарантуючи при цьому, що кожна змінна, форма множини та контекстна примітка залишаються недоторканими – тому ваш перекладений сайт працює, а не просто добре читається.

Готові перекладати файли .po без спотворених плейсхолдерів або втрачених множин? Спробуйте SimplePoTranslate безкоштовно – кредитна картка не потрібна. Завантажте свої файли .po, .pot, .json або .xliff та отримайте безпечні для gettext переклади ШІ на безкоштовному тарифному плані.