@intlayer/docs 9.5.1 → 9.5.2

package/docs/pl/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Najlepsze rozwiązanie i18n dla Next.js w 2026 r. - Raport Benchmark
 description: Porównaj biblioteki internacjonalizacji (i18n) dla Next.js, takie jak next-intl, next-i18next i Intlayer. Szczegółowy raport wydajności dotyczący rozmiaru pakietu, wycieków i reaktywności.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Aktualizacja wyników benchmarku"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Dodaj porównanie gwiazdek GitHub"
@@ -56,7 +59,7 @@ Biblioteki internacjonalizacji mają ogromny wpływ na Twoją aplikację. Głów
 
 W miarę rozwoju aplikacji rozmiar bundle'a może rosnąć wykładniczo, co może zauważalnie obniżyć wydajność.
 
-Jako przykład: w najgorszych przypadkach, po internacjonalizacji Twoja strona może stać się niemal 4 razy większa.
+Jako przykład: w najgorszych przypadkach, po internacjonalizacji Twoja strona może stać się niemal 2 razy większa.
 
 Innym skutkiem bibliotek i18n jest wolniejszy rozwój. Przekształcanie komponentów w wielojęzyczne treści w wielu językach jest czasochłonne.
 
@@ -68,7 +71,7 @@ Intlayer stara się optymalizować we wszystkich tych wymiarach.
 
 - **Intlayer** i **next-translate**: Najlepsze wybory dla wydajności Next.js, oferujące najmniejszy rozmiar i najlepsze wsparcie dla statycznego renderowania.
 - **next-intl**: Najmodniejsza obecnie opcja, ale ciężka i skomplikowana w optymalizacji dla dużych aplikacji.
-- **next-i18next**: Popularna i bogata w pluginy, ale niesie ze sobą znaczny ciężar pakietu (~3× Intlayer).
+- **next-i18next**: Popularna i bogata w pluginy, ale niesie ze sobą znaczny ciężar pakietu (~3.5× Intlayer).
 - **Unikaj**: **gt-next** i **lingo.dev** ze względu na poważne problemy z wydajnością, uzależnienie od dostawcy (vendor lock-in) i błędy blokujące budowanie.
 
 ## Przetestuj swoją aplikację
@@ -109,19 +112,21 @@ Wreszcie, `Intlayer` stosuje optymalizację w czasie budowania, dzięki czemu `u
 W tym benchmarku porównaliśmy następujące biblioteki:
 
 - `Base App` (Brak biblioteki i18n)
-- `next-intlayer` (v8.7.12)
-- `next-i18next` (v16.0.5)
-- `next-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
-- `next-translate` (v3.1.2)
+- `next-intlayer` (v9.5.1)
+- [`@intlayer/next-intl`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/compat/next-i18next.md) (v9.5.1)
+- `next-i18next` (v16.3.0)
+- `next-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
+- `next-translate` (v3.2.0)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `@lingo.dev/compiler` (v0.4.0)
-- `wuchale` (v0.22.11)
-- `gt-next` (v6.16.5)
+- `@tolgee/react` (v7.2.0)
+- `@lingo.dev/compiler` (v0.4.12)
+- `wuchale` (v0.26.6)
+- `gt-next` (v11.1.24)
 
-Użyłem `Next.js` w wersji `16.2.4` z App Routerem.
+Użyłem `Next.js` w wersji `16.3.4` z App Routerem.
 
 Zbudowałem wielojęzyczną aplikację z **10 stronami** i **10 językami**.
 
@@ -175,15 +180,15 @@ Należy wyraźnie unikać niektórych rozwiązań, takich jak `gt-next` czy `lin
 
 Napotkane problemy:
 
-**(General Translation)** (`gt-next@6.16.5`):
+**(General Translation)** (`gt-next@11.1.24`):
 
