Ошибки в ТЗ на технический перевод увеличивают стоимость итогового проекта на 30–50% за счет бесконечных итераций правок и переделок терминологии. Качественный бриф сокращает время согласования финального текста в 2.5 раза, превращая процесс из «угадывания смыслов» в промышленный конвейер.
Терминологический базис и глоссарии
Главный триггер правок — отсутствие закрепленного глоссария. В проектах объемом от 10 000 слов без согласованного списка терминов уровень расхождения в переводе одного и того же понятия достигает 15–20%. Например, термин «Valve» в гидравлике может быть переведен и как «клапан», и как «вентиль», что в инструкции по эксплуатации критично для безопасности.
Требуйте от заказчика или формируйте сами таблицу: Термин (EN) — Перевод (RU) — Контекст/Определение. Если глоссарий создается с нуля переводчиком, закладывайте дополнительные 0.05–0.10$ за слово или фиксированную ставку за единицу термина. Это инвестиция, которая убирает 80% правок по смыслу.
Экспертный вывод: Работа без глоссария в техническом переводе — это лотерея. Всегда фиксируйте терминологию до начала основного этапа перевода.
Спецификации форматов и верстки
Перевод «в Word» при исходнике в InDesign или FrameMaker ведет к потере структуры и раздуванию бюджета на верстку. Технический перевод документации требует четкого указания формата поставки: XLIFF для CAT-инструментов или редактируемый PDF. Ошибка в выборе формата на старте добавляет к срокам 2–3 рабочих дня на ручной перенос текста.
Кейс: Заказчик предоставил сканы PDF. Стоимость подготовки текста (OCR) составила 20% от цены самого перевода. Если бы ТЗ включало требование к исходникам в редактируемом формате, эти затраты были бы нулевыми. Также важно указать лимит расширения текста: русский язык длиннее английского на 15–25%, что может «развалить» верстку интерфейса или таблиц.
Экспертный вывод: Формат файла определяет стоимость. Требуйте исходники в редактируемом виде, чтобы избежать переплаты за ручной набор текста.
Локализация единиц измерения и стандартов
Игнорирование стандартов оформления приводит к тому, что документация становится непригодной для эксплуатации. В ТЗ должен быть четко прописан выбор: оставить оригинальные единицы измерения или провести конвертацию. Сравнение методов локализации технических единиц измерения и стандартов оформления при техническом переводе документации: метрическая система vs региональные спецификации показывает, что ошибки в десятичных разделителях (точка vs запятая) в чертежах ведут к браку деталей при производстве.
Указывайте стандарт: ГОСТ, ISO или DIN. Например, для электротехнической документации разница в обозначении фаз между стандартами США и ЕС может привести к неправильному монтажу оборудования. Ошибка в одной цифре или символе в техпаспорте — это риск многомиллионных убытков при пуско-наладке.
Экспертный вывод: Локализация — это не замена слов, а адаптация под региональный стандарт. Без указания конкретного ГОСТ/ISO в ТЗ переводчик будет действовать субъективно.
Целевая аудитория и уровень сложности
Разрыв между уровнем языка и квалификацией читателя — причина 30% правок по стилистике. Текст для сервисного инженера (высокая плотность терминов, минимум пояснений) и текст для конечного пользователя (упрощенный язык, пошаговые инструкции) — это два разных продукта. Если в ТЗ не указан профиль читателя, переводчик часто уходит в излишний академизм или, наоборот, в примитивизм.
Пример: Перевод руководства по эксплуатации промышленного станка. Вариант А (для профи): «Обеспечить демпфирование вибраций». Вариант Б (для оператора): «Убедитесь, что станок не трясется при работе». Использование варианта А для оператора приведет к бесконечным правкам от отдела маркетинга или службы поддержки.
Экспертный вывод: Определяйте Persona читателя. Чем точнее описан профиль пользователя, тем меньше правок по «тону» и «понятности» текста.
Процесс контроля качества и приемки
Отсутствие критериев приемки превращает правки в бесконечный процесс. В ТЗ должен быть зафиксирован регламент: кто проверяет (LQA — Language Quality Assurance), какие типы ошибок считаются критическими (Critical), а какие — стилистическими (Minor). Внедрение многоязыковой архитектуры документации на стоимость поддержки продукта: анализ затрат при техническом переводе документации подтверждает, что четкий регламент приемки сокращает цикл согласования с 4-х до 1-го этапа.
Рекомендуемая схема: Перевод → Редактирование (Bilingual review) → Вычитка (Final proofreading). Если заказчик хочет сократить расходы, убирая этап редактирования, он должен принять риск увеличения итераций правок на финальном этапе на 40–60%.
Экспертный вывод: Бесплатные правки бесконечны, если нет критериев качества. Фиксируйте количество итераций и перечень критических ошибок в ТЗ.
Вывод
Идеальное ТЗ на технический перевод — это документ, который исключает интерпретацию. Чтобы минимизировать правки, начните с формирования глоссария и четкого определения целевой аудитории. Избегайте передачи заказов в формате «просто переведите этот PDF» — это гарантированный путь к переплате и срыву сроков. Рекомендую внедрять комплексную модель управления жизненным циклом контента, где ТЗ является живым документом, обновляемым по мере роста продукта, а не разовой бумажкой. Выбирайте исполнителей, которые сами требуют глоссарий и уточняют стандарты оформления — это признак профессионального подхода, который экономит ваши деньги.