@intlayer/docs 8.9.4-canary.0 → 8.9.5

package/docs/pl/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+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:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inicjalizacja benchmarku"
+---
+
+# Biblioteki i18n dla Solid — raport z benchmarku 2026
+
+Ta strona zawiera raport z benchmarku rozwiązań i18n dla Solid.
+
+## Spis treści
+
+<Toc/>
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Referencja wyników:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+Pełne repozytorium benchmarku znajdziesz [tutaj](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Wstęp
+
+Rozwiązania do internacjonalizacji należą do najcięższych zależności w aplikacji Solid. Głównym ryzykiem jest wysyłanie niepotrzebnych treści: tłumaczeń dla innych stron i innych lokalizacji w paczce (bundle) pojedynczej trasy.
+
+W miarę rozwoju aplikacji problem ten może szybko zwiększyć ilość JavaScriptu wysyłanego do klienta i spowolnić nawigację.
+
+W praktyce, w przypadku najmniej zoptymalizowanych implementacji, strona zinternacjonalizowana może okazać się kilkukrotnie cięższa niż wersja bez i18n.
+
+Innym skutkiem jest wpływ na doświadczenie programisty (DX): sposób deklarowania treści, typy, organizacja przestrzeni nazw (namespaces), dynamiczne ładowanie i reaktywność przy zmianie lokalizacji.
+
+## TL;DR
+
+- **Intlayer**: Zalecany wybór dla profesjonalnych aplikacji Solid wymagających zaawansowanych funkcji i optymalizacji (v8.7.12).
+- **@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.
+- **Paraglide**: Innowacyjne podejście, ale złożone DX i problemy z tree-shakingiem w niektórych konfiguracjach.
+
+## Przetestuj swoją aplikację
+
+Aby szybko wykryć problemy z wyciekami i18n, przygotowałem darmowy skaner dostępny [tutaj](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Problem
+
+Dwa dźwignie są kluczowe dla ograniczenia kosztów aplikacji wielojęzycznej:
+
+- Dzielenie treści według stron / przestrzeni nazw, aby nie ładować całych słowników, gdy nie są potrzebne.
+- Dynamiczne ładowanie odpowiedniej lokalizacji tylko wtedy, gdy jest potrzebna.
+
+Zrozumienie technicznych ograniczeń tych podejść:
+
+**Dynamiczne ładowanie**
+
+Bez dynamicznego ładowania większość rozwiązań przechowuje komunikaty w pamięci od pierwszego renderowania, co dodaje znaczny narzut w przypadku aplikacji z wieloma trasami i lokalizacjami.
+
+Dzięki dynamicznemu ładowaniu akceptujesz kompromis: mniej początkowego JS, ale czasami dodatkowe zapytanie przy zmianie języka.
+
+**Dzielenie treści (Splitting)**
+
+Składnie zbudowane wokół `t('a.b.c')` są bardzo wygodne, ale często zachęcają do utrzymywania dużych obiektów JSON w czasie wykonywania. Ten model utrudnia tree-shaking, chyba że biblioteka oferuje rzeczywistą strategię dzielenia na poszczególne strony.
+
+## Metodologia badań
+
+W tym benchmarku porównaliśmy następujące biblioteki:
+
+- `Base App` (Brak biblioteki i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Framework to `Solid` z aplikacją wielojęzyczną składającą się z **10 stron** i **10 języków**.
+
+Porównaliśmy **cztery strategie ładowania**:
+
+| Strategia                | Brak przestrzeni nazw (globalna)                  | Z przestrzeniami nazw (scoped)                                                   |
+| :----------------------- | :------------------------------------------------ | :------------------------------------------------------------------------------- |
+| **Ładowanie statyczne**  | **Static**: Wszystko w pamięci przy starcie.      | **Scoped static**: Podział na przestrzenie nazw; wszystko ładowane przy starcie. |
+| **Ładowanie dynamiczne** | **Dynamic**: Ładowanie na żądanie na lokalizację. | **Scoped dynamic**: Szczegółowe ładowanie na przestrzeń nazw i lokalizację.      |
+
+## Podsumowanie strategii
+
+- **Static**: Proste; brak opóźnień sieciowych po początkowym załadowaniu. Minus: duży rozmiar paczki.
+- **Dynamic**: Zmniejsza początkową wagę (lazy-loading). Idealne, gdy masz wiele lokalizacji.
+- **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.
+
+## Wyniki szczegółowe
+
+### 1 — Rozwiązania, których należy unikać
+
+> W ekosystemie Solid nie ma jednoznacznego rozwiązania, którego należy unikać.
+
+### 2 — Rozwiązania akceptowalne
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`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`).
+
+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).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+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` 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.
+Wreszcie, w porównaniu z innymi rozwiązaniami, Paraglide nie używa store'a (np. Solid signal) do pobierania aktualnej lokalizacji w celu renderowania treści. Dla każdego sparsowanego węzła będzie żądać lokalizacji z localStorage / cookie itp. Prowadzi to do wykonywania niepotrzebnej logiki, która wpływa na reaktywność komponentu.
+
+### 3 — Rekomendacje
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Nie będę osobiście oceniać `solid-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.
+
+### Notatka osobista
+
+Ta notatka jest osobista i nie wpływa na wyniki benchmarku. Mimo to w świecie i18n często widać konsensus wokół wzorca takiego jak `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` dla treści przetłumaczonych.
+
+W aplikacjach Solid wstrzykiwanie funkcji jako `JSX.Element` jest moim zdaniem antywzorcem. Dodaje to również złożoność, której można uniknąć, oraz narzut na wykonywanie JavaScriptu (nawet jeśli jest on ledwo zauważalny).

package/docs/pl/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+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:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inicjalizacja benchmarku"
+---
+
+# Biblioteki i18n dla Svelte — raport z benchmarku 2026
+
+Ta strona zawiera raport z benchmarku rozwiązań i18n dla Svelte.
+
+## Spis treści
+
+<Toc/>
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## Referencja wyników:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
+
+Pełne repozytorium benchmarku znajdziesz [tutaj](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Wstęp
+
+Rozwiązania do internacjonalizacji należą do najcięższych zależności w aplikacji Svelte. Głównym ryzykiem jest wysyłanie niepotrzebnych treści: tłumaczeń dla innych stron i innych lokalizacji w paczce (bundle) pojedynczej trasy.
+
+W miarę rozwoju aplikacji problem ten może szybko zwiększyć ilość JavaScriptu wysyłanego do klienta i spowolnić nawigację.
+
+W praktyce, w przypadku najmniej zoptymalizowanych implementacji, strona zinternacjonalizowana może okazać się kilkukrotnie cięższa niż wersja bez i18n.
+
+Innym skutkiem jest wpływ na doświadczenie programisty (DX): sposób deklarowania treści, typy, organizacja przestrzeni nazw (namespaces), dynamiczne ładowanie i reaktywność przy zmianie lokalizacji.
+
+## TL;DR
+
+- **Intlayer**: Najbardziej wydajny wybór (v8.7.12) 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).
+
+## Przetestuj swoją aplikację
+
+Aby szybko wykryć problemy z wyciekami i18n, przygotowałem darmowy skaner dostępny [tutaj](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Problem
+
+Dwa dźwignie są kluczowe dla ograniczenia kosztów aplikacji wielojęzycznej:
+
+- Dzielenie treści według stron / przestrzeni nazw, aby nie ładować całych słowników, gdy nie są potrzebne.
+- Dynamiczne ładowanie odpowiedniej lokalizacji tylko wtedy, gdy jest potrzebna.
+
+Zrozumienie technicznych ograniczeń tych podejść:
+
+**Dynamiczne ładowanie**
+
+Bez dynamicznego ładowania większość rozwiązań przechowuje komunikaty w pamięci od pierwszego renderowania, co dodaje znaczny narzut w przypadku aplikacji z wieloma trasami i lokalizacjami.
+
+Dzięki dynamicznemu ładowaniu akceptujesz kompromis: mniej początkowego JS, ale czasami dodatkowe zapytanie przy zmianie języka.
+
+**Dzielenie treści (Splitting)**
+
+Składnie zbudowane wokół `t('a.b.c')` są bardzo wygodne, ale często zachęcają do utrzymywania dużych obiektów JSON w czasie wykonywania. Ten model utrudnia tree-shaking, chyba że biblioteka oferuje rzeczywistą strategię dzielenia na poszczególne strony.
+
+## Metodologia badań
+
+W tym benchmarku porównaliśmy następujące biblioteki:
+
+- `Base App` (Brak biblioteki i18n)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Framework to `Svelte` z aplikacją wielojęzyczną składającą się z **10 stron** i **10 języków**.
+
+Porównaliśmy **cztery strategie ładowania**:
+
+| Strategia                | Brak przestrzeni nazw (globalna)                  | Z przestrzeniami nazw (scoped)                                                   |
+| :----------------------- | :------------------------------------------------ | :------------------------------------------------------------------------------- |
+| **Ładowanie statyczne**  | **Static**: Wszystko w pamięci przy starcie.      | **Scoped static**: Podział na przestrzenie nazw; wszystko ładowane przy starcie. |
+| **Ładowanie dynamiczne** | **Dynamic**: Ładowanie na żądanie na lokalizację. | **Scoped dynamic**: Szczegółowe ładowanie na przestrzeń nazw i lokalizację.      |
+
+## Podsumowanie strategii
+
+- **Static**: Proste; brak opóźnień sieciowych po początkowym załadowaniu. Minus: duży rozmiar paczki.
+- **Dynamic**: Zmniejsza początkową wagę (lazy-loading). Idealne, gdy masz wiele lokalizacji.
+- **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.
+
+## Wyniki szczegółowe
+
+### 1 — Rozwiązania, których należy unikać
+
+> W ekosystemie Svelte nie ma jednoznacznego rozwiązania, którego należy unikać.
+
+### 2 — Rozwiązania akceptowalne
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`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.
+Workflow i DX są również bardziej złożone niż w przypadku innych opcji.
+Osobiście nie jestem fanem konieczności regeneracji plików JS przed każdym pushem, co stwarza ciągłe ryzyko konfliktów przy mergowaniu poprzez PR-y. 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 store'a (np. Svelte store) do pobierania aktualnej lokalizacji w celu renderowania treści. Dla każdego sparsowanego węzła będzie żądać lokalizacji z localStorage / cookie itp. Prowadzi to do wykonywania niepotrzebnej logiki, która wpływa na reaktywność komponentu.
+
+> 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, 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`):
+
+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`).
+
+### 3 — Rekomendacje
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+Nie będę osobiście oceniać `svelte-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.
+
+### Notatka osobista
+
+Ta notatka jest osobista i nie wpływa na wyniki benchmarku. Mimo to w świecie i18n często widać konsensus wokół wzorca takiego jak `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` dla treści przetłumaczonych.
+
+W aplikacjach Svelte wstrzykiwanie funkcji jako `Slot` jest moim zdaniem antywzorcem. Dodaje to również złożoność, której można uniknąć, oraz narzut na wykonywanie JavaScriptu (nawet jeśli jest on ledwo zauważalny).

package/docs/pl/benchmark/tanstack.md

@@ -57,6 +57,13 @@ W praktyce, w przypadku najmniej zoptymalizowanych implementacji, strona zintern
 
 Inny wpływ dotyczy doświadczenia programisty (DX): sposobu deklarowania treści, typów, organizacji przestrzeni nazw, ładowania dynamicznego i reaktywności przy zmianie lokalizacji.
 
+## TL;DR
+
+- **Intlayer**: Zapewnia najlepszą wydajność i najmniejszy rozmiar pakietu (v8.7.12) 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).
+
 ## Przetestuj swoją aplikację
 
 Aby szybko wykryć problemy z wyciekami i18n, przygotowałem darmowy skaner dostępny [tutaj](https://intlayer.org/i18n-seo-scanner).
@@ -87,12 +94,12 @@ 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.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,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.
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> 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.
+
+**(Tolgee)** (`@tolgee/react@7.0.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.
 

package/docs/pl/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+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:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - wydajność
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inicjalizacja benchmarku"
+---
+
+# Biblioteki i18n dla Vue — raport z benchmarku 2026
+
+Ta strona zawiera raport z benchmarku rozwiązań i18n dla Vue.
+
+## Spis treści
+
+<Toc/>
+
+## Interaktywny benchmark
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## Referencja wyników:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
+
+Pełne repozytorium benchmarku znajdziesz [tutaj](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Wstęp
+
+Rozwiązania do internacjonalizacji należą do najcięższych zależności w aplikacji Vue. Głównym ryzykiem jest wysyłanie niepotrzebnych treści: tłumaczeń dla innych stron i innych lokalizacji w paczce (bundle) pojedynczej trasy.
+
+W miarę rozwoju aplikacji problem ten może szybko zwiększyć ilość JavaScriptu wysyłanego do klienta i spowolnić nawigację.
+
+W praktyce, w przypadku najmniej zoptymalizowanych implementacji, strona zinternacjonalizowana może okazać się kilkukrotnie cięższa niż wersja bez i18n.
+
+Innym skutkiem jest wpływ na doświadczenie programisty (DX): sposób deklarowania treści, typy, organizacja przestrzeni nazw (namespaces), dynamiczne ładowanie i reaktywność przy zmianie lokalizacji.
+
+## TL;DR
+
+- **Intlayer**: Najlżejsze rozwiązanie (v8.7.12) 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.
+
+## Przetestuj swoją aplikację
+
+Aby szybko wykryć problemy z wyciekami i18n, przygotowałem darmowy skaner dostępny [tutaj](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Problem
+
+Dwa dźwignie są kluczowe dla ograniczenia kosztów aplikacji wielojęzycznej:
+
+- Dzielenie treści według stron / przestrzeni nazw, aby nie ładować całych słowników, gdy nie są potrzebne.
+- Dynamiczne ładowanie odpowiedniej lokalizacji tylko wtedy, gdy jest potrzebna.
+
+Zrozumienie technicznych ograniczeń tych podejść:
+
+**Dynamiczne ładowanie**
+
+Bez dynamicznego ładowania większość rozwiązań przechowuje komunikaty w pamięci od pierwszego renderowania, co dodaje znaczny narzut w przypadku aplikacji z wieloma trasami i lokalizacjami.
+
+Dzięki dynamicznemu ładowaniu akceptujesz kompromis: mniej początkowego JS, ale czasami dodatkowe zapytanie przy zmianie języka.
+
+**Dzielenie treści (Splitting)**
+
+Składnie zbudowane wokół `const { t } = useI18n()` + `t('a.b.c')` są bardzo wygodne, ale często zachęcają do utrzymywania dużych obiektów JSON w czasie wykonywania. Ten model utrudnia tree-shaking, chyba że biblioteka oferuje rzeczywistą strategię dzielenia na poszczególne strony.
+
+## Metodologia badań
+
+W tym benchmarku porównaliśmy następujące biblioteki:
+
+- `Base App` (Brak biblioteki i18n)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+Framework to `Vue` z aplikacją wielojęzyczną składającą się z **10 stron** i **10 języków**.
+
+Porównaliśmy **cztery strategie ładowania**:
+
+| Strategia                | Brak przestrzeni nazw (globalna)                  | Z przestrzeniami nazw (scoped)                                                   |
+| :----------------------- | :------------------------------------------------ | :------------------------------------------------------------------------------- |
+| **Ładowanie statyczne**  | **Static**: Wszystko w pamięci przy starcie.      | **Scoped static**: Podział na przestrzenie nazw; wszystko ładowane przy starcie. |
+| **Ładowanie dynamiczne** | **Dynamic**: Ładowanie na żądanie na lokalizację. | **Scoped dynamic**: Szczegółowe ładowanie na przestrzeń nazw i lokalizację.      |
+
+## Podsumowanie strategii
+
+- **Static**: Proste; brak opóźnień sieciowych po początkowym załadowaniu. Minus: duży rozmiar paczki.
+- **Dynamic**: Zmniejsza początkową wagę (lazy-loading). Idealne, gdy masz wiele lokalizacji.
+- **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 technologicznego, a następnie zanotowałem, co faktycznie przesłała sieć i ile czasu zajęły poszczególne operacje. Rozmiary są podawane **po normalnej kompresji internetowej**, ponieważ jest to bliższe temu, co ludzie faktycznie pobierają, niż surowa liczba linii kodu źródłowego.
+
+- **Rozmiar biblioteki internacjonalizacji**: Po spakowaniu (bundling), tree-shakingu i minifikacji, rozmiar biblioteki i18n to rozmiar kodu providerów + composables w pustym komponencie. Nie obejmuje ładowania plików tłumaczeń. Odpowiada na pytanie, jak „droga” jest biblioteka, zanim Twoja treść wejdzie do gry.
+
+- **JavaScript na stronę**: Dla każdej trasy benchmarku, ile skryptów przeglądarka pobiera dla tej wizyty, uśrednione dla stron w zestawie (i dla lokalizacji). Ciężkie strony to wolne strony.
+
+- **Wycieki z innych lokalizacji (Leakage)**: To treść tej samej strony, ale w innym języku, która zostałaby błędnie załadowana na kontrolowanej stronie. Ta treść jest niepotrzebna i należy jej unikać (np. treść strony `/fr/about` w paczce strony `/en/about`).
+
+- **Wycieki z innych tras**: Ten sam pomysł dla **innych ekranów** w aplikacji: czy ich teksty są dołączane, gdy otworzyłeś tylko jedną stronę (np. treść strony `/en/about` w paczce strony `/en/contact`). Wysoki wynik sugeruje słabe dzielenie lub zbyt szerokie paczki.
+
+- **Średni rozmiar paczki komponentu**: Typowe elementy interfejsu użytkownika są mierzone **pojedynczo**, zamiast ukrywać się w gigantycznej liczbie dla całej aplikacji. Pokazuje to, czy internacjonalizacja po cichu nadyma codzienne komponenty. Na przykład, jeśli Twój komponent renderuje się ponownie, załaduje wszystkie te dane z pamięci. Dołączanie gigantycznego JSON-a do dowolnego komponentu jest jak podłączanie dużego magazynu nieużywanych danych, co spowolni wydajność Twoich komponentów.
+
+- **Reaktywność przełączania języka**: Przełączam język za pomocą własnego sterowania aplikacji i mierzę czas, aż strona wyraźnie się przełączy — co zauważyłby odwiedzający.
+
+- **Praca renderowania po zmianie języka**: Bardziej szczegółowe badanie: ile wysiłku interfejs włożył w ponowne odrysowanie dla nowego języka po rozpoczęciu zmiany. Przydatne, gdy „odczuwalny” czas i koszt frameworka się rozbiegają.
+
+- **Czas początkowego ładowania strony**: Od nawigacji do momentu, w którym przeglądarka uzna stronę za w pełni załadowaną dla testowanych przeze mnie scenariuszy. Dobre do porównywania „zimnych startów”.
+
+- **Czas hydratacji (Hydration)**: Czas, jaki klient spędza na przekształcaniu HTML z serwera w interaktywny interfejs. Myślnik w tabelach oznacza, że ta implementacja nie dostarczyła wiarygodnej liczby dotyczącej hydratacji w tym benchmarku.
+
+## Wyniki szczegółowe
+
+### 1 — Rozwiązania, których należy unikać
+
+> W ekosystemie Vue nie ma jednoznacznego rozwiązania, którego należy unikać.
+
+### 2 — Rozwiązania akceptowalne
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **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`).
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **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`).
+
+### 3 — Rekomendacje
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+Nie będę osobiście oceniać `vue-intlayer` ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.

package/docs/pl/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-13
-updatedAt: 2026-04-08
+updatedAt: 2026-05-12
 title: Konfiguracja
 description: Dowiedz się, jak skonfigurować Intlayer dla swojej aplikacji. Zrozum różne ustawienia i opcje dostępne do dostosowania Intlayer do Twoich potrzeb.
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - concept
   - configuration
 history:
+  - version: 8.9.4
+    date: 2026-05-12
+    changes: "Dodano obsługę dostawcy LM Studio"
   - version: 8.7.0
     date: 2026-04-08
     changes: "Dodano opcje `prune` i `minify` do konfiguracji budowania"
@@ -350,7 +353,7 @@ const config: IntlayerConfig = {
   ai: {
     /**
      * Wybrany dostawca AI.
-     * Opcje: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai'
+     * Opcje: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai', 'lmstudio'
      * Domyślnie: 'openai'
      */
     provider: "openai",
@@ -916,16 +919,17 @@ Intlayer obsługuje szeroką gamę dostawców AI, aby zapewnić maksymalną elas
 - **Groq**
 - **Amazon Bedrock**
 - **Together.ai**
-
-| Pole                 | Opis                                                                                                                                 | Typ                                                                                                                                                                                                                                                                                                                                                                                            | Domyślnie   | Przykład                                                      | Uwagi                                                                                                                                                                                        |
-| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `provider`           | Dostawca, który będzie używany do funkcji AI w Intlayer.                                                                             | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` | `undefined` | `'anthropic'`                                                 | Różni dostawcy wymagają różnych kluczy API i mają różne cenniki.                                                                                                                             |
-| `model`              | Model AI do użycia w funkcjach AI.                                                                                                   | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Brak        | `'gpt-4o-2024-11-20'`                                         | Konkretne modele zależą od dostawcy.                                                                                                                                                         |
-| `temperature`        | Kontroluje losowość odpowiedzi AI.                                                                                                   | `number`                                                                                                                                                                                                                                                                                                                                                                                       | Brak        | `0.1`                                                         | Wyższa temperatura = bardziej kreatywne, ale mniej niezawodne odpowiedzi.                                                                                                                    |
-| `apiKey`             | Twój klucz API dla wybranego dostawcy.                                                                                               | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Brak        | `process.env.OPENAI_API_KEY`                                  | Musi pozostać tajny; używaj zmiennych środowiskowych.                                                                                                                                        |
-| `applicationContext` | Dodatkowy kontekst o Twojej aplikacji, aby pomóc AI generować dokładniejsze tłumaczenia (domena, grupa docelowa, ton, terminologia). | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Brak        | `'mój własny kontekst aplikacji'`                             | Można użyć do dodania zasad (np.: `"Nie powinieneś tłumaczyć swoich URL"` ).                                                                                                                 |
-| `baseURL`            | Bazowy URL dla API AI.                                                                                                               | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Brak        | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Może wskazywać na lokalne lub własne punkty końcowe API AI.                                                                                                                                  |
-| `dataSerialization`  | Format serializacji danych dla funkcji AI.                                                                                           | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                 | `undefined` | `'toon'`                                                      | • `'json'`: domyślnie, niezawodne; zużywa więcej tokenów.<br/>• `'toon'`: mniej tokenów, mniej stabilne.<br/>• Przekazuje modelowi kontekst jako dodatkowy parametr (reasoning effort itp.). |
+- **LM Studio**
+
+| Pole                 | Opis                                                                                                                                 | Typ                                                                                                                                                                                                                                                                                                                                                                                                                      | Domyślnie   | Przykład                                                      | Uwagi                                                                                                                                                                                        |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `provider`           | Dostawca, który będzie używany do funkcji AI w Intlayer.                                                                             | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` &#124; <br/> `'lmstudio'` | `undefined` | `'anthropic'`                                                 | Różni dostawcy wymagają różnych kluczy API i mają różne cenniki.                                                                                                                             |
+| `model`              | Model AI do użycia w funkcjach AI.                                                                                                   | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Brak        | `'gpt-4o-2024-11-20'`                                         | Konkretne modele zależą od dostawcy.                                                                                                                                                         |
+| `temperature`        | Kontroluje losowość odpowiedzi AI.                                                                                                   | `number`                                                                                                                                                                                                                                                                                                                                                                                                                 | Brak        | `0.1`                                                         | Wyższa temperatura = bardziej kreatywne, ale mniej niezawodne odpowiedzi.                                                                                                                    |
+| `apiKey`             | Twój klucz API dla wybranego dostawcy.                                                                                               | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Brak        | `process.env.OPENAI_API_KEY`                                  | Musi pozostać tajny; używaj zmiennych środowiskowych.                                                                                                                                        |
+| `applicationContext` | Dodatkowy kontekst o Twojej aplikacji, aby pomóc AI generować dokładniejsze tłumaczenia (domena, grupa docelowa, ton, terminologia). | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Brak        | `'mój własny kontekst aplikacji'`                             | Można użyć do dodania zasad (np.: `"Nie powinieneś tłumaczyć swoich URL"` ).                                                                                                                 |
+| `baseURL`            | Bazowy URL dla API AI.                                                                                                               | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Brak        | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Może wskazywać na lokalne lub własne punkty końcowe API AI.                                                                                                                                  |
+| `dataSerialization`  | Format serializacji danych dla funkcji AI.                                                                                           | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                                           | `undefined` | `'toon'`                                                      | • `'json'`: domyślnie, niezawodne; zużywa więcej tokenów.<br/>• `'toon'`: mniej tokenów, mniej stabilne.<br/>• Przekazuje modelowi kontekst jako dodatkowy parametr (reasoning effort itp.). |
 
 ---