Уяви: відкриваєш звіт Xbench на 500 рядків. Там є можливий пропуск, розбіжність у числі, невідповідність тегів і десятки зауважень до термінів, які в контексті перекладені правильно. Якщо йти згори донизу й виправляти кожен рядок, витратиш час на шум і ризикуєш змінити добрий переклад.
Краще сприймай кожен рядок як сигнал для перевірки, а не як наказ щось виправити. Спершу відсортуй сигнали за тим, наскільки вони можуть змінити зміст або функцію тексту. Потім відсіюй повторювані хибні спрацювання й готуй звіт для передавання.
Що означають попередження Xbench¶
Xbench QA - це набір автоматизованих перевірок, які шукають у файлах потенційні проблеми. Результат перевірки не доводить, що в перекладі є помилка. Він показує місце, яке варто переглянути.
Документація Xbench описує ці перевірки як пошук сегментів із потенційними проблемами. Програма перевіряє неперекладений текст, узгодженість джерела й перекладу, теги, числа, URL, буквено-цифрові послідовності, пари розділових знаків, повторені слова й пробіли. Також Xbench шукає ключові терміни, перевіряє контрольні списки й орфографію (перелік перевірок Xbench).
Через таку різноманітність у звіті поруч опиняються рядки з дуже різними наслідками. Пропущене речення й подвійний пробіл можуть потрапити до одного списку, але для читача й проєкту це не рівнозначні проблеми.
Тримай у голові три різні поняття:
- Попередження - автоматичний сигнал про можливу проблему.
- Хибне спрацювання - сигнал, який після перевірки виявився прийнятним перекладом або неактуальною перевіркою.
- Підтверджена помилка - проблема, яку перевірив редактор і яка порушує зміст, вимогу проєкту або функцію тексту.
Специфікація MQM теж розрізняє автоматичний сигнал і помилку: програма може підсвітити потенційну проблему, а людина під час перевірки з’ясує, що переклад правильний. Наприклад, термін може не повторюватися дослівно, бо в реченні його замінив займенник (специфікація MQM).
У специфікації MQM зазначено: “If human examination finds that the term was translated improperly, it is an error. However, examination might also find that the issue was not an error because the linguistic structure in the translation dictated that the term be replaced by a pronoun, so the translation is correct.”
Простими словами: система помічає, що терміна немає, але не знає, що граматика вимагає займенника. Перевір речення повністю, а не виправляй його через сам сигнал.
Ще одна корисна відмінність: тип перевірки не дорівнює рівню ризику. Попередження про тег може бути критичним, якщо тег керує посиланням або змінною, і нешкідливим, якщо йдеться лише про форматування. Сигнал про число може стосуватися важливої суми або числа у назві версії, яке змінювати не треба.
Універсальної кнопки «прибрати шум» тут немає. Спочатку з’ясуй вимоги проєкту, призначення тексту й наслідки можливої помилки. Документація Xbench пояснює доступні перевірки, але не задає єдиної черговості виправлень для всіх команд.
Як розставити пріоритети у звіті на 500 рядків¶
Наведена нижче черговість - практичний спосіб сортувати результати за потенційною шкодою, а не офіційна шкала Xbench. Якщо проєкт має власні критерії якості, вимоги клієнта й правила обробки помилок, вони важливіші за цю загальну схему.
Спершу шукайте можливу втрату змісту¶
Почни із сегментів із неперекладеним текстом, пропущеними фрагментами й очевидною розбіжністю між джерелом і перекладом. Запитай себе: чи зберіг переклад усю інформацію, яка впливає на розуміння або виконання дії?
Прочитай вихідний і цільовий сегменти поруч. Якщо речення розділене на частини або посилання на попередню інформацію винесене окремо, перевір і сусідні сегменти. Автоматична перевірка може знайти порожній сегмент, але не завжди знає, чи порожнім він мав бути.
Далі звір числа й URL. Не кожна числова розбіжність означає помилку: число може змінитися через формат локалі або правила проєкту. Але дати, суми, розміри, коди й інші важливі для інструкції значення не варто губити серед косметичних спрацювань. Зістав значення з джерелом і перевір формат за домовленостями проєкту.
URL перевіряй не лише на наявність. Звір адресу повністю, зокрема символи, які легко пропустити під час читання. Якщо посилання не має змінюватися в перекладі, однієї неправильної літери вистачить, щоб воно перестало працювати.
Потім перевірте теги, що впливають на функцію¶
Теги можуть позначати форматування, посилання, змінні, службові фрагменти й інші елементи, від яких залежить результат у програмі. Перевір не лише кількість тегів, а й їхнє місце та контекст. Чи працюватиме рядок після імпорту? Чи відкриється посилання? Чи не опинилася змінна поза потрібним фрагментом?
Не кожну різницю між тегами треба виправляти. Для перевірок узгодженості Xbench пропонує параметр Ignore Tags: він дає змогу порівнювати текст, що збігається, навіть коли вбудовані теги різняться (документація про QA-перевірки). Добирай налаштування під конкретне завдання, а не використовуй їх, щоб приховати незрозумілу розбіжність.
Далі звірте обов’язкову термінологію¶
З’ясуй, чи обов’язковий термін саме в цьому контексті, чи доречне його граматичне відмінювання і чи дозволяє проєкт кілька відповідників. Термінологічне попередження може вказувати на справжню непослідовність, а може виникнути через те, що простий пошук підрядка не враховує контекст.
Наприкінці розгляньте механічні й косметичні сигнали¶
Повторені слова, зайві пробіли й пунктуаційні пари теж треба переглянути, але не став їх в один ряд із можливою втратою змісту. Якщо одна причина породила багато схожих результатів, частину спрацювань можна перевірити групою.
Такий порядок не означає, що косметичні помилки можна пропустити. Він допомагає не витрачати увагу на оформлення, поки у звіті залишаються сигнали про неперекладений текст, важливі значення чи порушені функціональні теги.
У документації MQM сказано: “evaluation metrics should check the fewest issue types needed to meet user requirements”.
Цей принцип підказує налаштовувати QA під завдання, а не бездумно вмикати всі доступні перевірки. Для інструкції з критичними значеннями команда може зосередитися на пропусках, числах і функціональних тегах; для маркетингового тексту порядок буде іншим. Визначай пріоритети за вимогами проєкту, а не за кількістю пунктів у меню.
Як відрізнити хибні спрацювання від помилок¶
Під час сортування найважливіше - відкрити контекст. Рядок із позначкою Xbench сам по собі не доводить, що сталася помилка. Прочитай джерело й цільовий текст, а за потреби - сусідні сегменти.
Для кожного результату постав собі три запитання:
- Яке правило спрацювало? З’ясуй, що саме порівнює перевірка: збіг, тег, число, термін чи інший елемент.
- Яка вимога проєкту застосовується? Звернися до інструкції, глосарія або погодженого рішення, а не лише до загального правила.
- Що станеться, якщо залишити рядок без змін? Якщо зміст збережений, текст працює, а варіант дозволений, сигнал може бути хибним. Якщо переклад спотворює зміст або функцію, потрібна правка чи ескалація.
У командній комунікації не плутай «перевірено, хибне спрацювання» з «виправлено». Перша позначка означає, що редактор переглянув контекст і вирішив не змінювати текст. Друга - що команда внесла правку. Обидва результати корисні, але це різні речі.
Приклад із тегами: сигнал не завжди означає пошкодження¶
У дописі на форумі ApSIC користувач розповів, що японські повноширинні знаки пунктуації або символи позначалися як невідповідність тегів, хоча, за його словами, переміщеного тегу не було. У відповіді від 8 листопада 2023 року радили позначити результат комбінацією Ctrl+M і вибрати Hide Marked (обговорення на форумі ApSIC).
У відповіді на форумі радили: “To exclude false positives from the QA report, select the segment and press Ctrl+M to mark the issue. Then, at the QA options toolbar, select Hide Marked at the Filter Issues section.”
Це окремий випадок із форуму, а не доказ того, що будь-яка перевірка тегів хибна. Практичний висновок простий: спершу перевір сегмент і його функцію, а вже потім вирішуй, чи виправляти текст, чи позначити конкретне спрацювання.
Приклад із термінами: короткий пошук не читає контекст¶
Ключовий термін може мати кілька дозволених відповідників, змінювати форму або не повторюватися дослівно в кожному реченні. Перевірка, яка шукає відповідник у тексті, не обов’язково розуміє синтаксис і значення конкретного контексту.
Форумне обговорення ApSIC описує історичний випадок, коли великий обсяг попереджень виник через термінологічну базу з окремим записом для кожного дозволеного перекладу. Як один зі способів упорядкувати базу в дописі запропонували зберігати альтернативи як синоніми одного поняття (обговорення про невідповідності ключових термінів).
“You can avoid this issue if you define these entries as synonyms when you prepare the MultiTerm term base.”
Ця порада стосується описаного способу організації термінології, а не гарантує, що попереджень стане менше в кожному проєкті. Перевір базу, яку використовує команда, і погодь зміни, якщо нею користуються різні групи.
Контекстні терміни теж потребують точних правил. Те саме слово в джерелі не завжди перекладається однаково в усіх ситуаціях. У згаданому обговоренні як один із підходів описано пошукові умови PowerSearch у контрольних списках: вони враховують контекст і дозволяють альтернативні цільові варіанти. Перш ніж застосовувати правило, перевір його на завантаженому проєкті. Надто широкий збіг просто створить інший тип шуму.
Як зменшити шум до запуску перевірки¶
Не весь роздутий звіт треба розгрібати після запуску. Частину зайвих результатів можна прибрати заздалегідь, правильно вибравши обсяг перевірки, налаштування й правила пошуку.
Обмежте сегменти, які входять до перевірки¶
Xbench документує варіанти запуску QA для нових сегментів і збігів зі 100-відсотковою відповідністю, можливість виключити сегменти ICE, а в описі робочого процесу згадує також виключення заблокованих сегментів (робота з QA-функціями). Використовуй потрібні обмеження, якщо вони відповідають етапу роботи й правилам проєкту.
Перед запуском зафіксуй, що саме перевіряєш. Якщо переглядаєш нову роботу, перевірка всього проєкту може додати повторні сигнали зі старих або заблокованих сегментів. Якщо ж це фінальна перевірка всього результату, звужена вибірка може приховати потрібну інформацію.
Не виключай сегменти тільки тому, що їх багато. Спершу з’ясуй, чи дозволяє специфікація проєкту не перевіряти цю категорію і хто відповідає за її якість.
Налаштуйте параметри під мову й задачу¶
Перевірку Target same as Source вимкнено за замовчуванням. Однаковий текст у джерелі й перекладі може бути навмисним, але може вказувати й на неперекладений фрагмент. Параметр допомагає знайти такий випадок, але сам не визначає, який сценарій перед тобою (опис QA-перевірок Xbench).
У діалозі QA перевірки відповідників у CamelCase та варіантів, написаних лише великими літерами, також вимкнено за замовчуванням. Вмикай або вимикай їх залежно від формату й вимог проєкту, а не просто щоб отримати коротший список (діалог QA).
Для перевірок узгодженості є параметр чутливості до регістру, а Ignore Tags дає змогу порівнювати текст без урахування відмінностей у вбудованих тегах (документація про QA-функції). Перш ніж змінювати налаштування, подумай про побічний ефект. Ігнорування тегів допомагає, коли їхня різниця не має значення для порівняння тексту, але не замінює перевірки функціональних тегів.
Обережно налаштуйте перевірку ключових термінів¶
Документація Xbench попереджає про мовний компроміс у параметрі зіставлення цілих слів для QA ключових термінів. Якщо в мовах із відмінюванням вимкнути це налаштування, кількість хибних спрацювань може зменшитися (параметри Miscellaneous).
Не сприймай цю пораду як універсальне правило. Перевірка цілих слів і відмінювання по-різному взаємодіють залежно від мови й побудови глосарія. Вибери налаштування за правилами проєкту й перевір його на реальних сегментах, перш ніж застосовувати масово.
Перетворіть повторювані правила на контрольний список¶
Контрольні списки Xbench допомагають повторно запускати пошуки. У документації серед прикладів є заборонені терміни, поширені помилки, зауваження клієнта й проєктні неперекладені ключові слова (керування контрольними списками).
Контрольний список проєкту зберігається разом із файлом Xbench-проєкту .xbp. Особисті списки використовують файл .xbckl і підходять для перевірок, які можна переносити між проєктами (документація про контрольні списки). Відділяй правила конкретного клієнтського проєкту від тих, які справді можна повторно використовувати.
Перед запуском перевір запис контрольного списку на завантаженому проєкті. Окремий запис можна вимкнути, і його вимкнений стан зберігається на диску (керування контрольними списками). Тест одразу покаже, чи знаходить правило потрібні випадки, чи просто роздуває звіт.
Як позначати, приховувати й експортувати результати¶
Позначай результат, якщо вже перевірив конкретний рядок і не хочеш, щоб підтверджене хибне спрацювання відволікало під час подальшого сортування. Важливо, щоб у робочому процесі було зрозуміло: прихований результат - не те саме, що виправлена проблема.
- Перевірте рядок у контексті. Порівняйте джерело й переклад та звіртеся з інструкціями проєкту.
- Виправте підтверджену помилку. Позначка не замінює редагування.
- Позначте підтверджене хибне спрацювання. У QA-вікні виберіть результат і натисніть Ctrl+M.
- Увімкніть Hide Marked. Фільтр приховає позначені елементи під час подальшого перегляду.
- Збережіть позначки, якщо проблема повторюється. Файл
.xbmrkможна завантажити знову для повторюваних проєктів і проблем. - Перевірте стан фільтра перед експортом. Експорт містить лише результати, які відображаються.
Документація Xbench описує показ і приховування позначених результатів як спосіб відфільтрувати хибні спрацювання під час роботи зі звітом. Там само сказано, що позначки можна зберегти у файлі .xbmrk, а потім повторно завантажити для проєктів із файлами чи проблемами, які повторюються (робота з QA-функціями).
Перед повторним використанням перевір, чи стосується позначка того самого випадку. Схожий рядок в іншому сегменті може мати інший контекст. А зміна глосарія чи інструкції може означати, що колишнє хибне спрацювання вже не нешкідливе.
Xbench дає змогу експортувати результати, які відображаються, у HTML, текст із табуляцією, Excel або XML (опис діалогу QA). Вибирай формат за тим, хто читатиме файл і як його оброблятимуть далі. Але важливіше за формат розуміти, що саме потрапить до експорту.
Export QA Results вивантажує тільки результати, які показує поточний фільтр. Якщо позначені елементи приховані, експортований файл їх не міститиме (документація Xbench про роботу з QA). Тож файл після Hide Marked зручний для передавання нерозв’язаних проблем, але не замінює повного запису перевірки.
Якщо проєкту потрібен аудит, збережи повний звіт до застосування фільтра або окремо зафіксуй правила, за якими приховував результати. Для передавання команді підготуй відфільтрований список невирішених питань і зазнач, що позначені рядки не потрапили до експорту. Не називай відфільтрований файл повним звітом, якщо в ньому немає прихованих результатів.
Типові помилки під час сортування QA-звіту¶
Хибні спрацювання - не єдина причина, чому команда довго розбирає звіт. Невдалі дії редактора теж додають шуму, приховують реальні проблеми або ускладнюють передавання результату.
Виправляти все, що підсвітила програма¶
Автоматичне попередження - привід перевірити сегмент, а не команда негайно його змінити. Якщо переписати прийнятний варіант лише для того, щоб прибрати рядок зі звіту, можна зіпсувати граматику, зміст чи погоджену термінологію.
Якщо перевірка повідомляє про відсутній ключовий термін, з’ясуй, чи можна замінити його займенником або іншим природним формулюванням. Якщо звіт знайшов невідповідність тегів, перевір, чи змінилася функція, а не лише спосіб, у який програма бачить вбудовані елементи.
Позначати рядок до перевірки¶
Якщо позначити кожен повторюваний сигнал, не переглянувши контекст, Hide Marked приховає не лише підтверджений шум, а й потенційні помилки. Спершу перевір типові приклади з групи. Позначай лише ті результати, для яких маєш зрозуміле пояснення.
Якщо команда передає файл між редакторами, додай коротку причину: наприклад, «дозволений варіант за глосарієм» або «тег перевірено, функцію збережено». Самої позначки може не вистачити людині, яка відкриє звіт пізніше.
Вимикати перевірки заради меншого звіту¶
Менший звіт не обов’язково кращий. Вимкнеш перевірку, якої вимагає проєкт, - рядків стане менше, але ризик пропустити проблему зросте.
До запуску визнач мету QA-проходу, потрібні категорії й сегменти. Xbench дає змогу налаштовувати перевірки та обсяг сегментів; добирай параметри під проєкт, а не під бажану кількість результатів (документація QA, робота з QA-функціями).
Експортувати відфільтрований звіт і назвати його повним¶
Коли активний Hide Marked, експорт не містить прихованих результатів. Для робочого списку нерозв’язаних питань це зручно, але для повного аудиту потрібен і нефільтрований запис (документація Xbench про експорт результатів).
Перед надсиланням перевір стан фільтра й назви файл за його вмістом. Наприклад, «невирішені результати після Hide Marked» точніше описує відфільтрований експорт, ніж «повний звіт QA».
Змішувати клієнтські правила й особисті звички¶
Особистий контрольний список може містити корисні пошуки, але це не робить кожне правило обов’язковим для всіх проєктів. Зберігай правила клієнта в контрольному списку проєкту, а перевірки для повторного використання в різних проєктах - в особистому списку, якщо вони справді не залежать від клієнта (керування контрольними списками).
Для командної роботи домовтеся, хто затверджує зміни в термінології й правилах пошуку. Інакше один редактор може приховати попередження, яке інший вважає обов’язковим для перевірки.
Перед передаванням звіту перевір чотири речі: справжні проблеми виправлені або призначені відповідальному; позначені рядки перевірені; фільтр відповідає меті експорту; повний запис збережено, якщо його вимагає аудит. Автоматичні сигнали від цього не стануть безпомилковими, але команді буде простіше відрізнити нерозв’язані ризики від підтвердженого шуму.
FAQ¶
Як приховати хибні спрацювання у звіті Xbench?¶
Вибери перевірений результат і натисни Ctrl+M, а потім увімкни Hide Marked у фільтрі. Xbench дає змогу показувати або приховувати позначені результати під час роботи з QA-звітом (документація про QA-функції).
Позначай рядок лише після перевірки контексту. Приховування прибирає спрацювання з поточного перегляду, але не виправляє переклад.
Як зменшити попередження про невідповідність ключового терміна в Xbench?¶
Спершу перевір термінологічну базу: чи збережені дозволені варіанти як альтернативи одного поняття і чи не потрібне окреме правило для конкретного контексту. Форумне обговорення ApSIC описує випадок, де окремі записи для кожного дозволеного перекладу спричиняли багато попереджень. Запропоноване там об’єднання синонімів не є універсальною гарантією (обговорення про key-term mismatches).
Для мов із відмінюванням перевір налаштування зіставлення цілих слів. Документація Xbench застерігає, що вимкнення цього параметра може зменшити хибні спрацювання, але правильний вибір залежить від мовного сценарію (параметри Miscellaneous).
Які попередження Xbench виправляти першими?¶
Спершу перевір можливі пропуски змісту, розбіжності в числах і URL, теги, що можуть впливати на функцію, та обов’язкові терміни. Потім переходь до повторюваних механічних і косметичних попереджень.
Це практичний порядок за потенційним ризиком, а не офіційний рейтинг Xbench. Змінюй черговість відповідно до вимог проєкту, типу тексту й наслідків можливої помилки.
Чи можна зберегти позначені хибні спрацювання Xbench і використати їх знову?¶
Так. Xbench дає змогу зберегти позначки QA у файлі .xbmrk, а потім завантажити їх знову для проєктів із повторюваними файлами чи проблемами (документація про роботу з QA).
Перед повторним використанням перевір контекст і правила поточного завдання. Давня позначка не доводить, що схожий рядок у новому файлі теж є хибним спрацюванням.
Чи потрапляють приховані попередження до експорту QA Results?¶
Ні. Export QA Results містить лише результати, які зараз відображаються, тому Hide Marked впливає на склад експортованого звіту (документація про експорт QA).
Для передавання невирішених проблем відфільтрований експорт може бути доречним. Для аудиту збережи також повний варіант без прихованих результатів.