Одновременный перевод техдокументации на русский, казахский и английский: управление трёхъязычными проектами

Инженер по вводу в эксплуатацию открывает операционную инструкцию к насосной станции и обнаруживает, что английский оригинал называет узел «discharge manifold», русская версия — «напорный коллектор», а казахская — «айдау коллекторы». Три документа, три термина, и ни одного способа быстро понять, что речь об одном и том же узле. Для проекта, где подрядчик работает по английской документации, надзорный орган требует казахскую версию, а эксплуатационный персонал читает русскую, такое расхождение оборачивается не филологическим спором, а остановкой пусконаладки.

Трёхъязычные проекты стали нормой для крупных промышленных объектов Казахстана. Причина не только в удобстве: требование вести документацию на государственном языке закреплено законодательно, английский приходит вместе с иностранными подрядчиками и оборудованием, а русский остаётся рабочим языком большинства инженерных команд. Разберём, как выстроить перевод сразу на три языка так, чтобы версии не расходились, сроки не срывались, а терминология оставалась единой на всём жизненном цикле документа.

Почему трёхъязычность — это не «перевести три раза»

Самое частое заблуждение заказчика: трёхъязычный проект — это обычный перевод, умноженный на три. На практике добавление третьего языка меняет саму архитектуру процесса. При двух языках достаточно одной пары «оригинал — перевод». При трёх появляется вопрос, что считать источником истины: английский оригинал вендора, русская инженерная версия или казахский документ, который пойдёт в надзорный орган.

От ответа зависит вся цепочка. Если казахскую и русскую версии переводят независимо от английского оригинала, они почти гарантированно разойдутся в терминах, форматировании таблиц и трактовке технических требований. Если же выстроить перевод последовательно, английский становится базой, русский — рабочей инженерной версией, казахский готовится с опорой на утверждённую русскую и сверяется с оригиналом, расхождения удаётся удержать под контролем.

Закон «О языках в Республике Казахстан» прямо обязывает вести техническую и иную документацию в государственных органах и организациях на государственном и русском языках. В январе 2025 года в закон внесли поправки, вступившие в силу 16 марта 2025 года, но базовое требование двуязычия документации сохранилось. Для промышленного объекта с иностранным участием это означает минимум три языковые версии одного пакета: казахскую и русскую по требованию закона плюс английскую для международного подрядчика и вендора оборудования.

Единая терминология как ядро проекта

Терминологическая база — это то, с чего трёхъязычный проект должен начинаться, а не то, чем он заканчивается. Для промышленной документации характерна плотность терминов: в одном руководстве по эксплуатации газоперекачивающего агрегата их легко набирается несколько сотен, и каждый должен иметь ровно один эквивалент на каждом из трёх языков.

Проблема казахского языка в техническом контексте — незавершённая стандартизация терминологии. Многие узкоотраслевые понятия имеют по два-три варианта перевода, часть из которых калькирована с русского, часть образована по нормам казахского словообразования. «Задвижка» может встретиться и как «ысырма», и как «задвижка» в транслитерации, а в старых ГОСТах и вовсе остаться без казахского эквивалента. Без единого глоссария, согласованного с заказчиком и профильными специалистами, каждый переводчик выберет свой вариант, и трёхъязычный пакет потеряет внутреннюю связность.

Мы в бюро технических переводов iText строим для таких проектов трёхколоночный глоссарий RU-KK-EN, где термин фиксируется вместе с контекстом применения и ссылкой на источник: стандарт, паспорт оборудования или ранее утверждённую заказчиком версию. Глоссарий согласуется до начала основного перевода и дальше работает как обязательный справочник для всей команды. О том, как выстроить типологию документов перед началом перевода и не упустить критичные форматы, мы подробно писали в материале про типологию технической документации промышленных компаний.

Глоссарий имеет смысл собирать не только из словарей, но и из уже действующих документов заказчика: паспортов установленного оборудования, ранее переведённых регламентов, внутренних стандартов предприятия. Так термин привязывается к реальной практике объекта, а не к абстрактно «правильному» варианту, и эксплуатационный персонал узнаёт в переводе привычные наименования. Для длинных проектов глоссарий живёт вместе с документацией: по мере поступления нового оборудования в него добавляются термины, а версии фиксируются с датой утверждения.

Отдельная сложность — синхронизация терминологии с корпоративными системами заказчика. Если наименования узлов и материалов уже заведены в PLM или ERP, глоссарий обязан им соответствовать, иначе перевод разойдётся с рабочей номенклатурой предприятия. Как связать переводческий процесс с SAP и Teamcenter, чтобы термины совпадали на всех уровнях, разобрано в статье про интеграцию переводческих процессов с PLM и ERP.

Как выстроить рабочий процесс

Рабочая схема трёхъязычного проекта складывается из нескольких понятных этапов. Логика простая: сначала определяемся с источником и терминами, потом переводим последовательно, а не параллельно, и на каждом шаге фиксируем версию.

