@intlayer/docs 9.5.6 → 9.5.7

package/blog/pl/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: Benchmark i Porównanie 2026"
 description: "Szczegółowe porównanie next-intl i Intlayer w Next.js App Router i TanStack Start. Rozmiar paczki, wyciek treści, rozmiar komponentu, hydratacja i doświadczenie programisty."
 keywords:
@@ -22,11 +22,11 @@ author: aymericzip
 
 # next-intl VS Intlayer | Benchmark internacjonalizacji (i18n) w React i Next.js
 
-`next-intl` to obecnie domyślny wybór w zakresie i18n dla Next.js App Router: ścisła integracja z routingiem, pełna obsługa ICU MessageFormat i środowisko pracy znane każdemu, kto korzystał z klasycznych bibliotek i18n.
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
 
-`Intlayer` podchodzi do tematu od nowa: brak scentralizowanych słowników, brak konieczności ręcznego dopasowywania przestrzeni nazw (namespaces) do tras. Treści deklarowane są bezpośrednio przy komponentach, a kompilator w czasie budowania pakuje wyłącznie to, czego wymaga dana strona.
+`next-intl` jest najpopularniejszą biblioteką i18n dla Next.js. Intlayer to oparta na kompilatorze alternatywa o zasięgu komponentów. Obie lokalizują aplikację App Router. Pytanie brzmi, ile każda z nich kosztuje po zbudowaniu aplikacji.
 
-Poniższy artykuł porównuje obie biblioteki na podstawie danych z [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), otwartoźródłowego zestawu testów, który buduje tę samą aplikację z każdą biblioteką i rejestruje realny kod pobierany oraz wykonywany przez przeglądarkę.
+Ten artykuł nie jest samouczkiem. To porównanie oparte na liczbach z [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), pakietu testów porównawczych open-source, który buduje tę samą aplikację z każdą biblioteką i mierzy to, co przeglądarka faktycznie pobiera i wykonuje.
 
 <TOC/>
 
@@ -89,6 +89,10 @@ Dla każdego wariantu rejestrowano:
 
 ### Wyniki w Next.js (App Router)
 
+Wybierz metryki i biblioteki, które Cię interesują:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Biblioteka                     | Strategia      | Rozmiar Lib (gz) | Śr. JS strony (gz) | Wyciek języka | Wyciek strony | Śr. komponentu (gz) | Reaktywność E2E | Hydratacja |
 | ------------------------------ | -------------- | ---------------: | -----------------: | ------------: | ------------: | ------------------: | --------------: | ---------: |
 | **Baza** (bez i18n)            | -              |           0.0 KB |           141.0 KB |          0.0% |          0.0% |              0.9 KB |         13.4 ms |    11.8 ms |
@@ -107,8 +111,19 @@ Dla każdego wariantu rejestrowano:
 - **Wyciek treści.** W najczęstszych konfiguracjach (`static` i `dynamic`) `next-intl` wysyła na każdej stronie **~90% ciągów z innych stron**, ponieważ cały plik `en.json` trafia do dostawcy klienta. Osiągnięcie 0% wymaga ręcznego dzielenia katalogów, podczas gdy Intlayer robi to automatycznie.
 - **Rozmiar komponentu.** Komponent wywołujący `useTranslations()` waży średnio 21.8 KB; ten sam komponent z `useIntlayer()` waży jedynie 6.9 KB.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Pełna tabela, każda biblioteka i każda strategia, w [raporcie benchmarku Next.js](https://intlayer.org/pl/doc/benchmark/nextjs).
+
 ### Wyniki w TanStack Start (`use-intl`)
 
+`use-intl` jest niezależnym od frameworka rdzeniem `next-intl`. To samo API, ten sam format wiadomości. Porównanie go z `intlayer` na TanStack Start usuwa z równania specyfikę Next.js.
+
 | Biblioteka                    | Strategia      | Rozmiar Lib (gz) | Śr. JS strony (gz) | Wyciek języka | Wyciek strony | Śr. komponentu (gz) | Reaktywność E2E |
 | ----------------------------- | -------------- | ---------------: | -----------------: | ------------: | ------------: | ------------------: | --------------: |
 | **Baza** (bez i18n)           | -              |           0.0 KB |           111.0 KB |          0.0% |          0.0% |              0.7 KB |          8.1 ms |
@@ -127,8 +142,19 @@ Dla każdego wariantu rejestrowano:
 - Różnica architektoniczna jest widoczna w **rozmiarze komponentów**: 76-87 KB w `use-intl` w porównaniu do 6-8 KB w Intlayerze.
 - **Przełączanie języka** jest 2-4x szybsze w Intlayerze (3 ms vs 7-21 ms).
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Pełna tabela w [raporcie benchmarku TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack).
+
 ## Dlaczego jest taka różnica? Scentralizowane katalogi vs kompilowane słowniki
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `next-intl` podąża za klasycznym wzorcem: jeden plik JSON per język, ładowany w `getRequestConfig`, przekazywany do `NextIntlClientProvider` i odczytywany przez `t("namespace.key")`.
 
 ```bash
@@ -150,6 +176,10 @@ Dla każdego wariantu rejestrowano:
 
 Runtime nie może wiedzieć, jakich kluczy użyje dana strona, dlatego domyślnie wysyła cały katalog.
 
+Koszt nieosiągnięcia tego celu rośnie na dwóch osiach jednocześnie: stron i języków:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer odwraca tę relację. Treść deklarowana jest tuż obok komponentu:
 
 ```bash
@@ -177,7 +207,8 @@ Podczas budowania kompilator analizuje, które komponenty importują poszczegól
 
 ### Komponent klienta
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -188,7 +219,7 @@ Podczas budowania kompilator analizuje, które komponenty importują poszczegól
 }
 ```
 
-```tsx fileName="src/components/Counter.tsx"
+```tsx fileName="src/components/ClientCounter.tsx"
 "use client";
 
 import { useState } from "react";
@@ -210,7 +241,10 @@ export const Counter = () => {
 };
 ```
 
