Переводчик отключает проверку чисел после очередного отчёта, где корректная дата, сумма или число, записанное словами, отмечены как ошибка. Но вместе с лишними предупреждениями можно убрать и сигнал о действительно изменившемся коде, сроке или количестве.
Проверка чисел полезна не потому, что автоматически доказывает правильность перевода, а потому, что помогает заметить различия, которые легко пропустить при чтении. Сложность начинается там, где программа принимает любое различие в записи за смысловую ошибку, а человек привыкает нажимать «игнорировать».
Дальше разберём, почему числовые проверки шумят, какие ошибки не ловят и как настроить процесс так, чтобы предупреждения оставались полезными. Речь пойдёт не о бездумном доверии к QA и не о полном отказе от неё, а о проверке каждого числа по его функции и контексту.
Что проверка чисел в переводе делает на практике¶
Числовая проверка в QA переводов ищет различия между исходным и целевым сегментами: например, число есть в исходнике, но не найдено в переводе. Сегментом называют отдельную единицу текста, с которой работает CAT-инструмент. Проверка помогает быстро обнаружить пропуски, случайные подмены и другие расхождения, но сама по себе не устанавливает, равнозначны ли записи по смыслу.
Программа может сравнить последовательности цифр в двух сегментах. Если исходник содержит 1252, а перевод - 1254, расхождение заметно. Если исходник содержит 2, а переводчик написал числительное словом, сравнение одних лишь цифр может сообщить об отсутствующем числе, хотя значение сохранено.
В документации pofilter приведён пример с изменившимся кодом Windows-1252 и Windows-1254: числовая проверка показывает подмену, которую редактору стоит перепроверить. В той же документации поясняется, что сигнал не обязательно указывает на ошибку, если число в переводе написано словами: пример pofilter. Такой пример показывает обе стороны одной функции: проверка замечает полезное различие и может ошибочно трактовать допустимый перевод.
Проверка обычно сравнивает формальные признаки текста, а переводчик оценивает значение в контексте. Между этими задачами есть зазор. Он особенно заметен, когда числа форматируются по-разному, превращаются в слова, входят в код или маркируют дату.
Важно различать четыре вопроса:
- Присутствуют ли в переводе числа, найденные в исходнике?
- Не появились ли в переводе лишние числа?
- Осталось ли прежним значение числа, а не только его написание?
- Подходит ли форма записи целевой локали и документу?
Первый и второй вопросы сравнительно удобно автоматизировать. Третий требует понимания связей внутри фразы: что именно измеряет число, к чему относится дата, какой валютой выражена сумма. Четвёртый зависит от языковой нормы, требований заказчика и жанра текста.
Автоматический сигнал полезен как повод для проверки, но не как вердикт. Если команда рассматривает каждое предупреждение как доказанную ошибку, она будет исправлять допустимые форматы. Если предупреждения без просмотра снимают пачкой, проверка перестаёт работать как страховка.
Более широкую картину даёт обзор автоматических QA-проверок в переводе: числа - лишь один класс проверок наряду с тегами, терминологией и согласованностью. Отчёт по числам стоит читать вместе с исходным сегментом и окружающим текстом.
Почему число в отчёте не всегда означает ошибку¶
Ложная тревога появляется, когда инструмент сравнивает формальные записи, а допустимый перевод меняет форму числа. Проверка может обнаружить различие между строками цифр, но не знать, что такое изменение разрешено правилами локализации или обусловлено грамматикой.
Разделители зависят от локали¶
Локаль - это набор языковых и региональных правил, влияющих на представление чисел, дат, валют и других данных. В одних форматах запятая обозначает десятичную часть, в других для этой роли используют точку. Различаться может и знак группировки разрядов: пробел, точка, запятая или другой символ.
CLDR описывает десятичные и группирующие символы как зависящие от локали. В спецификации отмечено, что группировка часто идёт тройками цифр, но встречаются группы по четыре цифры и схемы с первичной и вторичной группировкой, например 12,34,56,789 в соответствующей системе записи (CLDR: числа). Значит, посимвольное несовпадение разделителей не всегда указывает на иное числовое значение.
Документация Microsoft также описывает точки, запятые, арабский десятичный разделитель, апострофы и средние точки как возможные разделители в зависимости от локали или контекста. В качестве примера приводится Швейцария: для обычных десятичных чисел может использоваться запятая, а в денежных форматах - точка (документация Microsoft о форматировании чисел). Алгоритм с жёстко заданным шаблоном способен ошибочно отметить корректный денежный формат.
Похожая неоднозначность есть у группировки разрядов. Microsoft описывает трёхзначные группы как распространённые в европейских языках, четырёхзначные - в Китае, Японии и Корее, а также приводит южноазиатскую запись 1,00,00,000 (документация Microsoft о форматировании чисел). Универсальное правило «группируй только по три» не покрывает все локали.
Число может быть записано не цифрами¶
Число в исходнике и переводе может выглядеть по-разному: словами, порядковой формой или компактным обозначением. Microsoft перечисляет запись чисел словами, порядковые формы и компактные варианты вроде 123K как допустимые представления, которые строгая проверка цифр способна принять за пропуск или добавление (документация Microsoft о форматировании чисел).
Отдельная причина расхождений - разные системы записи чисел. CLDR различает числовые системы, основанные на наборе цифр, и алгоритмические системы, где величина выражается с помощью правил. Среди примеров числовых систем есть западные и тайские цифры, а китайская запись может быть алгоритмической (CLDR: числа). Сравнение символов не равно сравнению значений.
В переводе числа также меняют грамматическую форму. Количество может потребовать числительного словами, а номер пункта - порядковой формы. Переводчик может сохранить смысл и изменить структуру фразы, поэтому сигнал о несовпадающих цифрах нужно проверять по всему сегменту, а не исправлять механически.
Формат валюты и знак числа меняют положение¶
Денежная сумма - это не только цифры с символом валюты. В зависимости от локали меняются положение символа, пробелы и знаки пунктуации. Microsoft приводит примеры € -1.234,56 для Нидерландов и -1 234,56 € для Франции (документация Microsoft о форматировании чисел).
Знак отрицательного значения тоже может представляться по-разному. В описании Microsoft упоминаются начальный дефис-минус и бухгалтерские скобки (документация Microsoft о форматировании чисел). Проверка, настроенная на один шаблон, может не распознать другой допустимый формат или спутать знак с частью соседней записи.
Для переводчика важен не только ответ на вопрос «те же ли цифры?», но и вопрос «сохранилась ли сумма?». Нужно сверить знак, валюту, разрядность и связь суммы с предметом, к которому она относится. Одно только присутствие цифр не подтверждает, что денежное значение передано верно.
Даты требуют сравнения по смыслу¶
Дата может быть представлена другой последовательностью элементов в другой локали. Поэтому две записи одной даты не обязательно совпадут посимвольно. Стандарт CLDR для дат описывает форматы как локальные данные и поддерживает разные шаблоны записи (CLDR: даты).
Для проверки недостаточно увидеть, что в обеих строках присутствуют цифры. Сверьте, какой день, месяц и год обозначает исходник и какой смысл несёт перевод. Если порядок элементов изменился, автоматическое сравнение строк способно выдать предупреждение на правильную дату; если цифры сохранились, но поменялись местами, строковое сопоставление не обязательно распознает ошибку.
Реальный шум превращает проверку в фоновый сигнал¶
Один переводчик на форуме RWS описал опыт использования проверки чисел и объяснил, почему отключил её. Это индивидуальный рассказ, а не измерение распространённости ложных тревог.
Как пишет участник сообщества RWS:
I get more false positives than actual positives.
Перевод: «Ложных срабатываний у меня больше, чем настоящих». Такая оценка отражает личный опыт автора сообщения, а не статистику по переводчикам или CAT-инструментам. Но описанный механизм знаком многим командам: если предупреждения часто требуют ручной отмены, пользователи начинают воспринимать их как шум и могут перестать замечать полезные сигналы.
Тот же участник сообщил, что в его случае около 95% предупреждений он считал ложными и игнорировал. Эта цифра - самооценка одного пользователя на форуме, не измеренная доля ложных срабатываний в отрасли (сообщение на форуме RWS). Её не следует переносить на другую языковую пару, набор правил или тип проекта.
Тот же участник написал, что проверка всё же поймала пару ошибок, пропуск которых мог бы его смутить. Значит, раздражающие сигналы не отменяют того, что инструмент способен заметить реальное расхождение (сообщение на форуме RWS). Решение отключить проверку после серии шумных сообщений может одновременно снизить усталость и убрать полезную страховку.
Команде стоит искать не один переключатель, который решит всё, а способ сделать предупреждения понятнее. Для этого нужно разбирать причины ложных срабатываний: локальный формат, запись словами, неизменяемый код, разные правила оформления или действительно неполная поддержка инструмента.
Что автоматическая проверка чисел может не заметить¶
Проверка чисел может пропустить ошибку, если исходная и целевая строки содержат похожий набор цифр, но значения в контексте разошлись. Наличие числа в обеих версиях ещё не доказывает, что оно стоит рядом с правильным объектом, обозначает правильную величину или сохранило нужный знак.
Числовой сигнал отвечает на ограниченный вопрос о сопоставлении признаков. Из него не следует автоматически, что система поняла, какое число относится к сроку, сумме, пункту списка или коду. Оценку соответствия перевода нужно строить на значении предложения.
Пропущенный знак или неверный знак. Если число сохранилось, а отрицание или знак изменился, проверка по наличию цифр может не сработать. Сверьте, осталось ли значение положительным или отрицательным и соответствует ли знак смыслу исходника.
Изменившаяся единица измерения. Одинаковое число при другой единице означает другое значение. Если числовой тест сравнивает только последовательность цифр, его сигнал не заменит проверку единицы и её связи с измеряемой величиной.
Изменившаяся разрядность. Ошибка в нуле может существенно изменить сумму или количество. Сравнивать нужно всю числовую запись, включая ведущие и завершающие цифры, а затем проверить, к чему относится значение.
Неправильная связь с объектом. В предложении могут стоять несколько значений: дата, сумма и номер. Проверка может увидеть, что все они присутствуют, но сама по себе не подтверждает, что каждое осталось при своём описании. Читайте предложение целиком и сопоставляйте соответствия.
Неверно интерпретированная дата. Цифры могут сохраниться, но другой порядок элементов изменить прочтение. CLDR рассматривает даты как локальные форматы с различными шаблонами, поэтому буквальное совпадение не заменяет проверку значения даты (CLDR: даты).
Подменённый код или идентификатор. Проверка может заметить изменение цифр в коде, как в примере Windows-1252 и Windows-1254 из pofilter (документация pofilter). Но сигнал нужно интерпретировать: часть обозначения может быть неизменяемым кодом, а часть - ошибкой, которую следует исправить.
Неверная словесная форма. Цифровая проверка может не распознать число, записанное словами, а смысловая - не всегда отличит подходящую форму от неподходящей. Числительное нужно сверить с исходным количеством и ролью в предложении, а не считать правильным только потому, что программа не показала расхождение.
Хороший контрпример к подходу «если предупреждения нет, всё в порядке» - длинное предложение с несколькими датами и суммами. Если все цифры на месте, но дата относится не к тому сроку, простое сравнение количества чисел может пройти без сигнала. Точная проверка требует не только обнаружить запись, но и установить её функцию.
Поэтому ручная вычитка чисел не должна превращаться в повторное чтение всего документа с одинаковым вниманием к каждой строке. Сначала используйте автоматический отчёт для поиска расхождений, затем проверьте сами цифры, единицы, знаки и контекст. Такой подход помогает сосредоточиться на том, чего тест по строкам не доказывает.
Если нужно системно распределить проверки по этапам, полезно посмотреть, как устроена многоэтапная модель TEP и QA перевода. Смысл в том, чтобы автоматические сигналы дополняли редакторскую проверку, а не подменяли её.
Отключать проверку или менять правила¶
Полностью отключать проверку чисел только из-за ложных срабатываний обычно не лучший выход. Сначала выясните, какая именно форма вызывает шум, и разделите допустимое форматное различие, ошибку исходника и реальное расхождение перевода.
Набор действий зависит от того, что умеет конкретный CAT-инструмент. В одной системе можно изменить правила форматирования, в другой - добавить исключение для повторяющегося кода, в третьей - только проверить предупреждения вручную. Не приписывайте своему инструменту возможности, которых нет в его документации.
Разделите предупреждения по причине¶
Для каждого повторяющегося сигнала запишите, что его вызвало. Часто достаточно отнести случай к одной из понятных групп:
- Локальный формат. Запятые, точки, пробелы или положение символа валюты соответствуют целевой локали.
- Преобразование по смыслу. Число записано словами, порядковой формой или компактным обозначением.
- Неизменяемая строка. Число входит в код или идентификатор и должно остаться без изменений.
- Изменение значения. Цифры, знак, разрядность, дата или единица не соответствуют исходнику.
- Проблема источника. В исходном сегменте есть опечатка или противоречие, которое переводчик не должен молча воспроизводить.
Такое деление помогает обсуждать проверку конкретно. Формулировка «числовой QA бесполезен» не показывает, какой тип предупреждений создаёт трудности и какие ошибки команда рискует пропустить.
Исключайте только то, что можете объяснить¶
Если повторяющийся код вызывает одинаковую ложную тревогу, исключение должно быть узким и понятным. Фиксируйте, что именно не нужно проверять, почему и кто подтвердил правило. Если сомнение остаётся, оставьте предупреждение на ручную проверку вместо того, чтобы снимать его автоматически.
В документации pofilter показано, что проверка чисел может выявить изменение значения кода, но также создать ложную тревогу, когда число написано словами (документация pofilter). Примеры полезны именно как напоминание: исключение для одного типа строк не должно становиться разрешением игнорировать все числа в документе.
Не подгоняйте перевод под формат исходника, если целевая локаль требует другой записи. Сначала проверьте, сохраняется ли значение, затем решите, какой формат подходит читателю. Microsoft отдельно описывает различия десятичных и группирующих символов, а также денежных форматов (документация Microsoft о форматировании чисел).
Проверяйте исходник, когда перевод выглядит правильным¶
Иногда расхождение возникает потому, что ошибку допустили в исходном тексте. Если переводчик видит, что число в исходнике противоречит другому фрагменту документа, сигнал QA не подсказывает, какую версию считать правильной. Нужен запрос к автору или ответственному редактору.
Документация pofilter приводит пример не с числом, а с пунктуацией: в исходнике было две точки, перевод исправил их, и рекомендация состояла в том, чтобы оставить исправление и сообщить о проблеме источника (пример pofilter). Тот же принцип полезен для чисел: не копируйте подозрительное значение автоматически и не исправляйте исходник без согласования.
Запишите решение там, где его смогут найти другие участники проекта. Одному переводчику может быть очевидно, почему число записано словами или почему код оставлен без изменений; редактору, который проверяет файл позже, контекст может быть неизвестен.
Сопоставляйте усилие с риском текста¶
Не каждое числовое расхождение несёт одинаковые последствия. Ошибку в рекламном округлении и неверное число в юридическом документе нельзя проверять с одинаковой глубиной только потому, что оба случая подсветил один и тот же тест.
Европейская комиссия описывает контроль качества перевода как несколько разных задач: двуязычная ревизия проверяет точность и полноту, а отдельная монолингвальная проверка оценивает ясность, тон и соответствие аудитории (страница Еврокомиссии о качестве перевода, обновлена 18 июня 2026 года). Автоматическая проверка числа не заменяет ни один из этих этапов.
Комиссия также отмечает, что последствия ошибки зависят от типа документа: юридическая ошибка может иметь правовые или процедурные последствия, поэтому для текстов с высоким риском нужны более тщательные проверки (страница Еврокомиссии о качестве перевода, обновлена 18 июня 2026 года). В том же описании среди факторов риска названы дефицит времени, доступность ресурсов и опыт переводчика.
Если число определяет срок, сумму, параметр или юридическое условие, проверьте его отдельно в контексте всего документа. Если число находится в пояснительном тексте с допустимым округлением, сначала уточните требования проекта. Само по себе предупреждение не устанавливает уровень риска, но помогает понять, где нужна дополнительная ревизия.
Как проверять числа: рабочий порядок для команды¶
Удобная процедура помогает отделить форматное различие от ошибки значения. Команда не должна выбирать между автоматическим тестом и внимательной вычиткой: проверка быстрее находит подозрительные места, а человек решает, что они значат.
Шаг 1. Проверьте исходный сегмент и контекст¶
Откройте не только строку из отчёта, но и предложение вокруг неё. Определите, к чему относится число: к дате, количеству, валюте, коду, единице измерения или номеру пункта. Если в предложении несколько чисел, сопоставьте каждое с его ролью.
Шаг 2. Сверьте значение, а не внешний вид¶
Проверьте, сохранились ли величина, знак, разрядность и объект, к которому относится число. Учитывайте, что допустимая целевая запись может отличаться по разделителям, положению валютного символа или использованию словесной формы. CLDR описывает локальные правила записи чисел, а документация Microsoft приводит примеры различий форматирования (CLDR: числа; Microsoft: форматирование чисел).
Шаг 3. Проверьте дату в целевой локали¶
Прочитайте исходную и целевую дату как значения, а не как набор символов. Уточните, какие элементы обозначают день, месяц и год, и убедитесь, что перевод не меняет их порядок так, что появляется другой смысл. CLDR описывает форматы дат как локальные данные и предусматривает разные шаблоны (CLDR: даты).
Шаг 4. Разберите неоднозначное предупреждение¶
Если система пометила число словами, компактную запись или локальный формат, не исправляйте перевод автоматически. Сравните значение и требования проекта. Если текст соответствует норме и смысл не изменился, зафиксируйте причину, по которой предупреждение снято.
Шаг 5. Проверьте подозрительные коды отдельно¶
Сверьте каждый код или идентификатор посимвольно с источником и другими упоминаниями в файле. Пример Windows-1252 против Windows-1254 показывает, что проверка способна обнаружить именно такую подмену (pofilter). Не считайте обнаруженное различие ошибкой до проверки источника и контекста.
Шаг 6. Разберите исходную ошибку и эскалируйте сомнение¶
Если исходник противоречит сам себе, не выбирайте значение наугад. Отметьте расхождение и задайте вопрос ответственному лицу. Запишите принятое решение, чтобы редактор и переводчики, работающие с тем же документом, видели согласованный вариант.
Шаг 7. Проведите дополнительную ревизию текста высокого риска¶
Сверьте критические числа отдельно от общего отчёта: перечитайте исходное предложение, перевод и связанные упоминания в документе. Для юридического или процедурного текста оцените последствия ошибочного значения и предусмотрите более тщательную проверку. Еврокомиссия связывает объём контроля с риском документа и возможными последствиями ошибок (описание контроля качества Еврокомиссии, обновлено 18 июня 2026 года).
Такой порядок не превращает QA в гарантию отсутствия ошибок. Он помогает понять, какие предупреждения можно закрыть как форматное различие, а какие требуют исправления, согласования или отдельной ревизии.
FAQ¶
Почему проверка чисел в CAT-инструменте показывает ложные ошибки?¶
Проверка может сравнивать строки цифр, не понимая их смысл. Она способна принять локальный разделитель, запись числа словами, порядковую форму или компактное обозначение за пропуск либо добавление числа.
Какие числовые ошибки автоматическая QA-проверка может пропустить?¶
Проверка по совпадению цифр может не заметить смысловую ошибку, если все цифры сохранены, но изменились знак, разрядность, единица измерения или связь числа с объектом. Алгоритм, который видит только символы, также может не распознать числа, записанные словами.
Нужно ли отключать проверку чисел в CAT-инструменте?¶
Не стоит отключать её для всех текстов из-за шумных сигналов. Настройте проверку под языковую пару и формат, а каждое предупреждение оценивайте в контексте исходника и целевого текста.
Как проверять даты, валюты и единицы измерения при локализации?¶
Сначала установите, какое значение выражает исходная запись, затем проверьте целевую запись с учётом языковой локали, формата даты, валюты и единицы измерения. Даты нужно сравнивать по смыслу, а не только по совпадающим символам.
Как уменьшить количество ложных тревог в проверке чисел?¶
Учитывайте локальные разделители и допустимые форматы, различайте смысловую проверку и буквальное сравнение строк, а повторяющиеся безопасные случаи фиксируйте в правилах команды. Не снимайте предупреждение, пока не сверили контекст.