@intlayer/docs 9.5.0 → 9.5.2

package/docs/uk/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Найкраще i18n рішення для Next.js у 2026 році - Звіт бенчмарку
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Next.js, такі як next-intl, next-i18next та Intlayer. Детальний звіт про продуктивність за розміром бандла, витоком та реактивністю.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Оновлення результатів бенчмарку"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Додати порівняння зірок GitHub"
@@ -56,7 +59,7 @@ style="border:none;"
 
 У міру зростання додатку розмір бандла може збільшуватися в геометричній прогресії, що помітно погіршує продуктивність.
 
-Наприклад, у найгірших випадках інтернаціоналізована сторінка може стати майже в 4 рази важчою.
+Наприклад, у найгірших випадках інтернаціоналізована сторінка може стати майже в 2 рази важчою.
 
 Інший вплив бібліотек i18n - сповільнення розробки. Перетворення компонентів на багатомовний контент багатьма мовами займає багато часу.
 
@@ -68,7 +71,7 @@ Intlayer намагається оптимізувати всі ці парам
 
 - **Intlayer** та **next-translate**: Найкращі варіанти для продуктивності Next.js, що забезпечують мінімальний розмір та найкращу підтримку статичного рендерингу.
 - **next-intl**: Найбільш трендовий варіант на сьогодні, проте він важкий і складний в оптимізації для великих додатків.
-- **next-i18next**: Популярний та багатий на плагіни, але має значну вагу бандла (~3× Intlayer).
+- **next-i18next**: Популярний та багатий на плагіни, але має значну вагу бандла (~3.5× Intlayer).
 - **Уникайте**: **gt-next** та **lingo.dev** через серйозні проблеми з продуктивністю, прив'язку до вендора (vendor lock-in) та критичні помилки при збірці.
 
 ## Протестуйте свій додаток
@@ -109,19 +112,21 @@ Intlayer намагається оптимізувати всі ці парам
 Для цього бенчмарку ми порівняли наступні бібліотеки:
 
 - `Base App` (Без бібліотеки i18n)
-- `next-intlayer` (v8.7.12)
-- `next-i18next` (v16.0.5)
-- `next-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
-- `next-translate` (v3.1.2)
+- `next-intlayer` (v9.5.1)
+- [`@intlayer/next-intl`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/compat/next-i18next.md) (v9.5.1)
+- `next-i18next` (v16.3.0)
+- `next-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
+- `next-translate` (v3.2.0)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `@lingo.dev/compiler` (v0.4.0)
-- `wuchale` (v0.22.11)
-- `gt-next` (v6.16.5)
+- `@tolgee/react` (v7.2.0)
+- `@lingo.dev/compiler` (v0.4.12)
+- `wuchale` (v0.26.6)
+- `gt-next` (v11.1.24)
 
-Я використовував `Next.js` версії `16.2.4` з App Router.
+Я використовував `Next.js` версії `16.3.4` з App Router.
 
 Я побудував багатомовний додаток з **10 сторінками** та **10 мовами**.
 
@@ -175,15 +180,15 @@ Intlayer намагається оптимізувати всі ці парам
 
 Виявлені проблеми:
 
-**(General Translation)** (`gt-next@6.16.5`):
+**(General Translation)** (`gt-next@11.1.24`):
 
-- Для додатку розміром 110 КБ `gt-next` додає понад 440 КБ зайвих даних.
+- Для додатку розміром 141 КБ `gt-next` додає понад 50 КБ зайвих даних.
 - `Quota Exceeded, please upgrade your plan` вже під час першої збірки.
 - Переклади не рендериться; отримую помилку `Error: <T> used on the client-side outside of <GTProvider>`, що схоже на баг бібліотеки.
 - При впровадженні **gt-next** я також стикнувся з [проблемою](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) бібліотеки: помилка `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, через яку додаток падав. Після звіту про помилку розробник виправив її протягом 24 годин.
 - Бібліотека блокує статичний рендеринг сторінок Next.js.
 
-**(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.12`):
 
 - Перевищено квоту AI, що повністю блокує збірку - ви не можете випустити продукт у продакшн без оплати.
 - Компілятор пропустив майже 40% перекладеного контенту. Мені довелося переписувати всі `.map` у плоскі блоки компонентів, щоб це запрацювало.
@@ -192,7 +197,7 @@ Intlayer намагається оптимізувати всі ці парам
 
 ### 2 - Експериментальні рішення
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 Ідея `Wuchale` цікава, але поки не життєздатна. Я зіткнувся з проблемами реактивності та був змушений примусово перерендерити провайдер, щоб додаток запрацював. Документація також досить нечітка, що ускладнює освоєння.
 
