@intlayer/docs 9.5.1 → 9.5.2

package/docs/pt/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Melhor solução i18n para Next.js em 2026 - Relatório de Benchmark
 description: Compare bibliotecas de internacionalização (i18n) para Next.js como next-intl, next-i18next e Intlayer. Relatório detalhado de desempenho sobre tamanho do bundle, vazamento e reatividade.
 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: "Atualização dos resultados do benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Adicionar comparativo de estrelas do GitHub"
@@ -56,7 +59,7 @@ As bibliotecas de internacionalização têm um impacto pesado na sua aplicaçã
 
 À medida que sua aplicação cresce, o tamanho do bundle pode crescer exponencialmente, o que pode prejudicar visivelmente o desempenho.
 
-Como exemplo, nos piores casos, uma vez internacionalizada, sua página pode acabar ficando quase 4 vezes maior.
+Como exemplo, nos piores casos, uma vez internacionalizada, sua página pode acabar ficando quase 2 vezes maior.
 
 Outro impacto das bibliotecas i18n é o desenvolvimento mais lento. Transformar componentes em conteúdo multilíngue em todos os idiomas consome muito tempo.
 
@@ -68,7 +71,7 @@ O Intlayer tenta otimizar em todas essas dimensões.
 
 - **Intlayer** e **next-translate**: As melhores escolhas para o desempenho do Next.js, oferecendo a menor pegada e o melhor suporte para renderização estática.
 - **next-intl**: A opção mais badalada, mas pesada e complexa de otimizar para grandes aplicações.
-- **next-i18next**: Popular e rico em plugins, mas carrega um peso significativo de bundle (~3× Intlayer).
+- **next-i18next**: Popular e rico em plugins, mas carrega um peso significativo de bundle (~3.5× Intlayer).
 - **Evite**: **gt-next** e **lingo.dev** devido a problemas graves de desempenho, aprisionamento tecnológico (vendor lock-in) e erros que quebram a build.
 
 ## Teste sua aplicação
@@ -109,19 +112,21 @@ Finalmente, o `Intlayer` aplica uma otimização no momento do build para que `u
 Para este benchmark, comparamos as seguintes bibliotecas:
 
 - `Base App` (Sem biblioteca 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/pt/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/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)
 
-Utilizei a versão `16.2.4` do `Next.js` com o App Router.
+Utilizei a versão `16.3.4` do `Next.js` com o App Router.
 
 Construí uma aplicação multilíngue com **10 páginas** e **10 idiomas**.
 
@@ -175,15 +180,15 @@ Algumas soluções, como `gt-next` ou `lingo.dev`, devem claramente ser evitadas
 
 Problemas encontrados:
 
-**(General Translation)** (`gt-next@6.16.5`):
+**(General Translation)** (`gt-next@11.1.24`):
 
-- Para uma aplicação de 110kb, o `gt-next` adiciona mais de 440kb extras.
+- Para uma aplicação de 141kb, o `gt-next` adiciona mais de 50kb extras.
 - `Quota Exceeded, please upgrade your plan` logo no primeiro build com a General Translation.
 - Traduções não são renderizadas; recebo o erro `Error: <T> used on the client-side outside of <GTProvider>`, o que parece ser um bug na biblioteca.
 - Ao implementar o **gt-next**, também encontrei um [problema](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) con la biblioteca: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, que fazia a aplicação falhar. Após relatar esse problema, o mantenedor corrigiu-o em 24 horas.
 - A biblioteca bloqueia a renderização estática das páginas do Next.js.
 
-**(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.12`):
 
 - Cota de IA excedida, bloqueando a build inteiramente - então você não pode lançar para produção sem pagar.
 - O compilador estava perdendo quase 40% do conteúdo traduzido. Tive que reescrever todos os `.map` em blocos de componentes planos para fazer funcionar.
@@ -192,7 +197,7 @@ Problemas encontrados:
 
 ### 2 - Soluções experimentais
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 A ideia por trás do `Wuchale` é interessante, mas ainda não é viável. Encontrei problemas de reatividade e tive que forçar a re-renderização do provedor para fazer a aplicação funcionar. A documentação também é bastante incerta, o que torna a integração mais difícil.
 
@@ -202,21 +207,21 @@ O `Paraglide` oferece uma abordagem inovadora e bem pensada. Mesmo assim, neste
 Pessoalmente, não gosto de ter que regenerar arquivos JS antes de cada push, o que cria um risco constante de conflito de merge via PRs. A ferramenta também parece mais focada no Vite do que no Next.js.
 Finalmente, em comparação com outras soluções, o Paraglide não usa store (ex: React context) para recuperar a localidade atual para renderizar le conteúdo. Para cada nó analisado, ele solicitará a localidade do localStorage / cookie etc. Isso leva à execução de lógica desnecessária que impacta a reatividade do componente.
 
