@intlayer/docs 9.5.2 → 9.5.3

package/blog/pl/vue-i18n_vs_intlayer-vue-i18n.md

@@ -0,0 +1,289 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n vs @intlayer/vue-i18n: Ten sam API, Inny Bundle"
+description: Co się zmienia, gdy aplikacja Vue 3 zachowuje swoje wywołania vue-i18n, ale obsługuje je za pośrednictwem adaptera kompatybilności @intlayer/vue-i18n. JavaScript na stronę, rozmiar runtime, rozmiar komponentu i wyciek zmierzony na tym samym kodzie Vite + Vue, plus to, co adapter zachowuje, ignoruje i nie może zastąpić.
+keywords:
+  - vue-i18n
+  - "@intlayer/vue-i18n"
+  - Intlayer
+  - Compat adapter
+  - Migration
+  - Internationalization
+  - i18n
+  - Benchmark
+  - Bundle size
+  - Blog
+  - Vue
+  - Nuxt
+  - Vite
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer-vue-i18n
+author: aymericzip
+---
+
+# vue-i18n VS @intlayer/vue-i18n | Ten sam API, Inny Bundle
+
+`@intlayer/vue-i18n` to adapter kompatybilności: ujawnia API `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) i serwuje go ze słowników skompilowanych przez Intlayer. Twoje pliki `.vue` się nie zmieniają. Zmienia się to, do czego `t("footer.github")` jest związane.
+
+Artykuł ten mierzy tę wymianę na tej samej aplikacji Vite + Vue 3, zbudowanej raz z `vue-i18n` i raz z adapterem. Liczby pochodzą z [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Aby porównać `vue-i18n` i Intlayer jako biblioteki, przeczytaj [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) i [porównanie wydajności vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Ten artykuł dotyczy tego, co adapter zmienia, gdy zachowujesz swoje komponenty takie, jakie są.
+
+<TOC/>
+
+> **tl;dr**: Na tej samej aplikacji Vite + Vue 3, zastąpienie `vue-i18n` przez `@intlayer/vue-i18n` zmniejszyło JavaScript na stronę z **134.9 KB na 47.0 KB** gzip (aplikacja bez i18n waży 41.3 KB), runtime z **24.3 KB na 7.9 KB**, średni komponent z **196 KB na 8.4 KB**, i wyciek stringów z obcych stron z **90% na 0%**, bez edycji któregokolwiek pliku `.vue`. `createI18n({ messages })` pozostaje funkcjonalne jako fallback; usuń importy JSON, aby uzyskać wymienione wyżej liczby. Bloki SFC `<i18n>` i runtime `setLocaleMessage()` to dwie funkcje, które się nie przenoszą.
+
+## Co to jest `@intlayer/vue-i18n`
+
+`vue-i18n` to runtime. `createI18n({ messages: { en, fr, ... } })` buduje globalną instancję zawierającą każdą wiadomość każdej lokalizacji; `useI18n()` wiąże każdy komponent z nią; `t("footer.github")` przechodzi po drzewie w czasie renderowania. Ten projekt sprawia, że bloki SFC `<i18n>` i `setLocaleMessage()` są możliwe, i jest to również powód, dla którego graf zależności każdego komponentu obejmuje całe drzewo.
+
+`@intlayer/vue-i18n` zachowuje API i zastępuje drzewo:
+
+1. **Import aliasing.** `vueI18nVitePlugin()` z `@intlayer/vue-i18n/plugin` opakowuje `vite-intlayer` i dodaje `resolve.alias`, aby `vue-i18n` rozwiązywał się do `@intlayer/vue-i18n`. Żaden import nie jest zmieniam.
+2. **JSON jako źródło prawdy.** Plugin `syncJSON` odczytuje istniejący plik `locales/{locale}.json` z `format: "vue-i18n"` (dzięki czemu `{name}`, `{0}` interpolacja listy i `"car | cars"` plurale z pipe są prawidłowo parsowane) i zapisuje tłumaczenia z powrotem, gdy CLI lub CMS je aktualizuje.
+3. **Call-site binding.** Passe optymalizacji Intlayer przepisuje miejsca wywołania `useI18n()` tak, aby komponent otrzymywał słowniki dla swoich kluczy w aktywnym ustawieniu regionalnym, jako imporyt, które bundler może śledzić i dzielić.
+
+```vue fileName="src/components/Footer.vue"
+<!-- Twój kod, bez zmian -->
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <a href="https://github.com/intlayer-org/benchmark-bloom">{{
+    t("footer.github")
+  }}</a>
+</template>
+```
+
+```ts fileName="Co emituje kompilator (uproszczone)"
+import _dicHash_footer from "../.intlayer/dictionaries/footer.mjs";
+import { useDictionary as useI18n } from "@intlayer/vue-i18n";
+
+// Komponent nie ma już dostępu do globalnego drzewa wiadomości. Dotyka tylko `footer`.
+const { t } = useI18n(_dicHash_footer);
+```
+
+Komponent nie ma już dostępu do globalnego drzewa wiadomości. Dotyka tylko `footer`. Dlatego kolumna rozmiaru komponentu poniżej spada z 196 KB do 8 KB.
+
+## Co adapter zachowuje, ignoruje i nie zastępuje
+
+| API `vue-i18n`                                                      | Z `@intlayer/vue-i18n`                                                                                               |
+| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
+| `useI18n()` → `{ t, d, n, te, tm, rt, locale, availableLocales }`   | ✅ Zachowane. Klucze `t` są typowane względem Twoich słowników                                                       |
+| `t("key", { name })`, `t("key", [a, b])`, `t("key", count)`         | ✅ Zachowane. `{name}`, `{0}` i plurale rozdzielone znakiem pipe rozpoznawane jak poprzednio                         |
+| `d(date, "long")`, `n(value, "currency")`                           | ✅ Zachowane. `datetimeFormats` / `numberFormats` z `createI18n()` są honorowane, wspierane przez natywny `Intl`     |
+| `i18n.global.locale.value = "fr"`                                   | ✅ Zachowane. Pisana `WritableComputedRef` wspierana przez klienta Intlayer; reaktywność zachowuje się jak wcześniej |
+| `$t`, `$tc`, `$te`, `$tm`, `$rt`, `$d`, `$n`, `$i18n` (Options API) | ✅ Zachowane. Zarejestrowane na `app.config.globalProperties` przez `app.use(i18n)`                                  |
+| `v-t` directive                                                     | ✅ Zachowane                                                                                                         |
+| `legacy: true`                                                      | ✅ Akceptowane                                                                                                       |
+| `createI18n({ messages })`                                          | ⚠️ `messages` są używane jako **fallback w runtime** z ostrzeżeniem dev. Usuń importy JSON dla zmniejszenia bundla   |
+| `setLocaleMessage()`, `mergeLocaleMessage()`                        | ❌ Ostrzeżenie i nic się nie dzieje. Ładowanie wiadomości w runtime jest zastępowane słownikami w czasie budowania   |
+| SFC `<i18n>` custom blocks                                          | ❌ Nie są czytane. Przenieś te wiadomości do lokalizacyjnego JSON-a (lub `.content.ts` obok komponentu)              |
+| `@nuxtjs/i18n`                                                      | ⚠️ Osobny adapter, zobacz [dokumentację kompatybilności Nuxt](https://intlayer.org/doc/compatibility/nuxtjs-i18n)    |
+
+## Benchmark
+
+### Co zostało zmierzone
+
+Zestawienie [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) buduje **tę samą aplikację Vite + Vue 3** z każdą konfiguracją: **10 stron** (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), **10 lokalizacji** (`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`), identyczne komponenty i identyczną treść. Strony są mierzone w `en` i `fr`.
+
+Oba zostały zbudowane w konfiguracji **static**, takiej jaką wysyła większość projektów Vue: dla `vue-i18n`, każdy JSON lokalizacji importowany i przekazywany do `createI18n({ messages })`; dla adaptera, te same komponenty z zmienionymi `vite.config.ts` i `intlayer.config.ts` oraz usuniętym importem `messages`. Native `vue-intlayer` jest zawarty jako punkt odniesienia.
+
+Dla każdego buildu, zestaw rejestruje:
+
+- **Lib size**: rozmiar gzip (i zminifikowany) pustego komponentu, który tylko importuje bibliotekę i18n.
+- **Page JS**: gzip JavaScript pobrany na stronę, uśredniony dla wszystkich stron i locales.
+- **Locale leak %**: udział przetłumaczonych stringów w pobranym JS, które należą do locale'u, którego użytkownik **nie** przegląda.
+- **Page leak %**: udział przetłumaczonych stringów w pobranym JS, które należą do strony, na której użytkownik **nie** jest.
+- **Component avg**: średni rozmiar gzip każdego komponentu skompilowanego w izolacji.
+- **E2E reactivity**: czas ścienno-zegarowy między wybraniem nowego locale a aktualizacją `html[lang]` w DOM (Playwright, 5 iteracji).
+- **Page load**: `PerformanceNavigationTiming.duration`.
+
+> Liczby poniżej pochodzą z uruchomienia z dnia **2026-09-12** przy użyciu `vue-i18n` 11.4.0 i `@intlayer/vue-i18n` 9.5.1. Aplikacja testowa jest celowo mała (kilkadziesiąt stringów na locale), więc procenty wycieków opisują **wzorzec**: rosną wraz z Twoją zawartością, podczas gdy koszt runtime pozostaje stały.
+
+### Wyniki na Vite + Vue 3
+
+| Setup                    | Strategy | Rozmiar lib (gz) | Rozmiar lib (min) | Średni JS strony (gz) | Wyciek locale | Wyciek strony | Średnia lib komponentu (gz) | Reaktywność E2E | Ładowanie strony |
+| ------------------------ | -------- | ---------------: | ----------------: | --------------------: | ------------: | ------------: | --------------------------: | --------------: | ---------------: |
+| **base** (brak i18n)     | -        |           0.0 KB |            0.0 KB |               41.3 KB |          0.0% |             - |                      1.1 KB |          1.8 ms |          10.8 ms |
+| `vue-i18n`               | static   |          24.3 KB |           83.2 KB |              134.9 KB |         50.0% |         90.0% |                    196.0 KB |          2.8 ms |          13.6 ms |
+| **`@intlayer/vue-i18n`** | static   |       **7.9 KB** |       **23.2 KB** |           **47.0 KB** |     **15.0%** |      **0.0%** |                  **8.4 KB** |      **1.5 ms** |       **9.3 ms** |
+| `vue-intlayer` (native)  | static   |           3.9 KB |           11.1 KB |               57.1 KB |         56.8% |          0.0% |                      7.7 KB |          4.5 ms |          13.8 ms |
+| `vue-intlayer` (native)  | dynamic  |           3.9 KB |           11.1 KB |               59.8 KB |         50.0% |          0.0% |                      6.5 KB |          4.0 ms |          15.8 ms |
+
+> Kolumna page-leak aplikacji bazowej jest pusta: bez biblioteki i18n fingerprinting wybiera zakodowane na stałe ciągi w udostępnianych fragmentach i liczba nie jest znacząca.
+
+**Jak to czytać**
+
+- **88 KB mniej na stronę, te same komponenty.** `vue-i18n` bierze aplikację 41.3 KB do **134.9 KB**. Build adaptera z tymi samymi komponentami ląduje na **47.0 KB**, 5.7 KB powyżej aplikacji bazowej. Większość różnicy to 74.9 KB `src/locales`, które `createI18n({ messages })` ściąga na każdą stronę, a adapter nigdy nie bundluje jako blok.
+- **Runtime zmniejsza się 3x.** Pusty komponent, który importuje tylko `vue-i18n`, kosztuje **24.3 KB gzip / 83.2 KB minified**: `@intlify/core-base`, compiler wiadomości i runtime. Adapter kosztuje **7.9 KB / 23.2 KB**, większość z tego to core Intlayera plus powierzchnia API `vue-i18n`.
+- **Komponenty: 23x mniejsze.** Komponent `useI18n()` skompilowany w izolacji średnio ważyć **196 KB**, ponieważ `t` jest powiązany z instancją, która przechowuje każdą wiadomość każdej lokalizacji. Z adapterem ten sam komponent ważyć średnio **8.4 KB**: osiąga własny słownik.
+- **Wyciek danych.** `vue-i18n` wysyła każdą locale i stringi każdej strony na każdej stronie: 50% wyciek locale (na dwóch identyfikowanych locale; z dziesięcioma bundlowanymi locale rzeczywiste marnotrawstwo jest wyższe), 90% wyciek strony. Adapter zmniejsza wyciek strony do **0%**, ponieważ każdy komponent importuje tylko swoje słowniki. Wyciek locale wynosi 15% w tym przebiegu `static`; `importMode: 'dynamic'` to ustawienie, które go usuwa, a ta konfiguracja nie była częścią tego przebiegu Vue.
+- **Reaktywność i ładowanie strony.** Przełączanie locale jest tanie dla obu (1,5-2,8 ms); system reaktywności Vue sprawia, że tak jest, gdy wiadomości są w pamięci. Ładowanie strony zmienia się z 13,6 ms na **9,3 ms**, zgodnie z 88 KB mniej JavaScriptu do analizy.
+- **O natywnych wierszach.** `vue-intlayer` w tym uruchomieniu zawierał każdą lokalizację w trybie `static` i osiągnął 57,1 KB z runtimem 3,9 KB; zsynchronizowane słowniki adaptera zawierały mniej ciągów obcych lokalizacji, stąd niższa liczba na stronę. Natywny runtime pozostaje najlżejszy z trzech, a jego model `.content.ts` to miejsce, gdzie bloki SFC `<i18n>` znajdują swój odpowiednik.
+
+## Dlaczego liczby się zmieniają
+
+Nic w `src/components/` się nie zmieniło, więc zyski pochodzą z tego, do czego wiąże się `useI18n`.
+
+**Za pomocą `vue-i18n`**, binding to instancja globalna. `createI18n({ messages: { en, fr, ... } })` to jeden import, który zawiera wszystko; każdy komponent, który wywołuje `useI18n()`, może uzyskać dostęp do całości, dlatego bundler nie może podzielić się poniżej instancji. Optymalizacja oznacza, że _ty_ dzielisz `en.json` po trasach, wywołujesz `setLocaleMessage()` w routerze guard, i utrzymujesz mapę trasy do pliku w miarę przenoszenia się komponentów.
+
+```bash
+.
+├── locales
+│   ├── en.json                    # ciągi znaków każdej strony
+│   └── fr.json
+└── src
+    ├── i18n.ts                    # createI18n({ messages: { en, fr, ... } })
+    ├── main.ts                    # app.use(i18n)
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")
+```
+
+**Z `@intlayer/vue-i18n`**, binding to słownik. `syncJSON` zamienia każdy klucz najwyższego poziomu w `en.json` na słownik; przebieg optymalizacji przekazuje komponentowi te, których klucze nosi, jako importy, które bundler śledzi i dzieli na stronę.
+
+```bash
+.
+├── intlayer.config.ts             # syncJSON({ format: "vue-i18n", source: ... })
+├── locales
+│   ├── en.json                    # unchanged, still the source of truth
+│   └── fr.json
+├── .intlayer/                     # generated: one dictionary per top-level key, per locale
+└── src
+    ├── i18n.ts                    # createI18n({})   ← messages import removed
+    ├── main.ts                    # app.use(i18n)    ← unchanged
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")  ← unchanged
+```
+
+Import `messages` w `i18n.ts` to jest jedyna linia do usunięcia. To daje 88 KB.
+
+## Migracja w trzech krokach
+
+<Steps>
+<Step number={1} title="Instalacja">
+
+```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
+```
+
+Polecenie wykrywa `vue-i18n`, instaluje `intlayer`, `vue-intlayer`, `@intlayer/vue-i18n` i `@intlayer/sync-json-plugin`, oraz wstępnie wypełnia `intlayer.config.ts`. Zachowaj `vue-i18n` zainstalowany: jest to peer dependency i dostarcza typy.
+
+</Step>
+<Step number={2} title="Wskaż Intlayer na pliki lokalizacyjne">
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    // "static" łączy każdą locale; "dynamic" ładuje aktywną na żądanie
+    importMode: "dynamic",
+    format: "vue-i18n",
+  },
+  plugins: [
+    syncJSON({
+      // dialekt vue-i18n: {name}, {0}, "car | cars"
+      format: "vue-i18n",
+      source: ({ locale }) => `./locales/${locale}.json`,
+      location: "locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+`locales/{locale}.json` pozostaje w swoim miejscu. Każdy klucz na najwyższym poziomie (`footer`, `hero`...) staje się słownikiem.
+
+</Step>
+<Step number={3} title="Dodaj plugin i usuń import wiadomości">
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import vue from "@vitejs/plugin-vue";
+import { vueI18nVitePlugin } from "@intlayer/vue-i18n/plugin";
+
+export default defineConfig({
+  plugins: [vue(), vueI18nVitePlugin()],
+});
+```
+
+```ts fileName="src/i18n.ts"
+import { createI18n } from "vue-i18n";
+
+// Przed: createI18n({ locale: "en", messages: { en, fr, es } })
+export const i18n = createI18n({ locale: "en" });
+```
+
+`vueI18nVitePlugin()` opakowuje `vite-intlayer` (obserwacja zawartości, kompilacja słownika, przebieg optymalizacji) i aliasuje `vue-i18n` do adaptera. Usunięcie importu `messages` to to, co zmniejsza 88 KB; pozostawienie go sprawia, że aplikacja działa, ale wysyła oba.
+
+</Step>
+</Steps>
+
+### Co można usunąć później
+
+| Plik / wzorzec                                 | Powód                                                                                |
+| ---------------------------------------------- | ------------------------------------------------------------------------------------ |
+| `import en from "./locales/en.json"` i podobne | Używane tylko jako fallback przez adapter. To jest miejsce, gdzie były 88 KB         |
+| `setLocaleMessage()` w guardach routera        | No-op. Ładowanie per-route to teraz zadanie kompilatora                              |
+| `@intlify/unplugin-vue-i18n`                   | Niepotrzebne: prekompiluje wiadomości i bloki SFC, których adapter nie czyta         |
+| Bloki SFC `<i18n>`                             | Nie są odczytywane; przenieś je do JSON-a locale'a lub do `.content.ts` na komponent |
+
+### Co zyskujesz poza zmniejszeniem rozmiaru
+
+- **Wpisane klucze.** `t("footer.github")` jest wpisany względem skompilowanego słownika `footer`; błędna ścieżka to błąd TypeScript zamiast klucza renderowanego jako tekst.
+- **`npx intlayer test`** powoduje niepowodzenie CI na brakującym kluczu w dowolnym locale'u. **`npx intlayer fill`** tłumaczy brakujące za pomocą twojego klucza providera (OpenAI, Anthropic, Mistral, Gemini...) i zapisuje je z powrotem do `locales/{locale}.json`.
+- **Edytor wizualny i CMS** działają na tym samym JSON-ie, więc osoby niebędące programistami edytują przez interfejs użytkownika, a pliki są aktualizowane.
+- **Stopniowe przejście do `.content.ts`.** Każdy komponent może przejść z `useI18n()` na `useIntlayer("footer")` ze współlokalizowanym plikiem content. Słowniki JSON i `.content.ts` współistnieją i się łączą.
+
+## Limity, które warto znać przed rozpoczęciem
+
+- **Bloki `<i18n>` SFC nie są czytane.** Jeśli Twoje wiadomości znajdują się wewnątrz komponentów, muszą przejść do plików locale (lub do `.content.ts`, co jest tym samym pomysłem z typami).
+- **Dynamiczne ładowanie wiadomości nie istnieje.** `setLocaleMessage()` i `mergeLocaleMessage()` ostrzegają i zwracają. Tłumaczenia pobrane z CMS w czasie rzeczywistym wymagają CMS-u Intlayer lub poleceń `intlayer pull` / `push`.
+- **`messages` to fallback, nie darmowy.** Utrzymywanie importów JSON w `createI18n()` utrzymuje 75 KB w bundle. Usuń je, gdy `intlayer test` przejdzie pomyślnie.
+- **Adapter nie jest natywnym runtimem.** 7,9 KB wobec 3,9 KB dla `vue-intlayer`. Gdy każdy komponent przejdzie na `useIntlayer`, możesz go usunąć.
+
+## Kiedy użyć którego?
+
+- **Pozostań na `vue-i18n`** jeśli Twoja aplikacja zależy od bloków SFC `<i18n>`, od przepływów runtime `setLocaleMessage()`, lub jeśli 90 KB na stronę nie stanowi problemu dla Twojej audience.
+- **Używaj `@intlayer/vue-i18n`** jeśli jesteś na `vue-i18n` i chcesz zaoszczędzić 88 KB, mieć komponenty 23x mniejsze, 0% wycieku strony, typed keys i CI checks bez edytowania pliku `.vue`. To jest punkt wejścia dla istniejącej codebase `vue-i18n`.
+- **Idź natywnie (`vue-intlayer`)** dla nowych projektów, lub gdy adapter wykonał swoje zadanie. Ma najlżejszy runtime (3,9 KB) i model per-component `.content.ts`, który zastępuje bloki `<i18n>` typed content.
+
+## Powiązane porównania
+
+- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (funkcje i DX)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (biblioteki, ten sam benchmark)
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (ta sama seria adapterów)
+- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (ta sama seria adapterów)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (ta sama seria adapterów)
+- [Przewodnik migracji: vue-i18n do Intlayer](https://intlayer.org/doc/migration/vue-i18n)
+- [Compat adapter reference: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+
+## Podsumowanie
+
+`@intlayer/vue-i18n` zmienia to, do czego `useI18n()` jest powiązane: z globalnej instancji zawierającej każdą wiadomość każdej lokalizacji na słownik skompilowany dla tego komponentu. W tej samej aplikacji Vite + Vue 3, która jest **88 KB mniejsza na stronę**, **3x mniejszy runtime**, **23x mniejsze komponenty** i **0% wycieków strony**, dla pliku konfiguracyjnego, linii pluginu i jednego usuniętego importu. Bloki SFC `<i18n>` i ładowanie wiadomości w runtime to dwie rzeczy, które nie są obsługiwane, a natywny runtime `vue-intlayer` pozostaje o połowę mniejszy.
+
+Wszystkie surowe dane, aplikacje testowe i skrypty znajdują się w [repozytorium Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Uruchom je sam.
+
+Więcej szczegółów znajdziesz w dokumentacji ['Why Intlayer?'](https://intlayer.org/doc/why).

package/blog/pl/vue-i18n_vs_intlayer.md

@@ -235,7 +235,7 @@ Korzystając z `intlayer`, możesz zadeklarować swoją zawartość w formacie u
 
 Gwiazdy na GitHubie są silnym wskaźnikiem popularności projektu, zaufania społeczności oraz jego długoterminowej istotności. Choć nie są bezpośrednim miernikiem jakości technicznej, odzwierciedlają, ilu deweloperów uważa projekt za użyteczny, śledzi jego rozwój i jest skłonnych go przyjąć. Przy szacowaniu wartości projektu, gwiazdy pomagają porównać zainteresowanie różnymi alternatywami oraz dostarczają wglądu w rozwój ekosystemu.
 
-[![Wykres historii gwiazd](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://www.star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
+[![Wykres historii gwiazd](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
 ## Podsumowanie
 

package/blog/pt/i18next_vs_intlayer-i18next.md

@@ -0,0 +1,327 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "i18next vs @intlayer/i18next: Mesma API, Outro Bundle"
+description: O que muda quando uma aplicação React ou Next.js mantém suas chamadas de i18next, react-i18next e next-i18next mas as executa através dos adaptadores @intlayer/i18next. JavaScript por página, tamanho de componentes, vazamento de conteúdo e hidratação medidos no mesmo código, além do que os adaptadores mantêm, ignoram e não substituem.
+keywords:
+  - i18next
+  - react-i18next
+  - next-i18next
+  - "@intlayer/i18next"
+  - "@intlayer/react-i18next"
+  - "@intlayer/next-i18next"
+  - Intlayer
+  - Adaptador de compatibilidade
+  - Migração
+  - Internacionalização
+  - i18n
+  - Benchmark
+  - Tamanho de bundle
+  - Blog
+  - Next.js
+  - React
+slugs:
+  - blog
+  - i18next-vs-intlayer-i18next
+author: aymericzip
+---
+
+# i18next VS @intlayer/i18next | Mesma API, Outro Bundle
+
+`@intlayer/i18next`, `@intlayer/react-i18next` e `@intlayer/next-i18next` são adaptadores de compatibilidade. Eles expõem a API do `i18next` que seu código já utiliza (`useTranslation`, `t()`, `<Trans>`, `i18n.changeLanguage()`, `getFixedT`, `serverSideTranslations`...) e a fornecem a partir de dicionários compilados pelo Intlayer. Os componentes não mudam. O runtime abaixo deles sim.
+
+Este artigo analisa essa substituição na mesma aplicação Next.js, construída uma vez com `next-i18next` e outra com `@intlayer/next-i18next`. Os dados são do [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Para comparar `i18next` e Intlayer como bibliotecas completas, leia [i18next vs Intlayer](https://intlayer.org/pt/blog/i18next-vs-intlayer). Este artigo se concentra no que o adaptador transforma quando você preserva seu código como está.
+
+<TOC/>
+
+> **tl;dr**: Na mesma aplicação Next.js, substituir `next-i18next` por `@intlayer/next-i18next` reduziu o JavaScript por página de **218.5 KB para 150.7 KB** gzip (setup básico) e superou o setup do `next-i18next` totalmente otimizado (163.4 KB) em **12.7 KB**. O componente médio caiu de **78.5 KB para 9.7 KB**, o vazamento de strings para outras páginas foi de **~90% para 0%**, a hidratação de **15.6 ms para 11.3 ms** e o runtime de **19.7 KB para 9.4 KB**. Nenhum componente foi editado; apenas um arquivo de provider foi ajustado. Plugins do `i18next` (backends, detectores de idioma) são aceitos mas não realizam nada: não há mais nada para carregar ou detectar em tempo de execução.
+
+## O que é o `@intlayer/i18next`
+
+O `i18next` é um runtime. `i18n.init({ resources })` ou um plugin de backend carrega `locales/{lng}/{ns}.json` em uma instância global; `useTranslation("about")` inscreve o componente nela; `t("title")` busca a chave no momento da renderização. Namespaces, carregamento sob demanda (lazy loading), listas de namespaces por página e segurança de tipos ficam sob sua responsabilidade de configuração e manutenção.
+
+Os adaptadores preservam a API e substituem a instância:
+
+1. **Aliases de importação.** `createNextI18nPlugin()` do `@intlayer/next-i18next/plugin` (ou `withI18next`) envolve o `withIntlayer` e cria aliases no Webpack / Turbopack para que `next-i18next`, `react-i18next` e `i18next` resolvam para os pacotes `@intlayer/*`. No Vite, o `reactI18nextVitePlugin()` do `@intlayer/react-i18next/plugin` tem o mesmo papel. Nenhuma importação precisa ser renomeada.
+2. **JSON como fonte de verdade.** O plugin `syncJSON` lê seus arquivos existentes `locales/{lng}/{ns}.json` com `format: "i18next"` (garantindo que `{{name}}`, aninhamento `$t()`, `_one` / `_other` e sufixos de contexto sejam interpretados adequadamente) e regrava as traduções quando a CLI ou o CMS as atualizam.
+3. **Vinculação no ponto de chamada.** A etapa de otimização do Intlayer reescreve `useTranslation("about")` em uma chamada que recebe o dicionário `about` diretamente, no idioma ativo. O componente deixa de acessar a store global.
+
+```tsx fileName="components/About.tsx"
+// Seu código, inalterado
+import { useTranslation } from "react-i18next";
+
+const About = () => {
+  const { t } = useTranslation("about");
+  return <h1>{t("title")}</h1>;
+};
+```
+
+```tsx fileName="O que o compilador emite (simplificado)"
+import _dicHash_about from "../.intlayer/dictionaries/about.mjs";
+import { useDictionary as useTranslation } from "@intlayer/react-i18next";
+
+const About = () => {
+  const { t } = useTranslation(_dicHash_about);
+  return <h1>{t("title")}</h1>;
+};
+```
+
+Essa transformação é a razão pela qual as colunas de tamanho de componente e vazamento de página caem drasticamente nos dados abaixo.
+
+## O que os adaptadores mantêm, ignoram e não substituem
+
+| API do `i18next`                                                                | Com `@intlayer/*`                                                                                                     |
+| ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| `useTranslation("ns")`, `useTranslation("ns", { keyPrefix })`                   | ✅ Mantido. Vinculado ao dicionário `ns` em tempo de compilação; tipado com seu conteúdo                              |
+| `t("key", { name })`, `{{interpolation}}`, aninhamento `$t(key)`                | ✅ Mantido                                                                                                            |
+| Plurais `key_one` / `key_other`, contexto `key_male`, `returnObjects`           | ✅ Mantido. Plurais calculados com `Intl.PluralRules`                                                                 |
+| `<Trans>` com `components`, tags numeradas `<1>...</1>`, `values`               | ✅ Mantido                                                                                                            |
+| `withTranslation`, `Translation`, `I18nContext`                                 | ✅ Mantido                                                                                                            |
+| `i18n.changeLanguage()`, `i18n.language`, `i18n.dir()`, `on("languageChanged")` | ✅ Mantido. `changeLanguage` controla o idioma do Intlayer                                                            |
+| `getFixedT(lng, ns, keyPrefix)`, `i18n.exists()`, `hasLoadedNamespace()`        | ✅ Mantido                                                                                                            |
+| `i18n.use(Backend).use(LanguageDetector).init({...})`                           | ⚠️ `use()` executa o `init` do plugin e encerra; backends e detectores não têm nada para carregar ou detectar         |
+| `init({ resources })`, `addResourceBundle()`                                    | ⚠️ `resources` é **ignorado** com alerta de desenvolvimento; remova imports de JSON para obter ganhos reais de bundle |
+| `I18nextProvider i18n={i18n}`                                                   | ⚠️ Renderiza um `IntlayerProvider`; a prop `i18n` é ignorada. No App Router, passe o locale (veja abaixo)             |
+| `serverSideTranslations(locale, ["common"])` (next-i18next)                     | ⚠️ Retorna a estrutura esperada e não carrega nada. Seguro de manter, seguro de remover                               |
+| `appWithTranslation(App)` (next-i18next)                                        | ✅ Mantido                                                                                                            |
+| `next-i18next.config.js`                                                        | ⚠️ Não é lido. Os idiomas são configurados no `intlayer.config.ts`                                                    |
+| `useTranslation()` sem namespace                                                | ✅ Opera contra o dicionário geral `translation` do arquivo inteiro (`splitKeys: false`)                              |
+
+## O benchmark
+
+### O que foi medido
+
+A suite [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) compila **a mesma aplicação** em cada ambiente: **10 páginas** (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), **10 locales** (`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`), componentes idênticos e conteúdo idêntico. As páginas são avaliadas em `en` e `fr`.
+
+O `next-i18next` foi configurado em quatro estratégias de carregamento, desde o JSON de cada idioma importado em `resources` (`static`) até um namespace por rota, carregado de forma diferida via backend (`scoped-dynamic`). O adaptador foi testado sobre **os mesmos componentes do setup inicial**, com alterações limitadas a `next.config.ts`, `intlayer.config.ts` e ao arquivo do provider. Ele não possui variante "scoped" manual: o compilador define o escopo do conteúdo por componente.
+
+Para cada compilação, registram-se:
+
+- **Tamanho da lib**: tamanho gzip de um componente vazio que apenas importa a biblioteca de i18n.
+- **JS por página**: média de JavaScript gzip transferido por página em todas as rotas e locales.
+- **% de vazamento de locale**: parcela de strings traduzidas no JS que pertence a um idioma que o usuário **não** está visualizando.
+- **% de vazamento de página**: parcela de strings traduzidas no JS que pertence a uma página em que o usuário **não** está navegando.
+- **Média por componente**: tamanho médio gzip de cada componente compilado de forma isolada.
+- **Reatividade E2E**: intervalo de tempo real entre selecionar um novo idioma e a alteração de `html[lang]` no DOM (Playwright, 5 repetições).
+- **Hidratação**: tempo de duração da fase de hidratação do React.
+
+> Os dados abaixo resultam da execução de **12/09/2026** com `next-i18next` 16.3.0 (`react-i18next` 17.0.13, `i18next` 26.4.2) e `@intlayer/next-i18next` 9.5.1. A aplicação de teste foi projetada com escopo enxuto propositalmente (algumas dezenas de strings por idioma), portanto os percentuais de vazamento ilustram um **comportamento**: expandem-se proporcionalmente ao crescimento do conteúdo enquanto o custo do runtime permanece estático.
+
+### Resultados no Next.js
+
+| Setup                        | Estratégia     | Tamanho lib (gz) | Média JS pág (gz) | Vazamento locale | Vazamento pág | Média comp (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 |
+| `next-i18next`               | static         |          19.7 KB |          218.5 KB |             0.0% |         89.8% |         78.5 KB |         16.4 ms |     15.6 ms |
+| `next-i18next`               | dynamic        |          19.7 KB |          169.5 KB |            50.0% |         89.8% |         26.1 KB |         15.4 ms |     27.7 ms |
+| `next-i18next`               | scoped-static  |          19.7 KB |          220.1 KB |             0.0% |         89.8% |         78.9 KB |         16.4 ms |     14.7 ms |
+| `next-i18next`               | scoped-dynamic |          19.7 KB |          163.4 KB |             0.0% |          0.0% |         27.1 KB |         15.9 ms |     15.1 ms |
+| **`@intlayer/next-i18next`** | static         |       **9.4 KB** |      **150.7 KB** |         **0.0%** |      **0.0%** |      **9.7 KB** |     **10.7 ms** | **11.3 ms** |
+| **`@intlayer/next-i18next`** | dynamic        |       **9.4 KB** |      **150.7 KB** |         **0.0%** |      **0.0%** |      **9.7 KB** |     **11.9 ms** | **10.6 ms** |
+| `next-intlayer` (nativo)     | static         |           5.5 KB |          141.3 KB |             0.0% |          0.0% |          8.5 KB |         15.5 ms |     16.9 ms |
+| `next-intlayer` (nativo)     | dynamic        |           5.5 KB |          141.3 KB |             0.0% |          0.0% |          6.9 KB |         15.3 ms |     15.9 ms |
+
+**Como interpretar os dados**
+
+- **68 KB a menos por página em relação ao setup básico.** `resources: { en, fr, ... }` despacha todos os idiomas e namespaces para cada rota: **218.5 KB**. O build com o adaptador cai para **150.7 KB**. Supera também a configuração mais elaborada do `next-i18next` (163.4 KB, namespace único por rota, carregado sob demanda) em 12.7 KB, pois a própria biblioteca `i18next` consome 19.7 KB contra 9.4 KB.
+- **O vazamento atinge 0% sem intervenção em componentes.** Cada configuração do `next-i18next`, à exceção da modularizada manualmente, entrega ~90% de strings de rotas distintas. A linha `dynamic` é pior na prática do que aparenta: preserva o vazamento entre páginas e adiciona **50% de vazamento de idioma**, dado que o backend busca todo o namespace `translation` do locale ativo. O adaptador estabelece 0% / 0% a partir do código original.
+- **Componentes: 8x mais enxutos.** Um componente com `useTranslation()` isolado consome **78.5 KB** com `resources` inlined e **26-27 KB** com backend, já que `t` continua preso à store global. No adaptador, a média cai para **9.7 KB**.
+- **Hidratação e alternância de idioma aceleradas.** A hidratação cai de 15.6 ms para **11.3 ms** (e de 27.7 ms no modo `dynamic`, no qual o carregamento do backend reside no caminho crítico). A troca de idioma cai de 15-16 ms para **11-12 ms**.
+- **O adaptador é diferente do runtime nativo.** O `next-intlayer` crava **141.3 KB**, meros +0.3 KB acima do app sem i18n. O adaptador suporta as particularidades da API do `i18next` (expressões de interpolação, sufixos de plural e contexto, tags `<Trans>`) sobre o núcleo do Intlayer: 9.4 KB e +9.4 KB por página em relação ao nativo. Atua como transição, não como destino final.
+
+> O adaptador `react-i18next` no Vite / TanStack Start não constou desta rodada de testes. A medição para `react-i18next` no TanStack Start pode ser verificada em [i18next vs Intlayer](https://intlayer.org/pt/blog/i18next-vs-intlayer): 127-184 KB por página e 123-185 ms na troca de idioma com backend sob demanda.
+
+## O motivo da mudança nos indicadores
+
+Nenhum arquivo em `components/` foi alterado, logo o ganho advém da entidade à qual `useTranslation` se acopla.
+
+**Com o `i18next`**, a ligação é feita na instância global. Qualquer recurso alocado nela (todos os idiomas em `static`, o namespace completo do idioma ativo em `dynamic`) torna-se acessível para qualquer componente chamador de `useTranslation()`. O bundler não consegue fragmentar abaixo do volume contido na instância, e o runtime não é capaz de prever quais chaves serão demandadas em renderização.
+
+```bash
+.
+├── next-i18next.config.js
+├── public/locales
+│   ├── en/translation.json           # strings de todas as páginas
+│   └── fr/translation.json
+├── i18n/i18n.ts                      # i18n.use(initReactI18next).init({ resources })
+└── components
+    ├── AppProviders.tsx              # <I18nextProvider i18n={i18n}>
+    └── About.tsx                     # useTranslation(); t("about.title")
+```
+
+**Com o `@intlayer/next-i18next`**, a ligação é feita diretamente com o dicionário. O plugin `syncJSON` transforma cada arquivo de namespace em um dicionário; o ciclo de otimização repassa ao componente apenas o dicionário declarado, na forma de import que o empacotador rastreia e separa por página e locale.
+
+```bash
+.
+├── intlayer.config.ts                # syncJSON({ format: "i18next", source: ... })
+├── public/locales
+│   ├── en/translation.json           # inalterado, continua como fonte da verdade
+│   └── fr/translation.json
+├── .intlayer/                        # gerado: um dicionário por namespace, por locale
+└── components
+    ├── AppProviders.tsx              # <IntlayerClientProvider locale={locale}>
+    └── About.tsx                     # useTranslation(); t("about.title")  ← inalterado
+```
+
+O arquivo `i18n/i18n.ts` e sua importação de `resources` tornam-se código inerte. É daí que procedem os 68 KB de alívio.
+
+## Migração em três etapas
+
+<Steps>
+<Step number={1} title="Instalação">
+
+```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
+```
+
+O comando identifica `i18next` / `react-i18next` / `next-i18next`, instala o `intlayer`, o pacote do framework (`next-intlayer` ou `react-intlayer`), o respectivo adaptador `@intlayer/*` e o `@intlayer/sync-json-plugin`, além de preencher o `intlayer.config.ts`. Conserve as dependências originais instaladas: elas operam como peer dependencies e entregam as tipagens.
+
+</Step>
+<Step number={2} title="Aponte o Intlayer para seus arquivos de tradução">
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic",
+    format: "i18next",
+  },
+  plugins: [
+    syncJSON({
+      // dialeto i18next: {{name}}, $t(key), key_one / key_other, key_male
+      format: "i18next",
+      // Um arquivo por namespace: `useTranslation("about")` → about.json
+      source: ({ locale, key }) => `./public/locales/${locale}/${key}.json`,
+      location: "public/locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+Caso você mantenha um único arquivo `translation.json` por locale (o namespace padrão do i18next), configure `splitKeys: false` para que o arquivo integral permaneça como um único dicionário e invocações diretas de `useTranslation()` prossigam sem falhas.
+
+</Step>
+<Step number={3} title="Adicione o plugin">
+
+<Tabs>
+<Tab label="Next.js">
+
+```ts fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { withI18next } from "@intlayer/next-i18next/plugin";
+
+const nextConfig: NextConfig = {};
+
+export default withI18next(nextConfig);
+```
+
+No App Router, componentes de cliente identificam o idioma pelo segmento `[locale]`. O `I18nextProvider` do adaptador não aceita locale como propriedade, logo substitua-o uma única vez no arquivo de provider:
+
+```tsx fileName="components/AppProviders.tsx"
+"use client";
+
+import { IntlayerClientProvider } from "next-intlayer";
+import type { LocalesValues } from "intlayer";
+
+export const AppProviders = ({
+  locale,
+  children,
+}: {
+  locale: LocalesValues;
+  children: React.ReactNode;
+}) => (
+  <IntlayerClientProvider locale={locale}>{children}</IntlayerClientProvider>
+);
+```
+
+Todos os componentes abaixo continuam invocando `useTranslation()`.
+
+</Tab>
+<Tab label="Vite / TanStack Start">
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import react from "@vitejs/plugin-react";
+import { reactI18nextVitePlugin } from "@intlayer/react-i18next/plugin";
+
+export default defineConfig({
+  plugins: [react(), reactI18nextVitePlugin()],
+});
+```
+
+O `reactI18nextVitePlugin()` encapsula o `vite-intlayer` e define os aliases para `react-i18next` e `i18next`. Para projetos sem React, `i18nextVitePlugin()` do `@intlayer/i18next/plugin` provê o alias somente para `i18next`.
+
+</Tab>
+</Tabs>
+
+</Step>
+</Steps>
+
+### O que você pode remover em seguida
+
+| Arquivo / padrão                                       | Motivo                                                                                       |
+| ------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
+| `resources: { en, fr, ... }` e importações JSON        | Ignorados pelo adaptador. Era aqui que se concentravam os 68 KB                              |
+| `i18next-http-backend`, `i18next-resources-to-backend` | Não há nada a carregar dinamicamente                                                         |
+| `i18next-browser-languagedetector`                     | A identificação é controlada pelo roteamento do Intlayer (prefixo de URL, cookie, cabeçalho) |
+| `serverSideTranslations()` em `getStaticProps`         | Devolve um objeto vazio; inofensivo, mas inútil                                              |
+| `next-i18next.config.js`                               | Não é consultado. Idiomas residem no `intlayer.config.ts`                                    |
+| Listas de `ns: [...]` por página                       | O compilador detecta os namespaces por componente                                            |
+
+### O que você ganha além da redução em bytes
+
+- **Tipagem estrita de chaves.** `useTranslation("about")` valida chaves contra o dicionário `about` compilado; `t("does.not.exist")` gera um erro do compilador TypeScript em vez de retornar a string crua.
+- **`npx intlayer test`** bloqueia a integração contínua (CI) se faltar qualquer tradução em qualquer idioma. **`npx intlayer fill`** traduz pendências com sua própria chave de provedor (OpenAI, Anthropic, Mistral, Gemini...) e as salva em `locales/{lng}/{ns}.json`.
+- **Editor Visual e CMS** atuam diretamente no mesmo JSON, permitindo que editores atualizem textos por interface gráfica enquanto os arquivos Git são versionados.
+- **Migração gradual para `.content.ts`.** Cada componente pode migrar de `useTranslation("about")` para `useIntlayer("about")` adotando um arquivo de conteúdo co-localizado. Dicionários JSON e `.content.ts` operam juntos harmonicamente.
+
+## Limitações importantes antes de iniciar
+
+- **Backends e detectores ficam desativados.** `i18n.use(HttpBackend)` executa o método `init` do plugin e encerra. Se seu projeto dependia de buscar traduções em um CMS em tempo de execução, esse fluxo é descontinuado; use o CMS do Intlayer ou os comandos `intlayer pull` / `push`.
+- **`resources` é descartado, não combinado.** Ao contrário de certos adaptadores, o `@intlayer/i18next` não usa `resources` inline como recurso de segurança. Toda chave precisa existir nos dicionários sincronizados, o que é validado por `intlayer test`.
+- **App Router necessita do ajuste de provider.** Apenas um arquivo, apresentado acima. O Pages Router com `appWithTranslation` opera sem ajustes adicionais.
+- **`next-i18next.config.js` não é aproveitado.** Parâmetros como `localePath`, `fallbackLng` e `reloadOnPrerender` não são lidos; configurações de idioma e fallback residem em `intlayer.config.ts`.
+- **O adaptador possui um custo.** 9.4 KB de runtime e +9.4 KB por página em relação ao `next-intlayer`. Assim que todos os componentes forem convertidos para `useIntlayer`, ele pode ser desinstalado.
+
+## Quando utilizar cada alternativa?
+
+- **Mantenha-se no `i18next`** se sua infraestrutura depender de backends dinâmicos em tempo de execução (traduções servidas sob demanda por CMS), de plugins exclusivos ou de um ambiente fora do ecossistema React não atendido pelos adaptadores.
+- **Adote `@intlayer/*`** se você já opera com `react-i18next` / `next-i18next` e deseja resgatar 68 KB, atingir componentes 8x menores, eliminar vazamento (0%), obter chaves tipadas e validação na CI sem reescrever seus componentes. É a transição recomendada para bases existentes de `i18next`.
+- **Prefira o modelo nativo (`next-intlayer` / `react-intlayer`)** em projetos novos ou logo após o adaptador consolidar a migração. Trata-se da opção mais rápida (5.5 KB, +0.3 KB por página), liberando Server Components síncronos e arquivos `.content.ts` por componente.
+
+## Comparações relacionadas
+
+- [i18next vs Intlayer](https://intlayer.org/pt/blog/i18next-vs-intlayer) (comparação das bibliotecas, mesmo benchmark)
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/pt/blog/next-intl-vs-intlayer-next-intl) (mesma série de adaptadores)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/pt/blog/lingui-vs-intlayer-lingui) (mesma série de adaptadores)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/pt/blog/vue-i18n-vs-intlayer-vue-i18n) (mesma série de adaptadores)
+- 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)
+- Referência dos adaptadores: [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)
+
+## Conclusão
+
+O `i18next` figura como o runtime mais pesado deste benchmark, e os adaptadores cortam a maior parte dessa carga sem exigir que você abandone sua API habitual. Na mesma aplicação Next.js, isso representa **68 KB a menos por página** comparado à configuração inicial, **12.7 KB a menos** em relação à opção mais otimizada manualmente, **componentes 8x mais leves**, **0% de vazamento** e **4 ms a menos de hidratação**, demandando apenas um arquivo de configuração, uma inclusão de plugin e um ajuste no provider. Backends e detectores tornam-se inócuos, `resources` é descartado ao invés de incorporado, e a implementação nativa do `next-intlayer` preserva outros 9 KB de leveza adicional.
+
+A totalidade dos dados brutos, aplicações de teste e scripts encontra-se publicada no [repositório do Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom).
+
+Consulte o documento [Por que Intlayer?](https://intlayer.org/pt/doc/why) para aprofundar.