@@ -202,21 +207,21 @@ Intlayer намагається оптимізувати всі ці парам
 Особисто мені не подобається необхідність регенерувати JS-файли перед кожним пушем, що створює постійний ризик конфліктів під час злиття через PR. Інструмент також здається більш орієнтованим на Vite, ніж на Next.js.
 Нарешті, порівняно з іншими рішеннями, Paraglide не використовує стор (наприклад, React context) для отримання поточної локалі для рендерингу. Для кожного обробленого вузла він запитує локаль з localStorage / cookie тощо. Це призводить до виконання непотрібної логіки, що впливає на реактивність компонентів.
 
-> Примітка щодо paraglide: це рішення впроваджує код у вашу кодову базу для імпорту, в результаті чого показник 'розмір бібліотеки' у звіті бенчмарку становить майже 0. Генерація коду - це добре, оскільки функція, що використовується, міститиме лише необхідну логіку (повний префікс проти відсутності префікса, кукі проти сховища тощо). Для порівняння, Intlayer виконує цю фільтрацію через впровадження змінних середовища під час збірки, щоб змусити бандлер видалити невикористаний контент (tree-shaking) залежно від логіки. Завдяки цьому paraglide та intlayer виявляються в 6-10 разів легшими рішеннями, ніж i18next або next-intl.
+> Примітка щодо paraglide: це рішення впроваджує код у вашу кодову базу для імпорту, в результаті чого показник 'розмір бібліотеки' у звіті бенчмарку становить майже 0. Генерація коду - це добре, оскільки функція, що використовується, міститиме лише необхідну логіку (повний префікс проти відсутності префікса, кукі проти сховища тощо). Для порівняння, Intlayer виконує цю фільтрацію через впровадження змінних середовища під час збірки, щоб змусити бандлер видалити невикористаний контент (tree-shaking) залежно від логіки. Завдяки цьому paraglide та intlayer виявляються в 3-8 разів легшими рішеннями, ніж i18next або next-intl.
 
 ### 3 - Прийнятні рішення
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` вирішує багато зі згаданих проблем. Проте його впровадження здалося мені складнішим, ніж у подібних інструментів. Він не забезпечує типізацію (type safety), що ускладнює виявлення відсутніх ключів під час компіляції. Мені довелося обертати функції Tolgee своїми, щоб додати перевірку відсутніх ключів.
 
-**(Next Intl)** (`next-intl@4.9.1`):
+**(Next Intl)** (`next-intl@4.14.2`):
 
-`next-intl` - це зараз найбільш трендовий варіант, який ШІ-агенти просувають найбільше, але на мій погляд, помилково. Почати роботу легко. На практиці ж оптимізація для обмеження витоків є складною. Поєднання динамічного завантаження + просторів імен + типів TypeScript сильно сповільнює розробку. Пакет також досить важкий (~13 КБ для `NextIntlClientProvider` + `useTranslations`, що майже вдвічі більше за `next-intlayer`). **next-intl** раніше блокував статичний рендеринг сторінок Next.js. Він надає хелпер `setRequestLocale()`. Здається, це частково вирішено для централізованих файлів на кшталт `en.json` / `fr.json`, але статичний рендеринг все одно ламається, коли контент розділений на простори імен, як-от `en/shared.json` / `fr/shared.json` / `es/shared.json`.
+`next-intl` - це зараз найбільш трендовий варіант, який ШІ-агенти просувають найбільше, але на мій погляд, помилково. Почати роботу легко. На практиці ж оптимізація для обмеження витоків є складною. Поєднання динамічного завантаження + просторів імен + типів TypeScript сильно сповільнює розробку. Пакет також досить важкий (~14.7 КБ для `NextIntlClientProvider` + `useTranslations`, що більш ніж у 2.5 раза більше за `next-intlayer`). **next-intl** раніше блокував статичний рендеринг сторінок Next.js. Він надає хелпер `setRequestLocale()`. Здається, це частково вирішено для централізованих файлів на кшталт `en.json` / `fr.json`, але статичний рендеринг все одно ламається, коли контент розділений на простори імен, як-от `en/shared.json` / `fr/shared.json` / `es/shared.json`.
 
-**(Next I18next)** (`next-i18next@16.0.5`):
+**(Next I18next)** (`next-i18next@16.3.0`):
 
-`next-i18next` - це, мабуть, найпопулярніший варіант, оскільки він був одним із перших рішень i18n для JS-додатків. Він має багато плагінів від спільноти. Має ті ж основні недоліки, що й `next-intl`. Пакет особливо важкий (~18 КБ для `I18nProvider` + `useTranslation`, приблизно втричі більше за `next-intlayer`).
+`next-i18next` - це, мабуть, найпопулярніший варіант, оскільки він був одним із перших рішень i18n для JS-додатків. Він має багато плагінів від спільноти. Має ті ж основні недоліки, що й `next-intl`. Пакет особливо важкий (~19.7 КБ для `I18nProvider` + `useTranslation`, приблизно у 3.5 раза більше за `next-intlayer`).
 
 Формати повідомлень також відрізняються: `next-intl` використовує ICU MessageFormat, тоді як `i18next` використовує власний формат.
 
@@ -224,17 +229,17 @@ Intlayer намагається оптимізувати всі ці парам
 
 `next-international` також намагається вирішити ці проблеми, але не сильно відрізняється від `next-intl` або `next-i18next`. Він включає `scopedT()` для перекладів у межах просторів імен, але це практично не впливає на розмір бандла.
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` часто хвалять. Особисто мені робочий процес із `lingui extract` / `lingui compile` здався складнішим за альтернативи, без явних переваг. Також помічені непослідовні синтаксиси, які плутають ШІ (наприклад, `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
 ### 4 - Рекомендації
 
-**(Next Translate)** (`next-translate@3.1.2`):
+**(Next Translate)** (`next-translate@3.2.0`):
 
-`next-translate` - моя основна рекомендація, якщо вам подобається API у стилі `t()`. Він елегантно працює через `next-translate-plugin`, завантажуючи простори імен через `getStaticProps` за допомогою завантажувача Webpack / Turbopack. Це також найлегший варіант у цьому списку (~2.5 КБ). Визначення просторів імен для сторінок або маршрутів у конфігу добре продумане і простіше в підтримці, ніж у **next-intl** чи **next-i18next**. У версії `3.1.2` я помітив, що статичний рендеринг не працював; Next.js переходив до динамічного рендерингу.
+`next-translate` - моя основна рекомендація, якщо вам подобається API у стилі `t()`. Він елегантно працює через `next-translate-plugin`, завантажуючи простори імен через `getStaticProps` за допомогою завантажувача Webpack / Turbopack. Це також один із найлегших варіантів у цьому списку (~3.5 КБ). Визначення просторів імен для сторінок або маршрутів у конфігу добре продумане і простіше в підтримці, ніж у **next-intl** чи **next-i18next**. У версії `3.1.2` я помітив, що статичний рендеринг не працював; Next.js переходив до динамічного рендерингу.
 
-**(Intlayer)** (`next-intlayer@8.7.12`):
+**(Intlayer)** (`next-intlayer@9.5.1`):
 
 Я не буду особисто оцінювати `next-intlayer` заради об’єктивності, оскільки це моє власне рішення.
 

package/docs/uk/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Найкраще i18n рішення для Solid у 2026 році - Звіт про бенчмарк
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Solid, такі як solid-primitives, solid-i18next та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Оновлення результатів бенчмарку"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Додати порівняння зірок GitHub"
@@ -62,9 +65,9 @@ style="border:none;"
 
 ## TL;DR
 
-- **Intlayer**: Рекомендований вибір для професійних додатків Solid, які потребують розширених функцій та оптимізації (v8.7.12).
+- **Intlayer**: Рекомендований вибір для професійних додатків Solid, які потребують розширених функцій та оптимізації (v9.5.0).
 - **@solid-primitives/i18n**: Відмінна легка альтернатива для простих проєктів, хоча їй бракує розширених функцій, таких як lazy loading.
-- **solid-i18next**: Стандартний, але важкий варіант (~4.7 рази більше за Intlayer) з тими ж недоліками, що і React i18next.
+- **solid-i18next**: Стандартний, але важкий варіант (~3.5 рази більше за Intlayer) з тими ж недоліками, що і React i18next.
 - **Paraglide**: Інноваційний підхід, але складний DX та проблеми з tree-shaking у деяких конфігураціях.
 
 ## Протестуйте свій додаток
@@ -97,10 +100,10 @@ style="border:none;"
 Для цього бенчмарку ми порівняли наступні бібліотеки:
 
 - `Base App` (Без бібліотеки i18n)
-- `solid-intlayer` (v8.7.12)
+- `solid-intlayer` (v9.5.0)
 - `@solid-primitives/i18n` (v2.2.1)
-- `solid-i18next` (v17.0.2)
-- `@inlang/paraglide-js` (v2.17.0)
+- `i18next` (v26.0.8) + `@mbarzda/solid-i18next` (v1.4.1)
+- `@inlang/paraglide-js` (v2.25.1)
 
 Фреймворк - `Solid` з багатомовним додатком із **10 сторінок** і **10 мов**.
 
@@ -154,11 +157,11 @@ style="border:none;"
 
 ### 2 - Прийнятні рішення
 
-**(solid-i18next)** (`solid-i18next@17.0.2`):
+**(solid-i18next)** (`i18next@26.0.8`):
 
 `solid-i18next`, ймовірно, є найпопулярнішим варіантом, оскільки він був одним із перших, хто задовольнив потреби i18n у JavaScript-додатках. Він також має широкий набір плагінів спільноти для конкретних проблем.
 
-Пакет важкий (~14.6kb, що приблизно в 4.7 рази більше за `solid-intlayer`).
+Пакет важкий (~14.9kb, що приблизно в 3.5 рази більше за `solid-intlayer`).
 
 Тим не менш, він має ті ж основні недоліки, що і стеки, побудовані на `t('a.b.c')`: оптимізація можлива, але забирає багато часу, а великі проєкти ризикують поганими практиками (простори імен + динамічне завантаження + типи).
 
@@ -167,7 +170,7 @@ style="border:none;"
 Solid primitive надзвичайно легкий і ефективний. Я рекомендую це рішення для легких проєктів, але в ньому може швидко не вистачити функцій для професійних рішень, що включають управління кукі, перенаправлення проксі, форматери тощо.
 Йому також не вистачає lazy loading та скоупінгу просторів імен для оптимізації розміру сторінки.
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` пропонує інноваційний, добре продуманий підхід. Незважаючи на це, у цьому бенчмарку деревоподібне шейкінг (tree-shaking), яке рекламує їхня компанія, не спрацювало для моєї реалізації. Робочий процес і DX також складніші за інші варіанти.
 Особисто я не прихильник того, щоб перегенерувати файли JS перед кожним пушем, що створює постійний ризик конфліктів при злитті через PR.
@@ -175,7 +178,7 @@ Solid primitive надзвичайно легкий і ефективний. Я
 
 ### 3 - Рекомендації
 
-**(Intlayer)** (`solid-intlayer@8.7.12`):
+**(Intlayer)** (`solid-intlayer@9.5.0`):
 
 Я не буду особисто оцінювати `solid-intlayer` заради об'єктивності, оскільки це моє власне рішення.
 

package/docs/uk/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Найкраще i18n рішення для Svelte у 2026 році - Звіт про бенчмарк
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Svelte, такі як svelte-i18n, Paraglide та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Оновлення результатів бенчмарку"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Додати порівняння зірок GitHub"
@@ -62,9 +65,9 @@ style="border:none;"
 
 ## TL;DR
 
-- **Intlayer**: Найефективніший за продуктивністю вибір (v8.7.12) з найменшим слідом (footprint).
+- **Intlayer**: Найефективніший за продуктивністю вибір (v9.5.0) з найменшим слідом (footprint).
 - **Paraglide**: Сильний претендент для tree-shaking, але має складніший досвід розробника та накладні витрати на реактивність.
-- **svelte-i18n**: Комплексний та стандартний для Svelte, але несе значно більшу вагу бандла (~7 разів більше за Intlayer).
+- **svelte-i18n**: Комплексний та стандартний для Svelte, але несе значно більшу вагу бандла (~4.5 разів більше за Intlayer).
 
 ## Протестуйте свій додаток
 
@@ -96,9 +99,9 @@ style="border:none;"
 Для цього бенчмарку ми порівняли наступні бібліотеки:
 
 - `Base App` (Без бібліотеки i18n)
-- `svelte-intlayer` (v8.7.12)
+- `svelte-intlayer` (v9.5.0)
 - `svelte-i18n` (v4.0.1)
-- `@inlang/paraglide-js` (v2.17.0)
+- `@inlang/paraglide-js` (v2.25.1)
 
 Фреймворк - `Svelte` з багатомовним додатком із **10 сторінок** і **10 мов**.
 
@@ -152,7 +155,7 @@ style="border:none;"
 
 ### 2 - Прийнятні рішення
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` пропонує інноваційний, добре продуманий підхід. У контексті додатка Vite + Svelte деревоподібне шейкінг (tree-shaking), яке рекламує їхня компанія, працювало як очікувалося, і це чудово.
 Але у випадку React + TanStack Start tree-shaking не спрацював як очікувалося, те саме для Next.js. Тим не менш, використання Paraglide у проєкті Svelte та TanStack Start варто було б перевірити ще раз.
@@ -162,13 +165,13 @@ style="border:none;"
 
 > Примітка щодо paraglide: рішення впорскує код у вашу кодову базу для імпорту; як результат, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду - це добре, тому що використана функція включатиме лише необхідну логіку (префікс скрізь проти відсутності префікса, кукі проти сховища тощо). Для порівняння, Intlayer виконує цю фільтрацію за допомогою впорскування змінних оточення під час збірки, щоб змусити бандлер виконувати tree-shaking контенту залежно від логіки. Завдяки цьому paraglide та intlayer стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
 
-**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+**(svelte-i18n)** (`svelte-i18n@4.0.1`):
 
-Це рішення задовольняє всі потреби i18n у проєкті Svelte. Але як і у випадку з i18next або іншими великими i18n рішеннями, воно трохи важке (~15.9kb, що приблизно в 7 разів більше за `svelte-intlayer`).
+Це рішення задовольняє всі потреби i18n у проєкті Svelte. Але як і у випадку з i18next або іншими великими i18n рішеннями, воно трохи важке (~16.6kb, що приблизно в 4.5 разів більше за `svelte-intlayer`).
 
 ### 3 - Рекомендації
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`):
+**(Intlayer)** (`svelte-intlayer@9.5.0`):
 
 Я не буду особисто оцінювати `svelte-intlayer` заради об'єктивності, оскільки це моє власне рішення.
 

