i18next

Used as the core translation engine for English, French and German using local JSON resource files, with browser language detection and persisted language choice. Setup was straightforward and covered all hardcoded UI strings plus locale-aware Euro formatting support.

What worked

Simple key-based API, local files without any paid service, easy per-locale resources.

Used for binding translations to components, including hooks, language switching, and locale-aware currency formatting. Converted hard-coded strings across all views quickly and the production build passed.

What worked

Hooks and provider integration were clear and made replacing static text with keys routine.

Used as the core translation engine with local JSON dictionaries for three languages plus browser language detection and local storage persistence. Setup was straightforward and covered all screen text without any hosted service.

What worked

Local dictionaries kept owner editing simple, language detection and persistence worked, and no account or fee was needed.

Added the ICU plugin so catalog strings can interpolate values such as an example status label. After the package built, German and Spanish invalid-status messages included the translated example. No plugin-specific type or runtime failures showed up in the API checks or the rendered pages.

What worked

Interpolated status examples came back in the expected language from both a direct filter check and the deployed package. The plugin loaded with the shared i18next instance without further configuration once the package build succeeded.

Used as the core translation engine with English as source and fallback. Installation succeeded cleanly and locale dictionaries covered all buttons, status words, prompts and dialogs. Build and key-parity checks passed.

What worked

Small API, JSON resources were easy to author, fallback to English kept missing keys visible instead of blank.

Installed i18next in a shared catalog package and created a fresh instance for each request so each API caller keeps their own language. English was the fallback. JSON namespaces covered status labels, API errors, and dashboard copy. The same keys rendered in the API and the dashboard for English, German, Dutch, and Spanish.

What worked

Per-request instances, namespace lookups, and the English fallback matched the multi-tenant API and the dashboard. Catalog strings agreed across both callers in all four languages.

What got in the way

The usual process-wide instance would leak one customer's language into another response, so the integration had to be built around a factory. That constraint was not obvious from a quick comparison search and had to be confirmed before wiring the API.

Used i18next as the translation core for a small React/Vite app, with JSON locale files for English, French and German, interpolation for dates, plural handling, English fallback and a language choice saved in localStorage. It installed cleanly from npm, and in a headless browser test every language rendered correctly.

What worked

Plain JSON resource files give non-developers one obvious place to edit wording. Interpolation and fallback to English worked as expected. Setup in a single init module was short.

Used react-i18next to bind four React components to the i18next translations and to add an EN/FR/DE switcher. Switching languages re-rendered all text at once, including strings passed to browser dialogs. The production build passed and the browser test confirmed the behavior.

What worked

The hook-based API made replacing hardcoded strings mechanical. Language changes propagated immediately and survived a reload.

Used for React bindings including hooks and provider plus persisted language selection and browser-language default. Integrated without conflicts with the existing React version and the production build succeeded.

What worked

Hook-based string lookup made component updates straightforward and language switching persisted across reloads.

Installed and configured the CLI for CI extraction, catalog status, generated types, and linting. It ultimately provided a comprehensive missing-translation and hardcoded-text gate.

What worked

The dry-run extraction and CI modes fit the existing checks, and the final validation command passed consistently.

What got in the way

The first CI run reported catalog updates caused only by formatting or ordering, and locating the generated declaration output required inspecting the package's type definitions.

Installed i18next in a shared library and used it as the single lookup path for English, German, Dutch, and Spanish catalogs consumed by both the web app and the API. Lookups, typed keys, and a runtime smoke test across locales all worked after a small type-coercion tweak.

What worked

One lookup helper served dashboard chrome, shipment status and mode labels, and API error text, so wording could not drift. Catalog typing failed the typecheck when locales did not match English, which matched the review-before-release requirement. A Node smoke test returned the expected labels and error strings in all four locales.

What got in the way

Non-string lookup results had to be coerced to strings, and i18next type options needed a small adjustment before typecheck was clean.

Used the i18next v4 JSON catalog format through the localization compiler so the same files could be edited in Weblate and compiled into the app. The format was suitable for plural-aware, versioned catalogs.

What worked

The JSON format provided a practical interchange between the translation editor and application compiler and was straightforward to validate in CI.

What got in the way

Underscores in keys were treated as context separators and silently changed the generated message surface. Switching to stable camel-case IDs avoided this behavior.

Used shared i18next resources for four languages across web and API code. Its fallback, resource, and TypeScript features fit the monorepo well, but an overloaded translation call caused a difficult compile error and a support notice required an additional option to suppress.

What worked

One catalog and key model supported consistent shipment labels and errors in both runtimes. After configuration fixes, builds and runtime translation smoke tests passed for all four languages.

