@intlayer/docs 9.5.6 → 9.5.7

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/lingui_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "Lingui vs Intlayer: Benchmark e Comparativo 2026"
 description: "Duas bibliotecas de i18n baseadas em compilador avaliadas no Next.js e TanStack Start. Tamanho do bundle, vazamento de conteúdo, tamanho dos componentes, hidratação, reatividade na troca de idioma e experiência do desenvolvedor."
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # Lingui VS Intlayer | Benchmark de Internacionalização (i18n) para React e Next.js
 
+![JavaScript i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Lingui e Intlayer são as duas bibliotecas deste benchmark que utilizam um **compilador** em vez de operarem estritamente como um runtime. O Lingui extrai mensagens a partir de macros durante o build e compila catálogos por idioma. O Intlayer compila dicionários por componente e aplica tree-shaking por idioma. Na teoria, deveriam ser muito parecidos. Os números revelam onde eles se distanciam.
 
 Os dados são provenientes 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 afere o que o navegador efetivamente baixa e executa.
@@ -96,6 +98,10 @@ Para cada compilação, registram-se:
 
 ### Resultados no Next.js
 
+Escolha as métricas e bibliotecas do seu interesse:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Biblioteca          | Estratégia     | Lib size (gz) | Page JS méd (gz) | Vazamento idioma | Vazamento página | Componente méd (gz) | Reatividade E2E | Hidratação |
 | ------------------- | -------------- | ------------: | ---------------: | ---------------: | ---------------: | ------------------: | --------------: | ---------: |
 | **base** (sem i18n) | -              |        0,0 KB |         141,0 KB |             0,0% |             0,0% |              0,9 KB |         13,4 ms |    11,8 ms |
@@ -114,6 +120,15 @@ Para cada compilação, registram-se:
 - **O fallback do idioma de origem vaza por construção.** Mesmo nas configurações mais bem planejadas, **entre 3% e 15% das strings em inglês são enviadas nas páginas em francês**. As macros do Lingui guardam o texto fonte como salvaguarda, de modo que ele aterrissa no bundle. O Intlayer resolve fallbacks no build e entrega exclusivamente o idioma ativo.
 - **O tamanho dos componentes isolados dispara em `scoped-dynamic`.** Cada componente compilado isoladamente projeta uma média de **152,6 KB**, pois os catálogos das rotas permanecem alcançáveis pelos imports. O mesmo componente usando `useIntlayer()` registra uma média de **6,9 KB**.
 
+<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
 
 | Biblioteca                  | Estratégia     | Lib size (gz) | Page JS méd (gz) | Vazamento idioma | Vazamento página | Componente méd (gz) | Reatividade E2E | Hidratação |
@@ -135,8 +150,19 @@ Para cada compilação, registram-se:
 - **A linha `static` do Intlayer já apresenta 0% de vazamento de página**, pois inclui unicamente os dicionários consumidos pelos componentes daquela tela. Uma única linha de configuração (`importMode: 'dynamic'`) extingue igualmente o vazamento de idioma.
 - **`@intlayer/lingui`** mantém a sintaxe das macros do Lingui consumindo dicionários do Intlayer. Ele cede um pouco no tamanho final da página (137 KB, devido à presença do runtime de macros) em troca de componentes muito mais leves (12,8 KB) e hidratação mais ágil. Uma excelente rota de transição.
 
+<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).
+
 ## Qual é a origem desse contraste? Dois compiladores, duas unidades de trabalho
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Ambas as soluções utilizam um compilador. O divisor de águas é **o que** elas compilam.
 
 **O Lingui compila catálogos.** As macros espalhadas pelo seu código são recolhidas em um arquivo `.po` por idioma e compiladas em um módulo JS por idioma. A unidade central é o **idioma**. Dividir além disso, por rota ou por componente, pressupõe criar catálogos adicionais, configurar o `lingui.config.ts` para extrair cada pedaço separadamente e administrar o carregamento manualmente. A instância `I18n` é global; cada `useLingui()` subscreve o componente a ela.
