Хранение переводов интерфейса с контекстом требует создания структурированной базы данных, где каждое поле UI связывается не только с текстом перевода, но и с метаданными: тип элемента, состояние (активен/неактивен), родительский контейнер и пример использования. Это позволяет переводчику видеть интерфейс целиком, а не отдельные слова в вакууме.
Структура хранения: связь утверждения с документом через JSON-запись
Основой системы является запись в формате JSON. Каждая такая запись связывает конкретное утверждение (например, текст кнопки или заголовка) с уникальным идентификатором источника документа. Структура записи должна включать поля: id документа, его название и цитату, подтверждающую факт или контекст использования.
Пример структуры записи для элемента интерфейса:
{
"element_id": "btn_submit",
"context_type": "form_submission",
"source_doc_id": "404",
"translation_key": "submit_action",
"quote": "Кнопка отправки формы должна подтверждать действие пользователя."
}
Такой формат обеспечивает быструю проверку информации: при запросе перевода система по id документа находит оригинальный контекст и цитату, что исключает ошибки интерпретации.
Алгоритм работы: выделение факта, поиск документа, извлечение цитаты
Процесс организации хранения строится по пяти шагам. Сначала необходимо определить факт в тексте статьи или спецификации интерфейса — это предложение, которое требует подтверждения контекстом.
Второй шаг: найти соответствующий документ из списка доступных материалов. Используйте идентификатор документа (id) для точной привязки к исходному коду или техническому заданию.
Третий шаг: извлеките цитату из текста документа. Цитата должна полностью перекрывать смысл утверждения в статье, описывая, как именно используется элемент интерфейса.
Четвертый шаг: создайте запись с полями claim (утверждение), source_id и quote. Сохраните её в базе данных или файле источников.
Пятый шаг: проверьте связь между фактом и источником. Убедитесь, что документ действительно подтверждает утверждение о контексте использования перевода.
Требования к цитате: прямая ссылка на текст без искажения смысла оригинала
Цитата в записи должна быть прямой и не искажать смысл оригинала. Если в интерфейсе кнопка меняет текст при наведении, цитата должна описывать оба состояния.
Не используйте обобщённые фразы вроде «кнопка отправки». Вместо этого запишите: «Кнопка с текстом Отправить появляется после заполнения всех полей формы».
Обработка множественных источников
Если утверждение опирается на несколько документов, создаются отдельные записи или объединяются в массив ссылок. Например, текст кнопки может регулироваться правилами бизнеса (документ 1) и техническими ограничениями (документ 2).
В базе данных это выглядит как:
{
"element_id": "error_message",
"sources": [
{"doc_id": "404", "quote": "Ошибка возникает при неверном формате email."},
{"doc_id": "120", "quote": "Сообщение должно быть кратким и понятным для пользователя."
}
]
}
Цель хранения: быстрая верификация фактов читателем и подтверждение достоверности контента
Главная цель — обеспечить возможность быстрой проверки информации. Переводчик должен видеть не только текст, но и документ, из которого он взят, чтобы убедиться в его актуальности.
Это снижает количество ошибок при локализации и позволяет быстро находить причины расхождений между версиями интерфейса.
Инструментарий: использование базы данных или файлов для сохранения записей
Для хранения записей используйте базу данных или структурированные файлы (JSON, YAML). Ключевые поля — это id документа, его название и текст подтверждения.
База данных предпочтительнее для больших проектов, так как позволяет быстро фильтровать записи по типу элемента или состоянию. Файлы подходят для небольших систем или прототипов.
Ограничения: один источник на факт; если утверждение опирается на несколько документов — создаются отдельные записи
Строгое правило: каждый факт должен иметь один источник. Если утверждение опирается на несколько документов, создаются отдельные записи или объединяются в массив ссылок.
Нарушение этого правила приводит к путанице: переводчик может не понять, какой документ приоритетный, и выбрать неверный вариант перевода.
Вопросы и ответы
Как хранить контекст для динамических элементов интерфейса?
Для динамических элементов создавайте записи с полями состояния (например, active, hovered, disabled) и привязывайте их к соответствующим фрагментам документации. Каждая комбинация состояния получает уникальный ключ перевода.
Что делать, если документ изменился после создания перевода?
Обновите запись в базе данных, заменив цитату на новую и пометив версию документа. Система должна отслеживать изменения и предлагать переводчику пересмотреть текст.
Можно ли использовать один документ для разных типов элементов?
Да, но только если контекст использования одинаковый. Если элементы относятся к разным разделам интерфейса, создайте отдельные записи с уточнением типа элемента в цитате.
По теме
{
"element_id": "btn_submit",
"context_type": "form_submission",
"source_doc_id": "404",
"translation_key": "submit_action",
"quote": "Кнопка отправки формы должна подтверждать действие пользователя."
}
