@intlayer/docs 9.5.6 → 9.5.7

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/lingui_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "Lingui против Intlayer: бенчмарк и сравнение 2026"
 description: "Две библиотеки интернационализации на базе компилятора, протестированные на Next.js и TanStack Start. Размер бандла, утечка контента, размер компонентов, гидратация, отзывчивость при смене языка и опыт разработки."
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # Lingui против Intlayer | Бенчмарк интернационализации (i18n) для React и Next.js
 
+![JavaScript i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Lingui и Intlayer - единственные две библиотеки в этом сравнительном исследовании, которые опираются на **компилятор**, а не на обычный рантайм. Lingui извлекает сообщения из макросов во время сборки и компилирует каталоги под каждую локаль. Intlayer компилирует словари на уровне компонентов и применяет tree-shaking отдельно для каждого языка. В теории их показатели должны быть близки. Цифры показывают, в чем они существенно расходятся.
 
 Данные получены с помощью [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) - открытого набора тестов, который собирает одно и то же приложение с каждой библиотекой и замеряет то, что браузер реально скачивает и исполняет.
@@ -96,6 +98,10 @@ Lingui и Intlayer - единственные две библиотеки в э
 
 ### Результаты на Next.js
 
+Выберите интересующие вас метрики и библиотеки:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Библиотека          | Стратегия      | Lib size (gz) | Page JS ср. (gz) | Утечка языка | Утечка страниц | Компонент ср. (gz) | E2E-реактивность | Гидратация |
 | ------------------- | -------------- | ------------: | ---------------: | -----------: | -------------: | -----------------: | ---------------: | ---------: |
 | **база** (без i18n) | -              |        0,0 КБ |         141,0 КБ |         0,0% |           0,0% |             0,9 КБ |          13,4 мс |    11,8 мс |
@@ -114,6 +120,15 @@ Lingui и Intlayer - единственные две библиотеки в э
 - **Утечка оригинального текста.** Даже в наиболее продуманных схемах **от 3% до 15% английских строк попадают на страницы на французском языке**. Макросы Lingui встраивают исходную строку для подстраховки в итоговый бандл. Intlayer разрешает фолбеки на этапе сборки и доставляет клиенту только целевой язык.
 - **Взрывной рост размера компонентов в `scoped-dynamic`.** Каждый изолированный компонент весит в среднем **152,6 КБ**, поскольку через цепочку импортов в него попадают каталоги других маршрутов. Тот же компонент на `useIntlayer()` занимает всего **6,9 КБ**.
 
+<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
 
 | Библиотека                   | Стратегия      | Lib size (gz) | Page JS ср. (gz) | Утечка языка | Утечка страниц | Компонент ср. (gz) | E2E-реактивность | Гидратация |
@@ -135,8 +150,19 @@ Lingui и Intlayer - единственные две библиотеки в э
 - **Строка `static` у Intlayer сразу обеспечивает 0% утечки страниц**, так как в бандл включаются исключительно словари, импортированные задействованными на странице компонентами. А параметр `importMode: 'dynamic'` устраняет и языковую утечку.
 - **`@intlayer/lingui`** сохраняет синтаксис макросов Lingui, связывая их со словарями Intlayer. Это решение жертвует небольшим объемом на страницу (137 КБ из-за присутствия макро-рантайма), взамен давая облегченные компоненты (12,8 КБ) и быструю гидратацию. Прекрасный вариант для плавного перехода.
 
+<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)
+
 Обе библиотеки компилируют код, но принципиально отличается **объект компиляции**.
 
 **Lingui компилирует каталоги.** Макросы в коде извлекаются в единый файл `.po` на язык, а затем компилируются в модуль JS на язык. Главная единица деления - **локаль**. Чтобы разделить данные глубже (по маршрутам или компонентам), вам придется заводить отдельные каталоги, прописывать правила в `lingui.config.ts` и вручную настраивать их загрузку. Экземпляр `I18n` глобален, и каждый `useLingui()` подключает компонент ко всему его содержимому.
