Чому перекладачі вимикають перевірку чисел у QA і що проходить повз¶

В інструкції артикул Windows-1252 перетворився на Windows-1254, і перевірка чисел підсвітила розбіжність, яку легко не помітити. Та сама перевірка може позначити й правильну зміну: число записали словом або оформили за правилами цільової локалі. Тож проблема не в самих попередженнях, а в тому, чи допомагають вони відрізнити помилку від потрібної зміни.

Коли QA-звіт знову й знову показує довгий список сигналів, однаково уважно перевіряти кожен стає важко. Частина перекладачів просто вимикає перевірку чисел. Шуму меншає, але разом із ним зникає й нагадування про помилку в сумі, даті, номері моделі чи параметрі.

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

Що перевіряє автоматична перевірка чисел¶

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

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

У документації pofilter є такий приклад повідомлення: “The number 1252 does not appear in the translation.” Автори пояснюють, що проблема може бути лише уявною, якщо цифру записали словом: “Might not be a problem if 2 has been written in full” (приклади pofilter). Тобто сигнал означає «перевір», а не «переклад точно помилковий».

Буває й навпаки. У прикладі pofilter система порівнює Windows-1252 з Windows-1254 і знаходить змінене значення (приклади pofilter). Тут автоматичне попередження вказує на підміну, яку легко прогледіти серед схожих цифр. У назві моделі, коді, номері версії чи ідентифікаторі може відрізнятися один символ - і цього достатньо, щоб інструкція перестала працювати.

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

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

Чому точні правила створюють хибні тривоги¶

Хибне сповіщення з’являється, коли QA бачить формальну різницю, яка не змінює змісту. Найчастіше причина - локалізація: десяткові знаки, роздільники груп цифр, пробіли, знаки мінуса й місце для валюти залежать від мови та контексту.

CLDR - база даних мовних і регіональних правил Unicode - описує десяткові та групувальні символи як локалізовані дані (стандарт CLDR для чисел). Роздільником може бути кома, крапка, пробіл або інший знак. Тому просте порівняння текстових рядків не завжди коректно зіставляє числові значення.

Microsoft наводить приклади, де коми, крапки, апострофи й середні крапки можуть бути десятковими роздільниками залежно від локалі чи контексту. У Швейцарії звичайний десятковий запис може використовувати кому, а валюта - крапку (форматування чисел за локаллю). Не змінюй значення лише заради того, щоб позначки збігалися з оригіналом.

Групування цифр теж відрізняється. Microsoft описує групи з трьох цифр як поширені в європейських мовах, групи з чотирьох - у Китаї, Японії та Кореї, а також південноазійську схему на кшталт 1,00,00,000 (форматування чисел за локаллю). Перевірка, яка очікує тільки групи по три цифри, може позначити правильний цільовий формат як помилковий.

Навіть у межах однієї країни правила й звички можуть різнитися. Microsoft наводить приклад Німеччини: DIN 1333 передбачає пробіл як роздільник від п’яти цифр, тоді як у поширеному вжитку групи цифр часто відокремлюють крапкою (форматування чисел за локаллю). Якщо перевірка налаштована на один варіант, вона може спрацювати на інший прийнятний формат.

Розбіжність не завжди стосується пунктуації. Мінус можуть поставити перед числом або передати дужками в бухгалтерському форматі. Символ валюти може стояти до суми чи після неї, з пробілом або без нього: Microsoft порівнює формати € -1.234,56 у Нідерландах і -1 234,56 € у Франції (форматування чисел за локаллю). Перевіряй суму й знак, а не механічно повторюй позицію символу.

Ще одне джерело хибних тривог - перехід від цифр до слів. CLDR розділяє числові системи, де значення записують цифрами, та алгоритмічні системи, де кількість утворюється за правилами запису, а не простою заміною одного знака іншим (стандарт CLDR для чисел). Через це зіставлення лише цифрових символів не впізнає еквівалентність, якщо форма числа змінилася.

Microsoft також зазначає, що число можна записати словами, порядковою формою або компактно, наприклад 123K (форматування чисел за локаллю). Переклад, у якому скорочення розгорнули або змінили спосіб подання за стилем, може отримати попередження, хоча зміст зберігся. Але все одно звір точне значення: компактний запис не виправдовує округлення чи пропуск потрібної точності.

