@intlayer/docs 9.5.6 → 9.5.7

package/blog/pl/lingui_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "Lingui vs Intlayer: Benchmark i Porównanie 2026"
 description: "Dwie biblioteki i18n oparte na kompilatorze zmierzone w Next.js i TanStack Start. Rozmiar paczki, wyciek treści, rozmiar komponentu, hydratacja, reaktywność zmiany języka i wrażenia programisty."
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # Lingui VS Intlayer | Benchmark internacjonalizacji (i18n) w React i Next.js
 
+![JavaScript i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Lingui i Intlayer to dwie biblioteki w tym benchmarku, które opierają się na **kompilatorze**, a nie na czystym środowisku wykonawczym (runtime). Lingui wyodrębnia wiadomości z makr w czasie budowania i kompiluje katalogi per lokalizacja. Intlayer kompiluje słowniki per komponent i przeprowadza tree-shaking per lokalizacja. W teorii powinny dawać zbliżone wyniki. Liczby pokazują jednak, gdzie się różnią.
 
 Dane pochodzą z projektu [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), zestawu testów open-source, który buduje tę samą aplikację z każdą biblioteką i rejestruje, co przeglądarka faktycznie pobiera i wykonuje.
@@ -96,6 +98,10 @@ Dla każdego buildu zestaw rejestruje:
 
 ### Wyniki w Next.js
 
+Wybierz metryki i biblioteki, które Cię interesują:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Biblioteka          | Strategia      | Rozmiar Lib (gz) | Średni JS strony (gz) | Wyciek języka | Wyciek strony | Śr. komponentu (gz) | Reaktywność E2E | Hydratacja |
 | ------------------- | -------------- | ---------------: | --------------------: | ------------: | ------------: | ------------------: | --------------: | ---------: |
 | **base** (bez i18n) | -              |           0.0 KB |              141.0 KB |          0.0% |          0.0% |              0.9 KB |         13.4 ms |    11.8 ms |
@@ -114,6 +120,15 @@ Dla każdego buildu zestaw rejestruje:
 - **Wyciek języka zapasowego (fallback).** Nawet w zoptymalizowanych ustawieniach **3-15% ciągów `en` trafia na podstrony `fr`**. Makra Lingui zachowują tekst źródłowy jako fallback, przez co ląduje on w paczce obok tłumaczenia. Intlayer rozwiązuje fallbacki w czasie budowania i wysyła wyłącznie aktywny język.
 - **Gwałtowny wzrost rozmiaru komponentu w `scoped-dynamic`.** Każdy komponent skompilowany w izolacji osiąga średnio **152.6 KB**, ponieważ katalog każdej trasy staje się dostępny z komponentu, który go importuje. Ten sam komponent z `useIntlayer()` waży średnio zaledwie **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
 
 | Biblioteka                  | Strategia      | Rozmiar Lib (gz) | Średni JS strony (gz) | Wyciek języka | Wyciek strony | Śr. komponentu (gz) | Reaktywność E2E | Hydratacja |
@@ -135,8 +150,19 @@ Dla każdego buildu zestaw rejestruje:
 - **Wiersz `static` w Intlayerze ma już 0% wycieku stron**, ponieważ dołączane są wyłącznie słowniki importowane przez komponenty danej strony. Jedna linijka konfiguracji (`importMode: 'dynamic'`) usuwa również wyciek językowy.
 - **`@intlayer/lingui`** zachowuje składnię makr Lingui, ale zasila je ze słowników Intlayera. Poświęca nieco rozmiaru strony (137 KB ze względu na obecność runtime makr) w zamian za mniejsze komponenty (12.8 KB) i szybszą hydratację niż natywne Lingui. To doskonały krok migracyjny.
 
+<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).
+
 ## Skąd ta różnica? Dwa kompilatory, dwie jednostki pracy
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Obie biblioteki korzystają z kompilatora. Różnica polega na tym, **co** kompilują.
 
 **Lingui kompiluje katalogi.** Makra w kodzie źródłowym są wyodrębniane do jednego pliku `.po` na dany język, a następnie kompilowane do modułu JS na język. Podstawową jednostką jest **lokalizacja (język)**. Dalszy podział, per trasa lub per komponent, oznacza tworzenie wielu katalogów, odpowiednie konfigurowanie `lingui.config.ts` i ręczne ładowanie ich na trasach. Instancja `I18n` jest globalna; każde wywołanie `useLingui()` subskrybuje komponent do tej instancji.
