Is locale query-string a reserved keyword ?

[ScreamZ]

Hello,

I'm developing a search feature using nusq and I'm using the following configuration for parsing.

const AvailableLocales = ["en", "fr"] as const satisfies ReadonlyArray<string>;

export const searchParamsParsers = {
  q: textSearchQueryParser.withDefault({ tags: [], users: [], text: "" }),
  locale: parseAsStringLiteral(AvailableLocales),
};

and so far my page is

export default async function SearchPage({
  searchParams,
}: {
  searchParams: Record<string, string | string[] | undefined>;
}) {
  console.log("searchParams", searchParams);
  const params = searchParamsCache.parse(searchParams);

Now when running on development side I have

searchParams { q: '#man #woman Lorem', locale: "fr" }

now in production (on vercel only ? not when running locally npm run build npm start

i get only

searchParams { q: '#man #woman Lorem' }

My question is, is there any restrictions that I'm missing, where locale parameter is stripped by the library in production ?

Thanks

[ScreamZ]

Using l instead of language seems to fix the issue. Maybe we could improve the doc on that reserved keywords somewhere if you confirm.

The issue was happening only on vercel deployment, I guess that in local version (even built) I might be missing some env vars.

[amannn]

That‘s interesting. In that case it‘d be reserved search param on Vercel. Is it mentioned anywhere in their docs?

[amannn]

next-intl doesn‘t touch your search params, so there shouldn’t be a difference. It’s a bit suspicious that this works in „local production“ but not on Vercel, so possibly a hosting issue.

You could try to debug this by logging the incoming search params in the middleware, before the next-intl middleware runs.