package/docs/uk/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Найкраще i18n рішення для TanStack Start у 2026 році - Звіт бенчмарку
 description: Порівняйте бібліотеки інтернаціоналізації для TanStack Start, такі як react-i18next, use-intl та Intlayer. Детальний звіт про продуктивність за розміром бандла, витоком та реактивністю.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Оновлення результатів бенчмарку"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Додати порівняння зірок GitHub"
@@ -62,7 +65,7 @@ history:
 
 ## TL;DR
 
-- **Intlayer**: Забезпечує найкращу продуктивність і найменший розмір бандла (v8.7.12) для TanStack Start.
+- **Intlayer**: Забезпечує найкращу продуктивність і найменший розмір бандла (v9.5.1) для TanStack Start.
 - **react-i18next** та **use-intl**: Зрілі альтернативи з великими екосистемами, але значно важчі та складніші в оптимізації.
 - **Paraglide**: Інноваційна ідея tree-shaking, яка не працює на практиці. Складний DX та накладні витрати реактивності в TanStack Start.
 - **Уникайте**: **General Translation (GT)** та **Lingo.dev** через серйозні проблеми з продуктивністю, ліміти ШІ та прив'язку до вендора (vendor lock-in).
@@ -97,16 +100,18 @@ history:
 Для цього бенчмарку ми порівняли наступні бібліотеки:
 
 - `Base App` (Без бібліотеки i18n)