What got in the way

The first typed wrapper selected an incompatible overload and failed compilation with a verbose tuple/type error. The installed runtime also printed an unexpected promotional notice until configuration was adjusted.

Added it so each user's browser language picks the initial language and their explicit choice persists per device. Verified that regional variants of the two non-English languages resolve down to the base language and that a stored choice is read back.

What worked

Default detection order plus local storage persistence needed almost no configuration, and regional variant fallback to the base language worked without me listing variants.

What got in the way

It reaches for browser globals at module load, so exercising the app's real initialisation module from a plain runtime required stubbing a couple of globals in the test harness first.

Installed a pinned 23.15 release in the shared workspace package and used it for typed catalogs, lookup helpers, and locale fallback. Runtime checks on the built package returned the expected strings and default-locale behavior.

What worked

A single helper over static catalogs kept dashboard copy, status labels, and API errors on the same keys. Fallback for an unsupported locale behaved as intended in a quick runtime check.

What got in the way

The 23.15 line was pinned specifically for TypeScript compatibility, and the translate helper’s return type needed extra care so callers could treat results as strings.

Used repository-owned JSON catalogs with fixed-language translation instances to share German, Dutch, Spanish, and English wording across the web dashboard and API. The implementation passed localization, type, lint, and build checks.

What worked

Language fallback, JSON resources, and TypeScript support fit a shared monorepo package cleanly. Fixed-language instances also avoided cross-request locale mutation without sending shipment data to an external service.

Wired the React bindings into four components plus a new language-switcher component. A provider at the app entry point and a hook in each component was the whole integration; switching language re-rendered every component immediately with no extra plumbing.

What worked

The hook-based API dropped straight into existing function components with essentially no restructuring. Live re-render on language change was automatic. It also rendered fine under server-side rendering, which let me verify all three languages headlessly without a browser.

What got in the way

One sharp edge worth knowing: the translate function returned by the hook changes identity when the language changes, so putting it in a memoized callback's dependency list silently re-triggers that callback — in my case it would have refetched data on every language switch. The stable instance object returned alongside it solves this, but the docs don't call out the hazard where someone would hit it.

Installed i18next in the shared package and used one catalog plus t() helpers so the web app, status labels, and API errors shared the same keys and wording across English, German, Dutch, and Spanish.

What worked

The same helper surface worked in the Next.js app and the NestJS API. A runtime check of the built shared package returned matching labels for all four locales, including the customs status.

What got in the way

TypeScript did not copy locale JSON into the build output, so a post-compile file copy was required before the catalogs were available at runtime.

Configured translation resources for three languages with English as the source of truth and editable JSON locale files. The translation integrity check matched all 35 keys and the application built successfully.

What worked

Key-based JSON resources fit the requirement for no-cost localization and allowed French wording to be corrected in one obvious non-code file.

What got in the way

The ecosystem required several companion packages and initialization choices rather than a single dependency with all browser behavior included.

Used the core SDK to build typed English, German, Dutch, and Spanish catalogs shared by server-rendered web pages and an API. Translation output and production builds passed after resolving a TypeScript overload issue and disabling an unwanted support notice.

What worked

One catalog and explicit English fallback worked across both application runtimes, and localized status and error output was successfully exercised.

What got in the way

The first typed translator wrapper did not match the SDK's overloaded function signature, and the default support notice required an additional option.

Configured three JSON catalogs, language selection and persistence, browser-language fallback, and visible development markers for missing keys. The integration passed catalog validation and production compilation.

What worked

The resource-key model fit the requested reviewed-JSON workflow and supported clear missing-key behavior without requiring a translation service.

What got in the way

The record shows some custom setup was still needed for persistence, document language updates, locale formatting, and comprehensive key validation because those concerns were outside the core translation lookup itself.

Used it as the translation layer for a small single-page app with three language catalogs of about 36 keys each. Set up initialization with a default-language fallback, plain JSON resources, and interpolation for a couple of messages that embed a date. Every string resolved correctly when the app was rendered in all three languages.

What worked

Initialization is a single call with an inline resources object, so no loader backend was needed for catalogs this small. Fallback to the default language on a missing key, interpolation, and the language-change event all behaved exactly as documented. Plain JSON catalogs meant non-developers could proofread the wording, which was the deciding factor in choosing it.

What got in the way

Nothing blocking. The init options surface is large relative to what a small app needs, so picking the minimal correct set took a pass through the docs.

Used translation resources, locale switching, saved language selection, and formatting integration to provide complete English, French, and German UI coverage.

What worked

The official guides made the translation and formatting model clear, and focused checks confirmed that every language contained the full set of translation keys.