@intlayer/docs 8.9.8 → 8.10.0-canary.1

package/docs/uk/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
+updatedAt: 2026-05-18
 title: Найкраще i18n рішення для Next.js у 2026 році - Звіт бенчмарку
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Next.js, такі як next-intl, next-i18next та Intlayer. Детальний звіт про продуктивність за розміром бандла, витоком та реактивністю.
 keywords:
@@ -17,12 +17,15 @@ slugs:
 author: Aymeric PINEAU
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
+  - version: 8.9.8
+    date: 2026-05-18
+    changes: "Додати порівняння зірок GitHub"
   - version: 8.7.5
     date: 2026-01-06
     changes: "Ініціалізація бенчмарку"
 ---
 
-# Бібліотеки i18n для Next.js — Звіт бенчмарку 2026
+# Бібліотеки i18n для Next.js - Звіт бенчмарку 2026
 
 Ця сторінка є звітом бенчмарку i18n рішень на Next.js.
 
@@ -55,9 +58,9 @@ style="border:none;"
 
 Наприклад, у найгірших випадках інтернаціоналізована сторінка може стати майже в 4 рази важчою.
 
-Інший вплив бібліотек i18n — сповільнення розробки. Перетворення компонентів на багатомовний контент багатьма мовами займає багато часу.
+Інший вплив бібліотек i18n - сповільнення розробки. Перетворення компонентів на багатомовний контент багатьма мовами займає багато часу.
 
-Оскільки це складна проблема, існує багато рішень — деякі зосереджені на DX (досвід розробника), інші на продуктивності чи масштабованості тощо.
+Оскільки це складна проблема, існує багато рішень - деякі зосереджені на DX (досвід розробника), інші на продуктивності чи масштабованості тощо.
 
 Intlayer намагається оптимізувати всі ці параметри одночасно.
 
@@ -85,17 +88,17 @@ Intlayer намагається оптимізувати всі ці парам
 
 **Динамічне завантаження**
 
-Навіть якщо ви оголошуєте роути на кшталт `[locale]/page.tsx`, використовуючи Webpack або Turbopack, і навіть якщо визначено `generateStaticParams`, бандлер не розглядає `locale` як статичну константу. Це означає, що він може додати контент для всіх мов у кожну сторінку. Основний спосіб обмежити це — завантажувати контент через динамічний імпорт (наприклад, `import('./locales/${locale}.json')`).
+Навіть якщо ви оголошуєте роути на кшталт `[locale]/page.tsx`, використовуючи Webpack або Turbopack, і навіть якщо визначено `generateStaticParams`, бандлер не розглядає `locale` як статичну константу. Це означає, що він може додати контент для всіх мов у кожну сторінку. Основний спосіб обмежити це - завантажувати контент через динамічний імпорт (наприклад, `import('./locales/${locale}.json')`).
 
 На етапі збірки (build time) Next.js створює один JS-бандл на локаль (наприклад, `./locales_uk_12345.js`). Після того, як сайт надіслано клієнту, під час запуску сторінки браузер робить додатковий HTTP-запит для потрібного JS-файлу.
 
-> Інший спосіб вирішення цієї проблеми — використання `fetch()` для динамічного завантаження JSON. Саме так працює `Tolgee`, коли JSON знаходиться в `/public`, або `next-translate`, який використовує `getStaticProps` для завантаження контенту. Процес ідентичний: браузер робить додатковий HTTP-запит для завантаження ресурсу.
+> Інший спосіб вирішення цієї проблеми - використання `fetch()` для динамічного завантаження JSON. Саме так працює `Tolgee`, коли JSON знаходиться в `/public`, або `next-translate`, який використовує `getStaticProps` для завантаження контенту. Процес ідентичний: браузер робить додатковий HTTP-запит для завантаження ресурсу.
 
 **Розділення контенту (Content splitting)**
 
 Якщо ви використовуєте синтаксис на кшталт `const t = useTranslation()` + `t('my-object.my-sub-object.my-key')`, зазвичай весь JSON має бути в бандлі, щоб бібліотека могла розібрати його та знайти ключ. Велика частина цього контенту передається клієнту, навіть якщо вона не використовується на сторінці.
 
