@intlayer/docs 9.5.5 → 9.5.7

package/blog/uk/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 @@ Intlayer не потребує окремого варіанту "scoped": ко
 
 ### Результати на Next.js (`next-i18next`)
 
+Виберіть метрики та бібліотеки, які вас цікавлять:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Бібліотека                         | Стратегія      | Вага Lib (gz) | Сер. JS сторінки (gz) | Витік мов | Витік сторінок | Сер. вага комп. (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 @@ Intlayer не потребує окремого варіанту "scoped": ко
 - **Розмір компонентів**: компонент із викликом `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/uk/doc/benchmark/nextjs).
+
 ### Результати на TanStack Start (`react-i18next`)
 
 Той самий додаток на TanStack Start із чистим `react-i18next` для виключення специфіки Next.js:
@@ -141,8 +156,19 @@ Intlayer не потребує окремого варіанту "scoped": ко
 - Режим `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/uk/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 році як середовище виконання: єдиний глобальний об'єкт містить базу ресурсів, плагіни доповнюють його, а функція `t()` шукає ключі під час рендерингу. Це забезпечує високу гнучкість, але призводить до відчутного навантаження:
 
 ```bash
@@ -166,7 +192,13 @@ Intlayer не потребує окремого варіанту "scoped": ко
                 └── 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 = () => {
 
 > Сторінка, на якій відображається цей компонент, зобов'язана підвантажити namespace `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>
+
 ### Синхронний серверний компонент (RSC)
 
-**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>`, форми множини та суфікси контексту продовжують працювати, транслюючись зі словників, скомпільованих Intlayer.
@@ -415,18 +462,85 @@ export default defineConfig({
 
 ## Що і коли обирати?
 
-- **Обирайте i18next**: якщо вам критично необхідна його екосистема плагінів (специфічні детектори, кастомні бекенди, ICU, Locize), ви реалізуєте переклад поза React (сервіси Node, чистий JS, інші фреймворки), команда вже має значний досвід, або зовнішня платформа вимагає структури `locales/{lng}/{ns}.json`. Але виділіть ресурси на підтримку просторів імен та маршрутів, якщо швидкість має значення.
-- **Обирайте Intlayer**: якщо вам потрібні **контент у структурі компонентів**, **сувора типізація TypeScript**, **виявлення пропущених перекладів під час збірки**, **автоматичний tree-shaking та ліниве завантаження без зусиль**, миттєва зміна мови, синхронні серверні компоненти та вбудовані інструменти (візуальний редактор, 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/uk/doc/concept/editor), [CMS](https://intlayer.org/uk/doc/concept/cms), [ШІ-переклад](https://intlayer.org/uk/doc/concept/auto-fill), [MCP-сервер](https://intlayer.org/uk/doc/mcp-server)). Особливо актуально для великих модульних кодових баз та дизайн-систем.
+
+</Accordion>
+<Accordion header="Обрати адаптери @intlayer/*-i18next">
+
+Ви вже використовуєте i18next і хочете отримати переваги у розмірі бандла та реактивності без переписування компонентів. Ваші файли `locales/{lng}/{ns}.json` залишаються джерелом істини. Виміряно пліч-о-пліч у [i18next проти @intlayer/i18next](https://intlayer.org/uk/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ (Часті запитання)
+
+<FAQ>
+
+<Question title="Чому i18next набагато важчий за інші бібліотеки?">
+
+Він створювався як агностичний до фреймворків рантайм: глобальний екземпляр, конвеєр плагінів, сховище ресурсів, резолвер ключів. Ця гнучкість компілюється в кожен бандл. Порожній компонент, який імпортує лише бібліотеку, коштує **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** більше, ніж 141.3 KB в Intlayer, який не вимагав жодного налаштування. Див. [оптимізацію бандла](https://intlayer.org/uk/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/uk/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Що відбувається з моїми плагінами i18next?">
+
+Бекенди та детектори мови приймаються, але залишаються пасивними: у рантаймі більше нічого завантажувати або визначати. Визначення мови стає конфігурацією маршрутизації Intlayer (префікс URL, cookie, заголовок). Якщо ваш додаток отримує переклади з CMS під час запиту, використовуйте [Intlayer CMS](https://intlayer.org/uk/doc/concept/cms) або команди `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Схожі порівняння
 
-- [next-intl проти Intlayer](https://intlayer.org/uk/blog/next-intl-vs-intlayer) (той самий бенчмарк)
-- [Lingui проти Intlayer](https://intlayer.org/uk/blog/lingui-vs-intlayer) (той самий бенчмарк)
-- [vue-i18n проти Intlayer: бенчмарк](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-benchmark) (той самий бенчмарк)
-- [next-i18next проти next-intl та Intlayer](https://intlayer.org/uk/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [react-i18next проти react-intl та Intlayer](https://intlayer.org/uk/blog/react-i18next-vs-react-intl-vs-intlayer)
+Той самий бенчмарк, інші бібліотеки:
+
+- [next-intl vs Intlayer](https://intlayer.org/uk/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/uk/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/uk/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/uk/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Докладніше про i18next:
+
+- [i18next проти @intlayer/i18next](https://intlayer.org/uk/blog/i18next-vs-intlayer-i18next), адаптери виміряні на одному додатку
 - [Чи застарів i18next?](https://intlayer.org/uk/blog/is-i18next-outdated)
+- [Використання Intlayer з i18next](https://intlayer.org/uk/blog/intlayer-with-i18next) та [з react-i18next](https://intlayer.org/uk/blog/intlayer-with-react-i18next)
+- [Як інтернаціоналізувати додаток Next.js за допомогою next-i18next](https://intlayer.org/uk/blog/nextjs-internationalization-using-next-i18next)
+
+Довідкова документація:
+
+- [Звіт про бенчмарк Next.js](https://intlayer.org/uk/doc/benchmark/nextjs) та [звіт про бенчмарк TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack)
+- Адаптери сумісності: [i18next](https://intlayer.org/uk/doc/compatibility/i18next), [react-i18next](https://intlayer.org/uk/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/uk/doc/compatibility/next-i18next)
+- Посібники з міграції: [i18next](https://intlayer.org/uk/doc/migration/i18next), [react-i18next](https://intlayer.org/uk/doc/migration/react-i18next), [next-i18next](https://intlayer.org/uk/doc/migration/next-i18next)
+- [Оптимізація бандла](https://intlayer.org/uk/doc/concept/bundle-optimization) та [компілятор Intlayer](https://intlayer.org/uk/doc/compiler)
+- [Компонентна i18n проти централізованої](https://intlayer.org/uk/blog/per-component-vs-centralized-i18n)
+- [Компіляторна i18n проти декларативної](https://intlayer.org/uk/blog/compiler-vs-declarative-i18n)
 
 ## Зірки на GitHub
 

package/blog/uk/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: "Дві бібліотеки i18n на основі компілятора протестовані на 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 - це дві бібліотеки в цьому бенчмарку, які покладаються на **компілятор**, а не на чистий runtime. Lingui витягує повідомлення з макросів під час збирання та компілює каталоги для кожної локалі. Intlayer компілює словники для кожного компонента та виконує tree-shaking для кожної локалі. У теорії вони мають бути близькими. Числа показують, де вони розходяться.
 
 Дані отримані з [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), відкритого набору тестів, який створює однаковий додаток з кожною бібліотекою та фіксує, що браузер насправді завантажує та виконує.
@@ -96,6 +98,10 @@ Intlayer не має варіанта "scoped": компілятор автом
 
 ### Результати на Next.js
 
+Виберіть метрики та бібліотеки, які вас цікавлять:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Бібліотека          | Стратегія      | Розмір Lib (gz) | Сер. JS сторінки (gz) | Витік локалі | Витік сторінки | Сер. компонента (gz) | Реактивність E2E | Гідратація |
 | ------------------- | -------------- | --------------: | --------------------: | -----------: | -------------: | -------------------: | ---------------: | ---------: |
 | **base** (без i18n) | -              |          0.0 KB |              141.0 KB |         0.0% |           0.0% |               0.9 KB |          13.4 ms |    11.8 ms |
@@ -114,6 +120,15 @@ Intlayer не має варіанта "scoped": компілятор автом
 - **Витік резервної мови (fallback).** Навіть в оптимізованих конфігураціях **3-15% рядків `en` потрапляють на сторінки `fr`**. Макроси Lingui зберігають початкове повідомлення як fallback, через що воно потрапляє у бандл поруч із перекладом. 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/uk/doc/benchmark/nextjs).
+
 ### Результати на TanStack Start
 
 | Бібліотека                   | Стратегія      | Розмір Lib (gz) | Сер. JS сторінки (gz) | Витік локалі | Витік сторінки | Сер. компонента (gz) | Реактивність E2E | Гідратація |
@@ -135,8 +150,19 @@ Intlayer не має варіанта "scoped": компілятор автом
 - **Рядок `static` в Intlayer вже має 0% витоку сторінки**, оскільки до бандла потрапляють лише словники, імпортовані компонентами поточної сторінки. Один рядок конфігурації (`importMode: 'dynamic'`) повністю прибирає і витік локалі.
 - **`@intlayer/lingui`** зберігає синтаксис макросів Lingui та обслуговує їх зі словників Intlayer. Це дещо збільшує розмір сторінки (137 КБ через наявність runtime макросів) заради зменшення розміру компонентів (12.8 КБ) та швидшої гідратації, ніж у нативному Lingui. Це чудовий крок для поступової міграції.
 
+<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/uk/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 @@ Intlayer не має варіанта "scoped": компілятор автом
             └── 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/uk/doc/concept/bundle-optimization).
 
@@ -184,7 +212,8 @@ Intlayer не має варіанта "scoped": компілятор автом
 
 ### Налаштування
 
-**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>`. Жодних кроків extract чи compile: словники створюються автоматично під час роботи бандлера.
 
+</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`. Якщо забути виконати цю команду або `compile`, застосунок непомітно повернеться до англійського тексту.
 
-**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>
 ### За межами компонентів
 
 Метадані, завантажувачі (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, а ваша команда звикла керувати процесом вилучення, компіляції та розділення каталогів. Розмір JS на сторінку дуже конкурентний після налаштування лінивого завантаження.
-- **Обирайте 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/uk/doc/concept/editor), [CMS](https://intlayer.org/uk/doc/concept/cms), [переклад через ШІ](https://intlayer.org/uk/doc/concept/auto-fill), [сервер MCP](https://intlayer.org/uk/doc/mcp-server)). Особливо актуально для великих модульних кодових баз і дизайн-систем.
+
+</Accordion>
+<Accordion header="Обрати @intlayer/lingui">
+
+Ви вже використовуєте Lingui і хочете поступово перейти на словники Intlayer, не змінюючи макроси. Ваші каталоги `.po` залишаються джерелом правди завдяки [плагіну синхронізації PO](https://intlayer.org/uk/doc/compatibility/lingui). Виміряно поруч у [Lingui vs @intlayer/lingui](https://intlayer.org/uk/blog/lingui-vs-intlayer-lingui).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Lingui також компілює. Чому результат настільки відрізняється?">
+
+Тому що одиниця компіляції відрізняється. Lingui компілює **один каталог на мову**: все інше (каталоги на маршрут, lazy loading, виключення резервного варіанту з бандла) вимагає налаштування. Intlayer компілює **один словник на компонент**, тому ізоляція за маршрутами виникає автоматично під час збирання. Ось чому окремо скомпільований компонент Lingui важить 58-153 KB проти 6-8 KB в Intlayer.
+
+</Question>
+
+<Question title="Чому витік локалей ніколи не досягає 0% з Lingui?">
+
+Макроси зберігають вихідне повідомлення доступним у рантаймі як резервний варіант (fallback), тому англійський рядок відправляється поруч із перекладом. Бенчмарк фіксує **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/uk/doc/compatibility/lingui).
+
+</Question>
+
+<Question title="Що щодо кроків вилучення та компіляції?">
+
+Вони залишаються для макросів і зникають для власного контенту Intlayer. Словники `.content.ts` створюються під час роботи бандлера без окремого виклику CLI, а [`intlayer test`](https://intlayer.org/uk/doc/concept/cli) зупиняє CI у разі відсутності ключа замість непомітного відкату до вихідного рядка.
+
+</Question>
+
+</FAQ>
 
 ## Схожі порівняння
 
-- [next-intl проти Intlayer](https://intlayer.org/uk/blog/next-intl-vs-intlayer) (той самий бенчмарк)
-- [i18next проти Intlayer](https://intlayer.org/uk/blog/i18next-vs-intlayer) (той самий бенчмарк)
-- [Бенчмарк vue-i18n проти Intlayer](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-benchmark) (той самий бенчмарк)
-- [Компілятор проти декларативного i18n](https://intlayer.org/uk/blog/compiler-vs-declarative-i18n)
+Той самий бенчмарк, інші бібліотеки:
+
+- [next-intl vs Intlayer](https://intlayer.org/uk/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/uk/blog/i18next-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/uk/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/uk/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Докладніше:
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/uk/blog/lingui-vs-intlayer-lingui), адаптер виміряно на тому ж застосунку
+- [Compiler-driven vs declarative i18n](https://intlayer.org/uk/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/uk/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/uk/blog/icu-message-format)
+
+Довідкова документація:
+
+- [Звіт про бенчмарк Next.js](https://intlayer.org/uk/doc/benchmark/nextjs) та [звіт про бенчмарк TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack)
+- [Compat adapter: Lingui](https://intlayer.org/uk/doc/compatibility/lingui)
+- [Оптимізація бандла](https://intlayer.org/uk/doc/concept/bundle-optimization) та [компілятор Intlayer](https://intlayer.org/uk/doc/compiler)
 
 ## Зірки GitHub