Автоматизированные QA-проверки в переводе: теги, числа, терминология

Представь: ты сдаешь перевод технического мануала на 200 страниц. Два месяца работы, сложная терминология, сотни XML-тегов в каждом файле. Клиент открывает - и через день присылает список: 47 сломанных тегов, десятичные разделители неправильные в 23 местах, термин “клапан” переведен тремя разными способами на протяжении документа. Два дня переделок. Репутация подпорчена. Дедлайн по следующему проекту уже горит, потому что ты сидишь и правишь теги вручную.

Самое обидное - все эти ошибки можно было поймать за 30 секунд. Автоматический QA-прогон перед сдачей нашел бы каждую из них. Не потому что ты плохой переводчик - а потому что человеческий мозг не заточен на проверку парности XML-тегов в документе из 48 000 сегментов.

Ниже - разбор того, что именно ловят автоматизированные QA-проверки, какие тулы существуют, и как построить воркфлоу, в котором такие ошибки не доходят до клиента.

Что такое автоматизированные QA-проверки и зачем они переводчику¶

Автоматизированные QA-проверки - это скрипты и алгоритмы, которые сканируют пару “исходник + перевод” на определенные паттерны ошибок. Не машинный перевод, не искусственный интеллект - просто набор правил, которые проверяют формальные вещи: совпадают ли теги, одинаковы ли числа в оригинале и переводе, нет ли пропущенных сегментов, используется ли правильная терминология из глоссария.

Что они ловят:

• Теги и форматирование - пропущенные, лишние, сломанные XML/HTML теги
• Числа - несовпадение чисел между оригиналом и переводом, неправильные десятичные разделители
• Терминология - нарушение глоссария, несогласованность перевода одного и того же термина
• Консистентность - один и тот же исходный сегмент переведен по-разному (или наоборот, разные исходники - одинаково)
• Пунктуация - лишние/пропущенные точки, двойные пробелы, неправильные кавычки
• Пропуски - пустые или непереведенные сегменты

Чего они НЕ ловят:

• Семантические ошибки - слово переведено неправильно, но формально “похоже”
• Стилистические проблемы - текст звучит криво, но формально правильно
• Ошибки смысла - предложение грамматически верное, но говорит противоположное
• Культурные несоответствия - шутка, которая не работает в целевой культуре
• Контекстные ошибки - слово правильное само по себе, но не подходит к контексту

Автоматический QA дополняет человеческую проверку, а не заменяет ее. Автомат ловит формальные ошибки, которые человек пропускает из-за усталости или невнимательности. Человек ловит смысловые ошибки, которые автомат не понимает в принципе. Одно без другого - дырявый процесс.

memoQ’s quality assurance (QA) module can perform over 100 different types of checks on bilingual documents and can be run on single documents or entire projects.

• memoQ Documentation

100+ типов проверок - и это только один тул. Попробуй вручную проверить хотя бы 20 из них в документе на 200 страниц. Не получится. Не потому что ты ленишься - потому что это физически невозможно для человеческого мозга за разумное время.

Еще один момент: QA-проверки работают в двух режимах. Первый - реал-тайм, прямо во время перевода. Ты закрываешь сегмент - система тут же подсвечивает проблему: “В оригинале два тега, в переводе один”. Второй - пакетная проверка после завершения перевода. Прогоняешь весь проект разом, получаешь список всех проблем с привязкой к конкретным сегментам.

Реал-тайм проверки полезны, но иногда раздражают - особенно когда ты только начал сегмент и система уже кричит об ошибке. Пакетная проверка - must have перед каждой сдачей. Без исключений.

Проверки тегов и форматирования¶

Теги - самая частая причина возвратов перевода на доработку в технических проектах. И самая легкопредотвратимая, потому что автоматический QA ловит 99% таких ошибок.

Что такое теги в контексте перевода¶

Когда ты переводишь файл в CAT-инструменте, часть контента - это не текст, а разметка. XML-теги (<b>, </b>, <ph id="1"/>), HTML-теги, плейсхолдеры ({0}, %s, %d, {{variable}}), маркеры форматирования (жирный, курсив, подстрочный, надстрочный индекс).