-Щоб мінімізувати це, деякі бібліотеки просять вас вказувати для кожної сторінки, які простори імен завантажувати — наприклад, `next-i18next`, `next-intl`, `lingui`, `next-translate`, `next-international`.
+Щоб мінімізувати це, деякі бібліотеки просять вас вказувати для кожної сторінки, які простори імен завантажувати - наприклад, `next-i18next`, `next-intl`, `lingui`, `next-translate`, `next-international`.
 
 Натомість `Paraglide` додає додатковий крок перед збіркою, щоб перетворити JSON на плоскі символи на кшталт `const en_my_var = () => 'my value'`. Теоретично це дозволяє видаляти невикористаний контент на сторінці. Як ми побачимо, цей метод все одно має свої компроміси.
 
@@ -140,9 +143,9 @@ Intlayer намагається оптимізувати всі ці парам
 
 Я запускав один і той самий багатомовний додаток у реальному браузері для кожного стеку, а потім фіксував, що насправді передавалося через мережу і скільки часу це займало. Розміри вказані **після звичайного веб-стиснення**, оскільки це ближче до того, що люди реально завантажують.
 
-- **Розмір бібліотеки інтернаціоналізації**: Після складання, видалення невикористаного коду та мінімізації, розмір бібліотеки i18n — це розмір коду провайдерів (наприклад, `NextIntlClientProvider`) + хуків (наприклад, `useTranslations`) у порожньому компоненті. Це не включає завантаження файлів перекладу. Це показує, наскільки "важкою" є бібліотека ще до появи вашого контенту.
+- **Розмір бібліотеки інтернаціоналізації**: Після складання, видалення невикористаного коду та мінімізації, розмір бібліотеки i18n - це розмір коду провайдерів (наприклад, `NextIntlClientProvider`) + хуків (наприклад, `useTranslations`) у порожньому компоненті. Це не включає завантаження файлів перекладу. Це показує, наскільки "важкою" є бібліотека ще до появи вашого контенту.
 
-- **JavaScript на сторінку**: Для кожного тестового маршруту — скільки скриптів завантажує браузер під час візиту, усереднено за сторінками тесту (і за локалями). Важкі сторінки — це повільні сторінки.
+- **JavaScript на сторінку**: Для кожного тестового маршруту - скільки скриптів завантажує браузер під час візиту, усереднено за сторінками тесту (і за локалями). Важкі сторінки - це повільні сторінки.
 
 - **Витік з інших локалей (Leakage)**: Це контент тієї ж сторінки, але іншою мовою, який помилково завантажується на сторінку, що перевіряється. Цей контент є зайвим і його слід уникати (наприклад, контент сторінки `/fr/about` у бандлі сторінки `/en/about`).
 
@@ -150,7 +153,7 @@ Intlayer намагається оптимізувати всі ці парам
 
 - **Середній розмір бандла компонента**: Окремі UI-елементи вимірюються **по одному**, а не ховаються всередині одного гігантського загального показника додатку. Це показує, чи інтернаціоналізація "роздуває" звичайні компоненти. Наприклад, якщо ваш компонент перерендериться, він завантажуватиме всі ці дані з пам'яті. Прив'язка гігантського JSON до будь-якого компонента схожа на підключення великого сховища невикористаних даних, що сповільнює продуктивність ваших компонентів.
 
-- **Швидкість реакції на перемикання мови**: Я перемикаю мову через власний інтерфейс додатку і заміряю час до моменту, коли сторінка явно оновилася — те, що помітить відвідувач.
+- **Швидкість реакції на перемикання мови**: Я перемикаю мову через власний інтерфейс додатку і заміряю час до моменту, коли сторінка явно оновилася - те, що помітить відвідувач.
 
 - **Робота рендерингу після зміни мови**: Вужчий показник: скільки зусиль витратив інтерфейс на перемальовування для нової мови після початку перемикання. Корисно, коли "відчутний" час і вартість роботи фреймворку відрізняються.
 
@@ -158,11 +161,17 @@ Intlayer намагається оптимізувати всі ці парам
 
 - **Час гідратації (Hydration)**: Час, який клієнт витрачає на перетворення HTML від сервера на інтерактивний інтерфейс. Прочерк у таблицях означає, що дана реалізація не надала надійних даних про гідратацію в цьому тесті.
 
+## Зірки на GitHub
+
+Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=i18next%2Fnext-i18next%2Camannn%2Fnext-intl%2Clingui%2Fjs-lingui%2Cvinissimus%2Fnext-translate%2Cinostudio%2Fnext-international%2Copral%2paraglide-js%2Ctolgee%2Ftolgee-js%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#i18next/next-i18next&amannn/next-intl&lingui/js-lingui&vinissimus/next-translate&inostudio/next-international&opral/paraglide-js&tolgee/tolgee-js&aymericzip/intlayer)
+
 ## Детальні результати
 