-- `react-intlayer` (v8.7.12)
-- `react-i18next` (v17.0.2)
-- `use-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
+- `react-intlayer` (v9.5.1)
+- `@intlayer/use-intl` (v9.5.1)
+- [`@intlayer/lingui`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/compat/lingui.md) (v9.5.1)
+- `react-i18next` (v17.0.13)
+- `use-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `react-intl` (v10.1.1)
-- `wuchale` (v0.22.11)
-- `gt-react` (vlatest)
-- `lingo.dev` (v0.133.9)
+- `@tolgee/react` (v7.2.0)
+- `react-intl` (v10.1.26)
+- `wuchale` (v0.26.6)
+- `gt-react` (v10.18.3)
+- `lingo.dev` (v0.138.7)
 
 Фреймворк - `TanStack Start` з багатомовним додатком на **10 сторінок** та **10 мов**.
 
@@ -160,15 +165,15 @@ history:
 
 Виявлені проблеми:
 
-**(General Translation)** (`gt-react@latest`):
+**(General Translation)** (`gt-react@10.18.3`):
 
-- Для додатку розміром близько 110 КБ `gt-react` може додати понад 440 КБ зайвих даних (порядок величини зафіксовано в реалізації Next.js у тому ж бенчмарку).
+- Для додатку розміром близько 111 КБ `gt-react` може додати понад 170 КБ зайвих даних (порядок величини зафіксовано в реалізації Next.js у тому ж бенчмарку).
 - `Quota Exceeded, please upgrade your plan` вже під час першої збірки.
 - Переклади не рендериться; отримую помилку `Error: <T> used on the client-side outside of <GTProvider>`, що схоже на баг бібліотеки.
 - При впровадженні **gt-tanstack-start-react** я також стикнувся з [проблемою](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) бібліотеки: помилка `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, через яку додаток падав. Після звіту про помилку розробник виправив її протягом 24 годин.
 - Ці бібліотеки використовують антипатерн через функцію `initializeGT()`, що заважає чистому видаленню невикористаного коду (tree-shaking) бандла.
 
-**(Lingo.dev)** (`lingo.dev@0.133.9`):
+**(Lingo.dev)** (`lingo.dev@0.138.7`):
 
 - Перевищено квоту AI (або блокування серверної залежності), що робить збірку / продакшн ризикованим без оплати.
 - Компілятор пропустив майже 40% перекладеного контенту. Мені довелося переписувати всі `.map` у плоскі блоки компонентів, щоб це запрацювало.
@@ -178,7 +183,7 @@ history:
 
 ### 2 - Експериментальні рішення
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 Ідея `Wuchale` цікава, але поки що не є життєздатним рішенням. Я зіткнувся з проблемами реактивності бібліотеки і був змушений примусово перерендерити провайдер, щоб додаток запрацював на TanStack Start. Документація також досить нечітка, що ускладнює освоєння.
 
@@ -188,9 +193,9 @@ history:
 
 `Paraglide` пропонує інноваційний, добре продуманий підхід. Проте в цьому тесті рекламований компанією tree-shaking не спрацював ні для моєї реалізації на Next.js, ні для TanStack Start. Робочий процес і DX також складніші за інші варіанти. Особисто я не прихильник необхідності регенерувати JS-файли перед кожним пушем, що створює постійний ризик конфліктів під час злиття для розробників через PR.
 
-> Примітка щодо paraglide: це рішення впорскує код у вашу кодову базу для імпорту; як наслідок, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду - це добре, оскільки використовувана функція включатиме лише необхідну логіку (префікс усюди проти відсутності префікса, куки проти сховища тощо). Для порівняння, Intlayer виконує це фільтрування за допомогою впорскування змінних оточення в збірку, щоб змусити бандлер виконати tree-shake контенту залежно від логіки. Завдяки цьому paraglide та intlayer врешті-решт стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
+> Примітка щодо paraglide: це рішення впорскує код у вашу кодову базу для імпорту; як наслідок, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду - це добре, оскільки використовувана функція включатиме лише необхідну логіку (префікс усюди проти відсутності префікса, куки проти сховища тощо). Для порівняння, Intlayer виконує це фільтрування за допомогою впорскування змінних оточення в збірку, щоб змусити бандлер виконати tree-shake контенту залежно від логіки. Завдяки цьому paraglide та intlayer врешті-решт стають у 3–10 разів легшими рішеннями, ніж i18next або next-intl.
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` вирішує багато зі згаданих проблем. Проте почати роботу з ним здалося мені важче, ніж з іншими інструментами з подібними підходами. Він не забезпечує типізацію, що значно ускладнює виявлення відсутніх ключів під час компіляції. Мені довелося обертати Tolgee API своїми рішеннями, щоб додати перевірку відсутніх ключів.
 