-> Nota sobre paraglide: a solução injeta código na sua base de código para importação, como resultado a métrica 'tamanho da lib' no relatório de benchmark é quase 0. A geração de código é algo bom, porque a função utilizada incluirá apenas a lógica necessária (prefixo total vs sem prefixo, cookie vs armazenamento, etc.). Em comparação, o Intlayer executa essa filtragem via inyeções de variáveis de ambiente na build para forçar o bundler a aplicar tree-shaking ao conteúdo dependendo da lógica. Graças a isso, paraglide e intlayer acabam sendo soluções de 6 a 10 vezes mais leves do que i18next ou next-intl.
+> Nota sobre paraglide: a solução injeta código na sua base de código para importação, como resultado a métrica 'tamanho da lib' no relatório de benchmark é quase 0. A geração de código é algo bom, porque a função utilizada incluirá apenas a lógica necessária (prefixo total vs sem prefixo, cookie vs armazenamento, etc.). Em comparação, o Intlayer executa essa filtragem via inyeções de variáveis de ambiente na build para forçar o bundler a aplicar tree-shaking ao conteúdo dependendo da lógica. Graças a isso, paraglide e intlayer acabam sendo soluções de 3 a 8 vezes mais leves do que i18next ou next-intl.
 
 ### 3 - Soluções aceitáveis
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 O `Tolgee` resolve muitos dos problemas mencionados anteriormente. Achei mais difícil de adotar do que ferramentas semelhantes. Ele não fornece segurança de tipos (type safety), o que também torna mais difícil encontrar chaves ausentes no momento da compilação. Tive que envolver as funções do Tolgee com as minhas para adicionar a detecção de chaves ausentes.
 
-**(Next Intl)** (`next-intl@4.9.1`):
+**(Next Intl)** (`next-intl@4.14.2`):
 
-O `next-intl` é a opção mais badalada e a que os agentes de IA mais recomendam, mas, na minha visão, erradamente. Começar é fácil. Na prática, otimizar para limitar o vazamento é complexo. Combinar carregamento dinâmico + namespaces + tipos TypeScript retarda muito o desenvolvimento. O pacote também é bastante pesado (~13kb para `NextIntlClientProvider` + `useTranslations`, que é mais de 2x o `next-intlayer`). O **next-intl** costumava bloquear a renderização estática das páginas do Next.js. Ele fornece um auxiliar chamado `setRequestLocale()`. Isso parece ter sido parcialmente resolvido para arquivos centralizados como `en.json` / `fr.json`, mas a renderização estática ainda quebra quando o conteúdo é dividido em namespaces como `en/shared.json` / `fr/shared.json` / `es/shared.json`.
+O `next-intl` é a opção mais badalada e a que os agentes de IA mais recomendam, mas, na minha visão, erradamente. Começar é fácil. Na prática, otimizar para limitar o vazamento é complexo. Combinar carregamento dinâmico + namespaces + tipos TypeScript retarda muito o desenvolvimento. O pacote também é bastante pesado (~14.7kb para `NextIntlClientProvider` + `useTranslations`, que é mais de 2.5x o `next-intlayer`). O **next-intl** costumava bloquear a renderização estática das páginas do Next.js. Ele fornece um auxiliar chamado `setRequestLocale()`. Isso parece ter sido parcialmente resolvido para arquivos centralizados como `en.json` / `fr.json`, mas a renderização estática ainda quebra quando o conteúdo é dividido em namespaces como `en/shared.json` / `fr/shared.json` / `es/shared.json`.
 
-**(Next I18next)** (`next-i18next@16.0.5`):
+**(Next I18next)** (`next-i18next@16.3.0`):
 
-O `next-i18next` é provavelmente a opção mais popular porque foi uma das primeiras soluções de i18n para aplicações JavaScript. Possui muitos plugins da comunidade. Compartilha os mesmos grandes pontos negativos que o `next-intl`. O pacote é especialmente pesado (~18kb para `I18nProvider` + `useTranslation`, cerca de 3x o `next-intlayer`).
+O `next-i18next` é provavelmente a opção mais popular porque foi uma das primeiras soluções de i18n para aplicações JavaScript. Possui muitos plugins da comunidade. Compartilha os mesmos grandes pontos negativos que o `next-intl`. O pacote é especialmente pesado (~19.7kb para `I18nProvider` + `useTranslation`, cerca de 3.5x o `next-intlayer`).
 
 Os formatos de mensagem também diferem: o `next-intl` usa ICU MessageFormat, enquanto o `i18next` usa seu próprio formato.
 
