Structure locale-aware routing in the App Router without reaching for a heavy i18n framework

You are structuring locale-aware routing for a Next.js App Router site, deciding the segment structure, the locale-detection strategy, and whether the stated needs actually justify a dedicated i18n library or are simple enough for a lighter, hand-rolled approach.

LOCALES SUPPORTED
en (default), es, fr

CONTENT TRANSLATION APPROACH
Marketing copy lives in per-locale JSON dictionaries; no pluralization or rich formatting needs beyond simple string interpolation for a name or count

DEFAULT LOCALE BEHAVIOR
Undecided today — some internal links point to /about, others to /en/about, inconsistently

CURRENT STRUCTURE
Locale is currently read from a cookie only, with no [locale] segment in the URL at all — every page is served at the same path regardless of language, which breaks sharing a Spanish-language link with someone whose browser defaults to English

DESIGN RULES
Nest every localized route under a [locale] dynamic segment — app/[locale]/page.tsx, app/[locale]/about/page.tsx — so the locale is a first-class part of the URL and the route structure, rather than inferred from a cookie or a header alone with no reflection in the path; a locale that isn't in the URL can't be shared via a link, can't be indexed separately by search engines for each language, and breaks the browser's own back button expectation when a visitor switches languages. Use generateStaticParams at the [locale] segment level to pre-render each supported locale's static pages at build time rather than resolving locale-specific content only at request time, for any content that doesn't need to be dynamic per-request beyond varying by locale. Do the initial locale negotiation, meaning deciding which locale an unprefixed request like the bare root path should redirect to, in middleware — reading the Accept-Language header and any existing locale preference cookie, then issuing a redirect to the matching [locale] path — rather than duplicating that negotiation logic inside every page component that might receive an unprefixed request. Decide explicitly, and state the decision, on default-locale URL behavior: whether the default locale gets its own visible segment in the URL (/en/about) or is treated as the unprefixed default (/about, with /es/about for the non-default locale) — both are legitimate choices, but leaving it undecided produces inconsistent internal links as different pages get built by different people making different implicit assumptions. Assess honestly whether the actual translation need here — a handful of static strings, or full pluralization rules, date/number formatting, and rich message interpolation across many locales — justifies a dedicated library like next-intl, versus a much simpler hand-rolled dictionary object keyed by locale; recommend the lighter approach when the stated need doesn't go beyond static string lookup, and say plainly why a heavier library would be unjustified overhead rather than defaulting to it because it's the more commonly cited solution.

OUTPUT FORMAT
The folder structure showing the [locale] segment and where generateStaticParams lives, the middleware's locale-negotiation logic, and one paragraph stating the default-locale URL decision and the translation-approach recommendation, each with its reasoning made explicit rather than left implied.