@@ -198,37 +203,37 @@ history:
 
 На TanStack Start я також мав проблеми з реактивністю: при зміні локалі довелося примусово перерендерити провайдер і підписуватися на події зміни локалі, щоб завантаження іншою мовою працювало коректно.
 
-**(use-intl)** (`use-intl@4.9.1`):
+**(use-intl)** (`use-intl@4.14.2`):
 
 `use-intl` - це зараз наймодніша частина "intl" в екосистемі React (та ж родина, що й `next-intl`), яку часто просувають ШІ-агенти, але на мій погляд - помилково в контексті продуктивності. Почати роботу досить просто. На практиці ж процес оптимізації та обмеження витоків є досить складним. Аналогічно, поєднання динамічного завантаження + просторів імен + типів TypeScript сильно сповільнює розробку.
 
 У TanStack Start ви уникаєте специфічних пасток Next.js (`setRequestLocale`, статичний рендеринг), але основна проблема та ж сама: без суворої дисципліни бандл швидко перевантажується повідомленнями, а підтримка просторів імен для кожного маршруту стає виснажливою.
 
-**(react-i18next)** (`react-i18next@17.0.2`):
+**(react-i18next)** (`react-i18next@17.0.13`):
 
 `react-i18next` - це, мабуть, найпопулярніший варіант, оскільки він був одним із перших, хто задовольнив потреби i18n у JS-додатках. Він також має великий набір плагінів від спільноти для конкретних проблем.
 
 Проте він має ті ж недоліки, що й стеки на базі `t('a.b.c')`: оптимізація можлива, але забирає багато часу, а великі проекти ризикують скотитися до поганих практик (простори імен + динамічне завантаження + типи).
 
