@intlayer/docs 8.9.4-canary.0 → 8.9.5

package/docs/pt/plugins/sync-po.md

@@ -0,0 +1,333 @@
+---
+createdAt: 2026-05-10
+updatedAt: 2026-05-10
+title: Plugin Sync PO
+description: Sincronize os dicionários Intlayer com arquivos Gettext PO. Mantenha seu i18n existente enquanto usa o Intlayer para gerenciar, traduzir e testar suas mensagens.
+keywords:
+  - Intlayer
+  - Sync PO
+  - Gettext
+  - i18n
+  - traduções
+slugs:
+  - doc
+  - plugin
+  - sync-po
+youtubeVideo: https://www.youtube.com/watch?v=MpGMxniDHNg
+history:
+  - version: 8.9.4
+    date: 2026-05-10
+    changes: "Documentação inicial do plugin Sync PO"
+---
+
+# Sync PO (pontes i18n) - Sync PO com suporte a ICU / i18next
+
+Use o Intlayer como um complemento à sua stack de i18n existente. Este plugin mantém suas mensagens Gettext PO em sincronia com os dicionários Intlayer para que você possa:
+
+- Manter seu fluxo de trabalho de tradução baseado em PO existente.
+- Gerenciar e traduzir suas mensagens com o Intlayer (CLI, CI, provedores, CMS), sem refatorar seu aplicativo.
+- Enviar tutoriais e conteúdo de SEO direcionados a cada ecossistema, sugerindo o Intlayer como a camada de gerenciamento de PO.
+
+Notas e escopo atual:
+
+- A externalização para o CMS funciona para traduções e texto clássico.
+- Ainda não há suporte para inserções, plurais/ICU ou recursos avançados de tempo de execução de outras bibliotecas dentro das próprias entradas PO.
+- O editor visual ainda não é suportado para saídas i18n de terceiros.
+
+### Quando usar este plugin
+
+- Você já usa arquivos Gettext PO para suas traduções.
+- Você deseja preenchimento assistido por IA, testes em CI e operações de conteúdo sem alterar seu tempo de execução de renderização.
+
+## Instalação
+
+```bash
+pnpm add -D @intlayer/sync-po-plugin
+# ou
+npm i -D @intlayer/sync-po-plugin
+```
+
+## Plugins
+
+Este pacote fornece dois plugins:
+
+- `loadPO`: Carrega arquivos PO nos dicionários Intlayer.
+  - Este plugin é usado para carregar arquivos PO de uma fonte e eles serão carregados nos dicionários Intlayer. Ele pode escanear toda a base de código e procurar por arquivos PO específicos.
+    Este plugin pode ser usado:
+    - se você usa uma biblioteca i18n que impõe um local específico para que seus arquivos PO sejam carregados, mas você deseja colocar sua declaração de conteúdo onde preferir em sua base de código.
+    - Também pode ser usado se você desejar buscar suas mensagens de uma fonte remota (ex: um CMS, uma API, etc.) e armazenar suas mensagens em arquivos PO.
+
+  > Por baixo dos panos, este plugin escaneará toda a base de código e procurará por arquivos PO específicos e os carregará nos dicionários Intlayer.
+  > Observe que este plugin não gravará a saída e as traduções de volta nos arquivos PO.
+
+- `syncPO`: Sincroniza arquivos PO com dicionários Intlayer.
+  - Este plugin é usado para sincronizar arquivos PO com dicionários Intlayer. Ele pode escanear o local fornecido e carregar o PO que corresponde ao padrão para arquivos PO específicos. Este plugin é útil se você deseja obter os benefícios do Intlayer enquanto usa outra biblioteca i18n.
+
+## Usando ambos os plugins
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO, syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  // Mantenha seus arquivos PO atuais em sincronia com os dicionários Intlayer
+  plugins: [
+    /**
+     * Carregará todos os arquivos PO no src que correspondem ao padrão {key}.i18n.po
+     */
+    loadPO({
+      source: ({ key }) => `./src/**/${key}.i18n.po`,
+      locale: Locales.ENGLISH,
+      priority: 1, // Garante que esses arquivos PO tenham precedência sobre os arquivos em `./locales/en/${key}.po`
+    }),
+    /**
+     * Carregará e gravará a saída e as traduções de volta nos arquivos PO no diretório locales
+     */
+    syncPO({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      priority: 0,
+    }),
+  ],
+};
+
+export default config;
+```
+
+## Plugin `syncPO`
+
+### Início rápido
+
+Adicione o plugin ao seu `intlayer.config.ts` e aponte-o para sua estrutura PO existente.
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  // Mantenha seus arquivos PO atuais em sincronia com os dicionários Intlayer
+  plugins: [
+    syncPO({
+      // Layout por idioma, por namespace
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+    }),
+  ],
+};
+
+export default config;
+```
+
+Alternativa: arquivo único por idioma:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  plugins: [
+    syncPO({
+      source: ({ locale }) => `./locales/${locale}.po`,
+    }),
+  ],
+};
+
+export default config;
+```
+
+#### Como funciona
+
+- Leitura: o plugin descobre arquivos PO a partir do seu construtor `source` e os carrega como dicionários Intlayer.
+- Gravação: após compilações e preenchimentos, ele grava o PO localizado de volta nos mesmos caminhos (com cabeçalhos Gettext apropriados).
+- Preenchimento automático: o plugin declara um caminho `autoFill` para cada dicionário. Executar `intlayer fill` atualiza apenas as traduções ausentes em seus arquivos PO por padrão.
+
+API:
+
+```ts
+syncPO({
+  source: ({ key, locale }) => string, // obrigatório
+  location?: string, // rótulo opcional, padrão: "sync-po::path/to/source"
+  priority?: number, // prioridade opcional para resolução de conflitos, padrão: 0
+});
+```
+
+### Múltiplas fontes PO e prioridade
+
+Você pode adicionar vários plugins `syncPO` para sincronizar diferentes fontes PO. Isso é útil quando você tem várias fontes de tradução ou estruturas PO diferentes em seu projeto.
+
+#### Sistema de prioridade
+
+Quando vários plugins visam a mesma chave de dicionário, o parâmetro `priority` determina qual plugin tem precedência:
+
+- Números de prioridade mais altos vencem os mais baixos
+- A prioridade padrão dos arquivos `.content` é `0`
+- A prioridade padrão dos plugins é `0`
+- Plugins com a mesma prioridade são processados na ordem em que aparecem na configuração
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  plugins: [
+    // Fonte PO primária (maior prioridade)
+    syncPO({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      location: "main-translations",
+      priority: 10,
+    }),
+
+    // Fonte PO de fallback (prioridade mais baixa)
+    syncPO({
+      source: ({ locale }) => `./fallback-locales/${locale}.po`,
+      location: "fallback-translations",
+      priority: 5,
+    }),
+
+    // Fonte PO legada (prioridade mínima)
+    syncPO({
+      source: ({ locale }) => `/my/other/app/legacy/${locale}/messages.po`,
+      location: "legacy-translations",
+      priority: 1,
+    }),
+  ],
+};
+
+export default config;
+```
+
+## Plugin Load PO
+
+### Início rápido
+
+Adicione o plugin ao seu `intlayer.config.ts` para ingerir arquivos PO existentes como dicionários Intlayer. Este plugin é apenas para leitura (sem gravações no disco):
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  plugins: [
+    // Ingerir mensagens PO localizadas em qualquer lugar em sua árvore de fontes
+    loadPO({
+      source: ({ key }) => `./src/**/${key}.i18n.po`,
+      // Carregar um único idioma por instância de plugin (o padrão é o defaultLocale da configuração)
+      locale: Locales.ENGLISH,
+      priority: 0,
+    }),
+  ],
+};
+
+export default config;
+```
+
+Alternativa: layout por idioma, ainda apenas leitura (apenas o idioma selecionado é carregado):
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  plugins: [
+    loadPO({
+      // Apenas arquivos para Locales.FRENCH serão carregados a partir deste padrão
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      locale: Locales.FRENCH,
+    }),
+  ],
+};
+
+export default config;
+```
+
+### Como funciona
+
+- Descoberta: constrói um glob a partir do seu construtor `source` e coleta arquivos PO correspondentes.
+- Ingestão: carrega cada arquivo PO como um dicionário Intlayer com o `locale` fornecido.
+- Apenas leitura: não grava nem formata arquivos de saída; use `syncPO` se precisar de sincronização de ida e volta.
+- Pronto para preenchimento automático: define um caminho `fill` para que o `intlayer content fill` possa preencher as chaves ausentes.
+
+### API
+
+```ts
+loadPO({
+  // Construir caminhos para seus POs. `locale` é opcional se sua estrutura não tiver segmento de idioma
+  source: ({ key, locale }) => string,
+
+  // Idioma de destino para os dicionários carregados por esta instância de plugin
+  // O padrão é configuration.internationalization.defaultLocale
+  locale?: Locale,
+
+  // Rótulo opcional para identificar a fonte
+  location?: string, // padrão: "plugin"
+
+  // Prioridade usada para resolução de conflitos com outras fontes
+  priority?: number, // padrão: 0
+});
+```
+
+### Comportamento e convenções
+
+- Se sua máscara `source` incluir um marcador de posição de idioma, apenas arquivos para o `locale` selecionado serão ingeridos.
+- Se não houver um segmento `{key}` em sua máscara, a chave do dicionário será "index".
+- As chaves são derivadas dos caminhos dos arquivos substituindo o marcador de posição `{key}` em seu construtor `source`.
+- O plugin usa apenas arquivos descobertos e não fabrica idiomas ou chaves ausentes.
+- O caminho `fill` é inferido a partir da sua `source` e usado para atualizar valores ausentes via CLI quando você aceita.
+
+## Resolução de conflitos
+
+Quando a mesma chave de tradução existe em várias fontes PO:
+
+1. O plugin com a maior prioridade determina o valor final
+2. Fontes de menor prioridade são usadas como fallback para chaves ausentes
+3. Isso permite que você mantenha traduções legadas enquanto migra gradualmente para novas estruturas
+
+## CLI
+
+Os arquivos PO sincronizados serão considerados como outros arquivos `.content`. Isso significa que todos os comandos do intlayer estarão disponíveis para os arquivos PO sincronizados. Incluindo:
+
+- `intlayer content test` para testar se há traduções ausentes
+- `intlayer content list` para listar os arquivos PO sincronizados
+- `intlayer content fill` para preencher as traduções ausentes
+- `intlayer content push` para enviar os arquivos PO sincronizados
+- `intlayer content pull` para baixar os arquivos PO sincronizados
+
+Consulte o [Intlayer CLI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/cli/index.md) para mais detalhes.
+
+## Limitações (atuais)
+
+- Sem suporte para inserções ou plurais/ICU ao visar bibliotecas de terceiros.
+- O editor visual ainda não está disponível para tempos de execução que não sejam Intlayer.
+- Sincronização PO apenas; formatos de catálogo não-PO não são suportados.
+
+## Por que isso importa
+
+- Podemos recomendar soluções de i18n estabelecidas e posicionar o Intlayer como um complemento.
+- Aproveitamos seu SEO/palavras-chave com tutoriais que terminam sugerindo o Intlayer para gerenciar PO.
+- Expande o público endereçável de “novos projetos” para “qualquer equipe que já use i18n”.

