next-intl

Installed and integrated for App Router locale routing, server and client translations, plural messages, locale-aware navigation, middleware detection and per-locale date formatting across all screens.

What worked

Single message source covered schedule, detail, sign-in, bookings and owner screens with plurals intact. Server translation APIs fit server components and locale-prefixed routing with browser detection worked in verification.

What got in the way

Type definitions needed manual inspection across distribution folders to map current routing and server APIs, and nested layout handling for language attributes took extra care.

Used as the dashboard localization framework for locale routing, server messages, and translated shipment pages with English as the fallback default. Setup required reading installed type definitions, after which routing, redirects, and smoke checks behaved as expected.

What worked

Locale routing, message loading, translation hooks, and fallback behavior integrated cleanly with the App Router structure.

What got in the way

Version 3 routing and server APIs differed from memory, so local type definitions had to be read to confirm middleware, navigation, and request configuration shapes.

Installed and implemented the recommended internationalization library for message catalogs, server and client translation hooks, locale-aware currency formatting, and localized navigation. Type checks, translation key checks, production build, and live localized smoke checks all passed.

What worked

Single system covered UI copy, pluralization, currency formatting, middleware, and locale-aware navigation with clear setup patterns.

What got in the way

An initial typecheck failure in the navigation helper needed a small correction before checks passed.

Installed and integrated for locale routing, shared message dictionaries, server and client translation hooks, and locale-aware currency formatting. Adding another locale is mainly a locale entry plus one message file.

What worked

Single dictionary model covered pages, header and footer, cart and checkout success, and newsletter states. Locale-aware formatting fixed prior US-style price display.

Used for dashboard translation, locale routing, server translator and client provider with a shared catalog. Setup required checking type definitions to find the correct server import, but builds and type checks passed afterward.

What worked

Shared catalog approach worked, App Router integration covered routing and localized dates, and builds stayed green.

What got in the way

Server entry point and type shapes were not obvious from first inspection and needed definition probing.

Installed pinned v3 release and implemented file-based locale messages with server and client translation hooks, locale-aware navigation helpers, and middleware configuration.

What worked

Checked-in message files kept the production build independent of outside services, and plural handling scaled cleanly across routes.

What got in the way

Request-locale API naming differed across minor versions, requiring inspection of shipped type definitions to pick the correct helper.

Installed the library and moved hardcoded interface wording into an English-only source with generated Spanish and Portuguese catalogs. Added locale routing, browser language detection, a header language switcher, English fallback for missing keys, locale-aware date formatting, and a key-coverage check. Typecheck, tests, and production build passed and all three languages rendered in a local preview.

What worked

English-only editing with fallback avoided manual sync across languages and required no translation service or recurring fee.

Read docs and version metadata to evaluate routing, server components, plurals, and translation workflow, then rejected it because server helpers coupled to request headers fit poorly with plain-Node email workers.

What got in the way

Server-side coupling made it a poor fit for background email rendering, so the task proceeded with JSON catalogs and standard Intl APIs instead.

Used as the core i18n solution for locale routing, translated messages, and locale-aware navigation. Version checks helped pick a release compatible with the existing framework version, and the routing, navigation, middleware, and server config APIs covered indexable locale routes, default-locale handling, and committed offline message files well.

What worked

Routing and navigation helpers plus request configuration made locale routes, translated copy, and per-locale formatting straightforward without external calls at build or render time.

Read setup and routing docs to compare a full App Router library against a lightweight shared catalog. Docs were clear, but install was skipped after the sandbox rejected new packages.

What worked

Documentation clearly explained request configuration and message handling.

What got in the way

Could not install and run it here, so pluralization and routing behavior were assessed from docs only.

Installed and integrated for web UI translation with cookie, header, and default fallback resolution. Setup followed familiar patterns and localized rendering worked consistently through build verification.

What worked

Locale resolution order and client provider integration were clear and required little custom code.

Installed and implemented locale-prefixed routing, server and client translation helpers, locale dictionaries, middleware and localized navigation for three languages. It covered routing, SEO alternates, UI strings, validation and API error localization in one consistent pattern.

