Как собрать глоссарий для перевода с помощью ИИ: выгрузите строки интерфейса, попросите модель выделить термины и предложить пары «источник → перевод», затем вручную проверьте каждую пару по контексту и передайте список языковому владельцу на утверждение. Ниже — порядок действий, готовый промпт и учебный пример.
Назначение глоссария и его границы
Глоссарий перевода — это управляемый словарь, который сопоставляет слова и фразы исходного языка с согласованными эквивалентами целевого языка. В документации l10n.dev такое определение дано прямо: глоссарий отражает осознанные редакционные решения для конкретной области, бренда или аудитории и удерживает модель на выбранной терминологии. Соответствие этому словарю нужно проверять в каждом переводе: определение задачи само по себе не гарантирует поведения модели.
Границы документа стоит зафиксировать до начала работы. В документации Microsoft по управлению терминологией перечислены поля, которые имеет смысл вести для каждого термина: исключения (когда термин использовать нельзя и какие написания нежелательны), применимость к продукту (когда разные линейки продуктов переводят один английский термин по-разному), аббревиатуры, слоганы и маркетинговые фразы. Там же отмечено, что один исходный термин в написании может относиться к нескольким понятиям, и для таких случаев нужны отдельные записи.
Практический вывод: закрепите в глоссарии терминологию продукта. Стиль, тон и правила письма в Lokalise Vantage выносятся в отдельные style guides, а память переводов хранит уже утверждённые фрагменты. Смешивать эти три слоя в одном файле неудобно: при обновлении термина придётся пересматривать лишние записи.
Ещё одна граница — статус записи. Кандидат и утверждённый термин различаются. Модель выдаёт кандидатов, а решение принимает человек, отвечающий за язык продукта. В документации Microsoft описано, что после автоматического извлечения терминов список обычно требует ручной чистки и отбора специалистом по терминологии вместе с командой разработки. Этот шаг и есть переход от кандидата к утверждению.
Сбор и проверка исходных данных
Исходные данные — это строки интерфейса, которые предстоит переводить. Соберите их в один плоский список, по одной строке на единицу текста, и сохраните рядом контекст: где строка показывается, что делает пользователь, есть ли ограничение по длине. Без контекста модель угадывает смысл, и на выходе получаются пары, которые формально верны и практически бесполезны.
Проверьте список до отправки в модель. Уберите дубликаты, схлопните строки с одинаковым смыслом, отметьте места, где встречается название продукта или бренда. В документации Microsoft по созданию пользовательского глоссария для перевода документов указано, что файл глоссария содержит список терминов исходного языка вместе с соответствующими переводами, а для каждого языка создаётся отдельный файл. Там же отмечено, что термины и фразы в файле учитывают регистр.
Формат файла выбирайте по инструменту, в который пойдёт результат. Документация Microsoft описывает сохранение в TSV или TAB, а при разделении запятыми — в CSV; для обмена между системами локализации там же упоминаются файлы XLF. Документация Cloud Translation API для наборов эквивалентных терминов принимает файлы в формате CSV. Документация Lokalise Vantage описывает загрузку глоссария в CSV, в том числе прямо при создании проекта.
Отдельно решите, что делать с именами. В документации Microsoft по управлению терминологией разбирается вопрос, переводить ли названия продуктов и ключевых функций, транслитерировать их или оставлять в исходном виде, и что делать с товарными знаками. Там же вводится пометка Do Not Translate для случаев, когда термин остаётся на английском по причинам бренда или отраслевой традиции. Эти решения принимаются до перевода, потому что они влияют на каждую строку.
Учебный пример: интерфейс BookNest
Возьмём условную пару en→ru и интерфейс библиотеки BookNest. Пять строк для перевода: Reserve a book; Your reservation; Reading list; Your plan; Start a trial. В условии примера Your plan и Start a trial показаны на экране управления подпиской. Ниже — заполненный глоссарий, который получился после разбора. Все записи имеют статус «кандидат»: реального языкового утверждения по этому примеру нет.
| Источник | Перевод | Часть речи | Контекст | Нежелательные варианты | Регистр | Статус |
|---|---|---|---|---|---|---|
| reserve | забронировать | глагол | получить книгу позднее | зарезервировать | строчные | кандидат |
| reservation | бронь | существительное | подтверждение брони | резервация | строчные | кандидат |
| reading list | список для чтения | словосочетание | подборка книг пользователя | лист чтения | строчные | кандидат |
| plan | тариф | существительное | подписка | план | строчные | кандидат |
| trial | пробный период | существительное | подписка | испытание | строчные | кандидат |
| BookNest | BookNest | имя | название продукта | — | как в источнике | кандидат |
Таблица показывает, какие решения нужно принять до перевода. Для reserve выбран глагол «забронировать», а вариант «зарезервировать» помечен как нежелательный. Для plan в контексте подписки выбран «тариф», а слово «план» в этом контексте запрещено. Для trial выбран «пробный период», вариант «испытание» отброшен. BookNest остаётся без перевода и сохраняет регистр.
Обратите внимание на строку reservation: существительное переведено как «бронь», хотя глагол reserve переведён как «забронировать». Это разные части речи и разные формы, и в глоссарии они живут отдельными записями. Документация Localize прямо предупреждает, что записи глоссария учитывают регистр, поэтому для покрытия всех форм термина иногда нужно добавить несколько вариантов написания.
Копируемый промпт с указанными входами
Промпт ниже решает одну задачу: превратить список строк в черновой глоссарий с фиксированным набором полей. Скопируйте его целиком и подставьте свои данные.
Ты помогаешь подготовить глоссарий для перевода интерфейса.
Входные данные:
- Языковая пара: [например, en → ru]
- Продукт: [название продукта]
- Строки интерфейса (по одной на строку):
[вставьте строки]
Задача:
1. Выдели из строк термины и устойчивые словосочетания, которые стоит зафиксировать.
2. Для каждого термина выдай поля: source, target, context, part of speech, forbidden variants, case sensitivity, status.
3. Выбирай значение термина по контексту конкретной строки.
4. Статус каждой записи всегда Candidate.
5. Если у термина несколько возможных смыслов, укажи неоднозначность отдельной пометкой.
6. Названия продукта и бренда помечай как непереводимые и сохраняй регистр.
Формат ответа: таблица markdown с колонками source, target, context, part of speech, forbidden variants, case sensitivity, status.
Что менять под себя: языковую пару, название продукта и сам список строк. Если в интерфейсе есть строки с ограничением по длине, добавьте их в контекст — модель учтёт это при выборе перевода. Если продукт использует несколько линеек с разной терминологией, разделите строки по линейкам и прогоните промпт отдельно для каждой.
Вариации той же задачи, которые стоит держать под рукой. Первая: попросить модель проверить новые строки по уже готовому глоссарию и показать совпадения без автоматической замены. Вторая: попросить найти в списке строки, где один и тот же термин употреблён в разных смыслах. Третья: попросить предложить нежелательные варианты перевода для каждого термина. Четвёртая: попросить сгруппировать термины по частям речи. Пятая: попросить отметить термины, которые уже встречались в предыдущих партиях строк.
Отрицательный пример и неизвестные данные
Отрицательный пример из учебного набора: строку Your plan for reading нельзя автоматически переводить как «ваш тариф для чтения». В этом предложении plan относится к плану чтения. Подписка здесь не упоминается. Глоссарий зафиксировал plan как «тариф» для контекста подписки, и автоматическая подстановка в другом контексте даёт ошибку.
Отсюда практическое правило: контекстная пометка в записи глоссария нужна именно для таких случаев. В документации l10n.dev отмечено, что контекстная заметка помогает модели применить соответствие только тогда, когда в тексте присутствует нужный смысл, и что это особенно полезно для многозначных слов. Для plan в нашем примере пометка «подписка» отделяет тариф от плана чтения.
Неизвестные данные тоже стоит фиксировать явно. Если для термина нет устоявшегося перевода, оставьте поле target пустым и пометьте запись как требующую решения. В документации Microsoft по управлению терминологией сказано, что для новых терминов, у которых ещё нет переводов в целевых языках, полезно придумать их как можно раньше: так переводчики успевают освоиться с новой функцией. Пустая ячейка честнее выдуманного перевода.
Ещё одна категория неизвестного — регистр и формы слова. Документация Localize предупреждает, что записи глоссария учитывают регистр, и для покрытия всех форм термина может понадобиться несколько записей. Документация l10n.dev описывает другой подход: общие термины пишутся строчными, а модель сама подстраивает заглавные буквы под контекст предложения; точный регистр задаётся для брендов, аббревиатур и регистрозависимых терминов. Выбор подхода зависит от инструмента, в который пойдёт глоссарий.
Проверка результата вручную по исходнику
Для ручной проверки откройте исходные строки рядом с ответом модели. Откройте список строк и таблицу глоссария рядом и пройдитесь по каждой паре. Проверьте четыре вещи: термин действительно встречается в строках, перевод подходит к контексту этой строки, нежелательные варианты действительно нежелательны, регистр и форма слова совпадают с тем, как термин употреблён.
Отдельно проверьте случаи, где один исходный термин имеет несколько смыслов. Документация Microsoft по управлению терминологией советует заводить для таких случаев отдельные записи. Проверьте, что для каждого смысла многозначного термина есть отдельная запись с собственным контекстом.
Проверьте и обратную ситуацию: разные исходные термины, которые переводятся одинаково. Документация Microsoft рекомендует по возможности этого избегать. Если два разных термина получили один и тот же перевод, решите, действительно ли они означают одно и то же, или это следствие ошибки.
Наконец, проверьте полноту. В документации Microsoft по управлению терминологией перечислены типы записей, которые легко пропустить: аббревиатуры, слоганы, вымышленные имена в примерах, названия продуктов и ключевых функций. Пройдитесь по этому списку и убедитесь, что для каждого типа есть решение. Вымышленные имена в примерах там же рекомендуется подбирать так, чтобы они были уместны для целевой аудитории.
Сохранение и согласование результата
Согласование начинается с разделения ролей. Кандидаты от модели попадают к специалисту по терминологии, который вместе с командой разработки отбирает и утверждает термины для словаря — так описан процесс в документации Microsoft по управлению терминологией. Утверждённые записи получают статус, отличный от кандидата, и дальше живут как источник истины.
Сохраните глоссарий в формате, который принимает ваш инструмент. Документация Microsoft по пользовательскому глоссарию описывает TSV, TAB и CSV, а также XLF для обмена между системами локализации. Документация Cloud Translation API для наборов эквивалентных терминов принимает CSV. Документация Lokalise Vantage описывает загрузку CSV при создании проекта.
Продумайте, как глоссарий попадёт в рабочий процесс перевода. В документации l10n.dev описано, что активный глоссарий для языковой пары применяется автоматически, а при активации другого глоссария для той же пары предыдущий деактивируется. В документации Lokalise Vantage указано, что глоссарии не переносятся между рабочими пространствами автоматически: существующий глоссарий экспортируется в CSV и загружается в целевое пространство.
Обновления терминов — отдельная процедура. Документация Microsoft по управлению терминологией советует уведомлять всех участников об изменениях терминов и закладывать время на перевод новых и изменённых терминов, а также на обновление материалов, где использовались старые варианты. Инструмент словаря даёт всем участникам доступ к обновлённым терминам сразу после их появления.
Частые вопросы
Что такое глоссарий перевода и зачем он нужен?
Это управляемый словарь, который сопоставляет термины исходного языка с согласованными переводами. В документации l10n.dev он описан как набор осознанных редакционных решений для конкретной области, бренда или аудитории. Его задача — удержать модель и переводчиков на выбранной терминологии. Без него модель выбирает из нескольких равнозначных синонимов.
Можно ли вести глоссарий в обычной таблице?
Да, базовый словарь помещается в таблицу с терминами и их эквивалентами — так описано в документации Microsoft по управлению терминологией. Там же отмечено, что выделенное решение для управления терминологией, интегрированное с системами автоматизированного перевода, даёт более предсказуемый результат. Для небольшого проекта таблицы достаточно на старте.
Как ИИ помогает собрать глоссарий?
Модель выделяет повторяющиеся термины, названия продуктов и отраслевую лексику из ваших строк и заполняет черновой список. В документации l10n.dev описано автоматическое извлечение терминов из файлов локализации с учётом уже существующих записей. В документации Microsoft по управлению терминологией отмечено, что после автоматического извлечения список обычно требует ручной чистки специалистом.
Что делать с многозначными словами?
Заводить отдельные записи для каждого смысла. Документация Microsoft по управлению терминологией прямо указывает, что один исходный термин в написании может относиться к нескольким понятиям, и для таких случаев нужны отдельные записи. В документации l10n.dev для этого предусмотрена контекстная заметка, которая помогает применить соответствие только при нужном смысле.
Как проверить готовый глоссарий?
Пройтись по исходным строкам и сверить каждую пару вручную: термин встречается в тексте, перевод подходит к контексту, нежелательные варианты обоснованы, регистр совпадает. Отдельно проверьте многозначные термины и случаи, где разные термины получили одинаковый перевод. Утверждение терминов остаётся за специалистом по терминологии и командой разработки.