@intlayer/docs 9.5.1 → 9.5.2

package/docs/ru/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** из-за серьезных проблем с производительностью, привязки к вендору и багов, ломающих сборку.
 
 ## Проверьте свое приложение
@@ -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/ru/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ru/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` (Квота превышена, пожалуйста, обновите тарифный план) при самой первой сборке с General Translation.
 - Переводы не отображаются; я получаю ошибку `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 / куки и т.д. Это приводит к выполнению ненужной логики, которая влияет на реактивность компонентов.
 
-> Примечание по paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате показатель 'размер библиотеки' в отчете о бенчмарке практически равен 0. Генерация кода - это хорошо, так как используемая функция будет включать только необходимую логику (все префиксы против отсутствия префиксов, куки против хранилища и т.д.). В сравнении с этим, Intlayer выполняет фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить сборщик исключить контент в зависимости от логики. Благодаря этому paraglide и intlayer оказываются в 6-10 раз легче, чем i18next или next-intl.
+> Примечание по paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате показатель 'размер библиотеки' в отчете о бенчмарке практически равен 0. Генерация кода - это хорошо, так как используемая функция будет включать только необходимую логику (все префиксы против отсутствия префиксов, куки против хранилища и т.д.). В сравнении с этим, Intlayer выполняет фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить сборщик исключить контент в зависимости от логики. Благодаря этому paraglide и intlayer оказываются в 3-8 раз легче, чем i18next или next-intl.
 
 ### 3 - Приемлемые решения
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` решает многие из упомянутых ранее проблем. Мне показалось, что его сложнее внедрить, чем аналогичные инструменты. Он не обеспечивает типобезопасность, что также затрудняет отлов отсутствующих ключей на этапе компиляции. Мне пришлось обернуть функции Tolgee своими собственными, чтобы добавить обнаружение отсутствующих ключей.
 
-**(Next Intl)** (`next-intl@4.9.1`):
+**(Next Intl)** (`next-intl@4.14.2`):
 
-`next-intl` - самый модный вариант, который чаще всего продвигают AI-агенты, но, на мой взгляд, ошибочно. Начать работу легко. На практике оптимизация для ограничения утечек сложна. Сочетание динамической загрузки + пространств имен + типов TypeScript сильно замедляет разработку. Пакет также довольно тяжелый (~13 КБ для `NextIntlClientProvider` + `useTranslations`, что более чем в 2 раза больше `next-intlayer`). **next-intl** раньше блокировал статический рендеринг страниц Next.js. Он предоставляет помощник под названием `setRequestLocale()`. Кажется, это частично решено для централизованных файлов типа `en.json` / `fr.json`, но статический рендеринг все равно ломается, когда контент разделен на пространства имен, такие как `en/shared.json` / `fr/shared.json` / `es/shared.json`.
+`next-intl` - самый модный вариант, который чаще всего продвигают AI-агенты, но, на мой взгляд, ошибочно. Начать работу легко. На практике оптимизация для ограничения утечек сложна. Сочетание динамической загрузки + пространств имен + типов 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-решений для JavaScript-приложений. У него много плагинов от сообщества. У него те же основные недостатки, что и у `next-intl`. Пакет особенно тяжелый (~18 КБ для `I18nProvider` + `useTranslation`, примерно в 3 раза тяжелее `next-intlayer`).
+`next-i18next`, вероятно, является самым популярным вариантом, так как был одним из первых i18n-решений для JavaScript-приложений. У него много плагинов от сообщества. У него те же основные недостатки, что и у `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` показался более сложным, чем у альтернатив, без явных преимуществ. Я также заметил непоследовательный синтаксис, который путает AI (например, `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/ru/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"
@@ -61,9 +64,9 @@ history:
 
 ## TL;DR
 
-- **Intlayer**: Рекомендуемый выбор для профессиональных Solid-приложений, требующих расширенных функций и оптимизации (v8.7.12).
+- **Intlayer**: Рекомендуемый выбор для профессиональных Solid-приложений, требующих расширенных функций и оптимизации (v9.5.0).
 - **@solid-primitives/i18n**: Отличная легкая альтернатива для простых проектов, хотя ей не хватает расширенных функций, таких как ленивая загрузка.
