Введение

Интернационализация (или i18n) — это одна из тех функций, которые кажутся необязательными, пока они действительно не понадобятся. Как только вы захотите выйти за пределы одного языка или региона, внезапно вашему коду приходится поддерживать несколько локалей, текст с направлением справа налево и культурно-специфичные форматы.

Если вы искали решения, то, скорее всего, уже встречали i18next или react-intl. Оба инструмента мощные, но у них есть свои недостатки: высокий порог входа, множество шаблонных JSON-файлов или сложная интеграция с TypeScript.

В этой статье мы разберём:

  • Что на самом деле значит интернационализация (и почему её стоит закладывать заранее).

  • Основные проблемы, с которыми сталкиваются разработчики при работе с i18n.

  • Пошаговый пример внедрения i18n в React.

  • Современный альтернативный подход, который можно попробовать уже сегодня.


Что такое интернационализация (i18n)?

Интернационализация — это процесс подготовки приложения к адаптации для нескольких языков и культурных форматов без переписывания основной логики.

Почему это важно:

Больше пользователей: 76% потребителей предпочитают продукты на своём языке.
Рост SEO: локализованные страницы выше ранжируются на местных рынках.
?️ Поддерживаемость: разделение контента и логики облегчает масштабирование приложений.
Пользовательский опыт: культурно адаптированный контент вызывает больше доверия и ощущается более инклюзивным.


Типичные проблемы с i18n

  • Разрозненные переводы: разработчики работают с десятками JSON-файлов, разбросанных по проекту.

  • Type safety: отсутствующие ключи или несоответствия в переводах обнаруживаются только во время выполнения.

  • SSR и SEO: такие фреймворки, как Next.js, требуют особой обработки локализованных маршрутов.

  • Владение контентом: маркетологам и другим нетехническим специалистам сложно управлять переводами без участия разработчиков.

Поэтому многие команды ищут альтернативы привычным инструментам вроде i18next или react-intl.


Современный подход к i18n

Вместо хранения переводов в изолированных JSON-файлах можно объявлять их рядом с компонентами с поддержкой TypeScript. Это делает код самодокументируемым, типобезопасным и более удобным в сопровождении.


Пример с React и современной i18n-библиотекой

Шаг 1: Установка

npm install intlayer react-intlayer vite-intlayer

Шаг 2: Конфигурация

// intlayer.config.ts
import { Locales, type IntlayerConfig } from "intlayer";

const config: IntlayerConfig = {
  internationalization: {
    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
    defaultLocale: Locales.ENGLISH,
  },
};

export default config;

Шаг 3: Объявление контента рядом с компонентами

// src/components/App.content.ts
import { t, type Dictionary } from "intlayer";

const appContent = {
  key: "app",
  content: {
    title: t({ en: "Hello World", fr: "Bonjour le monde", es: "Hola Mundo" }),
    subtitle: t({ en: "Welcome!", fr: "Bienvenue!", es: "¡Bienvenido!" }),
  },
} satisfies Dictionary;

export default appContent;

Шаг 4: Использование в компоненте

// src/components/App.tsx
import { useIntlayer } from "react-intlayer";

export function App() {
  const { title, subtitle } = useIntlayer("app");

  return (
    <div>
      <h1>{title}</h1>
      <p>{subtitle}</p>
    </div>
  );
}

Почему это работает лучше

  • Автодополнение TypeScript → ошибки с отсутствующими ключами ловятся на этапе компиляции.

  • SSR-дружелюбно → нет мерцания при рендеринге с Next.js или Vite.

  • Локализованные маршруты → легко настроить SEO-оптимизированные URL вида /fr/about.

  • Удобно для не-разработчиков → можно подключить визуальный редактор или CMS, чтобы команды маркетинга управляли переводами напрямую.


Заключение

Если вы подбираете решение для i18n и устали от шаблонного кода в i18next или react-intl, попробуйте современные подходы с словарами на уровне компонентов и поддержкой TypeScript.

Интернационализация не должна быть болезненной. Чем раньше вы её заложите, тем проще будет масштабировать продукт глобально.

? GitHub решения Документация

P.S. Этот текст был переведен с английского на русский с помощью ChatGPT.

Комментарии (5)


  1. artptr86
    25.09.2025 02:18

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

    Обычно файлы локалей все лежат в одном месте. Или же разделены помодульно, если тому соответствует архитектура приложения. Здесь же вы предлагаете управлять, возможно, тысячами файлов с локалями, разбросанными по проекту.

    Type safety: отсутствующие ключи или несоответствия в переводах обнаруживаются только во время выполнения.

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

    https://www.i18next.com/overview/typescript

    https://github.com/i18next/react-i18next/tree/master/example/react-typescript/simple

    Владение контентом: маркетологам и другим нетехническим специалистам сложно управлять переводами без участия разработчиков.

    Нет. В случае обычных файлов локалей достаточно только умения пользоваться Git. Появление новых ключей перевода определяется простым сравнением ключей дефолтной локали с другими локалями. Это можно даже вынести, например, в пайплайн тестирования релиза. В вашем случае переводчикам нужно также понимать и архитектуру приложения, и знать TypeScript, чтобы понимать, что там нагородили разработчики. Кроме того, системы автоматизации переводов скорее всего поддерживают плоские JSON с ключами-значениями, а из *.content.ts все строки придётся доставать руками и править на месте — минус автоматизация.

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


    1. aymericzip Автор
      25.09.2025 02:18

      Для людей без технических навыков, например переводчиков или маркетологов, мы предлагаем CMS, чтобы им не приходилось работать с Git и прочими инструментами разработчиков.С помощью этой системы они могут легко понимать, над каким проектом работают, какие переводы отсутствуют или ещё должны быть сделаны.Также есть возможность автоматически сгенерировать перевод с помощью кнопки, использующей ИИ и учитывающей контекст, чтобы получать более качественные переводы для каждого словаря.Если используется ключ, который должен быть общим, можно создать общий словарь и вызывать этот ключ именно из него.


      1. artptr86
        25.09.2025 02:18

        То есть вы реализуете банальный вендор-лок. Причём я сомневаюсь, что ваша CMS мощнее и удобнее, чем профессиональные CAT-системы (Computer-Aided Translation), используемые переводчиками. Даже если они возьмутся за такую работу, то, скорее всего, запросят значительно больше денег.


      1. artptr86
        25.09.2025 02:18

        AI в CAT-системах тоже прикручен: https://support.crowdin.com/for-translators/#ai-assistant


  1. xxrat
    25.09.2025 02:18

    [ вопрос уже задали выше ]