Переводчик сдал файл. Менеджер переслал клиенту. Клиент открыл - а там числа из исходника не совпадают с числами в переводе, два абзаца пропущены, а в юридическом термине ошибка, которая меняет смысл всего пункта договора. Проект на $15 000 уходит на переделку, дедлайн сорван, клиент задает неудобные вопросы.
Это не редкий сценарий. По данным CSA Research, около 40% переводческих проектов проходят через хотя бы один цикл существенных правок после сдачи. Причина почти всегда одна - отсутствие системного контроля качества между переводом и финальной доставкой.
TEP-модель (Translation - Editing - Proofreading) решает эту проблему. Три последовательных этапа, минимум два разных специалиста, четкие критерии на каждом шаге. Ниже - разбор каждого этапа, дополнительные уровни QA для сложных проектов и практические рекомендации по внедрению.
Что такое TEP-модель и откуда она взялась¶
TEP - это три этапа обработки текста:
- T (Translation) - первичный перевод: лингвист переводит исходный текст на целевой язык
- E (Editing) - редактирование (билингвальная ревизия): второй лингвист сверяет перевод с оригиналом
- P (Proofreading) - вычитка (монолингвальная проверка): третий специалист читает только целевой текст на предмет ошибок
Модель закреплена в ISO 17100 - международном стандарте для переводческих услуг. Стандарт требует как минимум два этапа: перевод + редактирование. Это так называемый “принцип четырех глаз” (four-eye principle) - один человек переводит, другой проверяет.
The four-eye principle means that at least two qualified linguists must be involved in every translation project - the translator and the reviser. This is the minimum quality standard defined by ISO 17100.
Почему именно два человека минимум? Потому что автор текста - любого текста - плохо видит собственные ошибки. Мозг подставляет то, что вы хотели написать, вместо того, что реально написали. Это работает одинаково для перевода романа и для перевода контракта на поставку оборудования.
Третий этап - пруфридинг - в ISO 17100 не обязателен, но большинство серьезных агентств его включают в стандартный воркфлоу. Особенно для публикуемых текстов, маркетинга и юридических документов.
Здесь стоит отметить разницу между TEP для “обычного” человеческого перевода и процессом пост-редактирования машинного перевода (MTPE). Второй регулируется отдельным стандартом - ISO 18587. В MTPE-воркфлоу этап T заменяется на MT + post-editing, но этапы E и P остаются теми же. Некоторые агентства объединяют оба подхода: часть проекта переводится человеком, часть - через MT+PE, а редактирование и вычитка единые для всего проекта.
Три этапа TEP: что происходит на каждом¶
T - Translation (перевод)¶
Первый лингвист создает перевод с нуля. Это самый ресурсоемкий этап - здесь закладывается фундамент, на котором строится все остальное.
Требования к переводчику по ISO 17100:
- Носитель целевого языка (или эквивалентный уровень владения)
- Профильное образование в лингвистике/переводе или минимум 5 лет опыта
- Предметная экспертиза в тематике проекта (если это медицина - переводчик должен разбираться в медицинской терминологии)
На этом этапе переводчик работает с CAT-инструментами, translation memory, терминологическими базами и style guide. Все это снижает количество ошибок, которые потом придется ловить на следующих этапах. Хорошо настроенная TM экономит время и деньги, но только если она чистая - “грязная” TM с неисправленными ошибками из старых проектов множит эти ошибки в новых.
Типичная продуктивность: 2 000-3 000 слов в день для сложного специализированного контента, 4 000-5 000 для общего текста. Эти цифры сильно зависят от языковой пары, предметной области и наличия TM-совпадений.
E - Editing (редактирование / ревизия)¶
Второй лингвист открывает оригинал и перевод рядом и проверяет:
- Точность - все ли передано, нет ли пропусков, добавлений или искажений смысла
- Терминология - соответствует ли перевод глоссарию и отраслевым стандартам
- Полнота - все ли сегменты переведены, нет ли пропущенных абзацев
- Стиль - соответствует ли текст style guide клиента
- Числа и данные - совпадают ли цифры, даты, единицы измерения
Это билингвальная проверка - редактор работает с обоими языками одновременно. Именно здесь ловится 70-80% критических ошибок: неверная передача смысла, пропущенные предложения, неправильные термины.
Требования к редактору аналогичны требованиям к переводчику (ISO 17100), но с дополнительным условием: редактор должен уметь оценивать качество чужого перевода, а не только создавать свой. Это разные навыки - хороший переводчик не автоматически хороший редактор, и наоборот.
In a typical TEP workflow, the editing stage catches 3 to 5 times more critical errors than proofreading. This is because bilingual comparison reveals meaning shifts that monolingual reading simply cannot detect.
Продуктивность редактора обычно в 1.5-2 раза выше, чем у переводчика: 5 000-8 000 слов в день. Но это зависит от качества первичного перевода - если перевод плохой, редактирование превращается в переписывание, и скорость падает до уровня полного перевода.
Есть одна ловушка, о которой редко говорят: “авторитет оригинала”. Редактор знает, что перед ним работа коллеги, и подсознательно склонен доверять ей. Особенно если переводчик - опытный специалист с хорошей репутацией. Поэтому для критичных проектов полезна “слепая ревизия” - когда редактор не знает, кто выполнял перевод.
P - Proofreading (вычитка)¶
Третий специалист читает только целевой текст - без оригинала. Задача: оценить текст так, как его увидит конечный читатель.
Что проверяет пруфридер:
- Грамматика и орфография
- Пунктуация
- Читаемость и естественность звучания
- Логические связки между предложениями
- Единообразие стиля на протяжении всего документа
- Опечатки и форматирование
Пруфридер не сравнивает с оригиналом - это сознательное решение. Он читает текст “свежими глазами” и ловит то, что не видят переводчик и редактор, погруженные в билингвальное сравнение. Корявая фраза, которая формально правильно передает смысл, но звучит неестественно для носителя - это задача пруфридера.
Классический пример: переводчик перевел “The company shall indemnify the contractor” как “Компания должна возместить подрядчику убытки”. Редактор проверил - смысл передан верно. Пруфридер читает и спрашивает: “Возместить подрядчику убытки или возместить убытки подрядчика? Это разные вещи.” Без пруфридинга двусмысленность уходит к клиенту.
Продуктивность: 8 000-12 000 слов в день, потому что пруфридер не переключается между языками и работает быстрее.
Сравнение этапов TEP¶
| Параметр | Translation | Editing | Proofreading |
|---|---|---|---|
| Кто выполняет | 1-й лингвист | 2-й лингвист | 3-й специалист |
| Тип проверки | - | Билингвальная | Монолингвальная |
| Фокус | Создание перевода | Точность, терминология, полнота | Читаемость, грамматика, стиль |
| Работает с оригиналом | Да | Да | Нет |
| Скорость (слов/день) | 2 000-5 000 | 5 000-8 000 | 8 000-12 000 |
| Обязательность по ISO 17100 | Да | Да | Нет (рекомендуется) |
| Какие ошибки ловит | - | Смысловые, терминологические, пропуски | Стилистические, грамматические, опечатки |
Иногда клиенты спрашивают: “А можно без пруфридинга? Экономим время и деньги.” Можно. ISO 17100 требует только T+E. Но на практике пруфридинг добавляет 10-15% к стоимости и ловит ошибки, которые редактор пропускает из-за “билингвального тоннельного зрения” - когда вы настолько сосредоточены на передаче смысла, что не замечаете, что фраза звучит криво.
Дополнительные уровни QA за пределами TEP¶
TEP - базовая модель. Для сложных проектов, регулируемых отраслей или высокорискового контента нужны дополнительные слои проверки.
SME review (экспертная проверка)¶
Subject Matter Expert - специалист в предметной области, не обязательно лингвист. Врач проверяет медицинский перевод. Юрист - правовой. Инженер - техническую документацию.
SME не оценивает качество языка. Он отвечает на один вопрос: “Верно ли передана суть?” Переводчик может идеально перевести фразу, но если он не знает, что в конкретной юрисдикции “tort” и “delict” - это разные вещи, SME это поймает.
Когда нужен SME review:
- Медицинские документы (клинические исследования, инструкции к препаратам, протоколы)
- Юридические тексты (контракты, регуляторные документы, патенты)
- Техническая документация для safety-critical отраслей (авиация, атомная энергетика, нефтегаз)
- Финансовая отчетность (IFRS, аудиторские заключения)
Стоимость SME review зависит от домена. Юрист или врач, проверяющий перевод, берет за час - не за слово. Типичные ставки: $80-200/час, на проверку 5 000 слов уходит 2-4 часа. Дорого? Дешевле, чем ошибка в дозировке лекарства.
Back-translation (обратный перевод)¶
Независимый переводчик берет готовый перевод и переводит его обратно на исходный язык. Результат сравнивают с оригиналом. Расхождения указывают на места, где перевод мог исказить смысл.
Это дорого (по сути, вы платите за два дополнительных перевода) и долго. Но в фармацевтике и клинических исследованиях back-translation обязателен - FDA и EMA требуют его для опросников пациентов (Patient-Reported Outcomes), информированных согласий и ключевых документов клинических испытаний.
Back-translation is not about producing a polished text. It’s a diagnostic tool - a way to surface meaning shifts that may not be visible through direct bilingual review.
Процесс обычно выглядит так: перевод EN>RU делает переводчик A. Обратный перевод RU>EN делает переводчик B (который не видел оригинал). Лингвист C сравнивает оригинал с back-translation и помечает расхождения. Переводчик A исправляет проблемные места. Иногда цикл повторяется 2-3 раза, пока все стороны не согласятся с результатом.
In-country review (ICR)¶
Перевод отправляют носителю языка, который живет в целевой стране и работает в целевой отрасли. ICR особенно важен для маркетинговых текстов, UI/UX и всего, что должно звучать “как местное”.
Пример: вы перевели рекламную кампанию с английского на испанский. Какой испанский - кастильский для Испании или латиноамериканский для Мексики? Фразы, которые отлично работают в Мадриде, могут звучать странно или даже обидно в Мехико. ICR-ревьюер из целевого рынка поймает такие нюансы.
Другой пример - перевод на португальский. Бразильский и европейский португальский различаются не только лексикой, но и грамматикой, пунктуацией, форматированием дат и чисел. ICR-ревьюер из Бразилии за 5 минут найдет фразы, которые звучат “по-португальски” вместо “по-бразильски”.
Когда добавлять дополнительные уровни¶
| Тип контента | TEP достаточно? | Нужен SME? | Нужен back-translation? | Нужен ICR? |
|---|---|---|---|---|
| Внутренние документы | Да | Нет | Нет | Нет |
| Техническая документация | Обычно да | Желательно | Нет | Нет |
| Юридические контракты | Да | Да | По требованию | Нет |
| Маркетинг / реклама | Да | Нет | Нет | Да |
| Фарма / клинические исследования | Да | Да | Да (обязательно) | Желательно |
| UI/UX локализация | Да | Нет | Нет | Да |
| Финансовая отчетность | Да | Да | Нет | Нет |
Автоматизированный QA: что проверяют тулы¶
Человеческий контроль качества - это основа. Но некоторые ошибки гораздо эффективнее ловит автоматика. Непарные теги в HTML, несовпадающие числа, двойные пробелы, непереведенные сегменты - все это поддается формальной проверке и не требует лингвистического чутья.
Основные QA-тулы¶
Xbench - один из самых популярных standalone QA-чекеров. Работает с файлами из любых CAT-инструментов: XLIFF, SDLXLIFF, MQXLIFF, TMX. Проверяет терминологию, числа, теги, консистентность переводов, непереведенные сегменты. Базовая версия бесплатна - это делает Xbench точкой входа для фрилансеров, которые хотят добавить автоматизированный QA в свой воркфлоу.
Verifika - QA-тул с фокусом на автоматизацию. Интегрируется с Trados, memoQ, Wordfast. Умеет проверять длину перевода относительно оригинала (критично для UI, где кнопка должна вместить текст), правильность URL-адресов, форматирование. Поддерживает пакетную обработку - можно прогнать QA по сотне файлов одним кликом.
QA Distiller - мощный тул с настраиваемыми правилами. Позволяет создавать кастомные проверки под конкретного клиента или домен. Поддерживает регулярные выражения для поиска паттернов. Если ваш клиент требует, чтобы “Торговая марка” писалась с заглавной буквы в каждом случае - QA Distiller поймает все отклонения.
Встроенный QA в CAT-системах - Trados, memoQ, Smartcat, Memsource (Phrase) имеют собственные QA-модули. Они менее гибкие, чем standalone-тулы, но удобны тем, что работают прямо в рабочей среде переводчика без необходимости экспортировать файлы.
Что проверяет автоматизированный QA¶
| Категория проверки | Что именно | Пример ошибки |
|---|---|---|
| Теги и форматирование | HTML/XML теги, парность скобок | <b>текст без закрывающего </b> |
| Числа и даты | Совпадение чисел в исходнике и переводе | “15 000 EUR” в оригинале, “1 500 EUR” в переводе |
| Терминология | Соответствие глоссарию | “liability” переведено как “обязательство” вместо утвержденного “ответственность” |
| Консистентность | Одинаковый перевод одинаковых сегментов | “Cancel” переведено и как “Отмена” и как “Отменить” |
| Непереведенные сегменты | Сегменты, оставленные на исходном языке | Абзац на английском посреди русского текста |
| Пунктуация | Двойные пробелы, неправильные кавычки | Прямые кавычки “…” вместо типографских “…” |
| Длина | Перевод значительно длиннее/короче оригинала | Подозрительно, если перевод на 300% длиннее - возможно, добавлен лишний текст |
По данным Nimdzi, агентства, которые используют автоматизированный QA как обязательный шаг перед сдачей проекта, снижают количество клиентских рекламаций на 35-45%. Это не замена человеческой проверки - это дополнение, которое ловит “механические” ошибки, чтобы редактор мог сосредоточиться на смысле и стиле.
Важный момент: автоматический QA нужно запускать дважды. Первый раз - переводчик проверяет свою работу перед сдачей. Второй раз - PM или QA-менеджер проверяет финальный файл перед отправкой клиенту. Удивительно, как часто переводчик “чинит” ошибки в сегментах, но забывает сохранить исправления или вносит новые ошибки в процессе правки.
MQM/DQF: как измерять качество перевода в цифрах¶
Проверить перевод - это одно. Измерить его качество и сравнить результаты разных переводчиков или проектов - совсем другое. Для этого существует MQM (Multidimensional Quality Metrics) - стандартизированная система классификации ошибок.
Категории ошибок MQM¶
MQM делит ошибки на пять основных категорий:
Accuracy (точность) - ошибки передачи смысла. Пропуски, добавления, искажения, неверный перевод терминов. Самая опасная категория - ошибка точности в юридическом тексте может стоить миллионы.
Fluency (беглость) - грамматика, орфография, пунктуация, естественность звучания на целевом языке. Текст может быть точным, но звучать как машинный перевод 2010 года.
Terminology (терминология) - использование неправильных или неконсистентных терминов. Отдельная от accuracy категория, потому что терминологические ошибки требуют проверки по глоссарию, а не по контексту.
Style (стиль) - несоответствие style guide, неправильный регистр (формальный вместо неформального), неподходящий тон. Перевод может быть точным и грамотным, но не соответствовать ожиданиям клиента.
Locale conventions (локальные конвенции) - форматы дат, чисел, валют, единиц измерения, адресов. “12/05/2026” - это 12 мая или 5 декабря? Зависит от локали. “1,500” - это тысяча пятьсот или одна целая пять? Опять зависит от страны.
Уровни серьезности¶
Каждой ошибке присваивается severity (серьезность):
- Critical - ошибка, которая делает перевод непригодным для использования или создает риск (неверный перевод дозировки лекарства, искажение юридического обязательства, оскорбительный контент из-за неверного перевода)
- Major - ошибка, которая заметно влияет на качество и требует исправления (неверный термин, пропущенное предложение, грубая грамматическая ошибка)
- Minor - ошибка, которая не влияет на смысл, но снижает впечатление о качестве (опечатка, лишний пробел, непоследовательное использование заглавных букв)
Как использовать MQM на практике¶
Базовая формула качества: каждой ошибке присваивается балл в зависимости от категории и серьезности. Типичная шкала:
| Серьезность | Штрафные баллы |
|---|---|
| Critical | 5-10 |
| Major | 2-5 |
| Minor | 0.5-1 |
Общий счет качества = сумма штрафных баллов / количество проверенных слов x 1000.
Если результат ниже порогового значения (обычно 3-5 баллов на 1000 слов) - перевод считается приемлемым. Если выше - отправляется на доработку.
Пример: в проекте на 10 000 слов найдено 2 major ошибки (2 x 3 = 6) и 5 minor (5 x 1 = 5). Итого: (6 + 5) / 10 000 x 1000 = 1.1 балла на 1000 слов. При пороге 5.0 - перевод проходит. Если добавить 1 critical (1 x 7 = 7) - получаем (6 + 5 + 7) / 10 000 x 1000 = 1.8. Все еще проходит, но одна critical ошибка может автоматически означать “не принято” - зависит от правил проекта.
Это не абстрактная теория. MQM активно используют крупные агентства и заказчики: Google, Microsoft, Adobe, Booking.com. Если вы работаете с enterprise-клиентами, вероятность столкнуться с MQM-метриками растет с каждым годом. И если ваш QA-процесс не позволяет выдавать результат с оценкой 2-3 балла на 1000 слов - вы проиграете тендер агентству, которое может.
Когда базового TEP недостаточно: чек-лист¶
TEP покрывает 80% переводческих проектов. Но для оставшихся 20% - где ставки выше, регуляторные требования жестче, а цена ошибки критична - нужен расширенный QA-пайплайн.
Вот признаки того, что вам нужно больше, чем T+E+P:
-
Регуляторные требования. Фармацевтика, медицинские изделия, финансовая отчетность. Если перевод проходит через регулятора (FDA, EMA, финансовый аудитор) - добавьте SME review и, возможно, back-translation.
-
Юридическая ответственность. Контракты, патенты, судебные документы. Ошибка в переводе контракта может стать основанием для спора. SME review юристом - обязательно.
-
Публичный маркетинговый контент. Рекламные кампании, слоганы, посты в соцсетях для нового рынка. Один неудачный перевод может стать вирусным мемом. ICR - обязательно.
-
Высокий объем с множеством переводчиков. Когда на проекте работают 10+ переводчиков, консистентность страдает. Автоматизированный QA + выделенный QA-менеджер - обязательно.
-
Safety-critical контент. Инструкции по эксплуатации оборудования, предупреждения о безопасности, медицинские инструкции для пациентов. Back-translation + SME review.
-
Первый проект с новым переводчиком. Пока вы не знаете уровень нового исполнителя, усиленный QA - страховка. После 2-3 успешных проектов можно ослабить контроль.
Практические советы по внедрению multi-step QA¶
Начните с минимального TEP¶
Если в вашем агентстве нет формализованного QA-процесса - не пытайтесь внедрить MQM, back-translation и ICR одновременно. Начните с базы: каждый перевод проходит через второго лингвиста. Это уже отсекает 70-80% критических ошибок. Когда T+E станет привычкой, добавляйте следующие уровни.
Формализуйте чек-листы¶
Для каждого этапа нужен конкретный чек-лист: что проверять, в каком порядке, какие критерии приемки. Без чек-листа редактор проверяет “на глаз”, и результат зависит от его настроения и загрузки.
Пример чек-листа для editing:
- Все сегменты переведены (нет пропусков)
- Числа совпадают с оригиналом
- Терминология соответствует глоссарию
- Имена собственные переданы корректно
- Форматирование сохранено
- Стиль соответствует style guide клиента
- Нет буквализмов и калек
- Единицы измерения конвертированы (если нужно)
Автоматизируйте то, что можно автоматизировать¶
Запуск QA-чекера (Xbench, Verifika или встроенного в CAT) должен быть обязательным шагом перед передачей файла на следующий этап. Это не отменяет человеческую проверку, но экономит время редактора - он не тратит его на поиск двойных пробелов и несовпадающих чисел. Настройте QA-профили для разных клиентов: у одного свой глоссарий, у другого - особые требования к тегам, у третьего - нестандартный формат чисел.
Разделяйте роли¶
Переводчик не должен редактировать сам себя. Это главное правило TEP и принцип четырех глаз. Соблазн сэкономить и попросить переводчика “самому перечитать” велик, но результат будет заметно хуже. Мозг автора подставляет правильный вариант вместо того, что написано на экране. Если бюджет не позволяет отдельного редактора на каждый проект - хотя бы чередуйте: переводчик A редактирует переводчика B, и наоборот.
Считайте стоимость ошибки, а не стоимость QA¶
QA добавляет 30-50% к стоимости проекта. Это кажется дорого - пока вы не посчитаете, сколько стоит переделка после клиентской рекламации. Один возврат на переделку - это потерянное время PM, повторная работа лингвистов, нервы и репутационный ущерб. Два возврата подряд - и клиент ищет другое агентство. Три - и он пишет отзыв в ProZ или TranslatorsCafe.
Ведите статистику ошибок¶
Записывайте типы и количество ошибок по каждому переводчику и проекту. Через 3-6 месяцев у вас будет картина: кто стабильно сдает качественные переводы, кто требует усиленной проверки, какие типы ошибок повторяются чаще всего. На основе этих данных можно точечно обучать переводчиков и оптимизировать QA-процесс. Если переводчик X систематически ошибается в числах - может, ему нужен не усиленный QA, а обязательный Xbench перед сдачей.
Калибруйте ожидания с клиентом¶
Не все проекты требуют полного TEP + SME + ICR. Объясните клиенту, какие уровни QA входят в стоимость, а какие - опция. “Базовый пакет - T+E. Полный пакет - T+E+P. Премиум - TEP + SME review. Для фармацевтики - TEP + SME + back-translation.” Прозрачность в этом вопросе повышает доверие и упрощает разговор о цене - клиент видит, за что он платит.
FAQ¶
Чем editing отличается от proofreading в переводе?¶
Editing (редактирование) - билингвальная проверка, где редактор сравнивает перевод с оригиналом на предмет точности, полноты и терминологической корректности. Proofreading (вычитка) - монолингвальная проверка, где специалист читает только перевод и оценивает его читаемость, грамматику и стиль. Editing ловит ошибки смысла, proofreading - ошибки формы.
Обязателен ли TEP-процесс по ISO 17100?¶
ISO 17100 требует минимум два этапа: перевод (T) и редактирование (E) - принцип четырех глаз. Третий этап - proofreading - рекомендован, но не обязателен. Полный TEP-цикл обязателен только если это прописано в спецификации проекта или в договоре с клиентом.
Какие автоматизированные QA-тулы лучше для переводчика?¶
Среди standalone-решений популярны Xbench (бесплатная базовая версия), Verifika и QA Distiller. Все основные CAT-системы - Trados, memoQ, Smartcat, Phrase - имеют встроенные QA-модули. Для фрилансера обычно достаточно встроенного QA + Xbench. Для агентства с большим потоком проектов стоит рассмотреть Verifika или QA Distiller с кастомными правилами.
Что такое MQM и зачем он нужен переводческому агентству?¶
MQM (Multidimensional Quality Metrics) - стандартизированная система классификации переводческих ошибок по категориям (точность, беглость, терминология, стиль, локальные конвенции) и серьезности (critical, major, minor). MQM позволяет измерять качество перевода в цифрах, сравнивать переводчиков, отслеживать прогресс и обосновывать решения перед клиентом. Используется Google, Microsoft, Adobe и другими крупными заказчиками.
Когда нужен back-translation и сколько он стоит?¶
Back-translation обязателен в фармацевтике (клинические исследования, опросники пациентов, информированные согласия) и часто требуется для юридических документов в международных спорах. Стоимость - фактически цена еще одного полного перевода, плюс время на сверку и анализ расхождений. Суммарно back-translation увеличивает бюджет проекта на 60-100%, поэтому его применяют только там, где цена ошибки многократно превышает затраты на дополнительную проверку.
Как внедрить multi-step QA в небольшом переводческом агентстве?¶
Начните с формализации T+E: каждый перевод должен проходить через второго лингвиста. Добавьте обязательный автоматизированный QA-чек (встроенный в CAT или Xbench) перед передачей файла редактору и перед отправкой клиенту. Создайте чек-листы для editing и proofreading. Ведите лог ошибок по каждому переводчику. Эти четыре шага - базовая инфраструктура QA, которая работает даже в агентстве из 3-5 человек. Расширяйте процесс по мере роста: MQM-метрики, SME review, ICR - когда появится соответствующий объем и тип проектов.