-- **solid-i18next**: Стандартный, но тяжелый вариант (~4.7 раза больше Intlayer) с теми же недостатками, что и React i18next.
+- **solid-i18next**: Стандартный, но тяжелый вариант (~3.5 раза больше Intlayer) с теми же недостатками, что и React i18next.
 - **Paraglide**: Инновационный подход, но сложный DX и проблемы с tree-shaking в некоторых конфигурациях.
 
 ## Проверьте свое приложение
@@ -96,10 +99,10 @@ history:
 Для этого бенчмарка мы сравнили следующие библиотеки:
 
 - `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 языков**.
 
@@ -153,11 +156,11 @@ history:
 
 ### 2 - Приемлемые решения
 
-**(solid-i18next)** (`solid-i18next@17.0.2`):
+**(solid-i18next)** (`i18next@26.0.8`):
 
 `solid-i18next`, вероятно, является самым популярным вариантом, так как был одним из первых решений для нужд i18n в JavaScript-приложениях. У него также есть широкий набор плагинов от сообщества для конкретных задач.
 
-Пакет тяжелый (~14.6 КБ, что примерно в 4.7 раза больше `solid-intlayer`).
+Пакет тяжелый (~14.9 КБ, что примерно в 3.5 раза больше `solid-intlayer`).
 
 Тем не менее, у него те же основные недостатки, что и у стеков, построенных на `t('a.b.c')`: оптимизация возможна, но отнимает очень много времени, а большие проекты рискуют столкнуться с плохими практиками (пространства имен + динамическая загрузка + типы).
 
@@ -166,7 +169,7 @@ history:
 Solid primitive чрезвычайно легкий и эффективный. Я рекомендую это решение для небольших проектов, но ему может быстро перестать хватать функций для профессиональных решений, включая управление куки, перенаправление прокси, форматировщики и т. д.
 В нем также отсутствует ленивая загрузка и разделение пространств имен для оптимизации размера страницы.
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` предлагает инновационный, хорошо продуманный подход. Тем не менее, в этом бенчмарке рекламируемый ими tree-shaking не сработал для моей реализации. Процесс работы и DX также сложнее, чем у других вариантов.
 Лично мне не нравится необходимость регенерировать JS-файлы перед каждым пушем, что создает постоянный риск конфликтов при слиянии в PR.
@@ -174,7 +177,7 @@ Solid primitive чрезвычайно легкий и эффективный.
 
 ### 3 - Рекомендации
 
-**(Intlayer)** (`solid-intlayer@8.7.12`):
+**(Intlayer)** (`solid-intlayer@9.5.0`):
 
 Я не буду лично оценивать `solid-intlayer` ради объективности, так как это мое собственное решение.
 

package/docs/ru/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) с минимальным влиянием на размер.
+- **Intlayer**: Самый эффективный выбор с точки зрения производительности (v9.5.0) с минимальным влиянием на размер.
 - **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: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода - это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения во время сборки (build time), чтобы заставить бандлер выполнять 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.9 КБ, что примерно в 7 раз больше `svelte-intlayer`).
+Это решение отвечает всем потребностям i18n в Svelte-проекте. Но, как и в случае с i18next или другими основными решениями i18n, оно немного тяжеловато (~16.6 КБ, что примерно в 4.5 раз больше `svelte-intlayer`).
 
 ### 3 - Рекомендации
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`):
+**(Intlayer)** (`svelte-intlayer@9.5.0`):
 
 Я не буду лично оценивать `svelte-intlayer` ради объективности, так как это мое собственное решение.
 

package/docs/ru/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** из-за серьезных проблем с производительностью, лимитов AI и привязки к вендору (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/ru/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` (Квота превышена, пожалуйста, обновите тарифный план) при самой первой сборке с General Translation.
 - Переводы не отображаются; я получаю ошибку `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: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода - это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить бандлер выполнять tree-shaking контента в зависимости от логики. Благодаря этому paraglide и intlayer в итоге оказываются в 6-10 раз легче, чем i18next или next-intl.
+> Примечание о paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода - это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить бандлер выполнять tree-shaking контента в зависимости от логики. Благодаря этому paraglide и intlayer в итоге оказываются в 3-10 раз легче, чем i18next или next-intl.
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` решает многие из упомянутых ранее проблем. Мне показалось, что начать работу с ним сложнее, чем с другими инструментами с похожими подходами. Он не обеспечивает типобезопасность, что значительно затрудняет отлов отсутствующих ключей на этапе компиляции. Мне пришлось обернуть API Tolgee своими собственными, чтобы добавить обнаружение отсутствующих ключей.
 
