@intlayer/docs 9.5.2 → 9.5.4-canary.0

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

@@ -49,7 +49,7 @@ As abordagens mudaram expressivamente: partimos de objetos globais e chamadas `t
 
 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)
+![Ecossistema de bibliotecas de internacionalização em JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
 
 ## Índice
 
@@ -149,87 +149,87 @@ As abas a seguir mostram como cada ecossistema respondeu a essas demandas, organ
 
 <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.                    |
+| Primeiro Lançamento | Biblioteca                           | Autor                                                        | Objetivo Principal                                                                                                                                        | Inovação Chave                                                                                                                                                 |
+| ------------------- | ------------------------------------ | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Janeiro de 2012     | `i18next`                            | Jan Mühlemann (`@jamuhl`)                                    | 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`                      | Ivan Hofer (`@ivanhofer`)                                    | 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`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | 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.                                                         |
+| Agosto 2024         | `intlayer`                           | Aymeric Pineau (`@aymericzip`)                               | 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`                            | Kidus Adugna (`@K1DV5`)                                      | 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.                                                                       |
+| Primeiro Lançamento | Biblioteca       | Autor                          | Objetivo Principal                                                                                                                                       | Inovação Chave                                                                                                                                                     |
+| ------------------- | ---------------- | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Junho de 2014       | `react-intl`     | Yahoo! / FormatJS              | 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`  | Jan Mühlemann (`@jamuhl`)      | 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`  | Tomáš Ehrlich (`@tricoder42`)  | 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`       | Jan Amann (`@amannn`)          | 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`  | Jan Cizmar (`@jcizmar`)        | 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.                                             |
+| Agosto 2024         | `react-intlayer` | Aymeric Pineau (`@aymericzip`) | 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`       | Ernest McCarter (`@eoinest`)   | 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.                                                          |
+| Junho 2025          | `@wuchale/jsx`   | Kidus Adugna (`@K1DV5`)        | 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.                                                                       |
+| Primeiro Lançamento | Biblioteca                                  | Autor                                                        | Objetivo Principal                                                                                                 | Inovação Chave                                                                                                                                                                             |
+| ------------------- | ------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Novembro de 2018    | `next-i18next`                              | Isaac Hinman (`@isaachinman`)                                | 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 2020       | `next-translate`                            | Arvin Wiyono (`@arvinn`) / Vinissimus (`@vinissimus`)        | 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.                                                                                      |
+| Dezembro 2020       | `next-intl`                                 | Jan Amann (`@amannn`)                                        | 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`                        | Tom Dussaix (`@tom-dussaix`)                                 | 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.                                                                               |
+| Outubro 2023        | `paraglide-next` (`@inlang/paraglide-next`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | 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.                                              |
+| Agosto 2024         | `next-intlayer`                             | Aymeric Pineau (`@aymericzip`)                               | 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. |
+| Julho 2024          | `gt-next`                                   | Ernest McCarter (`@eoinest`)                                 | 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. |
+| Primeiro Lançamento | Biblioteca     | Autor                                       | Objetivo Principal                                                                                                        | Inovação Chave                                                                                                                                            |
+| ------------------- | -------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Maio de 2014        | `vue-i18n`     | Kazupon (`@kazupon`)                        | 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`   | Comunidade Nuxt                             | 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 2020         | `fluent-vue`   | Mozilla (`@mozilla`) / Demivan (`@demivan`) | 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.                           |
+| Janeiro 2025        | `vue-intlayer` | Aymeric Pineau (`@aymericzip`)              | 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. |
+| Primeiro Lançamento | Biblioteca          | Autor                                                        | Objetivo Principal                                                                                                  | Inovação Chave                                                                                                                                         |
+| ------------------- | ------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Fevereiro de 2017   | `ngx-translate`     | Olivier Combe (`@ocombe`)                                    | 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` | Netanel Basal (`@NetanelBasal`) & Shahar Kazaz (`@shahar_k`) | 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` | Equipe Angular (@angular)                                    | 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`       | Jan Cizmar (`@jcizmar`)                                      | 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.                                                   |
+| Março 2026          | `angular-intlayer`  | Aymeric Pineau (`@aymericzip`)                               | 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.                              |
+| Primeiro Lançamento | Biblioteca        | Autor                          | Objetivo Principal                                                                                    | Inovação Chave                                                                                                                                               |
+| ------------------- | ----------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Julho de 2018       | `svelte-i18n`     | Kaisermann (`@kaisermann`)     | 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`  | Ivan Fevrier (`@ivanfevrier`)  | 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`  | Jan Cizmar (`@jcizmar`)        | 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.                                                       |
+| Outubro 2025        | `svelte-intlayer` | Aymeric Pineau (`@aymericzip`) | 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` | Kidus Adugna (`@K1DV5`)        | 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.                                        |
+| Primeiro Lançamento | Biblioteca               | Autor                          | Objetivo Principal                                                                                 | Inovação Chave                                                                                                                                |
+| ------------------- | ------------------------ | ------------------------------ | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| Setembro de 2021    | `@solid-primitives/i18n` | Comunidade SolidJS             | 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.            |
+| Julho 2025          | `solid-intlayer`         | Aymeric Pineau (`@aymericzip`) | 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`          | Tomáš Ehrlich (`@tricoder42`)  | 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>
 
@@ -237,7 +237,7 @@ As abas a seguir mostram como cada ecossistema respondeu a essas demandas, organ
 
 ## 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)
+![Histórico das bibliotecas de i18n em JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.webp?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:
 
@@ -287,7 +287,7 @@ Durante mais de dez anos, plataformas comerciais estruturaram receitas em torno
 
 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.
+- Iniciativas como o **lingo.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