@intlayer/docs 9.5.6 → 9.5.8

package/blog/uk/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl проти Intlayer: Бенчмарк та порівняння 2026"
 description: "Детальне порівняння next-intl та Intlayer у Next.js App Router і TanStack Start. Розмір бандла, витік контенту, розмір компонентів, гідратація та досвід розробника."
 keywords:
@@ -22,11 +22,11 @@ author: aymericzip
 
 # next-intl проти Intlayer | Бенчмарк інтернаціоналізації (i18n) у React та Next.js
 
-`next-intl` на сьогодні є стандартним вибором для i18n у Next.js App Router: тісна інтеграція з маршрутизацією, повна підтримка ICU MessageFormat та звичний досвід розробника для всіх, хто працював із класичними системами i18n.
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
 
-`Intlayer` повністю переосмислює цей підхід: жодних централізованих словників, жодної потреби вручну прив'язувати простори імен (namespaces) до маршрутів. Контент оголошується безпосередньо поруч із кожним компонентом, а компілятор часу збирання пакує лише те, що дійсно потрібно кожній окремій сторінці.
+`next-intl` є найпопулярнішою бібліотекою i18n для Next.js. Intlayer, це альтернатива на основі компілятора з областю видимості на рівні компонентів. Обидва рішення локалізують застосунок App Router. Питання полягає в тому, скільки коштує кожне з них після збирання проєкту.
 
-У цій статті порівнюються дві бібліотеки на основі даних із [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), відкритого набору тестів, який збирає однаковий додаток з кожною бібліотекою та фіксує те, що браузер насправді завантажує і виконує.
+Ця стаття не є посібником. Це порівняння, підтверджене даними з [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), відкритого набору бенчмарків, який створює однаковий застосунок із кожною бібліотекою та вимірює те, що браузер фактично завантажує та виконує.
 
 <TOC/>
 
@@ -89,6 +89,10 @@ Intlayer не має варіанта "scoped": компілятор автом
 
 ### Результати на Next.js (App Router)
 
+Виберіть метрики та бібліотеки, які вас цікавлять:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Бібліотека                      | Стратегія      | Розмір Lib (gz) | Сер. JS сторінки (gz) | Витік локалі | Витік сторінки | Сер. компонента (gz) | Реактивність E2E | Гідратація |
 | ------------------------------- | -------------- | --------------: | --------------------: | -----------: | -------------: | -------------------: | ---------------: | ---------: |
 | **Базовий додаток** (без i18n)  | -              |          0.0 KB |              141.0 KB |         0.0% |           0.0% |               0.9 KB |          13.4 ms |    11.8 ms |
@@ -107,8 +111,19 @@ Intlayer не має варіанта "scoped": компілятор автом
 - **Витік контенту.** У найпоширеніших конфігураціях (`static` та `dynamic`) `next-intl` відправляє на кожну сторінку **~90% рядків з інших сторінок**, оскільки весь файл `en.json` потрапляє до клієнтського провайдера. Щоб зменшити цей показник до 0%, потрібен складний ручний поділ на простори імен, тоді як в Intlayer це працює за замовчуванням.
 - **Розмір компонента.** Компонент із `useTranslations()` важить у середньому 21.8 КБ; той самий компонент з `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 (`use-intl`)
 
+`use-intl`, це незалежне від фреймворку ядро `next-intl`. Той самий API, той самий формат повідомлень. Порівняння його з `intlayer` на TanStack Start усуває особливості Next.js із рівняння.
+
 | Бібліотека                     | Стратегія      | Розмір Lib (gz) | Сер. JS сторінки (gz) | Витік локалі | Витік сторінки | Сер. компонента (gz) | Реактивність E2E |
 | ------------------------------ | -------------- | --------------: | --------------------: | -----------: | -------------: | -------------------: | ---------------: |
 | **Базовий додаток** (без i18n) | -              |          0.0 KB |              111.0 KB |         0.0% |           0.0% |               0.7 KB |           8.1 ms |
@@ -127,8 +142,19 @@ Intlayer не має варіанта "scoped": компілятор автом
 - Архітектурна різниця особливо помітна у **розмірі компонентів**: 76-87 КБ у `use-intl` проти 6-8 КБ в Intlayer.
 - **Перемикання локалі** відбувається у 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/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)
+
 `next-intl` слідує класичній моделі: один JSON для кожної мови, завантажується в `getRequestConfig`, передається в `NextIntlClientProvider` і зчитується через `t("namespace.key")`.
 
 ```bash