-### 1 — Рішення, яких слід уникати
+### 1 - Рішення, яких слід уникати
 
-Деяких рішень, таких як `gt-next` або `lingo.dev`, явно варто уникати. Вони поєднують прив'язку до вендора (vendor lock-in) із засміченням кодової бази. Попри багато годин спроб їх впровадження, я так і не зміг забезпечити їх стабільну роботу — ні на TanStack Start, ні на Next.js.
+Деяких рішень, таких як `gt-next` або `lingo.dev`, явно варто уникати. Вони поєднують прив'язку до вендора (vendor lock-in) із засміченням кодової бази. Попри багато годин спроб їх впровадження, я так і не зміг забезпечити їх стабільну роботу - ні на TanStack Start, ні на Next.js.
 
 Виявлені проблеми:
 
@@ -176,12 +185,12 @@ Intlayer намагається оптимізувати всі ці парам
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
 
-- Перевищено квоту AI, що повністю блокує збірку — ви не можете випустити продукт у продакшн без оплати.
+- Перевищено квоту AI, що повністю блокує збірку - ви не можете випустити продукт у продакшн без оплати.
 - Компілятор пропустив майже 40% перекладеного контенту. Мені довелося переписувати всі `.map` у плоскі блоки компонентів, щоб це запрацювало.
 - Їхній CLI працює нестабільно і часто без причини скидає конфігураційний файл.
 - Під час збірки він повністю стирав згенеровані JSON-файли при додаванні нового контенту. У результаті кілька ключів могли знищити понад 300 наявних.
 
-### 2 — Експериментальні рішення
+### 2 - Експериментальні рішення
 
 **(Wuchale)** (`wuchale@0.22.11`):
 
@@ -193,9 +202,9 @@ 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 виявляються в 6-10 разів легшими рішеннями, ніж i18next або next-intl.
 
-### 3 — Прийнятні рішення
+### 3 - Прийнятні рішення
 
 **(Tolgee)** (`@tolgee/react@7.0.0`):
 
@@ -203,11 +212,11 @@ Intlayer намагається оптимізувати всі ці парам
 
 **(Next Intl)** (`next-intl@4.9.1`):
 
-`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 сильно сповільнює розробку. Пакет також досить важкий (~13 КБ для `NextIntlClientProvider` + `useTranslations`, що майже вдвічі більше за `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` — це, мабуть, найпопулярніший варіант, оскільки він був одним із перших рішень i18n для JS-додатків. Він має багато плагінів від спільноти. Має ті ж основні недоліки, що й `next-intl`. Пакет особливо важкий (~18 КБ для `I18nProvider` + `useTranslation`, приблизно втричі більше за `next-intlayer`).
+`next-i18next` - це, мабуть, найпопулярніший варіант, оскільки він був одним із перших рішень i18n для JS-додатків. Він має багато плагінів від спільноти. Має ті ж основні недоліки, що й `next-intl`. Пакет особливо важкий (~18 КБ для `I18nProvider` + `useTranslation`, приблизно втричі більше за `next-intlayer`).
 
 Формати повідомлень також відрізняються: `next-intl` використовує ICU MessageFormat, тоді як `i18next` використовує власний формат.
 
@@ -219,11 +228,11 @@ Intlayer намагається оптимізувати всі ці парам
 
 `Lingui` часто хвалять. Особисто мені робочий процес із `lingui extract` / `lingui compile` здався складнішим за альтернативи, без явних переваг. Також помічені непослідовні синтаксиси, які плутають ШІ (наприклад, `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
-### 4 — Рекомендації
+### 4 - Рекомендації
 
 **(Next Translate)** (`next-translate@3.1.2`):
 
