@intlayer/docs 9.5.1 → 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/history_of_i18n.md

@@ -0,0 +1,304 @@
+---
+createdAt: 2026-09-09
+updatedAt: 2026-09-09
+title: "A História da i18n em JavaScript: De 2011 a 2026"
+description: "Explore a evolução da internacionalização frontend de 2011 a 2026. Conheça datas de lançamento, desafios arquiteturais e inovações em React, Vue, Next.js, Angular, Svelte e Solid."
+keywords:
+  - história i18n
+  - internacionalização JavaScript
+  - React i18n
+  - Next.js i18n
+  - Vue i18n
+  - Angular i18n
+  - Svelte i18n
+  - Solid i18n
+  - i18next
+  - intlayer
+slugs:
+  - blog
+  - history-of-js-internationalization
+author: aymericzip
+---
+
+# A História da Internacionalização em JavaScript (i18n)
+
+A internacionalização não é um conceito recente. Muito antes do JavaScript e da web atual, softwares já precisavam lidar com múltiplos idiomas, moedas, formatos de data e particularidades regionais. Sistemas operacionais gráficos pioneiros como o GEM e o Mac OS já resolviam muitas dessas questões na década de 1980.
+
+Esses mesmos princípios chegaram progressivamente aos frameworks de backend. Ruby on Rails, Django, ambientes Java e aplicações PHP desenvolveram métodos próprios para lidar com internacionalização. As questões fundamentais estavam bem estabelecidas:
+
+- Onde os arquivos de tradução devem ficar?
+- Como formatamos datas, números e moedas?
+- Como tratamos plurais e nuances gramaticais?
+- Como definimos o idioma apropriado para cada usuário?
+
+Quando o servidor gerava o HTML completo, o fluxo era direto. A aplicação carregava as traduções corretas, compilava o HTML e entregava a resposta ao navegador.
+
+> O PHP e o GNU gettext foram precursores do padrão de função auxiliar `t()`, que mais tarde se tornou ubíquo no ecossistema JavaScript e JSX.
+
+Com o tempo, o JavaScript assumiu um papel central no navegador.
+
+À medida que as aplicações migraram de páginas renderizadas no servidor para Single-Page Applications (SPAs) complexas, a internacionalização tornou-se também um desafio do frontend. Subitamente, o navegador precisava carregar textos, alternar idiomas em tempo real, formatar valores, resolver plurais e atualizar a interface sem recarregar a página.
+
+Isso trouxe à tona uma questão decisiva:
+
+**Como construir uma aplicação multilíngue sem enviar um volume desproporcional de dados de tradução e código de runtime para cada usuário?**
+
+Essa pergunta moldou o desenvolvimento da i18n em JavaScript por mais de uma década.
+
+As abordagens mudaram expressivamente: partimos de objetos globais e chamadas `t('chave')`, passando por bibliotecas especializadas para cada framework, extração em tempo de compilação, verificação estrita de tipos com TypeScript, Server Components, tree-shaking e, finalmente, fluxos baseados em compiladores onde os conteúdos são transformados em código JavaScript otimizado durante o build.
+
+Este artigo analisa essa evolução entre 2011 e 2026: os objetivos de cada geração de ferramentas, o que funcionou, os limites encontrados e como a evolução da arquitetura frontend influencia a forma como lidamos com a i18n hoje.
+
+![Ecossistema de bibliotecas de internacionalização em JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.png?raw=true)
+
+## Índice
+
+<TOC/>
+
+## A Web Inicial: Internacionalização em JavaScript antes de 2016
+
+Para compreender as soluções modernas de i18n, convém revisitar o cenário do desenvolvimento web entre 2011 e 2015.
+
+### O deslocamento da lógica para o cliente
+
+No início da década de 2010, a internacionalização concentrava-se majoritariamente no servidor. O JavaScript desempenhava um papel secundário, focado em animações pontuais, validações de formulário e pequenos componentes DOM via jQuery.
+
+Com a popularização das SPAs impulsionada por Backbone.js, Knockout.js e as primeiras versões do AngularJS, a lógica de renderização migrou para o navegador. O código executado no cliente precisava exibir datas localizadas, formatar valores monetários, resolver pluralizações e trocar textos dinamicamente sem atualizar a página.
+
+No entanto, os navegadores de 2011 tinham poucas ferramentas nativas para essa demanda:
+
+<AccordionGroup>
+<Accordion header="Ausência de uma API nativa de internacionalização">
+
+A especificação ECMAScript Internationalization API (ECMA-402) foi concluída apenas em dezembro de 2012, apresentando o objeto global `Intl`. Antes de sua adoção generalizada, operações básicas de formatação demandavam funções manuais ou polyfills volumosos.
+
+</Accordion>
+<Accordion header="Falta de empacotadores de módulos modernos">
+
+Ferramentas como o Webpack estavam no início e módulos ES nativos não funcionavam nos navegadores. Os desenvolvedores incluíam scripts por meio de tags `<script>`, frequentemente gravando traduções em objetos globais como `window.translations = { ... }`.
+
+</Accordion>
+<Accordion header="Cargas JSON monolíticas">
+
+As traduções eram organizadas em arquivos JSON extensos e centralizados. Um usuário em Tóquio acessando apenas a página de entrada baixava simultaneamente os textos de configurações de conta, cobrança e painéis administrativos.
+
+</Accordion>
+</AccordionGroup>
+
+### A primeira leva de bibliotecas no cliente
+
+Entre 2012 e 2015, foram estabelecidas as bases da i18n moderna em JavaScript:
+
+<AccordionGroup>
+<Accordion header="i18next (janeiro de 2012)">
+
+Criada por Jan Mühlemann, a `i18next` definiu o padrão para dicionários chave-valor em tempo de execução no JavaScript. Introduziu navegação de chaves, interpolação de variáveis, regras de plural e uma arquitetura modular para plug-ins de detecção e armazenamento. Tornou-se rapidamente a referência em JavaScript puro e no ecossistema inicial de Node.js.
+
+</Accordion>
+<Accordion header="vue-i18n (maio de 2014)">
+
+Desenvolvida por Kazuya Kawaguchi (Kazupon), a `vue-i18n` integrou a internacionalização diretamente ao modelo reativo do Vue.js, introduzindo diretivas de template (`v-t`) e a função utilitária `$t()`.
+
+</Accordion>
+<Accordion header="react-intl (junho de 2014)">
+
+Criada pela Yahoo! dentro do projeto FormatJS, a `react-intl` incorporou os padrões do ICU MessageFormat e as APIs nativas `Intl` ao React através de componentes declarativos como `<FormattedMessage>` e `<FormattedDate>`.
+
+</Accordion>
+<Accordion header="react-i18next (dezembro de 2015)">
+
+Jan Mühlemann trouxe a `i18next` para o ecossistema React, utilizando Higher-Order Components (`withTranslation`) e contextos para atualizar componentes quando o idioma fosse alterado.
+
+</Accordion>
+</AccordionGroup>
+
+### Limitações do período anterior a 2016
+
+Embora tenham viabilizado aplicações clientes multilíngues, as limitações técnicas da época impunham restrições importantes:
+
+<AccordionGroup>
+<Accordion header="Chaves de texto frágeis">
+
+Buscas como `t('marketing.landing.hero.cta')` não contavam com validação estática. Erros de digitação passavam pelo build e causavam textos vazios ou chaves cruas em produção.
+
+</Accordion>
+<Accordion header="Sobrecarga de processamento em tempo de execução">
+
+A análise da sintaxe ICU e o processamento de expressões regulares consumiam capacidade relevante de CPU, sobretudo em smartphones.
+
+</Accordion>
+<Accordion header="Tamanho excessivo dos pacotes">
+
+Sem divisão de código por rotas ou componentes, todas as mensagens eram transmitidas em conjunto, aumentando o tempo de carregamento inicial.
+
+</Accordion>
+<Accordion header="Distância entre desenvolvedores e tradutores">
+
+Os dicionários ficavam em arquivos JSON separados dos componentes de interface, resultando com frequência em chaves abandonadas e traduções ausentes.
+
+</Accordion>
+</AccordionGroup>
+
+## A Era dos Frameworks: Evolução por Ecossistema
+
+Entre 2016 e 2026, a arquitetura frontend passou por uma reformulação profunda. O TypeScript consolidou-se como padrão, o desenvolvimento em componentes amadureceu, empacotadores como Webpack, Vite e Turbopack popularizaram o code splitting, React Server Components reposicionou parte da renderização no servidor, e compiladores passaram a inspecionar o código da aplicação diretamente.
+
+As abas a seguir mostram como cada ecossistema respondeu a essas demandas, organizando datas de lançamento, objetivos e inovações em tabelas comparativas. Nesses cenários, o `react-intlayer` e seus equivalentes (`next-intlayer`, `vue-intlayer`, `angular-intlayer`, `svelte-intlayer` e `solid-intlayer`) trazem soluções eficientes projetadas para seus respectivos ambientes.
+
+<Tabs>
+
+<Tab label="JavaScript Core" value="javascript">
+
+| Primeiro Lançamento | Biblioteca                           | Objetivo Principal                                                                                                                                        | Inovação Chave                                                                                                                                                 |
+| ------------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Janeiro de 2012     | `i18next`                            | Padronizar consultas a dicionários em runtime para navegador e Node.js de forma agnóstica a frameworks.                                                   | Arquitetura extensível separando a lógica de tradução de carregadores, detectores de idioma e cache.                                                           |
+| Fevereiro de 2021   | `typesafe-i18n`                      | Evitar falhas silenciosas em produção e interpolações quebradas por chaves de texto não tipadas.                                                          | Funções de tradução totalmente tipadas geradas a partir de objetos de tradução, sem dependências adicionais em runtime.                                        |
+| Outubro de 2023     | `paraglide` (`@inlang/paraglide-js`) | Eliminar consultas a dicionários em runtime, parsers pesados e crescimento desnecessário do bundle.                                                       | Compilação de mensagens em módulos ECMAScript puros e funções JavaScript compatíveis com tree-shaking.                                                         |
+| Abril de 2024       | `intlayer`                           | Substituir namespaces difíceis de manter, evitar vazamento de dados entre páginas, reduzir conflitos de git e entregar segurança estrita de tipos com TS. | Colocação de arquivos `.content` junto aos componentes, geração automática de tipos em TypeScript, CMS visual embutido e comandos de tradução com IA pela CLI. |
+| Junho de 2025       | `wuchale`                            | Remover a necessidade de extrair strings manualmente e inventar nomes de chave durante o desenvolvimento.                                                 | Pré-processamento via AST que identifica textos inline e os compila diretamente em funções localizadas sem necessidade de wrappers manuais.                    |
+
+</Tab>
+
+<Tab label="React" value="react">
+
+| Primeiro Lançamento | Biblioteca       | Objetivo Principal                                                                                                                                       | Inovação Chave                                                                                                                                                     |
+| ------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Junho de 2014       | `react-intl`     | Padronizar a formatação de números, datas, moedas e plurais complexos em aplicações React.                                                               | Componentes declarativos (`<FormattedMessage>`, `<FormattedDate>`) baseados no ICU MessageFormat e no padrão ECMA-402.                                             |
+| Dezembro de 2015    | `react-i18next`  | Oferecer uma integração idiomática da `i18next` para React com suporte a renderizações reativas.                                                         | Evolução junto ao React de Higher-Order Components para interpolação JSX com `<Trans>` e o hook `useTranslation`.                                                  |
+| Janeiro de 2018     | `@lingui/react`  | Diminuir o impacto no tamanho dos bundles provocado por interpretadores de ICU em tempo de execução.                                                     | Macros de Babel/SWC que compilam `<Trans>` e `t` em arrays indexados compactos durante a etapa de build.                                                           |
+| Dezembro de 2020    | `use-intl`       | Apresentar uma alternativa concisa, orientada a hooks e tipada às soluções tradicionais em React.                                                        | Hooks ergonômicos `useTranslations` e `useFormatter` com integração aprofundada com TypeScript.                                                                    |
+| Fevereiro de 2021   | `@tolgee/react`  | Agilizar a comunicação entre desenvolvedores, tradutores e designers.                                                                                    | Edição em contexto no navegador permitindo clicar com Alt sobre textos, editar traduções e capturar telas diretamente.                                             |
+| Abril de 2024       | `react-intlayer` | Oferecer uma implementação de alto desempenho adequada ao ciclo de vida do React, sem a complexidade de JSONs centralizados ou namespaces desconectados. | Hook `useIntlayer` otimizado para renderizações no React, geração automática de tipos, tree-shaking por componente e sincronização visual com CMS sem boilerplate. |
+| Julho de 2024       | `gt-react`       | Automatizar a exportação manual de arquivos e a gestão contínua de traduções.                                                                            | Localização automatizada por IA diretamente no código de componentes React através de pipelines em nuvem.                                                          |
+| Agosto de 2025      | `@wuchale/jsx`   | Dispensar a criação manual de chaves e o uso repetitivo de hooks em JSX.                                                                                 | Transformação AST que localiza nós de texto no JSX e os compila em equivalentes localizados.                                                                       |
+
+</Tab>
+
+<Tab label="Next.js" value="nextjs">
+
+| Primeiro Lançamento | Biblioteca                                  | Objetivo Principal                                                                                                 | Inovação Chave                                                                                                                                                                             |
+| ------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Novembro de 2018    | `next-i18next`                              | Viabilizar SSR e SSG com a `i18next` no Pages Router do Next.js sem gerar requisições encadeadas no cliente.       | Funções `serverSideTranslations` e `appWithTranslation` transmitindo namespaces traduzidos via props da página.                                                                            |
+| Dezembro de 2019    | `next-translate`                            | Simplificar a configuração e diminuir o peso dos pacotes em projetos que utilizam Pages Router.                    | Plugin para loader do Webpack que injeta apenas os namespaces de tradução necessários em cada página.                                                                                      |
+| Novembro de 2020    | `next-intl`                                 | Repensar a internacionalização para o App Router, React Server Components (RSC) e SSR com streaming.               | Integração nativa com middleware, Server Actions e Server Components assíncronos do Next.js sem depender de código cliente.                                                                |
+| Julho de 2022       | `next-international`                        | Assegurar checagem de tipos estrita em TypeScript com impacto mínimo no bundle do cliente para Next.js.            | Tipos estritos para chaves com escopo definido por meio de adaptadores leves para App Router e Pages Router.                                                                               |
+| Abril de 2024       | `paraglide-next` (`@inlang/paraglide-next`) | Disponibilizar mensagens compiladas sem runtime para o App Router e Pages Router do Next.js.                       | Roteamento via middleware combinado a funções compatíveis com tree-shaking, evitando parsing de JSON em runtime nos RSC e bundles de cliente.                                              |
+| Abril de 2024       | `next-intlayer`                             | Entregar um adaptador para Server Components sem a necessidade de repassar funções `t()` ou dicionários via props. | Permite invocar `useIntlayer` diretamente em Server Components síncronos sem prop-drilling, garantindo renderização sem cascatas no servidor, middleware de rotas e sincronização com CMS. |
+| Setembro de 2024    | `gt-next`                                   | Automatizar a geração de conteúdos multilíngues e rotas localizadas no Next.js por meio de IA.                     | Integração para App Router associando tradução automática na nuvem a middlewares edge e camadas de cache do Next.js.                                                                       |
+
+</Tab>
+
+<Tab label="Vue & Nuxt" value="vue">
+
+| Primeiro Lançamento | Biblioteca     | Objetivo Principal                                                                                                        | Inovação Chave                                                                                                                                            |
+| ------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Maio de 2014        | `vue-i18n`     | Prover internacionalização reativa e natural para projetos desenvolvidos com Vue.                                         | Integração estreita com a reatividade do Vue, diretivas de template (`v-t`), helpers `$t` e blocos específicos `<i18n>` em componentes SFC.               |
+| Novembro de 2017    | `@nuxt/i18n`   | Gerenciar roteamento de URLs traduzidas, marcações hreflang para SEO e hidratação SSR no Nuxt.                            | Módulo de rotas full-stack que gera caminhos localizados (prefixo, domínio), meta tags para SEO e carregamento sob demanda de blocos de texto.            |
+| Agosto de 2019      | `fluent-vue`   | Atender a gêneros gramaticais complexos, concordâncias e estruturas linguísticas não lineares no Vue.                     | Integração da sintaxe Project Fluent da Mozilla ao Vue, dispensando código condicional extenso para tratar variações do idioma.                           |
+| Abril de 2025       | `vue-intlayer` | Fornecer uma implementação do Intlayer ajustada à Composition API do Vue 3 e ao Nuxt, evitando poluição de escopo global. | Composable `useIntlayer` otimizado para o rastreamento reativo do Vue 3, isolamento por componente, autocompletar completo em TypeScript e CMS integrado. |
+
+</Tab>
+
+<Tab label="Angular" value="angular">
+
+| Primeiro Lançamento | Biblioteca          | Objetivo Principal                                                                                                  | Inovação Chave                                                                                                                                         |
+| ------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Fevereiro de 2017   | `ngx-translate`     | Oferecer tradução dinâmica em tempo de execução no Angular sem exigir builds independentes para cada idioma.        | Serviço `TranslateService` e pipe `translate` viabilizando o carregamento assíncrono e a troca de idioma em execução.                                  |
+| Julho de 2019       | `@ngneat/transloco` | Superar limitações de desempenho, ausência de escopos isolados e carências funcionais de bibliotecas anteriores.    | Diretiva estrutural (`*transloco`), traduções isoladas para módulos com lazy loading, suporte a SSR e utilitário CLI de extração.                      |
+| Setembro de 2019    | `@angular/localize` | Atualizar o mecanismo nativo de i18n do Angular para evitar a recompilação completa do TypeScript a cada idioma.    | Template literals marcados com `$localize` injetados em uma etapa rápida pós-build pelo compilador Ivy.                                                |
+| Fevereiro de 2021   | `@tolgee/ngx`       | Incorporar tradução colaborativa no contexto e captura de telas aos fluxos de trabalho do Angular.                  | Pipes e diretivas integrados ao Tolgee para permitir alterações de texto diretamente pelo navegador.                                                   |
+| Abril de 2025       | `angular-intlayer`  | Disponibilizar uma implementação nativa do Intlayer para o Angular moderno (Signals, componentes standalone e SSR). | Integração reativa orientada a Signals compatível com o ciclo de detecção de mudanças do Angular, injeção de dependências standalone e sync com o CMS. |
+
+</Tab>
+
+<Tab label="Svelte & SvelteKit" value="svelte">
+
+| Primeiro Lançamento | Biblioteca        | Objetivo Principal                                                                                    | Inovação Chave                                                                                                                                               |
+| ------------------- | ----------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Julho de 2018       | `svelte-i18n`     | Estruturar uma solução reativa de internacionalização ancorada nos stores do Svelte.                  | Acesso via `$t` vinculado aos stores para garantir atualizações pontuais na árvore do DOM quando o idioma é alterado.                                        |
+| Dezembro de 2021    | `sveltekit-i18n`  | Gerenciar SSR e o carregamento de traduções por rota em aplicações SvelteKit de modo ordenado.        | Arquitetura de carregamento modular que obtém exclusivamente as mensagens e formatadores requisitados pela rota em exibição.                                 |
+| Novembro de 2021    | `@tolgee/svelte`  | Habilitar tradução em contexto para aplicações Svelte.                                                | Vinculação a stores do Svelte associada à interface de edição do Tolgee e captura programada de telas.                                                       |
+| Abril de 2025       | `svelte-intlayer` | Prover uma integração ágil do Intlayer projetada de raiz para Svelte 5 e SvelteKit.                   | Suporte nativo aos Runes do Svelte 5 (`$state`), declarações de conteúdo `.content` por componente, plug-ins de build zero-config e interface de CMS visual. |
+| Julho de 2025       | `@wuchale/svelte` | Eliminar o trabalho repetitivo de declarar dicionários e importar funções `$t` em componentes Svelte. | Pré-processador para Svelte que inspeciona templates durante o build e traduz nós de texto sem acrescentar wrappers adicionais.                              |
+
+</Tab>
+
+<Tab label="SolidJS" value="solid">
+
+| Primeiro Lançamento | Biblioteca               | Objetivo Principal                                                                                 | Inovação Chave                                                                                                                                |
+| ------------------- | ------------------------ | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| Setembro de 2021    | `@solid-primitives/i18n` | Desenvolver uma primitiva de i18n alinhada à reatividade refinada do SolidJS.                      | Resolução de traduções baseada em Signals capaz de atualizar elementos do DOM sem Virtual DOM nem re-renderizações desnecessárias.            |
+| Abril de 2025       | `solid-intlayer`         | Entregar uma implementação rápida do Intlayer criada especificamente para SolidJS e SolidStart.    | Vinculações compatíveis com Signals sem o peso de um Virtual DOM, validação estrita via esquemas TypeScript e integração com o editor visual. |
+| Junho de 2026       | `@lingui/solid`          | Levar a extração de mensagens via macros no build e o suporte ao ICU MessageFormat para o SolidJS. | Macros ajustadas ao modelo reativo do Solid, compilando mensagens em estruturas enxutas para execução.                                        |
+
+</Tab>
+
+</Tabs>
+
+## As Quatro Eras Arquiteturais da i18n em JavaScript
+
+![Histórico das bibliotecas de i18n em JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.png?raw=true)
+
+Ao analisar quinze anos de inovações, é possível estruturar a trajetória da internacionalização em JavaScript em quatro eras bem delineadas:
+
+<AccordionGroup>
+<Accordion header="1. A Era dos Dicionários em Runtime (2011 a 2017)">
+
+Marcada por `i18next`, `react-intl` e `vue-i18n`. As aplicações mantinham arquivos JSON estáticos em memória, e funções de busca percorriam objetos com base em chaves de texto. Pluralizações e substituições de variáveis eram resolvidas no navegador via expressões regulares e interpretadores ICU no cliente.
+
+</Accordion>
+<Accordion header="2. A Era das Macros no Build e Tipagem Estática (2018 a 2021)">
+
+Representada por `lingui`, `next-translate`, `transloco` e `typesafe-i18n`. Os desenvolvedores passaram a notar o custo do parsing em execução e os riscos de chaves sem checagem de tipos. Macros de Babel passaram a extrair textos no build, plugins de bundlers particionaram dicionários por página e o TypeScript passou a validar parâmetros de tradução.
+
+</Accordion>
+<Accordion header="3. A Era dos Server Components e Streaming (2022 a 2024)">
+
+Evidenciada por `next-intl`, `next-international` e adaptadores pioneiros de RSC. Com o surgimento dos React Server Components e do Next.js App Router, o objetivo principal tornou-se renderizar conteúdos traduzidos no servidor, sem despachar dicionários volumosos ou bibliotecas pesadas de i18n para o navegador.
+
+</Accordion>
+<Accordion header="4. A Era dos Compiladores Modernos e Conteúdo Unificado (2024 a 2026)">
+
+Protagonizada por `paraglide`, `intlayer` e `wuchale`. As soluções contemporâneas enxergam a internacionalização não apenas como substituição de strings, mas como uma arquitetura completa de conteúdo. Compiladores transformam mensagens em funções otimizadas para tree-shaking, declarações ficam acopladas aos componentes, e editores visuais e fluxos com IA integram-se organicamente ao trabalho diário. Sob essa perspectiva, o Intlayer separa a declaração e a geração de tipos da execução, fornecendo adaptadores dedicados (`react-intlayer`, `next-intlayer`, `vue-intlayer`, `angular-intlayer`, `svelte-intlayer` e `solid-intlayer`) otimizados para a reatividade de cada framework.
+
+</Accordion>
+</AccordionGroup>
+
+## Conclusão: Equilibrando Produtividade, Desempenho e o Impacto da IA
+
+Ao longo de quinze anos e quatro ondas arquiteturais, o desafio fundamental da internacionalização em JavaScript manteve-se o mesmo: harmonizar uma boa experiência de desenvolvimento (DX) e manutenibilidade com o melhor desempenho possível no cliente.
+
+O que começou com variáveis globais e arquivos JSON monolíticos evoluiu para conteúdos organizados por componente, checagem automatizada de tipos com TypeScript, renderização em servidor sem cascatas e empacotamento enxuto gerado por compiladores.
+
+### A Transformação Pela IA e os Modelos Legados de Localização
+
+Um catalisador marcante nos últimos anos foi a automação de traduções por inteligência artificial, provocando reflexões sobre os modelos tradicionais das plataformas legadas de localização.
+
+Historicamente, agrupar mensagens em arquivos JSON centralizados foi um arranjo feito para facilitar a integração de Translation Management Systems (TMS). Um arquivo centralizado fornecia a tradutores externos e sistemas terceiros um ponto claro para importação e exportação. Em contrapartida, isso trazia custos arquiteturais pesados aos desenvolvedores: conflitos constantes em merges no Git, chaves abandonadas sem rastreabilidade, falta de contexto nos componentes e namespaces difíceis de gerenciar.
+
+Com os modelos de IA generativa e os compiladores atuais, a Developer Experience (DX) volta a ser prioridade. Ferramentas de build e linhas de comando (CLI) conseguem localizar, validar e traduzir arquivos associados a componentes de forma automática, dispensando concessões na arquitetura do código para atender ao fluxo de tradução.
+
+Durante mais de dez anos, plataformas comerciais estruturaram receitas em torno dessa intermediação manual:
+
+- Soluções como **Locize** (plataforma SaaS por trás da `i18next`) e **Crowdin** (parceira em vários projetos open-source) desenharam modelos de cobrança focados em hospedagem de traduções, planos por faixas e taxas por palavra.
+- Como dependem de volume e etapas manuais para faturamento, essas plataformas tradicionais têm poucos incentivos para disponibilizar automações gratuitas e integradas diretamente às ferramentas de desenvolvimento.
+
+### Novas Ferramentas de IA vs. Custo Direto de Provedores
+
+Conforme os Modelos de Linguagem reduziram o custo de tradução para frações de centavo com elevados padrões de precisão, novas ferramentas surgiram no mercado:
+
+- Iniciativas como o Paraglide com o **linguo.dev** ou a **General Translation** (`gt-react`, `gt-next`) estruturaram ofertas baseadas em assinaturas proprietárias e infraestruturas intermediárias na nuvem.
+- Por outro lado, o **Intlayer** disponibiliza tradução automatizada via IA diretamente através de sua CLI, viabilizando o uso de chaves de API próprias (como OpenAI, Anthropic, Mistral ou Google Gemini). Sem margens adicionais, comissões ou retenção de dados, a execução opera estritamente pelo custo base do provedor selecionado.
+
+### Mais do que i18n: Um Sistema Completo de Conteúdo Multilíngue
+
+O desenvolvimento web contemporâneo não se restringe a traduzir palavras avulsas como `"Enviar"` ou `"Entrar"`. As aplicações atuais exigem conteúdos estruturados, modulares e dinâmicos em jornadas completas de usuário.
+
+O Intlayer aborda esse cenário não como uma ferramenta limitada a buscas de texto, mas como um sistema abrangente para gestão de conteúdo multilíngue. Com suporte nativo a Markdown, marcações HTML, estruturas complexas de dados e um CMS visual integrado, ele conecta código, automações de IA e gestão editorial.
+
+Para comparações arquiteturais aprofundadas e roteiros práticos de migração, explore os links a seguir:
+
+- [Compilador vs. i18n Declarativa](https://github.com/aymericzip/intlayer/blob/main/docs/blog/pt/compiler_vs_declarative_i18n.md)
+- [i18n por Componente vs. Centralizada](https://github.com/aymericzip/intlayer/blob/main/docs/blog/pt/per-component_vs_centralized_i18n.md)
+- [Desempenho e Benchmarks](https://intlayer.org/doc/benchmark)
+- [Adaptadores de Compatibilidade do Intlayer](https://intlayer.org/doc/concept/compatibility)