@@ -150,6 +176,10 @@ Intlayer не має варіанта "scoped": компілятор автом
 
 Runtime не може передбачити, які саме ключі знадобляться сторінці, тому відправка всього каталогу є єдиним безпечним варіантом.
 
+Ціна недосягнення цієї мети зростає відразу по двох осях, сторінки та локалі:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer змінює цей підхід. Контент декларується безпосередньо поруч із компонентом:
 
 ```bash
@@ -177,7 +207,8 @@ Intlayer змінює цей підхід. Контент декларуєтьс
 
 ### Клієнтський компонент
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -188,7 +219,7 @@ Intlayer змінює цей підхід. Контент декларуєтьс
 }
 ```
 
-```tsx fileName="src/components/Counter.tsx"
+```tsx fileName="src/components/ClientCounter.tsx"
 "use client";
 
 import { useState } from "react";
@@ -210,7 +241,10 @@ export const Counter = () => {
 };
 ```
 
-**Intlayer**
+> Не забудьте включити простір імен `counter` у повідомлення, що передаються до `NextIntlClientProvider` на кожній сторінці, яка рендерить цей компонент.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -249,11 +283,16 @@ export const Counter = () => {
 };
 ```
 
+На сторінці нічого не потрібно реєструвати: компонент приносить власний вміст.
+
+</Tab>
+</Tabs>
 ### Синхронні серверні компоненти
 
 Елементи дизайн-системи (навігаційні панелі, підвали, картки) часто є серверними компонентами, що відображаються всередині клієнтських компонентів, тому вони не можуть бути `async`.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -269,7 +308,10 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 );
 ```
 
-**Intlayer**
+Сторінка повинна виконати `await getTranslations("counter")` та `await getFormatter()`, а потім передати результати як пропси. Компонент більше не є автономним.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -288,9 +330,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";
@@ -323,7 +368,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";
@@ -347,6 +393,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Збережіть API next-intl, отримайте оптимізований вихід Intlayer
 
 Вам не потрібно переписувати компоненти, щоб отримати наведені вище результати продуктивності. Пакет `@intlayer/next-intl` є сумісним адаптером: він зберігає `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()` та множинні форми ICU, обслуговуючи їх зі словників, скомпільованих компілятором Intlayer.
@@ -368,17 +417,84 @@ export default withIntlayer(nextConfig);
 
 ## Що і коли обрати?
 
-- **Обирайте next-intl**, якщо вам потрібен стандарт спільноти Next.js, ви повністю спираєтесь на ICU MessageFormat, ваш проєкт невеликий або середній, або ви використовуєте платформи перекладу з централізованими JSON (Crowdin, Phrase, Lokalise...).
-- **Обирайте Intlayer**, якщо вам потрібен **контент з прив'язкою до компонентів**, **суворий TypeScript**, **помилки про відсутні ключі під час збирання**, **автоматичний tree-shaking та ліниве завантаження**, синхронні серверні компоненти та вбудовані інструменти редагування (Візуальний редактор, CMS, переклад за допомогою ШІ, сервер MCP).
-- **Обирайте `@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/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/next-intl">
+
+Ви вже використовуєте `next-intl` і хочете отримати переваги в розмірі бандла без повного переписування. [Адаптер сумісності](https://intlayer.org/uk/doc/compatibility/next-intl) зберігає ваші імпорти та файл `messages/{locale}.json` як єдине джерело правди. Порівняно пліч-о-пліч у [next-intl проти @intlayer/next-intl](https://intlayer.org/uk/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/uk/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Чи потрібно переписувати компоненти для міграції?">
+
+Ні. `@intlayer/next-intl` зберігає `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, множинні форми ICU та помічники навігації, надаючи їх зі скомпільованих словників. Лише один рядок плагіна в `next.config.ts`. Покроково в [посібнику з міграції next-intl](https://intlayer.org/uk/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/uk/blog/icu-message-format).
+
+</Question>
+
+<Question title="Чи можу я зберегти файли messages/{locale}.json?">
+
+Так. [Плагін синхронізації JSON](https://intlayer.org/uk/doc/compatibility/next-intl) читає їх, розбиває ключі верхнього рівня на словники та перезаписує переклади в ті самі файли під час оновлення через CLI або CMS. Робочий процес ваших перекладачів не змінюється.
+
+</Question>
+
+</FAQ>
 
 ## Схожі порівняння
 
-- [i18next проти Intlayer](https://intlayer.org/uk/blog/i18next-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)
-- [Чи застарів next-intl?](https://intlayer.org/uk/blog/is-next-intl-outdated)
+Той самий бенчмарк, інші бібліотеки:
+
+- [i18next vs Intlayer](https://intlayer.org/uk/blog/i18next-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)
+
+Більше про next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/uk/blog/next-intl-vs-intlayer-next-intl), адаптер виміряно на тому ж додатку
+- [Is next-intl outdated?](https://intlayer.org/uk/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/uk/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/uk/blog/nextjs-internationalization-using-next-intl)
+
+Довідкова документація:
+
+- [Звіт бенчмарку Next.js](https://intlayer.org/uk/doc/benchmark/nextjs) та [звіт бенчмарку TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack)
+- [Адаптер сумісності: next-intl](https://intlayer.org/uk/doc/compatibility/next-intl) та [посібник з міграції](https://intlayer.org/uk/doc/migration/next-intl)
+- [Оптимізація бандла](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/vue-i18n_vs_intlayer-vue-i18n.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "vue-i18n vs @intlayer/vue-i18n: Однаковий API, різний Bundle"
 description: Що змінюється, коли Vue 3 додаток зберігає свої виклики vue-i18n, але обслуговує їх через адаптер сумісності @intlayer/vue-i18n. JavaScript на сторінку, розмір runtime, розмір компонента та витоку вимірюються на тому самому коді Vite + Vue, плюс те, що адаптер зберігає, ігнорує та не може замінити.
 keywords:
@@ -25,17 +25,19 @@ author: aymericzip
 
 # vue-i18n VS @intlayer/vue-i18n | Однаковий API, різний Bundle
 
-`@intlayer/vue-i18n` — це адаптер сумісності: він надає API `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) та обслуговує його зі словників, скомпільованих Intlayer. Ваші файли `.vue` не змінюються. Змінюється лише те, до чого прив'язаний `t("footer.github")`.
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
+`@intlayer/vue-i18n`, це адаптер сумісності: він надає API `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) та обслуговує його зі словників, скомпільованих Intlayer. Ваші файли `.vue` не змінюються. Змінюється лише те, до чого прив'язаний `t("footer.github")`.
 
 Ця стаття вимірює цей перехід на тій же програмі Vite + Vue 3, зібраній один раз з `vue-i18n` і один раз з адаптером. Цифри походять з [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Для порівняння `vue-i18n` та Intlayer як бібліотек прочитайте [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) та [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Ця стаття присвячена тому, які зміни адаптер вносить, коли ви зберігаєте компоненти такими, якими вони є.
 
 <TOC/>
 
-> **tl;dr**: На тому самому додатку Vite + Vue 3 заміна `vue-i18n` на `@intlayer/vue-i18n` зменшила JavaScript на сторінку з **134.9 KB до 47.0 KB** gzip (додаток без i18n важить 41.3 KB), runtime з **24.3 KB до 7.9 KB**, середній компонент з **196 KB до 8.4 KB** і витоком рядків іноземної сторінки з **90% до 0%**, без редагування жодного файлу `.vue`. `createI18n({ messages })` продовжує працювати як резервний варіант; видаліть імпорти JSON, щоб отримати наведені вище цифри. SFC блоки `<i18n>` та runtime `setLocaleMessage()` — це дві функції, які не переносяться.
+> **tl;dr**: На тому самому додатку Vite + Vue 3 заміна `vue-i18n` на `@intlayer/vue-i18n` зменшила JavaScript на сторінку з **134.9 KB до 47.0 KB** gzip (додаток без i18n важить 41.3 KB), runtime з **24.3 KB до 7.9 KB**, середній компонент з **196 KB до 8.4 KB** і витоком рядків іноземної сторінки з **90% до 0%**, без редагування жодного файлу `.vue`. `createI18n({ messages })` продовжує працювати як резервний варіант; видаліть імпорти JSON, щоб отримати наведені вище цифри. SFC блоки `<i18n>` та runtime `setLocaleMessage()`, це дві функції, які не переносяться.
 
 ## Що таке `@intlayer/vue-i18n`
 
-`vue-i18n` — це runtime. `createI18n({ messages: { en, fr, ... } })` будує глобальний екземпляр, який містить усі повідомлення кожної мови; `useI18n()` пов'язує кожний компонент з ним; `t("footer.github")` проходить деревом під час рендеру. Це дизайн робить можливими SFC блоки `<i18n>` та `setLocaleMessage()`, а також робить граф залежностей кожного компонента включеним у все дерево.
+`vue-i18n`, це runtime. `createI18n({ messages: { en, fr, ... } })` будує глобальний екземпляр, який містить усі повідомлення кожної мови; `useI18n()` пов'язує кожний компонент з ним; `t("footer.github")` проходить деревом під час рендеру. Це дизайн робить можливими SFC блоки `<i18n>` та `setLocaleMessage()`, а також робить граф залежностей кожного компонента включеним у все дерево.
 
 `@intlayer/vue-i18n` зберігає API та замінює дерево:
 
@@ -105,6 +107,10 @@ The [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) suite б
 
 ### Результати на Vite + Vue 3
 
+Виберіть метрики та бібліотеки, які вас цікавлять:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
 | Setup                    | Strategy | Lib size (gz) | Lib size (min) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |  Page load |
 | ------------------------ | -------- | ------------: | -------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ---------: |
 | **base** (no i18n)       | -        |        0.0 KB |         0.0 KB |          41.3 KB |        0.0% |         - |             1.1 KB |         1.8 ms |    10.8 ms |
@@ -117,18 +123,31 @@ The [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) suite б
 
 **Як це читати**
 
-- **88 KB менше на сторінку, ті ж компоненти.** `vue-i18n` бере програму 41.3 KB до **134.9 KB**. Адаптер збірка тих же компонентів приземляється на **47.0 KB**, 5.7 KB більше базової програми. Більшість різниці — це 74.9 KB з `src/locales`, яку `createI18n({ messages })` тягне на кожну сторінку, а адаптер ніколи не пакує як блок.
+- **88 KB менше на сторінку, ті ж компоненти.** `vue-i18n` бере програму 41.3 KB до **134.9 KB**. Адаптер збірка тих же компонентів приземляється на **47.0 KB**, 5.7 KB більше базової програми. Більшість різниці, це 74.9 KB з `src/locales`, яку `createI18n({ messages })` тягне на кожну сторінку, а адаптер ніколи не пакує як блок.
 - **Runtime зменшується в 3 рази.** Порожний компонент, який лише імпортує `vue-i18n`, коштує **24.3 KB gzip / 83.2 KB мініфіковано**: `@intlify/core-base`, компілятор повідомлень і runtime. Адаптер коштує **7.9 KB / 23.2 KB**, більшість з яких це core Intlayer плюс поверхня API `vue-i18n`.
 - **Компоненти: 23x менші.** Компонент `useI18n()`, скомпільований ізольовано, в середньому займає **196 KB**, тому що `t` пов'язана з екземпляром, який містить кожне повідомлення кожної локалізації. З адаптером той самий компонент в середньому займає **8.4 KB**: він досягає своїх власних словників.
-- **Витоку.** `vue-i18n` поставляє кожну локаль і рядки кожної сторінки на кожній сторінці: 50% витоку локалі (на двох відбитих локалях; з десятьма упакованими локалями реальні втрати вищі), 90% витоку сторінки. Адаптер знижує витік сторінки до **0%**, оскільки кожний компонент імпортує тільки свої словники. Витік локалі становить 15% у цьому запуску `static`; `importMode: 'dynamic'` — це параметр, який його видаляє, і ця конфігурація не була частиною цього запуску Vue.
+- **Витоку.** `vue-i18n` поставляє кожну локаль і рядки кожної сторінки на кожній сторінці: 50% витоку локалі (на двох відбитих локалях; з десятьма упакованими локалями реальні втрати вищі), 90% витоку сторінки. Адаптер знижує витік сторінки до **0%**, оскільки кожний компонент імпортує тільки свої словники. Витік локалі становить 15% у цьому запуску `static`; `importMode: 'dynamic'`, це параметр, який його видаляє, і ця конфігурація не була частиною цього запуску Vue.
 - **Реактивність та завантаження сторінки.** Перемикання локалі дешево для обох (1,5-2,8 мс); система реактивності Vue робить це можливим, коли повідомлення вже в пам'яті. Завантаження сторінки займає 13,6 мс до **9,3 мс**, що відповідає 88 КБ менше JavaScript для аналізу.
-- **Про природні рядки.** `vue-intlayer` у цьому запуску упаковував кожну локаль у режимі `static` і приземлився на 57.1 KB з рантайм 3.9 KB; синхронізовані словники адаптера містили менше іноземних рядків локалі, тому нижча цифра на сторінку. Нативний рантайм залишається найлегшим із трьох, а його модель `.content.ts` — це еквівалент блоків SFC `<i18n>`.
+- **Про природні рядки.** `vue-intlayer` у цьому запуску упаковував кожну локаль у режимі `static` і приземлився на 57.1 KB з рантайм 3.9 KB; синхронізовані словники адаптера містили менше іноземних рядків локалі, тому нижча цифра на сторінку. Нативний рантайм залишається найлегшим із трьох, а його модель `.content.ts`, це еквівалент блоків SFC `<i18n>`.
+
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Повна таблиця, кожна бібліотека та кожна стратегія, у [звіті про бенчмарк Vue](https://intlayer.org/uk/doc/benchmark/vue).
 
 ## Чому змінюються числа
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Нічого в `src/components/` не змінилося, тому прибутки походять від того, до чого прив'язаний `useI18n`.
 
-**З `vue-i18n`**, прив'язка — це глобальний екземпляр. `createI18n({ messages: { en, fr, ... } })` — це один імпорт, який містить все; кожен компонент, який викликає `useI18n()`, може отримати доступ до всього цього, тому бандлер не може розділити нижче екземпляра. Оптимізація означає, що _ви_ розділяєте `en.json` за маршрутом, викликаєте `setLocaleMessage()` в охоронцеві маршрутизатора й утримуєте карту маршруту до файлу в актуальному стані, коли компоненти переміщуються.
+**З `vue-i18n`**, прив'язка, це глобальний екземпляр. `createI18n({ messages: { en, fr, ... } })`, це один імпорт, який містить все; кожен компонент, який викликає `useI18n()`, може отримати доступ до всього цього, тому бандлер не може розділити нижче екземпляра. Оптимізація означає, що _ви_ розділяєте `en.json` за маршрутом, викликаєте `setLocaleMessage()` в охоронцеві маршрутизатора й утримуєте карту маршруту до файлу в актуальному стані, коли компоненти переміщуються. Витрати зростають за двома осями одночасно, сторінки та локалі:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -142,7 +161,7 @@ The [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) suite б
         └── Footer.vue             # useI18n(); t("footer.github")
 ```
 