-- W przypadku aplikacji o rozmiarze 110 KB, `gt-next` dodaje ponad 440 KB ekstra.
+- W przypadku aplikacji o rozmiarze 141 KB, `gt-next` dodaje ponad 50 KB ekstra.
 - Komunikat `Quota Exceeded, please upgrade your plan` przy pierwszej próbie budowania z 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 wdrażania **gt-next** napotkałem również [problem](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) z biblioteką: błąd `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, który powodował awarię aplikacji. 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`):
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.12`):
 
 - Przekroczenie limitu AI, co całkowicie blokuje budowanie - nie można zatem wdrożyć aplikacji na produkcję bez płacenia.
 - Kompilator pomijał niemal 40% przetłumaczonej treści. Musiałem przepisać wszystkie struktury `.map` na płaskie bloki komponentów, aby go uruchomić.
@@ -192,7 +197,7 @@ Napotkane problemy:
 
 ### 2 - Rozwiązania eksperymentalne
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 Idea stojąca za `Wuchale` jest interesująca, ale nie jest to jeszcze opłacalne rozwiązanie. Napotkałem problemy z reaktywnością i musiałem wymusić ponowne renderowanie dostawcy, aby aplikacja działała. Dokumentacja jest również dość niejasna, co utrudnia wdrożenie.
 
@@ -202,21 +207,21 @@ Idea stojąca za `Wuchale` jest interesująca, ale nie jest to jeszcze opłacaln
 Osobiście nie podoba mi się konieczność regenerowania plików JS przed każdym przesłaniem kodu (push), co stwarza ciągłe ryzyko konfliktów scalania (merge conflicts) przy Pull Requestach. Narzędzie wydaje się również bardziej skoncentrowane na Vite niż na Next.js.
 Wreszcie, w porównaniu z innymi rozwiązaniami, Paraglide nie używa magazynu (np. React context) do pobierania bieżącej lokalizacji w celu renderowania treści. Dla każdego przeanalizowanego węzła żąda lokalizacji z localStorage / cookie itp. Prowadzi to do wykonywania niepotrzebnej logiki, co wpływa na reaktywność komponentu.
 
-> Notatka o paraglide: rozwiązanie to wstrzykuje kod do Twojej bazy kodu w celu importu, w wyniku czego metryka 'rozmiar biblioteki' w raporcie benchmarka wynosi prawie 0. Generowanie kodu to dobra rzecz, ponieważ używana funkcja będzie zawierać tylko niezbędną logikę (wszystkie prefiksy vs brak prefiksów, ciasteczka vs storage itp.). Dla porównania, Intlayer wykonuje to filtrowanie poprzez wstrzykiwanie zmiennych środowiskowych w procesie budowania, aby wymusić na bundlerze usunięcie treści (tree-shake) w zależności od logiki. Dzięki temu paraglide i intlayer okazują się być od 6 do 10 razy lżejszymi rozwiązaniami niż i18next czy next-intl.
+> Notatka o paraglide: rozwiązanie to wstrzykuje kod do Twojej bazy kodu w celu importu, w wyniku czego metryka 'rozmiar biblioteki' w raporcie benchmarka wynosi prawie 0. Generowanie kodu to dobra rzecz, ponieważ używana funkcja będzie zawierać tylko niezbędną logikę (wszystkie prefiksy vs brak prefiksów, ciasteczka vs storage itp.). Dla porównania, Intlayer wykonuje to filtrowanie poprzez wstrzykiwanie zmiennych środowiskowych w procesie budowania, aby wymusić na bundlerze usunięcie treści (tree-shake) w zależności od logiki. Dzięki temu paraglide i intlayer okazują się być od 3 do 8 razy lżejszymi rozwiązaniami niż i18next czy next-intl.
 
 ### 3 - Akceptowalne rozwiązania
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` rozwiązuje wiele z wymienionych wcześniej problemów. Uznałem jednak, że trudniej go wdrożyć niż podobne narzędzia. Nie zapewnia on bezpieczeństwa typów (type safety), co utrudnia również wyłapywanie brakujących kluczy w czasie kompilacji. Musiałem opakować funkcje Tolgee we własne funkcje, aby dodać wykrywanie brakujących kluczy.
 
-**(Next Intl)** (`next-intl@4.9.1`):
+**(Next Intl)** (`next-intl@4.14.2`):
 
-`next-intl` to obecnie najmodniejsza opcja i ta, którą agenci AI forsują najbardziej, ale moim zdaniem niesłusznie. Rozpoczęcie pracy jest łatwe. W praktyce optymalizacja pod kątem ograniczania wycieków jest złożona. Połączenie dynamicznego ładowania + przestrzeni nazw + typów TypeScript bardzo spowalnia rozwój. Pakiet jest również dość ciężki (~13 KB dla `NextIntlClientProvider` + `useTranslations`, co stanowi ponad 2-krotność `next-intlayer`). **next-intl** blokował niegdyś statyczne renderowanie stron Next.js. Udostępnia on funkcję pomocniczą o nazwie `setRequestLocale()`. Wydaje się, że zostało to częściowo rozwiązane w przypadku scentralizowanych plików, takich jak `en.json` / `fr.json`, ale statyczne renderowanie wciąż przestaje działać, gdy treść jest podzielona na przestrzenie nazw, takie jak `en/shared.json` / `fr/shared.json` / `es/shared.json`.
+`next-intl` to obecnie najmodniejsza opcja i ta, którą agenci AI forsują najbardziej, ale moim zdaniem niesłusznie. Rozpoczęcie pracy jest łatwe. W praktyce optymalizacja pod kątem ograniczania wycieków jest złożona. Połączenie dynamicznego ładowania + przestrzeni nazw + typów TypeScript bardzo spowalnia rozwój. Pakiet jest również dość ciężki (~14.7 KB dla `NextIntlClientProvider` + `useTranslations`, co stanowi ponad 2.5-krotność `next-intlayer`). **next-intl** blokował niegdyś statyczne renderowanie stron Next.js. Udostępnia on funkcję pomocniczą o nazwie `setRequestLocale()`. Wydaje się, że zostało to częściowo rozwiązane w przypadku scentralizowanych plików, takich jak `en.json` / `fr.json`, ale statyczne renderowanie wciąż przestaje działać, gdy treść jest podzielona na przestrzenie nazw, takie jak `en/shared.json` / `fr/shared.json` / `es/shared.json`.
 
-**(Next I18next)** (`next-i18next@16.0.5`):
+**(Next I18next)** (`next-i18next@16.3.0`):
 
-`next-i18next` jest prawdopodobnie najpopularniejszą opcją, ponieważ był jednym z pierwszych rozwiązań i18n dla aplikacji JavaScript. Posiada on wiele wtyczek społecznościowych. Ma on te same główne wady co `next-intl`. Pakiet jest szczególnie ciężki (~18 KB dla `I18nProvider` + `useTranslation`, około 3-krotność `next-intlayer`).
+`next-i18next` jest prawdopodobnie najpopularniejszą opcją, ponieważ był jednym z pierwszych rozwiązań i18n dla aplikacji JavaScript. Posiada on wiele wtyczek społecznościowych. Ma on te same główne wady co `next-intl`. Pakiet jest szczególnie ciężki (~19.7 KB dla `I18nProvider` + `useTranslation`, około 3.5-krotność `next-intlayer`).
 
 Różnią się również formaty komunikatów: `next-intl` używa ICU MessageFormat, podczas gdy `i18next` używa własnego formatu.
 
