Internationalization (i18n) Setup

You are a frontend internationalization architect who has built multi-language applications serving users across dozens of countries and languages. Create a comprehensive i18n implementation plan for the following project.

Project Details:
Framework: [NEXT.JS/REACT/VUE/ANGULAR]
Target Languages: [LIST OF LANGUAGES]
RTL Language Support: [YES/NO]
i18n Library Preference: [NEXT-INTL/REACT-INTL/I18NEXT/NONE YET]
Content Source: [STATIC FILES/CMS/TRANSLATION SERVICE/MIXED]
URL Strategy: [SUBDIRECTORY/SUBDOMAIN/DOMAIN PER LOCALE]

Section 1 - Architecture and Library Setup:
Define the i18n library selection and justify the choice between next-intl for Next.js projects, react-intl for React applications, or i18next with its rich ecosystem based on the project framework and requirements. Establish the translation file structure organizing translations by locale and then by namespace or feature module so that only the translations needed for the current page are loaded rather than the entire translation catalog. Create the locale detection and routing system that determines the user locale from the Accept-Language header on first visit, the URL path or subdomain on subsequent requests, and a stored preference cookie for returning users. Specify the type-safe translation key approach using TypeScript to generate types from the default language file ensuring that all translation key references are valid at compile time and that missing translations are caught before deployment. Address the server component and client component translation strategy in Next.js App Router projects specifying how translations are loaded on the server, passed to client components, and how to avoid shipping the full translation bundle to the browser.

Section 2 - Translation Management and Workflow:
Design the translation workflow from developer adding a new string in the default language through translation by professionals to deployment of the translated content. Create the translation key naming convention using a hierarchical dot-separated format like page.settings.profile.title that communicates the context of the string to translators. Establish the ICU MessageFormat usage guidelines for handling pluralization, gender, select patterns, and number and date formatting within translation strings rather than concatenating translated fragments in code. Specify the translation memory and glossary management approach ensuring consistent terminology across the application and reuse of previously translated strings. Address the translation service integration using platforms like Crowdin, Lokalise, or Phrase that synchronize translation files with the code repository and provide context screenshots to translators.

Section 3 - Date, Number, and Currency Formatting:
Define the date formatting strategy using the Intl.DateTimeFormat API with locale-aware presets for common patterns like short date, long date, relative time, and date ranges that automatically format correctly for each locale. Create the number formatting approach using Intl.NumberFormat for decimal numbers, percentages, and compact notation that respects locale-specific digit grouping, decimal separators, and numeral systems. Establish the currency formatting system that displays amounts in the correct format for the user locale including currency symbol placement, decimal precision, and the distinction between the transaction currency and the display locale. Specify the relative time formatting using Intl.RelativeTimeFormat for displaying time distances like two hours ago, yesterday, or in three days that update appropriately as time passes. Address the time zone handling strategy including how to store timestamps in UTC, display times in the user local time zone, and handle date inputs where the user intent might be a local date rather than a UTC timestamp.

Section 4 - RTL Support and Bidirectional Layout:
Design the RTL layout implementation using CSS logical properties like margin-inline-start instead of margin-left and padding-inline-end instead of padding-right that automatically flip in RTL contexts. Create the bidirectional text handling strategy using the dir attribute, the Unicode Bidirectional Algorithm, and explicit directional marks for strings that mix LTR and RTL content. Establish the icon and image mirroring rules specifying which icons should mirror in RTL layouts such as arrows and navigation icons and which should not such as clock hands and universally recognized symbols. Specify the CSS approach for handling layout differences beyond simple mirroring including text alignment, flex direction, absolute positioning, and transform origins that need to change between LTR and RTL. Address the testing strategy for RTL layouts including how to test with actual RTL languages, how to use pseudo-localization to simulate RTL during development, and how to catch RTL bugs in the CI pipeline.

Section 5 - Content Localization Beyond Text:
Define the image and media localization strategy for content that includes text in images, culturally specific imagery, or videos that need subtitles or dubbing in target languages. Create the SEO localization approach including translated meta tags, hreflang annotations, localized URL slugs, and separate sitemap generation per locale. Establish the legal and compliance localization for content that varies by jurisdiction like privacy policies, terms of service, cookie notices, and data handling disclosures. Specify the user-generated content handling in multilingual applications including language detection, translation suggestions, and how to display content in languages the user has not selected. Address the locale-specific feature configuration for features that should only appear in certain markets, content that has different regulations per country, and payment methods or integrations that vary by region.

Section 6 - Testing, Performance, and Maintenance:
Define the pseudo-localization testing strategy that replaces strings with accented characters and extended lengths during development to catch truncation issues, hard-coded strings, and concatenation problems before actual translation. Create the translation coverage monitoring system that tracks which strings are translated in each language, which translations are stale because the source string changed, and which new strings need translation. Establish the performance optimization for i18n including lazy loading translation namespaces per route, minimizing the client-side translation bundle size, and caching compiled ICU messages to avoid reparsing on every render. Specify the locale switching UX including the language selector placement and design, how to handle unsaved form data when switching locales, and whether the page should reload or update in place. Address the ongoing maintenance workflow for keeping translations current including how translators are notified of new strings, how translation reviews are conducted, and how to handle the gap between adding a new feature in the default language and having it translated for all markets.