-`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. Це також найлегший варіант у цьому списку (~2.5 КБ). Визначення просторів імен для сторінок або маршрутів у конфігу добре продумане і простіше в підтримці, ніж у **next-intl** чи **next-i18next**. У версії `3.1.2` я помітив, що статичний рендеринг не працював; Next.js переходив до динамічного рендерингу.
 
 **(Intlayer)** (`next-intlayer@8.7.12`):
 

package/docs/uk/benchmark/solid.md

@@ -1,7 +1,7 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
-title: Найкраще i18n рішення для Solid у 2026 році — Звіт про бенчмарк
+updatedAt: 2026-05-18
+title: Найкраще i18n рішення для Solid у 2026 році - Звіт про бенчмарк
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Solid, такі як solid-primitives, solid-i18next та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
 keywords:
   - benchmark
@@ -17,12 +17,15 @@ slugs:
 author: Aymeric PINEAU
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
+  - version: 8.9.8
+    date: 2026-05-18
+    changes: "Додати порівняння зірок GitHub"
   - version: 8.7.12
     date: 2026-01-06
     changes: "Ініціалізація бенчмарку"
 ---
 
-# Бібліотеки i18n для Solid — Звіт про бенчмарк 2026
+# Бібліотеки i18n для Solid - Звіт про бенчмарк 2026
 
 Ця сторінка є звітом про бенчмарк рішень i18n на Solid.
 
@@ -99,7 +102,7 @@ style="border:none;"
 - `solid-i18next` (v17.0.2)
 - `@inlang/paraglide-js` (v2.17.0)
 
-Фреймворк — `Solid` з багатомовним додатком із **10 сторінок** і **10 мов**.
+Фреймворк - `Solid` з багатомовним додатком із **10 сторінок** і **10 мов**.
 
 Ми порівняли **чотири стратегії завантаження**:
 
@@ -115,13 +118,19 @@ style="border:none;"
 - **Scoped static**: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
 - **Scoped dynamic**: Найкращий підхід для _code splitting_ та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
 
+## Зірки на GitHub
+
+Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=solidjs-community%2Fsolid-primitives%2Cmbarzda%2Fsolid-i18next%2Copral%2paraglide-js%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#solidjs-community/solid-primitives&mbarzda/solid-i18next&opral/paraglide-js&aymericzip/intlayer)
+
 ## Результати детально
 
-### 1 — Рішення, яких слід уникати
+### 1 - Рішення, яких слід уникати
 
 > В екосистемі Solid немає очевидних рішень, яких слід уникати.
 
-### 2 — Прийнятні рішення
+### 2 - Прийнятні рішення
 
 **(solid-i18next)** (`solid-i18next@17.0.2`):
 
@@ -142,7 +151,7 @@ Solid primitive надзвичайно легкий і ефективний. Я
 Особисто я не прихильник того, щоб перегенерувати файли JS перед кожним пушем, що створює постійний ризик конфліктів при злитті через PR.
 Нарешті, у порівнянні з іншими рішеннями, Paraglide не використовує стор (наприклад, Solid signal) для отримання поточної локалі для рендерингу контенту. Для кожного розібраного вузла він запитуватиме локаль з localStorage / cookie тощо. Це призводить до виконання непотрібної логіки, яка впливає на реактивність компонентів.
 
-### 3 — Рекомендації
+### 3 - Рекомендації
 
 **(Intlayer)** (`solid-intlayer@8.7.12`):
 

package/docs/uk/benchmark/svelte.md

@@ -1,7 +1,7 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
-title: Найкраще i18n рішення для Svelte у 2026 році — Звіт про бенчмарк
+updatedAt: 2026-05-18
+title: Найкраще i18n рішення для Svelte у 2026 році - Звіт про бенчмарк
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Svelte, такі як svelte-i18n, Paraglide та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
 keywords:
   - benchmark
@@ -17,12 +17,15 @@ slugs:
 author: Aymeric PINEAU
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
+  - version: 8.9.8
+    date: 2026-05-18
+    changes: "Додати порівняння зірок GitHub"
   - version: 8.7.12
     date: 2026-01-06
     changes: "Ініціалізація бенчмарку"
 ---
 
-# Бібліотеки i18n для Svelte — Звіт про бенчмарк 2026
+# Бібліотеки i18n для Svelte - Звіт про бенчмарк 2026
 
 Ця сторінка є звітом про бенчмарк рішень i18n на Svelte.
 
@@ -97,7 +100,7 @@ style="border:none;"
 - `svelte-i18n` (v4.0.1)
 - `@inlang/paraglide-js` (v2.17.0)
 
-Фреймворк — `Svelte` з багатомовним додатком із **10 сторінок** і **10 мов**.
+Фреймворк - `Svelte` з багатомовним додатком із **10 сторінок** і **10 мов**.
 
 Ми порівняли **чотири стратегії завантаження**:
 
@@ -113,13 +116,19 @@ style="border:none;"
 - **Scoped static**: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
 - **Scoped dynamic**: Найкращий підхід для _code splitting_ та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
 
+## Зірки на GitHub
+
+Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=kaisermann%2Fsvelte-i18n%2Copral%2paraglide-js%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#kaisermann/svelte-i18n&opral/paraglide-js&aymericzip/intlayer)
+
 ## Результати детально
 
-### 1 — Рішення, яких слід уникати
+### 1 - Рішення, яких слід уникати
 
 > В екосистемі Svelte немає очевидних рішень, яких слід уникати.
 
-### 2 — Прийнятні рішення
+### 2 - Прийнятні рішення
 
 **(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
 
@@ -129,13 +138,13 @@ style="border:none;"
 Особисто я не прихильник того, щоб перегенерувати файли JS перед кожним пушем, що створює постійний ризик конфліктів при злитті через PR. Інструмент також здається більш зосередженим на Vite, ніж на Next.js.
 Нарешті, у порівнянні з іншими рішеннями, Paraglide не використовує стор (наприклад, Svelte store) для отримання поточної локалі для рендерингу контенту. Для кожного розібраного вузла він запитуватиме локаль з localStorage / cookie тощо. Це призводить до виконання непотрібної логіки, яка впливає на реактивність компонентів.
 
-> Примітка щодо paraglide: рішення впорскує код у вашу кодову базу для імпорту; як результат, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду — це добре, тому що використана функція включатиме лише необхідну логіку (префікс скрізь проти відсутності префікса, кукі проти сховища тощо). Для порівняння, Intlayer виконує цю фільтрацію за допомогою впорскування змінних оточення під час збірки, щоб змусити бандлер виконувати tree-shaking контенту залежно від логіки. Завдяки цьому paraglide та intlayer стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
+> Примітка щодо paraglide: рішення впорскує код у вашу кодову базу для імпорту; як результат, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду - це добре, тому що використана функція включатиме лише необхідну логіку (префікс скрізь проти відсутності префікса, кукі проти сховища тощо). Для порівняння, Intlayer виконує цю фільтрацію за допомогою впорскування змінних оточення під час збірки, щоб змусити бандлер виконувати tree-shaking контенту залежно від логіки. Завдяки цьому paraglide та intlayer стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
 
 **(svelte-i18n)** (`svelte-i18n@3.4.0`):
 
 Це рішення задовольняє всі потреби i18n у проєкті Svelte. Але як і у випадку з i18next або іншими великими i18n рішеннями, воно трохи важке (~15.9kb, що приблизно в 7 разів більше за `svelte-intlayer`).
 
-### 3 — Рекомендації
+### 3 - Рекомендації
 
 **(Intlayer)** (`svelte-intlayer@8.7.12`):
 

package/docs/uk/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
+updatedAt: 2026-05-18
 title: Найкраще i18n рішення для TanStack Start у 2026 році - Звіт бенчмарку
 description: Порівняйте бібліотеки інтернаціоналізації для TanStack Start, такі як react-i18next, use-intl та Intlayer. Детальний звіт про продуктивність за розміром бандла, витоком та реактивністю.
 keywords:
@@ -17,12 +17,15 @@ slugs:
 author: Aymeric PINEAU
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
+  - version: 8.9.8
+    date: 2026-05-18
+    changes: "Додати порівняння зірок GitHub"
   - version: 8.7.5
     date: 2026-01-06
     changes: "Ініціалізація бенчмарку"
 ---
 
-# Бібліотеки i18n для TanStack Start — Звіт бенчмарку 2026
+# Бібліотеки i18n для TanStack Start - Звіт бенчмарку 2026
 
 Ця сторінка є звітом бенчмарку i18n рішень на TanStack Start.
 
@@ -105,7 +108,7 @@ history:
 - `gt-react` (vlatest)
 - `lingo.dev` (v0.133.9)
 
-Фреймворк — `TanStack Start` з багатомовним додатком на **10 сторінок** та **10 мов**.
+Фреймворк - `TanStack Start` з багатомовним додатком на **10 сторінок** та **10 мов**.
 
 Ми порівняли **чотири стратегії завантаження**:
 
@@ -121,9 +124,15 @@ history:
 - **Scoped static**: Зберігає код структурованим (логічний поділ) без складних мережевих запитів.
 - **Scoped dynamic**: Найкращий підхід для _розділення коду_ (code splitting) та продуктивності. Мінімізує обсяг пам'яті, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
 
+## Зірки на GitHub
+
+Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=formatjs%2Fformatjs%2Ci18next%2Freact-i18next%2Clingui%2Fjs-lingui%2Camannn%2Fnext-intl%2Copral%2paraglide-js%2Ctolgee%2Ftolgee-js%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#formatjs/formatjs&i18next/react-i18next&lingui/js-lingui&amannn/next-intl&opral/paraglide-js&tolgee/tolgee-js&aymericzip/intlayer)
+
 ## Детальні результати
 
-### 1 — Рішення, яких слід уникати
+### 1 - Рішення, яких слід уникати
 
 Деяких рішень, таких як `gt-react` або `lingo.dev`, явно варто триматися подалі. Вони поєднують прив'язку до вендора із засміченням вашої кодової бази. Гірше того: попри багато годин спроб їх впровадження, я так і не зміг забезпечити їх коректну роботу на TanStack Start (аналогічно до `gt-next` на Next.js).
 
@@ -145,19 +154,19 @@ history:
 - Під час збірки він повністю стирав згенеровані JSON-файли при додаванні нового контенту. У результаті лише кілька ключів могли знищити сотні наявних.
 - Я стикнувся з проблемами реактивності бібліотеки в TanStack Start: при зміні локалі довелося примусово перерендерити провайдер, щоб це запрацювало.
 
-### 2 — Експериментальні рішення
+### 2 - Експериментальні рішення
 
 **(Wuchale)** (`wuchale@0.22.11`):
 
 Ідея `Wuchale` цікава, але поки що не є життєздатним рішенням. Я зіткнувся з проблемами реактивності бібліотеки і був змушений примусово перерендерити провайдер, щоб додаток запрацював на TanStack Start. Документація також досить нечітка, що ускладнює освоєння.
 
-### 3 — Прийнятні рішення
+### 3 - Прийнятні рішення
 
 **(Paraglide)** (`@inlang/paraglide-js@2.15.1`):
 
 `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 врешті-решт стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
 
 **(Tolgee)** (`@tolgee/react@7.0.0`):
 