Первый шаг — определить язык-источник для каждого типа документа. Паспорта и руководства вендора приходят на английском, значит английский для них базовый. Проектная документация, разработанная казахстанским институтом, обычно исходно русская. Смешивать нельзя: для каждого пакета источник должен быть один.

Второй шаг — согласовать трёхъязычный глоссарий и стайлгайд. В стайлгайде фиксируются правила оформления единиц измерения, написания аббревиатур, передачи наименований оборудования и компаний. Для казахского отдельно оговаривается, какие термины переводятся, а какие остаются в оригинале или транслитерации.

Третий шаг — последовательный перевод с контролем на стыках. Английский переводится на русский, русская версия проходит редактуру и утверждение заказчиком, и только затем готовится казахская версия с обязательной сверкой по английскому оригиналу. Такой порядок не даёт казахскому тексту «оторваться» от исходного смысла, что случается при переводе через русский язык-посредник без обращения к первоисточнику.

Четвёртый шаг — контроль версий. У трёхъязычного документа три файла, которые обязаны меняться синхронно. Если инженер вносит правку в русскую версию после согласования, соответствующие изменения должны попасть и в английскую, и в казахскую. Без единого журнала изменений и понятной нумерации ревизий проект быстро превращается в набор несовпадающих файлов, где невозможно понять, какая версия актуальна.

Технологии: память переводов и CAT-инструменты

Ручное ведение трёхъязычного проекта в текстовом редакторе почти всегда заканчивается расхождениями. Объём документации крупного объекта измеряется тысячами страниц, повторяющиеся формулировки встречаются в паспортах, инструкциях и протоколах десятки раз, и держать их единообразие в голове невозможно. Поэтому серьёзный трёхъязычный проект ведётся в CAT-среде с общей памятью переводов и подключённой терминологической базой.

Память переводов решает сразу две задачи. Она подставляет ранее утверждённый перевод повторяющегося сегмента, экономя время и деньги заказчика, и она не даёт одному и тому же предложению получить два разных перевода в соседних документах. Для трёхъязычного проекта память ведётся по каждой паре, а терминологическая база остаётся общей и обязательной к применению: система подсвечивает переводчику утверждённый термин прямо в процессе работы и сигнализирует, если использован вариант вне глоссария.

Отдельно стоит учитывать формат исходников. Паспорта вендоров нередко приходят в виде сканов или чертежей с текстом внутри графики, а не редактируемых файлов. До начала перевода такие материалы нужно подготовить: распознать, извлечь текст, восстановить структуру таблиц. Пропуск этого этапа приводит к тому, что часть текста с чертежей просто не попадает в перевод, и казахская версия оказывается неполной по сравнению с английским оригиналом.

Терминологические ловушки казахского технического языка

Практика показывает несколько повторяющихся мест, где трёхъязычные проекты спотыкаются именно на казахской версии.

Первое — заимствования и кальки. Часть современной технической терминологии в казахском ещё не устоялась, и выбор между исконным термином и заимствованием приходится делать проектной команде. Здесь важна не «правильность» в отрыве от контекста, а согласованность: если заказчик и надзорный орган привыкли к определённому варианту, его и нужно закрепить в глоссарии.

Второе — порядок слов и согласование в технических конструкциях. Казахский язык агглютинативный, с иным строем предложения, чем русский и английский. Дословный перенос русской конструкции даёт формально понятный, но неестественный текст, который эксперт надзорного органа читает с трудом. Технический перевод на казахский требует переводчика, который думает на языке, а не подставляет окончания к русским корням.

Третье — единицы, обозначения и формулы. В трёхъязычном пакете легко получить ситуацию, когда десятичный разделитель, обозначение давления или запись диапазона в трёх версиях оформлены по-разному. Это мелочь ровно до момента, пока по документу не начинают работать: тогда разнобой в обозначениях порождает ошибки в настройке оборудования.

Кто участвует в проекте и как распределяются роли

Трёхъязычный проект нельзя вести силами одного переводчика-универсала. Здесь работает команда, и её состав напрямую влияет на качество результата.

Ядро — это отраслевые переводчики по каждой языковой паре: EN-RU и RU-KK как минимум, а для сложных проектов и прямая пара EN-KK. Над ними стоит редактор-терминолог, который держит единство глоссария и решает спорные случаи. Обязательна фигура технического эксперта или отраслевого специалиста, который проверяет смысловую корректность там, где лингвист может ошибиться в инженерной сути. Замыкает процесс менеджер проекта, отвечающий за версии, сроки и коммуникацию с заказчиком.

Для промышленного холдинга с постоянным потоком документации разовые заказы у разных исполнителей означают потерю терминологической памяти: каждый новый подрядчик начинает глоссарий с нуля. Выделенная команда с накопленной translation memory и единой терминологической базой снимает эту проблему. Как перейти от разовых заказов к постоянному переводческому процессу для холдинга, мы разбирали в руководстве по организации корпоративного перевода для промышленного холдинга.