В CAT-редакторе теги обычно выглядят как цветные плашки или скобки. Ты их не трогаешь - просто переносишь в правильное место в переводе. Но когда у тебя 200 сегментов подряд с 4-5 тегами в каждом - рано или поздно один потеряется.

Типы проверок тегов¶

Парность тегов. Каждый открывающий тег должен иметь закрывающий. <b>текст</b> - правильно. <b>текст - ошибка. QA-тул проверяет это за миллисекунды.

Порядок тегов. <b><i>текст</i></b> - правильно. <b><i>текст</b></i> - неправильная вложенность, которая может сломать рендеринг.

Самозакрывающиеся теги. <br/>, <ph id="1"/> - должны присутствовать в переводе в том же количестве. Удалил случайно - пробел или разрыв строки пропал.

Плейсхолдеры. {0}, {1}, %s, %d, {{userName}} - это переменные, которые в рантайме заменяются на реальные значения. Если в оригинале Hello, {0}! а в переводе Привет! без {0} - пользователь увидит “Привет!” без своего имени. Или приложение крашнется.

Почему это критично¶

Один пропущенный закрывающий тег в UI-строке - и весь блок меню рендерится жирным шрифтом. Это не гипотетический пример - это реальная проблема, которую я видел в проекте локализации мобильного приложения. Строка <b>Settings</b> - Manage your account была переведена как <b>Настройки - Управление аккаунтом без закрывающего </b>. Результат: весь экран настроек стал жирным, кнопки поехали, QA-менеджер на стороне клиента писал гневное письмо.

А в случае с плейсхолдерами последствия еще хуже. Пропущенный %s в строке формата на C/C++ - это потенциальный краш приложения. Не “некрасиво отобразится”, а буквально segfault.

In the Quality Assurance pane, you can choose from a set of checks to run against target segments. Checks include tag and formatting verification, number validation, terminology compliance, and more.

• Phrase TMS QA Documentation

Практический совет¶

В большинстве CAT-тулов можно настроить жесткость проверки тегов. Для софтверной локализации ставь максимальную - любой пропущенный тег потенциально ломает приложение. Для маркетинговых текстов можно чуть ослабить - пропущенный <b> не крашнет сайт, хотя и выглядит неаккуратно.

И главное: никогда не удаляй теги “потому что в целевом языке они не нужны”. Если в оригинале <b>Important:</b> Read carefully и ты решил, что в русском жирный не нужен - не удаляй тег. Оставь его на месте. Решение о форматировании принимает не переводчик, а разработчик или DTP-специалист.

Числа, даты, единицы измерения¶

Числа - вторая по частоте категория ошибок после тегов. И самая коварная, потому что неправильное число в техническом документе может стоить денег, здоровья или даже жизни.

Форматы чисел: это сложнее, чем кажется¶

То, что в одной стране записывается как 1,000.50, в другой выглядит как 1.000,50, а в третьей - 1 000,50. Это не вкусовщина - это стандарты записи, и ошибка в них путает читателя.

Разница между основными форматами:

Автоматический QA сравнивает числа в оригинале и переводе. Если в исходнике 1,234.56 а в переводе 1234,56 - система не просто проверяет “есть ли число” - она понимает форматы и сопоставляет значения. Хорошие тулы (memoQ, Xbench) умеют различать разные форматы записи и не ругаются на правильную локализацию числа.

Даты: когда формат ломает визу¶

05/06/2026 - это 5 июня или 6 мая? Зависит от того, в какой стране ты находишься. В США - 6 мая (MM/DD/YYYY). В Европе - 5 июня (DD/MM/YYYY). В Японии вообще YYYY/MM/DD.

Это не абстрактная проблема. В переводах для иммиграционных документов неправильная дата - это отказ в визе. В переводах контрактов - это неправильная дата вступления в силу или дедлайн. В медицинских переводах - неправильная дата анализа.

QA-тул проверяет, что даты в переводе соответствуют датам в оригинале. Но здесь есть нюанс: тул должен знать, какой формат используется в исходном и целевом языке. Иначе он будет ругаться на каждую правильно адаптированную дату.

Единицы измерения¶

Перевод с американского на европейский рынок? Тогда дюймы в сантиметры, фунты в килограммы, Фаренгейт в Цельсий. И тут автоматический QA не всегда помогает - он проверяет числа, но не всегда понимает, что 72°F и 22°C - это одно и то же.