@@ -224,17 +229,17 @@ Os formatos de mensagem também diferem: o `next-intl` usa ICU MessageFormat, en
 
 O `next-international` também aborda os problemas acima, mas não difere muito do `next-intl` ou `next-i18next`. Inclui `scopedT()` para traduções específicas de um namespace, mas usá-lo não tem praticamente impacto no tamanho do bundle.
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 O `Lingui` é frequentemente elogiado. Pessoalmente, achei o fluxo de trabalho `lingui extract` / `lingui compile` mais complexo que as alternativas, sem uma vantagem clara. Também notei sintaxes inconsistentes que confundem as IAs (ex: `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
 ### 4 - Recomendações
 
-**(Next Translate)** (`next-translate@3.1.2`):
+**(Next Translate)** (`next-translate@3.2.0`):
 
-O `next-translate` é minha recomendação principal se você gosta de uma API no estilo `t()`. É elegante via `next-translate-plugin`, carregando namespaces através de `getStaticProps` com um carregador Webpack / Turbopack. É também a opção mais leve aqui (~2.5kb). Para os namespaces, definir os namespaces por página ou rota na configuração é bem pensado e mais fácil de manter do que as principais alternativas como **next-intl** ou **next-i18next**. Na versão `3.1.2`, notei que a renderização estática não funcionava; o Next.js recorria à renderização dinâmica.
+O `next-translate` é minha recomendação principal se você gosta de uma API no estilo `t()`. É elegante via `next-translate-plugin`, carregando namespaces através de `getStaticProps` com um carregador Webpack / Turbopack. É também uma das opções mais leves aqui (~3.5kb). Para os namespaces, definir os namespaces por página ou rota na configuração é bem pensado e mais fácil de manter do que as principais alternativas como **next-intl** ou **next-i18next**. Na versão `3.1.2`, notei que a renderização estática não funcionava; o Next.js recorria à renderização dinâmica.
 
-**(Intlayer)** (`next-intlayer@8.7.12`):
+**(Intlayer)** (`next-intlayer@9.5.1`):
 
 Não serei eu a julgar pessoalmente o `next-intlayer` por uma questão de objetividade, já que é a minha própria solução.
 

package/docs/pt/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Melhor solução i18n para Solid em 2026 - Relatório de Benchmark
 description: Compare bibliotecas de internacionalização (i18n) para Solid como solid-primitives, solid-i18next e Intlayer. Relatório de desempenho detalhado sobre tamanho do bundle, vazamento e reatividade.
 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: "Atualização dos resultados do benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Adicionar comparativo de estrelas do GitHub"
@@ -62,9 +65,9 @@ O outro impacto é na experiência do desenvolvedor (DX): como você declara con
 
 ## TL;DR
 
-- **Intlayer**: Escolha recomendada para aplicações Solid profissionais que precisam de recursos avançados e otimização (v8.7.12).
+- **Intlayer**: Escolha recomendada para aplicações Solid profissionais que precisam de recursos avançados e otimização (v9.5.0).
 - **@solid-primitives/i18n**: Excelente alternativa leve para projetos simples, embora careça de recursos avançados como lazy loading.
-- **solid-i18next**: Opção padrão, mas pesada (~4.7× o Intlayer) com os mesmos pontos negativos do React i18next.
+- **solid-i18next**: Opção padrão, mas pesada (~3.5× o Intlayer) com os mesmos pontos negativos do React i18next.
 - **Paraglide**: Abordagem inovadora, mas DX complexa e problemas de tree-shaking em algumas configurações.
 
 ## Teste seu app
@@ -97,10 +100,10 @@ Sintaxes construídas em torno de `t('a.b.c')` são muito convenientes, mas freq
 Para este benchmark, comparamos as seguintes bibliotecas:
 
 - `Base App` (Sem biblioteca 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)
 
 O framework é `Solid` com um app multilíngue de **10 páginas** e **10 idiomas**.
 
@@ -154,11 +157,11 @@ As estrelas do GitHub são um forte indicador da popularidade de um projeto, da
 
 ### 2 - Soluções aceitáveis
 
-**(solid-i18next)** (`solid-i18next@17.0.2`):
+**(solid-i18next)** (`i18next@26.0.8`):
 
 O `solid-i18next` é provavelmente a opção mais popular porque foi uma das primeiras a atender às necessidades de i18n de apps JavaScript. Também possui um amplo conjunto de plugins da comunidade para problemas específicos.
 
-O pacote é pesado (~14.6kb, o que é cerca de 4.7× o `solid-intlayer`).
+O pacote é pesado (~14.9kb, o que é cerca de 3.5× o `solid-intlayer`).
 
 Ainda assim, compartilha as mesmas principais desvantagens das stacks construídas sobre o `t('a.b.c')`: otimizações são possíveis, mas consomem muito tempo, e grandes projetos correm o risco de más práticas (namespaces + carregamento dinâmico + tipos).
 
@@ -167,7 +170,7 @@ Ainda assim, compartilha as mesmas principais desvantagens das stacks construíd
 O Solid primitive é extremamente leve e eficiente. Recomendo essa solução para projetos leves, mas pode rapidamente carecer de recursos para soluções profissionais que incluam gerenciamento de cookies, redirecionamento de proxy, formatadores etc.
 Também carece de lazy loading e scoping de namespaces para otimização do tamanho da página.
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 O `Paraglide` oferece uma abordagem inovadora e bem pensada. Ainda assim, neste benchmark, o tree-shaking que a empresa anuncia não funcionou para minha implementação. O fluxo de trabalho e a DX também são mais complexos do que outras opções.
 Pessoalmente, não gosto de ter que regenerar arquivos JS antes de cada push, o que cria um risco constante de conflito de merge através de PRs.
@@ -175,7 +178,7 @@ Finalmente, em comparação com outras soluções, o Paraglide não usa um store
 
 ### 3 - Recomendações
 
-**(Intlayer)** (`solid-intlayer@8.7.12`):
+**(Intlayer)** (`solid-intlayer@9.5.0`):
 
 Eu não julgarei pessoalmente o `solid-intlayer` por uma questão de objetividade, já que é minha própria solução.
 

package/docs/pt/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Melhor solução i18n para Svelte em 2026 - Relatório de Benchmark
 description: Compare bibliotecas de internacionalização (i18n) para Svelte como svelte-i18n, Paraglide e Intlayer. Relatório de desempenho detalhado sobre tamanho do bundle, vazamento e reatividade.
 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: "Atualização dos resultados do benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Adicionar comparativo de estrelas do GitHub"
@@ -62,9 +65,9 @@ O outro impacto é na experiência do desenvolvedor (DX): como você declara con
 
 ## TL;DR
 
-- **Intlayer**: A escolha mais eficiente em desempenho (v8.7.12) com o menor footprint.
+- **Intlayer**: A escolha mais eficiente em desempenho (v9.5.0) com o menor footprint.
 - **Paraglide**: Forte candidato para tree-shaking, mas possui uma experiência de desenvolvedor mais complexa e overhead de reatividade.
-- **svelte-i18n**: Abrangente e padrão para Svelte, mas carrega um peso de bundle muito maior (~7× o Intlayer).
+- **svelte-i18n**: Abrangente e padrão para Svelte, mas carrega um peso de bundle muito maior (~4.5× o Intlayer).
 
 ## Teste seu app
 
@@ -96,9 +99,9 @@ Sintaxes construídas em torno de `t('a.b.c')` são muito convenientes, mas freq
 Para este benchmark, comparamos as seguintes bibliotecas:
 
 - `Base App` (Sem biblioteca 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)
 
 O framework é `Svelte` com um app multilíngue de **10 páginas** e **10 idiomas**.
 
@@ -152,7 +155,7 @@ As estrelas do GitHub são um forte indicador da popularidade de um projeto, da
 
 ### 2 - Soluções aceitáveis
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 O `Paraglide` oferece uma abordagem inovadora e bem pensada. No contexto de um app Vite + Svelte, o tree-shaking que a empresa anuncia funcionou conforme o esperado, o que é excelente.
 Mas no caso do React + TanStack Start, o tree-shaking não funcionou como esperado, o mesmo para o Next.js. Dito isso, o uso do Paraglide em um projeto Svelte e TanStack Start valeria uma dupla verificação.
@@ -162,13 +165,13 @@ Finalmente, em comparação com outras soluções, o Paraglide não usa um store
 
 > Nota sobre o paraglide: a solução injeta código em sua base de código para importações; como resultado, a métrica 'lib size' no relatório de benchmark é quase 0. A geração de código é algo bom, porque a função utilizada incluirá apenas a lógica necessária (prefixo em todos os lugares vs sem prefixo, cookie vs armazenamento, etc.). Em comparação, o Intlayer realiza essa filtragem via injeções de variáveis de ambiente durante o build para forçar o bundler a fazer tree-shaking do conteúdo dependendo da lógica. Graças a isso, o paraglide e o intlayer acabam sendo soluções de 6 a 10 vezes mais leves que o i18next ou o next-intl.
 
-**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+**(svelte-i18n)** (`svelte-i18n@4.0.1`):
 
-Esta solução atende a todas as necessidades de i18n em um projeto Svelte. Mas, como é o caso do i18next ou de outras grandes soluções de i18n, é um pouco pesada (~15.9kb, o que é cerca de 7× o `svelte-intlayer`).
+Esta solução atende a todas as necessidades de i18n em um projeto Svelte. Mas, como é o caso do i18next ou de outras grandes soluções de i18n, é um pouco pesada (~16.6kb, o que é cerca de 4.5× o `svelte-intlayer`).
 
 ### 3 - Recomendações
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`):
+**(Intlayer)** (`svelte-intlayer@9.5.0`):
 
 Eu não julgarei pessoalmente o `svelte-intlayer` por uma questão de objetividade, já que é minha própria solução.
 