@@ -176,7 +202,9 @@ Ambas as soluções utilizam um compilador. O divisor de águas é **o que** ela
             └── about.content.ts
 ```
 
-É por essa razão que o padrão `scoped-dynamic` é uma entrega nativa e automática do Intlayer, enquanto no Lingui constitui um projeto próprio de engenharia de configuração.
+É por essa razão que o padrão `scoped-dynamic` é uma entrega nativa e automática do Intlayer, enquanto no Lingui constitui um projeto próprio de engenharia de configuração. O abismo aumenta em dois eixos ao mesmo tempo, páginas e idiomas:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 > Para reproduzir as marcas da linha `dynamic`, defina `dictionary.importMode: 'dynamic'` no seu `intlayer.config.ts`. Acesse a [documentação sobre otimização de bundle](https://intlayer.org/pt/doc/concept/bundle-optimization).
 
@@ -184,7 +212,8 @@ Ambas as soluções utilizam um compilador. O divisor de águas é **o que** ela
 
 ### Configuração
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="lingui.config.ts"
 import { defineConfig } from "@lingui/cli";
@@ -215,7 +244,8 @@ export const loadCatalog = async (locale: string) => {
 
 Depois é necessário incluir `@lingui/babel-plugin-lingui-macro` (ou `@lingui/swc-plugin`) ao bundler, rodar `lingui extract` após alterar textos, rodar `lingui compile` antes do build e encapsular a aplicação em `<I18nProvider i18n={i18n}>`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -232,9 +262,12 @@ export default config;
 
 Basta adicionar `intlayer()` ao seu `vite.config.ts` (ou `withIntlayer()` no `next.config.ts`) e envolver a árvore de renderização com `<IntlayerProvider>`. Sem etapas de extração ou compilação manuais: os dicionários são montados diretamente quando o empacotador roda.
 
+</Tab>
+</Tabs>
 ### Componente
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```tsx fileName="src/components/Counter.tsx"
 import { useState } from "react";
