@intlayer/docs 8.9.7 → 8.10.0-canary.0

package/docs/ru/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.
 
@@ -57,7 +60,7 @@ style="border:none;"
 
 Еще одним последствием использования библиотек 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')`).
 
 На этапе сборки Next.js создает один JS-бандл на локаль (например, `./locales_fr_12345.js`). Когда сайт отправляется клиенту и страница запускается, браузер выполняет дополнительный HTTP-запрос для необходимого JS-файла (например, `./locales_fr_12345.js`).
 
-> Другой способ решения той же проблемы — использование `fetch()` для динамической загрузки JSON. Так работает `Tolgee`, когда JSON находится в `/public`, или `next-translate`, который полагается на `getStaticProps` для загрузки контента. Процесс тот же: браузер делает дополнительный HTTP-запрос для загрузки ресурса.
+> Другой способ решения той же проблемы - использование `fetch()` для динамической загрузки JSON. Так работает `Tolgee`, когда JSON находится в `/public`, или `next-translate`, который полагается на `getStaticProps` для загрузки контента. Процесс тот же: браузер делает дополнительный HTTP-запрос для загрузки ресурса.
 
 **Разделение контента**
 
 Если вы используете синтаксис типа `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 пытается оптимизировать все эти аспек
 
 Я запускал одно и то же мультиязычное приложение в реальном браузере для каждого стека, а затем записывал, что на самом деле передавалось по сети и сколько времени это занимало. Размеры указаны **после обычного веб-сжатия**, так как это ближе к тому, что скачивают пользователи, чем количество исходного кода.
 
-- **Размер библиотеки интернационализации**: После сборки, tree-shaking и минимизации, размер i18n-библиотеки — это размер провайдеров (например, `NextIntlClientProvider`) + код хуков (например, `useTranslations`) в пустом компоненте. Это не включает загрузку файлов перевода. Это ответ на вопрос, насколько "дорогая" библиотека сама по себе до добавления вашего контента.
+- **Размер библиотеки интернационализации**: После сборки, tree-shaking и минимизации, размер i18n-библиотеки - это размер провайдеров (например, `NextIntlClientProvider`) + код хуков (например, `useTranslations`) в пустом компоненте. Это не включает загрузку файлов перевода. Это ответ на вопрос, насколько "дорогая" библиотека сама по себе до добавления вашего контента.
 
-- **JavaScript на страницу**: Для каждого маршрута бенчмарка — сколько скриптов браузер загружает при посещении, усредненное по страницам в наборе (и по локалям, где отчет их объединяет). Тяжелые страницы — это медленные страницы.
+- **JavaScript на страницу**: Для каждого маршрута бенчмарка - сколько скриптов браузер загружает при посещении, усредненное по страницам в наборе (и по локалям, где отчет их объединяет). Тяжелые страницы - это медленные страницы.
 
 - **Утечка из других локалей**: Это контент той же страницы, но на другом языке, который ошибочно загружается на проверяемую страницу. Этого контента следует избегать (например, контент страницы `/fr/about` в бандле страницы `/en/about`).
 
@@ -150,19 +153,25 @@ Intlayer пытается оптимизировать все эти аспек
 
 - **Средний размер бандла компонента**: Общие элементы пользовательского интерфейса измеряются **по отдельности**, а не прячутся внутри одного гигантского числа приложения. Это показывает, не раздувает ли интернационализация обычные компоненты. Например, если ваш компонент перерендеривается, он будет загружать все эти данные из памяти. Привязка гигантского JSON-файла к любому компоненту подобна подключению большого хранилища неиспользуемых данных, которое замедлит работу ваших компонентов.
 
-- **Скорость переключения языка**: Я переключаю язык с помощью собственного элемента управления приложения и засекаю время, пока страница явно не переключится — то, что заметит посетитель, а не лабораторный микро-шаг.
+- **Скорость переключения языка**: Я переключаю язык с помощью собственного элемента управления приложения и засекаю время, пока страница явно не переключится - то, что заметит посетитель, а не лабораторный микро-шаг.
 
 - **Работа по рендерингу после смены языка**: Более узкое наблюдение: сколько усилий потребовалось интерфейсу для перерисовки на новом языке после начала переключения. Полезно, когда "ощущаемое" время и стоимость фреймворка расходятся.
 
 - **Время начальной загрузки страницы**: От перехода до того момента, когда браузер считает страницу полностью загруженной для протестированных сценариев. Хорошо для сравнения "холодных стартов".
 
-- **Время гидратации**: Когда приложение предоставляет такие данные — сколько времени клиент тратит на превращение серверного HTML в нечто, на что можно нажать. Прочерк в таблицах означает, что данная реализация не предоставила надежных данных по гидратации в этом бенчмарке.
+- **Время гидратации**: Когда приложение предоставляет такие данные - сколько времени клиент тратит на превращение серверного 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`, явно лучше избегать. Они сочетают в себе привязку к вендору с загрязнением вашей кодовой базы. Несмотря на многие часы попыток их внедрить, мне так и не удалось заставить их работать — ни на TanStack Start, ни на Next.js.
+Некоторых решений, таких как `gt-next` или `lingo.dev`, явно лучше избегать. Они сочетают в себе привязку к вендору с загрязнением вашей кодовой базы. Несмотря на многие часы попыток их внедрить, мне так и не удалось заставить их работать - ни на 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 / куки и т.д. Это приводит к выполнению ненужной логики, которая влияет на реактивность компонентов.
 
