Implement Internationalization and Localization

An i18n and L10n reference covering internationalization (making an app translatable) versus localization (the actual translations), locale (language plus region, for example en-US or tr-TR), and RTL (right-to-left languages like Arabic and Hebrew). Provides implementation patterns for React (react-i18next's useTranslation hook), Next.js (next-intl's useTranslations), and Python (gettext's underscore wrapper), plus a recommended locale file structure namespacing translations per language and per feature (common.json, auth.json, errors.json). Best practices: use translation keys rather than raw strings, namespace by feature, support pluralization and per-locale date and number formats via the Intl API, plan for RTL from the start, and use ICU message format for complex strings, while avoiding hardcoded strings, string concatenation, assuming fixed text length (German runs about 30% longer than English), and mixing languages in one file. RTL support is implemented with CSS logical properties, margin-inline-start and padding-inline-end instead of left and right, plus a [dir="rtl"] selector to flip directional icons. A companion scripts/i18n_checker.py script detects hardcoded strings and missing translations across a project. A pre-ship checklist covers translation-key coverage, locale files for every supported language, Intl-based date and number formatting, tested RTL layout, a configured fallback language, and zero hardcoded strings. It also maps common issues to fixes: a missing translation falls back to the default language, hardcoded strings get caught by the linter/checker script, date and number formatting use Intl.DateTimeFormat and Intl.NumberFormat respectively rather than manual string formatting, and pluralization is handled through ICU message format rather than ad hoc string branching.

Need varies by project type: a public web app or SaaS product should treat i18n as required, an internal tool or a currently single-region app should at least consider it for future expansion, and a personal project can treat it as fully optional. Use it whenever a codebase has any realistic path to a second language or region - retrofitting translation keys after strings are already hardcoded throughout components is far more expensive than building them in from the start. Not needed when a project will never ship to more than one language or region and has no plan to.

Input is the codebase's user-facing strings and target locales. Output is a translation-key-based codebase, a locales/<lang>/*.json file structure per language, RTL-aware CSS, and a checker script that flags hardcoded strings and missing translation keys.

python scripts/i18n_checker.py <project_path>

Names react-i18next for React, next-intl for Next.js, gettext for Python, and the runtime Intl.DateTimeFormat and Intl.NumberFormat APIs for locale-aware formatting.

Frontend and full-stack developers preparing an app for multiple languages or regions who need concrete library choices, file structure, and a pre-ship checklist rather than reinventing i18n conventions.