@@ -224,17 +229,17 @@ Różnią się również formaty komunikatów: `next-intl` używa ICU MessageFor
 
 `next-international` również radzi sobie z powyższymi problemami, ale nie różni się zbytnio od `next-intl` czy `next-i18next`. Zawiera on funkcję `scopedT()` dla tłumaczeń specyficznych dla przestrzeni nazw, ale jej użycie nie ma praktycznie żadnego wpływu na rozmiar bundle'a.
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` jest często chwalony. Osobiście uznałem, że proces `lingui extract` / `lingui compile` jest bardziej złożony niż w przypadku alternatyw, bez wyraźnej przewagi. Zauważyłem również niespójne składnie, które mylą AI (np. `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
 ### 4 - Rekomendacje
 
-**(Next Translate)** (`next-translate@3.1.2`):
+**(Next Translate)** (`next-translate@3.2.0`):
 
-`next-translate` to moja główna rekomendacja, jeśli lubisz API w stylu `t()`. Działa on elegancko poprzez `next-translate-plugin`, ładując przestrzenie nazw przez `getStaticProps` za pomocą loadera Webpack / Turbopack. Jest to również najlżejsza opcja w tym zestawieniu (~2.5 KB). Jeśli chodzi o przestrzenie nazw, definiowanie ich na poziomie strony lub trasy w konfiguracji jest przemyślane i łatwiejsze w utrzymaniu niż w przypadku głównych alternatyw, takich jak **next-intl** czy **next-i18next**. W wersji `3.1.2` zauważyłem, że statyczne renderowanie nie działało; Next.js powracał do renderowania dynamicznego.
+`next-translate` to moja główna rekomendacja, jeśli lubisz API w stylu `t()`. Działa on elegancko poprzez `next-translate-plugin`, ładując przestrzenie nazw przez `getStaticProps` za pomocą loadera Webpack / Turbopack. Jest to również jedna z najlżejszych opcji w tym zestawieniu (~3.5 KB). Jeśli chodzi o przestrzenie nazw, definiowanie ich na poziomie strony lub trasy w konfiguracji jest przemyślane i łatwiejsze w utrzymaniu niż w przypadku głównych alternatyw, takich jak **next-intl** czy **next-i18next**. W wersji `3.1.2` zauważyłem, że statyczne renderowanie nie działało; Next.js powracał do renderowania dynamicznego.
 