-> Примечание по paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате показатель 'размер библиотеки' в отчете о бенчмарке практически равен 0. Генерация кода — это хорошо, так как используемая функция будет включать только необходимую логику (все префиксы против отсутствия префиксов, куки против хранилища и т.д.). В сравнении с этим, Intlayer выполняет фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить сборщик исключить контент в зависимости от логики. Благодаря этому paraglide и intlayer оказываются в 6-10 раз легче, чем i18next или next-intl.
+> Примечание по paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате показатель 'размер библиотеки' в отчете о бенчмарке практически равен 0. Генерация кода - это хорошо, так как используемая функция будет включать только необходимую логику (все префиксы против отсутствия префиксов, куки против хранилища и т.д.). В сравнении с этим, Intlayer выполняет фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить сборщик исключить контент в зависимости от логики. Благодаря этому paraglide и intlayer оказываются в 6-10 раз легче, чем i18next или next-intl.
 
-### 3 — Приемлемые решения
+### 3 - Приемлемые решения
 
 **(Tolgee)** (`@tolgee/react@7.0.0`):
 
@@ -203,7 +212,7 @@ Intlayer пытается оптимизировать все эти аспек
 
 **(Next Intl)** (`next-intl@4.9.1`):
 
-`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 сильно замедляет разработку. Пакет также довольно тяжелый (~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 I18next)** (`next-i18next@16.0.5`):
 
@@ -219,11 +228,11 @@ Intlayer пытается оптимизировать все эти аспек
 
 `Lingui` часто хвалят. Лично мне рабочий процесс с `lingui extract` / `lingui compile` показался более сложным, чем у альтернатив, без явных преимуществ. Я также заметил непоследовательный синтаксис, который путает AI (например, `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/ru/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
+updatedAt: 2026-05-18
 title: Лучшее i18n решение для Solid в 2026 году - Отчет о бенчмарке
 description: Сравните библиотеки интернационализации (i18n) для Solid, такие как solid-primitives, solid-i18next и Intlayer. Подробный отчет о производительности, размере бандла, утечках и реактивности.
 keywords:
@@ -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.
 
@@ -54,7 +57,7 @@ history:
 
 На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.
 
-Другой аспект — это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
+Другой аспект - это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
 
 ## TL;DR
 
@@ -98,7 +101,7 @@ history:
 - `solid-i18next` (v17.0.2)
 - `@inlang/paraglide-js` (v2.17.0)
 
-Фреймворк — `Solid` с мультиязычным приложением из **10 страниц** и **10 языков**.
+Фреймворк - `Solid` с мультиязычным приложением из **10 страниц** и **10 языков**.
 
 Мы сравнили **четыре стратегии загрузки**:
 