package/docs/pt/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Melhor solução i18n para TanStack Start em 2026 - Relatório de Benchmark
 description: Compare bibliotecas de internacionalização para TanStack Start como react-i18next, use-intl e Intlayer. Relatório detalhado de desempenho sobre tamanho do bundle, vazamento e reatividade.
 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: "Atualização dos resultados do benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Adicionar comparativo de estrelas do GitHub"
@@ -62,7 +65,7 @@ O outro impacto é na experência do desenvolvedor: como você declara o conteú
 
 ## TL;DR
 
-- **Intlayer**: Oferece o melhor desempenho e o menor tamanho de bundle (v8.7.12) para TanStack Start.
+- **Intlayer**: Oferece o melhor desempenho e o menor tamanho de bundle (v9.5.1) para TanStack Start.
 - **react-i18next** & **use-intl**: Alternativas maduras com grandes ecossistemas, mas significativamente mais pesadas e complexas de otimizar.
 - **Paraglide**: Ideia inovadora de tree-shaking que não funciona na prática. DX complexo e sobrecarga de reatividade no TanStack Start.
 - **Evitar**: **General Translation (GT)** e **Lingo.dev** devido a graves problemas de desempenho, limites de cota de IA e bloqueio do fornecedor (vendor lock-in).
@@ -97,16 +100,18 @@ As sintaxes construídas em torno de `const t = useTranslation()` + `t('a.b.c')`
 Para este benchmark, comparamos as seguintes bibliotecas:
 
 - `Base App` (Sem biblioteca 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/pt/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)
 
 O framework é o `TanStack Start` com uma aplicação multilíngue de **10 páginas** e **10 idiomas**.
 
