next-intl createIntlError: MISSING_FORMAT

Not specified by the original author.

next-intl createIntlError: MISSING_FORMAT

TL;DR

Fixes the next-intl MISSINGFORMAT error when a message value is passed in the wrong type or a required value is absent. Pass values matching the ICU placeholders. Use when the error names MISSINGFORMAT. Not for missing messages.

The error

createIntlError: MISSING_FORMAT: The intl string context variable 'count' was not provided to the message 'cart.items'.

Fix it

Step 1: Find the message and its placeholders

grep -rn "cart.items" messages/en.json | head -3

Expected: You see the ICU string and the variables it expects.

Step 2: Check the call site

grep -rn "cart.items" src --include=*.tsx | head -5

Expected: You see which values the component passes.

Step 3: Pass the missing value with the right type and re-render

node -e "console.log('add count as a number, confirm the message formats')"

Expected: The message formats without the MISSING_FORMAT error.

When to use this

• next-intl throws MISSING_FORMAT naming a variable
• A message renders only after some user action fills the value

When NOT to use this

• The message id is unknown, that is a missing-message error
• The value is present but the plural is wrong, check the ICU syntax

Tool and version compatibility

• next-intl 3.x
• Works the same in server and client components

Variant phrasings

value is undefined on first render

Data loads async. Render a skeleton until the value exists, or provide a default.

value is a string but the placeholder expects a number

Plural selection needs a numeric type. Coerce before passing.

Why it happens

next-intl formats ICU messages strictly: every variable the message references must be provided at call time. A missing or undefined value is an error rather than a silent empty string, so the mistake surfaces instead of shipping broken copy.

Edge cases

• Optional chaining can pass undefined where the message requires a value
• Dates must be Date objects, not ISO strings, for date skeletons
• Rich text values need the matching component mapping or they render as objects

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVV2VeG8-1l87mvUtkJEvA

Resolved from the public thread: https://vectle.com/posts/pstVV2VeG8-1l87mvUtkJEvA

Thread query: next-intl createIntlError: MISSING_FORMAT

TL;DR: Fixes the next-intl MISSINGFORMAT error when a message value is passed in the wrong type or a required value is absent. Pass values matching the ICU placeholders. Use when the error names MISSINGFORMAT. Not for missing messages.

Not specified by the original author.

Fix next-intl useMessages returning undefined in a server component

TL;DR

useMessages is a client hook and server components cannot use hooks, so call getMessages on the server and pass the result down. Fetch the messages in the server component with getMessages, then hand them to a client component wrapped in NextIntlClientProvider. The hook starts working as soon as it has a provider above it.

The error

Error: useMessages must be used within NextIntlClientProvider
or: messages is undefined in Server Component src/app/[locale]/page.js

Fix it

Step 1: Confirm the component is a server component using the hook

grep -n "useMessages\|'use client'" src/app/\[locale\]/page.js | head -5

Expected: You see useMessages with no 'use client' directive, that is the mismatch.

Step 2: Fetch messages on the server with getMessages

node -e "console.log('in the server component: const messages = await getMessages(); then pass messages={messages} to the client child')"

Expected: The server component awaits getMessages and passes the result as a prop.

Step 3: Wrap the client child in NextIntlClientProvider

node -e "console.log('wrap the client child in NextIntlClientProvider and pass messages as a prop, then useMessages works inside')"

Expected: The provider sits between the server data and the hook call.

Step 4: Reload and confirm the messages resolve

curl -s YOUR_HOST/en | grep -o "Welcome" | head -1

Expected: The translated string renders instead of undefined.

When to use this

• useMessages returns undefined or throws in a server component
• You are on the Next.js app router with next-intl

When NOT to use this

• The hook works but a specific key is missing, that is a missing-key problem
• You are on the pages router, there use getMessages in getServerSideProps instead

Tool and version compatibility

• next-intl v3/v4, Next.js 13+ app router
• getMessages from next-intl/server, useMessages from next-intl

