React & Next.js Localisation
Organise i18next translations into namespaces — one JSON file per feature area rather than one large file per locale. A typical structure has a common namespace for shared UI labels, separate namespaces for authentication, checkout, and dashboard, and a namespace per page route. Load namespaces lazily using the i18next backend plugin so each route only loads the strings it needs, keeping initial bundle size small. This also makes it easier to assign translation work by feature area without translators touching unrelated strings.
Name translation keys semantically: button.submit is more stable than submit_button_label_text, and survives a copy change without requiring a key rename and code update. Avoid constructing keys dynamically at runtime — dynamic key construction breaks static analysis tools that scan for untranslated strings and prevents Language Monster from detecting new content reliably. In React, use the Trans component for strings that embed JSX elements such as links or bold spans — never split a sentence across multiple keys just to insert an inline element.
In Next.js, configure i18n in next.config.js with your full locales list, defaultLocale, and consider disabling localeDetection if you manage detection in middleware. Use next-i18next for server-rendered pages — it loads only the namespaces each page needs via getServerSideProps or getStaticProps, avoiding the full locale bundle on every request. For the App Router, follow the parallel route group pattern per locale to keep SSR locale resolution clean.
Connect your GitHub, Bitbucket, or Azure Repos repository to Language Monster. Language Monster detects your locale file structure automatically, maps keys across all language files, and pushes completed translations back to a branch for your standard pull request review — keeping translation inside your existing code review pipeline. Nested JSON structure, interpolation placeholders, and i18next plural key suffixes are preserved through every translation job.
Run eslint-plugin-i18next in your CI pipeline to catch hardcoded strings that have not been extracted to translation keys. Language Monster's quality controls check placeholder integrity, spelling, grammar, and number formatting on every saved string — errors are caught at translation time rather than code review. Translation Memory means identical strings across namespaces are matched and applied without re-translation cost.