@@ -167,17 +176,17 @@ history:
 
 **(use-intl)** (`use-intl@4.9.1`):
 
-`use-intl` — це зараз наймодніша частина "intl" в екосистемі React (та ж родина, що й `next-intl`), яку часто просувають ШІ-агенти, але на мій погляд — помилково в контексті продуктивності. Почати роботу досить просто. На практиці ж процес оптимізації та обмеження витоків є досить складним. Аналогічно, поєднання динамічного завантаження + просторів імен + типів TypeScript сильно сповільнює розробку.
+`use-intl` - це зараз наймодніша частина "intl" в екосистемі React (та ж родина, що й `next-intl`), яку часто просувають ШІ-агенти, але на мій погляд - помилково в контексті продуктивності. Почати роботу досить просто. На практиці ж процес оптимізації та обмеження витоків є досить складним. Аналогічно, поєднання динамічного завантаження + просторів імен + типів TypeScript сильно сповільнює розробку.
 
 У TanStack Start ви уникаєте специфічних пасток Next.js (`setRequestLocale`, статичний рендеринг), але основна проблема та ж сама: без суворої дисципліни бандл швидко перевантажується повідомленнями, а підтримка просторів імен для кожного маршруту стає виснажливою.
 
 **(react-i18next)** (`react-i18next@17.0.2`):
 
