Як виправити розмиті переклади у файлах .po WordPress

Ви переклали кожен рядок. Ви зберегли файл, завантажили .mo і оновили свій сайт. І все ж, кілька міток все ще вперто залишаються англійською. Ви відкриваєте файл .po, знаходите рядок, і він там, ідеально перекладений. То чому ж WordPress його ігнорує?

Відповідь майже завжди полягає у маленькому прапорці, що ховається над записом: #, fuzzy. Розмитий переклад – це спосіб gettext сказати: "цей переклад може бути неправильним, тому поки що не довіряйте йому." І що важливо, WordPress відмовляється відображати розмиті рядки на робочому сайті, повертаючись замість цього до оригінальної англійської. Це одна з найбільш неправильно зрозумілих причин проблеми "мій переклад не відображається".

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

Що насправді означає прапорець Fuzzy?

Прапорець fuzzy – це маркер, який gettext додає до запису перекладу, щоб вказати, що переклад є невизначеним і потребує перевірки людиною. У вихідному файлі .po він виглядає як спеціальний коментар безпосередньо над рядком.

#: includes/cart.php:88
#, fuzzy
msgid "Add to cart"
msgstr "Im Warenkorb"

Цей рядок #, fuzzy повідомляє кожному інструменту, що підтримує gettext, включаючи WordPress, що msgstr під ним є тимчасовим. Переклад існує, але gettext не вважає його підтвердженим.

Чому WordPress пропускає розмиті рядки

Ось поведінка, яка застає всіх зненацька. Коли WordPress компілює або читає файл .mo, він розглядає розмиті записи як неперекладені. Рядок технічно присутній у файлі, але WordPress навмисно ігнорує його та замість цього показує оригінальний msgid.

Отже, з вашої точки зору, переклад "готовий", він є у файлі. Але з точки зору WordPress, цей рядок не має надійного перекладу, тому він відображає англійське джерело. Саме тому каталог, що виглядає завершеним, все ще може відображати неперекладений текст на інтерфейсі сайту.

Цей дизайн є навмисним і, справедливості заради, розумним. Вся суть прапорця fuzzy полягає в тому, щоб запобігти прихованому публікуванню неперевірених, потенційно неправильних перекладів. Уявіть рядок, який спочатку читався як "Delete account" і був пізніше змінений на "Deactivate account." Якби gettext сліпо зберіг старий переклад, ваші користувачі могли б побачити кнопку з написом "Delete account", яка насправді лише деактивує його – небезпечна невідповідність. Приховуючи розмиті рядки, gettext змушує людину підтвердити, що переклад все ще відповідає новому значенню, перш ніж він дійде до когось. Прапорець – це механізм безпеки, а не помилка.

Чому прапорці Fuzzy постійно з'являються?

Прапорці fuzzy не випадкові. Вони генеруються автоматично інструментами gettext у двох основних ситуаціях, і розуміння обох підкаже вам, як їх запобігти.

Вихідний рядок змінився

Найпоширеніша причина – оновлення джерела. Уявіть, що розробник змінює рядок у наступній версії плагіна з "Add to cart" на "Add to basket." Коли ви об'єднуєте новий шаблон з вашим існуючим перекладом, gettext бачить, що джерело більше не відповідає тому, що ви переклали спочатку. Замість того, щоб викинути ваш старий переклад, він зберігає його, але позначає як fuzzy, по суті кажучи: "англійська змінилася, тому, будь ласка, перевірте ще раз, чи ваш переклад все ще підходить."

Автоматичне зіставлення за допомогою пам'яті перекладів та msgmerge

Друга причина – fuzzy-зіставлення під час об'єднання. Інструмент msgmerge оновлює старий файл перекладу відповідно до нового шаблону, і коли він знаходить вихідний рядок, схожий, але не ідентичний попередньому, він копіює старий переклад і позначає його як fuzzy.

# Merge a new template into an existing translation.
# Similar-but-changed strings get marked #, fuzzy automatically.
msgmerge --update awesome-plugin-de_DE.po awesome-plugin.pot

Пам'ять перекладів у настільних редакторах поводиться так само: коли вона автоматично заповнює пропозицію з близького збігу, вона позначає результат як fuzzy, щоб ви пам'ятали його перевірити. В обох випадках прапорець виконує свою роботу. Проблема лише в тому, що розмиті записи залишаються неперевіреними, і WordPress їх тихо приховує.