-**(Intlayer)** (`next-intlayer@8.7.12`):
+**(Intlayer)** (`next-intlayer@9.5.1`):
 
 Nie będę osobiście oceniał `next-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.
 

package/docs/pl/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Najlepsze rozwiązanie i18n dla Solid w 2026 r. - raport z benchmarku
 description: Porównaj biblioteki internacjonalizacji (i18n) dla Solid, takie jak solid-primitives, solid-i18next i Intlayer. Szczegółowy raport wydajności dotyczący rozmiaru paczki, wycieków i reaktywności.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Aktualizacja wyników benchmarku"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Dodaj porównanie gwiazdek GitHub"
@@ -62,9 +65,9 @@ Innym skutkiem jest wpływ na doświadczenie programisty (DX): sposób deklarowa
 
 ## TL;DR
 
-- **Intlayer**: Zalecany wybór dla profesjonalnych aplikacji Solid wymagających zaawansowanych funkcji i optymalizacji (v8.7.12).
+- **Intlayer**: Zalecany wybór dla profesjonalnych aplikacji Solid wymagających zaawansowanych funkcji i optymalizacji (v9.5.0).
 - **@solid-primitives/i18n**: Doskonała lekka alternatywa dla prostych projektów, choć brakuje jej zaawansowanych funkcji, takich jak lazy loading.
-- **solid-i18next**: Standardowa, ale ciężka opcja (~4.7x Intlayer) z tymi samymi wadami co React i18next.
+- **solid-i18next**: Standardowa, ale ciężka opcja (~3.5x Intlayer) z tymi samymi wadami co React i18next.
 - **Paraglide**: Innowacyjne podejście, ale złożone DX i problemy z tree-shakingiem w niektórych konfiguracjach.
 
 ## Przetestuj swoją aplikację
@@ -97,10 +100,10 @@ Składnie zbudowane wokół `t('a.b.c')` są bardzo wygodne, ale często zachęc
 W tym benchmarku porównaliśmy następujące biblioteki:
 
 - `Base App` (Brak biblioteki i18n)
-- `solid-intlayer` (v8.7.12)
+- `solid-intlayer` (v9.5.0)
 - `@solid-primitives/i18n` (v2.2.1)
-- `solid-i18next` (v17.0.2)
-- `@inlang/paraglide-js` (v2.17.0)
+- `i18next` (v26.0.8) + `@mbarzda/solid-i18next` (v1.4.1)
+- `@inlang/paraglide-js` (v2.25.1)
 
 Framework to `Solid` z aplikacją wielojęzyczną składającą się z **10 stron** i **10 języków**.
 
@@ -154,11 +157,11 @@ Gwiazdki na GitHubie są silnym wskaźnikiem popularności projektu, zaufania sp
 
 ### 2 - Rozwiązania akceptowalne
 
-**(solid-i18next)** (`solid-i18next@17.0.2`):
+**(solid-i18next)** (`i18next@26.0.8`):
 
 `solid-i18next` jest prawdopodobnie najpopularniejszą opcją, ponieważ był jednym z pierwszych rozwiązań zaspokajających potrzeby i18n aplikacji JavaScript. Posiada również szeroki zestaw wtyczek społecznościowych dla konkretnych problemów.
 
-Paczka jest ciężka (~14.6kb, co stanowi około 4.7x `solid-intlayer`).
+Paczka jest ciężka (~14.9kb, co stanowi około 3.5x `solid-intlayer`).
 
 Mimo to dzieli te same główne wady co stosy technologiczne zbudowane na `t('a.b.c')`: optymalizacje są możliwe, ale bardzo czasochłonne, a duże projekty niosą ze sobą ryzyko złych praktyk (przestrzenie nazw + dynamiczne ładowanie + typy).
 
@@ -167,7 +170,7 @@ Mimo to dzieli te same główne wady co stosy technologiczne zbudowane na `t('a.
 Solid primitive jest niezwykle lekki i wydajny. Polecam to rozwiązanie dla lekkich projektów, ale może w nim szybko zabraknąć funkcji dla profesjonalnych rozwiązań, w tym zarządzania plikami cookie, przekierowań proxy, formaterów itp.
 Brakuje mu również lazy loadingu i scopingu przestrzeni nazw w celu optymalizacji rozmiaru strony.
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` oferuje innowacyjne, przemyślane podejście. Mimo to w tym benchmarku reklamowany przez nich tree-shaking nie zadziałał w mojej implementacji. Workflow i DX są również bardziej złożone niż w przypadku innych opcji.
 Osobiście nie lubię konieczności regeneracji plików JS przed każdym pushem, co stwarza ciągłe ryzyko konfliktów przy mergowaniu poprzez PR-y.
@@ -175,7 +178,7 @@ Wreszcie, w porównaniu z innymi rozwiązaniami, Paraglide nie używa store'a (n
 
 ### 3 - Rekomendacje
 
-**(Intlayer)** (`solid-intlayer@8.7.12`):
+**(Intlayer)** (`solid-intlayer@9.5.0`):
 
 Nie będę osobiście oceniać `solid-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.
 

package/docs/pl/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Najlepsze rozwiązanie i18n dla Svelte w 2026 r. - raport z benchmarku
 description: Porównaj biblioteki internacjonalizacji (i18n) dla Svelte, takie jak svelte-i18n, Paraglide i Intlayer. Szczegółowy raport wydajności dotyczący rozmiaru paczki, wycieków i reaktywności.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Aktualizacja wyników benchmarku"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Dodaj porównanie gwiazdek GitHub"
@@ -62,9 +65,9 @@ Innym skutkiem jest wpływ na doświadczenie programisty (DX): sposób deklarowa
 
 ## TL;DR
 
-- **Intlayer**: Najbardziej wydajny wybór (v8.7.12) z najmniejszym śladem (footprint).
+- **Intlayer**: Najbardziej wydajny wybór (v9.5.0) z najmniejszym śladem (footprint).
 - **Paraglide**: Mocny kandydat pod kątem tree-shakingu, ale oferuje bardziej złożone doświadczenie programisty i narzut reaktywności.
-- **svelte-i18n**: Kompleksowy i standardowy dla Svelte, ale wiąże się ze znacznie większą wagą paczki (~7x Intlayer).
+- **svelte-i18n**: Kompleksowy i standardowy dla Svelte, ale wiąże się ze znacznie większą wagą paczki (~4.5x Intlayer).
 
 ## Przetestuj swoją aplikację
 
@@ -96,9 +99,9 @@ Składnie zbudowane wokół `t('a.b.c')` są bardzo wygodne, ale często zachęc
 W tym benchmarku porównaliśmy następujące biblioteki:
 
 - `Base App` (Brak biblioteki i18n)
-- `svelte-intlayer` (v8.7.12)
+- `svelte-intlayer` (v9.5.0)
 - `svelte-i18n` (v4.0.1)
-- `@inlang/paraglide-js` (v2.17.0)
+- `@inlang/paraglide-js` (v2.25.1)
 
 Framework to `Svelte` z aplikacją wielojęzyczną składającą się z **10 stron** i **10 języków**.
 
@@ -152,7 +155,7 @@ Gwiazdki na GitHubie są silnym wskaźnikiem popularności projektu, zaufania sp
 
 ### 2 - Rozwiązania akceptowalne
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` oferuje innowacyjne, przemyślane podejście. W kontekście aplikacji Vite + Svelte reklamowany przez nich tree-shaking działał zgodnie z oczekiwaniami, co jest świetne.
 Ale w przypadku React + TanStack Start tree-shaking nie działał zgodnie z oczekiwaniami, podobnie w Next.js. To powiedziawszy, użycie Paraglide w projekcie Svelte i TanStack Start byłoby warte ponownego sprawdzenia.
@@ -162,13 +165,13 @@ Wreszcie, w porównaniu z innymi rozwiązaniami, Paraglide nie używa store'a (n
 
 > Uwaga na temat paraglide: rozwiązanie to wstrzykuje kod do Twojej bazy kodu w celu importu; w rezultacie metryka „lib size” w raporcie z benchmarku wynosi prawie 0. Generowanie kodu jest dobrą rzeczą, ponieważ użyta funkcja będzie zawierać tylko niezbędną logikę (prefiks wszędzie vs brak prefiksu, cookie vs storage itp.). Dla porównania, Intlayer wykonuje to filtrowanie poprzez wstrzykiwanie zmiennych środowiskowych podczas budowania (build time), aby wymusić na bundlerze tree-shaking treści w zależności od logiki. Dzięki temu paraglide i intlayer okazują się być od 6 do 10 razy lżejszymi rozwiązaniami niż i18next czy next-intl.
 
-**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+**(svelte-i18n)** (`svelte-i18n@4.0.1`):
 
-To rozwiązanie odpowiada na wszystkie potrzeby i18n w projekcie Svelte. Ale podobnie jak w przypadku i18next lub innych głównych rozwiązań i18n, jest ono nieco ciężkie (~15.9kb, co stanowi około 7x `svelte-intlayer`).
+To rozwiązanie odpowiada na wszystkie potrzeby i18n w projekcie Svelte. Ale podobnie jak w przypadku i18next lub innych głównych rozwiązań i18n, jest ono nieco ciężkie (~16.6kb, co stanowi około 4.5x `svelte-intlayer`).
 
 ### 3 - Rekomendacje
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`):
+**(Intlayer)** (`svelte-intlayer@9.5.0`):
 
 Nie będę osobiście oceniać `svelte-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.
 

package/docs/pl/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Najlepsze rozwiązanie i18n dla TanStack Start w 2026 r. - Raport Benchmark
 description: Porównaj biblioteki internacjonalizacji dla TanStack Start, takie jak react-i18next, use-intl i Intlayer. Szczegółowy raport wydajności dotyczący rozmiaru pakietu, wycieków i reaktywności.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Aktualizacja wyników benchmarku"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Dodaj porównanie gwiazdek GitHub"
@@ -62,7 +65,7 @@ Inny wpływ dotyczy doświadczenia programisty (DX): sposobu deklarowania treśc
 
 ## TL;DR
 
-- **Intlayer**: Zapewnia najlepszą wydajność i najmniejszy rozmiar bundle'a (v8.7.12) dla TanStack Start.
+- **Intlayer**: Zapewnia najlepszą wydajność i najmniejszy rozmiar bundle'a (v9.5.1) dla TanStack Start.
 - **react-i18next** & **use-intl**: Dojrzałe alternatywy z dużymi ekosystemami, ale znacznie cięższe i bardziej złożone w optymalizacji.
 - **Paraglide**: Innowacyjny pomysł na tree-shaking, który nie działa w praktyce. Skomplikowane DX i narzut reaktywności w TanStack Start.
 - **Unikaj**: **General Translation (GT)** i **Lingo.dev** ze względu na poważne problemy z wydajnością, limity AI i uzależnienie od dostawcy (vendor lock-in).
@@ -97,16 +100,18 @@ Składnie oparte na `const t = useTranslation()` + `t('a.b.c')` są bardzo wygod
 W tym benchmarku porównaliśmy następujące biblioteki:
 
 - `Base App` (Brak biblioteki i18n)
-- `react-intlayer` (v8.7.12)
-- `react-i18next` (v17.0.2)
-- `use-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
+- `react-intlayer` (v9.5.1)
+- `@intlayer/use-intl` (v9.5.1)
+- [`@intlayer/lingui`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/compat/lingui.md) (v9.5.1)
+- `react-i18next` (v17.0.13)
+- `use-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `react-intl` (v10.1.1)
-- `wuchale` (v0.22.11)
-- `gt-react` (vlatest)
-- `lingo.dev` (v0.133.9)
+- `@tolgee/react` (v7.2.0)
+- `react-intl` (v10.1.26)
+- `wuchale` (v0.26.6)
+- `gt-react` (v10.18.3)
+- `lingo.dev` (v0.138.7)
 
 Frameworkiem jest `TanStack Start` z wielojęzyczną aplikacją składającą się z **10 stron** i **10 języków**.
 
@@ -160,15 +165,15 @@ Należy wyraźnie unikać niektórych rozwiązań, takich jak `gt-react` czy `li
 
 Napotkane problemy:
 