Однако QA-тул поймает другое: если в оригинале написано “72°F” а в переводе просто “72°C” без пересчета - число осталось тем же, а единица измерения сменилась. Это ошибка, и хороший QA-профиль ее отловит.

Валюта и телефонные номера¶

Символ валюты: $100 в английском, но 100 $ во французском (с пробелом и символом после числа). Или 100 USD - написание зависит от стандартов целевого языка.

Телефонные номера - отдельная боль. +1 (555) 123-4567 в США, +49 30 1234567 в Германии, +7 (495) 123-45-67 в России. QA-тул не пересчитает номер, но проверит, что цифры совпадают.

The most common QA errors in translation projects are inconsistent number formats, missing tags, and terminology violations. These three categories account for over 70% of all automated QA findings.

• Mitra Translations, QA Reports Beginner Guide

Что настроить¶

В QA-профиле обязательно укажи:

1. Формат чисел для исходного и целевого языка
2. Формат даты для обоих языков
3. Нужна ли конвертация единиц или только проверка числовых значений
4. Список исключений - номера страниц, артикулы, коды, которые не нужно проверять

Без этих настроек получишь тонну ложных срабатываний и начнешь игнорировать QA-отчет целиком. А это хуже, чем не иметь QA вообще - ложное чувство безопасности.

Терминологическая консистентность¶

Третий большой блок QA-проверок - и, пожалуй, самый недооцененный. Потому что сломанный тег видно сразу, неправильное число тоже. А вот тот факт, что “valve” в одном месте переведен как “клапан”, в другом как “вентиль”, а в третьем как “задвижка” - это заметит только внимательный читатель. Или автоматический QA.

Как работает проверка терминологии¶

У тебя есть термбаза (termbase, TB) или глоссарий - список терминов с утвержденными переводами. QA-тул проходит по каждому сегменту и проверяет:

• Если в исходнике есть термин из базы - использован ли его правильный перевод?
• Если в исходнике термин не из базы, но в переводе появилось слово из “запрещенного” списка - сигнал
• Если один и тот же исходный термин переведен по-разному в разных сегментах - предупреждение

Source consistency и target consistency¶

Source consistency - один и тот же исходный сегмент должен иметь одинаковый перевод во всем документе. Если “Click OK to continue” в сегменте 45 переведен как “Нажмите ОК для продолжения”, а в сегменте 312 как “Кликните ОК чтобы продолжить” - это inconsistency. Читатель путается.

Target consistency - обратная проверка. Разные исходные сегменты не должны иметь одинаковый перевод, если смысл разный. Если “Save” и “Keep” оба переведены как “Сохранить” - возможно, это правильно. А возможно, нет. QA подсвечивает, человек решает.

Запрещенные термины¶

Иногда клиент говорит: “Никогда не используйте слово X”. Например, в проекте для Microsoft запрещено слово “кликнуть” - только “щелкнуть”. Или в медицинском переводе запрещено использовать разговорные названия лекарств.

QA-тул ищет запрещенные слова в целевом тексте и помечает каждое вхождение. Простая проверка, но экономит часы ручного поиска.

Реальный кейс¶

Технический мануал по промышленному оборудованию, 300 страниц, английский на русский. Термин “valve” встречается 847 раз. Переводчик - опытный технический лингвист с 10-летним стажем. Результат без QA: “клапан” (612 раз), “вентиль” (198 раз), “задвижка” (37 раз). Три разных перевода одного термина. Технически все три варианта допустимы в определенном контексте, но в рамках одного документа это недопустимо - читатель (инженер на заводе) не должен гадать, один и тот же элемент описывается или три разных.

С термбазой и QA-проверкой: система подсветила бы каждое отклонение от утвержденного перевода “клапан” еще на этапе перевода. Вместо двух дней исправлений - 15 минут на ревью QA-отчета.

MQM и формальные фреймворки¶

MQM (Multidimensional Quality Metrics) - это фреймворк для оценки качества перевода, разработанный в рамках проекта QT21. Он категоризирует ошибки по типам и серьезности: от критических (меняет смысл) до минорных (стилистическое предпочтение).

Терминологические ошибки в MQM - это отдельная категория с подтипами: wrong term, inconsistent use of term, use of deprecated term. Если твое агентство работает по MQM-метрикам, автоматический QA покрывает значительную часть формальных категорий автоматически.

