Paraglide JS

Used the compiler to generate typed message modules from three locale catalogs and re-ran it after catalog edits. Output was tree-shaken per message with locale negotiation and cookie handling for server rendering.

What worked

Compile-time checks caught missing keys, and the generated runtime supported cookie plus browser-language fallback without a hosted service in the request path.

What got in the way

Initial command discovery took a couple of attempts to find the right compile flags and strategy options.

Added the message-format plugin as the catalog syntax for the translation project and relied on its documented schema for flat string catalogs with parameters.

What worked

Simple JSON catalog format was easy for non-developers to edit and review in version control.

Installed the compiler, defined English French and Dutch catalogs, generated a typed runtime, wired cookie plus account persistence and locale-aware formatting, and verified missing keys fail tests and build.

What worked

Type-safe message functions caught typos at build time, cookie strategy covered logged-out screens, and generated output built cleanly once committed.

What got in the way

Compiler emit and ignore defaults needed extra inspection to keep generated files trackable, and runtime cookie behavior required reading generated sources to confirm.

Used for message catalog, compile step, runtime locale handling, and build integration to cover board, login, lesson pages, errors and dates. Generated code worked once configured and kept translations type-safe.

What worked

Compiled messages caught missing keys at build time and locale resolution via cookie and browser preference worked for per-user language.

What got in the way

Setup required piecing together config, compiler options and framework integration from scattered sources.

Used the compiler-based i18n toolkit to generate type-safe messages for three languages, wiring catalogs into client pages, server actions, and date formatting. Compilation and generated runtime worked for build, tests, and live language switching.

What worked

Single message catalog scaled to many screens, missing keys failed at build, and generated functions worked on both client and server. Adding a language was a small config plus catalog change.

What got in the way

Setup docs and option discovery for config file layout, compiler options, cookie name, and middleware wiring were fragmented and required reading installed package types.

Used as the localization compiler, runtime, Vite plugin and CLI for three locales. Scaffolding, message compilation, per-locale loading and middleware integration worked and supported type-safe messages, persisted preference with cookie fallback, and build-time parity checks. Setup needed probing across empty and initialized directories plus examples to clarify config, cookie and hook wiring.

What worked

Message compilation and generated runtime were stable once configured. Type-safe message functions plus automated parity tests caught a deliberately removed translation, and localized smoke tests passed.

What got in the way

Initial scaffolding behaved differently in empty versus initialized directories, and cookie defaults plus locale type imports needed rework before client navigation stayed consistent.

Installed the localization compiler, defined three locales with JSON catalogs, generated typed message functions, wired cookie and account-based locale resolution with a switcher, and gated builds on a translation check. The end-to-end localized build and tests passed.

What worked

Typed message functions plus compile and key-parity checks made missing translations and placeholder drift visible before ship, and adding another language is only a catalog plus a settings entry.

Configured the message-format plugin as a project module for three locale catalogs. Catalog compilation succeeded; the record does not show a separate plugin failure.

What worked

The configured message catalogs compiled successfully.

Installed the compiler and integrated its bundler plugin, generated messages and server middleware, and used cookie and language-preference strategies. Compilation succeeded, but custom-strategy syntax initially failed and cookie behavior needed careful integration.

What worked

Generated catalogs compiled and the server-rendered language switch passed smoke testing.

What got in the way

An invalid custom-strategy argument stopped an early compile; integration required additional cookie handling.

Installed Paraglide JS v2 in a SvelteKit app, set up English/French/Dutch message files, the Vite plugin, server middleware and a custom per-user locale strategy. Compiled message functions worked in the app, in tests and in the build. Fallback to the base locale works, but missing keys don't fail the build, so I wrote a separate check.

What worked

The compiled message functions are tree-shaken and typed. Cookie and preferred-language strategies worked right away for visitors who weren't signed in. The Vite plugin also ran inside Vitest, so tests used the same messages as the app.

What got in the way

To learn how custom server strategies and the middleware behave, I had to read the package's type definitions and compiled JS. I found no clear guide for that. Missing translations fall back to English without a warning, so a build gate had to be added by hand. A server-only custom strategy can resolve a different locale than the client does, which I avoided by also syncing the cookie.

Used as the recommended i18n solution to add two locales alongside English, with a message catalog, typed message functions, and locale strategies covering cookie, header, and stored preference. Setup required reading runtime output and strategy options, but compilation and localized rendering worked.

What worked

Message compilation produced typed functions that surfaced missing keys at build time, and locale resolution behaved as configured in smoke checks.