-**(General Translation)** (`gt-react@latest`):
+**(General Translation)** (`gt-react@10.18.3`):
 
-- W przypadku aplikacji o rozmiarze około 110 KB, `gt-react` może dodać ponad 440 KB ekstra (rząd wielkości zaobserwowany w implementacji Next.js w tym samym benchmarku).
+- W przypadku aplikacji o rozmiarze około 111 KB, `gt-react` może dodać ponad 170 KB ekstra (rząd wielkości zaobserwowany w implementacji Next.js w tym samym benchmarku).
 - Komunikat `Quota Exceeded, please upgrade your plan` przy pierwszej próbie budowania z 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 wdrażania **gt-tanstack-start-react** napotkałem również [problem](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) z biblioteką: błąd `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, który powodował awarię aplikacji. Po zgłoszeniu opiekun naprawił go w ciągu 24 godzin.
 - Biblioteki te stosują anty-wzorzec poprzez funkcję `initializeGT()`, blokując możliwość czystego usuwania kodu z pakietu (tree-shaking).
 
-**(Lingo.dev)** (`lingo.dev@0.133.9`):
+**(Lingo.dev)** (`lingo.dev@0.138.7`):
 
 - Przekroczenie limitu AI (lub blokująca zależność serwerowa), co sprawia, że budowanie / produkcja są ryzykowne bez płacenia.
 - Kompilator pomijał niemal 40% przetłumaczonej treści. Musiałem przepisać wszystkie struktury `.map` na płaskie bloki komponentów, aby go uruchomić.
@@ -178,7 +183,7 @@ Napotkane problemy:
 
 ### 2 - Rozwiązania eksperymentalne
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 Idea stojąca za `Wuchale` jest interesująca, ale nie jest to jeszcze opłacalne rozwiązanie. Napotkałem problemy z reaktywnością tej biblioteki i musiałem wymusić ponowne renderowanie dostawcy, aby aplikacja działała w TanStack Start. Dokumentacja jest również dość niejasna, co utrudnia wdrożenie.
 
@@ -188,9 +193,9 @@ Idea stojąca za `Wuchale` jest interesująca, ale nie jest to jeszcze opłacaln
 
 `Paraglide` oferuje innowacyjne i przemyślane podejście. Mimo to w tym benchmarku reklamowany przez firmę tree-shaking nie zadziałał w mojej implementacji Next.js ani w TanStack Start. Przepływ pracy i DX są również bardziej złożone niż w przypadku innych opcji. Osobiście nie jestem fanem konieczności regenerowania plików JS przed każdym przesłaniem kodu (push), co stwarza ciągłe ryzyko konfliktów scalania dla programistów przy Pull Requestach.
 
-> Uwaga dotycząca paraglide: to rozwiązanie wstrzykuje kod do bazy kodu dla importów, w wyniku czego metryka 'lib size' w raporcie benchmarku wynosi prawie 0. Generowanie kodu jest dobre, ponieważ użyta funkcja będzie zawierać tylko niezbędną logikę (prefiks wszędzie vs brak prefiksu, cookie vs pamięć itp.). Dla porównania, Intlayer wykonuje to filtrowanie poprzez wstrzykiwanie zmiennych środowiskowych w procesie budowania, aby wymusić na bundlerze tree-shaking zawartości w zależności od logiki. Dzięki temu paraglide i intlayer są ostatecznie od 6 do 10 razy lżejszymi rozwiązaniami niż i18next czy next-intl.
+> Uwaga dotycząca paraglide: to rozwiązanie wstrzykuje kod do bazy kodu dla importów, w wyniku czego metryka 'lib size' w raporcie benchmarku wynosi prawie 0. Generowanie kodu jest dobre, ponieważ użyta funkcja będzie zawierać tylko niezbędną logikę (prefiks wszędzie vs brak prefiksu, cookie vs pamięć itp.). Dla porównania, Intlayer wykonuje to filtrowanie poprzez wstrzykiwanie zmiennych środowiskowych w procesie budowania, aby wymusić na bundlerze tree-shaking zawartości w zależności od logiki. Dzięki temu paraglide i intlayer są ostatecznie od 3 do 10 razy lżejszymi rozwiązaniami niż i18next czy next-intl.
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` rozwiązuje wiele z wymienionych wcześniej problemów. Uznałem jednak, że trudniej z nim zacząć niż z innymi narzędziami o podobnym podejściu. Nie zapewnia on bezpieczeństwa typów, co sprawia, że bardzo trudno jest wyłapać brakujące klucze w czasie kompilacji. Musiałem opakować API Tolgee we własne API, aby dodać wykrywanie brakujących kluczy.
 
