Автор:

Создание:2026-09-09Последнее обновление:2026-09-10

Ссылайтесь на этот документ на ваш любимый ассистент AIChatGPT Claude DeepSeek Google AI mode Gemini Perplexity Mistral Grok

Спросите свой вопрос и получите сводку документа, используя эту страницу и выбранного вами поставщика AI

Содержимое этой страницы было переведено с помощью ИИ.

Смотреть последнюю версию оригинального контента на английском

Изменить эту документацию

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

Ссылка на документацию GitHub

Копировать

Копировать Markdown документа в буфер обмена

История интернационализации в JavaScript (i18n)

Интернационализация появилась задолго до веба и JavaScript. Программному обеспечению всегда требовалось поддерживать несколько языков, валюты, форматы дат и региональные стандарты. Ранние графические операционные системы, такие как GEM и Mac OS, успешно решали многие из этих задач еще в 1980-х годах.

Те же принципы постепенно перешли в бэкенд-фреймворки. Ruby on Rails, Django, экосистема Java и приложения на PHP разработали собственные подходы к интернационализации. Базовые вопросы были понятны:

Где хранить файлы переводов?
Как форматировать даты, числа и валюты?
Как учитывать формы множественного числа и грамматические различия?
Как определять язык пользователя?

Пока сервер генерировал HTML-страницы целиком, процесс оставался прямолинейным. Сервер загружал нужный файл локализации, формировал разметку и отправлял ее браузеру.

PHP и GNU gettext стали предшественниками функции-хелпера t(), которая позже стала повсеместным стандартом в JavaScript и JSX.

Затем JavaScript начал активно захватывать браузер.

С переходом от серверных страниц к сложным Single-Page Applications (SPA) интернационализация стала задачей клиентской части. Браузеру потребовалось динамически подгружать переводы, переключать языки, форматировать значения, обрабатывать формы множественного числа и обновлять интерфейс без перезагрузки страницы.

В результате возник фундаментальный вопрос:

Как сделать веб-приложение многоязычным, не отправляя каждому пользователю огромные объемы данных перевода и тяжелый рантайм-код?

Этот вопрос определял развитие JavaScript i18n на протяжении полутора десятилетий.

Подходы радикально менялись: от глобальных объектов и вызовов t('key') до специализированных библиотек под конкретные фреймворки, экстракции на этапе компиляции, генерации типов в TypeScript, Server Components, tree-shaking и современных компиляторных решений, превращающих контент в оптимизированный JavaScript-код еще во время сборки.

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

Экосистема библиотек интернационализации JavaScript

Содержание

Ранний веб: интернационализация JavaScript до 2016 года

Чтобы оценить современные инструменты i18n, важно вспомнить контекст веб-разработки 2011-2015 годов.

Перенос логики на сторону клиента

В начале 2010-х годов интернационализация оставалась прерогативой сервера. JavaScript служил вспомогательным слоем для анимаций, валидации форм и небольших плагинов на jQuery.

С ростом популярности SPA на базе Backbone.js, Knockout.js и раннего AngularJS логика рендеринга перешла в браузер. Клиентский код должен был самостоятельно форматировать валюту, отображать локализованные даты, учитывать правила множественного числа и менять текст без перезагрузки страниц.

Однако браузерная среда 2011 года не имела для этого встроенных средств:

Спецификация ECMAScript Internationalization API (ECMA-402) была финализирована только в декабре 2012 года с появлением объекта Intl. До ее повсеместной поддержки даже базовое форматирование дат требовало громоздких сторонних функций или тяжелых полифилов.

Инструменты вроде Webpack только зарождались, а нативных ES-модулей в браузерах не существовало. Скрипты подключались через теги <script>, а словари складывались в глобальные переменные вроде window.translations = { ... }.

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

Первая волна клиентских библиотек

В период с 2012 по 2015 год был заложен фундамент современной клиентской i18n:

Созданная Яном Мюлеманом (Jan Mühlemann), библиотека i18next сформировала стандарт поиска по ключам в рантайме. Она предложила вложенные ключи, интерполяцию переменных, правила множественного числа и модульную структуру для плагинов детекции языка и бэкендов. Библиотека стала стандартом для чистого JS и раннего Node.js.

Созданная Кадзуей Кавагути (Kazupon), vue-i18n адаптировала интернационализацию к реактивной модели Vue.js, предложив шаблонные директивы (v-t) и функцию $t().

Созданная в Yahoo! в рамках проекта FormatJS, react-intl перенесла стандарт ICU MessageFormat и браузерные API Intl в React через декларативные компоненты (<FormattedMessage>, <FormattedDate>).

Ян Мюлеман адаптировал i18next для быстрорастущего сообщества React с использованием Higher-Order Components (withTranslation) и контекста для обновления компонентов при смене языка.

Ограничения эпохи до 2016 года

Несмотря на функциональность этих библиотек, архитектурные ограничения того времени создавали заметные трудности:

Вызовы вроде t('marketing.landing.hero.cta') не проверялись статически. Опечатка в ключе обнаруживалась только во время работы приложения, приводя к пустым блокам или отображению сырых идентификаторов.

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

Без разделения кода по маршрутам или компонентам все строки приложения загружались одновременно, замедляя первоначальную загрузку.

Файлы переводов хранились отдельно от компонентов, что часто приводило к появлению забытых неиспользуемых ключей и пропущенным переводам.

Эпоха фреймворков: эволюция по экосистемам

В период с 2016 по 2026 год архитектура фронтенда существенно изменилась. TypeScript стал стандартом индустрии, компонентная модель окрепла, сборщики Webpack, Vite и Turbopack принесли гранулярный code splitting, React Server Components вернули часть рендеринга на сервер, а компиляторы начали анализировать код приложения напрямую.

В приведенных ниже вкладках показано, как развивалась i18n в разных средах. В этих экосистемах react-intlayer и его аналоги (next-intlayer, vue-intlayer, angular-intlayer, svelte-intlayer и solid-intlayer) представляют собой оптимизированные решения, спроектированные с учетом особенностей каждого фреймворка.

Показать все данные таблицы