Існує третє, більш підступне джерело, про яке варто знати: інструменти для копіювання-вставки та масового імпорту. Деякі платформи перекладу та скрипти імпорту за замовчуванням позначають кожен запис як fuzzy як консервативний захід, очікуючи, що людина підтвердить кожен з них згодом. Якщо ви імпортуєте каталог з іншої системи і виявляєте, що кожен рядок раптом став fuzzy, це зазвичай є причиною. Переклади можуть бути абсолютно правильними, але доки прапорці не будуть зняті, жоден з них не з'явиться на вашому сайті. Знання джерела прапорців підказує вам, чи дійсно потрібно переглядати кожен запис, чи безпечно впевнено виконувати масове очищення.

Як знайти та виправити розмиті рядки?

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

Виправлення розмитих рядків у Poedit

Poedit робить це найпростішим. Відкрийте файл .po і використовуйте елементи керування пошуку та фільтрації, щоб показати лише розмиті записи, вони мають колірне кодування (зазвичай помаранчеве), тому відразу виділяються. Клацніть на кожному з них, підтвердьте або виправте переклад, а потім вимкніть стан fuzzy за допомогою клавіатурного скорочення (Редагувати, потім "Translation is Fuzzy," або ярлик, показаний у меню). Коли ви зберігаєте, Poedit перекомпілює чистий .mo, і тепер підтверджені рядки відображатимуться на вашому сайті. Якщо ви новачок у цьому редакторі, повний посібник Poedit детально описує робочий процес фільтрації та перегляду.

Виправлення розмитих рядків у командному рядку

Для автоматизації або великих каталогів командний рядок швидший. Ви можете підрахувати розмиті записи і, після того як ви їх масово перевірите, зняти прапорці, щоб WordPress їх завантажив.

# Count how many fuzzy strings remain
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po | grep -c "msgid"

# Clear all fuzzy flags (only after you trust the translations)
msgattrib --clear-fuzzy --empty awesome-plugin-de_DE.po \
  --output-file=awesome-plugin-de_DE.po

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

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

# Extract only the fuzzy entries for focused review
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po \
  --output-file=fuzzy-only.po

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

Після зняття прапорців завжди перезберігайте або перекомпілюйте файл .mo. Стан fuzzy знаходиться в .po, але WordPress читає бінарний .mo, тому, доки ви його не згенеруєте заново, ваш інтерфейс буде продовжувати показувати англійську, навіть якщо .po виглядає чистим. Poedit перекомпілює автоматично при збереженні; у командному рядку ви запускаєте msgfmt awesome-plugin-de_DE.po -o awesome-plugin-de_DE.mo. Забуття цього останнього кроку компіляції є однією з найпоширеніших причин, чому щойно очищений від fuzzy каталог все ще не відображається: переклад підтверджено у вихідному файлі, але бінарний файл, який насправді завантажує сайт, застарів.

Зауважте, що розмиті записи часто з'являються разом із множинними рядками, де змінений msgid_plural може позначити весь блок множини як fuzzy. Якщо ваш беклог fuzzy рясніє лічильниками та кількостями, наш посібник Множини Gettext та складна плюралізація пояснює, чому ці записи особливо крихкі під час об'єднань.

Масштабне очищення беклогу fuzzy

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

Чистіше рішення – перекласти розмиті записи заново, а не просто "штампувати" застарілі збіги. Коли ви обробляєте каталог через SimplePoTranslate, контекстно-орієнтований ШІ створює актуальний, підтверджений переклад для кожного зміненого рядка, тож ви не просто видаляєте попереджувальний прапорець, а замінюєте невизначені збіги справжніми перекладами. Блокування синтаксису зберігає кожен %s, %1$s, {count} та HTML-тег неушкодженим під час обробки, а Розумна пакетна обробка обробляє великі каталоги після оновлення за один раз. Ви отримуєте чистий ZIP-архів з файлами .po, .mo, .json, .php та .xliff, без залишків fuzzy-беклогу, готовий до розгортання з хмари.

Варто відрізняти це від ширшого питання про те, чому переклади взагалі не відображаються. Прапорці fuzzy є однією конкретною причиною, але відсутні файли .mo, неправильні імена файлів та невідповідності локалі викликають той самий симптом. Щоб отримати повний діагностичний перелік, перегляньте наш посібник з усунення несправностей для перекладів, які не відображаються у WordPress, який розглядає розмиті рядки як один пункт у більшому списку.

Готові очистити весь беклог fuzzy та зробити так, щоб кожен рядок відображався на вашому сайті? Спробуйте SimplePoTranslate безкоштовно — кредитна картка не потрібна. Безкоштовний рівень заново перекладає ваш файл .po, замінюючи невизначені fuzzy-збіги чистими, підтвердженими перекладами.