package/docs/ru/benchmark/nextjs.md

@@ -61,6 +61,13 @@ history:
 
 Intlayer пытается оптимизировать все эти аспекты.
 
+## TL;DR
+
+- **Intlayer** и **next-translate**: Лучшие варианты для производительности Next.js, предлагающие минимальный размер и лучшую поддержку статического рендеринга.
+- **next-intl**: Самый модный вариант, но тяжелый и сложный в оптимизации для больших приложений.
+- **next-i18next**: Популярный и богатый плагинами, но имеет значительный вес бандла (~3× Intlayer).
+- **Избегайте**: **gt-next** и **lingo.dev** из-за серьезных проблем с производительностью, привязки к вендору и багов, ломающих сборку.
+
 ## Проверьте свое приложение
 
 Чтобы выявить эти проблемы, я создал бесплатный сканер, который вы можете попробовать [здесь](https://intlayer.org/i18n-seo-scanner).
@@ -99,14 +106,14 @@ Intlayer пытается оптимизировать все эти аспек
 Для этого бенчмарка мы сравнили следующие библиотеки:
 
 - `Base App` (Без библиотеки i18n)
-- `next-intlayer` (v8.7.5)
+- `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-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `@lingo.dev/compiler` (v0.4.0)
 - `wuchale` (v0.22.11)
 - `gt-next` (v6.16.5)
@@ -161,10 +168,10 @@ Intlayer пытается оптимизировать все эти аспек
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- Для приложения весом 110 КБ `gt-react` добавляет более 440 КБ сверху.
+- Для приложения весом 110 КБ `gt-next` добавляет более 440 КБ сверху.
 - `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 часов.
+- При внедрении **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`):
@@ -186,9 +193,11 @@ Intlayer пытается оптимизировать все эти аспек
 Лично мне не нравится необходимость перегенерировать JS-файлы перед каждым пушем, что создает постоянный риск конфликтов слияния в PR. Инструмент также кажется более ориентированным на Vite, чем на Next.js.
 Наконец, по сравнению с другими решениями, Paraglide не использует хранилище (например, React context) для получения текущей локали для рендеринга контента. Для каждого обрабатываемого узла он запрашивает локаль из localStorage / куки и т.д. Это приводит к выполнению ненужной логики, которая влияет на реактивность компонентов.
 
+> Примечание по paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате показатель 'размер библиотеки' в отчете о бенчмарке практически равен 0. Генерация кода — это хорошо, так как используемая функция будет включать только необходимую логику (все префиксы против отсутствия префиксов, куки против хранилища и т.д.). В сравнении с этим, Intlayer выполняет фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить сборщик исключить контент в зависимости от логики. Благодаря этому paraglide и intlayer оказываются в 6-10 раз легче, чем i18next или next-intl.
+
 ### 3 — Приемлемые решения
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` решает многие из упомянутых ранее проблем. Мне показалось, что его сложнее внедрить, чем аналогичные инструменты. Он не обеспечивает типобезопасность, что также затрудняет отлов отсутствующих ключей на этапе компиляции. Мне пришлось обернуть функции Tolgee своими собственными, чтобы добавить обнаружение отсутствующих ключей.
 
@@ -216,7 +225,7 @@ Intlayer пытается оптимизировать все эти аспек
 
 `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.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 Я не буду лично судить о `next-intlayer` ради объективности, так как это мое собственное решение.
 

package/docs/ru/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Лучшее i18n решение для Solid в 2026 году - Отчет о бенчмарке
+description: Сравните библиотеки интернационализации (i18n) для Solid, такие как solid-primitives, solid-i18next и Intlayer. Подробный отчет о производительности, размере бандла, утечках и реактивности.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - производительность
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Инициализация бенчмарка"
+---
+
+# Библиотеки i18n для Solid — Отчет о бенчмарке 2026
+
+Эта страница представляет собой отчет о бенчмарке i18n-решений для Solid.
+
+## Содержание
+
+<Toc/>
+
+## Интерактивный бенчмарк
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Ссылка на результаты:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+Полный репозиторий бенчмарка можно найти [здесь](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Введение
+
+Решения для интернационализации являются одними из самых тяжелых зависимостей в Solid-приложении. Основной риск заключается в передаче ненужного контента: переводов для других страниц и других локалей в бандле одного маршрута.
+
+По мере роста вашего приложения эта проблема может быстро привести к раздуванию JavaScript, отправляемого клиенту, и замедлению навигации.
+
+На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.
+
+Другой аспект — это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.
+
+## TL;DR
+
+- **Intlayer**: Рекомендуемый выбор для профессиональных Solid-приложений, требующих расширенных функций и оптимизации (v8.7.12).
+- **@solid-primitives/i18n**: Отличная легкая альтернатива для простых проектов, хотя ей не хватает расширенных функций, таких как ленивая загрузка.
+- **solid-i18next**: Стандартный, но тяжелый вариант (~4.7 раза больше Intlayer) с теми же недостатками, что и React i18next.
+- **Paraglide**: Инновационный подход, но сложный DX и проблемы с tree-shaking в некоторых конфигурациях.
+
+## Проверьте свое приложение
+
+Чтобы быстро выявить проблемы с утечкой i18n, я настроил бесплатный сканер, доступный [здесь](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Проблема
+
+Два рычага необходимы для ограничения стоимости мультиязычного приложения:
+
+- Разделение контента по страницам / пространствам имен, чтобы не загружать целые словари, когда они вам не нужны.
+- Динамическая загрузка нужной локали только тогда, когда она требуется.
+
+Понимание технических ограничений этих подходов:
+
+**Динамическая загрузка**
+
+Без динамической загрузки большинство решений хранят сообщения в памяти с первого рендеринга, что создает значительные накладные расходы для приложений с множеством маршрутов и локалей.
+
+При использовании динамической загрузки вы идете на компромисс: меньше начального JS, но иногда дополнительный запрос при переключении языка.
+
+**Разделение контента**
+
+Синтаксис, построенный вокруг `t('a.b.c')`, очень удобен, но часто способствует хранению больших JSON-объектов во время выполнения. Эта модель затрудняет tree-shaking, если библиотека не предлагает реальную стратегию разделения контента для каждой страницы.
+
+## Методология
+
+Для этого бенчмарка мы сравнили следующие библиотеки:
+
+- `Base App` (Без библиотеки i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Фреймворк — `Solid` с мультиязычным приложением из **10 страниц** и **10 языков**.
+
+Мы сравнили **четыре стратегии загрузки**:
+
+| Стратегия                 | Без пространств имен (глобальная)               | С пространствами имен (локальная/scoped)                                         |
+| :------------------------ | :---------------------------------------------- | :------------------------------------------------------------------------------- |
+| **Статическая загрузка**  | **Static**: Все в памяти при запуске.           | **Scoped static**: Разделено по пространствам имен; все загружается при запуске. |
+| **Динамическая загрузка** | **Dynamic**: Загрузка по требованию для локали. | **Scoped dynamic**: Гранулярная загрузка по пространствам имен и локалям.        |
+
+## Резюме стратегий
+
+- **Статическая (Static)**: Простота; отсутствие задержек сети после начальной загрузки. Минус: большой размер бандла.
+- **Динамическая (Dynamic)**: Уменьшает начальный вес (ленивая загрузка). Идеально при наличии множества локалей.
+- **Локальная статическая (Scoped static)**: Позволяет организовать код (логическое разделение) без сложных дополнительных сетевых запросов.
+- **Локальная динамическая (Scoped dynamic)**: Лучший подход для _разделения кода_ и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.
+
+## Результаты в деталях
+
+### 1 — Решения, которых следует избегать
+
+> В экосистеме Solid нет однозначных решений, которых следует избегать.
+
+### 2 — Приемлемые решения
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next`, вероятно, является самым популярным вариантом, так как был одним из первых решений для нужд i18n в JavaScript-приложениях. У него также есть широкий набор плагинов от сообщества для конкретных задач.
+
+Пакет тяжелый (~14.6 КБ, что примерно в 4.7 раза больше `solid-intlayer`).
+
+Тем не менее, у него те же основные недостатки, что и у стеков, построенных на `t('a.b.c')`: оптимизация возможна, но отнимает очень много времени, а большие проекты рискуют столкнуться с плохими практиками (пространства имен + динамическая загрузка + типы).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive чрезвычайно легкий и эффективный. Я рекомендую это решение для небольших проектов, но ему может быстро перестать хватать функций для профессиональных решений, включая управление куки, перенаправление прокси, форматировщики и т. д.
+В нем также отсутствует ленивая загрузка и разделение пространств имен для оптимизации размера страницы.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` предлагает инновационный, хорошо продуманный подход. Тем не менее, в этом бенчмарке рекламируемый ими tree-shaking не сработал для моей реализации. Процесс работы и DX также сложнее, чем у других вариантов.
+Лично мне не нравится необходимость регенерировать JS-файлы перед каждым пушем, что создает постоянный риск конфликтов при слиянии в PR.
+Наконец, по сравнению с другими решениями, Paraglide не использует стор (например, Solid signal) для получения текущей локали для рендеринга. Для каждого обработанного узла он запрашивает локаль из localStorage / куки и т.д. Это приводит к выполнению ненужной логики, что влияет на реактивность компонентов.
+
+### 3 — Рекомендации
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Я не буду лично оценивать `solid-intlayer` ради объективности, так как это мое собственное решение.
+
+### Личное примечание
+
+Это примечание является личным и не влияет на результаты бенчмарка. Тем не менее, в мире i18n часто можно встретить консенсус вокруг паттерна типа `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` для переведенного контента.
+
+В Solid-приложениях внедрение функции в качестве `JSX.Element` является, на мой взгляд, антипаттерном. Это также добавляет лишнюю сложность и накладные расходы на выполнение JavaScript (даже если это почти незаметно).