-`react-i18next` — це, мабуть, найпопулярніший варіант, оскільки він був одним із перших, хто задовольнив потреби i18n у JS-додатках. Він також має великий набір плагінів від спільноти для конкретних проблем.
+`react-i18next` - це, мабуть, найпопулярніший варіант, оскільки він був одним із перших, хто задовольнив потреби i18n у JS-додатках. Він також має великий набір плагінів від спільноти для конкретних проблем.
 
 Проте він має ті ж недоліки, що й стеки на базі `t('a.b.c')`: оптимізація можлива, але забирає багато часу, а великі проекти ризикують скотитися до поганих практик (простори імен + динамічне завантаження + типи).
 
-Формати повідомлень також відрізняються: `use-intl` використовує ICU MessageFormat, тоді як `i18next` має власний формат — це ускладнює інструментарій або міграцію, якщо ви їх змішуєте.
+Формати повідомлень також відрізняються: `use-intl` використовує ICU MessageFormat, тоді як `i18next` має власний формат - це ускладнює інструментарій або міграцію, якщо ви їх змішуєте.
 
 **(Lingui)** (`@lingui/core@5.3.0`):
 
@@ -185,9 +194,9 @@ history:
 
 **(react-intl)** (`react-intl@10.1.1`):
 
-`react-intl` — це продуктивна реалізація від команди Format.js. DX залишається багатослівним: `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` додає складності, додаткової роботи JavaScript та прив'язує глобальний екземпляр i18n до багатьох вузлів у React-дереві.
+`react-intl` - це продуктивна реалізація від команди Format.js. DX залишається багатослівним: `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` додає складності, додаткової роботи JavaScript та прив'язує глобальний екземпляр i18n до багатьох вузлів у React-дереві.
 