@@ -176,7 +202,9 @@ Lingui и Intlayer - единственные две библиотеки в э
             └── about.content.ts
 ```
 
-Именно поэтому архитектура `scoped-dynamic` формируется в Intlayer автоматически на этапе сборки, тогда как в Lingui это требует масштабной ручной настройки.
+Именно поэтому архитектура `scoped-dynamic` формируется в Intlayer автоматически на этапе сборки, тогда как в Lingui это требует масштабной ручной настройки. Разрыв увеличивается сразу по двум осям, страницы и локали:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 > Чтобы повторить показатели строки `dynamic`, активируйте `dictionary.importMode: 'dynamic'` в `intlayer.config.ts`. Подробнее в [документации по оптимизации бандла](https://intlayer.org/ru/doc/concept/bundle-optimization).
 
@@ -184,7 +212,8 @@ Lingui и Intlayer - единственные две библиотеки в э
 
 ### Настройка
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="lingui.config.ts"
 import { defineConfig } from "@lingui/cli";
@@ -215,7 +244,8 @@ export const loadCatalog = async (locale: string) => {
 
 Затем в сборщик добавляется плагин `@lingui/babel-plugin-lingui-macro` (или `@lingui/swc-plugin`), после правок выполняется `lingui extract`, перед сборкой - `lingui compile`, а приложение оборачивается в `<I18nProvider i18n={i18n}>`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -232,9 +262,12 @@ export default config;
 
 Добавьте плагин `intlayer()` в `vite.config.ts` (или `withIntlayer()` в `next.config.ts`) и оберните дерево компонентов в `<IntlayerProvider>`. Никаких ручных команд извлечения или сборки: словари компилируются автоматически бандлером.
 
+</Tab>
+</Tabs>
 ### Компоненты
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```tsx fileName="src/components/Counter.tsx"
 import { useState } from "react";
