NEVER hardcode user-visible English strings in production code. ALWAYS use an i18n key for visible copy, placeholders, accessible labels, tooltips, menus, dialogs, empty states, and displayed errors.
When migrating existing copy to i18n, preserve the English text byte-for-byte unless the task explicitly requests a copy change.
NEVER change existing English text or English keys to facilitate translation. English is intentional, designer-written source copy; adapt locale-specific translations and i18n mechanics around it.
Keep locale and grammar logic behind the shared typed i18n API. Session components should use t(...), plural(...), parts(...), or pluralParts(...); they must not inspect locales, choose plural categories, construct category-suffixed keys, or assemble translated grammatical fragments.
Prefer complete phrase templates with typed rich slots for styled values. If the current API cannot express a phrase, deepen the shared context instead of leaking locale mechanics into session components.
Do not translate from model knowledge alone. Verify terminology and grammar with Unicode CLDR locale/plural data, Microsoft Localization Style Guides and terminology, Apple localization/style guidance and localized platform UI, Mozilla localization style guides, Mozilla Pontoon, and the Firefox localization corpus at github.com/mozilla-l10n/firefox-l10n.
Also use the relevant language authority or official dictionary for the locale (for example RAE/Fundéu, FranceTerme, Duden, TDK, Kotus/Kielitoimiston sanakirja, Språkrådet/Bokmålsordboka, Rada Języka Polskiego/PWN, the Russian and Arabic language academies, the Ukrainian Orthography, Taiwan MOE dictionaries, or the Royal Society of Thailand). Treat the English dictionary as the semantic source of truth and preserve placeholders, code identifiers, product names, and keyboard labels.