@@ -160,15 +165,15 @@ Algumas soluções, como `gt-react` ou `lingo.dev`, são claramente opções das
 
 Problemas encontrados:
 
-**(General Translation)** (`gt-react@latest`):
+**(General Translation)** (`gt-react@10.18.3`):
 
-- Para uma app de cerca de 110kb, o `gt-react` pode adicionar mais de 440kb extras (ordem de grandeza vista na implementação do Next.js no mesmo benchmark).
+- Para uma app de cerca de 111kb, o `gt-react` pode adicionar mais de 170kb extras (ordem de grandeza vista na implementação do Next.js no mesmo benchmark).
 - `Quota Exceeded, please upgrade your plan` logo no primeiro build com a General Translation.
 - Traduções não são renderizadas; recebo o erro `Error: <T> used on the client-side outside of <GTProvider>`, o que parece ser um bug na biblioteca.
 - Ao implementar o **gt-tanstack-start-react**, também encontrei um [problema](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) com a biblioteca: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, que fazia a aplicação falhar. Após relatar esse problema, o mantenedor corrigiu-o em 24 horas.
 - Essas bibliotecas usam um antipadrão através da função `initializeGT()`, impedindo que o bundle seja limpo corretamente via tree-shaking.
 
-**(Lingo.dev)** (`lingo.dev@0.133.9`):
+**(Lingo.dev)** (`lingo.dev@0.138.7`):
 
 - Cota de IA excedida (ou dependência de servidor bloqueada), tornando o build / produção arriscado sem pagar.
 - O compilador estava perdendo quase 40% do conteúdo traduzido. Tive que reescrever todos os `.map` em blocos de componentes planos para fazer funcionar.
@@ -178,7 +183,7 @@ Problemas encontrados:
 
 ### 2 - Soluções experimentais
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 A ideia por trás do `Wuchale` é interessante, mas ainda não é uma solução viável. Encontrei problemas de reatividade com a biblioteca e tive que forçar a re-renderização do provedor para fazer a aplicação funcionar no TanStack Start. A documentazione é também bastante incerta, o que torna a integração mais difícil.
 
@@ -188,9 +193,9 @@ A ideia por trás do `Wuchale` é interessante, mas ainda não é uma solução
 
 O `Paraglide` oferece uma abordagem inovadora e bem pensada. Mesmo assim, neste benchmark, o tree-shaking anunciado pela empresa não funcionou para minha implementação no Next.js ou para o TanStack Start. O fluxo de trabalho e o DX também são mais complexos do que outras opções. Pessoalmente, não sou fã de ter que regenerar arquivos JS antes de cada push, o que cria um risco constante de conflitos de merge para os desenvolvedores via PRs.
 
-> Nota sobre o paraglide: a solução injeta código na sua base de código para as importações; como resultado, a métrica 'lib size' no relatório de benchmark é quase 0. A geração de código é algo bom, porque a função utilizada incluirá apenas a lógica necessária (prefixo em todos os lugares vs. sem prefixo, cookie vs. armazenamento, etc.). Em comparação, o Intlayer realiza essa filtragem via injeções de variáveis de ambiente no build para forçar o bundler a fazer o tree-shaking do conteúdo dependendo da lógica. Graças a isso, o paraglide e o intlayer acabam sendo soluções 6 a 10 vezes mais leves que o i18next ou o next-intl.
+> Nota sobre o paraglide: a solução injeta código na sua base de código para as importações; como resultado, a métrica 'lib size' no relatório de benchmark é quase 0. A geração de código é algo bom, porque a função utilizada incluirá apenas a lógica necessária (prefixo em todos os lugares vs. sem prefixo, cookie vs. armazenamento, etc.). Em comparação, o Intlayer realiza essa filtragem via injeções de variáveis de ambiente no build para forçar o bundler a fazer o tree-shaking do conteúdo dependendo da lógica. Graças a isso, o paraglide e o intlayer acabam sendo soluções 3 a 10 vezes mais leves que o i18next ou o next-intl.
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 O `Tolgee` resolve muitos dos problemas mencionados anteriormente. Achei mais difícil de começar com ele do que com outras ferramentas com abordagens semelhantes. Ele não fornece segurança de tipos, o que também torna muito difícil encontrar chaves ausentes no momento da compilação. Tive que envolver as APIs do Tolgee com as minhas para adicionar a detecção de chaves ausentes.
 