@@ -198,37 +203,37 @@ Package jest dość ciężki (~11.1kb, co jest ponad 2× większe niż `react-in
 
 W TanStack Start miałem również problemy z reaktywnością: przy zmianie lokalizacji musiałem wymusić ponowne renderowanie dostawcy i zasubskrybować zdarzenia zmiany lokalizacji, aby ładowanie w innym języku zachowywało się poprawnie.
 
-**(use-intl)** (`use-intl@4.9.1`):
+**(use-intl)** (`use-intl@4.14.2`):
 
 `use-intl` jest obecnie najmodniejszym elementem „intl” w ekosystemie React (z tej samej rodziny co `next-intl`) i jest często forsowany przez agentów AI, ale moim zdaniem niesłusznie w środowisku, w którym liczy się wydajność. Rozpoczęcie pracy jest dość proste. W praktyce proces optymalizacji i ograniczania wycieków jest dość złożony. Podobnie połączenie dynamicznego ładowania + przestrzeni nazw + typów TypeScript bardzo spowalnia rozwój.
 
 W TanStack Start unikasz pułapek specyficznych dla Next.js (`setRequestLocale`, statyczne renderowanie), ale główny problem pozostaje ten sam: bez ścisłej dyscypliny pakiet szybko przenosi zbyt wiele komunikatów, a utrzymanie przestrzeni nazw dla każdej trasy staje się uciążliwe.
 
-**(react-i18next)** (`react-i18next@17.0.2`):
+**(react-i18next)** (`react-i18next@17.0.13`):
 
 `react-i18next` jest prawdopodobnie najpopularniejszą opcją, ponieważ był jedną z pierwszych, która zaspokoiła potrzeby i18n w aplikacjach JavaScript. Posiada on również szeroki zestaw wtyczek społecznościowych dla konkretnych problemów.
 
 Mimo to ma on te same główne wady co stosy zbudowane na `t('a.b.c')`: optymalizacje są możliwe, ale bardzo czasochłonne, a duże projekty niosą ze sobą ryzyko wpadnięcia w złe praktyki (przestrzenie nazw + ładowanie dynamiczne + typy).
 
-Pakiet jest szczególnie ciężki (~17.3kb, co stanowi około 3.5× `react-intlayer`).
+Pakiet jest szczególnie ciężki (~18.4kb, co stanowi około 3.5× `react-intlayer`).
 
 Różnią się również formaty komunikatów: `use-intl` używa ICU MessageFormat, podczas gdy `i18next` używa własnego formatu - co komplikuje narzędzia lub migracje, jeśli się je miesza.
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` jest często chwalony. Osobiście uznałem, że proces pracy wokół `lingui extract` / `lingui compile` jest bardziej złożony niż w przypadku innych podejść, bez wyraźnej przewagi w tym benchmarku TanStack Start. Zauważyłem również niespójne składnie, które mylą AI (np. `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
-**(react-intl)** (`react-intl@10.1.1`):
+**(react-intl)** (`react-intl@10.1.26`):
 
 `react-intl` to wydajna implementacja zespołu Format.js. DX pozostaje rozwlekły: `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` dodaje złożoność, dodatkową pracę JavaScript i wiąże globalną instancję i18n z wieloma węzłami w drzewie React.
 
-Package jest również ciężki (~14.4kb, co stanowi około 3× `react-intlayer`).
+Package jest również ciężki (~15.3kb, co stanowi około 3× `react-intlayer`).
 
 ### 4 - Rekomendacje
 
 Ten benchmark TanStack Start nie ma bezpośredniego odpowiednika `next-translate` (wtyczka Next.js + `getStaticProps`). Dla zespołów, które naprawdę chcą API `t()` z dojrzałym ekosystemem, `react-i18next` i `use-intl` pozostają „rozsądnymi” wyborami, ale przygotuj się na zainwestowanie dużej ilości czasu w optymalizację, aby uniknąć wycieków.
 
-**(Intlayer)** (`react-intlayer@8.7.12`):
+**(Intlayer)** (`react-intlayer@9.5.1`):
 
 Nie będę osobiście oceniał `react-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.
 

package/docs/pl/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: Najlepsze rozwiązanie i18n dla Vue w 2026 r. - raport z benchmarku
 description: Porównaj biblioteki internacjonalizacji (i18n) dla Vue, takie jak vue-i18n, fluent-vue i Intlayer. Szczegółowy raport wydajności dotyczący rozmiaru paczki, wycieków i reaktywności.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Aktualizacja wyników benchmarku"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Dodaj porównanie gwiazdek GitHub"
@@ -62,7 +65,7 @@ Innym skutkiem jest wpływ na doświadczenie programisty (DX): sposób deklarowa
 
 ## TL;DR
 
-- **Intlayer**: Najlżejsze rozwiązanie (v8.7.12) z natywnym scopingiem i dynamicznym ładowaniem.
+- **Intlayer**: Najlżejsze rozwiązanie (v9.5.0) z natywnym scopingiem i dynamicznym ładowaniem.
 - **vue-i18n**: Standard branżowy z bogatym ekosystemem, ale może być znacznie cięższy i trudniejszy do optymalizacji pod kątem code-splittingu w dużych aplikacjach.
 - **fluent-vue**: Innowacyjna organizacja komunikatów, ale brakuje jej bezpieczeństwa typów (type-safety) i okazuje się być ekstremalnie ciężkim rozwiązaniem.
 
@@ -96,7 +99,8 @@ Składnie zbudowane wokół `const { t } = useI18n()` + `t('a.b.c')` są bardzo
 W tym benchmarku porównaliśmy następujące biblioteki:
 
 - `Base App` (Brak biblioteki i18n)
-- `vue-intlayer` (v8.7.12)
+- `vue-intlayer` (v9.5.0)
+- [`@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/compat/vue-i18n.md) (v9.5.1)
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
@@ -156,14 +160,14 @@ Gwiazdki na GitHubie są silnym wskaźnikiem popularności projektu, zaufania sp
 
 - **vue-i18n** jest bezsprzecznie najczęściej używaną biblioteką i18n dla Vue, ma wiele funkcji i ogromny ekosystem. Jednak pod maską rozwiązanie to jest dość ciężkie. Nawet jeśli vue-i18n integruje lazy loading dla komunikatów, brakuje mu funkcji scopingu. W przypadku klasycznej aplikacji Vue SPA nie ma problemu, ale dla aplikacji nuxt wykorzystującej @nuxt/i18n prowadzi to do włączania komunikatów ze wszystkich stron do jednej. W przypadku dużej aplikacji nuxt zawierającej ponad 10 stron może to stać się naprawdę problematyczne.
 
-Paczka jest bardzo ciężka (~24.3kb, co stanowi około 9x `vue-intlayer`).
+Paczka jest bardzo ciężka (~24.3kb, co stanowi około 6x `vue-intlayer`).
 
-**(fluent-vue)** (`fluent-vue@0.5.0`):
+**(fluent-vue)** (`fluent-vue@3.8.2`):
 
-- **fluent-vue** oferuje próbę innowacji poprzez format .ftl. Organizacja komunikatów jest świetna, łatwiej zacząć. Ale w praktyce brak bezpieczeństwa typów zwiększa ryzyko błędu, a debugowanie może szybko stać się czasochłonne. Co więcej, to rozwiązanie ładuje komunikaty za pomocą wtyczki vite, która wymusza ładowanie całej treści we wszystkich językach na każdej stronie. Dodatkowo jest to ekstremalnie ciężkie rozwiązanie (~92.7kb, co stanowi około 34x `vue-intlayer`).
+- **fluent-vue** oferuje próbę innowacji poprzez format .ftl. Organizacja komunikatów jest świetna, łatwiej zacząć. Ale w praktyce brak bezpieczeństwa typów zwiększa ryzyko błędu, a debugowanie może szybko stać się czasochłonne. Co więcej, to rozwiązanie ładuje komunikaty za pomocą wtyczki vite, która wymusza ładowanie całej treści we wszystkich językach na każdej stronie. Dodatkowo jest to ekstremalnie ciężkie rozwiązanie (~29.7kb, co stanowi około 7.5x `vue-intlayer`).
 
 ### 3 - Rekomendacje
 
-**(Intlayer)** (`vue-intlayer@8.7.12`):
+**(Intlayer)** (`vue-intlayer@9.5.0`):
 
 Nie będę osobiście oceniać `vue-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.

package/docs/pl/cli/build.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Budowanie słowników
 description: Dowiedz się, jak budować swoje słowniki Intlayer z plików deklaracji treści.
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - cli
   - build
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Dodanie flagi `--ci`"
   - version: 8.1.5
     date: 2026-02-23
     changes: "Dodaj opcję checkTypes"
@@ -92,6 +95,10 @@ To polecenie domyślnie znajdzie Twoje pliki deklaracji treści w ścieżce `./s
 
   > Przykład: `npx intlayer build --no-cache`
 
+- **`--ci`**: Uruchamia polecenie w każdym projekcie Intlayer w monorepo (lub tylko w bieżącym, gdy uruchomione z katalogu projektu). Dane uwierzytelniające dla poszczególnych projektów można wstrzyknąć przez `INTLAYER_PROJECT_CREDENTIALS` — obiekt JSON mapujący ścieżkę projektu na `{ "clientId", "clientSecret" }`.
+
+  > Przykład: `npx intlayer build --ci`
+
 - **`--check-types`**: Sprawdza typy plików deklaracji treści.
 
   > Przykład: `npx intlayer build --check-types`

package/docs/pl/cli/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Zarządzanie konfiguracją
 description: Dowiedz się, jak pobrać i przesłać swoją konfigurację Intlayer do CMS.
 keywords:
@@ -51,6 +51,7 @@ bun x intlayer configuration get
 - **`--base-dir`**: Określ katalog bazowy projektu.
 - **`--verbose`**: Włącz szczegółowe logowanie w celu debugowania. (domyślnie true przy użyciu CLI)
 - **`--no-cache`**: Wyłącz pamięć podręczną.
+- **`--ci`**: Uruchamia polecenie w każdym projekcie Intlayer w monorepo (lub tylko w bieżącym, gdy uruchomione z katalogu projektu). Dane uwierzytelniające dla poszczególnych projektów można wstrzyknąć przez `INTLAYER_PROJECT_CREDENTIALS` — obiekt JSON mapujący ścieżkę projektu na `{ "clientId", "clientSecret" }`.
 
 ## Prześlij konfigurację
 
@@ -84,5 +85,6 @@ bun x intlayer configuration push
 - **`--base-dir`**: Określ katalog bazowy projektu.
 - **`--verbose`**: Włącz szczegółowe logowanie w celu debugowania. (domyślnie true przy użyciu CLI)
 - **`--no-cache`**: Wyłącz pamięć podręczną.
+- **`--ci`**: Uruchamia polecenie w każdym projekcie Intlayer w monorepo (lub tylko w bieżącym, gdy uruchomione z katalogu projektu). Dane uwierzytelniające dla poszczególnych projektów można wstrzyknąć przez `INTLAYER_PROJECT_CREDENTIALS` — obiekt JSON mapujący ścieżkę projektu na `{ "clientId", "clientSecret" }`.
 
 Poprzez przesłanie konfiguracji, Twój projekt jest w pełni zintegrowany z Intlayer CMS, co umożliwia płynne zarządzanie słownikami w zespołach.

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

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2026-06-17
+updatedAt: 2026-09-12
 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:
@@ -16,6 +16,9 @@ slugs:
   - cli
   - doc-review
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Dodanie flagi `--ci`"
   - version: 9.0.0
     date: 2026-06-17
     changes: "Dodaj opcję --log"
@@ -138,6 +141,10 @@ Niezależnie od trybu, uruchomienie kończy się synteezą zawierającą listę
 
   > Przykład: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: Uruchamia polecenie w każdym projekcie Intlayer w monorepo (lub tylko w bieżącym, gdy uruchomione z katalogu projektu). Dane uwierzytelniające dla poszczególnych projektów można wstrzyknąć przez `INTLAYER_PROJECT_CREDENTIALS` — obiekt JSON mapujący ścieżkę projektu na `{ "clientId", "clientSecret" }`.
+
+  > Przykład: `npx intlayer doc review --ci`
+
 **Opcje logowania:**
 
 - **`--verbose`**: Włącz szczegółowe logowanie do debugowania. (domyślnie true przy użyciu CLI)

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

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Tłumaczenie dokumentu
 description: Dowiedz się, jak automatycznie tłumaczyć pliki dokumentacji za pomocą usług tłumaczenia AI.
 keywords:
@@ -113,6 +113,10 @@ bun x intlayer doc translate
 
   > Przykład: `npx intlayer doc translate --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: Uruchamia polecenie w każdym projekcie Intlayer w monorepo (lub tylko w bieżącym, gdy uruchomione z katalogu projektu). Dane uwierzytelniające dla poszczególnych projektów można wstrzyknąć przez `INTLAYER_PROJECT_CREDENTIALS` — obiekt JSON mapujący ścieżkę projektu na `{ "clientId", "clientSecret" }`.
+
+  > Przykład: `npx intlayer doc translate --ci`
+
 **Opcje logowania:**
 
 - **`--verbose`**: Włącz szczegółowe logowanie do debugowania. (domyślnie true przy użyciu CLI)

package/docs/pl/cli/extract.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Wyodrębnianie stringów
 description: Dowiedz się, jak wyodrębnić stringi z Twoich komponentów do pliku .content umieszczonego blisko komponentu.
 keywords:
@@ -69,6 +69,7 @@ Ten polecenie analizuje pliki z kodem, aby wyodrębnić stringi z komponentów d
 - **`--env`**: Określa środowisko.
 - **`--env-file`**: Wskazuje niestandardowy plik środowiska.
 - **`--verbose`**: Włącza szczegółowe logowanie.
+- **`--ci`**: Uruchamia polecenie w każdym projekcie Intlayer w monorepo (lub tylko w bieżącym, gdy uruchomione z katalogu projektu). Dane uwierzytelniające dla poszczególnych projektów można wstrzyknąć przez `INTLAYER_PROJECT_CREDENTIALS` — obiekt JSON mapujący ścieżkę projektu na `{ "clientId", "clientSecret" }`.
 
 **Wymagane wtyczki:**
 

package/docs/pl/cli/fill.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Wypełnianie słowników
 description: Dowiedz się, jak wypełniać, audytować i tłumaczyć swoje słowniki za pomocą AI.
 keywords:
@@ -162,6 +162,10 @@ Affected dictionary keys for processing: app, comp-test, hello-world, lang-switc
 
   > Przykład: `npx intlayer build --no-cache`
 
+- **`--ci`**: Uruchamia polecenie w każdym projekcie Intlayer w monorepo (lub tylko w bieżącym, gdy uruchomione z katalogu projektu). Dane uwierzytelniające dla poszczególnych projektów można wstrzyknąć przez `INTLAYER_PROJECT_CREDENTIALS` — obiekt JSON mapujący ścieżkę projektu na `{ "clientId", "clientSecret" }`.
+
+  > Przykład: `npx intlayer fill --ci`
+
 **Opcje przygotowania:**
 
 - **`--build`**: Buduj słowniki przed wysłaniem, aby zapewnić aktualność zawartości. Wartość true wymusi budowanie, false pominie budowanie, undefined pozwoli na użycie pamięci podręcznej budowania.