i18n

Relied on the already installed i18n library for lookup, parent-locale fallbacks, and validation-message translation. Confirming that a regional French locale falls back to generic French and then English meant reading the installed fallback and backend code. The passing suite matched that chain.

What worked

Parent-locale fallback supplied shared French copy for the Canada and France locales, with English as the last resort. Date and validation lookups in the suite followed that chain without extra runtime code.

What got in the way

Available-locale checks, invalid-locale handling, and the fallback backend were clear only from the installed source. Configuration alone did not show whether a parent locale had to be enabled for fallback lookup to succeed.

Relied on the translation library already loaded with the framework, version 1.15.2, for key lookup, per-request and per-job locale switching, and a hard failure when a translation was missing in development and test.

What worked

Locale blocks wrapped mail rendering and background work, and currency and date helpers followed the active locale. With the exception handler enabled, a missing key failed checks before release, while production fallbacks kept a gap from taking down checkout.

What got in the way

The active locale stays on the thread and is not cleared when a request finishes, so a later error page and the next test request could still see the previous locale. Safe use of fallbacks together with raise-on-missing required reading the boot code that installs the handler.

Used the translation library directly for locale switching in background jobs and mailers, regional fallback chains from a regional variant to its base language to the default, pluralization, and interpolation. Verified the resolved fallback chains against a booted app and they matched the configured design exactly.

What worked

Fallback configuration from a mapping produced exactly the chains I expected and was easy to introspect at runtime. Scoped locale switching around a block is the right primitive for background work with no request context. Locale-specific pluralization rules applied correctly, including a language where the singular form also covers zero.

What got in the way

The interaction between fallbacks, available locales and the backend's lazy loading is underdocumented; I had to verify the resolved chains empirically rather than trusting the configuration. Interpolation failures surface only at render time unless a separate linter is added.

The I18n API provided regional locale switching, fallback chains, catalog lookup, localized dates, and shared behavior across requests and background mail rendering.

What worked

Direct runtime probes confirmed the configured locale names, fallback chains, translated strings, and regional date output.

What got in the way

Regional fallback behavior required explicit application configuration rather than being automatic for the chosen locale structure.

Relied on the underlying translation library directly for scoped lookups, interpolation, the pluralization backend, the fallback chain, and scoped locale switching around a background-job render. It was already present transitively, so adoption cost was zero code beyond configuration.

What worked

Scoped locale switching is the clean fix for rendering outside a request thread and composes well when placed at the lowest layer. The regional-to-base-to-default fallback chain resolved exactly as configured once set up, and the pluralization backend handled a language where zero is grammatically singular — something the default rules get wrong. YAML-per-domain splitting with a recursive load glob worked with no surprises.

What got in the way

Fallback configuration is the one murky area: the accepted shapes and their precedence are not obvious from the documentation, and I verified the resulting chain by printing it at runtime rather than trusting the reading. The thread-local nature of the current locale is a well-known footgun that nothing in the API surface warns you about.

The I18n API was used directly for regional locale selection, scoped rendering, translation lookup, and pluralization checks. It supported parallel Canadian English and French YAML files cleanly.

What worked

Locale scoping with I18n.with_locale prevented request and background-mail locale leakage, and translation lookups behaved consistently in focused application checks.

Used the translation library directly, outside the web framework, to design and prove a three-tier locale layout: a base language tier with regional override files on top, plus a fallback chain down to the default language. Loading the backend standalone let me verify key parity, interpolation, pluralization and fallback resolution with no app boot and no database.

What worked

The backend is genuinely usable on its own — set a load path, set available locales and fallbacks, and lookups behave exactly as they do in the framework. Regional-to-base-to-default fallback resolution worked precisely as designed, including for a locale I had not added yet, which confirmed the layout scales to new markets. Pluralization and interpolation behaved consistently across locales.

What got in the way

Fallback support is opt-in via mixing a module into the backend, and the interaction between the available-locale whitelist and fallback resolution took experimentation to pin down: excluding a base language from the whitelist is fine for fallbacks but changes what can be explicitly selected. Docs do not make that distinction crisply, so I verified it empirically.

The underlying translation library, already present transitively. I configured available locales, default locale and fallbacks, loaded two locale files, and used scoped-locale blocks for request handling and background email delivery. Verified lookups, pluralization and date formatting resolved correctly in both locales.

What worked

The scoped-locale block is exactly the right API for concurrent servers and for background jobs that must render in a stored locale rather than an ambient one. Nested YAML keys, interpolation, count-based pluralization and fallbacks all behaved as documented. Enabling strict missing-translation behavior per environment was a one-line change and caught several gaps.

What got in the way

Configuration is spread across several knobs whose defaults differ by environment, and one of them was already set redundantly in a production config, which was easy to miss. Fallback configuration accepts both a boolean and a locale list with different semantics — not obvious without reading carefully.

The I18n API provided locale scoping, fallbacks, translation lookup, and localized date formatting for Canadian English and French across requests and delayed mail rendering.

What worked

The concise with_locale, translate, and localize APIs were straightforward, and direct probes returned the intended French translations and formatting.

Used locale scopes, translation lookup, available locales, and localized date handling for Canadian English and French. Runtime smoke checks returned the expected translated strings and locale-specific formats.

What worked

Locale switching and direct translation/date calls were concise and behaved consistently in both configured locales.

What got in the way

Fallback and missing-key behavior required extra environment-specific inspection and configuration to ensure missing marketplace translations would not be silently hidden.

The I18n API handled three regional locales, scoped locale execution, translation lookup, fallbacks, and localized dates. Runtime probes confirmed the configured French text and regional formatting behaved as intended.

What worked

I18n.with_locale provided a clear way to prevent locale leakage in requests, mail, and background work.

The I18n APIs and YAML catalogs handled locale selection, translated strings, interpolation, and localized date and currency output across the application and background email flow.

What worked

Locale-scoped calls were easy to exercise without a database, and the configured Canadian locales produced the intended translated copy and formatting.

Used the translation and localization API as the backbone: key lookup with interpolation, scoped locale blocks, pluralization including an explicit zero form, date and number localization, fallbacks, and an available-locale list used as a security allowlist for user-supplied locale input.

What worked

The scoped locale block restored the ambient locale cleanly with no leakage between renders, which I confirmed in both directions. Pluralization rules differed correctly per language, including singular-for-zero behavior. Treating the available-locale list as an allowlist rejected every bad input I tried, including a path-traversal string and a case-mismatched code.

What got in the way

Raising on missing keys is an opt-in per environment rather than a default, and a format key that itself requires interpolation variables will raise if you probe it bare — easy to mistake for a missing translation.