@intlayer/docs 9.5.6 → 9.5.7

package/blog/ru/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: Один и тот же API, разный Bundle"
 description: Что меняется, когда импорты next-intl приложения Next.js обслуживаются адаптером совместимости @intlayer/next-intl. Размер bundle, утечки, размер компонента и гидратация, измеренные на одном коде, плюс то, что адаптер сохраняет, игнорирует и не может заменить.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Один и тот же API, разный Bundle
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` - это адаптер совместимости: он предоставляет API `next-intl` (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, ICU plurals, `NextIntlClientProvider`...) и обслуживает его из словарей, скомпилированных Intlayer. Код приложения не меняется. Меняется bundle.
 
 Эта статья сравнивает оба варианта на одном Next.js приложении, собранном один раз с `next-intl` и один раз с адаптером. Цифры взяты из [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), open-source набора инструментов, который записывает, что на самом деле загружает браузер. Если вам нужно сравнение `next-intl` и Intlayer как библиотек, прочитайте [next-intl vs Intlayer](https://intlayer.org/ru/blog/next-intl-vs-intlayer). Здесь речь идёт о том, что меняется в адаптере, когда вы оставляете компоненты как они есть.
@@ -109,6 +111,10 @@ const AboutPage = () => {
 
 ### Результаты на Next.js
 
+Выберите интересующие вас метрики и библиотеки:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,6 +135,15 @@ const AboutPage = () => {
 - **Гидратация на 2 мс быстрее** (12.8 против 14.7 мс): нет необходимости десериализовать объект сообщения из RSC payload перед тем, как React может выполнить гидратацию.
 - **Адаптер не является нативным runtime.** `next-intlayer` занимает **141.3 KB**, +0.3 KB относительно базового приложения, с runtime 5.5 KB. Адаптер предоставляет API поверхность `next-intl` (`useFormatter`, `t.rich`, ICU resolver) поверх ядра Intlayer, отсюда 8.0 KB и +6 KB на страницу. Это мост, а не пункт назначения.
 
+<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 (`use-intl`)
 
 `use-intl` - это framework-агностическое ядро `next-intl`. Его адаптер, `@intlayer/use-intl`, следует той же архитектуре с Vite плагином (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ const AboutPage = () => {
 - **Переключение локалей работает быстрее.** Оптимизированные настройки `use-intl` занимают **13-21 ms** для обновления `html[lang]`; адаптер занимает **4-9 ms**. Меньше компонентов перерисовывается, и ничего не переходит из дерева сообщений.
 - **`static` сохраняет каждую локаль.** Строка `static` адаптера показывает утечку локалей на 49.7%, как и native Intlayer в режиме `static`: все локали объединены, но используются только словари страницы. Одна строка конфига (`importMode: 'dynamic'`) это убирает.
 
+<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).
+
 ## Почему цифры меняются
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Ничего в компоненте не изменилось, поэтому прирост производительности полностью зависит от того, к чему привязана `useTranslations`.
 
-**With `next-intl`**, the binding is the provider. `NextIntlClientProvider` receives the whole `messages` object for the locale; every `useTranslations("about")` reads from it. The bundler sees one component importing one hook that reads one context, and cannot know that only the `about` branch is used. The routes below all share the same message object, so the page-leak column reads ~90% until you split the file yourself.
+**With `next-intl`**, the binding is the provider. `NextIntlClientProvider` receives the whole `messages` object for the locale; every `useTranslations("about")` reads from it. The bundler sees one component importing one hook that reads one context, and cannot know that only the `about` branch is used. The routes below all share the same message object, so the page-leak column reads ~90% until you split the file yourself, и потери растут сразу по двум осям, страницы и локали:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -273,32 +301,113 @@ export default withIntlayer(nextConfig);
 
 ### Что вы получаете сверх оптимизации размера
 
-- **Типизированные ключи.** `useTranslations("about")` типизирована против скомпилированного словаря `about`. `t("does.not.exist")` — это ошибка TypeScript, а не fallback во время выполнения.
+- **Типизированные ключи.** `useTranslations("about")` типизирована против скомпилированного словаря `about`. `t("does.not.exist")`, это ошибка TypeScript, а не fallback во время выполнения.
 - **`npx intlayer test`** блокирует CI, когда в какой-то локали отсутствует ключ. **`npx intlayer fill`** переводит отсутствующие ключи с помощью выбранного провайдера (OpenAI, Anthropic, Mistral, Gemini...) используя ваш собственный ключ и записывает результат обратно в `messages/{locale}.json`.
 - **Visual Editor и CMS** работают с одними и теми же словарями, поэтому не-разработчики могут редактировать `messages/fr.json` через UI, и файл обновляется.
 - **Постепенный переход на `.content.ts`.** Любой компонент может переключиться с `useTranslations("about")` на `useIntlayer("about")` с co-located content файлом, по одному за раз. JSON и `.content.ts` словари сосуществуют и объединяются.
 
 ## Ограничения, которые нужно знать перед началом
 
-- **Routing config переходит в `intlayer.config.ts`.** `createNavigation(routing)` и `createMiddleware(routing)` сохраняют свою сигнатуру, но игнорируют аргумент: локали, локаль по умолчанию и стратегия префикса поступают из конфига Intlayer's `routing`. Если вы используете локализованные `pathnames` от `next-intl` (`/about` → `/a-propos`), адаптер их не интерполирует; `intlayer.routing.rewrite` покрывает этот случай, но это отдельное изменение.
-- **`useTranslations()` без namespace не привязан.** Этап оптимизации требует статический namespace, чтобы знать, какой dictionary импортировать. Прямой вызов все еще работает через registry во время выполнения, который ссылается на каждый dictionary, что точно утечка, которую вы пытались избежать. Передайте namespace.
-- **Адаптер не бесплатен.** 8.0 KB runtime против 5.5 KB для `next-intlayer` и +6-7 KB на страницу по сравнению с native build. Это цена за API surface `next-intl`. Если вы дошли до точки, где каждый компонент был перемещен на `useIntlayer`, отказывайтесь от адаптера.
-- **`messages`, `timeZone`, `now` на провайдере игнорируются.** Форматеры поддерживаются нативным `Intl` и только locale влияет на их output; если вы полагаетесь на forced time zone или fixed `now` для hydration-stable дат, обработайте это на call site.
+<AccordionGroup>
+<Accordion header="Конфигурация маршрутизации переносится в intlayer.config.ts">
+
+`createNavigation(routing)` и `createMiddleware(routing)` сохраняют сигнатуру, но игнорируют аргумент: локали, локаль по умолчанию и стратегия префиксов берутся из конфигурации `routing` Intlayer. Если вы используете локализованные `pathnames` из `next-intl` (`/about` в `/a-propos`), адаптер их не интерполирует; `routing.rewrite` Intlayer покрывает этот случай, но это отдельное изменение.
+
+</Accordion>
+<Accordion header="useTranslations() без пространства имен не связывается">
+
+Фазе оптимизации требуется статическое пространство имен, чтобы знать, какой словарь импортировать. Вызов без namespace все еще работает через реестр рантайма, ссылающийся на каждый словарь, что как раз и является той утечкой, которую вы пытались устранить. Передавайте namespace.
+
+</Accordion>
+<Accordion header="Адаптер не бесплатен">
+
+8.0 KB рантайма против 5.5 KB у `next-intlayer`, и +6-7 KB на страницу по сравнению с нативной сборкой. Это плата за API `next-intl`. Когда все компоненты будут переведены на `useIntlayer`, удалите адаптер.
+
+</Accordion>
+<Accordion header="messages, timeZone и now в провайдере игнорируются">
+
+Форматтеры основаны на нативном `Intl`, и только локаль влияет на вывод. Если вам нужен принудительный часовой пояс или фиксированное `now` для стабильной гидратации дат, управляйте этим в месте вызова. См. [форматирование дат, времени и чисел](https://intlayer.org/ru/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## Когда использовать что?
 
-- **Оставайтесь на `next-intl`** если ваше приложение небольшое, bundle не вызывает беспокойства, и ваша команда комфортно владеет namespaces и `pick()` на каждой странице.
-- **Используйте `@intlayer/next-intl`**, если вы сейчас работаете с `next-intl` и хотите получить преимущества в размере bundle, устранение утечек и гидрации, типизированные ключи и инструменты CLI / CMS без переписывания. Это рекомендуемая точка входа для любого существующего `next-intl` codebase.
-- **Перейдите на native (`next-intlayer`)** для новых проектов или после того, как adapter выполнит свою работу. Это самый легкий из трех (5.5 KB, +0.3 KB за страницу) и разблокирует синхронные server components, `.content.ts` файлы per-component и полный набор функций.
+<AccordionGroup>
+<Accordion header="Остаться на next-intl">
+
+Ваше приложение небольшое, размер бандла вас не беспокоит, и вашей команде удобно вручную управлять пространствами имен и `pick()` на каждой странице.
+
+</Accordion>
+<Accordion header="Использовать @intlayer/next-intl">
+
+Вы уже используете `next-intl` сегодня и хотите получить преимущества в размере бандла, отсутствии утечек, быстрой гидратации, типизированных ключах и инструментах CLI / CMS без переписывания кода. Это рекомендуемая точка входа для любой существующей кодовой базы `next-intl`.
+
+</Accordion>
+<Accordion header="Перейти на нативный next-intlayer">
+
+Для новых проектов или когда адаптер выполнил свою задачу. Это самый легкий из трех вариантов (5.5 KB, +0.3 KB на страницу), который открывает синхронные серверные компоненты, файлы `.content.ts` для каждого компонента и полный набор функций. Начните с [Intlayer с Next.js](https://intlayer.org/ru/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Действительно ли код моего приложения остается нетронутым?">
+
+В Next.js да для компонентов: сборка бенчмарка изменила только `next.config.ts` и `intlayer.config.ts`. `getRequestConfig` в `src/i18n.ts`, проп `messages` в провайдере и вызовы `pick()` становятся мертвым кодом, который затем можно удалить.
+
+</Question>
+
+<Question title="Что происходит с сообщениями ICU?">
+
+Они продолжают работать. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` и `{ts, date, long}` обрабатываются резолвером ICU в Intlayer. См. [формат сообщений ICU](https://intlayer.org/ru/blog/icu-message-format).
+
+</Question>
+
+<Question title="Почему адаптер тяжелее нативного next-intlayer?">
+
+Он несет на себе API `next-intl` поверх ядра Intlayer: `useFormatter`, `t.rich`, резолвер ICU, хелперы навигации. Это 8.0 KB против 5.5 KB и +6 KB на страницу. Это мост, а не конечная цель.
+
+</Question>
+
+<Question title="Могу ли я мигрировать компонент за компонентом?">
+
+Да. Любой компонент может перейти с `useTranslations("about")` на `useIntlayer("about")` с рядом лежащим `.content.ts`. Словари JSON и `.content.ts` сосуществуют и объединяются.
+
+</Question>
+
+<Question title="Работают ли локализованные пути (pathnames)?">
+
+Не через `pathnames` из `next-intl`: адаптер принимает их для типизации, но не интерполирует. Используйте вместо этого `routing.rewrite` от Intlayer.
+
+</Question>
+
+</FAQ>
 
 ## Связанные сравнения
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (библиотеки, одинаковый benchmark)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (одна серия adapter)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (одна серия адаптеров)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (одна серия адаптеров)
-- [Руководство по миграции: next-intl на Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Справочник адаптера совместимости: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Та же серия адаптеров:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/ru/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/ru/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/ru/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Прямое сравнение библиотек:
+
+- [next-intl vs Intlayer](https://intlayer.org/ru/blog/next-intl-vs-intlayer), тот же бенчмарк
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/ru/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/ru/blog/is-next-intl-outdated)
+
+Справочная документация:
+
+- [Compat adapter: next-intl](https://intlayer.org/ru/doc/compatibility/next-intl)
+- [Руководство по миграции: с next-intl на Intlayer](https://intlayer.org/ru/doc/migration/next-intl)
+- [Отчет о бенчмарке Next.js](https://intlayer.org/ru/doc/benchmark/nextjs) и [отчет о бенчмарке TanStack Start](https://intlayer.org/ru/doc/benchmark/tanstack)
+- [Оптимизация бандла](https://intlayer.org/ru/doc/concept/bundle-optimization) и [компилятор Intlayer](https://intlayer.org/ru/doc/compiler)
+- [Визуальный редактор](https://intlayer.org/ru/doc/concept/editor), [CMS](https://intlayer.org/ru/doc/concept/cms) и [ИИ-перевод](https://intlayer.org/ru/doc/concept/auto-fill)
 
 ## Заключение
 

package/blog/ru/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: Benchmark и сравнение 2026"
 description: Bundle size, утечки контента, реактивность переключения локали и опыт разработчика, измеренные на Next.js и TanStack Start. Какую библиотеку i18n вам выбрать в 2026?
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # next-intl VS Intlayer | Benchmark интернационализации Next.js (i18n)
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `next-intl` - самая популярная библиотека i18n для Next.js. Intlayer - это альтернатива на основе компилятора с областью видимости компонента. Обе локализуют приложение App Router. Вопрос в том, какие затраты каждая из них влечет после сборки приложения.
 
 Эта статья - не учебное пособие. Это сравнение, подкрепленное числами из [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), открытого набора инструментов для тестирования, который создает одно и то же приложение с каждой библиотекой и измеряет то, что браузер фактически загружает и выполняет.
@@ -96,6 +98,10 @@ Intlayer не имеет варианта "scoped": компилятор авт
 
 ### Результаты на Next.js (App Router)
 
+Выберите метрики и библиотеки, которые вас интересуют:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                        | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
 | ------------------------------ | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (no i18n)             | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -116,6 +122,15 @@ Intlayer не имеет варианта "scoped": компилятор авт
 - **Размер компонента.** Компонент, который вызывает `useTranslations()`, компилируется в среднем до 21.8 KB; тот же компонент с `useIntlayer()` компилируется до 6.9 KB. В конфигурации `scoped-static` компоненты `next-intl` увеличиваются до 80.1 KB, потому что каждый встраивает свой каталог пространства имен.
 - **Реактивность и гидратация** находятся в одном диапазоне для обеих библиотек на Next.js (15-18 мс). Ни одна из них не является узким местом здесь.
 
+<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 (`use-intl`)
 
 `use-intl` - это не зависящее от фреймворка ядро `next-intl`. Тот же API, тот же формат сообщений. Его сравнение с `intlayer` на TanStack Start исключает из уравнения части, специфичные для Next.js.
@@ -139,8 +154,19 @@ Intlayer не имеет варианта "scoped": компилятор авт
 - **Размер компонента показывает разницу в архитектуре**: 76-87 KB на компонент с `use-intl` против 6-8 KB с Intlayer. `useTranslations()` привязывает каждый компонент к глобальному дереву сообщений; `useIntlayer()` привязывает его к собственному словарю.
 - **Переключение локали** в 2-4 раза быстрее с Intlayer (3 мс против 7-21 мс).
 
+<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).
+
 ## Почему такая разница? Централизованные каталоги vs скомпилированные словари
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `next-intl` следует классической модели: один JSON на локаль, загруженный в `getRequestConfig`, переданный в `NextIntlClientProvider`, доступный через `t("namespace.key")`.
 
 ```bash
@@ -162,6 +188,10 @@ Intlayer не имеет варианта "scoped": компилятор авт
 
 Runtime не может знать, какие ключи будет использовать страница, поэтому безопасный стандарт - отправить весь каталог. Оптимизация означает, что **вы** разделяете каталог на пространства имён, **вы** решаете, какие пространства имён нужны каждой странице, и **вы** поддерживаете это соответствие в синхронизации при перемещении компонентов. Строка `scoped-dynamic` в тесте производительности - это награда за эту работу, и большинство команд туда никогда не доходят.
 
+Цена недостижения этой цели растет сразу по двум осям, страницы и локали:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer переворачивает ответственность. Контент объявляется рядом с компонентом:
 
 ```bash
@@ -189,7 +219,8 @@ Intlayer переворачивает ответственность. Конте
 
 ### Client компонент
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -224,7 +255,8 @@ export const Counter = () => {
 
 > Помните, что нужно включить пространство имён `counter` в сообщения, передаваемые в `NextIntlClientProvider` на каждой странице, которая отображает этот компонент.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -265,11 +297,14 @@ export const Counter = () => {
 
 Не требуется регистрировать на странице: компонент содержит свой собственный контент.
 
+</Tab>
+</Tabs>
 ### Синхронный серверный компонент
 
 Компоненты системы проектирования (navbar, footer, карточки) часто являются серверными компонентами, отрендеренными как дочерние элементы клиентских компонентов, поэтому они не могут быть `async`.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -287,7 +322,8 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 
 Страница должна `await getTranslations("counter")` и `await getFormatter()`, затем передать результаты вниз как props. Компонент больше не является самостоятельным.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -306,9 +342,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### Метаданные
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -343,7 +382,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -367,6 +407,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Сохраните API next-intl, получите вывод Intlayer
 
 Вам не нужно переписывать компоненты, чтобы получить указанные выше числа производительности. `@intlayer/next-intl` - это готовый адаптер: он сохраняет `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, ICU plurals и помощники `next-intl/navigation`, и предоставляет их из словарей Intlayer, скомпилированных компилятором Intlayer.
@@ -388,17 +431,84 @@ export default withIntlayer(nextConfig);
 
 ## Когда выбрать что?
 
-- **Выбирайте next-intl**, если вам нужен стандарт экосистемы для Next.js, вы полагаетесь на ICU MessageFormat, ваше приложение небольшого или среднего размера, или вы интегрируетесь с платформой перевода (Crowdin, Phrase, Lokalise...), которая ожидает централизованный JSON. Учтите время на организацию пространств имён каталогов и выбор сообщений для каждой страницы, если производительность важна.
-- **Выбирайте Intlayer**, если вам нужно **контент, привязанный к компонентам**, **строгий TypeScript**, **ошибки missing-key на этапе сборки**, **автоматический tree-shaking и ленивая загрузка**, синхронные серверные компоненты и встроенные инструменты редактирования (Visual Editor, CMS, перевод с помощью AI, MCP server). Особенно актуально для больших модульных кодовых баз и дизайн-систем.
-- **Выбирайте `@intlayer/next-intl`**, если вы уже используете `next-intl` и хотите сэкономить на размере бандла без полного переписывания.
+<AccordionGroup>
+<Accordion header="Выбрать next-intl">
+
+Вам нужен стандарт экосистемы для Next.js, вы полагаетесь на ICU MessageFormat, ваше приложение небольшое или среднего размера, либо вы интегрируетесь с платформой переводов (Crowdin, Phrase, Lokalise...), ожидающей централизованный JSON. Заложите время на разделение каталогов по пространствам имен и выборку сообщений через `pick()` на каждой странице, если важна производительность.
+
+</Accordion>
+<Accordion header="Выбрать Intlayer">
+
+Вам нужен **контент с областью видимости компонента**, **строгий TypeScript**, **ошибки отсутствующих ключей на этапе сборки**, **автоматический tree-shaking и ленивая загрузка**, синхронные серверные компоненты и встроенные редакционные инструменты ([Визуальный редактор](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/next-intl">
+
+Вы уже используете `next-intl` и хотите получить преимущества в размере бандла без полного переписывания. [Адаптер совместимости](https://intlayer.org/ru/doc/compatibility/next-intl) сохраняет ваши импорты и файл `messages/{locale}.json` в качестве единого источника правды. Сравнение производительности в [next-intl против @intlayer/next-intl](https://intlayer.org/ru/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## Часто задаваемые вопросы
+
+<FAQ>
+
+<Question title="next-intl медленнее, чем Intlayer?">
+
+Не во время рендеринга. Разница в том, что передается клиенту: `next-intl` добавляет **+12.6 KB gzip** рантайма на каждой странице и в стандартных конфигурациях отправляет ~90% строк посторонних страниц с каждой страницей. Переключение локали и гидратация сопоставимы в Next.js (15-18 мс); в TanStack Start `use-intl` занимает 7-21 мс против 3-4 мс у Intlayer.
+
+</Question>
+
+<Question title="Могу ли я достичь 0% утечки с next-intl?">
+
+Да, с конфигурацией `scoped-dynamic`: разделите `messages/{locale}.json` на пространства имен для каждого маршрута, затем используйте `pick(messages, [...])` на каждой странице и поддерживайте эту структуру при перемещении компонентов. Строки `scoped-*` бенчмарка как раз отражают эту работу. Intlayer достигает 0% по умолчанию без этого, так как компилятор изолирует контент по компонентам. См. [оптимизация бандла](https://intlayer.org/ru/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Нужно ли переписывать компоненты для миграции?">
+
+Нет. `@intlayer/next-intl` сохраняет `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, множественные формы ICU и хелперы навигации, предоставляя их из скомпилированных словарей. Достаточно одной строки плагина в `next.config.ts`. Пошаговое руководство в [руководстве по миграции с next-intl](https://intlayer.org/ru/doc/migration/next-intl).
+
+</Question>
+
+<Question title="Поддерживает ли Intlayer формат сообщений ICU?">
+
+Нативная поддержка ICU находится в разработке. Адаптеры совместимости (`@intlayer/next-intl`, `@intlayer/use-intl`) полностью поддерживают ICU: множественные формы, `select`, `selectordinal`, `#` и `{ts, date, long}` обрабатываются резолвером ICU от Intlayer. Подробнее читайте в [формат сообщений ICU](https://intlayer.org/ru/blog/icu-message-format).
+
+</Question>
+
+<Question title="Могу ли я сохранить файлы messages/{locale}.json?">
+
+Да. [Плагин синхронизации JSON](https://intlayer.org/ru/doc/compatibility/next-intl) читает их, разбивает ключи верхнего уровня на словари и перезаписывает переводы в те же файлы при обновлении через CLI или CMS. Рабочий процесс переводчиков не меняется.
+
+</Question>
+
+</FAQ>
 
 ## Связанные сравнения
 
-- [i18next vs Intlayer](https://intlayer.org/ru/blog/i18next-vs-intlayer) (тот же benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/ru/blog/lingui-vs-intlayer) (тот же benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/ru/blog/vue-i18n-vs-intlayer-benchmark) (тот же benchmark)
+Тот же бенчмарк, другие библиотеки:
+
+- [i18next vs Intlayer](https://intlayer.org/ru/blog/i18next-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)
+
+Подробнее о next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/ru/blog/next-intl-vs-intlayer-next-intl), адаптер измерен на том же приложении
 - [Is next-intl outdated?](https://intlayer.org/ru/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/ru/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/ru/blog/nextjs-internationalization-using-next-intl)
+
+Справочная документация:
+
+- [Отчет о бенчмарке Next.js](https://intlayer.org/ru/doc/benchmark/nextjs) и [отчет о бенчмарке TanStack Start](https://intlayer.org/ru/doc/benchmark/tanstack)
+- [Адаптер совместимости: next-intl](https://intlayer.org/ru/doc/compatibility/next-intl) и [руководство по миграции](https://intlayer.org/ru/doc/migration/next-intl)
+- [Оптимизация бандла](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 STARs