@intlayer/docs 9.5.6 → 9.5.8

package/blog/ru/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next против Intlayer: бенчмарк и сравнение 2026"
 description: "react-i18next и next-i18next в сравнении с Intlayer на Next.js и TanStack Start. Размер bundle, утечки контента, скорость переключения локали и опыт разработчика."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next против Intlayer | Бенчмарк интернационализации (i18n) для React и Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` - самый распространенный i18n-фреймворк в экосистеме JavaScript. Через `react-i18next` и `next-i18next` он используется в огромном количестве приложений на React и Next.js. Intlayer представляет собой альтернативу на основе компилятора с изолированной областью видимости для каждого компонента.
 
 В этой статье они сравниваются на основе реальных замеров, а не списков возможностей. Данные взяты из [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) - открытого набора тестов, собирающего одно и то же приложение на каждой библиотеке и фиксирующего то, что браузер фактически загружает по сети.
@@ -99,6 +101,10 @@ author: aymericzip
 
 ### Результаты на Next.js (`next-i18next`)
 
+Выберите интересующие вас метрики и библиотеки:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Библиотека                        | Стратегия      | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E-реактивность | Гидратация |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | ---------------: | ---------: |
 | **base** (без i18n)               | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |          13.4 ms |    11.8 ms |
@@ -119,6 +125,15 @@ author: aymericzip
 - **Размер компонентов.** Компонент с вызовом `useTranslation()` компилируется в 26-79 KB; тот же компонент с `useIntlayer()` весит 6.9 KB.
 - **Гидратация** возрастает до 27.7 ms в варианте `dynamic`: экземпляр i18next инициализируется и запрашивает бэкенд на стороне клиента до того, как React завершит гидратацию.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Полная таблица, каждая библиотека и каждая стратегия, в [отчете о бенчмарке Next.js](https://intlayer.org/ru/doc/benchmark/nextjs).
+
 ### Результаты на TanStack Start (`react-i18next`)
 
 То же приложение на TanStack Start со стандартным `react-i18next`, что исключает специфику Next.js из сравнения.
@@ -141,8 +156,19 @@ author: aymericzip
 - Строка `static` у Intlayer уже дает **0% утечки страниц**, так как в сборку входят только словари, импортированные компонентами этой страницы. Включение `importMode: 'dynamic'` устраняет и утечку языков.
 - **Размер компонентов**: 24-27 KB на компонент в `react-i18next` против 6-8 KB в Intlayer. `useTranslation()` связывает каждый компонент с глобальным экземпляром i18next.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Полная таблица в [отчете о бенчмарке TanStack Start](https://intlayer.org/ru/doc/benchmark/tanstack).
+
 ## Причина различий: глобальный экземпляр против скомпилированных словарей
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` был создан в 2012 году как runtime: глобальный объект содержит хранилище ресурсов, плагины расширяют его возможности, а `t()` ищет ключи при рендере. Это обеспечивает гибкость (любой фреймворк, бэкенд и формат), но ведет к утяжелению:
 
 ```bash
@@ -166,7 +192,13 @@ author: aymericzip
                 └── page.tsx     # должна знать, что нужны ["common", "about"]
 ```
 
