i18n Guideline

Tech Stack

• •i18n: next-intl
• •Framework: Next.js

Non-Negotiables

• •/en/* must not exist (permanently redirect to non-prefixed)
• •Missing translation keys must fail build
• •No hardcoded user-facing strings outside localization
• •Translation bundles must be split by namespace or route (no monolithic language files)

Context

Internationalization isn't just translation — it's making the product feel native to each market. Bad i18n is obvious to users and signals that they're second-class citizens. Good i18n is invisible.

Consider: dates, numbers, currency, pluralization, text direction, cultural norms. Does the product feel like it was built for each locale, or does it feel like a translation of an English product?

Driving Questions

• •What would make the product feel native to a non-English user?
• •Where do translations feel awkward or machine-generated?
• •What cultural assumptions are baked into the UX that don't translate?
• •How painful is the translation workflow for adding new strings?
• •What locales are we missing that represent real market opportunity?
• •Where do we fall back to English in ways users would notice?
• •How large are the translation bundles, and what's being sent to the client?

Bundle Constraints

• •No monolithic language files — split by namespace (common, auth, dashboard, etc.)
• •Server Components for translations wherever possible — client bundles must not include translations that could stay on server
• •Each route should load only its required namespaces
• •Measure client bundle size impact of translations