-Пакет особливо важкий (~17.3kb, що становить близько 3.5× `react-intlayer`).
+Пакет особливо важкий (~18.4kb, що становить близько 3.5× `react-intlayer`).
 
 Формати повідомлень також відрізняються: `use-intl` використовує ICU MessageFormat, тоді як `i18next` має власний формат - це ускладнює інструментарій або міграцію, якщо ви їх змішуєте.
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` часто хвалять. Особисто мені робочий процес із `lingui extract` / `lingui compile` здався складнішим за інші підходи, без явних переваг у цьому тесті TanStack Start. Також помічені непослідовні синтаксиси, які плутають ШІ (наприклад, `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
-**(react-intl)** (`react-intl@10.1.1`):
+**(react-intl)** (`react-intl@10.1.26`):
 
 `react-intl` - це продуктивна реалізація від команди Format.js. DX залишається багатослівним: `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` додає складності, додаткової роботи JavaScript та прив'язує глобальний екземпляр i18n до багатьох вузлів у React-дереві.
 
-Пакет також важкий (~14.4kb, що становить близько 3× `react-intlayer`).
+Пакет також важкий (~15.3kb, що становить близько 3× `react-intlayer`).
 
 ### 4 - Рекомендації
 
 Цей бенчмарк TanStack Start не має прямого еквівалента `next-translate` (Next.js плагін + `getStaticProps`). Командам, які справді хочуть API у стилі `t()` зі зрілою екосистемою, `react-i18next` та `use-intl` залишаються "розумним" вибором, але будьте готові витратити багато часу на оптимізацію для уникнення витоків.
 