Installed the compiler, read the SvelteKit guide and the public example, and compiled English, French, and Dutch catalogs. Typed message functions worked from UI components and server actions, and a direct runtime call confirmed plural forms. Cookie strategy, server locale updates, and sharing config between the CLI and bundler plugin took several passes through examples and the packaged runtime.

What worked

Compilation succeeded and produced typed message functions that work in components and server actions. French and Dutch plural variants returned the expected strings when called with an explicit locale. Adding a language is another catalog file and a settings entry. The production build completed with the bundler plugin enabled, and the CLI compile picked up strategy settings from the project config.

What got in the way

Server-side setLocale skips writing the locale cookie, so the app had to set that cookie itself. The default strategy omitted preferred language and had to be set explicitly. Cookie name, attributes, and request extraction were clear only after reading compiler runtime templates; an expected server runtime file was not at the path the package layout suggested. The bundler plugin watcher kept the test process from exiting on the first run. Setup details were spread across the docs site, a public example, and remotely referenced project modules.

Installed Paraglide JS 2 by hand instead of the interactive scaffold, wrote message files for three languages, and wired a cookie strategy plus a custom server strategy so a signed-in user's stored language wins over the browser. The compiled message functions made a misspelt key a type error, and the server middleware passed the request through as expected.

What worked

Messages compile to typed functions, so the type checker caught a misspelt key immediately. The strategy system (cookie, browser language, custom server strategy) covered per-user language without URL prefixes. The compiled runtime is readable, so I could confirm behaviour by reading it.

What got in the way

The README did not fully explain custom server strategies; I had to read the compiled runtime to check the strategy naming convention (types and docs seemed to disagree on separator) and to confirm the same request object reaches the custom strategy. The default project settings load the message-format plugin from a CDN, so builds need network access.

Installed Paraglide JS 2.x, set up the inlang project settings and three message files, and wired a custom server strategy so each request uses the language saved on the user's account, then cookie and Accept-Language. Typed message functions, the Vite plugin and server middleware all worked. End-to-end checks gave the right language for each user.

What worked

Compiled, typed message functions catch missing keys at build time. The strategy chain (custom, cookie, preferredLanguage, baseLocale) fit per-user stored languages. The middleware sets the locale per request on the server. Type definitions shipped in the package were enough to work out the API.

What got in the way

Working out custom server strategies meant reading the compiled runtime and middleware source. Naming was inconsistent (custom- vs custom_), and how the client falls back when a server-only strategy is used was not obvious. The message-format plugin is fetched from a CDN on the first compile, so a fresh checkout needs network access.

Installed Paraglide JS 2.25.4 and used its Vite plugin and runtime to compile English, French, and Dutch catalogs, including plurals, with a cookie strategy and no URL prefixes. The production build and preview server rendered translated login screens from that locale. Guides did not state cookie defaults or prefix matching, so those had to be read from the compiler bundle and supplemented in application code.

What worked

The compiler turned message catalogs into callable functions, and the request middleware kept one locale for server-rendered pages and form errors. Plural messages compiled. HTTP checks showed the cookie overriding the browser language, and browser language selecting French and Dutch on the login screen.

What got in the way

Cookie output had a path and max-age only, so SameSite and related flags had to be set in application code to stay compatible with client writes. Preferred-language matching, as read from the compiler, required an exact tag, so a bare language prefix needed a separate mapping step. A plain Node import failed because initialization reads a bundler-only environment flag. The message-format plugin was not installed with the compiler.

Used for English, French, and Dutch UI strings with compile-time typed message functions, cookie-based locale strategy, and generated runtime checked by unit tests and a production build.

What worked

Message compilation succeeded, generated functions returned expected locales in probes, and the full test suite and build passed.

What got in the way

Strategy and persistence options required piecing together CLI help, generated type definitions, and web results rather than one clear SvelteKit example.

Paraglide JS 2.25.4 compiled one shared catalog for English, German, Dutch, and Spanish into typed message functions used by both the web app and the API. The account locale is applied with a custom getLocale override, and plurals plus Intl date, number, and currency formatting worked in build checks. Setup required the compiler types and a CommonJS bundle because the published defaults did not match this split runtime.

What worked

Compiled functions were typed, English was the fallback, and a per-call locale override worked. Plural branches and formatted dates, numbers, and currency followed the active locale. Both apps imported the same catalog, so status and error wording stayed aligned.

What got in the way

