@intlayer/docs 8.12.5-canary.0 → 9.0.0-canary.11

package/docs/pl/benchmark/___nextjs.md

@@ -0,0 +1,198 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Najlepsze rozwiązanie i18n dla Next.js w 2026 - Raport benchmarku
+description: Porównaj biblioteki internacjonalizacji Next.js takie jak next-intl, next-i18next i Intlayer. Szczegółowy raport wydajności dotyczący rozmiaru bundle, wycieków i reaktywności.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - nextjs
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - nextjs
+author:
+  name: Aymeric PINEAU
+  github: aymericzip
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "Init benchmark"
+---
+
+# Raport benchmarku bibliotek i18n dla Next.js w 2026
+
+Ta strona jest raportem benchmarku dla rozwiązań i18n dla Next.js.
+
+## Spis treści
+
+<Toc/>
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="nextjs" vertical/>
+
+## Referencja wyników:
+
+<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;"
+/>
+
+> [Patrz kompletne dane benchmarku](https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md)
+
+## Wstęp
+
+Rozwiązania internacjonalizacyjne są bibliotekami o dużym wpływie na aplikację. Głównym ryzykiem jest załadowanie zawartości wszystkich stron i wszystkich języków dla pojedynczej przeglądanej strony.
+
+Wraz z rozwojem aplikacji rozmiar bundle ewoluuje wykładniczo, co może znacząco spowolnić wydajność aplikacji.
+
+Jako przykład, dla najgorszych uczniów, po internacjonalizacji strona może skończyć się prawie 4 razy bardziej objętościowa.
+
+Innym wpływem rozwiązań internacjonalizacyjnych jest spowolnienie rozwoju. Transformowanie komponentów i organizowanie zawartości we wszystkich językach jest czasochłonne.
+
+Problem jest złożony, wiele rozwiązań pojawiło się aby rozwiązać problem i18n. Niektóre rozwiązania skupiają się na DX, inne na wydajności, inne na skalowalności, itp.
+
+Intlayer jest rozwiązaniem próbującym optymalizować wszystkie te aspekty.
+
+## Testuj swoją aplikację
+
+Aby wykryć te problemy, mam skonfigurowany bezpłatny skaner, który możesz przetestować [tutaj](https://intlayer.org/i18n-seo-scanner).
+
+## Problematyka
+
+Istnieją dwa główne aspekty aby ograniczyć wpływ wielojęzycznej aplikacji na bundle aplikacji:
+
+- Podziel swoje JSON (lub zawartość) na wiele plików / zmiennych / namespaces aby umożliwić bundlerowi tree-shake zawartość nieużywaną na stronie
+- Dynamicznie załaduj zawartość strony tylko w języku strony
+
+Zrozumienie ograniczeń technicznych dla tych podejść:
+
+**Dynamiczne ładowanie**
+
+Nawet jeśli deklarujesz swoje trasy jako `[locale]/page.tsx`, czy to z Webpack czy Turbopack, i mimo że `getStaticParams` jest zdefiniowany, bundler nie traktuje `locale` jako zmiennej statycznej. To oznacza, że bundler załaduje zawartość wszystkich języków dla każdej strony. Jedyną opcją aby ograniczyć ten problem jest załadowanie zawartości poprzez dynamiczny import (np. `import('./locales/${locale}.json')`).
+
+To co się dzieje podczas budowania, to że Next.js generuje plik JS (bundle) dla każdego języka (np. `./locales_fr_12345.js`). Następnie po wysłaniu witryny do klienta, gdy strona jest wykonywana, to przeglądarka zmieni się w wykonanie dodatkowego żądania HTTP, żądając wymaganego pliku JS (np. `./locales_fr_12345.js`).
+
+> Innym sposobem na odpowiedź na ten sam problem jest użycie metody `fetch()` aby dynamicznie żądać pliku JSON. To jest przypadek `Tolgee` poprzez umieszczenie JSON w folderze `/public` lub `next-translate`, które opierają się na funkcji `getStaticProps` aby załadować zawartość. Ale przepływ pozostaje taki sam, przeglądarka wykona dodatkowe żądanie HTTP aby załadować asset.
+
+**Podział zawartości**
+
+Jeśli używasz składni takiej jak `const t = useTranslation()` + `t('my-object.my-sub-object.my-key')`, JSON musi być w całości załadowany do bundle, aby następnie być parsowany przez bibliotekę aby wydedukować wartość klucza. Ale to oznacza, że duża część zawartości będzie załadowana w bundle, choć nieużywana na stronie.
+
+Aby odpowiedzieć na ten problem, niektóre biblioteki sugerują deklarowanie ręcznie dla każdej strony, które namespaces powinny być załadowane. To jest przypadek `next-i18next`, `next-intl`, `lingui`, `next-translate`, `next-international`.
+
+W porównaniu, `Paraglide` proponuje dodanie dodatkowego kroku, przed budowaniem aby transformować JSON w płaską zmienną, taką jak `const en_my_var = () => 'my value'`. To pozwala (teoretycznie) tree-shake zawartość nieużywaną na stronie. Ale zobaczymy, ta metoda nie jest bez kompromisów.
+
+Na koniec, `Intlayer` proponuje optymalizację w czasie budowania, pozwalającą na zastąpienie użycia `useIntlayer('my-key')` i bezpośrednie dołączenie odpowiadającej zawartości.
+
+## Metodologia
+
+Dla tego benchmarku porównaliśmy następujące biblioteki:
+
+- `Base App` (No i18n library)
+- `next-intlayer` (v8.7.5)
+- `next-i18next` (v16.0.5)
+- `next-intl` (v4.9.1)
+- `@lingui/core` (v5.3.0)
+- `next-translate` (v3.1.2)
+- `next-international` (v1.3.1)
+- `@inlang/paraglide-js` (v2.15.1)
+- `tolgee` (v7.0.0)
+- `@lingo.dev/compiler` (v0.4.0)
+- `wuchale` (v0.22.11)
+- `gt-next` (v6.16.5)
+
+Użyłem frameworka `Next.js` w wersji `16.2.4` z trybem `app router`.
+
+Stworzyłem wielojęzyczną aplikację z **10 stronami**, w **10 językach**.
+
+I porównałem **4 strategie ładowania**:
+
+| Strategi              | Bez Namespaces (Global)                        | Z Namespaces (Scoped)                                                |
+| :--------------------- | :------------------------------------------------ | :---------------------------------------------------------------------- |
+| **Ładowanie Static**  | **Static** : Wszystko w pamięci przy uruchomieniu.        | **Scoped Static** : Podzielone na namespace, wszystko załadowane przy uruchomieniu.   |
+| **Ładowanie Dynamic** | **Dynamic** : Ładowanie na żądanie przez lokalę. | **Scoped Dynamic** : Ładowanie granularne przez namespace i lokalę. |
+
+## Streszczenie strategii
+
+- **Static** : Proste, bez opóźnień sieciowych po załadowaniu początkowym. Wadą : wysoki rozmiar bundle.
+- **Dynamic** : Zmniejsza początkowy waga (lazy-loading). Idealne dla dużej liczby lokali.
+- **Scoped Static** : Pozwala na czystą organizację kodu (logiczne separacja) bez dodatkowego kosztu złożonych żądań sieciowych.
+- **Scoped Dynamic** : Optymalne podejście do _Code Splitting_ i wydajności. Minimalizuje obciążenie pamięci ładując tylko niezbędne dla bieżącego widoku i aktywnej lokali.
+
+## Szczegóły wyników
+
+### 1 - Rozwiązania do uniknięcia
+
+Pewne rozwiązania takie jak `gt-next` lub `lingo.dev` są wyraźnie rozwiązaniami do uniknięcia. Te rozwiązania integrują kombo blokady dostawcy + zatrucie bazy kodu. I górą wszystkiego jest to, że pomimo wielu godzin próby ich implementacji, nigdy mi się nie udało je uruchomić. Zarówno dla Tanstack start jak i Next.js.
+
+Lista napotkaných problemów:
+
+**(General Translation)** (`gt-next@6.16.5`):
+
+- Dla aplikacji 110kb, `gt-react` dodaje do niej ponad 440kb dodatkowego.
+- `Quota Exceeded, please upgrade your plan`, od pierwszego budowania z rozwiązaniem general translation.
+- Tłumaczenia nie są renderowane; otrzymuję błąd `Error: <T> used on the client-side outside of <GTProvider>`, co wydaje się być błędem w bibliotece.
+- Podczas implementacji **gt-tanstack-start-react**, natknąłem się na [problem](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) z biblioteką: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, co powodowało, że aplikacja się łamała. Po zgłoszeniu tego problemu, opiekun naprawił go w ciągu 24 godzin.
+- Biblioteka blokuje statyczne renderowanie stron Next.js.
+
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
+
+- Przywłaszczony limit AI, całkowicie blokujący budowanie. Jest wtedy niemożliwe pushowanie do produkcji bez płacenia.
+- Kompilator brakował prawie 40% przetłumaczonej zawartości. Musiałem przepisać wszystkie `.map` na płaskie bloki komponentów aby to zadziałało.
+- Ich CLI jest bugowy i zwykł resetować plik konfiguracyjny bez powodu.
+- Przy budowaniu, całkowicie wymazywał wygenerowane JSON gdy była dodana nowa zawartość. W wyniku, masz tylko 3 klucze usuwające >300 istniejących kluczy.
+
+### 2 - Rozwiązania eksperymentalne
+
+**(Wuchale)** (`wuchale@0.22.11`):
+
+Ideą `Wuchale` jest interesująca, ale nie jest jeszcze na etapie żywotnego rozwiązania. Napotkałem problemy reaktywności z biblioteką i musiałem wymusić ponowne renderowanie dostawcy aby uruchomić aplikację. Dokumentacja jest również stosunkowo niejasna, utrudniając przyjęcie.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.15.1`):
+
+`Paraglide` jest rozwiązaniem oferującym innowacyjne i dobrze przemyślane podejście. Niemniej jednak, w kontekście mojego benchmarku, widać, że tree-shaking, który sprzedają ich firma, nie działa ani dla mojej implementacji Next.js, ani dla Tanstack start. Przepływ i DX jest również bardziej złożony niż inne rozwiązania. I osobiście nie lubię faktu, że muszę przeregenerować pliki JS przed każdym pushowaniem, tworząc ciągłe ryzyko konfliktów między deweloperami poprzez ich PR. Wreszcie, rozwiązanie wydaje się bardziej skupiać na Vite niż na Next.js.
+
+### 3 - Rozwiązania 'ok'
+
+**(Tolgee)** (`tolgee@7.0.0`):
+
+`Tolgee` jest rozwiązaniem odpowiadającym różnym problemom wspominanym wcześniej. Ale znalazłem przyjęcie rozwiązania bardziej złożonym niż inne rozwiązania proponujące podobne podejścia. Rozwiązanie nie proponuje typesafety. To czyni detektywę brakujących kluczy przy kompilacji znacznie bardziej złożoną. Musiałem owrappować funkcje Tolgee własnymi aby dodać detektywę brakujących kluczy.
+
+**(Next Intl)** (`next-intl@4.9.1`):
+
+`next-intl` jest najmodniejszym rozwiązaniem i również najbardziej wypromowanym przez agentów AI, ale moim zdaniem słusznie. Get-started jest dość prosty. Ale w praktyce, proces optymalizacji aby ograniczyć wyciek jest dość złożony. Similarly, współistnienie dynamicznego ładowania + namespacing + typescript types znacznie spowalnia rozwój. Ponadto biblioteka jest dość ciężka (~13kb dla `NextIntlClientProvider` + `useTranslations` hook, co jest >2x bardziej ciężkie niż `next-intlayer`). **next-intl** zwykł blokować statyczne renderowanie stron Next.js. Zapewnia funkcję naprawy o nazwie `setRequestLocale()`. Ten problem wydaje się został częściowo rozwiązany dla scentralizowanej zawartości takich jak `en.json` / `fr.json` / itp. Ale rozwiązanie nadal blokuje statyczne renderowanie gdy zawartość jest ograniczona do namespaces takimi jak `en/shared.json` / `fr/shared.json` / `es/shared.json` / itp.
+
+**(Next I18next)** (`next-i18next@16.0.5`):
+
+`next-i18next` jest prawdopodobnie najpopularniejszym rozwiązaniem faktem, że to była pierwsza rozwiązanie, które pojawiło się aby odpowiedzieć na potrzeby internacjonalizacji aplikacji Javascript. To rozwiązanie również proponuje szeroki zestaw pluginów społeczności aby odpowiedzieć na pewne problemy. Niemniej jednak, to rozwiązanie pokazuje dokładnie takie same czarne punkty co `next-intl`. Ponadto biblioteka jest szczególnie ciężka (~18kb dla `I18nProvider` + `useTranslation` hook, co jest 3x bardziej ciężkie niż `next-intlayer`).
+Ponadto formaty wiadomości różnią się między bibliotekami. `next-intl` używa formatu ICU MessageFormat, podczas gdy `i18next` używa własnego formatu.
+
+**(Next International)** (`next-international@1.3.1`):
+
+`next-international` jest rozwiązaniem odpowiadającym również różnym problemom wspominanym wcześniej, ale nie proponuje znaczącej różnicy w stosunku do `next-intl` lub nawet `next-i18next`. Rozwiązanie zawiera funkcję `scopedT()`, która pozwala na tłumaczenie zawartości w określonym namespace. Niemniej jednak, użycie tej funkcji nie ma czysto i po prostu żadnego wpływu na rozmiar bundle.
+
+**(Lingui)** (`@lingui/core@5.3.0`):
+
+`Lingui` jest rozwiązaniem dla którego słyszałem wiele dobrego. Ale osobiście znalazłem przepływ bazujący na wykonaniu poleceń `lingui extract` / `lingui compile` bardziej złożonym niż inne podejścia, bez znaczącej przewagi. Zauważyłem również brak harmonii między składniami które noszą AI do zamieszania. (np. `t()`, `t''`, `i18n.t()`, `<Trans>`)
+
+### 4 - Moje rekomendacje
+
+**(Next Translate)** (`next-translate@3.1.2`):
+
+`next-translate` jest tutaj moją główną rekomendacją dla tych, którzy lubią użycie funkcji `t()` do tłumaczenia zawartości. To rozwiązanie oferuje eleganckie podejście poprzez `next-transalte-plugin`, optymalizując ładowanie namespaces poprzez `getStaticProps` poprzez loader Webpack / Turbopack. To również najprostsze rozwiązanie ze wszystkich (~2.5kb tylko). Do namespacing, wybieranie namespaces na poziomie konfiguracji jest również dobrze przemyślane: możesz definiować namespaces dla każdej strony lub trasy. Czyni to utrzymanie znacznie łatwiejszym niż główne alternatywy, takie jako **next-intl** lub **next-i18next**. Niemniej jednak zauważyłem, że w wersji `3.1.2`, budowanie w statycznym renderowaniu nie działa. Next.js fallback wtedy na dynamiczne renderowanie.
+
+**(Intlayer)** (`next-intlayer@8.7.5`):
+
+Na koniec, nie będę osobiście sądził `next-intlayer`, z powodu obiektywności, biorąc pod uwagę, że jest to moje własne rozwiązanie.
+
+### Notatka personalna
+
+Ta notatka jest personalna i nie ma wpływu na wyniki benchmarku. Niemniej jednak, w świecie i18n widzimy wyraźny konsensus, którym jest użycie składni takiej jak `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` do tłumaczenia zawartości.
+Niemniej jednak, w kontekście aplikacji React, iniekcja funkcji w formie `ReactNode` jest moim zdaniem antywzorem. Ponadto, to wprowadza dodatkową złożoność, którą można uniknąć, i overhead wykonywania JavaScript (chociaż niezauważalny).

package/docs/pl/benchmark/___solid.md

@@ -0,0 +1,36 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Najlepsze rozwiązanie i18n dla Solid w 2026 - Raport benchmarku
+description: Porównaj biblioteki internacjonalizacji Solid. Szczegółowy raport wydajności dotyczący rozmiaru bundle, wycieków i reaktywności.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author:
+  name: Aymeric PINEAU
+  github: aymericzip
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "Init benchmark"
+---
+
+# Raport benchmarku bibliotek i18n dla Solid w 2026
+
+Ta strona jest raportem benchmarku dla rozwiązań i18n dla Solid.
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="solid" vertical/>
+
+## Referencja wyników
+
+> [Patrz kompletne dane benchmarku](https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-solid.md)

package/docs/pl/benchmark/___svelte.md

@@ -0,0 +1,36 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Najlepsze rozwiązanie i18n dla Svelte w 2026 - Raport benchmarku
+description: Porównaj biblioteki internacjonalizacji Svelte. Szczegółowy raport wydajności dotyczący rozmiaru bundle, wycieków i reaktywności.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author:
+  name: Aymeric PINEAU
+  github: aymericzip
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "Init benchmark"
+---
+
+# Raport benchmarku bibliotek i18n dla Svelte w 2026
+
+Ta strona jest raportem benchmarku dla rozwiązań i18n dla Svelte.
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="svelte" vertical/>
+
+## Referencja wyników
+
+> [Patrz kompletne dane benchmarku](https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-svelte.md)

package/docs/pl/benchmark/___tanstack.md

@@ -0,0 +1,36 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Najlepsze rozwiązanie i18n dla TanStack Start w 2026 - Raport benchmarku
+description: Porównaj biblioteki internacjonalizacji TanStack Start takie jak react-i18next, use-intl i Intlayer. Szczegółowy raport wydajności dotyczący rozmiaru bundle, wycieków i reaktywności.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - tanstack
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - tanstack
+author:
+  name: Aymeric PINEAU
+  github: aymericzip
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "Init benchmark"
+---
+
+# Raport benchmarku bibliotek i18n dla TanStack Start w 2026
+
+Ta strona jest raportem benchmarku dla rozwiązań i18n dla TanStack Start.
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+## Referencja wyników
+
+> [Patrz kompletne dane benchmarku](https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md)

package/docs/pl/benchmark/___vue.md

@@ -0,0 +1,36 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Najlepsze rozwiązanie i18n dla Vue w 2026 - Raport benchmarku
+description: Porównaj biblioteki internacjonalizacji Vue. Szczegółowy raport wydajności dotyczący rozmiaru bundle, wycieków i reaktywności.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author:
+  name: Aymeric PINEAU
+  github: aymericzip
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "Init benchmark"
+---
+
+# Raport benchmarku bibliotek i18n dla Vue w 2026
+
+Ta strona jest raportem benchmarku dla rozwiązań i18n dla Vue.
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="vue" vertical/>
+
+## Referencja wyników
+
+> [Patrz kompletne dane benchmarku](https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vue.md)

package/docs/pl/benchmark/solid.md

@@ -118,6 +118,28 @@ Porównaliśmy **cztery strategie ładowania**:
 - **Scoped static**: Utrzymuje porządek w kodzie (logiczna separacja) bez skomplikowanych dodatkowych zapytań sieciowych.
 - **Scoped dynamic**: Najlepsze podejście dla _code splittingu_ i wydajności. Minimalizuje zużycie pamięci, ładując tylko to, czego potrzebuje bieżący widok i aktywna lokalizacja.
 
+### Co mierzyłem:
+
+Uruchomiłem tę samą wielojęzyczną aplikację w prawdziwej przeglądarce dla każdego stosu, a następnie zapisałem, co faktycznie pojawiło się na sieci i jak długo to trwało. Rozmiary są podawane **po normalnej kompresji internetowej**, ponieważ jest to bliższe temu, co ludzie pobierają, niż surowe liczby źródła.
+
+- **Rozmiar biblioteki internacjonalizacji**: Po bundlingu, tree-shakingu i minifikacji, rozmiar biblioteki i18n to rozmiar providerów + kodu hooks/primitives w pustym komponencie. Nie obejmuje ładowania plików tłumaczeń. Odpowiada na pytanie, jak kosztowna jest biblioteka zanim twoja zawartość wejdzie do gry.
+
+- **JavaScript na stronę**: Dla każdej trasy benchmarku, ile skryptu przeglądarka pobiera dla tej wizyty, uśrednione na stronach w zestawie (i na lokalizacjach, gdzie raport je łączy). Ciężkie strony to wolne strony.
+
+- **Wyciek z innych lokalizacji**: To zawartość tej samej strony, ale w innym języku, która byłaby załadowana przez pomyłkę na audytowanej stronie. Ta zawartość jest zbędna i powinna być unikana. (np. zawartość strony `/fr/about` w bundlu strony `/en/about`)
+
+- **Wyciek z innych tras**: Ten sam pomysł dla **innych ekranów** w aplikacji: czy ich kopia jedzie razem, gdy otworzysz tylko jedną stronę. (np. zawartość strony `/en/about` w bundlu strony `/en/contact`). Wysoki wynik sugeruje słabe dzielenie lub zbyt szerokie bundle'i.
+
+- **Średni rozmiar bundle'u komponentu**: Typowe elementy UI są mierzone **jeden po drugim** zamiast ukrywania się wewnątrz jednej gigantycznej liczby aplikacji. Pokazuje, czy internacjonalizacja po cichu rozszerza zwykłe komponenty. Na przykład, jeśli twój komponent zostanie ponownie renderowany, załaduje wszystkie te dane z pamięci. Przywiązanie gigantycznego JSON'a do dowolnego komponentu jest jak podłączenie dużego magazynu nieużywanych danych, który spowolni wydajność twoich komponentów.
+
+- **Responsywność przełącznika języka**: Przełączam język przy użyciu kontrolki aplikacji i mierzę, jak długo trwa, zanim strona wyraźnie się zmieni, co odwiedzający zauważy, a nie laboratoryjny mikrokrok.
+
+- **Praca renderowania po zmianie języka**: Węższe uzupełnienie: ile wysiłku interfejsowi zajęło przepainting dla nowego języka po tym, jak przełączenie jest w locie. Przydatne, gdy „odczuty" czas i koszt framework'u się rozchodzą.
+
+- **Czas początkowego załadowania strony**: Od nawigacji do przeglądarki traktującej stronę jako całkowicie załadowaną dla scenariuszy, które testowałem. Dobry do porównywania zimnych startów.
+
+- **Czas hydratacji**: Gdy aplikacja to ujawnia, jak długo klient spędza na zamienianiu HTML serwera na coś, na co możesz faktycznie kliknąć. Kreska w tabelach oznacza, że implementacja nie dostarczyła wiarygodnej liczby hydratacji w tym benchmarku.
+
 ## Gwiazdki na GitHubie
 
 Gwiazdki na GitHubie są silnym wskaźnikiem popularności projektu, zaufania społeczności i długoterminowego znaczenia. Choć nie są bezpośrednią miarą jakości technicznej, odzwierciedlają, ilu programistów uważa projekt za przydatny, śledzi jego postępy i prawdopodobnie go przyjmie. Przy szacowaniu wartości projektu gwiazdki pomagają porównać zainteresowanie alternatywami i dostarczają wglądu w rozwój ekosystemu.

package/docs/pl/benchmark/svelte.md

@@ -116,6 +116,28 @@ Porównaliśmy **cztery strategie ładowania**:
 - **Scoped static**: Utrzymuje porządek w kodzie (logiczna separacja) bez skomplikowanych dodatkowych zapytań sieciowych.
 - **Scoped dynamic**: Najlepsze podejście dla _code splittingu_ i wydajności. Minimalizuje zużycie pamięci, ładując tylko to, czego potrzebuje bieżący widok i aktywna lokalizacja.
 
+### Co mierzyłem:
+
+Uruchomiłem tę samą wielojęzyczną aplikację w prawdziwej przeglądarce dla każdego stosu, a następnie zapisałem, co faktycznie pojawiło się na sieci i ile czasu to zajęło. Rozmiary są podawane **po normalnej kompresji internetowej**, ponieważ jest to bliższe temu, co ludzie pobierają, niż surowe liczby źródłowe.
+
+- **Rozmiar biblioteki internacjonalizacji**: Po bundlingu, tree-shakingu i minifikacji rozmiar biblioteki i18n to rozmiar kodu dostawców + magazynów w pustym komponencie. Nie obejmuje wczytywania plików tłumaczeń. Odpowiada na pytanie, jak kosztowna jest biblioteka, zanim Twoja zawartość wejdzie na scenę.
+
+- **JavaScript na stronie**: Dla każdej trasy benchmarku, ile skryptu przeglądarka pobiera dla tej wizyty, uśrednione dla stron w zestawie (i dla lokalizacji, gdzie raport je łączy). Ciężkie strony są wolnymi stronami.
+
+- **Wyciek z innych lokalizacji**: To zawartość tej samej strony, ale w innym języku, która byłaby załadowana przez pomyłkę na auditowanej stronie. Ta zawartość jest niepotrzebna i powinna być unikana. (np. zawartość strony `/fr/about` w pakiecie strony `/en/about`)
+
+- **Wyciek z innych tras**: Ten sam pomysł dla **innych ekranów** w aplikacji: czy ich tekst towarzyszy ci, gdy otwierasz tylko jedną stronę. (np. zawartość strony `/en/about` w pakiecie strony `/en/contact`). Wysoki wynik sugeruje słabe dzielenie lub zbyt szerokie pakiety.
+
+- **Średni rozmiar pakietu komponentu**: Popularne elementy interfejsu użytkownika są mierzone **jeden na raz** zamiast ukrywania się wewnątrz jednej gigantycznej liczby aplikacji. Pokazuje, czy internacjonalizacja po cichu inflacyjnie wpływa na codzienne komponenty. Na przykład, jeśli twój komponent się renderuje, załaduje wszystkie te dane z pamięci. Dołączenie gigantycznego JSON-a do dowolnego komponentu to jak podłączenie dużego magazynu nieużywanych danych, który spowolni wydajność twoich komponentów.
+
+- **Responsywność przełącznika języka**: Przełączam język za pomocą własnej kontroli aplikacji i mierzę, ile czasu upłynie, zanim strona wyraźnie się przełączy, co odwiedzający by zauważył, a nie laboratoryjny mikro-krok.
+
+- **Praca renderowania po zmianie języka**: Bardziej zawężone uzupełnienie: ile wysiłku interfejs podjął, aby przemalować dla nowego języka, gdy przełącznik jest w locie. Przydatne, gdy „odczuwany" czas i koszt frameworka się rozbiegają.
+
+- **Czas ładowania początkowej strony**: Od nawigacji do przeglądarki uznającej stronę za w pełni załadowaną dla testowanych scenariuszy. Dobry dla porównywania zimnych startów.
+
+- **Czas hydratacji**: Kiedy aplikacja go ujawnia, jak długo klient spędza na zamienianiu HTML-a serwera w coś, na co faktycznie można kliknąć. Kreska w tabelach oznacza, że ta implementacja nie dostarczyła wiarygodnej liczby hydratacji w tym benchmarku.
+
 ## Gwiazdki na GitHubie
 
 Gwiazdki na GitHubie są silnym wskaźnikiem popularności projektu, zaufania społeczności i długoterminowego znaczenia. Choć nie są bezpośrednią miarą jakości technicznej, odzwierciedlają, ilu programistów uważa projekt za przydatny, śledzi jego postępy i prawdopodobnie go przyjmie. Przy szacowaniu wartości projektu gwiazdki pomagają porównać zainteresowanie alternatywami i dostarczają wglądu w rozwój ekosystemu.

package/docs/pl/benchmark/tanstack.md

@@ -124,6 +124,28 @@ Porównaliśmy **cztery strategie ładowania**:
 - **Scoped static**: Utrzymuje porządek w kodzie (separacja logiczna) bez skomplikowanych dodatkowych żądań sieciowych.
 - **Scoped dynamic**: Najlepsze podejście pod kątem dzielenia kodu (code splitting) i wydajności. Minimalizuje zużycie pamięci, ładując tylko to, czego potrzebuje bieżący widok i aktywna lokalizacja.
 
+### Co mierzyłem:
+
+Uruchomiłem tę samą wielojęzyczną aplikację w prawdziwej przeglądarce dla każdego stacku, a następnie zapisałem, co dokładnie pojawiło się na przewodzie i jak długo to trwało. Rozmiary są podawane **po normalnej kompresji sieci web**, ponieważ jest to bliższe temu, co ludzie pobierają, niż surowe liczby źródłowe.
+
+- **Rozmiar biblioteki internationalization**: Po bundlingu, tree-shakingu i minifikacji, rozmiar biblioteki i18n to rozmiar providerów (np. `NextIntlClientProvider`) + kod hooks'ów (np. `useTranslations`) w pustym komponencie. Nie obejmuje to ładowania plików tłumaczeń. Odpowiada na pytanie, jak kosztowna jest biblioteka, zanim Twoja zawartość pojawi się w grze.
+
+- **JavaScript na stronę**: Dla każdej trasy benchmarku, ile skryptu przeglądarka pobiera w tej wizycie, uśrednione na stronach w zestawie (i na locales, gdzie raport je łączy). Ciężkie strony to wolne strony.
+
+- **Wyciek z innych locale'ów**: To zawartość tej samej strony, ale w innym języku, która zostałaby załadowana przez pomyłkę na audytowanej stronie. Ta zawartość jest niepotrzebna i powinna być unikana. (np. zawartość strony `/fr/about` w bundlu strony `/en/about`)
+
+- **Wyciek z innych tras**: Ten sam pomysł dla **innych ekranów** w aplikacji: czy ich zawartość się pojawia, gdy otworzysz tylko jedną stronę. (np. zawartość strony `/en/about` w bundlu strony `/en/contact`). Wysoki wynik wskazuje na słabe splitting'owanie lub zbyt szerokie bundle'e.
+
+- **Średni rozmiar bundle'u komponentu**: Typowe elementy UI są mierzone **pojedynczo** zamiast być ukryte wewnątrz jednej gigantycznej liczby aplikacji. Pokazuje, czy internationalization po cichu nie powiększa codziennych komponentów. Na przykład, jeśli Twój komponent się ponownie renderuje, załaduje wszystkie dane z pamięci. Przyłączenie gigantskiego JSONa do dowolnego komponentu to jak podłączenie dużego magazynu nieużywanych danych, które spowolnią wydajność Twoich komponentów.
+
+- **Responsywność przełączania języka**: Przełączam język za pomocą kontrolki aplikacji i mierzę, jak długo trwa, zanim strona wyraźnie się zmieni, co zauważy odwiedzający, a nie mikro-krok z laboratorium.
+
+- **Praca renderowania po zmianie języka**: Węższe uzupełnienie: ile wysiłku zajęło interfejsowi przerysowanie nowego języka, gdy przełącznik jest w drodze. Przydatne, gdy "odczuwany" czas i koszt frameworka różnią się.
+
+- **Czas ładowania strony początkowej**: Od nawigacji do przeglądarki, która uważa stronę za w pełni załadowaną dla testowanych scenariuszy. Dobry do porównywania zimnych startów.
+
+- **Czas nawodnień (hydration)**: Gdy aplikacja to ujawnia, jak długo klient spędza na zamianie serwera HTML na coś, w co można faktycznie kliknąć. Kreska w tabelach oznacza, że implementacja nie dostarczyła wiarygodnej liczby nawodnienia w tym benchmarku.
+
 ## Gwiazdki na GitHubie
 
 Gwiazdki na GitHubie są silnym wskaźnikiem popularności projektu, zaufania społeczności i długoterminowego znaczenia. Choć nie są bezpośrednią miarą jakości technicznej, odzwierciedlają, ilu programistów uważa projekt za przydatny, śledzi jego postępy i prawdopodobnie go przyjmie. Przy szacowaniu wartości projektu gwiazdki pomagają porównać zainteresowanie alternatywami i dostarczają wglądu w rozwój ekosystemu.

package/docs/pl/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## Wygenerowane GitHub Actions
+
+Gdy uruchomisz `intlayer init`, Intlayer wykrywa Twój package manager (npm, yarn, pnpm lub bun) i generuje dwa przepływy pracy GitHub Actions w `.github/workflows/`, z poleceniami odpowiadającymi tego package managera:
+
+- **`intlayer-fill.yml`** — Na każde pull request, buduje słowniki i uruchamia `intlayer fill --git-diff --mode complete` aby wygenerować brakujące tłumaczenia dla zmienonych słowników, następnie zatwierdza wynik z powrotem do gałęzi PR.
+- **`intlayer-test.yml`** — Na każde pull request, buduje słowniki i uruchamia `intlayer test`, nie powodując sprawdzenia, gdy brakuje wymaganych lokalizacji tłumaczenia.
+
+Istniejące pliki przepływu pracy nigdy nie są zastępowane. Aby całkowicie pominąć scaffolding, uruchom:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Zapewnianie dostępu do AI w workflow fill
+
+Scaffold `intlayer-fill.yml` wymaga dostępu do AI. Dostępne są dwie opcje (skonfigurowane w bloku `env` workflow):
+
+1. **Twój własny klucz dostawcy AI** — Dodaj secret `AI_API_KEY` w ustawieniach repozytorium (Settings → Secrets and variables → Actions). Workflow przekazuje go poprzez `--provider`, `--model` i `--api-key`.
+2. **Klucze dostępu do Intlayer CMS** — Dodaj secrety `INTLAYER_CLIENT_ID` i `INTLAYER_CLIENT_SECRET` i powiąż je z sekcją `editor` w `intlayer.config`. Klucze dostępu do CMS zapewniają dostęp do AI poprzez backend Intlayer.
+
+Workflow `intlayer-test.yml` nie wymaga żadnego dostępu do AI.
+
 ## Obsługa błędów
 
 - Jeśli `INTLAYER_PROJECT_CREDENTIALS` nie jest ustawiona, polecenie zakończy się błędem.

package/docs/pl/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-06-17
 title: Przegląd dokumentu
 description: Dowiedz się, jak przeglądać pliki dokumentacji pod kątem jakości, spójności i kompletności w różnych lokalizacjach.
 keywords:
@@ -15,6 +15,10 @@ slugs:
   - concept
   - cli
   - doc-review
+history:
+  - version: 9.0.0
+    date: 2026-06-17
+    changes: "Dodaj opcję --log"
 author: aymericzip
 ---
 
@@ -55,8 +59,110 @@ W większości przypadków,
 
 ## Argumenty:
 
-Polecenie `doc review` akceptuje te same argumenty co `doc translate`, co pozwala na przeglądanie konkretnych plików dokumentacji i stosowanie kontroli jakości.
+**Opcje listy plików:**
 
-Jeśli aktywowałeś jedną z opcji git, polecenie przejrzy tylko te części plików, które uległy zmianie. Skrypt podzieli plik na fragmenty i przejrzy każdy z nich. Jeśli w danym fragmencie nie ma zmian, skrypt go pominie, aby przyspieszyć proces przeglądu i ograniczyć koszty korzystania z API dostawcy AI.
+- **`--doc-pattern [docPattern...]`**: Wzorce glob do dopasowania plików dokumentacji do przeglądu.
 
-- Pełną listę argumentów znajdziesz w dokumentacji polecenia [Translate Document](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/cli/doc-translate.md).
+  > Przykład: `npx intlayer doc review --doc-pattern "docs/**/*.md" "src/**/*.mdx"`
+
+- **`--excluded-glob-pattern [excludedGlobPattern...]`**: Wzorce glob do wykluczenia z przeglądu.
+
+  > Przykład: `npx intlayer doc review --excluded-glob-pattern "docs/internal/**"`
+
+- **`--skip-if-modified-before [skipIfModifiedBefore]`**: Pomiń plik, jeśli został zmodyfikowany przed podanym czasem.
+  - Może to być czas absolutny, np. "2025-12-05" (string lub Date)
+  - Może to być czas względny w ms `1 * 60 * 60 * 1000` (1 godzina)
+  - Ta opcja sprawdza czas aktualizacji pliku za pomocą metody `fs.stat`. Może więc być wpływana przez Git lub inne narzędzia modyfikujące plik.
+
+  > Przykład: `npx intlayer doc review --skip-if-modified-before "2025-12-05"`
+
+- **`--skip-if-modified-after [skipIfModifiedAfter]`**: Pomiń plik, jeśli został zmodyfikowany w podanym czasie.
+  - Może to być czas absolutny, np. "2025-12-05" (string lub Date)
+  - Może to być czas względny w ms `1 * 60 * 60 * 1000` (1 godzina)
+  - Ta opcja sprawdza czas aktualizacji pliku za pomocą metody `fs.stat`. Może więc być wpływana przez Git lub inne narzędzia modyfikujące plik.
+
+  > Przykład: `npx intlayer doc review --skip-if-modified-after "2025-12-05"`
+
+- **`--skip-if-exists`**: Pomiń plik, jeśli już istnieje.
+
+  > Przykład: `npx intlayer doc review --skip-if-exists`
+
+**Opcje trybu przeglądu:**
+
+- **`--log`**: Tryb tylko logowania. Nie tłumaczy za pomocą AI; zamiast tego loguje bloki wymagające uwagi (wraz z numerami linii i zawartością) dla bazowych i docelowych lokalizacji, aby pomóc innemu agentowi w wygenerowaniu tłumaczeń.
+
+  > Przykład: `npx intlayer doc review --log`
+
+**Opcje wyjścia wpisu:**
+
+- **`--locales [locales...]`**: Docelowe lokalizacje, dla których ma być przejrzana dokumentacja.
+
+  > Przykład: `npx intlayer doc review --locales fr es de`
+
+- **`--base-locale [baseLocale]`**: Źródłowa lokalizacja (bazowy dokument), z którą należy porównać.
+
+  > Przykład: `npx intlayer doc review --base-locale en`
+
+**Opcje przetwarzania plików:**
+
+- **`--nb-simultaneous-file-processed [nbSimultaneousFileProcessed]`**: Liczba plików przetwarzanych jednocześnie podczas przeglądu.
+
+  > Przykład: `npx intlayer doc review --nb-simultaneous-file-processed 5`
+
+**Opcje AI:**
+
+- **`--model [model]`**: Model AI używany do przeglądu (np. `gpt-3.5-turbo`).
+- **`--provider [provider]`**: Dostawca AI używany do przeglądu.
+- **`--temperature [temperature]`**: Ustawienie temperatury dla modelu AI.
+- **`--api-key [apiKey]`**: Podaj własny klucz API dla usługi AI.
+- **`--application-context [applicationContext]`**: Podaj dodatkowy kontekst dla przeglądu AI.
+- **`--data-serialization [dataSerialization]`**: Format serializacji danych dla funkcji AI w Intlayer. Opcje: `json` (standardowy, niezawodny), `toon` (mniej tokenów, mniej spójny).
+- **`--custom-prompt [prompt]`**: Dostosuj podstawowy prompt używany do przeglądu. (Uwaga: W większości przypadków zaleca się użycie opcji `--custom-instructions`, ponieważ zapewnia lepszą kontrolę.)
+
+  > Przykład: `npx intlayer doc review --model deepseek-chat --provider deepseek --temperature 0.5 --api-key sk-1234567890 --application-context "Moja aplikacja to sklep z kotami"`
+
+**Opcje zmiennych środowiskowych:**
+
+- **`--env`**: Określ środowisko (np. `development`, `production`).
+- **`--env-file [envFile]`**: Podaj niestandardowy plik środowiskowy do załadowania zmiennych.
+- **`--base-dir`**: Określ katalog bazowy projektu.
+- **`--no-cache`**: Wyłącz pamięć podręczną.
+
+  > Przykład: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
+
+**Opcje logowania:**
+
+- **`--verbose`**: Włącz szczegółowe logowanie do debugowania. (domyślnie true przy użyciu CLI)
+
+  > Przykład: `npx intlayer doc review --verbose`
+
+**Opcje niestandardowych instrukcji:**
+
+- **`--custom-instructions [customInstructions]`**: Niestandardowe instrukcje dodane do promptu. Przydatne do stosowania specyficznych reguł dotyczących formatowania, tłumaczenia URL itp.
+
+  > Przykład: `npx intlayer doc review --custom-instructions "Unikaj tłumaczenia URL-i i zachowaj format markdown"`
+
+  > Przykład: `npx intlayer doc review --custom-instructions "$(cat ./instructions.md)"`
+
+**Opcje Git:**
+
+- **`--git-diff`**: Uruchom tylko na plikach, które zawierają zmiany od bazy (domyślnie `origin/main`) do bieżącej gałęzi (domyślnie `HEAD`).
+- **`--git-diff-base`**: Określ bazowe odniesienie dla git diff (domyślnie `origin/main`).
+- **`--git-diff-current`**: Określ bieżące odniesienie dla git diff (domyślnie `HEAD`).
+- **`--uncommitted`**: Uwzględnij niezacommitowane zmiany.
+- **`--unpushed`**: Uwzględnij niepushowane zmiany.
+- **`--untracked`**: Uwzględnij nieśledzone pliki.
+
+  > Przykład: `npx intlayer doc review --git-diff --git-diff-base origin/main --git-diff-current HEAD`
+
+  > Przykład: `npx intlayer doc review --uncommitted --unpushed --untracked`
+
+> Zauważ, że ścieżka pliku wyjściowego zostanie określona przez zastąpienie następujących wzorców:
+>
+> - `/{{baseLocale}}/` na `/{{locale}}/` (Unix)
+> - `\{{baseLocale}}\` na `\{{locale}}\` (Windows)
+> - `_{{baseLocale}}.` na `_{{locale}}.`
+> - `{{baseLocale}}_` na `{{locale}}_`
+> - `.{{baseLocaleName}}.` na `.{{localeName}}.`
+>
+> Jeśli wzorzec nie zostanie znaleziony, plik wyjściowy doda `.{{locale}}` do rozszerzenia pliku. `./my/file.md` zostanie przejrzany i zaktualizowany do `./my/file.fr.md` dla lokalizacji francuskiej.

package/docs/pl/cli/fill.md

@@ -47,6 +47,14 @@ Kluczowe punkty:
 - Zachowuje istniejące tłumaczenia, nie nadpisując ich.
 - Przetwarza pliki, fragmenty i lokalizacje równolegle przy użyciu systemu kolejkowego, aby zwiększyć prędkość.
 
+## Kluczowe punkty:
+
+- Dzieli duże pliki JSON na fragmenty, aby pozostać w granicach kontekstu modelu AI.
+- Ponawia tłumaczenie, jeśli format wyjściowy jest nieprawidłowy.
+- Zawiera kontekst specyficzny dla aplikacji i pliku, aby poprawić dokładność tłumaczenia.
+- Zachowuje istniejące tłumaczenia, nie zastępując ich.
+- Przetwarza pliki, fragmenty i lokalizacje równolegle przy użyciu systemu kolejki, aby zwiększyć szybkość.
+
 ## Alias:
 
 - `npx intlayer dictionaries fill`

package/docs/pl/cli/index.md

@@ -17,7 +17,7 @@ slugs:
   - concept
   - cli
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "Dodano polecenie scan"
   - version: 8.6.4