@@ -258,7 +291,8 @@ export const Counter = () => {
 
 O texto em inglês vive no próprio componente; a tradução em francês fica em `src/locales/fr/messages.po` sob um ID em hash após a execução de `lingui extract`. Esquecer de extrair ou compilar aciona silenciosamente a string em inglês como fallback.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -297,11 +331,14 @@ export const Counter = () => {
 
 Ambos os idiomas coexistem no mesmo arquivo ao lado do componente. Um valor de `fr` em falta gera erro no build; uma chave digitada de forma errada aciona o verificador de tipos do TypeScript na hora.
 
+</Tab>
+</Tabs>
 ### Fora dos componentes
 
 Metadados, funções de carregamento (loaders), funções de servidor: em qualquer ponto fora da árvore do React.
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { setupI18n } from "@lingui/core";
@@ -324,7 +361,8 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 
 Gera-se uma nova instância `I18n` por execução, faz-se a importação manual do catálogo específico e emprega-se `msg` + `i18n._()` em vez de `t`. Conforme registrado nas [notas do benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md), saber a hora exata de recorrer a `t`, `` t` ` ``, `i18n.t()`, `msg` ou `<Trans>` é reconhecidamente confuso.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { getIntlayer } from "intlayer";
@@ -336,6 +374,9 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Mantenha as macros do Lingui, adote dicionários do Intlayer
 
 O `@intlayer/lingui` atua como um adaptador compatível para `@lingui/core` e `@lingui/react`. As macros continuam compilando normalmente; as chamadas resultantes para `i18n._()` passam a ser atendidas pelos dicionários do Intlayer, enquanto os plugins de sincronização `.po` sustentam seus catálogos originais como fonte da verdade. Plurais e condicionais ICU comportam-se com paridade absoluta.
@@ -353,16 +394,82 @@ Mantenha `@lingui/babel-plugin-lingui-macro` ou `@lingui/swc-plugin` no processo
 
 ## Qual ferramenta escolher?
 
-- **Escolha o Lingui** se você precisa do formato **ICU MessageFormat** com macros tipadas, seus tradutores trabalham em arquivos **`.po`** acoplados a sistemas TMS consolidados, sua equipe tem preferência por strings declaradas inline no JSX e domina o ciclo operacional de extração, compilação e divisão de catálogos. Seu peso em JavaScript por página é muito competitivo com lazy loading.
-- **Escolha o Intlayer** se você busca **conteúdo encapsulado por componente**, **TypeScript rigoroso**, **erros de compilação para chaves ausentes**, **tree-shaking e lazy loading automatizados sem esforço de configuração**, componentes leves, hidratação instantânea, alternância imediata de idiomas e suíte editorial nativa (Editor Visual, CMS, tradução por IA, servidor MCP). Uma escolha natural para aplicações modulares e design systems.
-- **Escolha o `@intlayer/lingui`** se você já opera sobre uma base de código em Lingui e quer evoluir para o modelo de dicionários do Intlayer de modo gradativo sem mexer nas macros.
+<AccordionGroup>
+<Accordion header="Escolha o Lingui">
+
+Você quer **ICU MessageFormat** com macros tipadas, seus tradutores trabalham em **`.po`** com um pipeline TMS existente, prefere strings de origem inline em JSX e sua equipe gerencia confortavelmente o fluxo de extração / compilação / divisão de catálogos. Seu JS por página é competitivo uma vez configurado o lazy loading.
+
+</Accordion>
+<Accordion header="Escolha o Intlayer">
+
+Você quer **conteúdo com escopo por componente**, **TypeScript rigoroso**, **erros de chaves ausentes em tempo de build**, **tree-shaking e lazy loading sem esforço**, componentes leves, hidratação rápida, troca instantânea de idioma 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 grandes e sistemas de design.
+
+</Accordion>
+<Accordion header="Escolha o @intlayer/lingui">
+
+Você já está no Lingui e quer migrar para os dicionários Intlayer gradualmente sem tocar nas macros. Seus catálogos `.po` permanecem a fonte da verdade através do [plugin de sincronização PO](https://intlayer.org/pt/doc/compatibility/lingui). Medido lado a lado em [Lingui vs @intlayer/lingui](https://intlayer.org/pt/blog/lingui-vs-intlayer-lingui).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="O Lingui também compila. Por que o resultado é tão diferente?">
+
+Porque a unidade de compilação difere. O Lingui compila **um catálogo por idioma**: tudo abaixo disso (catálogos por rota, lazy loading, exclusão do fallback do bundle) depende de configuração. O Intlayer compila **um dicionário por componente**, de modo que a divisão por rotas é resultado direto do build. É por isso que um componente Lingui compilado isoladamente pesa 58-153 KB contra 6-8 KB no Intlayer.
+
+</Question>
+
+<Question title="Por que o vazamento de idioma nunca chega a 0% com o Lingui?">
+
+As macros mantêm a mensagem de origem disponível como fallback em tempo de execução, então a string em inglês é enviada junto com a tradução. O benchmark mede **3-15% de strings `en` dentro de páginas `fr`** em cada configuração otimizada. O Intlayer resolve fallbacks no build e envia apenas o idioma ativo.
+
+</Question>
+
+<Question title="O JavaScript por página do Lingui é realmente competitivo?">
+
+Sim, e no TanStack Start vence por muito pouco: 115.2 KB no modo `dynamic` contra 118.6 KB do Intlayer. Catálogos compilados com IDs hasheados são compactos. O custo aparece em outros pontos: hidratação em 28-34 ms contra 11-14 ms, e uma troca de idioma de **42 ms** na configuração `scoped-dynamic`.
+
+</Question>
+
+<Question title="Preciso abrir mão das macros para migrar?">
+
+Não. O `@intlayer/lingui` mantém a compilação de `` t`...` ``, `<Trans>`, `msg`, `plural`, `select` e `selectOrdinal` como antes; apenas a resolução de `i18n._()` muda. Mantenha `@lingui/babel-plugin-lingui-macro` ou `@lingui/swc-plugin` no build. Veja a [documentação de compatibilidade do Lingui](https://intlayer.org/pt/doc/compatibility/lingui).
+
+</Question>
+
+<Question title="E quanto às etapas de extração e compilação?">
+
+Elas continuam para as macros e desaparecem para o conteúdo nativo do Intlayer. Dicionários `.content.ts` são gerados na execução do bundler, sem etapa separada de CLI, e [`intlayer test`](https://intlayer.org/pt/doc/concept/cli) falha no CI em caso de chave ausente em vez de usar silenciosamente a string de origem.
+
+</Question>
+
+</FAQ>
 
 ## Comparações correlatas
 
-- [next-intl vs Intlayer](https://intlayer.org/pt/blog/next-intl-vs-intlayer) (sob o mesmo benchmark)
-- [i18next vs Intlayer](https://intlayer.org/pt/blog/i18next-vs-intlayer) (sob o mesmo benchmark)
-- [vue-i18n vs Intlayer](https://intlayer.org/pt/blog/vue-i18n-vs-intlayer-benchmark) (sob o mesmo benchmark)
-- [Compilador vs i18n declarativo](https://intlayer.org/pt/blog/compiler-vs-declarative-i18n)
+Mesmo benchmark, outras bibliotecas:
+
+- [next-intl vs Intlayer](https://intlayer.org/pt/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/pt/blog/i18next-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)
+
+Indo além:
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/pt/blog/lingui-vs-intlayer-lingui), o adaptador medido na mesma aplicação
+- [Compiler-driven vs declarative i18n](https://intlayer.org/pt/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/pt/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/pt/blog/icu-message-format)
+
+Documentação 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)
+- [Compat adapter: Lingui](https://intlayer.org/pt/doc/compatibility/lingui)
+- [Otimização de bundle](https://intlayer.org/pt/doc/concept/bundle-optimization) e [o compilador Intlayer](https://intlayer.org/pt/doc/compiler)
 
 ## Estrelas no GitHub