Internationalisation (i18n) — Next.js App Router

Internationalisation, conventionally abbreviated to i18n for the eighteen letters between the first and last, is the practice of building an application so it can serve users in different languages and regional conventions without rewriting it for each. It is more than translating strings: it encompasses the language of the interface, the formatting of dates, numbers, and currencies according to local convention, the direction of text for right-to-left languages, and the way the application routes and serves the right locale to each user. In the App Router, i18n intersects directly with the routing model you have learned, because the cleanest way to serve multiple locales is to make the locale part of the URL, which turns i18n into a routing concern handled with the same segment and layout machinery you already understand.

This topic matters because the decision to internationalise is far cheaper to honour early than to retrofit, and because doing it well reaches users a single-language application simply cannot. An application that hard-codes English strings throughout, formats dates in one country's convention, and assumes left-to-right text has woven assumptions so deeply into its code that adding a second language later means touching nearly every component — whereas an application built from the start to read its text from a locale-keyed source and format values through locale-aware tools absorbs new languages with little structural change. The reach is real: serving users in their own language and conventions is often the difference between an application being usable and being ignored in a given market. The App Router supports this through locale-aware routing, server-side locale resolution that fits its rendering model, and the platform's built-in formatting capabilities for dates, numbers, and currencies. This lesson covers how locale is expressed in routing, how translated content and locale-aware formatting work, and the practices that make an application genuinely multilingual rather than merely translated.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.