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

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

Пакет начинается не с кнопки загрузки

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

Хороший пример пакета: основной договор, приложение с определениями, техническая спецификация и сопроводительное письмо. Название стороны должно совпадать во всех четырёх файлах, ссылка «Приложение 2» должна вести к тому же документу, а определённый термин должен сохранять регистр. Ошибка в одном файле становится ошибкой комплекта.

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

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

Рабочую папку сначала очищают от истории

В каталоге проекта почти всегда есть старые редакции, PDF для просмотра, копии с комментариями и документы с именами final или final2. Если загрузить всё подряд, на выходе появятся дубликаты, а редактор потратит время на проверку версии, которая вообще не должна была участвовать в работе.

Создайте папку source-approved и копируйте туда только утверждённые исходники. Архив не перемещайте и не переименовывайте без записи соответствия. Сомнение в версии нельзя решать по времени изменения файла: спросите владельца документа и зафиксируйте ответ в реестре.

Каждый DOCX стоит один раз открыть вручную. Word не должен предлагать восстановление. Комментарии и отслеживаемые правки должны соответствовать принятому правилу проекта. Файл с паролем или ограничением редактирования может не пройти обработку. Для скрытых данных используйте инспектор документов Word на копии: он помогает найти свойства, комментарии и невидимый текст, но удаление найденного содержимого может быть необратимым.

Реестр показывает состав лучше названий файлов

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

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

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

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

Опорный файл задаёт язык всего комплекта

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

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

Термин charge показывает, почему частотного словаря недостаточно. В одном файле он может означать плату, в другом заряд, в третьем обвинение. Общее правило без контекста ухудшит весь пакет. В глоссарии фиксируют не слово вообще, а решение для конкретной области.

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

Схема имён должна пережить скачивание

Имена результата должны сохранять связь с исходником. Один понятный вариант выглядит так:

01-master-agreement_ru_source.docx
01-master-agreement_en_v01.docx
01-master-agreement_en_v02_reviewed.docx

ID связывает три версии, код языка показывает направление, номер редакции объясняет порядок. Слово reviewed имеет смысл только после фактической проверки. Не ставьте его автоматически при скачивании.

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

Проверьте схему на самом длинном имени до запуска. Ограничения файловой системы, общая папка или архиватор могут обрезать путь либо заменить часть символов. Если имя приходится сокращать, стабильный ID сохраняют обязательно, а полное исходное название оставляют в реестре. Так короткое имя не превращается в новую загадку для выпускающего.

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

Первый просмотр отвечает за отдельные файлы

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

Размер файла остаётся только сигналом. Маленький DOCX мог потерять встроенный объект, но одинаковый размер не подтверждает полноту текста. Для каждого ID отметьте получение, открытие, смысловую проверку и просмотр макета. Подробный порядок сверки одного результата есть в чек-листе качества перевода.

Проверяйте текст раньше оформления. Иначе редактор потратит время на перенос таблицы, а после исправления термина все строки снова сдвинутся. Если верстка распалась, сначала найдите первую структурную причину, а не чините последние страницы по одной.

Второй просмотр идёт поперёк пакета

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

Названия сторон и продуктов

Соберите утверждённые формы в одну строку поиска и просмотрите все документы. Регистр, кавычки и транслитерация должны совпадать там, где название обозначает одну сущность. В договоре два варианта имени могут выглядеть как две разные стороны.

Определения и обязательства

Если основной договор вводит «Поставщика» или «Услуги» с заглавной буквы, приложения должны использовать те же формы в том же значении. Рядом проверяют shall, may, «обязан» и «вправе»: приложение не должно незаметно расширить или сузить правило основного текста.

Номера и ссылки

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

Форматы данных

Даты, десятичные разделители, валюты и единицы оформляют единообразно. Локализация записи допустима только по принятому правилу и не должна менять числовое значение. Эта проверка особенно важна, когда документы редактировали разные люди.

Папка выпуска собирается заново

Рабочий каталог содержит черновики и промежуточные редакции, поэтому его нельзя отправлять получателю целиком. Создайте отдельную папку release-v01 и положите туда только проверенные результаты. Сравните её с реестром строка за строкой.

Для каждого ID должен быть ровно один актуальный DOCX. Имена должны следовать одной схеме, все файлы должны повторно открываться, а права доступа должны соответствовать содержанию. Глоссарий и журнал решений хранят рядом или в системе проекта, но получателю передают их только тогда, когда это предусмотрено задачей.

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

Для очень крупного файла внутри пакета понадобится отдельная карта глав и приложений. Реестр контролирует состав комплекта, а карта показывает готовность частей одного DOCX. Смешивать эти два уровня в одной таблице неудобно.

Новый файл меняет версию пакета

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

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

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

Выпускайте release-v02, даже если добавилась одна позиция. Получателю должно быть ясно, получил он дополнение или полную замену. Две неизменяемые папки и реестр объяснят историю лучше переписки с вложениями.

Источники

• Структура DOCX в WordprocessingML, Microsoft Learn
• Проверка документа на скрытые данные, Microsoft Support