How to structure translations and load locale content in App Router
Tests App Router i18n architecture with next-intl. Answer: locale-prefixed routes, JSON message files with ICU syntax, and next-intl APIs consumed in Server Components. Red flag: using client-side locale state instead of integrated routing.
What's really being asked
This question evaluates whether you understand how to implement internationalization in Next.js App Router without violating Server Component boundaries. The interviewer wants to see that you know next-intl handles locale detection via URL routing, stores messages in JSON, and provides APIs that work directly in Server Components.
The full answer
First, routing structure: use locale-prefixed paths like /en/blog or /de/uber-uns so the URL determines the language. Second, file organization: keep translation files such as en.json and es.json containing nested namespaces like UserProfile with ICU message syntax for plurals and interpolation. Third, Server Component consumption: import APIs from next-intl that work in Server Components to retrieve the current locale and render translated content without client JavaScript. Fourth, rendering strategy: note that next-intl supports static rendering and SSG, so pages can be built per locale for performance. Fifth, type safety: mention that next-intl provides compile-time checks and autocompletion for message keys.
The mistakes people make
Proposing to store the active locale in React state or context and switching it client-side ignores URL-based routing and breaks SEO. Suggesting manual regex parsing of the pathname to detect locale shows you are not leveraging the framework integration. Recommending that all translated components must be Client Components in order to access translations adds unnecessary bundle size and ignores that next-intl works in Server Components. Forgetting to mention JSON message files or ICU syntax for pluralization reveals shallow familiarity.
What usually comes next
How would you handle localized pathnames where slugs differ per language, such as /en/about-us versus /es/sobre-nosotros? How do you format dates and numbers without hydration mismatches? How would you implement language switching while preserving the current pathname? What is your strategy for code-splitting translation files so only the active locale is loaded?
A concrete example
Suppose you have a blog page at app/[locale]/blog/page.tsx. The URL /es/blog sets the locale to Spanish. You have a messages/es.json file with a Blog namespace containing title and readTime keys using ICU syntax. Inside the Server Component, you use next-intl APIs to load the Spanish messages and render the heading and metadata. The page is statically generated at build time, so the HTML contains the translated strings with zero client-side translation logic.
Interview question
You are localizing a Next.js App Router site with next-intl. Which approach correctly renders a Spanish blog page at /es/blog?
- a.Use locale-prefixed routing, JSON message files with ICU syntax, and next-intl APIs directly in Server Components.Correct
- b.Fetch translations in a useEffect inside a Client Component to prevent hydration mismatches.
- c.Parse the pathname manually with regex and pass translations only to Client Components.
- d.Store locale in React context and switch languages with a client-side hook.
Why? this is the answer
Locale-prefixed routes allow next-intl to detect language from the URL and let Server Components render translations directly from JSON files without client JavaScript. Using React context for locale is wrong because it ignores URL-based routing, breaks SEO, and violates the Server Component architecture.
Just read this? Test yourself on what you have been reading.
Read the original → next-intl.dev
- #next.js
- #app router
- #i18n
- #server components
- #next-intl
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on next.js — each one lists the topics its interview covers.
See open roles