@@ -176,7 +202,9 @@ Obie biblioteki korzystają z kompilatora. Różnica polega na tym, **co** kompi
             └── about.content.ts
 ```
 
-Dlatego wzorzec `scoped-dynamic` jest dla Intlayera naturalnym efektem budowania, a dla Lingui osobnym i pracochłonnym zadaniem konfiguracyjnym.
+Dlatego wzorzec `scoped-dynamic` jest dla Intlayera naturalnym efektem budowania, a dla Lingui osobnym i pracochłonnym zadaniem konfiguracyjnym. Różnica powiększa się 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)
 
 > Aby uzyskać liczby z wiersza `dynamic`, ustaw `dictionary.importMode: 'dynamic'` w pliku `intlayer.config.ts`. Zobacz [dokumentację optymalizacji paczki](https://intlayer.org/pl/doc/concept/bundle-optimization).
 
@@ -184,7 +212,8 @@ Dlatego wzorzec `scoped-dynamic` jest dla Intlayera naturalnym efektem budowania
 
 ### Konfiguracja
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="lingui.config.ts"
 import { defineConfig } from "@lingui/cli";
@@ -215,7 +244,8 @@ export const loadCatalog = async (locale: string) => {
 
 Następnie dodaj `@lingui/babel-plugin-lingui-macro` (lub `@lingui/swc-plugin`) do bundlera, uruchamiaj `lingui extract` po modyfikacji kodu źródłowego, `lingui compile` przed budowaniem aplikacji i owiń drzewo komponentów w `<I18nProvider i18n={i18n}>`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -232,9 +262,12 @@ export default config;
 
 Dodaj `intlayer()` do `vite.config.ts` (lub `withIntlayer()` do `next.config.ts`) i owiń drzewo w `<IntlayerProvider>`. Brak etapów extract czy compile: słowniki budują się samoczynnie podczas pracy bundlera.
 
+</Tab>
+</Tabs>
 ### Komponent
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```tsx fileName="src/components/Counter.tsx"
 import { useState } from "react";
