How to structure translations and load locale content in App Router

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.