Подробнее о стандартах качества и TEP-модели - в статье про ISO 17100.

Инструменты: встроенный QA vs отдельные тулы¶

У тебя два пути: использовать QA, встроенный в CAT-инструмент, или подключить отдельный QA-тул. Или оба - что правильнее.

Встроенный QA¶

Каждый серьезный CAT-инструмент имеет встроенный QA-модуль. В memoQ это 100+ проверок. В Trados - около 50. В Smartcat, Phrase, Crowdin - свои наборы.

Плюсы встроенного QA:

• Работает прямо в редакторе, не нужно переключаться
• Реал-тайм предупреждения при работе с сегментом
• Доступ к TM и термбазе проекта
• Не нужно платить за отдельный тул

Минусы:

• Ограничен экосистемой одного CAT
• Не всегда достаточно гибкий для специфических проверок
• Нельзя проверить файлы из другого CAT-инструмента

Отдельные QA-тулы¶

Xbench и Verifika - два основных игрока. Оба умеют проверять файлы из любого CAT-инструмента и дают более гибкие возможности для настройки проверок.

Сравнительная таблица¶

Источники: Xbench, Verifika, Nimdzi обзор QA-тулов

Xbench: подробнее¶

Xbench - наверное, самый известный standalone QA-тул в индустрии. Версия 2.9 бесплатная и до сих пор рабочая - если бюджет ограничен, начни с нее.

Версия 3.0 - платная (99 EUR/год), но добавляет облачные фичи, автоматические проверки при коммите файла и поддержку большего количества форматов.

Ключевая особенность Xbench - он не редактирует файлы. Он генерирует отчет с найденными проблемами, а ты идешь и правишь в своем CAT-инструменте. Это одновременно минус (лишний шаг) и плюс (не рискуешь случайно испортить файл).

Xbench умеет: - Проверять файлы из Trados, memoQ, Wordfast, Transit, XLIFF и еще 25+ форматов - Использовать собственные чек-листы и regex-правила - Генерировать отчет в HTML или Excel - Работать как поисковый движок по TM и глоссариям (это отдельная полезная фича)

Verifika: подробнее¶

Verifika - более молодой тул, но с агрессивным развитием. Главный плюс - скорость. На проекте в 100 000 сегментов Verifika выдает результат за секунды, тогда как некоторые встроенные QA-модули могут думать минутами.

Второй плюс - Verifika умеет править ошибки прямо в интерфейсе. Нашел пропущенный тег - вставляешь на месте, без переключения в CAT. Для массовой правки тегов это экономит кучу времени.

55 встроенных проверок, плюс возможность добавлять свои через regex. Поддерживает XLIFF, SDLXLIFF, MQXLIFF, TTX, bilingual DOC и другие форматы.

Что выбрать¶

Если ты фрилансер и работаешь в одном CAT - встроенного QA часто достаточно. Но перед сдачей крупного проекта прогони его через Xbench или Verifika для подстраховки. Два прохода лучше одного.

Если ты PM в агентстве и принимаешь работу нескольких переводчиков - standalone тул обязателен. Ты не можешь полагаться на то, что каждый переводчик правильно настроил и запустил QA в своем инструменте.

Regex: когда стандартных проверок не хватает¶

Regex (Regular Expressions, регулярные выражения) - это язык паттернов для поиска текста. Звучит страшно, но для базовых QA-задач тебе хватит 10 минут на изучение основ.

Зачем переводчику regex¶

Стандартные QA-проверки покрывают типовые случаи. Но у каждого проекта свои особенности:

• Клиент требует, чтобы все даты были в формате DD.MM.YYYY, а не DD/MM/YYYY
• В тексте есть артикулы вида ABC-1234, которые не должны меняться при переводе
• Телефоны должны быть в формате +XX (XXX) XXX-XX-XX
• Сокращения единиц измерения должны быть с неразрывным пробелом: 5 кг, а не 5кг

Стандартная QA-проверка этого не знает. А regex-правило - знает.

Конкретные примеры¶

Проверка формата даты DD.MM.YYYY:

\b\d{2}\.\d{2}\.\d{4}\b