-### 4 — Рекомендації
+### 4 - Рекомендації
 
 Цей бенчмарк TanStack Start не має прямого еквівалента `next-translate` (Next.js плагін + `getStaticProps`). Командам, які справді хочуть API у стилі `t()` зі зрілою екосистемою, `react-i18next` та `use-intl` залишаються "розумним" вибором, але будьте готові витратити багато часу на оптимізацію для уникнення витоків.
 

package/docs/uk/benchmark/vue.md

@@ -1,7 +1,7 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
-title: Найкраще i18n рішення для Vue у 2026 році — Звіт про бенчмарк
+updatedAt: 2026-05-18
+title: Найкраще i18n рішення для Vue у 2026 році - Звіт про бенчмарк
 description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Vue, такі як vue-i18n, fluent-vue та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
 keywords:
   - benchmark
@@ -17,12 +17,15 @@ slugs:
 author: Aymeric PINEAU
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
+  - version: 8.9.8
+    date: 2026-05-18
+    changes: "Додати порівняння зірок GitHub"
   - version: 8.7.12
     date: 2026-01-06
     changes: "Ініціалізація бенчмарку"
 ---
 
-# Бібліотеки i18n для Vue — Звіт про бенчмарк 2026
+# Бібліотеки i18n для Vue - Звіт про бенчмарк 2026
 
 Ця сторінка є звітом про бенчмарк рішень i18n на Vue.
 
@@ -97,7 +100,7 @@ style="border:none;"
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
-Фреймворк — `Vue` з багатомовним додатком із **10 сторінок** і **10 мов**.
+Фреймворк - `Vue` з багатомовним додатком із **10 сторінок** і **10 мов**.
 
 Ми порівняли **чотири стратегії завантаження**:
 
@@ -117,17 +120,17 @@ style="border:none;"
 
 Я запустив той самий багатомовний додаток у реальному браузері для кожного стека, а потім записав, що насправді пройшло мережею і скільки часу це зайняло. Розміри вказані **після звичайного веб-стиснення**, оскільки це ближче до того, що люди насправді завантажують, ніж необроблена кількість рядків вихідного коду.
 
-- **Розмір бібліотеки інтернаціоналізації**: Після бандлінгу, tree-shaking та мініфікації розмір бібліотеки i18n — це розмір коду провайдерів + composables у порожньому компоненті. Він не включає завантаження файлів перекладу. Це відповідає на питання, наскільки "дорогою" є бібліотека до того, як ваш контент з'явиться в кадрі.
+- **Розмір бібліотеки інтернаціоналізації**: Після бандлінгу, tree-shaking та мініфікації розмір бібліотеки i18n - це розмір коду провайдерів + composables у порожньому компоненті. Він не включає завантаження файлів перекладу. Це відповідає на питання, наскільки "дорогою" є бібліотека до того, як ваш контент з'явиться в кадрі.
 
-- **JavaScript на сторінку**: Для кожного маршруту бенчмарку, скільки скриптів завантажує браузер для цього відвідування, усереднено за сторінками в наборі (і за локалями). Важкі сторінки — це повільні сторінки.
+- **JavaScript на сторінку**: Для кожного маршруту бенчмарку, скільки скриптів завантажує браузер для цього відвідування, усереднено за сторінками в наборі (і за локалями). Важкі сторінки - це повільні сторінки.
 
 - **Витік з інших локалей (Leakage)**: Це контент тієї ж сторінки, але іншою мовою, який помилково завантажується на сторінці, що перевіряється. Цей контент є непотрібним і його слід уникати (наприклад: контент сторінки `/fr/about` у бандлі сторінки `/en/about`).
 
 - **Витік з інших маршрутів**: Та ж ідея для **інших екранів** у додатку: чи додається їхній текст, коли ви відкрили лише одну сторінку (наприклад: контент сторінки `/en/about` у бандлі сторінки `/en/contact`). Високий бал вказує на слабкий поділ або занадто широкі бандли.
 