-**Intlayer**
+> Pamiętaj o uwzględnieniu przestrzeni nazw `counter` w komunikatach przekazywanych do `NextIntlClientProvider` na każdej stronie renderującej ten komponent.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -249,11 +283,16 @@ export const Counter = () => {
 };
 ```
 
+Nie trzeba niczego rejestrować na stronie: komponent dostarcza własną treść.
+
+</Tab>
+</Tabs>
 ### Synchroniczne komponenty serwerowe
 
 Wspólne elementy interfejsu (pasek nawigacji, stopka, karty) są często komponentami serwerowymi renderowanymi wewnątrz komponentów klienckich, więc nie mogą być asynchroniczne (`async`).
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -269,7 +308,10 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 );
 ```
 
-**Intlayer**
+Strona musi wywołać `await getTranslations("counter")` i `await getFormatter()`, a następnie przekazać wyniki w dół jako propsy. Komponent przestaje być samowystarczalny.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -288,9 +330,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### Metadane
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -323,7 +368,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -347,6 +393,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Zachowaj API next-intl, zyskaj lekki bundle z Intlayer
 
 Nie musisz przepisywać komponentów, aby zyskać powyższe wyniki wydajnościowe. `@intlayer/next-intl` to adapter typu drop-in: zachowuje `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()` i formaty ICU, serwując je ze słowników skompilowanych przez Intlayera.
