Уяви ситуацію. Ти здаєш переклад технічного мануалу на 200 сторінок. Дедлайн - вчора, клієнт чекає, ти натискаєш “Send” і нарешті видихаєш. А наступного ранку отримуєш листа: 47 зламаних XML-тегів, десяткові розділювачі неправильні в 23 місцях, а термін “клапан” перекладений трьома різними словами по всьому документу. Два дні ручного ріворкінгу. Нервовий клієнт. Пошарпана репутація.
Все це - не помилки некомпетентності. Це помилки неуважності, яких не уникне жодна людина на 200-сторінковому проєкті. І все це можна було зловити за 30 секунд - автоматичним QA-чеком перед відправкою.
Як саме працюють ці перевірки, які тули їх виконують і як побудувати QA-воркфлоу, що реально ловить помилки - розбираємося нижче.
Що таке автоматизовані QA-перевірки і навіщо вони перекладачу¶
Автоматизовані QA-перевірки (Quality Assurance checks) - це програмні алгоритми, які сканують пару “оригінал + переклад” і шукають конкретні патерни помилок. Не “якість тексту” в абстрактному сенсі, а формальні невідповідності: зламаний тег, число в оригіналі, якого немає в перекладі, термін із глосарію, який переклали інакше.
Що вони ловлять:
- Теги і форматування - пропущені, зайві або зламані XML/HTML-теги, плейсхолдери, розмітка.
- Числа - невідповідність чисел між оригіналом і перекладом, неправильні розділювачі тисяч і десяткових.
- Термінологія - порушення глосарію, неконсистентний переклад однакових термінів.
- Пунктуація - відсутня крапка наприкінці сегмента, подвійні пробіли, неправильні лапки.
- Довжина - сегменти, де переклад значно коротший або довший за оригінал (потенційний пропуск або зайвий контент).
- Порожні сегменти - непереведені фрагменти, які просто загубилися.
Чого вони НЕ ловлять: семантичні помилки (переклав “збільшити тиск” як “зменшити тиск”), стилістичні проблеми (текст звучить як калька), неправильний зміст (термін перекладений “правильно” за глосарієм, але в цьому контексті означає інше). Для цього потрібна людина - ревізор або коректор у TEP-моделі.
Автоматичний QA не замінює людську вичитку. Він її доповнює. Ти звільняєш людські очі від нудної рутини (перевіряти 3000 сегментів на предмет зламаних тегів) і фокусуєш людську увагу на тому, що машина не вміє - зміст, стиль, логіка.
memoQ’s QA module can perform over 100 different types of checks on translation documents, including segment-level and document-level checks for consistency, terminology, formatting, and more.
100+ типів перевірок в одному тулі. Жодна людина не зможе систематично виконувати навіть 20 з них на кожному сегменті документа. Автоматика може - і за секунди.
Поширена помилка: ігнорувати QA-варнінги, бо “їх занадто багато і більшість - false positives”. Так, false positives бувають. Але ігнорувати всі варнінги через це - як вимкнути антивірус, бо він іноді ругається на нормальні файли. Краще налаштувати профіль QA під проєкт, ніж вимикати перевірки взагалі.
Перевірки тегів і форматування¶
Теги - це, мабуть, найкритичніша категорія QA-перевірок. Тому що зламаний тег не просто виглядає погано - він може фізично зламати продукт.
Що таке теги в контексті перекладу¶
Коли ти перекладаєш у CAT-тулі, текст часто містить розмітку, яку не видно в кінцевому документі, але яка керує форматуванням і структурою. Ось основні типи:
XML/HTML-теги - <b>текст</b>, <a href="...">посилання</a>, <p>, <div>. Кожен відкриваючий тег повинен мати закриваючий. Пропустив </b> - і весь текст після цього місця стає жирним.
Плейсхолдери - {0}, {1}, %s, %d, {{userName}}, $variable$. Це змінні, які програма підставляє в рантаймі. Видалив {0} - і замість “Привіт, Олена” користувач побачить помилку додатку або порожній рядок.
Розмітка форматування - теги для bold, italic, підрядковий (<sub>), надрядковий (<sup>). У технічній документації з хімічними формулами (H₂O) або математикою (x²) це критично.
Самозакриваючі теги - <br/>, <img src="..." />. Якщо ти їх видалиш або змінив - зникає розрив рядка або зображення.
Чому це критично¶
Один пропущений закриваючий тег у UI-стрінгу мобільного додатку - і все меню рендериться жирним шрифтом. Або, що гірше, додаток крашиться, бо парсер не може обробити невалідний XML.
Реальний приклад: перекладач працює з .xliff файлом для iOS-додатку. У сегменті <b>Settings</b> > <b>Privacy</b> він перекладає як `Налаштування > Приватність