@@ -198,37 +203,37 @@ O package é bastante pesado (~11.1kb, o que é mais de 2× `react-intlayer`).
 
 No TanStack Start também tive problemas de reatividade: na mudança de localidade, tive que forçar o provedor a renderizar novamente e me inscrever em eventos de mudança de localidade para que o carregamento em outro idioma se comportasse corretamente.
 
-**(use-intl)** (`use-intl@4.9.1`):
+**(use-intl)** (`use-intl@4.14.2`):
 
 O `use-intl` é a peça "intl" mais badalada no ecossistema React (mesma família do `next-intl`) e é frequentemente recomendada por agentes de IA, mas, na minha visão, erroneamente em um ambiente focado em desempenho. Começar é bastante simples. Na prática, o processo para otimizar e limitar o vazamento é bastante complexo. Da mesma forma, combinar carregamento dinâmico + namespaces + tipos TypeScript retarda muito o desenvolvimento.
 
 No TanStack Start, você evita as armadilhas específicas do Next.js (`setRequestLocale`, renderização estática), mas o problema principal é o mesmo: sem uma disciplina rigorosa, o bundle rapidamente carrega muitas mensagens e a manutenção de namespaces por rota torna-se penosa.
 
-**(react-i18next)** (`react-i18next@17.0.2`):
+**(react-i18next)** (`react-i18next@17.0.13`):
 
 O `react-i18next` é provavelmente a opção mais popular porque foi uma das primeiras a atender às necessidades de i18n de aplicações JavaScript. Também possui um amplo conjunto de plugins da comunidade para problemas específicos.
 
 Ainda assim, compartilha os mesmos grandes pontos negativos que as stacks baseadas em `t('a.b.c')`: as otimizações são possíveis, mas consomem muito tempo, e grandes projetos correm o risco de cair em más práticas (namespaces + carregamento dinâmico + tipos).
 
-O package é especialmente pesado (~17.3kb, o que é aproximadamente 3.5× `react-intlayer`).
+O package é especialmente pesado (~18.4kb, o que é aproximadamente 3.5× `react-intlayer`).
 
 Os formatos de mensagem também divergem: o `use-intl` usa ICU MessageFormat, enquanto o `i18next` usa seu próprio formato - o que complica o ferramental ou migrações se você os misturar.
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 O `Lingui` é frequentemente elogiado. Pessoalmente, achei o fluxo de trabalho em torno de `lingui extract` / `lingui compile` mais complexo do que outras abordagens, sem uma vantagem clara neste benchmark do TanStack Start. Também notei sintaxes inconsistentes que confundem as IAs (ex: `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
-**(react-intl)** (`react-intl@10.1.1`):
+**(react-intl)** (`react-intl@10.1.26`):
 
 O `react-intl` é uma implementação de alto desempenho da equipe do Format.js. O DX permanece prolixo: `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` adiciona complexidade, trabalho extra de JavaScript e vincula a instância global de i18n a muitos nós na árvore React.
 
-O package também é pesado (~14.4kb, o que é cerca de 3× `react-intlayer`).
+O package também é pesado (~15.3kb, o que é cerca de 3× `react-intlayer`).
 
 ### 4 - Recomendações
 
 Este benchmark do TanStack Start não possui um equivalente direto do `next-translate` (plugin Next.js + `getStaticProps`). Para as equipes que realmente desejam uma API `t()` com um ecossistema maduro, o `react-i18next` e o `use-intl` continuam sendo escolhas "razoáveis", mas espere investir muito tempo otimizando para evitar vazamentos.
 
-**(Intlayer)** (`react-intlayer@8.7.12`):
+**(Intlayer)** (`react-intlayer@9.5.1`):
 
 Não serei eu a julgar pessoalmente o `react-intlayer` por uma questão de objetividade, já que é a minha própria solução.
 

package/docs/pt/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Melhor solução i18n para Vue em 2026 - Relatório de Benchmark
 description: Compare bibliotecas de internacionalização (i18n) para Vue como vue-i18n, fluent-vue e Intlayer. Relatório de desempenho detalhado sobre tamanho do bundle, vazamento e reatividade.
 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: "Atualização dos resultados do benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Adicionar comparativo de estrelas do GitHub"
@@ -62,7 +65,7 @@ O outro impacto é na experiência do desenvolvedor (DX): como você declara con
 
 ## TL;DR
 
-- **Intlayer**: A solução mais leve (v8.7.12) com escopo (scoping) e carregamento dinâmico integrados.
+- **Intlayer**: A solução mais leve (v9.5.0) com escopo (scoping) e carregamento dinâmico integrados.
 - **vue-i18n**: O padrão da indústria com um rico ecossistema, mas pode se tornar significativamente mais pesado e difícil de otimizar para code-splitting em aplicações de grande porte.
 - **fluent-vue**: Organização de mensagens inovadora, mas carece de segurança de tipos e acaba sendo uma solução extremamente pesada.
 
@@ -96,7 +99,8 @@ Sintaxes construídas em torno de `const { t } = useI18n()` + `t('a.b.c')` são
 Para este benchmark, comparamos as seguintes bibliotecas:
 
 - `Base App` (Sem biblioteca i18n)
-- `vue-intlayer` (v8.7.12)
+- `vue-intlayer` (v9.5.0)
+- [`@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/compat/vue-i18n.md) (v9.5.1)
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
@@ -156,14 +160,14 @@ As estrelas do GitHub são um forte indicador da popularidade de um projeto, da
 
 - **vue-i18n** é sem contestação a biblioteca i18n mais usada para Vue, possui muitos recursos e um ecossistema enorme. Mas, nos bastidores, a solução é bastante pesada. Mesmo que o vue-i18n integre lazy loading para mensagens, falta um recurso de escopo (scoping). No caso de um app Vue SPA clássico, não há problema, mas para um app Nuxt, usando @nuxt/i18n, isso leva à inclusão das mensagens de todas as páginas em uma única. Para um app Nuxt grande com mais de 10 páginas, isso pode se tornar realmente problemático.
 