@@ -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`), который часто продвигают AI-агенты, но, на мой взгляд, ошибочно в контексте производительности. Начать работу довольно просто. На практике процесс оптимизации и ограничения утечек довольно сложен. Аналогично, сочетание динамической загрузки + пространств имен + типов TypeScript сильно замедляет разработку.
 
 На TanStack Start вы избегаете ловушек, специфичных для Next.js (`setRequestLocale`, статический рендеринг), но основная проблема та же: без строгой дисциплины бандл быстро переполняется сообщениями, а обслуживание пространств имен для каждого маршрута становится мучительным.
 
-**(react-i18next)** (`react-i18next@17.0.2`):
+**(react-i18next)** (`react-i18next@17.0.13`):
 
 `react-i18next`, вероятно, является самым популярным вариантом, так как был одним из первых решений для нужд i18n в JavaScript-приложениях. У него также есть широкий набор плагинов от сообщества для конкретных задач.
 
 Тем не менее, у него те же основные недостатки, что и у стеков, построенных на `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. Я также заметил непоследовательный синтаксис, который путает AI (например, `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/ru/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**: Индустриальный стандарт с богатой экосистемой, но может быть значительно тяжелее и сложнее в оптимизации для разделения кода в больших приложениях.
 - **fluent-vue**: Инновационная организация сообщений, но не хватает типобезопасности и является чрезвычайно тяжелым решением.
 
@@ -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/ru/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 интегрирует ленивую загрузку сообщений, в нем отсутствует функция разделения (scoping). В случае классического Vue SPA приложения это не проблема, но для приложения Nuxt, использующего @nuxt/i18n, это приводит к включению сообщений со всех страниц в одну. Для большого приложения Nuxt, включающего более 10 страниц, это может стать действительно проблематичным.
 
-Пакет очень тяжелый (~24.3 КБ, что примерно в 9 раз больше `vue-intlayer`).
+Пакет очень тяжелый (~24.3 КБ, что примерно в 6 раз больше `vue-intlayer`).
 
-**(fluent-vue)** (`fluent-vue@0.5.0`):
+**(fluent-vue)** (`fluent-vue@3.8.2`):
 
-- **fluent-vue** предлагает попытку инновации через формат .ftl. Организация сообщений отличная, с ней легче начать работу. Но на практике отсутствие типобезопасности повышает риск ошибок и может быстро стать трудозатратным при отладке. Более того, это решение загружает сообщения с помощью плагина vite, который принудительно загружает весь контент на всех языках в каждую страницу. Кроме того, это чрезвычайно тяжелое решение (~92.7 КБ, что примерно в 34 раза больше `vue-intlayer`).
+- **fluent-vue** предлагает попытку инновации через формат .ftl. Организация сообщений отличная, с ней легче начать работу. Но на практике отсутствие типобезопасности повышает риск ошибок и может быстро стать трудозатратным при отладке. Более того, это решение загружает сообщения с помощью плагина vite, который принудительно загружает весь контент на всех языках в каждую страницу. Кроме того, это чрезвычайно тяжелое решение (~29.7 КБ, что примерно в 7.5 раза больше `vue-intlayer`).
 
 ### 3 - Рекомендации
 
-**(Intlayer)** (`vue-intlayer@8.7.12`):
+**(Intlayer)** (`vue-intlayer@9.5.0`):
 
 Я не буду лично оценивать `vue-intlayer` ради объективности, так как это мое собственное решение.

package/docs/ru/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/ru/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/ru/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`**: Включить подробное логирование для отладки. (по умолчанию включено при использовании CLI)

package/docs/ru/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`**: Включить подробное логирование для отладки. (по умолчанию включено при использовании CLI)