Internationalization and Localization
Pathrule2 Rules • 2 Memories • 1 Skill
Internationalization and localization require more than replacing visible strings because locale affects routing, formatting, plural rules, text direction, metadata, assets, and layout. This bundle defines canonical locale negotiation, message ownership, Intl formatting, bidi-safe rendering, and release checks. Unlike React TypeScript, it owns language and cultural behavior rather than component typing and React architecture.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
release-localization
src/
routes/
Resolve one canonical locale before rendering
components/
Format user-facing values with locale-aware APIs
Bidirectional text needs metadata and isolation
i18n/
Message identifiers describe meaning, not English wording
Rules
2Resolve one canonical locale before rendering/src/routeshighstrictRouting, server data, metadata, messages, and client hydration consume the same validated locale value.
| 1 | Routing, server data, metadata, messages, and client hydration consume the same validated locale value. When URL, profile, cookie, browser preference, and deployment default are resolved independently, the server and client can render different languages or cache one user's locale for another. Enforce this boundary in /src/routes so invalid work stops before it reaches another subsystem or creates an externally visible side effect. |
| 2 | |
| 3 | - Define precedence and supported fallback in one server-side resolver, then redirect or rewrite unsupported locale forms to a canonical route. |
| 4 | - Carry locale through data loading, metadata, cache keys, and hydration rather than reading browser globals in render code. |
| 5 | - Keep language, region, and text direction as separate values; language alone does not always determine direction or business region. |
| 6 | - Use locale-neutral identifiers in application state and persistence so translated labels never become keys. |
| 7 | |
| 8 | Verification: Request every supported, aliased, unsupported, missing, and malformed locale through server render and client navigation; confirm one canonical URL and no hydration mismatch. |
Format user-facing values with locale-aware APIs/src/componentshighstrictDates, times, numbers, currency, units, lists, and plurals use Intl or an equivalent locale engine at the display boundary.
| 1 | Dates, times, numbers, currency, units, lists, and plurals use Intl or an equivalent locale engine at the display boundary. String concatenation and hand-authored plural branches fail for grouping, decimal digits, calendars, time zones, grammar, and currency conventions outside the developer's locale. Enforce this boundary in /src/components so invalid work stops before it reaches another subsystem or creates an externally visible side effect. |
| 2 | |
| 3 | - Keep stored and transported values locale-neutral, including ISO timestamps, numeric amounts with currency, and stable enum identifiers. |
| 4 | - Format with an explicit locale and time zone where the product promises one; never rely on a server's process defaults. |
| 5 | - Use plural and select messages from the catalog rather than constructing sentences around translated fragments. |
| 6 | - Parse user-entered localized values with a deliberate product flow; do not assume display formatting is safely reversible. |
| 7 | |
| 8 | Verification: Snapshot representative values across supported locales, time zones, plural categories, currencies, negative amounts, and daylight changes; verify semantics, not only visual text. |
Memories
2Message identifiers describe meaning, not English wording/src/i18nKeys copied from source text become unstable when English changes and tempt translators to reuse a sentence whose context differs.
| 1 | Keys copied from source text become unstable when English changes and tempt translators to reuse a sentence whose context differs. Use stable semantic identifiers scoped to the product surface and provide description, variables, plural behavior, and screenshots or usage context where tooling supports them. |
| 2 | |
| 3 | Keep whole translatable sentences together instead of concatenating fragments. Require named variables with clear types and escape rules. Retire obsolete keys through extraction and usage checks so stale translations do not mask missing coverage. Keep the decision explicit at /src/i18n; moving it into an incidental caller makes behavior depend on which route happened to execute first. |
| 4 | |
| 5 | See /src/components for rendering context and the localization release skill for catalog validation. That related boundary consumes this decision and carries the evidence that proves it still holds. |
Bidirectional text needs metadata and isolation/src/componentsRight-to-left layout direction and the direction of an embedded user string are separate concerns, especially for mixed names, numbers, code, URLs, and identifiers.
| 1 | Right-to-left layout direction and the direction of an embedded user string are separate concerns, especially for mixed names, numbers, code, URLs, and identifiers. Set document or region direction from resolved locale, then isolate unknown-direction content with appropriate HTML direction semantics. |
| 2 | |
| 3 | Prefer logical CSS properties such as inline-start and inline-end over left and right for layout behavior. Do not reverse icons or timelines unless their meaning is directional in that culture. Test keyboard order, focus, tables, charts, truncation, and copy behavior under mixed-direction content. Keep the decision explicit at /src/components; moving it into an incidental caller makes behavior depend on which route happened to execute first. |
| 4 | |
| 5 | See /src/routes for canonical locale and /src/i18n for string direction metadata. That related boundary consumes this decision and carries the evidence that proves it still holds. |
Skills
1release-localization/rootRelease a locale with complete catalogs, formatting evidence, route checks, bidi coverage, and fallback behavior.
| 1 | --- |
| 2 | name: release-localization |
| 3 | description: Release a locale with complete catalogs, formatting evidence, route checks, bidi coverage, and fallback behavior. |
| 4 | --- |
| 5 | |
| 6 | # Release Localization |
| 7 | |
| 8 | Run this procedure whenever the governed surface changes or its operational evidence becomes stale. |
| 9 | |
| 10 | 1. Freeze the source catalog, extract used keys, remove obsolete entries, and provide translators with variable types, plural context, descriptions, and screenshots. |
| 11 | 2. Validate catalog syntax, required variables, plural categories, rich-text tags, unsafe markup, missing messages, and unintended fallback to the source language. |
| 12 | 3. Run route, metadata, server-render, hydration, formatting, input, accessibility, text expansion, and right-to-left checks with representative production content. |
| 13 | 4. Roll out the locale with explicit fallback and monitoring for missing messages, route errors, layout failures, and support feedback; record ownership for updates. |
| 14 | |
| 15 | Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory. |
Why this pattern
Agents hard-code strings and dates, infer text direction from language incorrectly, mix locale sources, or ship translated text without testing routes and layout expansion.
Built for Frontend teams serving products in multiple languages, regions, scripts, or cultural formats.
Keeps your assistant from:
- Different locale values in URL, cookie, server render, and client state
- Hand-built date, number, currency, and plural formatting
- Right-to-left or expanded translations breaking layout and interaction
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-08-25