@@ -258,7 +291,8 @@ export const Counter = () => {
 
 Английский текст пишется прямо в компоненте; перевод на французский хранится в `src/locales/fr/messages.po` под сгенерированным хеш-идентификатором после выполнения `lingui extract`. Если забыть запустить команду извлечения или сборки, на экране незаметно останется английский текст.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -297,11 +331,14 @@ export const Counter = () => {
 
 Оба языка находятся в одном файле рядом с компонентом. Отсутствие перевода для `fr` приведет к ошибке сборщика, а опечатка в имени ключа будет немедленно подсвечена TypeScript.
 
+</Tab>
+</Tabs>
 ### Вне компонентов React
 
 Метаданные, функции загрузки данных (loaders), серверные функции: в любом контексте без дерева React.
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { setupI18n } from "@lingui/core";
@@ -324,7 +361,8 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 
 Создание нового экземпляра `I18n` на каждый вызов, ручной импорт конкретного каталога и использование `msg` + `i18n._()` вместо привычного `t`. Как отмечается в [примечаниях к бенчмарку](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md), постоянный выбор между `t`, `` t` ` ``, `i18n.t()`, `msg` или `<Trans>` часто сбивает с толку.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { getIntlayer } from "intlayer";
@@ -336,6 +374,9 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Использование макросов Lingui со словарями Intlayer
 
 `@intlayer/lingui` работает как прозрачный адаптер для `@lingui/core` и `@lingui/react`. Макросы компилируются в прежнем режиме; генерируемые вызовы `i18n._()` берут данные из словарей Intlayer, а плагины синхронизации сохраняют файлы `.po` в качестве источника данных. Формы множественного числа и условия ICU отображаются абсолютно идентично.
@@ -353,16 +394,82 @@ export default defineConfig({
 
 ## Что выбрать для вашего проекта?
 
-- **Выбирайте Lingui**, если вам необходим синтаксис **ICU MessageFormat** с типизированными макросами, переводчики работают через файлы **`.po`** в сформированном процессе TMS, вам удобнее писать текст прямо в JSX, а команда готова поддерживать процесс извлечения, сборки и деления каталогов. При правильной настройке ленивой загрузки размер итоговой страницы крайне конкурентен.
-- **Выбирайте Intlayer**, если вам нужны **изолированный контент на уровне компонентов**, **строгая типизация TypeScript**, **контроль отсутствующих ключей на этапе сборки**, **автоматический tree-shaking и ленивая загрузка без конфигурации**, легковесные компоненты, мгновенная смена локалей и встроенные инструменты редактирования (Визуальный редактор, CMS, перевод через ИИ, сервер MCP). Идеально подходит для модульных систем и дизайн-систем.
-- **Выбирайте `@intlayer/lingui`**, если у вас уже есть кодовая база на Lingui и вы хотите постепенно перейти на архитектуру словарей Intlayer, не переписывая макросы.
+<AccordionGroup>
+<Accordion header="Выбрать Lingui">
+
+Вам нужен **ICU MessageFormat** с типизированными макросами, ваши переводчики работают в **`.po`** с существующим пайплайном TMS, вы предпочитаете исходные строки инлайн в JSX, и вашей команде удобно управлять извлечением, компиляцией и разделением каталогов. Его JS на страницу вполне конкурентоспособен после настройки lazy loading.
+
+</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/lingui">
+
+Вы уже используете Lingui и хотите постепенно перейти на словари Intlayer, не трогая макросы. Ваши каталоги `.po` остаются источником истины благодаря [плагину синхронизации PO](https://intlayer.org/ru/doc/compatibility/lingui). Измерено бок о бок в [Lingui vs @intlayer/lingui](https://intlayer.org/ru/blog/lingui-vs-intlayer-lingui).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Lingui тоже компилирует. Почему результат настолько разный?">
+
+Потому что единица компиляции различается. Lingui компилирует **один каталог на локаль**: всё, что ниже этого (каталоги по маршрутам, lazy loading, исключение fallback из бандла), требует ручной конфигурации. Intlayer компилирует **один словарь на компонент**, поэтому разделение по маршрутам происходит автоматически во время сборки. Вот почему изолированно скомпилированный компонент Lingui весит 58-153 KB против 6-8 KB у Intlayer.
+
+</Question>
+
+<Question title="Почему утечка локалей никогда не достигает 0% с Lingui?">
+
+Макросы сохраняют исходное сообщение доступным в рантайме в качестве фоллбэка, поэтому английская строка отправляется вместе с переводом. Бенчмарк фиксирует **3-15% строк `en` внутри страниц `fr`** в каждой оптимизированной конфигурации. Intlayer разрешает фоллбэки во время сборки и отправляет только активную локаль.
+
+</Question>
+
+<Question title="Действительно ли JavaScript на страницу у Lingui конкурентоспособен?">
+
+Да, а на TanStack Start он даже чуть впереди: 115.2 KB в режиме `dynamic` против 118.6 KB у Intlayer. Скомпилированные каталоги с хэшированными ID компактны. Однако цена проявляется в других аспектах: гидратация за 28-34 мс против 11-14 мс и переключение локали за **42 мс** в конфигурации `scoped-dynamic`.
+
+</Question>
+
+<Question title="Нужно ли отказываться от макросов для миграции?">
+
+Нет. `@intlayer/lingui` сохраняет компиляцию `` t`...` ``, `<Trans>`, `msg`, `plural`, `select` и `selectOrdinal` как раньше; меняется только то, относительно чего резолвит `i18n._()`. Сохраните `@lingui/babel-plugin-lingui-macro` или `@lingui/swc-plugin` в сборке. См. [документацию по совместимости с Lingui](https://intlayer.org/ru/doc/compatibility/lingui).
+
+</Question>
+
+<Question title="Что насчет этапов извлечения и компиляции?">
+
+Они остаются для макросов и исчезают для собственного контента Intlayer. Словари `.content.ts` собираются при запуске бандлера без отдельного шага CLI, а [`intlayer test`](https://intlayer.org/ru/doc/concept/cli) прерывает CI при отсутствии ключа вместо тихого отката к исходной строке.
+
+</Question>
+
+</FAQ>
 
 ## Похожие сравнения
 
-- [next-intl против Intlayer](https://intlayer.org/ru/blog/next-intl-vs-intlayer) (в рамках того же бенчмарка)
-- [i18next против Intlayer](https://intlayer.org/ru/blog/i18next-vs-intlayer) (в рамках того же бенчмарка)
-- [vue-i18n против Intlayer](https://intlayer.org/ru/blog/vue-i18n-vs-intlayer-benchmark) (в рамках того же бенчмарка)
-- [Компилятор против декларативной i18n](https://intlayer.org/ru/blog/compiler-vs-declarative-i18n)
+Тот же бенчмарк, другие библиотеки:
+
+- [next-intl vs Intlayer](https://intlayer.org/ru/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/ru/blog/i18next-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)
+
+Подробнее:
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/ru/blog/lingui-vs-intlayer-lingui), адаптер измерен на том же приложении
+- [Compiler-driven vs declarative i18n](https://intlayer.org/ru/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/ru/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/ru/blog/icu-message-format)
+
+Справочная документация:
+
+- [Отчет о бенчмарке Next.js](https://intlayer.org/ru/doc/benchmark/nextjs) и [отчет о бенчмарке TanStack Start](https://intlayer.org/ru/doc/benchmark/tanstack)
+- [Compat adapter: Lingui](https://intlayer.org/ru/doc/compatibility/lingui)
+- [Оптимизация бандла](https://intlayer.org/ru/doc/concept/bundle-optimization) и [компилятор Intlayer](https://intlayer.org/ru/doc/compiler)
 
 ## Звезды на GitHub