-**(Intlayer)** (`react-intlayer@8.7.12`):
+**(Intlayer)** (`react-intlayer@9.5.1`):
 
 Я не буду особисто оцінювати `react-intlayer` заради об’єктивності, оскільки це моє власне рішення.
 

package/docs/uk/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Найкраще i18n рішення для Vue у 2026 році - Звіт про бенчмарк
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Vue, такі як vue-i18n, fluent-vue та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Оновлення результатів бенчмарку"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Додати порівняння зірок GitHub"
@@ -62,7 +65,7 @@ style="border:none;"
 
 ## TL;DR
 
-- **Intlayer**: Найлегше рішення (v8.7.12) з нативним скоупінгом (scoping) та динамічним завантаженням.
+- **Intlayer**: Найлегше рішення (v9.5.0) з нативним скоупінгом (scoping) та динамічним завантаженням.
 - **vue-i18n**: Галузевий стандарт з багатою екосистемою, але може стати значно важчим і важчим для оптимізації під code-splitting у великих додатках.
 - **fluent-vue**: Інноваційна організація повідомлень, але не вистачає безпеки типів (type-safety) і виявляється надзвичайно важким рішенням.
 
@@ -96,7 +99,8 @@ style="border:none;"
 Для цього бенчмарку ми порівняли наступні бібліотеки:
 
 - `Base App` (Без бібліотеки i18n)