-**З `@intlayer/vue-i18n`**, binding — це словник. `syncJSON` перетворює кожен top-level ключ `en.json` у словник; оптимізаційний проход передає компоненту ті, чиї ключи він назначує, імпортуючи bundler відстежує та розділяє за сторінкою.
+**З `@intlayer/vue-i18n`**, binding, це словник. `syncJSON` перетворює кожен top-level ключ `en.json` у словник; оптимізаційний проход передає компоненту ті, чиї ключи він назначує, імпортуючи bundler відстежує та розділяє за сторінкою.
 
 ```bash
 .
@@ -251,20 +270,119 @@ export const i18n = createI18n({ locale: "en" });
 
 ### Що ви отримуєте крім економії байтів
 
-- **Типізовані ключі.** `t("footer.github")` має тип для скомпільованого словника `footer`; неправильний шлях — це помилка TypeScript замість ключа, відображеного як текст.
+- **Типізовані ключі.** `t("footer.github")` має тип для скомпільованого словника `footer`; неправильний шлях, це помилка TypeScript замість ключа, відображеного як текст.
 - **`npx intlayer test`** завершується помилкою CI для відсутнього ключа в будь-якій локалі. **`npx intlayer fill`** перекладає відсутні за допомогою вашого ключа постачальника (OpenAI, Anthropic, Mistral, Gemini...) і записує їх назад в `locales/{locale}.json`.
 - **Visual Editor і CMS** працюють з одним і тим самим JSON, тому розробники редагують через UI, а файли оновлюються.
 - **Поступовий перехід до `.content.ts`.** Будь-який компонент може перейти з `useI18n()` на `useIntlayer("footer")` з прив'язаним файлом контенту. JSON та `.content.ts` словники співіснують та об'єднуються.
 
 ## Обмеження, про які потрібно знати перед початком
 
-- **SFC `<i18n>` блоки не читаються.** Якщо ваші повідомлення знаходяться всередині компонентів, вони повинні перейти до файлів локалізації (або до `.content.ts`, що є тією ж ідеєю з типами).
-- **Завантаження повідомлень під час виконання відсутнє.** `setLocaleMessage()` та `mergeLocaleMessage()` видають попередження та повертаються. Переклади, отримані з CMS під час виконання, потребують CMS Intlayer або команд `intlayer pull` / `push`.
-- **`messages` є резервним варіантом, а не безплатним.** Збереження імпортів JSON у `createI18n()` зберігає 75 KB у bundle. Видаліть їх, коли `intlayer test` пройде.
-- **Адаптер - це не нативний runtime.** 7.9 KB проти 3.9 KB для `vue-intlayer`. Як тільки кожен компонент перейде на `useIntlayer`, можна його видалити.
+<AccordionGroup>
+<Accordion header="Блоки SFC <i18n> не читаються">
+
+Якщо ваші повідомлення розташовані всередині компонентів, їх потрібно перенести до файлів локалей або до `.content.ts`, що є тією ж ідеєю зі створеними типами.
+
+</Accordion>
+<Accordion header="Завантаження повідомлень під час виконання видалено">
+
+`setLocaleMessage()` та `mergeLocaleMessage()` видають попередження та завершують роботу. Переклади, отримані з CMS під час виконання, вимагають [Intlayer CMS](https://intlayer.org/uk/doc/concept/cms) або команд `intlayer pull` / `push`.
+
+</Accordion>
+<Accordion header="messages є запасним варіантом, але не безкоштовним">
+
+Збереження імпорту JSON у `createI18n()` залишає 75 КБ у бандлі. Видаліть їх, коли `intlayer test` завершиться успішно.
+
+</Accordion>
+<Accordion header="Адаптер не є нативним середовищем виконання">
+
+7.9 КБ проти 3.9 КБ у `vue-intlayer`. Як тільки кожен компонент перейде на `useIntlayer`, видаліть його.
+
+</Accordion>
+</AccordionGroup>
 
 ## Коли використовувати що?
 
-- **Залишайтеся на `vue-i18n`**, якщо ваш додаток залежить від SFC `<i18n>` блоків, від flows `setLocaleMessage()` під час виконання, або якщо 90 KB на сторінку - це не проблема для вашої аудиторії.
-- **Використовуйте `@intlayer/vue-i18n`**, якщо ви на `vue-i18n` і хочете зекономити 88 KB, мати компоненти в 23 рази менші, 0% витоків сторінки, типізовані ключі та CI перевірки без редагування `.vue` файлу. Це точка входу для існуючого `vue-i18n` codebase.
-- **Переходьте на native (`vue-intlayer`)** для нових проектів, або як тільки адаптер виконав свою роботу. Він має найлегший runtime (3.9 KB) та per-component `.content.ts` модель, яка замінює `<i18n>` блоки типізованим контентом.
+<AccordionGroup>
+<Accordion header="Залишитися на vue-i18n">
+
+Ваш додаток залежить від блоків SFC `<i18n>`, від робочих процесів `setLocaleMessage()` під час виконання, або 90 КБ на сторінку не є критичними для вашої аудиторії.
+
+</Accordion>
+<Accordion header="Використовувати @intlayer/vue-i18n">
+
+Ви використовуєте `vue-i18n` і хочете отримати 88 КБ економії, у 23 рази менші компоненти, 0% витоку сторінок, типізовані ключі та перевірки CI без редагування файлів `.vue`. Це відправна точка для існуючої кодової бази `vue-i18n`.
+
+</Accordion>
+<Accordion header="Перейти на нативний (vue-intlayer)">
+
+Для нових проєктів або коли адаптер виконав своє завдання. Він має найлегший рантайм (3.9 КБ) та модель `.content.ts` для кожного компонента, яка замінює блоки `<i18n>` типізованим вмістом. Почніть з [Intlayer з Vue](https://intlayer.org/uk/doc/environment/vite-and-vue) або [з Nuxt](https://intlayer.org/uk/doc/environment/nuxt-and-vue).
+
+</Accordion>
+</AccordionGroup>
+
+## Часті запитання
+
+<FAQ>
+
+<Question title="Чи потрібно мені редагувати мої файли .vue?">
+
+Ні. Збірка бенчмарка змінила лише `vite.config.ts`, `intlayer.config.ts` та один рядок у `src/i18n.ts`, імпорт `messages`. Кожен виклик `useI18n()`, `$t`, `v-t` та Options API залишився без змін.
+
+</Question>
+
+<Question title="Чому розмір компонента у 23 рази менший?">
+
+Тому що `useI18n()` більше не звертається до глобального екземпляра. `createI18n({ messages })` містить усі повідомлення кожної локалі, тому компонент, зібраний ізольовано, підтягує 196 КБ. З адаптером він звертається лише до власного словника: 8.4 КБ.
+
+</Question>
+
+<Question title="Що щодо форматування за допомогою d() та n()?">
+
+Збережено. Конфігурації `datetimeFormats` та `numberFormats`, передані в `createI18n()`, враховуються та підтримуються нативним `Intl`. Див. [форматування дати, часу та чисел](https://intlayer.org/uk/blog/date-time-number-formatting-locales).
+
+</Question>
+
+<Question title="Чи працює це з Nuxt?">
+
+`@intlayer/vue-i18n` орієнтований на Vite + Vue. Для `@nuxtjs/i18n` використовуйте [адаптер сумісності Nuxt i18n](https://intlayer.org/uk/doc/compatibility/nuxtjs-i18n) та дивіться [Intlayer з Nuxt](https://intlayer.org/uk/doc/environment/nuxt-and-vue) для нативного налаштування.
+
+</Question>
+
+<Question title="Чи можу я мігрувати компонент за компонентом?">
+
+Так. Будь-який компонент може перейти з `useI18n()` на `useIntlayer("footer")` з розташованим поруч файлом вмісту. Словники JSON та `.content.ts` співіснують і об'єднуються.
+
+</Question>
+
+</FAQ>
+
+## Пов'язані порівняння
+
+Та ж серія адаптерів:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/uk/blog/next-intl-vs-intlayer-next-intl)
+- [i18next vs @intlayer/i18next](https://intlayer.org/uk/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/uk/blog/lingui-vs-intlayer-lingui)
+
+Пряме порівняння бібліотек:
+
+- [vue-i18n vs Intlayer](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer), features and DX
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-benchmark)
+- [Is vue-i18n outdated?](https://intlayer.org/uk/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/uk/blog/how-to-pick-vue-i18n-library)
+
+Довідкова документація:
+
+- [Compat adapter: vue-i18n](https://intlayer.org/uk/doc/compatibility/vue-i18n) and [Nuxt i18n](https://intlayer.org/uk/doc/compatibility/nuxtjs-i18n)
+- [Посібник з міграції: vue-i18n на Intlayer](https://intlayer.org/uk/doc/migration/vue-i18n)
+- [Звіт про бенчмарк Vue](https://intlayer.org/uk/doc/benchmark/vue)
+- [Оптимізація бандла](https://intlayer.org/uk/doc/concept/bundle-optimization) та [компілятор Intlayer](https://intlayer.org/uk/doc/compiler)
+- [Візуальний редактор](https://intlayer.org/uk/doc/concept/editor), [CMS](https://intlayer.org/uk/doc/concept/cms) та [переклад за допомогою ШІ](https://intlayer.org/uk/doc/concept/auto-fill)
+
+## Висновок
+
+`@intlayer/vue-i18n` змінює те, до чого прив'язаний `useI18n()`: від глобального екземпляра, що містить усі повідомлення кожної локалі, до словника, скомпільованого для цього компонента. На тому ж додатку Vite + Vue 3 це дає **на 88 KB менше на сторінку**, у **3 рази менший runtime**, у **23 рази менші компоненти** та **0% витоку сторінок** за рахунок конфігураційного файлу, одного рядка плагіна та одного видаленого імпорту. SFC блоки `<i18n>` та завантаження повідомлень під час виконання, це дві речі, які він не переносить, а нативний runtime `vue-intlayer` залишається вдвічі меншим за нього.
+
+Всі вихідні дані, тестові додатки та скрипти знаходяться в [репозиторії Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Запустіть його самі.
+
+Зверніться до [документації 'Чому Intlayer?'](https://intlayer.org/uk/doc/why) для отримання детальнішої інформації.