nextjs - ✅(Solved) Fix Docs: App Router Guides Internationalization [1 pull requests, 6 comments, 6 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#86864Fetched 2026-04-08 02:08:51
View on GitHub
Comments
6
Participants
6
Timeline
23
Reactions
0
Author
Assignees
Timeline (top)
commented ×6mentioned ×5subscribed ×5assigned ×1

Error Message

I ended up receiving a type error when building (see context). The error received when running build is: Type error: Type 'typeof import("/home/musa/webProjects/musarochi/src/app/[lang]/layout")' does not satisfy the constraint 'LayoutConfig<"/[lang]">'.

Root Cause

While trying to implement intl for a next.js 16 app router based project. Using the given way (from the doc) to read the params in my root layout: (Note i use 'en' as short for english , not 'en-US' because i do not play on different 'en' support)

Fix Action

Fix / Workaround

My currnet workaround is to simply type params as Promiselang:string and then when calling getDictionary() cast it => await getDictionary(lang as "de" | "en");

PR fix notes

PR #86871: docs: i18n type narrowing w/ runtime guards

Description (problem / solution / changelog)

Closes: https://github.com/vercel/next.js/issues/86864

Changed files

  • docs/01-app/02-guides/internationalization.mdx (modified, +27/-20)
RAW_BUFFERClick to expand / collapse

What is the documentation issue?

There is a wrong information about the type of the lang param when reading from params.

While trying to implement intl for a next.js 16 app router based project. Using the given way (from the doc) to read the params in my root layout: (Note i use 'en' as short for english , not 'en-US' because i do not play on different 'en' support)

`export async function generateStaticParams() { return [{ lang: 'en' }, { lang: 'de' }] }

export default async function RootLayout({ children, params, }: Readonly<{ children: React.ReactNode params: Promise<{ lang: 'en' | 'de' }> }>) { return ( <html lang={(await params).lang}> <body>{children}</body> </html> ) }`

I ended up receiving a type error when building (see context).

My currnet workaround is to simply type params as Promiselang:string and then when calling getDictionary() cast it => await getDictionary(lang as "de" | "en");

Is there any context that might help us understand?

The error received when running build is: ` .next/dev/types/validator.ts:121:31 Type error: Type 'typeof import("/home/musa/webProjects/musarochi/src/app/[lang]/layout")' does not satisfy the constraint 'LayoutConfig<"/[lang]">'. Types of property 'default' are incompatible. Type '({ children, params, }: Readonly<{ params: Promise<{ lang: "en" | "de"; }>; children: ReactNode; }>) => Promise<Element>' is not assignable to type 'ComponentType<LayoutProps<"/[lang]">> | ((props: LayoutProps<"/[lang]">) => void | ReactNode | Promise<ReactNode> | Promise<...>)'. Type '({ children, params, }: Readonly<{ params: Promise<{ lang: "en" | "de"; }>; children: ReactNode; }>) => Promise<Element>' is not assignable to type 'FunctionComponent<LayoutProps<"/[lang]">>'. Types of parameters '__0' and 'props' are incompatible. Type 'LayoutProps<"/[lang]">' is not assignable to type 'Readonly<{ params: Promise<{ lang: "en" | "de"; }>; children: ReactNode; }>'. Types of property 'params' are incompatible. Type 'Promise<{ lang: string; }>' is not assignable to type 'Promise<{ lang: "en" | "de"; }>'. Type '{ lang: string; }' is not assignable to type '{ lang: "en" | "de"; }'. Types of property 'lang' are incompatible. Type 'string' is not assignable to type '"en" | "de"'.

119 | type __IsExpected<Specific extends LayoutConfig<"/[lang]">> = Specific 120 | const handler = {} as typeof import("../../../src/app/[lang]/layout.js")

121 | type __Check = __IsExpected<typeof handler> | ^ 122 | // @ts-ignore 123 | type __Unused = __Check 124 | } Next.js build worker exited with code: 1 and signal: null `

Does the docs page already exist? Please link to it.

https://nextjs.org/docs/app/guides/internationalization

extent analysis

TL;DR

The issue can be resolved by correctly typing the params object to match the expected type of lang as a string, and then using a type guard or assertion to narrow the type when accessing the lang property.

Guidance

  • The error message indicates a type mismatch between the expected lang type ("en" | "de") and the actual type (string), so updating the type of params to Promise<{ lang: string }> is a step in the right direction.
  • To avoid using type assertions (e.g., lang as "en" | "de"), consider using a type guard to narrow the type of lang based on its value.
  • Review the Next.js documentation on internationalization to ensure that the implementation aligns with the recommended approach.
  • Verify that the generateStaticParams function is correctly generating the expected lang values.

Example

export default async function RootLayout({
  children,
  params,
}: Readonly<{
  children: React.ReactNode
  params: Promise<{ lang: string }>
}>) {
  const { lang } = await params;
  const isSupportedLang = (lang: string): lang is "en" | "de" => ["en", "de"].includes(lang);
  if (isSupportedLang(lang)) {
    return (
      <html lang={lang}>
        <body>{children}</body>
      </html>
    )
  } else {
    // Handle unsupported language
  }
}

Notes

The provided workaround using lang as "en" | "de" may work, but it's generally safer to use type guards or other mechanisms to narrow types instead of relying on type assertions.

Recommendation

Apply workaround: Update the type of params to Promise<{ lang: string }>, and use a type guard to narrow the type of lang when accessing its value. This approach allows for more robust type checking and avoids the need for type assertions.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING