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

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

Глоссарий хранит решение, словарь предлагает варианты

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

Возьмём facility. В зависимости от предложения это объект, помещение, предприятие, возможность или функция. Запись facility = объект почти бесполезна. Запись production facility = производственный объект; техническая документация; утверждено 12.09.2026 уже задаёт проверяемое правило. Название Facility Management Unit при этом может сохраняться в официальной форме и не подчиняться общему соответствию.

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

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

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

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

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

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

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

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

Одна запись должна объяснять границы решения

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

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

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

Запрещённые варианты используют осторожно. Они полезны для ложных друзей, устаревших названий и форм, которые заказчик уже отклонил. Список всех возможных синонимов в поле Forbidden превращает полезное ограничение в попытку управлять всем языком.

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

Регистр может менять значение. Services с прописной буквы в договоре обозначает определённые «Услуги», а services в обычном абзаце говорит об услугах вообще. Одна запись без области применения смешает два случая.

То же происходит с многозначными словами:

Полная форма и сокращение должны оставаться связанными. Для service-level agreement (SLA) запишите утверждённый перевод полного названия и правило дальнейшего употребления SLA. Две несвязанные строки заставят редактора заново выяснять, относятся ли они к одному понятию.

Статус показывает, кому можно доверять

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

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

Дата важна после содержательной правки. Исправленная запятая в заметке не требует новой версии всей базы. Замена термина или области применения требует, поскольку затрагивает уже выпущенные документы.

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

Опорный документ быстро обнаруживает лишние правила

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

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

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

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

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

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

Для большого документа с несколькими редакторами назначьте одного владельца базы. Иначе участники одновременно изменят одно решение в разные стороны, а проверка по главам закрепит оба варианта.

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

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

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

Первая рабочая версия собирается за один сеанс

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

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

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

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

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

Источники

• ISO 704:2022, принципы и методы терминологической работы, карточка стандарта ISO
• Структура документов WordprocessingML, Microsoft Learn