Этот паттерн найдет все строки вида 05.06.2026, 31.12.2025 и т.д. Если в целевом тексте попадется дата в формате 05/06/2026 - regex ее не найдет, и это будет означать ошибку формата.

Поиск числа без неразрывного пробела перед единицей измерения:

\d+(кг|км|мм|см|мл|г|м)\b

Найдет “5кг”, “100мм” - то есть случаи, где между числом и единицей нет пробела.

Проверка артикулов:

[A-Z]{2,4}-\d{3,6}

Найдет артикулы вроде ABC-1234, XY-56789. Если такой паттерн есть в исходнике, но нет в переводе - артикул потеряли.

Поиск двойных пробелов:

\s{2,}

Простейший паттерн, но невероятно полезный. Двойные пробелы - бич DTP, потому что в верстке они создают неравномерные интервалы.

Где писать regex-правила¶

Regex поддерживают практически все серьезные QA-тулы:

• memoQ - в настройках QA-профиля, раздел “Regular Expression” (можно задавать regex для исходника, целевого текста или обоих)
• Trados - через плагин sdl-community или встроенный regex QA checker
• Xbench - в разделе Custom Checks, поддержка regex из коробки
• Verifika - в разделе User-Defined Checks

Подробный гайд по настройке regex-проверок в Trados - в статье Alexa Orr.

Совет для начинающих¶

Не пытайся сразу написать regex для всего. Начни с 3-5 простых правил для своих типичных проектов:

1. Проверка формата даты
2. Двойные пробелы
3. Пробел перед единицами измерения
4. Артикулы/коды продуктов, которые не должны меняться
5. Формат телефона (если актуально)

Каждое из этих правил - 1-2 строки regex. За полчаса настроишь, а потом используешь годами.

Еще одна хитрость: не обязательно писать regex с нуля. В сообществе переводчиков полно готовых наборов - гугли “translation QA regex rules” или спроси в профильных группах ProZ, TranslatorsCafe. Люди охотно делятся.

Как построить QA-воркфлоу, который реально работает¶

QA - это не кнопка “проверить”, которую нажимаешь перед сдачей. Это процесс, встроенный в каждый этап работы. Вот как он должен выглядеть.

До перевода: подготовка¶

Термбаза. Перед началом проекта загрузи глоссарий клиента (или создай свой на основе референсных материалов). Без термбазы QA-проверка терминологии не работает - нечего проверять.

QA-профиль. Настрой правила для конкретного проекта: форматы чисел, формат дат, locale-специфичные правила пунктуации. Не используй дефолтный профиль для всех проектов - у медицинского перевода и локализации мобильного приложения разные приоритеты.

Глоссарий запрещенных терминов. Если клиент прислал стайлгайд с запретами (“не используйте X, используйте Y”) - внеси это в QA-профиль или создай отдельный глоссарий с запрещенными терминами.

Тестовый прогон. Переведи 5-10 сегментов, запусти QA. Убедись, что правила работают корректно и не выдают 500 ложных срабатываний. Лучше потратить 10 минут на настройку сейчас, чем час на разбор мусорного QA-отчета потом.

Во время перевода: реал-тайм проверки¶

Включи реал-тайм QA в своем CAT-инструменте. Да, иногда предупреждения раздражают. Но лучше поправить ошибку в момент написания, чем искать ее потом среди тысяч сегментов.

Минимальный набор реал-тайм проверок:

• Теги (пропущенные, лишние, неправильный порядок)
• Числа (несовпадение с оригиналом)
• Непереведенные сегменты (скопирован оригинал вместо перевода)
• Терминология из глоссария

Не включай все 100 проверок в реал-тайм - это замедлит работу и утопит тебя в предупреждениях. Остальные проверки - на этапе финальной пакетной проверки.

После перевода: финальный QA-прогон¶

Перевод закончен. Прежде чем сдавать - полный QA-прогон.

Шаг 1: Запусти встроенный QA в CAT-инструменте с полным набором проверок. Пройди по списку ошибок, исправь реальные проблемы, пометь ложные срабатывания как игнорируемые.

Шаг 2: Прогони через standalone тул (Xbench или Verifika). Разные тулы ловят разные вещи - Xbench лучше с consistency, Verifika быстрее с тегами. Два прохода лучше одного.