-O pacote é muito pesado (~24.3kb, o que é cerca de 9× o `vue-intlayer`).
+O pacote é muito pesado (~24.3kb, o que é cerca de 6× o `vue-intlayer`).
 
-**(fluent-vue)** (`fluent-vue@0.5.0`):
+**(fluent-vue)** (`fluent-vue@3.8.2`):
 
-- **fluent-vue** oferece uma tentativa de inovação através do formato .ftl. A organização das mensagens é ótima, mais fácil de começar. Mas na prática, a falta de segurança de tipos aumenta o risco de erro e pode rapidamente se tornar demorada para debugar. Além disso, essa solução carrega as mensagens usando um plugin vite que força o carregamento de todo o conteúdo em todos os idiomas em cada página. Adicionalmente, é uma solução extremamente pesada (~92.7kb, o que é cerca de 34× o `vue-intlayer`).
+- **fluent-vue** oferece uma tentativa de inovação através do formato .ftl. A organização das mensagens é ótima, mais fácil de começar. Mas na prática, a falta de segurança de tipos aumenta o risco de erro e pode rapidamente se tornar demorada para debugar. Além disso, essa solução carrega as mensagens usando um plugin vite que força o carregamento de todo o conteúdo em todos os idiomas em cada página. Adicionalmente, é uma solução extremamente pesada (~29.7kb, o que é cerca de 7.5× o `vue-intlayer`).
 
 ### 3 - Recomendações
 
-**(Intlayer)** (`vue-intlayer@8.7.12`):
+**(Intlayer)** (`vue-intlayer@9.5.0`):
 
 Eu não julgarei pessoalmente o `vue-intlayer` por uma questão de objetividade, já que é minha própria solução.

package/docs/pt/cli/build.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Construir Dicionários
 description: Aprenda como construir seus dicionários Intlayer a partir de arquivos de declaração de conteúdo.
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - cli
   - build
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Adicionar o flag `--ci`"
   - version: 8.1.5
     date: 2026-02-23
     changes: "Adicionar opção checkTypes"
@@ -92,6 +95,10 @@ Este comando irá localizar seus arquivos de declaração de conteúdo por padr
 
   > Exemplo: `npx intlayer build --no-cache`
 
+- **`--ci`**: Executa o comando em cada projeto Intlayer do monorepo (ou apenas no atual quando executado de dentro de um diretório de projeto). Credenciais por projeto podem ser injetadas via `INTLAYER_PROJECT_CREDENTIALS`, um objeto JSON que associa cada caminho de projeto a `{ "clientId", "clientSecret" }`.
+
+  > Exemplo: `npx intlayer build --ci`
+
 - **`--check-types`**: Verifica os tipos dos arquivos de declaração de conteúdo.
 
   > Exemplo: `npx intlayer build --check-types`

package/docs/pt/cli/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Gerenciar Configuração
 description: Aprenda como obter e enviar sua configuração Intlayer para o CMS.
 keywords:
@@ -51,6 +51,7 @@ bun x intlayer configuration get
 - **`--base-dir`**: Especifica o diretório base para o projeto.
 - **`--verbose`**: Ativa o log detalhado para depuração. (padrão para true usando CLI)
 - **`--no-cache`**: Desativa o cache.