Опыт масштабных проектов показывает, насколько это критично при больших объёмах. Когда бюро технических переводов iText стало переводческим партнёром Eurasian Resources Group, счёт шёл на миллионы страниц, и удержать терминологическую согласованность на таком массиве без единой команды и общей базы было бы невозможно. Детали этой работы описаны в кейсе о сотрудничестве iText и ERG.

Сертификация и надзор: где казахская версия обязательна

Отдельно стоит держать в голове, что часть документации требует казахской версии не для удобства, а для допуска. Маркировка и эксплуатационная документация оборудования, попадающего под технические регламенты ЕАЭС, должна содержать сведения на государственном языке страны обращения. Для электрооборудования, например, маркировка и сопроводительная документация оформляются на русском и (или) казахском языке с указанием наименования, типа, изготовителя, основных характеристик и предупреждений по безопасности.

Это значит, что казахскую версию нельзя откладывать «на потом»: без неё оборудование не пройдёт сертификацию и не получит допуск к эксплуатации. Планировать перевод на казахский нужно параллельно с подготовкой сертификационного пакета, а не после ввода объекта. Пошаговый разбор требований к переводу для сертификации приведён в материале про перевод документации для сертификации EAC.

Многоступенчатый контроль качества

Качество трёхъязычного пакета проверяется не в конце, а на нескольких стыках процесса. Первый рубеж — редактура внутри каждой языковой пары: редактор сверяет перевод с оригиналом на полноту и точность передачи смысла. Второй — терминологический контроль: специальная проверка на соответствие глоссарию, которую удобно вести автоматизированными средствами CAT-среды по всему массиву сразу.

Третий рубеж специфичен именно для трёхъязычных проектов — межъязыковая сверка. Русскую и казахскую версии сопоставляют между собой и с английским оригиналом, чтобы убедиться, что все три документа описывают одно и то же: совпадают числовые значения, обозначения узлов, структура разделов и таблиц. Именно на этом этапе вылавливаются ситуации, когда правку внесли в две версии из трёх.

Финальный контроль — проверка оформления и вёрстки. Технический документ должен не только совпадать по содержанию, но и выглядеть узнаваемо: таблицы, нумерация, подписи к рисункам и колонтитулы в трёх версиях оформляются одинаково, чтобы эксперт надзорного органа и инженер эксплуатации могли работать с любым языком без переучивания.

Типичные ошибки, которых стоит избегать

Несколько промахов встречаются в трёхъязычных проектах чаще других, и почти все они возникают из-за экономии на подготовительном этапе.

Перевод казахской версии через русскую без обращения к оригиналу. Русский текст сам является переводом, и ошибка или неточность в нём автоматически переносится в казахский. Казахская версия критичных документов должна сверяться с первоисточником.

Старт перевода без согласованного глоссария. Соблазн «начать быстрее, а термины уточнить по ходу» оборачивается тем, что первые сотни страниц приходится переделывать после того, как заказчик утвердит терминологию.

Игнорирование сертификационных требований на старте. Если казахскую версию оставляют на потом, а сертификация внезапно требует её к конкретной дате, проект уходит в аврал.

Отсутствие единого журнала ревизий. Правки, внесённые в один язык и не отражённые в двух других, — самая частая причина расхождения версий на поздних стадиях.

Чек-лист запуска трёхъязычного проекта

Перед стартом работ имеет смысл пройти по короткому списку, чтобы не переделывать половину пакета в середине проекта.

Определите язык-источник для каждого типа документа и зафиксируйте его письменно. Соберите и согласуйте с заказчиком трёхъязычный глоссарий RU-KK-EN до начала основного перевода. Проверьте, соответствует ли терминология номенклатуре в PLM или ERP предприятия. Договоритесь о едином стайлгайде для единиц, аббревиатур и наименований. Установите порядок ревизий и единый журнал изменений для всех трёх версий. Выделите техэксперта для проверки инженерной корректности. Заложите казахскую сертификационную версию в план заранее, а не в последний момент.

Итог

Трёхъязычный проект удерживается не за счёт скорости отдельного переводчика, а за счёт архитектуры: один источник истины, согласованный до старта глоссарий RU-KK-EN, последовательный перевод со сверкой казахского по оригиналу и жёсткий контроль версий. Именно на этих узлах чаще всего рвётся связность, и именно их стоит проектировать в первую очередь.

Если ваша компания ведёт объект, где документация должна одновременно существовать на русском, казахском и английском, бюро технических переводов iText возьмёт на себя построение терминологической базы, распределение ролей в команде и синхронизацию всех трёх версий на протяжении всего проекта. Мы специализируемся на промышленной технической документации и работаем с объёмами, где согласованность терминологии решает исход пусконаладки. Опишите ваш проект и требования надзорных органов через страницу услуг iText, и мы предложим схему работы под конкретный тип документации и сроки.

---