-- `vue-intlayer` (v8.7.12)
+- `vue-intlayer` (v9.5.0)
+- [`@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/compat/vue-i18n.md) (v9.5.1)
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
@@ -156,14 +160,14 @@ style="border:none;"
 
 - **vue-i18n** безперечно є найбільш використовуваною бібліотекою i18n для Vue, вона має багато функцій і величезну екосистему. Але "під капотом" рішення досить важке. Навіть якщо vue-i18n інтегрує lazy loading для повідомлень, у ній відсутня функція скоупінгу (scoping). У випадку класичного Vue SPA додатка проблем немає, але для nuxt додатка, що використовує @nuxt/i18n, це призводить до включення повідомлень з усіх сторінок в одну. Для великого nuxt додатка з понад 10 сторінками це може стати справді проблематичним.
 
-Пакет дуже важкий (~24.3kb, що приблизно в 9 разів більше за `vue-intlayer`).
+Пакет дуже важкий (~24.3kb, що приблизно в 6 разів більше за `vue-intlayer`).
 
-**(fluent-vue)** (`fluent-vue@0.5.0`):
+**(fluent-vue)** (`fluent-vue@3.8.2`):
 
-- **fluent-vue** пропонує спробу інновації через формат .ftl. Організація повідомлень чудова, легше почати роботу. Але на практиці відсутність безпеки типів підвищує ризик помилок і налагодження може швидко стати трудомістким. Більше того, це рішення завантажує повідомлення за допомогою плагіна vite, який змушує завантажувати весь контент усіма мовами на кожну сторінку. Крім того, це надзвичайно важке рішення (~92.7kb, що приблизно в 34 рази більше за `vue-intlayer`).
+- **fluent-vue** пропонує спробу інновації через формат .ftl. Організація повідомлень чудова, легше почати роботу. Але на практиці відсутність безпеки типів підвищує ризик помилок і налагодження може швидко стати трудомістким. Більше того, це рішення завантажує повідомлення за допомогою плагіна vite, який змушує завантажувати весь контент усіма мовами на кожну сторінку. Крім того, це надзвичайно важке рішення (~29.7kb, що приблизно в 7.5 рази більше за `vue-intlayer`).
 
 ### 3 - Рекомендації
 
-**(Intlayer)** (`vue-intlayer@8.7.12`):
+**(Intlayer)** (`vue-intlayer@9.5.0`):
 
 Я не буду особисто оцінювати `vue-intlayer` заради об'єктивності, оскільки це моє власне рішення.

package/docs/uk/cli/build.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Побудова словників
 description: Дізнайтеся, як побудувати словники Intlayer зі файлів декларації контенту.
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - cli
   - build
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Додано прапорець `--ci`"
   - version: 8.1.5
     date: 2026-02-23
     changes: "Додати опцію checkTypes"
@@ -92,6 +95,10 @@ bun x intlayer build --watch
 
   > Приклад: `npx intlayer build --no-cache`
 
+- **`--ci`**: Виконує команду в кожному проєкті Intlayer монорепозиторію (або лише в поточному при запуску з директорії проєкту). Облікові дані для кожного проєкту можна підставити через `INTLAYER_PROJECT_CREDENTIALS` — JSON-об'єкт, що зіставляє шлях проєкту з `{ "clientId", "clientSecret" }`.
+
+  > Приклад: `npx intlayer build --ci`
+
 - **`--check-types`**: Перевіряє типи файлів оголошення контенту.
 
   > Приклад: `npx intlayer build --check-types`

package/docs/uk/cli/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Керування конфігурацією
 description: Дізнайтеся, як отримувати та завантажувати вашу конфігурацію Intlayer у CMS.
 keywords:
@@ -51,6 +51,7 @@ bun x intlayer configuration get
 - **`--base-dir`**: Вказати базовий каталог проекту.
 - **`--verbose`**: Увімкнути детальне логування для відлагодження. (за замовчуванням true при використанні CLI)
 - **`--no-cache`**: Вимкнути кеш.
+- **`--ci`**: Виконує команду в кожному проєкті Intlayer монорепозиторію (або лише в поточному при запуску з директорії проєкту). Облікові дані для кожного проєкту можна підставити через `INTLAYER_PROJECT_CREDENTIALS` — JSON-об'єкт, що зіставляє шлях проєкту з `{ "clientId", "clientSecret" }`.
 
 ## Надіслати конфігурацію
 
@@ -84,5 +85,6 @@ bun x intlayer configuration push
 - **`--base-dir`**: Вказати базовий каталог проекту.
 - **`--verbose`**: Увімкнути детальне логування для налагодження. (за замовчуванням true при використанні CLI)
 - **`--no-cache`**: Вимкнути кеш.
+- **`--ci`**: Виконує команду в кожному проєкті Intlayer монорепозиторію (або лише в поточному при запуску з директорії проєкту). Облікові дані для кожного проєкту можна підставити через `INTLAYER_PROJECT_CREDENTIALS` — JSON-об'єкт, що зіставляє шлях проєкту з `{ "clientId", "clientSecret" }`.
 
 Після пушу конфігурації ваш проєкт повністю інтегрується з Intlayer CMS, що дозволяє безшовне керування словниками між командами.

package/docs/uk/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2026-06-17
+updatedAt: 2026-09-12
 title: Перевірка документа
 description: Дізнайтеся, як перевіряти файли документації на предмет якості, узгодженості та повноти для різних локалей.
 keywords:
@@ -16,6 +16,9 @@ slugs:
   - cli
   - doc-review
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Додано прапорець `--ci`"
   - version: 9.0.0
     date: 2026-06-17
     changes: "Додати опцію --log"
@@ -138,6 +141,10 @@ bun x intlayer doc review
 
   > Приклад: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: Виконує команду в кожному проєкті Intlayer монорепозиторію (або лише в поточному при запуску з директорії проєкту). Облікові дані для кожного проєкту можна підставити через `INTLAYER_PROJECT_CREDENTIALS` — JSON-об'єкт, що зіставляє шлях проєкту з `{ "clientId", "clientSecret" }`.
+
+  > Приклад: `npx intlayer doc review --ci`
+
 **Параметри логування:**
 
 - **`--verbose`**: Увімкнути детальне логування для налагодження. (за замовчуванням true при використанні CLI)

package/docs/uk/cli/doc-translate.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Переклад документа
 description: Дізнайтеся, як автоматично перекладати файли документації за допомогою AI-сервісів перекладу.
 keywords:
@@ -113,6 +113,10 @@ bun x intlayer doc translate
 
   > Приклад: `npx intlayer doc translate --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: Виконує команду в кожному проєкті Intlayer монорепозиторію (або лише в поточному при запуску з директорії проєкту). Облікові дані для кожного проєкту можна підставити через `INTLAYER_PROJECT_CREDENTIALS` — JSON-об'єкт, що зіставляє шлях проєкту з `{ "clientId", "clientSecret" }`.
+
+  > Приклад: `npx intlayer doc translate --ci`
+
 **Параметри логування:**
 
 - **`--verbose`**: Увімкнути детальне логування для налагодження. (за замовчуванням true при використанні CLI)