-Экземпляр не может знать заранее, какие ключи понадобятся компоненту, поэтому держит в памяти все загруженные пространства имен. Оптимизация означает, что **вы** делите каталоги, **вы** перечисляете пространства имен для каждой страницы и **вы** вручную обновляете этот список при перемещении компонентов. Как отмечено в [заметках бенчмарка](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "поддерживать типобезопасность и точно знать, какое пространство имен подключить к странице - это сущий кошмар".
+Экземпляр не может знать заранее, какие ключи понадобятся компоненту, поэтому держит в памяти все загруженные пространства имен. Оптимизация означает, что **вы** делите каталоги, **вы** перечисляете пространства имен для каждой страницы и **вы** вручную обновляете этот список при перемещении компонентов.
+
+Издержки растут сразу по двум осям, страницам и локалям:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Как отмечено в [заметках бенчмарка](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "поддерживать типобезопасность и точно знать, какое пространство имен подключить к странице - это сущий кошмар".
 
 Intlayer отказывается от глобального экземпляра. Контент объявляется рядом с компонентом, а компилятор строит граф зависимостей при сборке:
 
@@ -193,7 +225,8 @@ Intlayer отказывается от глобального экземпляр
 
 ### Настройка
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Дополнительно требуется клиентский `I18nProvider`, воссоздающий экземпляр с теми же параметрами, `generateStaticParams` и список `namespaces` на каждой странице.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Клиентский компонент
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > Страница, отображающая этот компонент, обязана загрузить пространство имен `about`, а `t("counter.label")` будет обычной строкой без строгой типизации, если не дополнить интерфейс `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` и `increment` строго типизированы: опечатка в имени вызовет ошибку TypeScript, а отсутствие французского текста остановит сборку.
 
+</Tab>
+</Tabs>
+
 ### Синхронный серверный компонент
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 Страница вызывает `i18n.getFixedT(locale, "about")` и пробрасывает `t` и `locale` вниз через props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Сохраните API i18next, получите производительность Intlayer
 
 Вам не нужно переписывать компоненты, чтобы получить показатели из бенчмарка выше. `@intlayer/i18next`, `@intlayer/react-i18next` и `@intlayer/next-i18next` являются готовыми адаптерами: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, формы множественного числа `_one` / `_other`, суффиксы контекста и `returnObjects` продолжают работать, получая данные из скомпилированных словарей Intlayer.
@@ -415,18 +462,85 @@ export default defineConfig({
 
 ## Что и когда выбирать?
 
-- **Выбирайте i18next**, если вам необходима его экосистема плагинов (детекторы, бэкенды, ICU, Locize), вы локализуете решения вне React (сервисы Node, чистый JS, другие фреймворки), у команды уже есть практический опыт или переводческая платформа ожидает формат `locales/{lng}/{ns}.json`. Заложите время на организацию пространств имен, настройку бэкенда и ручную поддержку карты маршрутов, если важна скорость.
-- **Выбирайте Intlayer**, если вам нужны **контент внутри компонентов**, **строгий TypeScript**, **ошибки сборки при нехватке строк**, **автоматический tree-shaking и lazy loading**, мгновенное переключение языка, синхронные серверные компоненты и встроенные редакционные инструменты (Visual Editor, CMS, перевод через ИИ, сервер MCP). Идеально подходит для модульных кодовых баз и дизайн-систем.
-- **Выбирайте адаптеры `@intlayer/*-i18next`**, если вы уже используете i18next и хотите получить экономию в размере бандла и прирост скорости без масштабного рефакторинга.
+<AccordionGroup>
+<Accordion header="Выбрать i18next">
+
+Если вам необходима его экосистема плагинов (детекторы, бэкенды, ICU, Locize), вы локализуете решения вне React (сервисы Node, чистый JS, другие фреймворки), у команды уже есть практический опыт или переводческая платформа ожидает формат `locales/{lng}/{ns}.json`. Заложите время на организацию пространств имен, настройку бэкенда и ручную поддержку карты маршрутов, если важна скорость.
+
+</Accordion>
+<Accordion header="Выбрать Intlayer">
+
+Вам нужен **контент на уровне компонентов**, **строгий TypeScript**, **ошибки отсутствующих ключей во время сборки**, **tree-shaking и lazy loading без усилий**, мгновенное переключение языка, синхронные серверные компоненты и встроенные инструменты для редактирования ([Визуальный редактор](https://intlayer.org/ru/doc/concept/editor), [CMS](https://intlayer.org/ru/doc/concept/cms), [ИИ-перевод](https://intlayer.org/ru/doc/concept/auto-fill), [MCP-сервер](https://intlayer.org/ru/doc/mcp-server)). Особенно актуально для крупных модульных кодовых баз и дизайн-систем.
+
+</Accordion>
+<Accordion header="Выбрать адаптеры @intlayer/*-i18next">
+
+Вы уже используете i18next и хотите получить преимущества в размере бандла и реактивности без переписывания компонентов. Ваши файлы `locales/{lng}/{ns}.json` остаются источником истины. Измерено бок о бок в [i18next против @intlayer/i18next](https://intlayer.org/ru/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## Часто задаваемые вопросы (FAQ)
+
+<FAQ>
+
+<Question title="Почему i18next намного тяжелее других библиотек?">
+
+Он проектировался как агностичный к фреймворкам runtime: глобальный экземпляр, пайплайн плагинов, хранилище ресурсов, резолвер ключей. Эта гибкость компилируется в каждый бандл. Пустой компонент, импортирующий только библиотеку, весит **19.7 KB gzip** с `next-i18next` против **5.5 KB** с `next-intlayer`, и эта цена платится на каждой странице, независимо от объема контента.
+
+</Question>
+
+<Question title="Помогает ли ленивая загрузка с бэкендом?">
+
+Она решает проблему байтов, но не задержки. Переход на `i18next-resources-to-backend` экономит ~49 KB на страницу, но добавляет сетевой запрос при переключении локали: **123 мс** в конфигурации `dynamic` и **185 мс** в `scoped-static` против **3-4 мс** у Intlayer. Гидратация также увеличивается до 27.7 мс, так как инстанс резолвит бэкенд до гидратации React.
+
+</Question>
+
+<Question title="Можно ли достичь 0% утечек с i18next?">
+
+Да, с `scoped-dynamic`: один неймспейс на маршрут, бэкенд ресурсов и карта соответствия страниц неймспейсам, поддерживаемая вручную. Это дает 163.4 KB на страницу в Next.js, все еще на **+22 KB** больше, чем у Intlayer (141.3 KB), которому не требовалась ручная настройка. См. [оптимизацию бандла](https://intlayer.org/ru/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Нужно ли переписывать компоненты для миграции?">
+
+Нет. `@intlayer/i18next`, `@intlayer/react-i18next` и `@intlayer/next-i18next` сохраняют `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, формы множественного числа `_one` / `_other`, контекстные суффиксы и `returnObjects`. Всего одна строчка плагина в `next.config.ts` или `vite.config.ts`. Пошагово в [руководстве по миграции с next-i18next](https://intlayer.org/ru/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Что происходит с моими плагинами i18next?">
+
+Бэкенды и детекторы языка принимаются, но остаются неактивными: в рантайме больше нечего загружать или определять. Определение языка становится конфигурацией маршрутизации Intlayer (префикс URL, cookie, заголовок). Если ваше приложение получает переводы из CMS во время запроса, используйте [Intlayer CMS](https://intlayer.org/ru/doc/concept/cms) или `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Похожие сравнения
 
-- [next-intl против Intlayer](https://intlayer.org/ru/blog/next-intl-vs-intlayer) (тот же бенчмарк)
-- [Lingui против Intlayer](https://intlayer.org/ru/blog/lingui-vs-intlayer) (тот же бенчмарк)
-- [vue-i18n против Intlayer: бенчмарк](https://intlayer.org/ru/blog/vue-i18n-vs-intlayer-benchmark) (тот же бенчмарк)
-- [next-i18next против next-intl и Intlayer](https://intlayer.org/ru/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [react-i18next против react-intl и Intlayer](https://intlayer.org/ru/blog/react-i18next-vs-react-intl-vs-intlayer)
+Тот же бенчмарк, другие библиотеки:
+
+- [next-intl vs Intlayer](https://intlayer.org/ru/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/ru/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/ru/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/ru/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/ru/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Подробнее об i18next:
+
+- [i18next против @intlayer/i18next](https://intlayer.org/ru/blog/i18next-vs-intlayer-i18next), адаптеры измерены на одном приложении
 - [Устарел ли i18next?](https://intlayer.org/ru/blog/is-i18next-outdated)
+- [Использование Intlayer с i18next](https://intlayer.org/ru/blog/intlayer-with-i18next) и [с react-i18next](https://intlayer.org/ru/blog/intlayer-with-react-i18next)
+- [Как интернационализировать приложение Next.js с помощью next-i18next](https://intlayer.org/ru/blog/nextjs-internationalization-using-next-i18next)
+
+Справочная документация:
+
+- [Отчет о бенчмарке Next.js](https://intlayer.org/ru/doc/benchmark/nextjs) и [отчет о бенчмарке TanStack Start](https://intlayer.org/ru/doc/benchmark/tanstack)
+- Адаптеры совместимости: [i18next](https://intlayer.org/ru/doc/compatibility/i18next), [react-i18next](https://intlayer.org/ru/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/ru/doc/compatibility/next-i18next)
+- Руководства по миграции: [i18next](https://intlayer.org/ru/doc/migration/i18next), [react-i18next](https://intlayer.org/ru/doc/migration/react-i18next), [next-i18next](https://intlayer.org/ru/doc/migration/next-i18next)
+- [Оптимизация бандла](https://intlayer.org/ru/doc/concept/bundle-optimization) и [компилятор Intlayer](https://intlayer.org/ru/doc/compiler)
+- [Компонентная i18n против централизованной](https://intlayer.org/ru/blog/per-component-vs-centralized-i18n)
+- [Компиляторная i18n против декларативной](https://intlayer.org/ru/blog/compiler-vs-declarative-i18n)
 
 ## Звезды на GitHub
 

package/blog/ru/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Intlayer легче, чем Paraglide?
+description: Paraglide кажется практически невесомым в бенчмарках i18n, поскольку его код генерируется прямо в ваш репозиторий. Разбираемся, куда на самом деле уходит этот вес, почему чтение локали для каждого узла обходится дорого и как динамическая загрузка Intlayer отправляет одну локаль вместо всех.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Интернационализация
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Intlayer легче, чем Paraglide?
+
+Да.
+
+У `Paraglide` сложилась отличная репутация самого легкого решения для i18n, и на первый взгляд [бенчмарк](https://intlayer.org/ru/doc/benchmark/tanstack) с этим согласен: размер его библиотеки близок к нулю. Однако нулевой размер библиотеки вовсе не означает нулевое количество отправленных байтов. Это лишь говорит о том, что байты находятся там, куда эта метрика не заглядывает.
+
+<TOC/>
+
+## Ключевые выводы
+
+**Размер библиотеки скрыт, а не устранен:**
+
+Paraglide генерирует рантайм и функции сообщений непосредственно в вашу кодовую базу. Этот код отправляется в браузер, но учитывается как _ваш_ код, а не код библиотеки.
+
+**Отсутствие провайдера - это не бесплатный выигрыш:**
+
+Каждый вызов `m.my_key()` самостоятельно определяет локаль, считывая cookie или хранилище для каждого отрисованного узла, вместо того чтобы прочитать ее один раз из контекста.
+
+**Нет динамической загрузки:**
+
+Paraglide импортирует все локали сообщения в клиентский бандл. Intlayer с `importMode: 'dynamic'` или `'fetch'` загружает только ту локаль, которая сейчас отображается.
+
+**Tree shaking не гарантирован:**
+
+В некоторых наших тестах заявленный Paraglide tree shaking не сработал. Обязательно проверьте собственный бандл.
+
+## Куда уходит вес Paraglide?
+
+В отчетах бенчмарков метрика «размер библиотеки» измеряет провайдер и хуки каждой библиотеки i18n в пустом компоненте, до добавления какого-либо контента.
+
+| Библиотека (TanStack Start)   | Размер либы (gz) | Размер либы (min) |
+| ----------------------------- | ---------------- | ----------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB           | 4.5 KB            |
+| `react-intlayer@9.5.1`        | 5.0 KB           | 15.2 KB           |
+
+В отрыве от контекста Paraglide выигрывает. Но Paraglide - это компилятор: он читает ваши файлы `messages/*.json` и записывает папку `paraglide/` в ваш репозиторий. Она содержит `runtime.js` (определение локали, стратегии cookie и storage, локализация URL) и по одной JavaScript-функции на каждое сообщение.
+
+```bash
+src/paraglide/
+├── runtime.js      # определение локали, стратегии, URL-хелперы
+├── server.js
+├── messages.js     # реэкспорт всех сообщений
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Поскольку этот код находится в папке `src/` и вы импортируете его по относительному пути, сборщик приписывает его вашему приложению, а не пакету из `node_modules`. Колонка размера библиотеки почти ничего не показывает, хотя та же самая логика по-прежнему отправляется в бандле вашей страницы.
+
+Генерация кода сама по себе неплоха: сгенерированный рантайм содержит только ту логику, которая нужна вашей конфигурации (стратегия префиксов, cookie или local storage и т. д.). Intlayer достигает того же результата иначе, внедряя переменные окружения на этапе сборки, благодаря чему бандлер удаляет ветви кода, не используемые вашей конфигурацией. Оба подхода оказываются в 3–10 раз легче, чем `i18next` или `next-intl`.
+
+Поэтому честное сравнение - это не размер библиотеки. Это **JavaScript, фактически отправляемый на каждую страницу**.
+
+## Измеренный вес страницы
+
+Приложение TanStack Start, 10 страниц, измерения на маршрутах `en` и `fr`, сжатие gzip:
+
+| Конфигурация                       | Средний JS стр (gz) | Выше базы   | Утечка локали | Утечка других страниц |
+| ---------------------------------- | ------------------- | ----------- | ------------- | --------------------- |
+| Базовая (без i18n)                 | 111.0 KB            | -           | 0.0%          | 0.0%                  |
+| `paraglide` (любая стратегия)      | 125.1 KB            | +14.1 KB    | 49.7%         | 0.0%                  |
+| `intlayer` (`importMode: static`)  | 125.8 KB            | +14.8 KB    | 50.0%         | 0.0%                  |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**        | **+7.6 KB** | **0.0%**      | **0.0%**              |
+
+Next.js 16 App Router, то же приложение:
+
+| Конфигурация       | Средний JS стр (gz) | Выше базы   |
+| ------------------ | ------------------- | ----------- |
+| Базовая (без i18n) | 141.0 KB            | -           |
+| `paraglide-next`   | 155.3 KB            | +14.3 KB    |
+| `next-intlayer`    | **141.3 KB**        | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Полные данные приведены в [отчете о бенчмарке TanStack Start](https://intlayer.org/ru/doc/benchmark/tanstack) и в [отчете о бенчмарке Next.js](https://intlayer.org/ru/doc/benchmark/nextjs). Каждый бандл можно изучить в [репозитории бенчмарка](https://github.com/intlayer-org/benchmark-i18n).
+
+Два момента бросаются в глаза:
+
+- В режиме `static` Intlayer отправляет практически тот же объем данных, что и Paraglide (125.8 KB против 125.1 KB). Это ожидаемо: оба включают все локали сообщений, используемых страницей.
+- Paraglide остается на уровне 125.1 KB при любой стратегии, поскольку в нем нет динамического режима. Каждая строка в таблице выше соответствует статической конфигурации.
+
+## Отсутствие Provider: идея, кажущаяся хорошей лишь на первый взгляд
+
+У Paraglide нет провайдера. Вы импортируете сообщение и вызываете его:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Ни контекста, ни обертки, ни хука. Это кажется проще. Но локаль все равно нужно откуда-то получать. Каждая сгенерированная функция сообщения выглядит приблизительно так (упрощенно):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // вычисляется при каждом вызове
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...по одной ветке на каждую локаль
+};
+```
+
+А `getLocale()` проходит по всем настроенным стратегиям (cookie, local storage, URL, базовая локаль), чтобы определить текущую локаль. Таким образом, каждый отрисовываемый текстовый узел (`<>{m.my_key()}</>`) выполняет собственное определение локали, включая чтение `document.cookie` в браузере. Страница с 200 переведенными строками вычисляет локаль 200 раз за один рендер, и затем повторно при каждом перерендере.
+
+Библиотека с провайдером считывает локаль **один раз**, сохраняет ее в контексте (или сигнале, или сторе), и каждый узел читает значение, уже находящееся в оперативной памяти. Провайдер весит всего несколько сотен байт. Отказ от него нагружает процессор при каждом рендере, что наглядно отражается в бенчмарке: время загрузки страницы и скорость смены языка у Paraglide стабильно уступают Intlayer на TanStack Start (22.1 мс против 14.6 мс при загрузке страницы, 4.3 мс против 3.2 мс при реактивности E2E).
+
+## Удобство разработки (DX)
+
+Источником истины для Paraglide является JSON, но вы никогда не импортируете сам JSON. Вы импортируете сгенерированный файл `.js`:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/ru.json"
+{
+  "hero_title": "Публикуйте ваше приложение на всех языках"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Существует только после перегенерации компилятором из JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      ru: "Публикуйте ваше приложение на всех языках",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Такой рабочий процесс влечет за собой издержки:
+
+- Любое изменение в файле JSON требует перегенерации, прежде чем импорт заработает или обновятся типы.
+- Сгенерированную папку `paraglide/` приходится либо коммитить в репозиторий (что приводит к конфликтам слияния при каждом PR с правками текста), либо добавлять в игнорируемые файлы (что требует шага генерации перед каждой проверкой типов, тестом и задачей CI).
+- Каждая строка превращается в вызов функции. Константы становятся `m.key()` абсолютно везде, даже там, где подошло бы обычное статическое значение.
+
+## Tree Shaking: проверьте свой бандл
+
+Главное обещание Paraglide заключается в том, что неиспользуемые сообщения удаляются с помощью tree shaking, поскольку каждое сообщение является отдельным экспортом. В бенчмарке Svelte + Vite это работает именно так, как заявлено.
+
+В других окружениях этого не произошло. В нашем тесте на [Next.js](https://intlayer.org/ru/doc/benchmark/nextjs) страницы Paraglide весят на 14 KB больше базового приложения, тогда как `next-intlayer` добавляет лишь 0.3 KB. Предыдущие тесты на TanStack Start также показали, что сообщения с других страниц попадали в бандл текущего маршрута.
+
+Tree shaking зависит от вашего сборщика (Turbopack, Rolldown, Rollup), способа импорта сообщений (`import { m }` против `import * as m`) и анализа сайд-эффектов. Если вы выбираете Paraglide из-за размера, откройте анализатор бандла и убедитесь, что это действительно работает в вашем приложении.
+
+## Нет динамической загрузки
+
+Это фундаментальное структурное ограничение. В Paraglide нет способа загружать по одной локали за раз: каждая функция сообщения статически импортирует реализацию каждого языка, поэтому абсолютно все языки попадают в ваш клиентский бандл.
+
+При 2 языках половина трафика на переводы тратится впустую, что соответствует утечке локали около ~50%, измеренной выше. При 10 языках бесполезны 90% объема. При 30 языках - 97%.
+
+Переход на динамическую загрузку также не решил бы проблему: при наличии отдельной функции на каждое сообщение ленивая загрузка каждой из них привела бы к тысячам сетевых запросов.
+
+Intlayer позволяет выбирать стратегию как глобально, так и для каждого словаря отдельно:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Что отправляется клиенту                                     | vs. Paraglide                    |
+| ------------ | ------------------------------------------------------------ | -------------------------------- |
+| `static`     | Все локали словарей, которые использует страница             | Теоретически тот же объем        |
+| `dynamic`    | Только активная локаль, ленивая загрузка для каждого словаря | **В N раз меньше** при N локалях |
+| `fetch`      | Только активная локаль, получаемая через Live Sync API       | **В N раз меньше** при N локалях |
+
+Благодаря [трансформации на этапе сборки](https://intlayer.org/ru/doc/concept/bundle-optimization) и режиму `importMode: 'static'`, Intlayer теоретически загружает ровно тот же объем данных, что и Paraglide. А в режимах `'dynamic'` или `'fetch'` он загружает только то, что требуется текущей локали: для приложения на N языках объем передаваемых переводов оказывается в N раз меньше, чем у Paraglide.
+
+## Где Paraglide все еще уместен
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite с небольшим количеством языков">
+
+Если ваш стек - это Svelte с Vite и вы поддерживаете два или три языка, tree shaking работает как заявлено, а накладные расходы на лишние локали остаются незначительными.
+
+</Accordion>
+<Accordion header="Существующий рабочий процесс с inlang">
+
+Если ваша команда уже использует экосистему inlang (Fink, Sherlock, плагины форматов сообщений), Paraglide нативно интегрируется в этот процесс.
+
+</Accordion>
+</AccordionGroup>
+
+## Проверьте на своем приложении
+
+Проверьте объем бандла и утечки локалей вашего рабочего приложения с помощью бесплатного инструмента [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner):
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Установка Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Дополнительные материалы
+
+- [Бенчмарк i18n в TanStack Start](https://intlayer.org/ru/doc/benchmark/tanstack)
+- [Бенчмарк i18n в Next.js](https://intlayer.org/ru/doc/benchmark/nextjs)
+- [Оптимизация бандла и `importMode`](https://intlayer.org/ru/doc/concept/bundle-optimization)
+- [Как выбрать библиотеку i18n для React](https://intlayer.org/ru/blog/how-to-pick-react-i18n-library)
+- [Аргументы в пользу компиляторного подхода к интернационализации](https://intlayer.org/ru/blog/compiler-vs-declarative-i18n)