@intlayer/docs 9.5.6 → 9.5.7

package/blog/pl/i18next_vs_intlayer-i18next.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs @intlayer/i18next: To samo API, inny bundle"
 description: "Co się zmienia, gdy aplikacja React lub Next.js zachowuje wywołania i18next, react-i18next i next-i18next, ale obsługuje je za pośrednictwem adapterów @intlayer/i18next. JavaScript na stronę, rozmiar komponentów, wycieki i hydratacja zmierzone na tym samym kodzie, a także co adaptery zachowują, ignorują i czego nie mogą zastąpić."
 keywords:
@@ -28,6 +28,8 @@ author: aymericzip
 
 # i18next VS @intlayer/i18next | To samo API, inny bundle
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/i18next`, `@intlayer/react-i18next` i `@intlayer/next-i18next` to adaptery kompatybilności. Udostępniają API `i18next`, którego Twój kod już używa (`useTranslation`, `t()`, `<Trans>`, `i18n.changeLanguage()`, `getFixedT`, `serverSideTranslations`...) i obsługują je ze słowników skompilowanych przez Intlayer. Komponenty się nie zmieniają. Zmienia się runtime pod nimi.
 
 Ten artykuł mierzy tę zamianę na tej samej aplikacji Next.js, zbudowanej raz z `next-i18next`, a raz z `@intlayer/next-i18next`. Liczby pochodzą z [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Aby porównać `i18next` i Intlayer jako biblioteki, przeczytaj [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-vs-intlayer). Ten artykuł dotyczy tego, co zmienia adapter, gdy zachowujesz swój kod bez zmian.
@@ -109,6 +111,10 @@ Dla każdego buildu zestaw rejestruje:
 
 ### Wyniki w Next.js
 
+Wybierz metryki i biblioteki, które Cię interesują:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Konfiguracja                 | Strategia      | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ---------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (brak i18n)         | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,10 +135,21 @@ Dla każdego buildu zestaw rejestruje:
 - **Hydratacja i przełączanie są szybsze.** Hydratacja przyspiesza z 15.6 ms do **11.3 ms** (oraz z 27.7 ms w konfiguracji `dynamic`, gdzie pobieranie z backendu znajduje się na ścieżce krytycznej). Przełączanie języka przyspiesza z 15-16 ms do **11-12 ms**.
 - **Adapter to nie natywny runtime.** `next-intlayer` osiąga **141.3 KB**, czyli +0.3 KB względem bazowej aplikacji. Adapter wnosi powierzchnię API `i18next` (dialekt interpolacji, rozwiązywanie sufiksów liczby mnogiej i kontekstu, parsowanie tagów `<Trans>`) na wierzchu rdzenia Intlayer: 9.4 KB i +9.4 KB na stronę ponad natywną implementację. To pomost, a nie ostateczny cel.
 
+<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).
+
 > Adapter `react-i18next` w Vite / TanStack Start nie brał udziału w tym uruchomieniu. Wartość bazowa `react-i18next` w TanStack Start znajduje się w [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-vs-intlayer): 127-184 KB na stronę i 123-185 ms przełączania języka przy leniwym backendzie.
 
 ## Dlaczego liczby się zmieniają
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 W katalogu `components/` nic się nie zmieniło, więc zyski wynikają z tego, z czym powiązane jest `useTranslation`.
 
 **W przypadku `i18next`** powiązaniem jest instancja globalna. Cokolwiek zostało do niej załadowane (wszystkie języki w `static`, cała przestrzeń nazw aktywnego języka w `dynamic`), jest dostępne z każdego komponentu wywołującego `useTranslation()`. Bundler nie może dokonać podziału poniżej tego, co zawiera instancja, a runtime nie może wiedzieć, o które klucze zapyta komponent.
@@ -149,6 +166,10 @@ W katalogu `components/` nic się nie zmieniło, więc zyski wynikają z tego, z
     └── About.tsx                     # useTranslation(); t("about.title")
 ```
 