@@ -368,17 +417,84 @@ Zobacz [przewodnik migracji z next-intl](https://intlayer.org/pl/doc/migration/n
 
 ## Kiedy wybrać którą bibliotekę?
 
-- **Wybierz next-intl**, jeśli zależy Ci na standardzie społeczności Next.js, intensywnie korzystasz z ICU MessageFormat, Twoja aplikacja jest mała lub średnia, albo integrujesz się ze scentralizowanymi platformami TMS (Crowdin, Phrase, Lokalise...).
-- **Wybierz Intlayer**, jeśli zależy Ci na **treści powiązanej z komponentami**, **ścisłym TypeScripcie**, **wykrywaniu brakujących kluczy w czasie budowania**, **automatycznym tree-shakingu i leniwym ładowaniu**, synchronicznych komponentach serwerowych oraz wbudowanych narzędziach edycyjnych (Wizualny Edytor, CMS, tłumaczenia AI, serwer MCP).
-- **Wybierz `@intlayer/next-intl`**, jeśli używasz już `next-intl` i chcesz zredukować rozmiar paczki bez konieczności przepisywania kodu.
+<AccordionGroup>
+<Accordion header="Wybierz next-intl">
+
+Chcesz standardu ekosystemu Next.js, polegasz na ICU MessageFormat, Twoja aplikacja jest mała lub średnia, lub integrujesz się z platformą tłumaczeń (Crowdin, Phrase, Lokalise...) oczekującą scentralizowanego JSON. Zaplanuj czas na podział katalogów na przestrzenie nazw i wybieranie komunikatów za pomocą `pick()` na stronę, jeśli wydajność ma znaczenie.
+
+</Accordion>
+<Accordion header="Wybierz Intlayer">
+
+Chcesz **treści o zasięgu komponentu**, **ścisłego TypeScriptu**, **błędów brakujących kluczy w czasie budowania**, **automatycznego tree-shakingu i leniwego ładowania**, synchronicznych komponentów serwerowych oraz wbudowanych narzędzi redakcyjnych ([Edytor Wizualny](https://intlayer.org/pl/doc/concept/editor), [CMS](https://intlayer.org/pl/doc/concept/cms), [tłumaczenie AI](https://intlayer.org/pl/doc/concept/auto-fill), [serwer MCP](https://intlayer.org/pl/doc/mcp-server)). Szczególnie istotne dla dużych, modułowych baz kodu i systemów projektowania.
+
+</Accordion>
+<Accordion header="Wybierz @intlayer/next-intl">
+
+Używasz już `next-intl` i chcesz uzyskać korzyści z rozmiaru paczki bez przepisywania aplikacji. [Adapter zgodności](https://intlayer.org/pl/doc/compatibility/next-intl) zachowuje Twoje importy i plik `messages/{locale}.json` jako źródło prawdy. Zmierzono obok siebie w [next-intl vs @intlayer/next-intl](https://intlayer.org/pl/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Czy next-intl jest wolniejszy niż Intlayer?">
+
+Nie w czasie renderowania. Różnica polega na tym, co jest przesyłane do przeglądarki: `next-intl` kosztuje **+12.6 KB gzip** środowiska wykonawczego na każdej stronie i w standardowych konfiguracjach wysyła ~90% ciągów z innych stron wraz z każdą stroną. Przełączanie języka i hydratacja są porównywalne w Next.js (15-18 ms); w TanStack Start `use-intl` zajmuje 7-21 ms w porównaniu do 3-4 ms w Intlayer.
+
+</Question>
+
+<Question title="Czy mogę osiągnąć 0% wycieku z next-intl?">
+
+Tak, dzięki konfiguracji `scoped-dynamic`: podziel `messages/{locale}.json` na jedną przestrzeń nazw na trasę, a następnie użyj `pick(messages, [...])` na każdej stronie i utrzymuj to mapowanie w miarę przesuwania komponentów. Wiersze `scoped-*` w benchmarku odzwierciedlają dokładnie tę pracę. Intlayer osiąga 0% domyślnie, ponieważ kompilator ogranicza treść do poziomu komponentu. Zobacz [optymalizacja paczki](https://intlayer.org/pl/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Czy muszę przepisywać komponenty, aby przeprowadzić migrację?">
+
+Nie. `@intlayer/next-intl` zachowuje `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, liczbę mnogą ICU oraz pomocniki nawigacji, udostępniając je ze skompilowanych słowników. Wystarczy jedna linijka wtyczki w `next.config.ts`. Krok po kroku w [przewodniku migracji next-intl](https://intlayer.org/pl/doc/migration/next-intl).
+
+</Question>
+
+<Question title="Czy Intlayer obsługuje ICU MessageFormat?">
+
+Natywna obsługa ICU jest w trakcie opracowywania. Adaptery zgodności (`@intlayer/next-intl`, `@intlayer/use-intl`) w pełni obsługują ICU: liczba mnoga, `select`, `selectordinal`, `#` i `{ts, date, long}` przechodzą przez mechanizm ICU Intlayera. Szczegóły znajdziesz w [format wiadomości ICU](https://intlayer.org/pl/blog/icu-message-format).
+
+</Question>
+
+<Question title="Czy mogę zachować pliki messages/{locale}.json?">
+
+Tak. [Wtyczka synchronizacji JSON](https://intlayer.org/pl/doc/compatibility/next-intl) odczytuje je, dzieli klucze najwyższego poziomu na słowniki i zapisuje tłumaczenia z powrotem do tych samych plików, gdy CLI lub CMS je aktualizuje. Przepływ pracy tłumaczy pozostaje bez zmian.
+
+</Question>
+
+</FAQ>
 
 ## Powiązane porównania
 
-- [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-vs-intlayer) (ten sam benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/pl/blog/lingui-vs-intlayer) (ten sam benchmark)
-- [Benchmark vue-i18n vs Intlayer](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-benchmark) (ten sam benchmark)
+Ten sam benchmark, inne biblioteki:
+
+- [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/pl/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/pl/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [Czy next-intl jest przestarzałe?](https://intlayer.org/pl/blog/is-next-intl-outdated)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/pl/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Więcej o next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/pl/blog/next-intl-vs-intlayer-next-intl), adapter zmierzony na tej samej aplikacji
+- [Is next-intl outdated?](https://intlayer.org/pl/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/pl/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/pl/blog/nextjs-internationalization-using-next-intl)
+
+Dokumentacja referencyjna:
+
+- [Raport benchmarku Next.js](https://intlayer.org/pl/doc/benchmark/nextjs) oraz [raport benchmarku TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack)
+- [Adapter zgodności: next-intl](https://intlayer.org/pl/doc/compatibility/next-intl) oraz [przewodnik migracji](https://intlayer.org/pl/doc/migration/next-intl)
+- [Optymalizacja paczki](https://intlayer.org/pl/doc/concept/bundle-optimization) oraz [kompilator Intlayer](https://intlayer.org/pl/doc/compiler)
+- [i18n per-komponent vs scentralizowane](https://intlayer.org/pl/blog/per-component-vs-centralized-i18n)
+- [i18n oparte na kompilatorze vs deklaratywne](https://intlayer.org/pl/blog/compiler-vs-declarative-i18n)
 
 ## Gwiazdki na GitHub
 

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

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 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:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # vue-i18n VS @intlayer/vue-i18n | Ten sam API, Inny Bundle
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 `@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ą.
@@ -106,6 +108,10 @@ Dla każdego buildu, zestaw rejestruje:
 
 ### Wyniki na Vite + Vue 3
 
+Wybierz metryki i biblioteki, które Cię interesują:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
 | 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 |
@@ -125,11 +131,24 @@ Dla każdego buildu, zestaw rejestruje:
 - **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.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Pełna tabela, każda biblioteka i każda strategia, w [raporcie benchmarku Vue](https://intlayer.org/pl/doc/benchmark/vue).
+
 ## Dlaczego liczby się zmieniają
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 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.
+**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. Marnotrawstwo rośnie na dwóch osiach jednocześnie, stron i języków:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -259,26 +278,107 @@ export const i18n = createI18n({ locale: "en" });
 
 ## 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ąć.
+<AccordionGroup>
+<Accordion header="Bloki SFC <i18n> nie są odczytywane">
+
+Jeśli Twoje wiadomości znajdują się wewnątrz komponentów, muszą zostać przeniesione do plików lokalizacji lub do `.content.ts`, co stanowi tę samą koncepcję z wygenerowanymi typami.
+
+</Accordion>
+<Accordion header="Ładowanie wiadomości w czasie wykonywania zostało usunięte">
+
+`setLocaleMessage()` i `mergeLocaleMessage()` wyświetlają ostrzeżenie i kończą działanie. Tłumaczenia pobierane z CMS w czasie wykonywania wymagają [Intlayer CMS](https://intlayer.org/pl/doc/concept/cms) lub poleceń `intlayer pull` / `push`.
+
+</Accordion>
+<Accordion header="messages to rozwiązanie awaryjne, nie darmowe">
+
+Zachowanie importów JSON w `createI18n()` pozostawia 75 KB w paczce. Usuń je, gdy `intlayer test` zakończy się powodzeniem.
+
+</Accordion>
+<Accordion header="Adapter to nie natywny runtime">
+
+7.9 KB w porównaniu do 3.9 KB dla `vue-intlayer`. Gdy każdy komponent przejdzie na `useIntlayer`, usuń go.
+
+</Accordion>
+</AccordionGroup>
 
 ## 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.
+<AccordionGroup>
+<Accordion header="Pozostań przy vue-i18n">
+
+Twoja aplikacja zależy od bloków SFC `<i18n>`, od przepływów `setLocaleMessage()` w czasie wykonywania lub 90 KB na stronę nie stanowi problemu dla Twoich odbiorców.
+
+</Accordion>
+<Accordion header="Użyj @intlayer/vue-i18n">
+
+Korzystasz z `vue-i18n` i chcesz zaoszczędzić 88 KB, mieć 23-krotnie mniejsze komponenty, 0% wycieku stron, typowane klucze i testy CI bez modyfikowania plików `.vue`. To punkt wejścia dla istniejącej bazy kodu `vue-i18n`.
+
+</Accordion>
+<Accordion header="Przejdź na rozwiązanie natywne (vue-intlayer)">
+
+Dla nowych projektów lub po zakończeniu pracy przez adapter. Ma najlżejszy runtime (3.9 KB) i model `.content.ts` dla każdego komponentu, który zastępuje bloki `<i18n>` typowaną zawartością. Zacznij od [Intlayer z Vue](https://intlayer.org/pl/doc/environment/vite-and-vue) lub [z Nuxt](https://intlayer.org/pl/doc/environment/nuxt-and-vue).
+
+</Accordion>
+</AccordionGroup>
+
+## Często zadawane pytania
+
+<FAQ>
+
+<Question title="Czy muszę modyfikować pliki .vue?">
+
+Nie. Kompilacja benchmarku zmieniła jedynie `vite.config.ts`, `intlayer.config.ts` i jedną linię w `src/i18n.ts`, import `messages`. Wszystkie wywołania `useI18n()`, `$t`, `v-t` oraz Options API pozostały bez zmian.
+
+</Question>
+
+<Question title="Dlaczego rozmiar komponentu jest 23 razy mniejszy?">
+
+Ponieważ `useI18n()` przestaje odwoływać się do instancji globalnej. `createI18n({ messages })` zawiera wszystkie wiadomości ze wszystkich języków, przez co komponent skompilowany w izolacji pociąga za sobą 196 KB. Z adapterem sięga wyłącznie do własnego słownika: 8.4 KB.
+
+</Question>
+
+<Question title="Co z formatowaniem d() i n()?">
+
+Zachowane. Konfiguracje `datetimeFormats` i `numberFormats` przekazane do `createI18n()` są respektowane, wspierane przez natywne `Intl`. Zobacz [formatowanie daty, czasu i liczb](https://intlayer.org/pl/blog/date-time-number-formatting-locales).
+
+</Question>
+
+<Question title="Czy to działa z Nuxt?">
+
+`@intlayer/vue-i18n` jest przeznaczony dla Vite + Vue. Dla `@nuxtjs/i18n` użyj [adaptera zgodności Nuxt i18n](https://intlayer.org/pl/doc/compatibility/nuxtjs-i18n) i zapoznaj się z [Intlayer z Nuxt](https://intlayer.org/pl/doc/environment/nuxt-and-vue) w celu konfiguracji natywnej.
+
+</Question>
+
+<Question title="Czy mogę migrować komponent po komponencie?">
+
+Tak. Każdy komponent może przejść z `useI18n()` na `useIntlayer("footer")` z umieszczonym obok plikiem treści. Słowniki JSON i `.content.ts` współistnieją i łączą się.
+
+</Question>
+
+</FAQ>
 
 ## 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)
+Ta sama seria adapterów:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/pl/blog/next-intl-vs-intlayer-next-intl)
+- [i18next vs @intlayer/i18next](https://intlayer.org/pl/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/pl/blog/lingui-vs-intlayer-lingui)
+
+Biblioteki w bezpośrednim porównaniu:
+
+- [vue-i18n vs Intlayer](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer), features and DX
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-benchmark)
+- [Is vue-i18n outdated?](https://intlayer.org/pl/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/pl/blog/how-to-pick-vue-i18n-library)
+
+Dokumentacja referencyjna:
+
+- [Compat adapter: vue-i18n](https://intlayer.org/pl/doc/compatibility/vue-i18n) and [Nuxt i18n](https://intlayer.org/pl/doc/compatibility/nuxtjs-i18n)
+- [Przewodnik po migracji: z vue-i18n do Intlayer](https://intlayer.org/pl/doc/migration/vue-i18n)
+- [Raport benchmarku Vue](https://intlayer.org/pl/doc/benchmark/vue)
+- [Optymalizacja paczki](https://intlayer.org/pl/doc/concept/bundle-optimization) i [kompilator Intlayer](https://intlayer.org/pl/doc/compiler)
+- [Edytor wizualny](https://intlayer.org/pl/doc/concept/editor), [CMS](https://intlayer.org/pl/doc/concept/cms) i [tłumaczenie AI](https://intlayer.org/pl/doc/concept/auto-fill)
 
 ## Podsumowanie
 
@@ -286,4 +386,4 @@ export const i18n = createI18n({ locale: "en" });
 
 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).
+Więcej szczegółów znajdziesz w dokumentacji ['Why Intlayer?'](https://intlayer.org/pl/doc/why).