Przejdź do głównej treści
Wdrożenia

React i18n

Wdrażamy internacjonalizację w aplikacjach React i Next.js. Porównujemy biblioteki, konfigurujemy routing językowy, implementujemy pluralizację i optymalizujemy performance.

react-i18next, next-intl, react-intl czy Lingui? Każda biblioteka ma swoje mocne strony. Dobieramy rozwiązanie do Twojego stacku i wymagań.

Co wdrażamy:

  • Wybór i konfiguracja biblioteki i18n
  • Routing językowy (/pl, /en, /de)
  • Pluralizacja i formatowanie (ICU)
  • SSR/SSG z tłumaczeniami
  • Lazy loading namespaces
  • Type-safe translation keys

Porównanie bibliotek i18n

4 najpopularniejsze biblioteki do internacjonalizacji React. Każda ma inne mocne strony.

react-i18next

9k+ GitHub stars

Uniwersalny standard

  • Pełne wsparcie React 18+ i Next.js
  • Namespaces i lazy loading
  • Pluralizacja (ICU + custom)
  • SSR/SSG przez next-i18next
  • Ogromna społeczność i ekosystem
  • Integracja z Lokalise, Crowdin
const { t } = useTranslation("ns"); return <h1>{t("hero.title")}</h1>;

Rekomendacja: Większość projektów React i Next.js. Największy ekosystem, najlepsza dokumentacja.

next-intl

2k+ GitHub stars

Natywny dla Next.js App Router

  • Pełne wsparcie App Router i RSC
  • Type-safe z TypeScript
  • ICU MessageFormat
  • Middleware routing per locale
  • Formatowanie dat, liczb, walut
  • Mały bundle size
const t = useTranslations("ns"); return <h1>{t("hero.title")}</h1>;

Rekomendacja: Projekty Next.js z App Router. Najlepsza integracja z RSC i server components.

react-intl (FormatJS)

14k+ GitHub stars (FormatJS)

ICU MessageFormat native

  • Pełny ICU MessageFormat
  • Zaawansowane formatowanie (daty, waluty, listy)
  • Compile-time extraction
  • Polyfills dla Intl API
  • Używany przez duże firmy (Yahoo, Airbnb)
  • Rich text formatting
const intl = useIntl(); return <h1>{intl.formatMessage({ id: "hero.title" })}</h1>;

Rekomendacja: Projekty wymagające zaawansowanego formatowania ICU i compliance z międzynarodowymi standardami.

Lingui

4k+ GitHub stars

Minimalny bundle, compile-time

  • Ekstrakcja compile-time (nie runtime)
  • Minimalny bundle size (~3kB)
  • ICU MessageFormat
  • Macro-based API (babel plugin)
  • Wsparcie React i React Native
  • CLI do ekstrakcji i kompilacji
const { t } = useLingui(); return <h1>{t`Hero title`}</h1>;

Rekomendacja: Projekty wrażliwe na bundle size. Mobile-first, PWA, aplikacje z rygorystycznymi limitami performance.

Kroki implementacji

1

Wybór biblioteki

Analiza wymagań projektu (SSR, bundle size, ICU) i rekomendacja.

2

Konfiguracja

Instalacja, konfiguracja providera, middleware (Next.js), ustawienia języków.

3

Struktura plików

Organizacja katalogów: locales/[lang]/[namespace].json. Konwencja kluczy.

4

Ekstrakcja stringów

Zamiana hardcoded tekstów na wywołania t(). Obsługa atrybutów, alt, placeholder.

5

Pluralizacja i formatowanie

Implementacja form liczebnikowych, dat, walut, list. Testowanie per język.

6

Routing językowy

Konfiguracja /pl, /en, /de routing, middleware detekcji, cookie preference.

7

Testy i QA

Sprawdzenie brakujących kluczy, overflow UI, RTL, formularzy, SEO (hreflang).

SSR i Server Components

Server Components (RSC)

next-intl i react-i18next obsługują RSC. Tłumaczenia mogą być ładowane server-side bez hydration mismatch. Klucz to osobny provider per request.

Static Generation (SSG)

generateStaticParams z listą locale generuje statyczne strony per język. Tłumaczenia bundlowane build-time. Najlepsza performance.

Hydration mismatch

Częsty problem: server renderuje w jednym języku, client w innym. Rozwiązanie: initial locale z cookie/header, nie z localStorage.

Middleware routing

Next.js middleware do detekcji języka z Accept-Language header, cookie lub URL prefix. Redirect do właściwej wersji.

Optymalizacja performance

Lazy loading namespaces

Ładuj tylko tłumaczenia potrzebne na danej stronie. Dynamiczny import per namespace zmniejsza initial bundle nawet o 80%.

Compile-time extraction

Lingui i FormatJS wspierają ekstrakcję w build time. Tłumaczenia są kompilowane do zoptymalizowanego formatu, mniejszy runtime overhead.

Server-side loading

Ładuj tłumaczenia na serwerze (getServerSideProps / RSC). Client nie musi pobierać plików JSON osobnym requestem.

Cache i preload

Cache tłumaczeń w memory (i18next-http-backend). Preload następnego języka przy hover na selektorze. Service Worker cache.

Najczęstsze błędy w React i18n

Tłumaczenia w komponentach zamiast w plikach

Hardcoded: const label = language === "pl" ? "Zapisz" : "Save". To anty-pattern. Wszystkie stringi powinny być w plikach JSON, nie w logice komponentu.

Brak namespace splitting

Jeden ogromny plik en.json na 10 tys. kluczy. Rozdziel na namespaces: common, auth, checkout, dashboard. Ładuj per strona.

Formatowanie dat w stringach

"Data: " + date.toLocaleDateString(). Używaj Intl.DateTimeFormat lub formatDate z biblioteki i18n. Każdy locale ma inny format.

Ignorowanie kontekstu przy tłumaczeniu

Klucz "open" bez kontekstu. Czy to "Otwórz" (plik), "Otwarte" (status sklepu), "Rozpocznij" (sesja)? Dodawaj context lub description.

Brak type safety

t("typo.in.key") nie rzuci błędu. Używaj typed keys (next-intl, lingui) lub sprawdzaj brakujące klucze w CI pipeline.

Wdrożymy i18n w Twojej aplikacji React

Dobierzemy bibliotekę, skonfigurujemy routing i przetłumaczymy aplikację. Wyślij link do repo lub opis stacku technicznego.

Powiązane usługi

Wdrożenie JSON i18n

Struktura kluczy, pluralizacja, walidacja

Więcej

Integracje TMS

Lokalise, Crowdin, POEditor

Więcej

Lokalizacja szablonów

Ekstrakcja stringów, funkcje i18n

Więcej

Wdrożenie Weglot

Automatyczne tłumaczenie z korektą

Więcej

SEO wielojęzyczne

Hreflang, meta tagi, routing

Więcej

Tłumaczenie stron WWW

Pełna lokalizacja stron internetowych

Więcej