+Wszystko, co zawiera instancja, jest przesyłane na każdą stronę, a marnotrawstwo rośnie na dwóch osiach, 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)
+
 **W przypadku `@intlayer/next-i18next`** powiązaniem jest słownik. `syncJSON` przekształca każdy plik przestrzeni nazw w słownik; krok optymalizacji przekazuje komponentowi słownik, do którego się odwołuje, jako import, który bundler może śledzić i dzielić według stron i języków.
 
 ```bash
@@ -297,26 +318,112 @@ export default defineConfig({
 
 ## Ograniczenia, które warto znać przed rozpoczęciem
 
-- **Backendy i detektory są nieaktywne.** `i18n.use(HttpBackend)` wywołuje `init` wtyczki i nic więcej. Jeśli Twoja aplikacja polegała na pobieraniu tłumaczeń z CMS w czasie wykonywania, ten mechanizm już nie działa; użyj CMS Intlayer lub poleceń `intlayer pull` / `push`.
-- **`resources` jest ignorowane, a nie scalane.** W przeciwieństwie do niektórych innych adapterów, `@intlayer/i18next` nie używa wbudowanych `resources` jako mechanizmu fallback. Każdy klucz musi istnieć w zsynchronizowanych słownikach, co weryfikuje `intlayer test`.
-- **App Router wymaga edycji providera.** Jeden plik, pokazany powyżej. Pages Router z `appWithTranslation` nie wymaga żadnych zmian.
-- **`next-i18next.config.js` nie jest odczytywany.** `localePath`, `fallbackLng`, `reloadOnPrerender` i pokrewne nie mają odpowiedników; języki i fallback pochodzą z `intlayer.config.ts`.
-- **Adapter nie jest darmowy.** 9.4 KB runtime i +9.4 KB na stronę względem `next-intlayer`. Gdy każdy komponent przejdzie na `useIntlayer`, można go usunąć.
+<AccordionGroup>
+<Accordion header="Backendy i detektory są bezczynne">
+
+`i18n.use(HttpBackend)` wywołuje jedynie init wtyczki i nic więcej. Jeśli Twoja aplikacja polegała na pobieraniu tłumaczeń z CMS w czasie wykonywania, ten przepływ znika; użyj zamiast tego [Intlayer CMS](https://intlayer.org/pl/doc/concept/cms) lub poleceń `intlayer pull` / `push`. Wykrywanie języka staje się konfiguracją routingu Intlayer (prefiks URL, cookie, nagłówek).
+
+</Accordion>
+<Accordion header="resources jest ignorowane, nie scalane">
+
+W przeciwieństwie do innych adapterów, `@intlayer/i18next` nie używa wbudowanych `resources` jako rozwiązania awaryjnego. Każdy klucz musi istnieć w zsynchronizowanych słownikach, co weryfikuje `intlayer test`.
+
+</Accordion>
+<Accordion header="App Router wymaga modyfikacji providera">
+
+Jeden plik, pokazany powyżej. Pages Router z `appWithTranslation` nie wymaga żadnych zmian.
+
+</Accordion>
+<Accordion header="next-i18next.config.js nie jest odczytywany">
+
+`localePath`, `fallbackLng`, `reloadOnPrerender` i pokrewne nie mają odpowiedników; języki i wartości domyślne pochodzą z `intlayer.config.ts`.
+
+</Accordion>
+<Accordion header="Adapter nie jest darmowy">
+
+9.4 KB runtime i +9.4 KB na stronę w stosunku do `next-intlayer`. Gdy każdy komponent przejdzie na `useIntlayer`, usuń go.
+
+</Accordion>
+</AccordionGroup>
 
 ## Kiedy używać którego rozwiązania?
 
-- **Pozostań przy `i18next`**, jeśli Twoja aplikacja zależy od backendów czasu wykonywania (tłumaczenia serwowane przez CMS w momencie żądania), od ekosystemu wtyczek lub od środowiska innego niż React, którego adaptery nie obsługują.
-- **Użyj `@intlayer/*`**, jeśli używasz `react-i18next` / `next-i18next` i zależy Ci na zaoszczędzeniu 68 KB, 8-krotnie mniejszych komponentach, 0% wycieków, typowanych kluczach i testach w CI bez konieczności przepisywania kodu. To idealny punkt wyjścia dla istniejącej bazy kodu `i18next`.
-- **Wybierz rozwiązanie natywne (`next-intlayer` / `react-intlayer`)** dla nowych projektów lub gdy adapter spełnił już swoje zadanie. Jest najlżejszy z całej trójki (5.5 KB, +0.3 KB na stronę) i odblokowuje synchroniczne komponenty serwerowe oraz pliki `.content.ts` powiązane z komponentami.
+<AccordionGroup>
+<Accordion header="Pozostań przy i18next">
+
+Twoja aplikacja zależy od backendów w czasie wykonywania (tłumaczenia serwowane przez CMS w momencie żądania), od ekosystemu wtyczek lub od środowiska innego niż React, którego adaptery nie obsługują.
+
+</Accordion>
+<Accordion header="Użyj @intlayer/*">
+
+Używasz `react-i18next` / `next-i18next` i chcesz zaoszczędzić 68 KB, mieć 8-krotnie mniejsze komponenty, 0% wycieków, typowane klucze i testy CI bez przepisywania kodu. To punkt wejścia dla istniejącej bazy kodu `i18next`.
+
+</Accordion>
+<Accordion header="Przejdź na rozwiązanie natywne (next-intlayer / react-intlayer)">
+
+Dla nowych projektów lub po zakończeniu pracy przez adapter. Ma najlżejszy runtime (5.5 KB, +0.3 KB na stronę) i odblokowuje synchroniczne Server Components oraz pliki `.content.ts` dla każdego komponentu. Zacznij od [Intlayer z Next.js](https://intlayer.org/pl/doc/environment/nextjs) lub [z Vite i React](https://intlayer.org/pl/doc/environment/vite-and-react).
+
+</Accordion>
+</AccordionGroup>
+
+## Często zadawane pytania
+
+<FAQ>
+
+<Question title="Skąd bierze się 68 KB?">
+
+Z `resources: { en, fr, ... }`. Domyślna konfiguracja `next-i18next` importuje JSON każdego języka do `init()`, przez co każda strona przenosi każdy namespace w każdym języku: **218.5 KB** na stronę. Adapter nigdy nie dołącza tego bloku w całości; przekazuje każdemu komponentowi tylko żądany słownik w aktywnym języku.
+
+</Question>
+
+<Question title="Czy moje komponenty <Trans> nadal działają?">
+
+Tak, z `components`, numerowanymi tagami `<1>...</1>` oraz `values`. Podobnie z `{{interpolation}}`, zagnieżdżaniem `$t(key)`, formami mnogimi `key_one` / `key_other` (ocenianymi za pomocą `Intl.PluralRules`), sufiksami kontekstowymi i `returnObjects`.
+
+</Question>
+
+<Question title="Co jeśli używam pojedynczego translation.json na język?">
+
+Ustaw `splitKeys: false` we wtyczce `syncJSON`. Cały plik pozostanie jednym słownikiem, a standardowe wywołanie `useTranslation()` będzie nadal na niego wskazywać.
+
+</Question>
+
+<Question title="Czy to to samo co migracja do Intlayer?">
+
+Nie, to pomost. Adapter zachowuje API `i18next` i kosztuje 9.4 KB runtime; natywny `next-intlayer` kosztuje 5.5 KB i dodaje synchroniczne Server Components oraz pliki `.content.ts` umieszczone obok komponentów. Możesz migrować komponent po komponencie, ponieważ słowniki JSON i `.content.ts` współistnieją.
+
+</Question>
+
+<Question title="Czy tłumacze mogą nadal pracować tak jak dzisiaj?">
+
+Tak. `locales/{lng}/{ns}.json` pozostaje źródłem prawdy: `syncJSON` odczytuje go w dialekcie i18next i zapisuje tłumaczenia z powrotem, gdy CLI lub CMS je zaktualizuje.
+
+</Question>
+
+</FAQ>
 
 ## Powiązane porównania
 
-- [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-vs-intlayer) (biblioteki, ten sam benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/pl/blog/next-intl-vs-intlayer-next-intl) (ta sama seria adapterów)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/pl/blog/lingui-vs-intlayer-lingui) (ta sama seria adapterów)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-vue-i18n) (ta sama seria adapterów)
-- Przewodniki migracji: [i18next](https://intlayer.org/pl/doc/migration/i18next), [react-i18next](https://intlayer.org/pl/doc/migration/react-i18next), [next-i18next](https://intlayer.org/pl/doc/migration/next-i18next)
-- Dokumentacja adapterów kompatybilności: [i18next](https://intlayer.org/pl/doc/compatibility/i18next), [react-i18next](https://intlayer.org/pl/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/pl/doc/compatibility/next-i18next)
+Ta sama seria adapterów:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/pl/blog/next-intl-vs-intlayer-next-intl)
+- [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)
+
+Biblioteki w bezpośrednim porównaniu:
+
+- [i18next vs Intlayer](https://intlayer.org/pl/blog/i18next-vs-intlayer), same 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)
+- [Is i18next outdated?](https://intlayer.org/pl/blog/is-i18next-outdated)
+
+Dokumentacja referencyjna:
+
+- Compat adapters: [i18next](https://intlayer.org/pl/doc/compatibility/i18next), [react-i18next](https://intlayer.org/pl/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/pl/doc/compatibility/next-i18next)
+- Migration guides: [i18next](https://intlayer.org/pl/doc/migration/i18next), [react-i18next](https://intlayer.org/pl/doc/migration/react-i18next), [next-i18next](https://intlayer.org/pl/doc/migration/next-i18next)
+- [Next.js benchmark report](https://intlayer.org/pl/doc/benchmark/nextjs) and [TanStack Start benchmark report](https://intlayer.org/pl/doc/benchmark/tanstack)
+- [Bundle optimization](https://intlayer.org/pl/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/pl/doc/compiler)
+- [Visual Editor](https://intlayer.org/pl/doc/concept/editor), [CMS](https://intlayer.org/pl/doc/concept/cms) and [AI translation](https://intlayer.org/pl/doc/concept/auto-fill)
 
 ## Podsumowanie
 

package/blog/pl/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark i porównanie 2026"
 description: "react-i18next i next-i18next w porównaniu z Intlayer na Next.js i TanStack Start. Rozmiar bundle, wycieki treści, czas reakcji przy zmianie języka i doświadczenie programisty."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark internacjonalizacji (i18n) w React i Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` to najczęściej używany framework i18n w ekosystemie JavaScript. Poprzez `react-i18next` i `next-i18next` zasila ogromną część aplikacji React i Next.js. Intlayer to nowoczesna alternatywa oparta na kompilatorze i izolacji na poziomie komponentów.
 
 Ten artykuł porównuje oba rozwiązania na podstawie twardych pomiarów, a nie list funkcji. Liczby pochodzą z [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), otwartoźródłowego pakietu testów, który buduje tę samą aplikację z każdą biblioteką i rejestruje, co przeglądarka faktycznie pobiera.
@@ -99,6 +101,10 @@ Dla każdego buildu rejestrowane są wskaźniki:
 
 ### Wyniki w Next.js (`next-i18next`)
 
+Wybierz metryki i biblioteki, które Cię interesują:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Biblioteka                        | Strategia      | Lib size (gz) | Page JS avg (gz) | Wyciek języka | Wyciek strony | Komponent śr. (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 |
@@ -119,6 +125,15 @@ Dla każdego buildu rejestrowane są wskaźniki:
 - **Wielkość komponentów**: Komponent wywołujący `useTranslation()` kompiluje się do 26-79 KB; ten sam komponent z `useIntlayer()` zajmuje zaledwie 6.9 KB.
 - **Czas hydratacji**: w konfiguracji `dynamic` wzrasta do 27.7 ms, ponieważ instancja i18next musi zainicjalizować się i przetworzyć backend po stronie klienta, zanim React ukończy hydratację.
 
+<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 (`react-i18next`)
 
 Ta sama aplikacja na TanStack Start z czystym `react-i18next`, co eliminuje specyfikę Next.js z testu porównawczego.
@@ -141,8 +156,19 @@ Ta sama aplikacja na TanStack Start z czystym `react-i18next`, co eliminuje spec
 - Intlayer w trybie `static` wykazuje **0% wycieku stron** już na starcie, ponieważ pakowane są tylko te słowniki, które zostały zaimportowane przez komponenty danej strony. Włączenie `importMode: 'dynamic'` eliminuje także wyciek języka.
 - **Rozmiar komponentu**: 24-27 KB w `react-i18next` wobec 6-8 KB w Intlayer. `useTranslation()` wiąże każdy komponent z globalną instancją i18next.
 
+<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? Globalna instancja vs skompilowane 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)
+
 `i18next` powstał w 2012 roku jako runtime: pojedyncza globalna instancja trzyma repozytorium zasobów, wtyczki je rozszerzają, a `t()` szuka kluczy w czasie renderowania. Daje to wszechstronność, ale generuje narzut:
 
 ```bash
@@ -166,7 +192,13 @@ Ta sama aplikacja na TanStack Start z czystym `react-i18next`, co eliminuje spec
                 └── page.tsx     # musi wiedzieć, że potrzebuje ["common", "about"]
 ```
 
-Instancja nie wie z góry, o jakie klucze zapyta komponent, dlatego trzyma wszystkie przestrzenie nazw przekazane do załadowania. Optymalizacja wymaga, aby **programista** dzielił katalogi, wyliczał przestrzenie dla każdej strony i na bieżąco korygował te powiązania. Jak zauważono w [notatkach z benchmarku](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Utrzymanie typowania i dokładna wiedza o tym, który namespace dołączyć do danej strony, to koszmar".
+Instancja nie wie z góry, o jakie klucze zapyta komponent, dlatego trzyma wszystkie przestrzenie nazw przekazane do załadowania. Optymalizacja wymaga, aby **programista** dzielił katalogi, wyliczał przestrzenie dla każdej strony i na bieżąco korygował te powiązania.
+
+Koszt rośnie w dwóch wymiarach 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)
+
+Jak zauważono w [notatkach z benchmarku](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Utrzymanie typowania i dokładna wiedza o tym, który namespace dołączyć do danej strony, to koszmar".
 
 Intlayer eliminuje instancję globalną. Treści deklarowane są tuż obok komponentu, a kompilator rozwiązuje graf zależności podczas budowania:
 
@@ -193,7 +225,8 @@ Intlayer eliminuje instancję globalną. Treści deklarowane są tuż obok kompo
 
 ### Konfiguracja
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Do tego dochodzi kliencki `I18nProvider`, `generateStaticParams` oraz deklarowanie tablicy `namespaces` na każdej podstronie.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Komponent kliencki
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > Strona renderująca ten komponent musi załadować namespace `about`, a `t("counter.label")` pozostaje zwykłym stringiem bez rozszerzenia `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 Pola `label` oraz `increment` posiadają ścisłe typowanie; każda literówka natychmiast generuje błąd TypeScript, a brak tłumaczenia dla języka francuskiego zablokuje proces budowania.
 
+</Tab>
+</Tabs>
+
 ### Synchroniczny komponent serwerowy (RSC)
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 Na poziomie strony wywołuje się `i18n.getFixedT(locale, "about")`, po czym przekazuje `t` i `locale` w dół za pomocą props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Zachowaj API i18next, zyskaj wydajność Intlayer
 
 Nie musisz przepisywać istniejących komponentów, aby cieszyć się zyskami z powyższego benchmarku. Adaptery `@intlayer/i18next`, `@intlayer/react-i18next` i `@intlayer/next-i18next` działają bezpośrednio jako zamienniki typu drop-in: wywołania `useTranslation`, `t()`, `<Trans>`, obsługa liczb mnogich i kontekstów działają bez zmian, serwowane przez zoptymalizowane słowniki Intlayer.
@@ -415,18 +462,85 @@ Zobacz przewodniki migracji: [i18next](https://intlayer.org/pl/doc/migration/i18
 
 ## Kiedy wybrać dane rozwiązanie?
 
-- **Wybierz i18next**: jeśli bezwzględnie wymagasz jego ekosystemu wtyczek (specyficzne detektory, niestandardowe backendy, ICU, Locize), lokalizujesz treści także poza środowiskiem React (serwisy Node, czysty JS, inne frameworki), zespół ma już opanowane narzędzia lub zewnętrzna platforma tłumaczeniowa wymaga struktury `locales/{lng}/{ns}.json`. Zadbaj o czas na ręczną organizację przestrzeni nazw i mapowanie tras.
-- **Wybierz Intlayer**: jeśli zależy Ci na **treściach przypisanych bezpośrednio do komponentów**, **ścisłym bezpieczeństwie TypeScript**, **wykrywaniu brakujących kluczy podczas budowania**, **automatycznym tree-shakingu i leniwym ładowaniu bez wysiłku**, natychmiastowej zmianie języka, synchronicznych komponentach serwerowych i zintegrowanych narzędziach (Edytor Wizualny, CMS, tłumaczenie AI, serwer MCP). Znakomity wybór dla aplikacji modułowych i systemów projektowych (Design Systems).
-- **Wybierz adaptery `@intlayer/*-i18next`**: jeśli posiadasz istniejący kod oparty na i18next i chcesz natychmiast zredukować wagę paczki oraz przyspieszyć działanie bez konieczności refaktoryzacji.
+<AccordionGroup>
+<Accordion header="Wybierz i18next">
+
+Jeśli bezwzględnie wymagasz jego ekosystemu wtyczek (specyficzne detektory, niestandardowe backendy, ICU, Locize), lokalizujesz treści także poza środowiskiem React (serwisy Node, czysty JS, inne frameworki), zespół ma już opanowane narzędzia lub zewnętrzna platforma tłumaczeniowa wymaga struktury `locales/{lng}/{ns}.json`. Zadbaj o czas na ręczną organizację przestrzeni nazw i mapowanie tras.
+
+</Accordion>
+<Accordion header="Wybierz Intlayer">
+
+Zależy Ci na **treściach przypisanych do komponentów**, **ścisłym TypeScript**, **błędach brakujących kluczy w czasie kompilacji**, **tree-shakingu i leniwym ładowaniu bez wysiłku**, natychmiastowej zmianie języka, synchronicznych komponentach serwerowych i wbudowanych narzędziach edycyjnych ([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 w dużych, modułowych bazach kodu i systemach projektowych.
+
+</Accordion>
+<Accordion header="Wybierz adaptery @intlayer/*-i18next">
+
+Korzystasz już z i18next i chcesz uzyskać korzyści w wielkości paczki i reaktywności bez przepisywania komponentów. Twoje pliki `locales/{lng}/{ns}.json` pozostają źródłem prawdy. Zmierzone ramię w ramię w [i18next vs @intlayer/i18next](https://intlayer.org/pl/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Dlaczego i18next jest o wiele cięższy niż inne biblioteki?">
+
+Został zaprojektowany jako środowisko uruchomieniowe niezależne od frameworka: globalna instancja, potok wtyczek, magazyn zasobów, mechanizm rozwiązywania kluczy. Ta elastyczność jest kompilowana w każdej paczce. Pusty komponent importujący jedynie bibliotekę waży **19.7 KB gzip** z `next-i18next` wobec **5.5 KB** z `next-intlayer`, a koszt ten ponoszony jest na każdej stronie, niezależnie od objętości treści.
+
+</Question>
+
+<Question title="Czy leniwe ładowanie z backendem rozwiązuje ten problem?">
+
+Rozwiązuje problem bajtów, ale nie opóźnień. Przejście na `i18next-resources-to-backend` oszczędza ~49 KB na stronę, ale dodaje zapytanie sieciowe przy zmianie języka: **123 ms** w konfiguracji `dynamic` oraz **185 ms** w `scoped-static`, w porównaniu do **3-4 ms** w Intlayer. Hydratacja wzrasta do 27.7 ms, ponieważ instancja odpytuje backend przed hydratacją Reacta.
+
+</Question>
+
+<Question title="Czy mogę osiągnąć 0% wycieku z i18next?">
+
+Tak, z konfiguracją `scoped-dynamic`: jeden namespace na trasę, backend zasobów i ręcznie utrzymywana mapa stron do przestrzeni nazw. Daje to 163.4 KB na stronę w Next.js, co nadal jest o **+22 KB** więcej niż 141.3 KB w Intlayer, który nie wymagał żadnej konfiguracji. Zobacz [optymalizację paczki](https://intlayer.org/pl/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Czy muszę przepisywać komponenty, aby przeprowadzić migrację?">
+
+Nie. `@intlayer/i18next`, `@intlayer/react-i18next` oraz `@intlayer/next-i18next` zachowują `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, formy mnogie `_one` / `_other`, sufiksy kontekstowe i `returnObjects`. Wystarczy jedna linijka wtyczki w `next.config.ts` lub `vite.config.ts`. Krok po kroku w [przewodniku migracji next-i18next](https://intlayer.org/pl/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Co dzieje się z moimi wtyczkami do i18next?">
+
+Backendy i detektory języka są akceptowane, ale pozostają bezczynne: w czasie wykonywania nie ma już nic do załadowania ani wykrycia. Detekcja języka staje się konfiguracją routingu Intlayer (prefiks URL, ciasteczko, nagłówek). Jeśli aplikacja pobiera tłumaczenia z CMS podczas żądania, użyj [Intlayer CMS](https://intlayer.org/pl/doc/concept/cms) lub poleceń `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Powiązane porównania
 
-- [next-intl vs Intlayer](https://intlayer.org/pl/blog/next-intl-vs-intlayer) (ten sam benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/pl/blog/lingui-vs-intlayer) (ten sam benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-benchmark) (ten sam benchmark)
+Ten sam benchmark, inne biblioteki:
+
+- [next-intl vs Intlayer](https://intlayer.org/pl/blog/next-intl-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)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/pl/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Więcej o i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/pl/blog/i18next-vs-intlayer-i18next), porównanie adapterów na tej samej aplikacji
 - [Czy i18next jest przestarzały?](https://intlayer.org/pl/blog/is-i18next-outdated)
+- [Używanie Intlayer z i18next](https://intlayer.org/pl/blog/intlayer-with-i18next) oraz [z react-i18next](https://intlayer.org/pl/blog/intlayer-with-react-i18next)
+- [Jak zinternacjonalizować aplikację Next.js za pomocą next-i18next](https://intlayer.org/pl/blog/nextjs-internationalization-using-next-i18next)
+
+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)
+- Adaptery kompatybilności: [i18next](https://intlayer.org/pl/doc/compatibility/i18next), [react-i18next](https://intlayer.org/pl/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/pl/doc/compatibility/next-i18next)
+- Przewodniki migracji: [i18next](https://intlayer.org/pl/doc/migration/i18next), [react-i18next](https://intlayer.org/pl/doc/migration/react-i18next), [next-i18next](https://intlayer.org/pl/doc/migration/next-i18next)
+- [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