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

Начните с общей карты терминов

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

Разделите продуктовый и маркетинговый контекст

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

Планируйте проверку связей

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

LOCALIZATION HANDOFFСхема локализационного контекстастрока → экран → проверка
KEYcontext.key.example
SOURCE

Source string

TARGET · RU

Целевая строка

CONTEXTScreen, role and user action

CHECKVariables and links are checked