Дати додають ще один рівень складності. Стандарт дат CLDR описує формати як локальні дані й підтримує різні шаблони дат (стандарт CLDR для дат). День, місяць і рік можуть записуватися по-різному, тож перевіряй не лише символи, а й значення дати та порядок компонентів.

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

Чому перекладачі зрештою вимикають цю перевірку¶

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

Один користувач у спільноті RWS описав свій досвід так (допис у спільноті RWS):

I get more false positives than actual positives

Це особистий досвід, а не вимірювання для всієї галузі. Але він добре показує, як виникає втома від сповіщень: що більше сигналів здаються беззмістовними, то легше перестати сприймати їх як підказки.

Автор того самого допису оцінив ситуацію так (допис у спільноті RWS):

95% of the errors were false positives and I would ignore

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

У тому самому повідомленні перекладач також написав, що перевірка виявила кілька помилок, пропустити які було б соромно (допис у спільноті RWS). У цьому й пастка: перевірка створює шум, але водночас знаходить справжні проблеми. Якщо просто її вимкнути, звіт стане тихішим, зате ти втратиш один зі способів помітити змінене значення.

У щільному тексті справжня помилка легко ховається серед звичних форматних відмінностей. 1,000 і 1.000 можуть бути різними локальними записами того самого числа, а зміна однієї цифри в коді може позначати інший стандарт. Для алгоритму обидва випадки - невідповідність; для змісту перший може бути нормальним, а другий - критичним.

Ризик зростає, коли ти перестаєш розрізняти автоматичний результат, власне рішення та звіряння з оригіналом. Вимкнений інструмент уже не запитає, чи потрібна зміна формату, чи відмінність вказує на помилку. Команда просто перестане бачити автоматичні сигнали.

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

Що проходить повз, коли перевірку вимкнено¶

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

Приклад Windows-1252 і Windows-1254 показує, навіщо потрібна така перевірка: числовий фрагмент змінився, і pofilter повідомив про розбіжність (приклади pofilter). Помилка може з’явитися під час набору, копіювання чи редагування, а схожість значень ускладнює ручну вичитку. Автоматичний сигнал не доводить, що переклад неправильний, але вказує, де звірити джерело.

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

Суми вразливі до двох різних помилок: зміненого числового значення та неправильного прочитання роздільника, який у вихідній і цільовій локалях виконує різні ролі. З’ясуй, чи змінилося тільки оформлення, чи й величина. Формат валюти також може змінити місце символу й пробіли, як видно з прикладів Microsoft для Нідерландів і Франції (форматування чисел за локаллю).

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

Ще один ризик - виправляти переклад, хоча помилка була вже в джерелі. Документація pofilter описує приклад, де в оригіналі є зайва крапка, а переклад її виправляє; автори радять залишити виправлену версію та повідомити про проблему в оригіналі (приклади pofilter). Приклад стосується пунктуації, але принцип той самий: контроль якості порівнює тексти, та не завжди може визначити, чи помилився автор джерела.

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

Найризикованіше - вважати відсутність сигналу доказом правильності. Автоматична перевірка знаходить лише ті розходження, які вміють розпізнати її правила. Якщо значення змінилося так, що числовий фрагмент формально збігається, або число записали в непідтримуваній формі, потрібен людський перегляд.

Європейська комісія описує контроль якості перекладу як поєднання двомовного редагування на точність і повноту та окремого одномовного перегляду на ясність, тон і відповідність аудиторії (контроль якості перекладу, сторінку оновлено 18 червня 2026 року). Перевірка чисел - лише один шар цієї роботи, а не заміна звіряння двох версій.

Як налаштувати перевірку, не відмовляючись від неї¶

Щоб зменшити кількість хибних тривог, не починай із вимкнення правила. Спершу розбери сповіщення: які типи розбіжностей повторюються, чому вони виникають і чи відповідають прийнятому стилю цільової мови. Так ти відокремиш помилки налаштування від звичних локальних форматів і побачиш, які попередження справді потрібні.

1. З’ясуй, що саме повідомляє перевірка. Розділи пропущене число, зайве число, змінений рядок цифр і відмінність у форматуванні. Кожен сигнал потребує свого рішення: числа може не бути, бо його записали словами, а зміну цифри в коді треба звірити з джерелом.

2. Визнач функцію числового елемента. З’ясуй, чи перед тобою сума, дата, код, номер моделі, відсоток, одиниця виміру, порядковий номер або частина назви. Той самий набір цифр може виконувати різні ролі, а формат, прийнятний для суми, може бути неприйнятним для коду.

