В языках с различием между формальным и неформальным обращением требуется учитывать не только перевод слов, но и социолингвистический контекст. В русскоязычных интерфейсах это выражается через выбор между «ты» и «вы», в немецком — между du и Sie, во французском — tu и vous. В интернационализированных приложениях эта проблема решается на уровне системы локализации, где одна и та же бизнес-логика должна адаптироваться под разные стили общения без изменения кода компонентов.
i18next предоставляет механизмы, позволяющие моделировать формальность через набор ключей перевода, контексты, параметры и правила выбора ресурсов. При этом сама библиотека не навязывает конкретную модель «формальности», а предоставляет инструменты для её выражения.
Базовый подход заключается в разделении переводов на разные наборы ключей в зависимости от стиля обращения.
{
"greeting": {
"formal": "Здравствуйте, {{name}}",
"informal": "Привет, {{name}}"
}
}Использование в коде:
i18next.t('greeting.formal', { name: 'Иван' });
i18next.t('greeting.informal', { name: 'Иван' });Такой подход прост, но быстро приводит к разрастанию дерева ключей. При увеличении количества параметров (пол, число, роль пользователя) структура становится трудно поддерживаемой.
Механизм context в i18next предназначен для вариативности перевода без дублирования ключей. Он позволяет добавлять суффиксы к базовому ключу в зависимости от переданного контекста.
{
"greeting": "Здравствуйте",
"greeting_male": "Здравствуйте, господин",
"greeting_female": "Здравствуйте, госпожа"
}Использование:
i18next.t('greeting', { context: 'formal' });
i18next.t('greeting', { context: 'informal' });В реальных проектах контекст часто комбинируется с формальностью:
{
"greeting_formal": "Здравствуйте, {{name}}",
"greeting_informal": "Привет, {{name}}"
}Контекст становится особенно полезным, когда формальность зависит не только от пользователя, но и от роли адресата:
{
"message_user_formal": "Уважаемый пользователь",
"message_admin_formal": "Уважаемый администратор",
"message_user_informal": "Привет",
"message_admin_informal": "Эй"
}Формальность часто связана с изменением структуры предложения, а не только отдельных слов. Интерполяция позволяет отделить текстовую форму от динамических данных:
{
"welcome_formal": "Добро пожаловать, {{title}} {{lastName}}",
"welcome_informal": "Привет, {{firstName}}"
}i18next.t('welcome_formal', {
title: 'г-н',
lastName: 'Иванов'
});Использование разных параметров для формального и неформального стиля снижает риск грамматических ошибок, поскольку каждая форма проектируется независимо.
Даже в пределах одного языка может существовать несколько уровней вежливости. В русской локализации это выражается не только выбором местоимений, но и общей стилистикой:
{
"button": {
"save_formal": "Сохранить изменения",
"save_informal": "Сохрани"
},
"error": {
"network_formal": "Произошла ошибка соединения",
"network_informal": "Сеть не работает"
}
}В таких случаях ключи группируются по функциональности, а стиль становится дополнительным измерением.
В реальных приложениях уровень формальности часто определяется настройками пользователя или его ролью.
const formality = user.settings.formality; // 'formal' | 'informal'
i18next.t(`greeting_${formality}`, {
name: user.name
});Более гибкий подход использует функцию-обёртку:
function tWithFormality(key, options = {}) {
const formality = options.formality || 'formal';
return i18next.t(`${key}_${formality}`, options);
}Такой слой абстракции позволяет централизовать логику выбора стиля и избежать дублирования условий в компонентах интерфейса.
Формальность часто пересекается с правилами множественного числа, особенно в языках со сложной морфологией. i18next поддерживает pluralization, что позволяет комбинировать обе оси вариативности.
{
"message_formal_one": "У вас {{count}} новое сообщение",
"message_formal_other": "У вас {{count}} новых сообщений",
"message_informal_one": "Тебе {{count}} сообщение",
"message_informal_other": "Тебе {{count}} сообщения"
}i18next.t('message', {
context: 'formal',
count: 5
});На практике ключи часто структурируются иначе:
{
"message": {
"formal_one": "У вас {{count}} новое сообщение",
"formal_other": "У вас {{count}} новых сообщений",
"informal_one": "Тебе {{count}} сообщение",
"informal_other": "Тебе {{count}} сообщения"
}
}При масштабных проектах стиль обращения может выноситься в отдельные namespace:
{
"formal": {
"greeting": "Здравствуйте, {{name}}"
},
"informal": {
"greeting": "Привет, {{name}}"
}
}Использование:
i18next.t('formal:greeting', { name: 'Иван' });
i18next.t('informal:greeting', { name: 'Иван' });Такой подход упрощает поддержку крупных интерфейсов, где один и тот же текст повторяется в разных стилях в десятках экранов.
В некоторых архитектурах выбор формальности выносится за пределы ключей и реализуется как слой бизнес-логики:
function getGreetingKey(user) {
if (user.isGuest) return 'greeting_informal';
if (user.role === 'admin') return 'greeting_formal';
return user.settings.formality === 'informal'
? 'greeting_informal'
: 'greeting_formal';
}
i18next.t(getGreetingKey(user), { name: user.name });Такой подход снижает нагрузку на систему переводов, но увеличивает ответственность кода приложения.
Смешивание формального и неформального стиля в одном ключе приводит к нескольким типичным проблемам:
Поэтому чаще используется либо разделение по ключам, либо по namespace, либо комбинация этих подходов.
Формальность не является универсальной характеристикой. В некоторых языках она выражается грамматически, в других — лексически, а иногда отсутствует вовсе.
В английской локализации:
{
"greeting": "Hello, {{name}}"
}Разделение формальности может быть минимальным:
{
"greeting_formal": "Good day, {{name}}",
"greeting_informal": "Hey, {{name}}"
}В японском или корейском контекст формальности может влиять на окончания и выбор слов, что требует более сложных наборов переводов, но архитектурно подход остаётся тем же.
Формальность часто пересекается с состояниями системы:
{
"loading_formal": "Загрузка данных, пожалуйста, подождите",
"loading_informal": "Подожди, загружаю",
"error_formal": "Произошла ошибка",
"error_informal": "Что-то сломалось"
}Такая модель позволяет формировать согласованный тон интерфейса в зависимости от сценария использования: корпоративного, массового или игрового.
При больших приложениях формальность становится частью общей дизайн-системы текста. В этом случае ключи проектируются по принципу:
greeting, error,
button.save)formal, informal)admin, guest,
premium)Комбинация этих параметров может реализовываться через:
i18next позволяет свободно комбинировать эти стратегии без привязки к одному способу организации данных, что особенно важно в проектах, где стиль общения является частью пользовательского опыта, а не второстепенной деталью.