@@ -258,7 +291,8 @@ export const Counter = () => {
 
 Angielski tekst znajduje się w komponencie; francuski ląduje w `src/locales/fr/messages.po` pod haszowanym identyfikatorem po uruchomieniu `lingui extract`. Zapomnienie o uruchomieniu komendy lub o `compile` cicho przywraca wersję angielską.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -297,11 +331,14 @@ export const Counter = () => {
 
 Oba języki znajdują się w jednym pliku tuż obok komponentu. Brak tłumaczenia `fr` powoduje błąd budowania, a błędny klucz to natychmiastowy błąd TypeScriptu.
 
+</Tab>
+</Tabs>
 ### Poza komponentami
 
 Metadane, loadery, funkcje serwerowe: dowolne miejsce bez drzewa Reacta.
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { setupI18n } from "@lingui/core";
@@ -324,7 +361,8 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 
 Nowa instancja `I18n` per wywołanie, ręczne ładowanie właściwego katalogu oraz użycie `msg` + `i18n._()` zamiast `t`. Jak zauważono w [uwagach do benchmarku](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md), rozróżnienie kiedy użyć `t`, `` t` ` ``, `i18n.t()`, `msg` czy `<Trans>` bywa nieintuicyjne.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { getIntlayer } from "intlayer";
@@ -336,6 +374,9 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Zachowaj makra Lingui, zyskaj słowniki Intlayera
 
 `@intlayer/lingui` to gotowy adapter dla `@lingui/core` i `@lingui/react`. Makra kompilują się tak jak dotychczas; wywołania `i18n._()`, do których prowadzą, są obsługiwane przez słowniki Intlayera, a wtyczki synchronizacji `.po` pozwalają zachować dotychczasowe pliki jako źródło prawdy. Liczba mnoga i konstrukcje ICU renderują się identycznie.
@@ -353,16 +394,82 @@ Zachowaj `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` w potoku bud
 
 ## Kiedy wybrać którą bibliotekę?
 
-- **Wybierz Lingui**, jeśli zależy Ci na **ICU MessageFormat** z typowanymi makrami, Twoi tłumacze pracują na plikach **`.po`** w ramach istniejącego systemu TMS, preferujesz ciągi źródłowe umieszczone inline w JSX i Twój zespół bez problemu zarządza procesem extract / compile / podziału katalogów.
-- **Wybierz Intlayer**, jeśli zależy Ci na **treści powiązanej bezpośrednio z komponentami**, **ścisłym TypeScripcie**, **wykrywaniu brakujących kluczy w czasie budowania**, **automatycznym tree-shakingu i leniwym ładowaniu bez zbędnej konfiguracji**, lekkich komponentach, błyskawicznej hydratacji, natychmiastowej zmianie języka oraz wbudowanych narzędziach redakcyjnych (Edytor Wizualny, CMS, tłumaczenia AI, serwer MCP).
-- **Wybierz `@intlayer/lingui`**, jeśli używasz obecnie Lingui i chcesz stopniowo przejść na słowniki Intlayera bez modyfikowania makr.
+<AccordionGroup>
+<Accordion header="Wybierz Lingui">
+
+Chcesz **ICU MessageFormat** z typowanymi makrami, Twoi tłumacze pracują w plikach **`.po`** z istniejącym potokiem TMS, wolisz ciągi źródłowe wbudowane w JSX, a Twój zespół bez problemu radzi sobie z przepływem ekstrakcji, kompilacji i podziału katalogów. Jego JS na stronę jest konkurencyjny po skonfigurowaniu leniwego ładowania.
+
+</Accordion>
+<Accordion header="Wybierz Intlayer">
+
+Chcesz **treści o zasięgu komponentu**, **ścisłego TypeScriptu**, **błędów brakujących kluczy w czasie budowania**, **bezproblemowego tree-shakingu i leniwego ładowania**, małych komponentów, szybkiej hydratacji, natychmiastowego przełączania języków 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 projektowych.
+
+</Accordion>
+<Accordion header="Wybierz @intlayer/lingui">
+
+Używasz Lingui i chcesz stopniowo przejść na słowniki Intlayer bez modyfikowania makr. Twoje katalogi `.po` pozostają źródłem prawdy dzięki [wtyczce synchronizacji PO](https://intlayer.org/pl/doc/compatibility/lingui). Zmierzone bezpośrednio w [Lingui vs @intlayer/lingui](https://intlayer.org/pl/blog/lingui-vs-intlayer-lingui).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Lingui również kompiluje. Dlaczego wynik jest tak różny?">
+
+Ponieważ jednostka kompilacji jest inna. Lingui kompiluje **jeden katalog na język**: wszystko poniżej (katalogi per trasa, leniwe ładowanie, wykluczenie wartości domyślnej z paczki) to kwestia ręcznej konfiguracji. Intlayer kompiluje **jeden słownik na komponent**, więc podział na trasy wynika bezpośrednio z procesu budowy. Dlatego komponent Lingui skompilowany w izolacji waży 58-153 KB w porównaniu do 6-8 KB w Intlayer.
+
+</Question>
+
+<Question title="Dlaczego wyciek językowy nigdy nie osiąga 0% w Lingui?">
+
+Makra zachowują komunikat źródłowy w czasie wykonywania jako fallback, więc ciąg angielski jest przesyłany obok tłumaczenia. Benchmark mierzy **3-15% ciągów `en` wewnątrz stron `fr`** w każdej zoptymalizowanej konfiguracji. Intlayer rozwiązuje fallbacki w czasie budowy i dostarcza tylko aktywny język.
+
+</Question>
+
+<Question title="Czy kod JavaScript na stronę w Lingui jest naprawdę konkurencyjny?">
+
+Tak, a na TanStack Start wygrywa o włos: 115.2 KB w trybie `dynamic` wobec 118.6 KB w Intlayer. Skompilowane katalogi z haszowanymi identyfikatorami są zwarte. Koszt ujawnia się gdzie indziej: hydratacja w 28-34 ms wobec 11-14 ms oraz zmiana języka trwająca **42 ms** w konfiguracji `scoped-dynamic`.
+
+</Question>
+
+<Question title="Czy muszę rezygnować z makr, aby przeprowadzić migrację?">
+
+Nie. `@intlayer/lingui` zachowuje kompilację `` t`...` ``, `<Trans>`, `msg`, `plural`, `select` i `selectOrdinal` tak jak dotychczas; zmienia się tylko to, względem czego `i18n._()` rozwiązuje tłumaczenia. Zachowaj `@lingui/babel-plugin-lingui-macro` lub `@lingui/swc-plugin` w procesie budowy. Zobacz [dokumentację zgodności z Lingui](https://intlayer.org/pl/doc/compatibility/lingui).
+
+</Question>
+
+<Question title="Co z krokami wyodrębniania i kompilacji?">
+
+Pozostają dla makr, a znikają w przypadku natywnych treści Intlayer. Słowniki `.content.ts` są tworzone podczas działania bundlera, bez osobnego kroku w CLI, a [`intlayer test`](https://intlayer.org/pl/doc/concept/cli) przerywa proces CI w przypadku brakującego klucza.
+
+</Question>
+
+</FAQ>
 
 ## Powiązane porównania
 
-- [next-intl vs Intlayer](https://intlayer.org/pl/blog/next-intl-vs-intlayer) (ten sam benchmark)
-- [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-vs-intlayer) (ten sam benchmark)
-- [Benchmark vue-i18n vs Intlayer](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-benchmark) (ten sam benchmark)
-- [Kompilator vs deklaratywne i18n](https://intlayer.org/pl/blog/compiler-vs-declarative-i18n)
+Ten sam benchmark, inne biblioteki:
+
+- [next-intl vs Intlayer](https://intlayer.org/pl/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-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)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/pl/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Więcej informacji:
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/pl/blog/lingui-vs-intlayer-lingui), adapter zmierzony na tej samej aplikacji
+- [Compiler-driven vs declarative i18n](https://intlayer.org/pl/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/pl/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/pl/blog/icu-message-format)
+
+Dokumentacja referencyjna:
+
+- [Raport benchmarku Next.js](https://intlayer.org/pl/doc/benchmark/nextjs) i [raport benchmarku TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack)
+- [Compat adapter: Lingui](https://intlayer.org/pl/doc/compatibility/lingui)
+- [Optymalizacja bundle](https://intlayer.org/pl/doc/concept/bundle-optimization) i [kompilator Intlayer](https://intlayer.org/pl/doc/compiler)
 
 ## Gwiazdki na GitHub
 

package/blog/pl/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: Ten sam API, Inny Bundle"
 description: Co się zmienia, gdy importy next-intl aplikacji Next.js są obsługiwane przez adapter kompatybilności @intlayer/next-intl. Rozmiar bundle'a, wyciek, rozmiar komponentu i hydratacja zmierzone na tym samym kodzie, plus co adapter zachowuje, ignoruje i nie może zastąpić.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Ten sam API, Inny Bundle
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` jest adapterem kompatybilności: ekspozuje API `next-intl` (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, plurale ICU, `NextIntlClientProvider`...) i serwuje go ze słowników skompilowanych przez Intlayer. Kod aplikacji nie zmienia się. Bundle się zmienia.
 
 Artykuł porównuje oba na tej samej aplikacji Next.js, zbudowanej raz z `next-intl` i raz z adapterem. Liczby pochodzą z [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), pakietu open-source'owego, który rejestruje to, co przeglądarka faktycznie pobiera. Jeśli chcesz porównania `next-intl` vs Intlayer jako bibliotek, przeczytaj [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer). Ten artykuł dotyczy tego, co adapter zmienia, gdy zachowujesz komponenty takimi, jakimi są.
@@ -109,6 +111,10 @@ Dla każdego buildu suite rejestruje:
 
 ### Wyniki na Next.js
 
+Wybierz metryki i biblioteki, które Cię interesują:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,6 +135,15 @@ Dla każdego buildu suite rejestruje:
 - **Hydration jest o 2 ms szybsza** (12.8 vs 14.7 ms): nie ma obiektu komunikatów do deserializacji z payloadu RSC, zanim React będzie mógł się nawodnić.
 - **Adapter nie jest natywnym runtime'em.** `next-intlayer` siedzi na **141.3 KB**, +0.3 KB ponad aplikację bazową, z runtime'em 5.5 KB. Adapter nosi API surface `next-intl` (`useFormatter`, `t.rich`, ICU resolver) na szczycie Intlayer'owego core'u, stąd 8.0 KB i +6 KB na stronę. To most, a nie miejsce docelowe.
 
+<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 na TanStack Start (`use-intl`)
 
 `use-intl` to framework-agnostyczne jądro `next-intl`. Jego adapter, `@intlayer/use-intl`, podąża za tym samym projektem z pluginem Vite (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ Dla każdego buildu suite rejestruje:
 - **Przełączanie lokalizacji jest szybsze.** Zoptymalizowane konfiguracje `use-intl` zajmują **13-21 ms** na aktualizację `html[lang]`; adapter zajmuje **4-9 ms**. Mniej komponentów się re-renderuje i nic nie jest pobierane ponownie z drzewa wiadomości.
 - **`static` zachowuje każdą lokalizację.** Wiersz `static` adaptera pokazuje 49,7% wycieków lokalizacji, tak samo jak natywny Intlayer w trybie `static`: wszystkie lokalizacje są pakowane, tylko słowniki strony. Jedna linia konfiguracji (`importMode: 'dynamic'`) ją usuwa.
 
+<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 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 komponencie się nie zmieniło, więc zyski pochodzą całkowicie z tego, do czego `useTranslations` jest powiązany.
 
-**Z `next-intl`**, binding jest dostawcą. `NextIntlClientProvider` otrzymuje cały obiekt `messages` dla locale'a; każdy `useTranslations("about")` czyta z niego. Bundler widzi jeden komponent importujący jeden hook, który czyta jeden context, i nie może wiedzieć, że używana jest tylko gałąź `about`. Trasy poniżej dzielą się tym samym obiektem message'a, więc kolumna page-leak czyta ~90% aż do czasu, gdy samodzielnie podzielisz plik.
+**Z `next-intl`**, binding jest dostawcą. `NextIntlClientProvider` otrzymuje cały obiekt `messages` dla locale'a; każdy `useTranslations("about")` czyta z niego. Bundler widzi jeden komponent importujący jeden hook, który czyta jeden context, i nie może wiedzieć, że używana jest tylko gałąź `about`. Trasy poniżej dzielą się tym samym obiektem message'a, więc kolumna page-leak czyta ~90% aż do czasu, gdy samodzielnie podzielisz plik, a narzut 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
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## Ograniczenia, które warto znać przed rozpoczęciem
 
-- **Routing config przenieśli się do `intlayer.config.ts`.** `createNavigation(routing)` i `createMiddleware(routing)` zachowują swoją sygnaturę, ale ignorują argument: locales, domyślny locale i strategia prefiksu pochodzą z konfiguracji `routing` Intlayera. Jeśli używasz zlokalizowanych `pathnames` (`/about` → `/a-propos`) z `next-intl`, adapter ich nie interpoluje; `routing.rewrite` Intlayera obejmuje ten przypadek, ale jest to oddzielna zmiana.
-- **`useTranslations()` bez namespace nie jest powiązany.** Przebieg optymalizacji wymaga statycznego namespace, aby wiedzieć, który słownik zaimportować. Bare call nadal działa, za pośrednictwem runtime registry, który odwołuje się do każdego słownika, co jest dokładnie wyciekiem, który chciałeś usunąć. Przekaż namespace.
-- **Adapter nie jest darmowy.** 8.0 KB runtime w porównaniu do 5.5 KB dla `next-intlayer`, i +6-7 KB na stronę w stosunku do natywnego buildu. To pokrywa koszt powierzchni API `next-intl`. Jeśli osiągniesz punkt, w którym każdy component został przeniesiony do `useIntlayer`, porzuć adapter.
-- **`messages`, `timeZone`, `now` na providerze są ignorowane.** Formaterzy są wspierani przez natywny `Intl` i tylko locale wpływa na ich output; jeśli polegasz na wymuszonym time zone lub ustalonym `now` dla hydration-stabilnych dat, obsługuj to w miejscu wywołania.
+<AccordionGroup>
+<Accordion header="Konfiguracja routingu przenosi się do intlayer.config.ts">
+
+`createNavigation(routing)` i `createMiddleware(routing)` zachowują sygnatury, ale ignorują argument: języki, język domyślny i strategia prefiksów pochodzą z konfiguracji `routing` Intlayer. Jeśli używasz zlokalizowanych `pathnames` z `next-intl` (`/about` na `/a-propos`), adapter ich nie interpoluje; `routing.rewrite` w Intlayer obsługuje ten przypadek, ale jest osobną zmianą.
+
+</Accordion>
+<Accordion header="useTranslations() bez przestrzeni nazw nie jest powiązane">
+
+Faza optymalizacji wymaga statycznej przestrzeni nazw, aby wiedzieć, który słownik zaimportować. Wywołanie bez namespace nadal działa poprzez rejestr runtime odwołujący się do każdego słownika, co stanowi dokładnie ten wyciek, który próbowano wyeliminować. Przekaż przestrzeń nazw.
+
+</Accordion>
+<Accordion header="Adapter nie jest darmowy">
+
+8.0 KB runtime w porównaniu z 5.5 KB dla `next-intlayer` i +6-7 KB na stronę względem kompilacji natywnej. Płaci za powierzchnię API `next-intl`. Kiedy każdy komponent przejdzie na `useIntlayer`, usuń adapter.
+
+</Accordion>
+<Accordion header="messages, timeZone i now w providerze są ignorowane">
+
+Formatery opierają się na natywnym `Intl` i tylko język wpływa na ich wynik. Jeśli polegasz na wymuszonej strefie czasowej lub stałym `now` dla stabilnych dat przy hydratacji, obsłuż to w miejscu wywołania. Zobacz [formatowanie daty, czasu i liczb](https://intlayer.org/pl/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## Kiedy używać którego?
 
-- **Zostań przy `next-intl`** jeśli twoja aplikacja jest mała, bundle nie jest problemem, i twój zespół jest komfortowy z posiadaniem namespaces i `pick()` na stronę.
-- **Użyj `@intlayer/next-intl`** jeśli aktualnie używasz `next-intl` i chcesz uzyskać korzyści w bundle, wyciekach i hydratacji, typed keys oraz narzędziach CLI / CMS bez pełnego przepisania. To jest rekomendowany punkt wejścia dla każdego istniejącego codebase'a `next-intl`.
-- **Przejdź na native (`next-intlayer`)** dla nowych projektów lub gdy adapter spełnił swoją rolę. Jest to najlżejsza z trzech opcji (5.5 KB, +0.3 KB na stronę) i odblokowuje synchroniczne server components, pliki `.content.ts` per-component i pełny zestaw funkcji.
+<AccordionGroup>
+<Accordion header="Zostań przy next-intl">
+
+Twoja aplikacja jest mała, rozmiar paczki nie stanowi problemu, a zespół bez problemu radzi sobie z zarządzaniem przestrzeniami nazw i `pick()` na stronę.
+
+</Accordion>
+<Accordion header="Użyj @intlayer/next-intl">
+
+Używasz dziś `next-intl` i chcesz uzyskać korzyści w rozmiarze bundle, braku wycieków, szybszej hydratacji, typowanych kluczach i narzędziach CLI / CMS bez przepisywania kodu. To zalecany punkt wyjścia dla każdej istniejącej bazy kodu `next-intl`.
+
+</Accordion>
+<Accordion header="Przejdź na rozwiązanie natywne (next-intlayer)">
+
+Dla nowych projektów lub po zakończeniu etapu przejściowego z adapterem. Jest najlżejszy z całej trójki (5.5 KB, +0.3 KB na stronę) i odblokowuje synchroniczne komponenty serwerowe, pliki `.content.ts` dla każdego komponentu oraz pełen zestaw funkcji. Zacznij od [Intlayer z Next.js](https://intlayer.org/pl/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Czy kod mojej aplikacji naprawdę pozostaje nienaruszony?">
+
+W Next.js tak dla komponentów: build benchmarku zmienił tylko `next.config.ts` i `intlayer.config.ts`. `getRequestConfig` w `src/i18n.ts`, prop `messages` w providerze oraz wywołania `pick()` stają się martwym kodem, który można potem usunąć.
+
+</Question>
+
+<Question title="Co dzieje się z komunikatami ICU?">
+
+Nadal działają. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` oraz `{ts, date, long}` są przetwarzane przez mechanizm ICU Intlayer. Zobacz [format wiadomości ICU](https://intlayer.org/pl/blog/icu-message-format).
+
+</Question>
+
+<Question title="Dlaczego adapter jest cięższy niż natywny next-intlayer?">
+
+Niesie ze sobą powierzchnię API `next-intl` na bazie rdzenia Intlayer: `useFormatter`, `t.rich`, resolver ICU, pomocników nawigacji. To 8.0 KB w porównaniu do 5.5 KB i +6 KB na stronę. To most, a nie cel ostateczny.
+
+</Question>
+
+<Question title="Czy mogę migrować komponent po komponencie?">
+
+Tak. Każdy komponent może przejść z `useTranslations("about")` na `useIntlayer("about")` z umieszczonym obok plikiem `.content.ts`. Słowniki JSON i `.content.ts` współistnieją i łączą się.
+
+</Question>
+
+<Question title="Czy działają zlokalizowane ścieżki (pathnames)?">
+
+Nie przez `pathnames` z `next-intl`: adapter akceptuje je do typowania, ale ich nie interpoluje. Zamiast tego użyj `routing.rewrite` z Intlayer.
+
+</Question>
+
+</FAQ>
 
 ## Powiązane porównania
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (biblioteki, ten sam benchmark)
-- [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) (seria tego samego adaptera)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (seria tego samego adaptera)
-- [Przewodnik migracji: next-intl do Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Dokumentacja adaptera kompatybilności: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Ta sama seria adapterów:
+
+- [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)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Bezpośrednie porównanie bibliotek:
+
+- [next-intl vs Intlayer](https://intlayer.org/pl/blog/next-intl-vs-intlayer), ten sam benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/pl/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/pl/blog/is-next-intl-outdated)
+
+Dokumentacja referencyjna:
+
+- [Compat adapter: next-intl](https://intlayer.org/pl/doc/compatibility/next-intl)
+- [Przewodnik migracji: z next-intl do Intlayer](https://intlayer.org/pl/doc/migration/next-intl)
+- [Raport benchmarku Next.js](https://intlayer.org/pl/doc/benchmark/nextjs) i [raport benchmarku TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack)
+- [Optymalizacja bundle](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