Шаг 3: Проверь QA-отчет на паттерны. Если 80% ошибок - это один и тот же тип (например, неправильный формат числа) - значит, ты систематически делал одну и ту же ошибку. Запомни и не повторяй в следующем проекте.

Человеческая проверка: то, что автомат не поймает¶

После автоматического QA - ревью живым человеком. Это может быть TEP-процесс (редактор + пруфридер) или хотя бы самостоятельная вычитка.

Автомат не поймает: - “Клапан открывается по часовой стрелке” вместо “против часовой стрелки” - Правильный термин, но в неправильном контексте - Грамматически верное предложение, которое звучит неестественно - Пропущенную частицу “не”, которая меняет смысл на противоположный

Подробнее о стоимости quality-процессов и почему экономить на QA - ложная экономия.

Интеграция QA в воркфлоу агентства¶

Если ты не фрилансер, а PM в агентстве - QA-воркфлоу усложняется. Несколько переводчиков на одном проекте, у каждого свои привычки, свои настройки.

Что делать:

1. Стандартный QA-профиль для всех проектов компании. Базовый набор правил, который используют все. Без исключений.
2. Проектный QA-профиль поверх стандартного - с настройками для конкретного клиента.
3. Обязательный QA-отчет от переводчика при сдаче файлов. Не “я проверил, все ок” - а приложенный файл QA-отчета с нулем необработанных ошибок.
4. Контрольный QA-прогон PMом после получения файлов - независимо от того, что прислал переводчик.
5. Документирование ложных срабатываний - если QA-правило регулярно дает false positives, его нужно поправить, а не игнорировать.

Требования к процессам QA и квалификации специалистов описаны в ISO 18587 для MTPE-проектов и в ISO 17100 для человеческого перевода.

FAQ¶

Какие QA-проверки встроены в memoQ и Trados?¶

memoQ предлагает более 100 типов проверок: теги, числа, терминология, консистентность, длина сегмента, пунктуация, regex-правила, проверка форматирования и другие. Trados - около 50 проверок из коробки, но их можно расширить плагинами. Оба тула поддерживают пользовательские regex-проверки и интеграцию с термбазами. Основная разница: memoQ дает больше проверок по умолчанию и более гибкую настройку профилей, Trados компенсирует это экосистемой плагинов.

Заменяет ли автоматический QA человеческую вычитку?¶

Нет. Автоматический QA ловит формальные ошибки: теги, числа, терминология, форматирование. Он не понимает смысл текста и не может оценить, насколько перевод точно передает оригинал. Пропущенная частица “не”, неверно понятая метафора, двусмысленная формулировка - это ловит только человек. QA + человеческая ревизия вместе дают результат, которого ни один из подходов не дает по отдельности.

Xbench бесплатный или платный?¶

Оба варианта. Xbench 2.9 - бесплатная версия, которая до сих пор работает и поддерживает основные форматы файлов (SDLXLIFF, MQXLIFF, XLIFF, TMX и другие). Xbench 3.0 - платная версия за 99 EUR/год, с облачными функциями, улучшенной поддержкой форматов и автоматизацией. Для фрилансера 2.9 вполне хватает. Для агентства или проектного менеджера, работающего с большими объемами - 3.0 окупается за один-два проекта.

Как проверить консистентность терминологии в переводе?¶

Три способа. Первый - загрузи термбазу в CAT-инструмент и включи QA-проверку терминологии. Система подсветит каждый сегмент, где термин из базы переведен не по глоссарию. Второй - используй source/target consistency check в Xbench или memoQ: он найдет случаи, когда одинаковый исходный текст переведен по-разному. Третий - прогони весь проект через Verifika с включенной проверкой consistency - она работает быстро даже на больших проектах.

Что такое MQM и как это связано с QA?¶

MQM (Multidimensional Quality Metrics) - это фреймворк для оценки качества перевода, разработанный в рамках европейского проекта QT21. MQM определяет категории ошибок (точность, беглость, терминология, стиль, locale conventions и другие) и их серьезность (критическая, большая, малая). Связь с автоматическим QA прямая: многие категории MQM (терминология, числа, форматирование, консистентность) можно проверять автоматически. Остальные (точность, стиль, беглость) требуют человеческой оценки. MQM используют крупные LSP и корпоративные клиенты для формализации требований к качеству.