Разделение переводов по функциональности

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

Функциональное разделение переводов основано на идее, что каждая область приложения должна иметь собственный изолированный набор ключей. Вместо единого глобального JSON-файла используется набор ресурсов, сгруппированных по смыслу:

  • авторизация и регистрация
  • профиль пользователя
  • корзина и оформление заказа
  • навигация и меню
  • ошибки и уведомления
  • административная панель

Такое разделение снижает вероятность коллизий ключей и позволяет масштабировать проект без роста сложности словарей.

Namespaces как основа архитектуры i18next

В i18next ключевым механизмом разделения переводов выступают пространства имён (namespaces). Каждый namespace представляет собой логически обособленный блок переводов.

Пример структуры:

{
  "auth": {
    "login": "Войти",
    "logout": "Выйти",
    "error": {
      "invalid_password": "Неверный пароль"
    }
  },
  "profile": {
    "title": "Профиль пользователя",
    "edit": "Редактировать"
  }
}

Однако при использовании namespaces структура становится более модульной:

locales/
  en/
    auth.json
    profile.json
    cart.json
  ru/
    auth.json
    profile.json
    cart.json

Каждый файл представляет отдельный функциональный блок.

Конфигурация загрузки namespaces

i18next позволяет явно указывать используемые пространства имён:

i18next.init({
  lng: 'ru',
  fallbackLng: 'en',
  ns: ['auth', 'profile', 'cart'],
  defaultNS: 'auth',
  backend: {
    loadPath: '/locales/{{lng}}/{{ns}}.json'
  }
});

Такой подход обеспечивает:

  • загрузку только необходимых переводов
  • уменьшение объёма начального бандла
  • ускорение времени первого рендера

Динамическая загрузка переводов по функциональным зонам

Разделение переводов становится особенно эффективным при lazy-loading. При переходе в новую часть приложения соответствующий namespace подгружается отдельно.

i18next.loadNamespaces('cart', () => {
  // теперь доступны переводы корзины
});

В SPA архитектуре это позволяет связывать перевод напрямую с маршрутом:

  • /auth → namespace auth
  • /profile → namespace profile
  • /checkout → namespace cart

Каждый маршрут получает только необходимые ресурсы.

Изоляция ключей и предотвращение конфликтов

При отсутствии разделения ключей возникает проблема пересечений:

"title": "..."

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

Namespace устраняет неоднозначность:

auth:title
profile:title
product:title

или через разделённые файлы:

auth.title
profile.title
product.title

Внутренняя реализация i18next поддерживает оба подхода через точечную нотацию и вложенные структуры.

Гранулярность разделения: уровень функциональных модулей

Оптимальная степень дробления переводов зависит от архитектуры приложения:

Крупные модули

  • auth
  • dashboard
  • settings

Подход подходит для небольших и средних приложений.

Средняя гранулярность

  • auth/login
  • auth/register
  • settings/profile
  • settings/security

Позволяет разделять даже части одного функционального блока.

Микроразделение

  • form/validation
  • form/labels
  • form/placeholders

Используется в системах с большим количеством переиспользуемых компонентов.

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

Компонентный подход предполагает, что каждый UI-компонент имеет собственный namespace:

components/
  button/
    en.json
    ru.json
  modal/
    en.json
    ru.json

Использование:

const { t } = useTranslation('button');

t('submit');

Такой подход уменьшает зависимость компонентов друг от друга и делает их переносимыми между проектами.

Использование fallback namespaces

При разделении переводов неизбежно возникает ситуация отсутствия ключа в конкретном модуле. В i18next предусмотрена цепочка fallback:

i18next.init({
  ns: ['checkout', 'common'],
  defaultNS: 'checkout',
  fallbackNS: 'common'
});

Стратегия поиска ключа:

  1. текущий namespace
  2. fallback namespace
  3. глобальные ресурсы

Это позволяет хранить общие строки отдельно:

  • кнопки
  • системные сообщения
  • базовые ошибки

Общие переводы как отдельный функциональный слой

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

Содержимое:

common.json
{
  "ok": "ОК",
  "cancel": "Отмена",
  "error": "Ошибка",
  "loading": "Загрузка"
}

Этот слой используется всеми частями приложения и не привязан к конкретной функциональности.

Разделение переводов в связке с код-сплиттингом

Функциональные namespaces тесно связаны с динамическими импортами:

const loadCheckout = async () => {
  await i18next.loadNamespaces('checkout');
  const module = await import('./checkout');
  return module;
};

Это синхронизирует:

  • загрузку кода
  • загрузку переводов

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

Организация больших проектов

В масштабных системах структура часто принимает вид:

locales/
  ru/
    common.json
    auth.json
    checkout.json
    dashboard.json
    admin/
      users.json
      roles.json
  en/
    ...

Дополнительно вводится уровень доменов:

  • public
  • private
  • admin

Это позволяет отделять пользовательскую и административную части интерфейса.

Версионирование и независимость функциональных блоков

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

Изменения в checkout.json не затрагивают:

  • auth.json
  • profile.json
  • dashboard.json

Такое поведение критично для командной разработки, где разные группы работают над разными доменами.

Согласованность ключей внутри функциональных модулей

Внутри одного namespace важно поддерживать единый стиль ключей:

  • глагольные действия: save, delete, update
  • сущности: title, description, label
  • состояния: loading, error, success

i18next обрабатывает вложенные структуры, что позволяет сохранять семантическую читаемость:

{
  "button": {
    "save": "Сохранить",
    "cancel": "Отмена"
  }
}

Масштабирование системы переводов

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

Это приводит к следующим свойствам архитектуры:

  • локализация изменений
  • предсказуемость структуры
  • минимизация конфликтов в merge-запросах
  • независимое тестирование переводов

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

Оглавление