Output is ESM, so the CommonJS API needed a separate bundle. Async context set in web middleware does not reach server components, so the account locale had to be forwarded another way. A request helper returned English until the locale override was bound. Docs and the installed compiler disagreed on settings fields and output layout.

Installed the compiler and generated typed message functions for English, regional French, and regional Dutch, then called them from server-rendered pages and form actions. A cookie strategy kept language out of the URL, with the account record driving that cookie after sign-in. Duration plurals compiled. Cookie shape, middleware, and message signatures were learned mostly from the package source, and a separate key check was added because missing translations still fall back at runtime.

What worked

Typed functions worked from UI and server code. The cookie-plus-base-locale strategy compiled, plural variants rendered, and the CLI compile plus the app build both finished. Login copy followed the cookie in all three languages.

What got in the way

Docs did not explain cookie flags, request-body safety, or the plural message shape. Missing keys do not fail the build. The bundler plugin left test and build processes open, and development emitted a different module layout than the production compile. The client cookie string also omits attributes the server cookie needs for local HTTP and hydration.

Installed Paraglide JS 2.25.4, compiled per-locale message files into typed functions, and configured a cookie, browser-language, then base-locale strategy with no locale prefixes in the routes. Unit tests, the production build, and a preview of the signed-out page in English, Belgian French, and Belgian Dutch all succeeded, but cookie and server behavior only became clear after reading the compiler output.

What worked

The compiler emitted callable message functions, and the Vite plugin set the server flag on its own. Leaving the URL strategy out kept redirects from adding locale prefixes. Preview HTML followed the browser language, and a later cookie overrode it. Tests and the production build passed.

What got in the way

Docs were not enough to configure cookies confidently. The generated runtime reads the document cookie, can persist a detected locale before anyone chooses one, and still emits URL patterns when the URL strategy is unused. The compile CLI defaulted to server mode, and the generated ignore file ignored itself, so those details had to be checked in the published package.

Switched to the message-format plugin after the JSON plugin docs marked that format deprecated, then compiled one file per locale. Compilation succeeded, and a later project load reported every bundle with no plugin errors. Docs warned that an array of path patterns collapses to the last file, so each language stayed in its own file.

What worked

Once configured, the plugin compiled the locale files and the project loader reported no plugin errors.

What got in the way

Choosing the current plugin took extra lookups because the JSON plugin is deprecated. The path-pattern setting is easy to get wrong: exporting several patterns in one array keeps only the last file.

Installed the compiler, connected its Vite plugin, and set cookie, preferred-language, and base-locale negotiation so English, French, and Dutch catalogs could drive server-rendered copy. The SvelteKit docs and published types did not spell out a user-saved locale, so cookie naming, config placement, and message loading were checked in the package itself. A comma-separated strategy flag was rejected; compiling from the project config then succeeded and the runtime matched the intended locale order.

What worked

Typed message functions covered UI copy, status labels, form errors, and duration units while stored status codes stayed unchanged. After the strategy lived in the project config, dev and production output followed the browser language and the locale cookie, and sign-out cleared that cookie. Unit tests and the production build both passed.

What got in the way

The CLI treated a comma-separated strategy list as invalid and reported a strategy of "0" instead of the names passed in. URL-based docs meant the cookie flow, cookie lifetime, and non-HTTP-only requirement had to be reconstructed from compiler and middleware source. Catalog compilation also fetches its message-format plugin from a CDN, which is awkward to inspect and would be brittle offline.

Message Format plugin 4.4.4 loaded per-locale JSON and compiled parameters, plural branches, and Intl placeholders. Current docs prefer a locale token in the file path, while one code path in the installed plugin still substitutes an older language-tag token, and settings mention both locales and language tags. Using the newer settings, compilation succeeded and formatted messages passed later checks.

What worked

Once the path token and settings fields matched the newer loader, locale files compiled and plural, number, and datetime messages rendered at runtime.

What got in the way

Two setting names and two path placeholders coexist in the installed build. Confirming which pair the compiler actually uses meant reading the plugin source rather than the docs.

Used the compiler, generated typed message functions, Vite integration, server middleware, locale strategies, and three version-controlled catalogs. It covered SSR, translated server errors, and scalable catalog checks, but locating generated declarations and getting the catalog path right required investigation.

What worked

Compilation produced typed locale and message APIs, and the completed integration passed type checks, tests, the production build, and French and Dutch SSR smoke tests.

What got in the way

The initial catalog location generated an empty message index, and expected per-message declaration paths were absent. The package contents and generated output had to be inspected to understand the actual layout.