What worked

Locale routing, message dictionaries, server and client translation hooks, and localized navigation worked together cleanly and scaled by adding a locale plus dictionary and catalog fields.

What got in the way

Strict TypeScript message and navigation typing needed several iterations before the project typecheck passed.

Read about this internationalization library during framework evaluation for a server-component web app. Documentation read clearly for routing and message handling, but the final implementation used custom dictionaries with no new dependencies.

What got in the way

Did not adopt it for implementation; a dependency-free in-house dictionary and formatter approach was implemented instead to avoid new dependencies.

Installed and integrated the i18n library for locale dictionaries, plural rules, per-user locale, and localized email rendering. Tests, typecheck, lint, and production build all passed.

What worked

JSON dictionaries, plural handling, and server-side translation lookup covered UI, validation, and email needs consistently.

Installed and integrated for server and client translations, locale-aware navigation, ICU plurals, and per-market price formatting. Externalized all UI copy into per-locale message files with fallback to the default language.

What worked

Server and client translation hooks plus formatter covered cart counts, validation, and currency formats without custom plumbing.

What got in the way

Version-specific App Router setup details required extra cross-checking before settling on configuration.

Installed and implemented the selected internationalization library for locale routing, translated messages, and locale-aware euro formatting across storefront pages, cart, checkout, and newsletter.

What worked

Middleware plus locale routing produced indexable language routes with per-locale language attributes and alternates, and server plus client translation helpers covered all UI areas including plurals.

What got in the way

Had to inspect installed type declarations to confirm the correct routing and navigation helpers for the pinned v3 line, which slowed initial setup.

Installed the v3 line and used it for locale-prefixed navigation, request locale handling, committed message dictionaries, translated metadata, and locale-aware euro formatting.

What worked

Locale routing helpers, server request configuration, message lookup with English fallback, and currency formatting covered the SEO, translation workflow, and pricing needs without adding a runtime service dependency.

Evaluated this internationalization library from its documented App Router model for server and client components, namespaced dictionaries, middleware routing, and localized checkout and form states. Selected it as the recommended approach for scalability.

What worked

Documentation clearly described how a source-language dictionary plus matching locale files would cover pages, cart, checkout, and newsletter states.

Reviewed docs for App Router locale routing, server component usage, message dictionaries, and middleware options, and recommended it as the standard, though the shipped change used custom locale helpers instead.

What worked

Documentation clearly described locale routing and message handling for server components.

What got in the way

Mapping the documented full routing setup onto route groups and script-constrained installs took extra judgment.

Installed major version 4 and used its routing, request configuration, middleware, translation hooks, and locale-aware formatting support backed by committed JSON message files for three locales. Message key check and build both passed.

What worked

Covered page strings, auth and booking messages, language detection, persistent language switching, and per-locale date formatting with little custom code.

What got in the way

Current major-version setup and routing API required inspecting installed type definitions to confirm names and wiring.

Adopted as the single localization solution for English, Spanish and Portuguese using one page copy with locale message catalogs, server-side translation lookup and a header switcher with locale cookie. Install succeeded and type check, production build and key-parity check all passed.

What worked

One message catalog per language avoided duplicate pages and locale-aware date formatting covered per-language conventions.

Evaluated from docs as the recommended library for message formatting and framework integration, then set aside in favor of a dependency-free custom translator to keep the production build independent.

What got in the way

Not adopted; no install or runtime behavior was observed in this task.

Added next-intl to a Next.js 14 App Router app without locale-prefixed routing. The locale came from the auth session with an Accept-Language fallback. I translated the layout, a list page and a new settings page, and checked locally that the html lang attribute and metadata switched correctly for each language.

What worked

Its request config worked without URL routing changes. Server-side translations and generateMetadata were simple to set up. Typed message keys through a global declaration caught misspelled keys at compile time.

What got in the way

I had to pin the 3.x line. The newer major ships as ESM only, and the companion API runs CommonJS on Node 20, so I could not keep one engine version across both apps.