@@ -114,13 +117,19 @@ history:
 - **Локальная статическая (Scoped static)**: Позволяет организовать код (логическое разделение) без сложных дополнительных сетевых запросов.
 - **Локальная динамическая (Scoped dynamic)**: Лучший подход для _разделения кода_ и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.
 
+## Звезды на 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`):
 
@@ -141,7 +150,7 @@ Solid primitive чрезвычайно легкий и эффективный.
 Лично мне не нравится необходимость регенерировать JS-файлы перед каждым пушем, что создает постоянный риск конфликтов при слиянии в PR.
 Наконец, по сравнению с другими решениями, Paraglide не использует стор (например, Solid signal) для получения текущей локали для рендеринга. Для каждого обработанного узла он запрашивает локаль из localStorage / куки и т.д. Это приводит к выполнению ненужной логики, что влияет на реактивность компонентов.
 
-### 3 — Рекомендации
+### 3 - Рекомендации
 
 **(Intlayer)** (`solid-intlayer@8.7.12`):
 

package/docs/ru/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
+updatedAt: 2026-05-18
 title: Лучшее i18n решение для Svelte в 2026 году - Отчет о бенчмарке
 description: Сравните библиотеки интернационализации (i18n) для Svelte, такие как svelte-i18n, Paraglide и Intlayer. Подробный отчет о производительности, размере бандла, утечках и реактивности.
 keywords:
@@ -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.
 
@@ -55,7 +58,7 @@ style="border:none;"
 
 На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.
 
-Другой аспект — это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
+Другой аспект - это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
 
 ## TL;DR
 
@@ -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)**: Лучший подход для _разделения кода_ и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.
 
+## Звезды на 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 / куки и т.д. Это приводит к выполнению ненужной логики, что влияет на реактивность компонентов.
 
-> Примечание о paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода — это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения во время сборки, чтобы заставить бандлер выполнять tree-shaking контента в зависимости от логики. Благодаря этому paraglide и intlayer в итоге оказываются в 6-10 раз легче, чем i18next или next-intl.
+> Примечание о paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода - это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения во время сборки, чтобы заставить бандлер выполнять tree-shaking контента в зависимости от логики. Благодаря этому paraglide и intlayer в итоге оказываются в 6-10 раз легче, чем i18next или next-intl.
 
 **(svelte-i18n)** (`svelte-i18n@3.4.0`):
 
 Это решение отвечает всем потребностям i18n в Svelte-проекте. Но, как и в случае с i18next или другими основными решениями i18n, оно немного тяжеловато (~15.9 КБ, что примерно в 7 раз больше `svelte-intlayer`).
 
-### 3 — Рекомендации
+### 3 - Рекомендации
 
 **(Intlayer)** (`svelte-intlayer@8.7.12`):
 

package/docs/ru/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.
 
@@ -55,7 +58,7 @@ history:
 
 На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.
 
-Другой аспект — это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
+Другой аспект - это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
 
 ## TL;DR
 
@@ -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)**: Лучший подход для _разделения кода_ и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.
 
+## Звезды на 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 (аналогично Next.js с `gt-next`).
 
@@ -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: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода — это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить бандлер выполнять tree-shaking контента в зависимости от логики. Благодаря этому paraglide и intlayer в итоге оказываются в 6-10 раз легче, чем i18next или next-intl.
+> Примечание о paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода - это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить бандлер выполнять tree-shaking контента в зависимости от логики. Благодаря этому paraglide и intlayer в итоге оказываются в 6-10 раз легче, чем i18next или next-intl.
 
 **(Tolgee)** (`@tolgee/react@7.0.0`):
 
@@ -167,7 +176,7 @@ history:
 
 **(use-intl)** (`use-intl@4.9.1`):
 