+- **`--ci`**: Executa o comando em cada projeto Intlayer do monorepo (ou apenas no atual quando executado de dentro de um diretório de projeto). Credenciais por projeto podem ser injetadas via `INTLAYER_PROJECT_CREDENTIALS`, um objeto JSON que associa cada caminho de projeto a `{ "clientId", "clientSecret" }`.
 
 ## Enviar Configuração
 
@@ -84,5 +85,6 @@ bun x intlayer configuration push
 - **`--base-dir`**: Especifica o diretório base para o projeto.
 - **`--verbose`**: Ativa o log detalhado para depuração. (padrão para true usando CLI)
 - **`--no-cache`**: Desativa o cache.
+- **`--ci`**: Executa o comando em cada projeto Intlayer do monorepo (ou apenas no atual quando executado de dentro de um diretório de projeto). Credenciais por projeto podem ser injetadas via `INTLAYER_PROJECT_CREDENTIALS`, um objeto JSON que associa cada caminho de projeto a `{ "clientId", "clientSecret" }`.
 
 Ao enviar a configuração, seu projeto fica totalmente integrado com o CMS do Intlayer, permitindo uma gestão fluida dos dicionários entre equipes.

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

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2026-06-17
+updatedAt: 2026-09-12
 title: Revisar Documento
 description: Aprenda como revisar arquivos de documentação para qualidade, consistência e completude em diferentes locais.
 keywords:
@@ -16,6 +16,9 @@ slugs:
   - cli
   - doc-review
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Adicionar o flag `--ci`"
   - version: 9.0.0
     date: 2026-06-17
     changes: "Adicionar opção --log"
@@ -138,6 +141,10 @@ Seja qual for o modo, a execução termina com uma síntese listando os document
 
   > Exemplo: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: Executa o comando em cada projeto Intlayer do monorepo (ou apenas no atual quando executado de dentro de um diretório de projeto). Credenciais por projeto podem ser injetadas via `INTLAYER_PROJECT_CREDENTIALS`, um objeto JSON que associa cada caminho de projeto a `{ "clientId", "clientSecret" }`.
+
+  > Exemplo: `npx intlayer doc review --ci`
+
 **Opções de log:**
 
 - **`--verbose`**: Ativa o log detalhado para depuração. (padrão para true usando CLI)

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

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Traduzir Documento
 description: Aprenda como traduzir automaticamente arquivos de documentação usando serviços de tradução por IA.
 keywords:
@@ -113,6 +113,10 @@ bun x intlayer doc translate
 
   > Exemplo: `npx intlayer doc translate --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: Executa o comando em cada projeto Intlayer do monorepo (ou apenas no atual quando executado de dentro de um diretório de projeto). Credenciais por projeto podem ser injetadas via `INTLAYER_PROJECT_CREDENTIALS`, um objeto JSON que associa cada caminho de projeto a `{ "clientId", "clientSecret" }`.
+
+  > Exemplo: `npx intlayer doc translate --ci`
+
 **Opções de log:**
 
 - **`--verbose`**: Ativa o log detalhado para depuração. (padrão para true usando CLI)

package/docs/pt/cli/extract.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Extrair strings
 description: Aprenda como extrair strings dos seus componentes para um ficheiro .content próximo do componente.
 keywords:
@@ -69,6 +69,7 @@ Este comando analisa os seus ficheiros de código para extrair strings dos compo
 - **`--env`**: Especifica o ambiente.
 - **`--env-file`**: Fornece um ficheiro de ambiente personalizado.
 - **`--verbose`**: Ativa o logging detalhado.
+- **`--ci`**: Executa o comando em cada projeto Intlayer do monorepo (ou apenas no atual quando executado de dentro de um diretório de projeto). Credenciais por projeto podem ser injetadas via `INTLAYER_PROJECT_CREDENTIALS`, um objeto JSON que associa cada caminho de projeto a `{ "clientId", "clientSecret" }`.
 
 **Plugins obrigatórios:**
 

package/docs/pt/cli/fill.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Preencher Dicionários
 description: Aprenda como preencher, auditar e traduzir seus dicionários usando IA.
 keywords:
@@ -162,6 +162,10 @@ Affected dictionary keys for processing: app, comp-test, hello-world, lang-switc
 
   > Exemplo: `npx intlayer build --no-cache`
 
+- **`--ci`**: Executa o comando em cada projeto Intlayer do monorepo (ou apenas no atual quando executado de dentro de um diretório de projeto). Credenciais por projeto podem ser injetadas via `INTLAYER_PROJECT_CREDENTIALS`, um objeto JSON que associa cada caminho de projeto a `{ "clientId", "clientSecret" }`.
+
+  > Exemplo: `npx intlayer fill --ci`
+
 **Opções de preparação:**
 
 - **`--build`**: Constrói os dicionários antes de enviar para garantir que o conteúdo esteja atualizado. True força a construção, false pula a construção, undefined permite usar o cache da construção.