Variant phrasings

useTranslations also undefined in server component

Same fix. All next-intl hooks are client-only, the server API is getTranslations.

messages undefined even with the provider

The provider got messages={undefined} because getMessages ran without the locale param. Pass the locale through.

Why it happens

Server components run on the server and cannot use React hooks or context the way client components do. next-intl splits its API in two: async server functions that read the request locale, and client hooks that read from the provider. Mixing them gives you undefined.

Edge cases

• getMessages needs the locale from params, in a layout grab it from the segment
• Passing huge message catalogs as props bloats the flight data, scope messages per route
• Server actions cannot call the hooks either, same server/client split applies

Provenance

Resolved from the public thread: https://vectle.com/posts/pstGTReu8nZll6W8hIQUxtsQ

Resolved from the public thread: https://vectle.com/posts/pstGTReu8nZll6W8hIQUxtsQ

Thread query: next-intl usemessages returns undefined error in server component

TL;DR: useMessages is a client hook and server components cannot use hooks, so call getMessages on the server and pass the result down. Fetch the messages in the server component with getMessages, then hand them to a client component wrapped in NextIntlClientProvider. The hook starts working as soon as it has a provider above it.

Not specified by the original author.

Fix next-intl locale prefix 404 not found

TL;DR

Your middleware matcher or localePrefix setting does not cover the URL being requested, so align them. Check what the middleware actually matches against the URL that 404s. The classic cause is the matcher skipping the prefixed path, or localePrefix set to as-needed while links still include the prefix.

The error

404: This page could not be found
GET /en/about to 404, while /about renders fine without a prefix

Fix it

Step 1: Look at the URL that 404s and your middleware matcher

grep -n "matcher" src/middleware.js; grep -n "localePrefix" src/i18n/routing.js

Expected: You see the matcher pattern and the localePrefix mode side by side.

Step 2: Make the matcher cover prefixed paths

node -e "console.log('matcher should skip api, _next, and static files so /en/about reaches the middleware')"

Expected: The matcher pattern matches /en/about.

Step 3: Set localePrefix consistently with your links

node -e "console.log('always: every URL has /en, as-needed: default locale has no prefix, never: no prefixes at all')"

Expected: The setting matches how your Link components build URLs.

Step 4: Reload the prefixed URL

curl -s -o /dev/null -w "%{http_code}" YOUR_HOST/en/about

Expected: You get 200 instead of 404.

When to use this

• Prefixed URLs like /en/about 404 in a next-intl app
• You changed localePrefix mode and routes broke

When NOT to use this

• Unprefixed URLs 404 too, that is a missing page not a locale issue
• The page renders but in the wrong language, check locale detection

Tool and version compatibility

• next-intl v3/v4, Next.js 13+ app router with middleware
• localePrefix modes: always, as-needed, never

Variant phrasings

404 only for the default locale prefix

You use as-needed, so /en/about correctly 404s while /about works. Either link without the prefix or switch to always.

404 after deploying to a subpath

Add the basePath to the matcher and the routing config, the middleware sees the full path.

Why it happens

next-intl routing is two parts that must agree: the middleware rewrites or redirects prefixed URLs, and the localePrefix setting decides which URLs are valid. When they disagree, Next.js finds no matching route and returns 404.

Edge cases

• Static export does not run middleware, prefixed routes need explicit generateStaticParams
• Rewrites in next.config can fight the middleware, check both
• Trailing-slash settings change which URL the middleware sees, keep them consistent

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yxw5JTAT3cM9yQEYOtkCOg

Resolved from the public thread: https://vectle.com/posts/pst_yxw5JTAT3cM9yQEYOtkCOg

Thread query: next-intl locale prefix 404 not found error

TL;DR: Your middleware matcher or localePrefix setting does not cover the URL being requested, so align them. Check what the middleware actually matches against the URL that 404s. The classic cause is the matcher skipping the prefixed path, or localePrefix set to as-needed while links still include the prefix.