Back to Blog
EngineeringApril 28, 20268 min read

Building Multilingual Apps with Next.js and next-intl

A technical deep-dive into building production-grade multilingual applications using Next.js App Router and next-intl.

Building Multilingual Apps with Next.js and next-intl

Building a multilingual application that feels native in every market is one of the hardest UX engineering challenges. Translation is the easy part — the hard part is designing systems that adapt to cultural context, RTL layouts, locale-specific formatting, and market-specific features, all while maintaining a single, maintainable codebase.

Why next-intl Is the Right Foundation

next-intl is purpose-built for Next.js App Router and provides a type-safe, server-first i18n layer. Unlike react-i18next, it is designed around React Server Components, which means your translations do not bloat the client bundle.

  • Server-side translation rendering with zero client-side hydration overhead for static strings.
  • Type-safe message keys — TypeScript catches missing translations at build time.
  • Built-in ICU message format support for plurals, gender, and rich text.
  • Seamless integration with the App Router's parallel routes and layouts.

Project Structure

The recommended structure wraps your entire app in a [locale] dynamic segment. This gives you automatic locale routing without middleware rewrites, and keeps your server components clean.

Design your locale routing before writing a single component. Retrofitting i18n into a large Next.js app is significantly more expensive than designing for it from day one.

Cultural Adaptation Beyond Translation

The most common mistake in multilingual apps is treating i18n as a pure translation problem. True localization includes formatting, layout, and product decisions.

  • Date and number formatting via Intl.DateTimeFormat and Intl.NumberFormat — never hardcode these.
  • RTL layout support using CSS logical properties (margin-inline-start instead of margin-left).
  • Font loading strategies — some scripts require different typefaces and line-heights.
  • Market-specific features — payment methods, phone number formats, legal disclaimers.

Scaling the Translation Workflow

For production, your translation files should be stored in a CMS or translation management system, not in your Git repository. This decouples content updates from code deploys and lets non-technical team members manage copy.