@intlayer/docs 9.5.6 → 9.5.8

package/blog/pt/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark e Comparativo 2026"
 description: "react-i18next e next-i18next medidos contra o Intlayer no Next.js e TanStack Start. Tamanho do bundle, vazamento de conteúdo, reatividade na troca de idioma e experiência de desenvolvimento."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark de internacionalização (i18n) para React e Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 O `i18next` é o framework de i18n mais utilizado no ecossistema JavaScript. Através do `react-i18next` e `next-i18next`, sustenta grande parte das aplicações React e Next.js. O Intlayer é uma alternativa baseada em compilador, com escopo por componente.
 
 Este artigo compara ambas as soluções com base em medições reais e não em listas de recursos. Os números vêm do [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), uma suíte de código aberto que constrói a mesma aplicação com cada biblioteca e registra o que o navegador realmente baixa.
@@ -99,6 +101,10 @@ Para cada build, a suíte registra:
 
 ### Resultados no Next.js (`next-i18next`)
 
+Escolha as métricas e as bibliotecas que importam para você:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Biblioteca                        | Estratégia     | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | Reatividade E2E | Hydration |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | --------------: | --------: |
 | **base** (sem i18n)               | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |         13.4 ms |   11.8 ms |
@@ -119,6 +125,15 @@ Para cada build, a suíte registra:
 - **Tamanho dos componentes.** Um componente invocando `useTranslation()` compila entre 26 e 79 KB; o mesmo componente com `useIntlayer()` compila em 6.9 KB.
 - **A hidratação** sobe para 27.7 ms na configuração `dynamic`: a instância do i18next inicializa e resolve o backend no cliente antes de o React conseguir hidratar a página.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabela completa, cada biblioteca e cada estratégia, no [relatório de benchmark do Next.js](https://intlayer.org/pt/doc/benchmark/nextjs).
+
 ### Resultados no TanStack Start (`react-i18next`)
 
 A mesma aplicação no TanStack Start com `react-i18next` puro, isolando os efeitos específicos do Next.js.
@@ -141,8 +156,19 @@ A mesma aplicação no TanStack Start com `react-i18next` puro, isolando os efei
 - A linha `static` do Intlayer já apresenta **0% de vazamento de página** porque somente os dicionários importados pelos componentes daquela página são empacotados. Ativar `importMode: 'dynamic'` elimina também o vazamento de idioma.
 - **Tamanho por componente**: 24-27 KB com `react-i18next` contra 6-8 KB com Intlayer. O `useTranslation()` conecta cada componente à instância global do i18next.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabela completa no [relatório de benchmark do TanStack Start](https://intlayer.org/pt/doc/benchmark/tanstack).
+
 ## De onde vem a diferença? Instância global vs. dicionários compilados
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 O `i18next` foi projetado em 2012 como um runtime: uma instância global mantém os recursos, plugins a expandem e `t()` busca chaves em tempo de renderização. Isso proporciona grande flexibilidade (qualquer framework, backend ou formato), mas impõe custo de peso:
 
 ```bash
@@ -166,7 +192,13 @@ O `i18next` foi projetado em 2012 como um runtime: uma instância global mantém
                 └── page.tsx     # precisa saber que depende de ["common", "about"]
 ```
 
-A instância não tem como prever quais chaves um componente solicitará. Otimizar exige que **você** divida catálogos em namespaces, **você** liste os namespaces de cada página e **você** mantenha essa lista sincronizada ao mover componentes. Como destacam as [notas do benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "manter a segurança de tipos e saber com precisão qual namespace incluir em cada página é um pesadelo".
+A instância não tem como prever quais chaves um componente solicitará. Otimizar exige que **você** divida catálogos em namespaces, **você** liste os namespaces de cada página e **você** mantenha essa lista sincronizada ao mover componentes.
+
+O custo cresce em dois eixos simultaneamente, páginas e idiomas:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Como destacam as [notas do benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "manter a segurança de tipos e saber com precisão qual namespace incluir em cada página é um pesadelo".
 
 O Intlayer remove a instância global. O conteúdo é declarado ao lado do componente e o compilador resolve o grafo de dependências no momento do build:
 
@@ -193,7 +225,8 @@ O `@intlayer/swc` / `@intlayer/babel` identifica qual componente importa qual di
 
 ### Configuração
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Adiciona-se a isso um `I18nProvider` client-side que recria a instância com as mesmas configurações, `generateStaticParams` e uma lista de `namespaces` em cada página.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Componente de cliente
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > A página que renderiza este componente precisa carregar o namespace `about`, e `t("counter.label")` é uma string simples a menos que você estenda `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` e `increment` são estritamente tipados; erros de digitação tornam-se erros de TypeScript e uma tradução ausente causa erro na compilação.
 
+</Tab>
+</Tabs>
+
 ### Componente de servidor síncrono
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 A página invoca `i18n.getFixedT(locale, "about")` e propaga `t` e `locale` via props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Mantenha a API do i18next, aproveite o desempenho do Intlayer
 
 Você não precisa reescrever componentes para obter os números do benchmark. `@intlayer/i18next`, `@intlayer/react-i18next` e `@intlayer/next-i18next` são adaptadores compatíveis: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurais `_one` / `_other`, sufixos de contexto e `returnObjects` continuam operacionais, alimentados pelos dicionários compilados pelo Intlayer.
@@ -415,18 +462,85 @@ Consulte os guias de migração: [i18next](https://intlayer.org/pt/doc/migration
 
 ## Quando escolher cada um?
 
-- **Escolha o i18next** se você depende de seu ecossistema de plugins (detectores, backends, ICU, Locize), traduz também fora do React (serviços Node, vanilla JS, outros frameworks), seu time já possui domínio ou uma plataforma externa exige `locales/{lng}/{ns}.json`. Reserve tempo para separar catálogos em namespaces, conectar um backend e manter o mapa de rotas se a performance for prioritária.
-- **Escolha o Intlayer** se busca **conteúdo com escopo por componente**, **TypeScript estrito**, **detecção de chaves ausentes no build**, **tree-shaking e lazy loading automáticos**, troca instantânea de idioma, componentes de servidor síncronos e ferramentas editoriais nativas (Editor Visual, CMS, tradução com IA, servidor MCP). Ideal para bases de código modulares e design systems.
-- **Escolha os adaptadores `@intlayer/*-i18next`** se você já utiliza o i18next e quer os ganhos de bundle e reatividade sem precisar reescrever seus componentes.
+<AccordionGroup>
+<Accordion header="Escolher o i18next">
+
+Se você depende de seu ecossistema de plugins (detectores, backends, ICU, Locize), traduz também fora do React (serviços Node, vanilla JS, outros frameworks), seu time já possui domínio ou uma plataforma externa exige `locales/{lng}/{ns}.json`. Reserve tempo para separar catálogos em namespaces, conectar um backend e manter o mapa de rotas se a performance for prioritária.
+
+</Accordion>
+<Accordion header="Escolher o Intlayer">
+
+Você valoriza **conteúdo no nível do componente**, **TypeScript estrito**, **erros em tempo de compilação para chaves ausentes**, **tree-shaking e lazy loading sem esforço**, troca instantânea de idioma, componentes de servidor síncronos e ferramentas editoriais integradas ([Editor Visual](https://intlayer.org/pt/doc/concept/editor), [CMS](https://intlayer.org/pt/doc/concept/cms), [tradução por IA](https://intlayer.org/pt/doc/concept/auto-fill), [servidor MCP](https://intlayer.org/pt/doc/mcp-server)). Especialmente relevante para bases de código modulares e design systems.
+
+</Accordion>
+<Accordion header="Escolher os adaptadores @intlayer/*-i18next">
+
+Você já está no i18next e quer os ganhos de bundle e reatividade sem reescrever seus componentes. Seus arquivos `locales/{lng}/{ns}.json` permanecem como a fonte da verdade. Medido lado a lado em [i18next vs @intlayer/i18next](https://intlayer.org/pt/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Por que o i18next é muito mais pesado que outras bibliotecas?">
+
+Ele foi projetado como um runtime agnóstico a frameworks: uma instância global, um pipeline de plugins, um repositório de recursos, um resolvedor de chaves. Essa flexibilidade é compilada em cada bundle. Um componente vazio que apenas importa a biblioteca custa **19.7 KB gzip** com `next-i18next` contra **5.5 KB** com `next-intlayer`, e esse custo é pago em todas as páginas, independentemente do peso do conteúdo.
+
+</Question>
+
+<Question title="O lazy loading com um backend resolve o problema?">
+
+Ele resolve os bytes, não a latência. Mudar para `i18next-resources-to-backend` economiza ~49 KB por página, mas adiciona um ciclo de ida e volta na rede ao trocar de idioma: **123 ms** na configuração `dynamic` e **185 ms** em `scoped-static`, contra **3-4 ms** com o Intlayer. A hidratação também sobe para 27.7 ms porque a instância resolve o backend antes de o React poder hidratar.
+
+</Question>
+
+<Question title="Posso atingir 0% de vazamento com o i18next?">
+
+Sim, com `scoped-dynamic`: um namespace por rota, um backend de recursos e um mapa de página para namespace mantido manualmente. Isso resulta em 163.4 KB por página no Next.js, ainda **+22 KB** sobre os 141.3 KB do Intlayer, que não precisou de nenhuma configuração. Veja a [otimização de bundle](https://intlayer.org/pt/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Preciso reescrever meus componentes para migrar?">
+
+Não. `@intlayer/i18next`, `@intlayer/react-i18next` e `@intlayer/next-i18next` mantêm `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurais `_one` / `_other`, sufixos de contexto e `returnObjects`. Apenas uma linha de plugin no `next.config.ts` ou `vite.config.ts`. Passo a passo no [guia de migração do next-i18next](https://intlayer.org/pt/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="O que acontece com meus plugins do i18next?">
+
+Backends e detectores de idioma são aceitos, mas ficam inertes: não há nada para carregar ou detectar em tempo de execução. A detecção de idioma passa a ser a configuração de roteamento do Intlayer (prefixo de URL, cookie, cabeçalho). Se seu aplicativo busca traduções de um CMS no momento da requisição, use o [CMS do Intlayer](https://intlayer.org/pt/doc/concept/cms) ou `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Comparações relacionadas
 
-- [next-intl vs Intlayer](https://intlayer.org/pt/blog/next-intl-vs-intlayer) (mesmo benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/pt/blog/lingui-vs-intlayer) (mesmo benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/pt/blog/vue-i18n-vs-intlayer-benchmark) (mesmo benchmark)
+Mesmo benchmark, outras bibliotecas:
+
+- [next-intl vs Intlayer](https://intlayer.org/pt/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/pt/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/pt/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/pt/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/pt/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Aprofundando no i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/pt/blog/i18next-vs-intlayer-i18next), os adaptadores medidos na mesma aplicação
 - [O i18next está desatualizado?](https://intlayer.org/pt/blog/is-i18next-outdated)
+- [Usando o Intlayer com i18next](https://intlayer.org/pt/blog/intlayer-with-i18next) e [com react-i18next](https://intlayer.org/pt/blog/intlayer-with-react-i18next)
+- [Como internacionalizar um app Next.js com next-i18next](https://intlayer.org/pt/blog/nextjs-internationalization-using-next-i18next)
+
+Documentos de referência:
+
+- [Relatório de benchmark do Next.js](https://intlayer.org/pt/doc/benchmark/nextjs) e [relatório de benchmark do TanStack Start](https://intlayer.org/pt/doc/benchmark/tanstack)
+- Adaptadores de compatibilidade: [i18next](https://intlayer.org/pt/doc/compatibility/i18next), [react-i18next](https://intlayer.org/pt/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/pt/doc/compatibility/next-i18next)
+- Guias de migração: [i18next](https://intlayer.org/pt/doc/migration/i18next), [react-i18next](https://intlayer.org/pt/doc/migration/react-i18next), [next-i18next](https://intlayer.org/pt/doc/migration/next-i18next)
+- [Otimização de bundle](https://intlayer.org/pt/doc/concept/bundle-optimization) e [o compilador Intlayer](https://intlayer.org/pt/doc/compiler)
+- [i18n por componente vs centralizada](https://intlayer.org/pt/blog/per-component-vs-centralized-i18n)
+- [i18n orientada a compilador vs declarativa](https://intlayer.org/pt/blog/compiler-vs-declarative-i18n)
 
 ## Estrelas no GitHub
 

package/blog/pt/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: O Intlayer é mais leve que o Paraglide?
+description: O Paraglide parece quase gratuito nos benchmarks de i18n porque seu código é gerado diretamente no seu repositório. Veja para onde esse peso realmente vai, por que a resolução de locale por nó consome recursos e como o carregamento dinâmico do Intlayer envia apenas um idioma em vez de todos.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internacionalização
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# O Intlayer é mais leve que o Paraglide?
+
+Sim.
+
+O `Paraglide` tem uma boa reputação por ser a solução de i18n mais leve disponível, e à primeira vista o [benchmark](https://intlayer.org/pt/doc/benchmark/tanstack) concorda: o tamanho de sua biblioteca é próximo de zero. Mas um tamanho de biblioteca de zero não significa zero bytes enviados. Significa apenas que os bytes residem onde a métrica não olha.
+
+<TOC/>
+
+## Principais conclusões
+
+**O tamanho da biblioteca está oculto, não eliminado:**
+
+O Paraglide gera sua runtime e funções de mensagens diretamente na sua codebase. Esse código é enviado ao navegador, mas é contabilizado como _seu_ código, não como o da biblioteca.
+
+**Não ter provider não é um ganho gratuito:**
+
+Cada chamada a `m.my_key()` resolve o locale por conta própria, lendo o cookie ou o storage para cada nó renderizado, em vez de ler uma única vez a partir de um contexto.
+
+**Sem carregamento dinâmico:**
+
+O Paraglide importa todos os idiomas de uma mensagem no bundle do seu cliente. O Intlayer com `importMode: 'dynamic'` ou `'fetch'` carrega apenas o idioma que está sendo renderizado.
+
+**O tree shaking não é garantido:**
+
+Em alguns de nossos benchmarks, o tree shaking divulgado pelo Paraglide não teve efeito. Verifique o seu próprio bundle.
+
+## Para onde vai o peso do Paraglide?
+
+Nos relatórios de benchmark, a métrica "tamanho da biblioteca" mede o provider e os hooks de cada biblioteca de i18n em um componente vazio, antes de qualquer conteúdo ser adicionado.
+
+| Biblioteca (TanStack Start)   | Tam lib (gz) | Tam lib (min) |
+| ----------------------------- | ------------ | ------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB       | 4.5 KB        |
+| `react-intlayer@9.5.1`        | 5.0 KB       | 15.2 KB       |
+
+Analisado isoladamente, o Paraglide vence. Mas o Paraglide é um compilador: ele lê seus arquivos `messages/*.json` e escreve uma pasta `paraglide/` no seu repositório, contendo um arquivo `runtime.js` (detecção de locale, estratégias de cookies e storage, localização de URLs) e uma função JavaScript por mensagem.
+
+```bash
+src/paraglide/
+├── runtime.js      # detecção de locale, estratégias, helpers de URL
+├── server.js
+├── messages.js     # reexporta todas as mensagens
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Como esse código fica na sua pasta `src/` e você o importa através de um caminho relativo, o bundler o atribui à sua aplicação, e não a um pacote em `node_modules`. A coluna de tamanho da biblioteca exibe quase nada, enquanto a mesma lógica continua sendo enviada no bundle da sua página.
+
+Gerar código não é uma má ideia em si: a runtime gerada inclui apenas a lógica que sua configuração precisa (estratégia de prefixo, cookie vs. local storage, etc.). O Intlayer alcança o mesmo resultado de maneira diferente, injetando variáveis de ambiente em tempo de build para que o bundler descarte as ramificações que sua configuração não utiliza. Ambas as abordagens acabam sendo de 3 a 10 vezes mais leves do que `i18next` ou `next-intl`.
+
+Portanto, a comparação justa não é o tamanho da biblioteca. É **o JavaScript realmente enviado por página**.
+
+## Peso por página, medido
+
+Aplicação TanStack Start, 10 páginas, medido nas rotas `en` e `fr`, comprimido com gzip:
+
+| Configuração                       | JS pág médio (gz) | Acima da base | Vazamento locale | Vazamento outras págs |
+| ---------------------------------- | ----------------- | ------------- | ---------------- | --------------------- |
+| Base (sem i18n)                    | 111.0 KB          | -             | 0.0%             | 0.0%                  |
+| `paraglide` (qualquer estratégia)  | 125.1 KB          | +14.1 KB      | 49.7%            | 0.0%                  |
+| `intlayer` (`importMode: static`)  | 125.8 KB          | +14.8 KB      | 50.0%            | 0.0%                  |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**      | **+7.6 KB**   | **0.0%**         | **0.0%**              |
+
+Next.js 16 App Router, mesma aplicação:
+
+| Configuração     | JS pág médio (gz) | Acima da base |
+| ---------------- | ----------------- | ------------- |
+| Base (sem i18n)  | 141.0 KB          | -             |
+| `paraglide-next` | 155.3 KB          | +14.3 KB      |
+| `next-intlayer`  | **141.3 KB**      | **+0.3 KB**   |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Dados completos no [relatório de benchmark TanStack Start](https://intlayer.org/pt/doc/benchmark/tanstack) e no [relatório de benchmark Next.js](https://intlayer.org/pt/doc/benchmark/nextjs). Cada bundle pode ser inspecionado no [repositório do benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Dois pontos se destacam:
+
+- No modo `static`, o Intlayer envia praticamente o mesmo conteúdo que o Paraglide (125.8 KB vs. 125.1 KB). Isso é esperado: ambos incluem todos os idiomas das mensagens que uma página utiliza.
+- O Paraglide permanece em 125.1 KB independentemente da estratégia, pois não possui um modo dinâmico. Cada linha na tabela acima corresponde à opção estática.
+
+## Sem Provider: uma ideia que parece boa, mas não é
+
+O Paraglide não requer provider. Você importa uma mensagem e a executa:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Sem contexto, sem wrapper, sem hook. Parece mais simples. Porém, o locale ainda precisa vir de algum lugar. Cada função de mensagem gerada se parece com isto (simplificado):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // resolvido a cada chamada
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...uma ramificação por locale
+};
+```
+
+E `getLocale()` percorre as estratégias configuradas (cookie, local storage, URL, locale padrão) para identificar o locale atual. Assim, cada nó de texto renderizado (`<>{m.my_key()}</>`) executa sua própria resolução de locale, incluindo ler `document.cookie` no navegador. Uma página com 200 strings traduzidas resolve o locale 200 vezes por renderização, e novamente a cada nova renderização.
+
+Uma biblioteca baseada em provider lê o locale **uma única vez**, o armazena em um contexto (ou sinal, ou store), e cada nó lê um valor já residente na memória. O provider custa algumas centenas de bytes. Deixar de usá-lo consome ciclos de CPU a cada renderização, o que se reflete no benchmark: os tempos de carregamento de página e troca de idioma do Paraglide ficam sistematicamente atrás dos do Intlayer no TanStack Start (22.1 ms vs. 14.6 ms no carregamento de página, 4.3 ms vs. 3.2 ms na reatividade E2E).
+
+## Experiência do Desenvolvedor (DX)
+
+A fonte da verdade do Paraglide é o JSON, mas você nunca importa o JSON diretamente. Você importa o arquivo `.js` gerado:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/pt.json"
+{
+  "hero_title": "Publique seu app em todos os idiomas"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Existe apenas após o compilador regenerá-lo a partir do JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      pt: "Publique seu app em todos os idiomas",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Esse fluxo de desenvolvimento tem um custo:
+
+- Cada alteração em um arquivo JSON exige regeneração antes que a importação resolva ou os tipos sejam atualizados.
+- A pasta gerada `paraglide/` deve ser commitada (gerando conflitos de merge em arquivos gerados em cada PR que altere textos) ou ignorada (exigindo uma etapa de geração prévia a cada verificação de tipos, testes e job de CI).
+- Cada string vira uma chamada de função. Constantes tornam-se `m.key()` em todos os lugares, inclusive onde um valor estático bastaria.
+
+## Tree Shaking: verifique seu bundle
+
+A promessa central do Paraglide é que mensagens não utilizadas sofrem tree shaking, já que cada mensagem é seu próprio export. No benchmark com Svelte + Vite, isso funciona conforme divulgado.
+
+Em outros cenários, não funcionou. Em nossos testes no [Next.js](https://intlayer.org/pt/doc/benchmark/nextjs), as páginas do Paraglide pesam 14 KB a mais do que a aplicação base, enquanto o `next-intlayer` adiciona apenas 0.3 KB. Execuções anteriores no TanStack Start também mostraram mensagens de outras páginas indo parar no bundle da rota.
+
+O tree shaking depende do seu bundler (Turbopack, Rolldown, Rollup), de como as mensagens são importadas (`import { m }` vs. `import * as m`) e da análise de side effects. Se você optar pelo Paraglide pelo seu tamanho, abra seu visualizador de bundle e comprove se isso se mantém na sua aplicação.
+
+## Sem carregamento dinâmico
+
+Este é o limite estrutural. O Paraglide não possui uma forma de carregar um idioma por vez: cada função de mensagem importa estaticamente a implementação de cada idioma, portanto todos os idiomas acabam no bundle do seu cliente.
+
+Com 2 idiomas, metade da sua carga de traduções é desperdiçada, o que equivale aos ~50% de vazamento de locale medidos acima. Com 10 idiomas, 90%. Com 30 idiomas, 97%.
+
+Mudar para o carregamento dinâmico também não resolveria: com uma função por mensagem, carregar cada uma sob demanda resultaria em milhares de requisições.
+
+O Intlayer permite que você escolha, globalmente ou por dicionário:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | O que é enviado ao cliente                                  | vs. Paraglide                   |
+| ------------ | ----------------------------------------------------------- | ------------------------------- |
+| `static`     | Todos os idiomas dos dicionários usados pela página         | Teoricamente o mesmo conteúdo   |
+| `dynamic`    | Apenas o idioma atual, carregado sob demanda por dicionário | **N vezes menor** com N idiomas |
+| `fetch`      | Apenas o idioma atual, buscado através da Live Sync API     | **N vezes menor** com N idiomas |
+
+Com a [transformação no build](https://intlayer.org/pt/doc/concept/bundle-optimization) e `importMode: 'static'`, o Intlayer carrega, em teoria, exatamente o mesmo conteúdo que o Paraglide. Com `'dynamic'` ou `'fetch'`, ele carrega apenas o que o idioma atual necessita: para um app em N idiomas, a carga de tradução é N vezes menor do que a do Paraglide.
+
+## Onde o Paraglide ainda se encaixa
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite com poucos idiomas">
+
+Se a sua stack é Svelte com Vite e você suporta dois ou três idiomas, o tree shaking funciona como anunciado e o overhead de idiomas permanece pequeno.
+
+</Accordion>
+<Accordion header="Fluxo de trabalho inlang existente">
+
+Se sua equipe já utiliza o ecossistema inlang (Fink, Sherlock, plugins de formato de mensagens), o Paraglide se integra a ele nativamente.
+
+</Accordion>
+</AccordionGroup>
+
+## Teste na sua aplicação
+
+Avalie o payload e os vazamentos de locale da sua aplicação em produção com o [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) gratuito:
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Para instalar o Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Leituras complementares
+
+- [Benchmark de i18n TanStack Start](https://intlayer.org/pt/doc/benchmark/tanstack)
+- [Benchmark de i18n Next.js](https://intlayer.org/pt/doc/benchmark/nextjs)
+- [Otimização de bundle e `importMode`](https://intlayer.org/pt/doc/concept/bundle-optimization)
+- [Como escolher uma biblioteca de i18n para React](https://intlayer.org/pt/blog/how-to-pick-react-i18n-library)
+- [Por que escolher internacionalização orientada a compilador](https://intlayer.org/pt/blog/compiler-vs-declarative-i18n)