-`use-intl` — самый модный представитель "intl" в экосистеме React (из того же семейства, что и `next-intl`), который часто продвигают AI-агенты, но, на мой взгляд, ошибочно в контексте производительности. Начать работу довольно просто. На практике процесс оптимизации и ограничения утечек довольно сложен. Аналогично, сочетание динамической загрузки + пространств имен + типов TypeScript сильно замедляет разработку.
+`use-intl` - самый модный представитель "intl" в экосистеме React (из того же семейства, что и `next-intl`), который часто продвигают AI-агенты, но, на мой взгляд, ошибочно в контексте производительности. Начать работу довольно просто. На практике процесс оптимизации и ограничения утечек довольно сложен. Аналогично, сочетание динамической загрузки + пространств имен + типов TypeScript сильно замедляет разработку.
 
 На TanStack Start вы избегаете ловушек, специфичных для Next.js (`setRequestLocale`, статический рендеринг), но основная проблема та же: без строгой дисциплины бандл быстро переполняется сообщениями, а обслуживание пространств имен для каждого маршрута становится мучительным.
 
@@ -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/ru/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-04-21
+updatedAt: 2026-05-18
 title: Лучшее i18n решение для Vue в 2026 году - Отчет о бенчмарке
 description: Сравните библиотеки интернационализации (i18n) для Vue, такие как vue-i18n, fluent-vue и Intlayer. Подробный отчет о производительности, размере бандла, утечках и реактивности.
 keywords:
@@ -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.
 
@@ -55,7 +58,7 @@ style="border:none;"
 
 На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.
 
-Другой аспект — это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
+Другой аспект - это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
 
 ## TL;DR
 
@@ -97,7 +100,7 @@ style="border:none;"
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
-Фреймворк — `Vue` с мультиязычным приложением из **10 страниц** и **10 языков**.
+Фреймворк - `Vue` с мультиязычным приложением из **10 страниц** и **10 языков**.
 
 Мы сравнили **четыре стратегии загрузки**:
 
@@ -117,9 +120,9 @@ style="border:none;"
 
 Я запускал одно и то же мультиязычное приложение в реальном браузере для каждого стека, а затем фиксировал, что на самом деле передавалось по сети и сколько времени это занимало. Размеры указаны **после обычного веб-сжатия**, так как это ближе к тому, что люди реально скачивают.
 
-- **Размер библиотеки интернационализации**: После сборки, tree-shaking и минификации, размер библиотеки i18n — это размер кода провайдеров + композиблов (composables) в пустом компоненте. Это не включает загрузку файлов перевода. Это показывает, насколько "дорогая" библиотека еще до появления вашего контента.
+- **Размер библиотеки интернационализации**: После сборки, tree-shaking и минификации, размер библиотеки i18n - это размер кода провайдеров + композиблов (composables) в пустом компоненте. Это не включает загрузку файлов перевода. Это показывает, насколько "дорогая" библиотека еще до появления вашего контента.
 
-- **JavaScript на страницу**: Для каждого тестового маршрута — сколько скриптов загружает браузер во время посещения, усреднено по страницам теста (и по локалям). Тяжелые страницы — это медленные страницы.
+- **JavaScript на страницу**: Для каждого тестового маршрута - сколько скриптов загружает браузер во время посещения, усреднено по страницам теста (и по локалям). Тяжелые страницы - это медленные страницы.
 
 - **Утечка из других локалей (Leakage)**: Это контент той же страницы, но на другом языке, который по ошибке загружается на проверяемую страницу. Этот контент является лишним и его следует избегать (например, контент страницы `/fr/about` в бандле страницы `/en/about`).
 
@@ -127,7 +130,7 @@ style="border:none;"
 
 - **Средний размер бандла компонента**: Отдельные UI-элементы измеряются **по одному**, а не прячутся внутри одного гигантского общего показателя приложения. Это показывает, "раздувает" ли интернационализация обычные компоненты. Например, если ваш компонент перерендерится, он будет загружать все эти данные из памяти. Привязка гигантского 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.7 КБ, что примерно в 34 раза больше `vue-intlayer`).
 
-### 3 — Рекомендации
+### 3 - Рекомендации
 
 **(Intlayer)** (`vue-intlayer@8.7.12`):
 

package/docs/ru/bundle_optimization.md

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