@intlayer/docs 8.9.4 → 8.9.6-canary.0

package/docs/pt/benchmark/nextjs.md

@@ -61,6 +61,13 @@ Como o problema é difícil, existem muitas soluções — algumas focadas na DX
 
 O Intlayer tenta otimizar em todas essas dimensões.
 
+## TL;DR
+
+- **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).
+- **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
 
 Para trazer à tona esses problemas, construí um scanner gratuito que você pode experimentar [aqui](https://intlayer.org/i18n-seo-scanner).
@@ -99,14 +106,14 @@ 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.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 @@ Problemas encontrados:
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- Para uma aplicação de 110kb, o `gt-react` adiciona mais de 440kb extras.
+- Para uma aplicação de 110kb, o `gt-next` adiciona mais de 440kb 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-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.
+- 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`):
@@ -184,11 +191,13 @@ A ideia por trás do `Wuchale` é interessante, mas ainda não é viável. Encon
 
 O `Paraglide` oferece uma abordagem inovadora e bem pensada. Mesmo assim, neste benchmark, o tree-shaking anunciado pela empresa não funcionou para minhas configurações de Next.js ou TanStack Start. O fluxo de trabalho e o DX 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 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 o 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.
+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.
 
 ### 3 — Soluções aceitáveis
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.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.
 
@@ -216,7 +225,7 @@ O `Lingui` é frequentemente elogiado. Pessoalmente, achei o fluxo de trabalho `
 
 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.
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 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

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+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:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - desempenho
+  - 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: "Inicialização do benchmark"
+---
+
+# Bibliotecas i18n para Solid — Relatório de Benchmark 2026
+
+Esta página é um relatório de benchmark para soluções i18n no Solid.
+
+## Índice
+
+<Toc/>
+
+## Benchmark Interativo
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Referência de resultados:
+
+<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
+
+Veja o repositório completo do benchmark [aqui](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introdução
+
+As soluções de internacionalização estão entre as dependências mais pesadas em um app Solid. O principal risco é enviar conteúdo desnecessário: traduções para outras páginas e outros locais no bundle de uma única rota.
+
+À medida que seu app cresce, esse problema pode rapidamente explodir o JavaScript enviado ao cliente e tornar a navegação lenta.
+
+Na prática, para as implementações menos otimizadas, uma página internacionalizada pode acabar sendo várias vezes mais pesada do que a versão sem i18n.
+
+O outro impacto é na experiência do desenvolvedor (DX): como você declara conteúdo, tipos, organização de namespaces, carregamento dinâmico e reatividade quando o local muda.
+
+## TL;DR
+
+- **Intlayer**: Escolha recomendada para aplicações Solid profissionais que precisam de recursos avançados e otimização (v8.7.12).
+- **@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.
+- **Paraglide**: Abordagem inovadora, mas DX complexa e problemas de tree-shaking em algumas configurações.
+
+## Teste seu app
+
+Para identificar rapidamente problemas de vazamento de i18n, configurei um scanner gratuito disponível [aqui](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## O problema
+
+Duas alavancas são essenciais para limitar o custo de um app multilíngue:
+
+- Dividir o conteúdo por página / namespace para não carregar dicionários inteiros quando não for necessário.
+- Carregar o local correto dinamicamente, apenas quando necessário.
+
+Entendendo as limitações técnicas dessas abordagens:
+
+**Carregamento dinâmico**
+
+Sem carregamento dinâmico, a maioria das soluções mantém as mensagens na memória desde o primeiro render, o que adiciona um overhead significativo para apps com muitas rotas e locais.
+
+Com carregamento dinâmico, você aceita uma troca: menos JS inicial, mas às vezes uma requisição extra ao trocar de idioma.
+
+**Divisão de conteúdo (Splitting)**
+
+Sintaxes construídas em torno de `t('a.b.c')` são muito convenientes, mas frequentemente incentivam a manutenção de grandes objetos JSON em tempo de execução. Esse modelo torna o tree-shaking difícil, a menos que a biblioteca ofereça uma estratégia real de divisão por página.
+
+## Metodologia
+
+Para este benchmark, comparamos as seguintes bibliotecas:
+
+- `Base App` (Sem biblioteca i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+O framework é `Solid` com um app multilíngue de **10 páginas** e **10 idiomas**.
+
+Comparamos **quatro estratégias de carregamento**:
+
+| Estratégia                | Sem namespaces (global)                          | Com namespaces (scoped)                                               |
+| :------------------------ | :----------------------------------------------- | :-------------------------------------------------------------------- |
+| **Carregamento estático** | **Static**: Tudo na memória ao iniciar.          | **Scoped static**: Dividido por namespace; tudo carregado ao iniciar. |
+| **Carregamento dinâmico** | **Dynamic**: Carregamento sob demanda por local. | **Scoped dynamic**: Carregamento granular por namespace e local.      |
+
+## Resumo das estratégias
+
+- **Static**: Simples; sem latência de rede após o carregamento inicial. Desvantagem: grande tamanho de bundle.
+- **Dynamic**: Reduz o peso inicial (lazy-loading). Ideal quando você tem muitos locais.
+- **Scoped static**: Mantém o código organizado (separação lógica) sem requisições de rede extras complexas.
+- **Scoped dynamic**: Melhor abordagem para _code splitting_ e desempenho. Minimiza a memória carregando apenas o que a view atual e o local ativo precisam.
+
+## Resultados em detalhes
+
+### 1 — Soluções a evitar
+
+> Nenhuma solução clara a evitar no ecossistema Solid.
+
+### 2 — Soluções aceitáveis
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+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`).
+
+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).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+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`):
+
+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.
+Finalmente, em comparação com outras soluções, o Paraglide não usa um store (ex: Solid signal) para recuperar o local atual para renderizar o conteúdo. Para cada nó analisado, ele solicitará o local do localStorage / cookie etc. Isso leva à execução de lógica desnecessária que impacta a reatividade do componente.
+
+### 3 — Recomendações
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Eu não julgarei pessoalmente o `solid-intlayer` por uma questão de objetividade, já que é minha própria solução.
+
+### Nota pessoal
+
+Esta nota é pessoal e não afeta os resultados do benchmark. Ainda assim, no mundo do i18n, você costuma ver consenso em torno de um padrão como `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` para o conteúdo traduzido.
+
+Em apps Solid, injetar uma função como um `JSX.Element` é, na minha opinião, um antipadrão. Também adiciona complexidade evitável e overhead de execução de JavaScript (mesmo que seja quase imperceptível).

package/docs/pt/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+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:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - desempenho
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inicialização do benchmark"
+---
+
+# Bibliotecas i18n para Svelte — Relatório de Benchmark 2026
+
+Esta página é um relatório de benchmark para soluções i18n no Svelte.
+
+## Índice
+
+<Toc/>
+
+## Benchmark Interativo
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## Referência de resultados:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.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_svelte.md
+
+Veja o repositório completo do benchmark [aqui](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introdução
+
+As soluções de internacionalização estão entre as dependências mais pesadas em um app Svelte. O principal risco é enviar conteúdo desnecessário: traduções para outras páginas e outros locais no bundle de uma única rota.
+
+À medida que seu app cresce, esse problema pode rapidamente explodir o JavaScript enviado ao cliente e tornar a navegação lenta.
+
+Na prática, para as implementações menos otimizadas, uma página internacionalizada pode acabar sendo várias vezes mais pesada do que a versão sem i18n.
+
+O outro impacto é na experiência do desenvolvedor (DX): como você declara conteúdo, tipos, organização de namespaces, carregamento dinâmico e reatividade quando o local muda.
+
+## TL;DR
+
+- **Intlayer**: A escolha mais eficiente em desempenho (v8.7.12) 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).
+
+## Teste seu app
+
+Para identificar rapidamente problemas de vazamento de i18n, configurei um scanner gratuito disponível [aqui](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## O problema
+
+Duas alavancas são essenciais para limitar o custo de um app multilíngue:
+
+- Dividir o conteúdo por página / namespace para no carregar dicionários inteiros quando não for necessário.
+- Carregar o local correto dinamicamente, apenas quando necessário.
+
+Entendendo as limitações técnicas dessas abordagens:
+
+**Carregamento dinâmico**
+
+Sem carregamento dinâmico, a maioria das soluções mantém as mensagens na memória desde o primeiro render, o que adiciona um overhead significativo para apps com muitas rotas e locais.
+
+Com carregamento dinâmico, você aceita uma troca: menos JS inicial, mas às vezes uma requisição extra ao trocar de idioma.
+
+**Divisão de conteúdo (Splitting)**
+
+Sintaxes construídas em torno de `t('a.b.c')` são muito convenientes, mas frequentemente incentivam a manutenção de grandes objetos JSON em tempo de execução. Esse modelo torna o tree-shaking difícil, a menos que a biblioteca ofereça uma estratégia real de divisão por página.
+
+## Metodologia
+
+Para este benchmark, comparamos as seguintes bibliotecas:
+
+- `Base App` (Sem biblioteca i18n)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+O framework é `Svelte` com um app multilíngue de **10 páginas** e **10 idiomas**.
+
+Comparamos **quatro estratégias de carregamento**:
+
+| Estratégia                | Sem namespaces (global)                          | Com namespaces (scoped)                                               |
+| :------------------------ | :----------------------------------------------- | :-------------------------------------------------------------------- |
+| **Carregamento estático** | **Static**: Tudo na memória ao iniciar.          | **Scoped static**: Dividido por namespace; tudo carregado ao iniciar. |
+| **Carregamento dinâmico** | **Dynamic**: Carregamento sob demanda por local. | **Scoped dynamic**: Carregamento granular por namespace e local.      |
+
+## Resumo das estratégias
+
+- **Static**: Simples; sem latência de rede após o carregamento inicial. Desvantagem: grande tamanho de bundle.
+- **Dynamic**: Reduz o peso inicial (lazy-loading). Ideal quando você tem muitos locais.
+- **Scoped static**: Mantém o código organizado (separação lógica) sem requisições de rede extras complexas.
+- **Scoped dynamic**: Melhor abordagem para _code splitting_ e desempenho. Minimiza a memória carregando apenas o que a view atual e o local ativo precisam.
+
+## Resultados em detalhes
+
+### 1 — Soluções a evitar
+
+> Nenhuma solução clara a evitar no ecossistema Svelte.
+
+### 2 — Soluções aceitáveis
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+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.
+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. 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 um store (ex: Svelte store) para recuperar o local atual para renderizar o conteúdo. Para cada nó analisado, ele solicitará o local do localStorage / cookie etc. Isso leva à execução de lógica desnecessária que impacta a reatividade do componente.
+
+> 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`):
+
+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`).
+
+### 3 — Recomendações
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+Eu não julgarei pessoalmente o `svelte-intlayer` por uma questão de objetividade, já que é minha própria solução.
+
+### Nota pessoal
+
+Esta nota é pessoal e não afeta os resultados do benchmark. Ainda assim, no mundo do i18n, você costuma ver consenso em torno de um padrão como `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` para o conteúdo traduzido.
+
+Em apps Svelte, injetar uma função como um `Slot` é, na minha opinião, um antipadrão. Também adiciona complexidade evitável e overhead de execução de JavaScript (mesmo que seja quase imperceptível).

package/docs/pt/benchmark/tanstack.md

@@ -55,7 +55,14 @@ As soluções de internacionalização estão entre as dependências mais pesada
 
 Na prática, para as implementações menos otimizadas, uma página internacionalizada pode acabar ficando várias vezes mais pesada do que a versão sem i18n.
 
-O outro impacto é na experiência do desenvolvedor: como você declara o conteúdo, tipos, organização de namespaces, carregamento dinâmico e reatividade quando a localidade muda.
+O outro impacto é na experência do desenvolvedor: como você declara o conteúdo, tipos, organização de namespaces, carregamento dinâmico e reatividade quando a localidade muda.
+
+## TL;DR
+
+- **Intlayer**: Oferece o melhor desempenho e o menor tamanho de bundle (v8.7.12) 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).
 
 ## Teste sua aplicação
 
@@ -87,12 +94,12 @@ 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.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,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.
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> 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.
+
+**(Tolgee)** (`@tolgee/react@7.0.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.
 

package/docs/pt/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+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:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - desempenho
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inicialização do benchmark"
+---
+
+# Bibliotecas i18n para Vue — Relatório de Benchmark 2026
+
+Esta página é um relatório de benchmark para soluções i18n no Vue.
+
+## Índice
+
+<Toc/>
+
+## Benchmark Interativo
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## Referência de resultados:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.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_vue.md
+
+Veja o repositório completo do benchmark [aqui](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introdução
+
+As soluções de internacionalização estão entre as dependências mais pesadas em um app Vue. O principal risco é enviar conteúdo desnecessário: traduções para outras páginas e outros locais no bundle de uma única rota.
+
+À medida que seu app cresce, esse problema pode rapidamente explodir o JavaScript enviado ao cliente e tornar a navegação lenta.
+
+Na prática, para as implementações menos otimizadas, uma página internacionalizada pode acabar sendo várias vezes mais pesada do que a versão sem i18n.
+
+O outro impacto é na experiência do desenvolvedor (DX): como você declara conteúdo, tipos, organização de namespaces, carregamento dinâmico e reatividade quando o local muda.
+
+## TL;DR
+
+- **Intlayer**: A solução mais leve (v8.7.12) 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.
+
+## Teste seu app
+
+Para identificar rapidamente problemas de vazamento de i18n, configurei um scanner gratuito disponível [aqui](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## O problema
+
+Duas alavancas são essenciais para limitar o custo de um app multilíngue:
+
+- Dividir o conteúdo por página / namespace para não carregar dicionários inteiros quando não for necessário.
+- Carregar o local correto dinamicamente, apenas quando necessário.
+
+Entendendo as limitações técnicas dessas abordagens:
+
+**Carregamento dinâmico**
+
+Sem carregamento dinâmico, a maioria delle soluções mantém as mensagens na memória desde o primeiro render, o que adiciona um overhead significativo para apps com muitas rotas e locais.
+
+Com carregamento dinâmico, você aceita uma troca: menos JS inicial, mas às vezes uma requisição extra ao trocar de idioma.
+
+**Divisão de conteúdo (Splitting)**
+
+Sintaxes construídas em torno de `const { t } = useI18n()` + `t('a.b.c')` são muito convenientes, mas frequentemente incentivam a manutenção de grandes objetos JSON em tempo de execução. Esse modelo torna o tree-shaking difícil, a menos que a biblioteca ofereça uma estratégia real de divisão por página.
+
+## Metodologia
+
+Para este benchmark, comparamos as seguintes bibliotecas:
+
+- `Base App` (Sem biblioteca i18n)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+O framework é `Vue` com um app multilíngue de **10 páginas** e **10 idiomas**.
+
+Comparamos **quatro estratégias de carregamento**:
+
+| Estratégia                | Sem namespaces (global)                          | Com namespaces (scoped)                                               |
+| :------------------------ | :----------------------------------------------- | :-------------------------------------------------------------------- |
+| **Carregamento estático** | **Static**: Tudo na memória ao iniciar.          | **Scoped static**: Dividido por namespace; tudo carregado ao iniciar. |
+| **Carregamento dinâmico** | **Dynamic**: Carregamento sob demanda por local. | **Scoped dynamic**: Carregamento granular por namespace e local.      |
+
+## Resumo das estratégias
+
+- **Static**: Simples; sem latência de rede após o carregamento inicial. Desvantagem: grande tamanho de bundle.
+- **Dynamic**: Reduz o peso inicial (lazy-loading). Ideal quando você tem muitos locais.
+- **Scoped static**: Mantém o código organizado (separação lógica) sem requisições de rede extras complexas.
+- **Scoped dynamic**: Melhor abordagem para _code splitting_ e desempenho. Minimiza a memória carregando apenas o que a view atual e o local ativo precisam.
+
+### O que eu medi:
+
+Executei o mesmo app multilíngue em um navegador real para cada stack e anotei o que realmente passou pela rede e quanto tempo as coisas levaram. Os tamanhos são relatados **após a compressão web normal**, pois isso é mais próximo do que as pessoas realmente baixam.
+
+- **Tamanho da biblioteca de internacionalização**: Após bundling, tree-shaking e minificação, o tamanho da biblioteca i18n é o tamanho do código dos providers + composables em um componente vazio. Não inclui o carregamento de arquivos de tradução. Responde o quão "cara" a biblioteca é antes do seu conteúdo entrar em cena.
+
+- **JavaScript por página**: Para cada rota de benchmark, quanto script o navegador puxa para aquela visita, calculado pela média entre as páginas do conjunto (e entre os locais). Páginas pesadas são páginas lentas.
+
+- **Vazamento de outros locais (Leakage)**: É o conteúdo da mesma página, mas em outro idioma, que seria carregado por engano na página auditada. Este conteúdo é desnecessário e deve ser evitado (ex: conteúdo da página `/fr/about` no bundle da página `/en/about`).
+
+- **Vazamento de outras rotas**: A mesma ideia para **outras telas** no app: se os textos delas estão vindo junto quando você abriu apenas uma página (ex: conteúdo da página `/en/about` no bundle da página `/en/contact`). Uma pontuação alta sugere divisão fraca ou bundles excessivamente amplos.
+
+- **Tamanho médio do bundle do componente**: Elementos de UI comuns são medidos **um por um**, em vez de se esconderem dentro de um único número gigante do app. Mostra se a internacionalização infla silenciosamente os componentes do dia a dia. Por exemplo, se o seu componente re-renderiza, ele carregará todos esses dados da memória. Anexar um JSON gigante a qualquer componente é como conectar um grande depósito de dados não utilizados que retardará o desempenho dos seus componentes.
+
+- **Capacidade de resposta à mudança de idioma**: Eu troco o idioma usando o próprio controle do app e cronometro quanto tempo leva até que a página tenha mudado claramente, o que um visitante notaria.
+
+- **Trabalho de renderização após uma mudança de idioma**: Um acompanhamento mais detalhado: quanto esforço a interface levou para redesenhar para o novo idioma assim que a mudança começou. Útil quando o tempo "sentido" e o custo do framework divergem.
+
+- **Tempo inicial de carregamento da página**: Da navegação até o navegador considerar a página totalmente carregada para os cenários que testei. Bom para comparar inicializações a frio.
+
+- **Tempo de hidratação (Hydration)**: O tempo que o cliente gasta transformando o HTML do servidor em uma interface interativa. Um traço nas tabelas significa que aquela implementação não forneceu um número de hidratação confiável neste benchmark.
+
+## Resultados em detalhes
+
+### 1 — Soluções a evitar
+
+> Nenhuma solução clara a evitar no ecossistema Vue.
+
+### 2 — Soluções aceitáveis
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **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`).
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **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`).
+
+### 3 — Recomendações
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+Eu não julgarei pessoalmente o `vue-intlayer` por uma questão de objetividade, já que é minha própria solução.