3. Перевір правила локалі й редакційні вимоги. Зістав десяткові та групувальні знаки з правилами цільової мови й проєкту. CLDR описує локалізовані роздільники та різні схеми групування (стандарт CLDR для чисел); Microsoft наводить приклади різних роздільників, знаків та оформлення валют (форматування чисел за локаллю).

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

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

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

Для команди корисно мати три варіанти рішення: виправити переклад, залишити його з поясненням або передати проблему авторові джерела. Позначка «хибна тривога» не має означати «ігнорувати назавжди». Вона означає, що формат або зміст перевірили й за потреби пояснили.

Європейська комісія наголошує: наслідки помилки залежать від типу документа, а тексти з вищим ризиком потребують ретельнішого контролю. Комісія також називає часовий тиск, доступні ресурси й досвід перекладача чинниками, що впливають на ймовірність помилок (контроль якості перекладу, сторінку оновлено 18 червня 2026 року). Отже, не обов’язково однаково глибоко перевіряти кожен фрагмент. Важливо не втратити увагу там, де числова помилка матиме наслідки.

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

Як пріоритизувати хибні спрацювання Xbench допоможе організувати роботу з великими звітами: спершу відділи ризикові сигнали від повторюваних форматних. Для команд із кількома етапами перевірки стане в пригоді модель TEP у контролі якості перекладу: автоматичний звіт не замінює редакторського перегляду. А автоматизовані QA-перевірки тегів, термінології та чисел допоможуть побачити числові сигнали як частину ширшого контролю.

Коли перевірка чисел потрібна, а коли її недостатньо¶

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

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

Автоматичне зіставлення не оцінить самостійно, чи зрозумілий текст читачеві, чи доречний спосіб подання та чи не переплутано значення з одиницею. Європейська комісія підкреслює, що якість залежить не лише від мовної точності, а й від контексту, формулювання та мовних звичаїв (контроль якості перекладу, сторінку оновлено 18 червня 2026 року). Тому оцінюй сигнал у контексті.

Коли розбираєш сповіщення, постав собі кілька запитань: що означає число, чи збереглося його значення, чи відповідає формат цільовій локалі та чи вимагає документ особливої точності? Якщо переклад правильний, закрий сповіщення як перевірене. Якщо значення змінилося або роль числа незрозуміла, звір джерело чи запитай автора.

Не роби висновків про надійність перевірки лише за кількістю сповіщень. Довгий список може з’явитися через особливості локалі, а короткий звіт не гарантує, що всі змістові помилки знайдено. Краще відстежуй, які типи сигналів знаходять справжні проблеми, а які постійно повторюють те саме форматне застереження.

Команді допоможе коротко записувати рішення для повторюваних випадків: приклад, тип числа, прийнятна форма й дія зі сповіщенням. Не треба створювати довідник для кожного числа. Мета проста: не витрачати час на ту саму суперечку й не змінювати налаштування навмання.

Якщо джерело й переклад не збігаються, не перенось помилку в переклад мовчки й не виправляй її без пояснення. Приклад pofilter із зайвою крапкою показує, що проблема може бути в оригіналі, а не в перекладі (приклади pofilter). Для числової розбіжності діє та сама логіка: перевір контекст, залиш правильний текст і повідом відповідальну сторону, якщо треба виправити джерело.

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

FAQ¶

Чому перевірка чисел у перекладі створює хибні сповіщення?¶

Перевірка може порівнювати символи буквально й не розпізнавати локалізовані роздільники, запис числа словами, порядкові форми чи компактне подання. CLDR описує локальні правила запису чисел, а Microsoft наводить приклади різних десяткових і групувальних знаків (CLDR, Microsoft).

Які помилки в числах може пропустити автоматична перевірка?¶

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

Чи варто вимикати перевірку чисел у CAT-інструменті?¶

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

Як перевіряти дати, валюти й одиниці виміру в локалізації?¶

Зіставляй значення та роль елемента, а не лише його вигляд. Перевіряй повну дату, суму разом із валютою та число разом з одиницею виміру; CLDR описує дати як локальні формати, а Microsoft наводить приклади різного запису валют (CLDR, Microsoft).

Як зменшити хибні тривоги в перевірці чисел?¶

Розділи попередження за типом, звір правила цільової локалі й задокументуй повторювані прийнятні форми. Не змінюй загальні налаштування через один приклад: спершу переконайся, що сигнали про реальні розбіжності залишилися.