-- **Середній розмір бандла компонента**: Загальні елементи інтерфейсу вимірюються **по одному**, замість того щоб ховатися всередині одного гігантського числа додатка. Це показує, чи інтернаціоналізація непомітно роздуває повсякденні компоненти. Наприклад, якщо ваш компонент перерендерюється, він завантажуватиме всі ці дані з пам'яті. Прикріплення гігантського JSON до будь-якого компонента — це як підключення великого сховища невикористовуваних даних, що сповільнить продуктивність ваших компонентів.
+- **Середній розмір бандла компонента**: Загальні елементи інтерфейсу вимірюються **по одному**, замість того щоб ховатися всередині одного гігантського числа додатка. Це показує, чи інтернаціоналізація непомітно роздуває повсякденні компоненти. Наприклад, якщо ваш компонент перерендерюється, він завантажуватиме всі ці дані з пам'яті. Прикріплення гігантського JSON до будь-якого компонента - це як підключення великого сховища невикористовуваних даних, що сповільнить продуктивність ваших компонентів.
 
-- **Швидкість реакції на зміну мови**: Я змінюю мову за допомогою власного контролера додатка і вимірюю час, поки сторінка чітко не зміниться — те, що помітить відвідувач.
+- **Швидкість реакції на зміну мови**: Я змінюю мову за допомогою власного контролера додатка і вимірюю час, поки сторінка чітко не зміниться - те, що помітить відвідувач.
 
 - **Робота рендерингу після зміни мови**: Більш точне спостереження: скільки зусиль доклав інтерфейс для перемальовування для нової мови після початку зміни. Корисно, коли "відчутний" час і витрати фреймворку розходяться.
 
@@ -135,13 +138,19 @@ style="border:none;"
 
 - **Час гідратації (Hydration)**: Час, який клієнт витрачає на перетворення серверного HTML на інтерактивний інтерфейс. Тире в таблицях означає, що ця реалізація не надала надійного показника гідратації в цьому бенчмарку.
 
+## Зірки на GitHub
+
+Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=intlify%2Fvue-i18n%2Cfluent-vue%2Ffluent-vue%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#intlify/vue-i18n&fluent-vue/fluent-vue&aymericzip/intlayer)
+
 ## Результати детально
 
-### 1 — Рішення, яких слід уникати
+### 1 - Рішення, яких слід уникати
 
 > В екосистемі Vue немає очевидних рішень, яких слід уникати.
 
-### 2 — Прийнятні рішення
+### 2 - Прийнятні рішення
 
 **(vue-i18n)** (`vue-i18n@11.4.0`):
 
@@ -153,7 +162,7 @@ style="border:none;"
 
 - **fluent-vue** пропонує спробу інновації через формат .ftl. Організація повідомлень чудова, легше почати роботу. Але на практиці відсутність безпеки типів підвищує ризик помилок і налагодження може швидко стати трудомістким. Більше того, це рішення завантажує повідомлення за допомогою плагіна vite, який змушує завантажувати весь контент усіма мовами на кожну сторінку. Крім того, це надзвичайно важке рішення (~92.7kb, що приблизно в 34 рази більше за `vue-intlayer`).
 
-### 3 — Рекомендації
+### 3 - Рекомендації
 
 **(Intlayer)** (`vue-intlayer@8.7.12`):
 

package/docs/uk/bundle_optimization.md

@@ -35,7 +35,7 @@ history:
 
 ## Сканування бандла
 
-Аналіз бандла — це перший крок до виявлення "важких" JSON-файлів та можливостей розділення коду. Ці інструменти генерують візуальну деревоподібну карту (treemap) скомпільованого коду вашого застосунку, дозволяючи вам точно побачити, які бібліотеки займають найбільше місця.
+Аналіз бандла - це перший крок до виявлення "важких" JSON-файлів та можливостей розділення коду. Ці інструменти генерують візуальну деревоподібну карту (treemap) скомпільованого коду вашого застосунку, дозволяючи вам точно побачити, які бібліотеки займають найбільше місця.
 
 <Tabs>
  <Tab value="vite">