Recommended approach for handling country prefix along with locale

[im-luka]

Hi, love the library, use it in every app! However, I encountered a problem and I am not sure what is the go-to way to resolve it.

As the title suggest, our team is building an application that has both, multi-language and multi-country support. In the app, user has ability to change both country and language. All locales are available to all countries, but every country has it's own products, prices, orders etc. There are two dropdowns, one for country and one for locale. It looks something like this (demo example):

We are currently using next-intl to handle localization and languages, and we are handling countries through search params.
The code structure looks like standard structure from the docs:
/src/app/[locale]/...pages
and url looks something like this:
myapp.com/[locale]/some-page?countryId=[country] ➡️ myapp.com/en/some-page?countryId=de

However, the client came to us with request that they longer don't like this structure and would like to include countryId as the url prefix as well. They want the url to look like this:
myapp.com/[country]/[locale]/some-page ➡️ myapp.com/de/en/some-page

My question is - what would be recommended approach in this case, if there is any? I went through the docs, discussions and issues and the closest thing I found is #653 but the problem is:

• we can't create custom prefixes for locales when initializing middleware as all of our countries support all languages (we can, but it could get quite messy - solution is below)
• we can't add basePath as our countries are dynamic and could be changed at any given moment

Current, "hacky" solution we have so far is that we add country prefix to all of our .json files and modify localePrefix when we define routing. So if we have, for example, languages de and en and countries at, de, hr, it it will look like this:
messages/AT-de.json
messages/AT-en.json
messages/DE-de.json
messages/DE-en.json
messages/HR-de.json
messages/HR-en.json
messages/IT-de.json
messages/IT-en.json

routing.ts:

import { defineRouting } from "next-intl/routing";
import { createSharedPathnamesNavigation } from "next-intl/navigation";

export const routing = defineRouting({
  locales: [
    "AT-de",
    "AT-en",
    "DE-de",
    "DE-en",
    "HR-de",
    "HR-en",
    "IT-de",
    "IT-en",
  ],
  defaultLocale: "DE-en",
  localePrefix: {
    mode: "always",
    prefixes: {
      "AT-de": "/at/de",
      "AT-en": "/at/en",
      "DE-de": "/de/de",
      "DE-en": "/de/en",
      "HR-de": "/hr/de",
      "HR-en": "/hr/en",
      "IT-de": "/it/de",
      "IT-en": "/it/en",
    },
  },
});

export const { Link, redirect, usePathname, useRouter } =
  createSharedPathnamesNavigation(routing);

middleware.ts:

import createMiddleware from "next-intl/middleware";
import { routing } from "./i18n/routing";

export default createMiddleware(routing);

export const config = {
  matcher: ["/", "/(at/de|at/en|de/de|de/en|hr/de|hr/en|it/de|it/en)/:path*"],
};

With that, we could always split locale and from that extract both country and locale. However, this solution could get quite cumbersome and, as multi-countries/multi-languages is core feature of our app, we wanted to see if there is more reliable, recommended solution.

Thank you and all the best!

[amannn]

Glad to hear if next-intl is working well for you! 🙌

Not sure if I'm missing something, but can you generate locales and prefixes dynamically? Maybe something like:

import {defineRouting} from "next-intl/routing";

const countries = ['DE', 'AT', /* ... */];
const languages = ['de', 'en', /* ... */];

export const routing = defineRouting({
  locales: countries.map((country) => languages.map((language) => `${language}-${country}`)).flat(),
  defaultLocale: "en-DE",
  localePrefix: {
    mode: "always",
    prefixes: Object.fromEntries(
      countries.map((country) => languages.map((language) => [`${language}-${country}`, `/${country}/${language}`])).flat()
    )
  }
});

If type safety for the routing is important to you, you might have to add some TypeScript tricks to this, but for the JavaScript part this might work.

After that, in i18n/request.ts you can extract the language part of the locale and use that to load the respective messages file. There's no need to declare JSON files redundantly if they don't differ by country.

Could that work for you?

One important note: A locale needs to be a valid IETF BCP 47 language tag. E.g. en-AT is valid, but AT-en is not. You won't notice a difference with simple static messages, but as soon as e.g. date formatting, plural rules, etc. come into play, this will break in an unexpected way.

[im-luka]

Thank you very much for a detailed answer. I really like this solution and I've tried something similar but I get the error inside getRequestConfig function inside i18n/request.ts file.

I have the translations like this:
messages/en.json
messages/de.json

Mine routing.ts file is exactly like yours.

However, I get the following error inside i18n/request.ts file (for example, url is myapp.com/DE/en/home):

And this is how my code looks like:

import { notFound } from "next/navigation";
import { getRequestConfig } from "next-intl/server";
import { routing } from "./routing";

export default getRequestConfig(async ({ locale }) => {
  console.log("LOCALE ->", locale); // en-DE
  if (!routing.locales.includes(locale as any)) {
    notFound();
  }

  const currLocale = locale.split("-")[0];
  console.log("CURR LOCALE ->", currLocale); // en

  return {
    messages: (await import(`../../messages/${currLocale}.json`)).default,
  };
});

Even when I try hardcoding currLocale variable to en string, I get the same error:

import { notFound } from "next/navigation";
import { getRequestConfig } from "next-intl/server";
import { routing } from "./routing";

export default getRequestConfig(async ({ locale }) => {
  console.log("LOCALE ->", locale); // en-DE
  if (!routing.locales.includes(locale as any)) {
    notFound();
  }

  const currLocale = "en";
  console.log("CURR LOCALE ->", currLocale); // en

  return {
    messages: (await import(`../../messages/${currLocale}.json`)).default,
  };
});

But when I enter en directly inside return statement, it works fine:

import { notFound } from "next/navigation";
import { getRequestConfig } from "next-intl/server";
import { routing } from "./routing";

export default getRequestConfig(async ({ locale }) => {
  console.log("LOCALE ->", locale); // en-DE
  if (!routing.locales.includes(locale as any)) {
    notFound();
  }

  return {
    messages: (await import(`../../messages/${"en"}.json`)).default,
  };
});

Could it be that it is not possible to define variables inside getRequestConfig, make some operations, or something like that? Also, big probability is that I might be doing something wrong but really can't find the problem 😅

[amannn]

That's quite odd indeed. Using a dynamic expression in import calls is definitely fine, this is used for all examples of next-intl:

next-intl/examples/example-app-router/src/i18n/request.ts

Line 14 in 4c9c130

: import(`../../messages/${locale}.json`))

Are you using a special bundling setup? Or maybe you're on an old version of Next.js that has a bug here? If you can set up a basic reproduction using next-intl-bug-repro-app-router I can have a look!

[im-luka]

Nothing special, just default Next.js bundling (Next.js version is 14.2.12).

When I modified next.config.mjs file and set swcMinify to false, everything works as expected:

import createNextIntlPlugin from "next-intl/plugin";

const withNextIntl = createNextIntlPlugin();

/** @type {import('next').NextConfig} */
const nextConfig = {
  swcMinify: false,
};

export default withNextIntl(nextConfig);

This is fine for me now. Do you still want me to setup a basic reproduction, or try to help in any other way?

[amannn]

Oh right, that's the culprit then. You could share your finding in vercel/next.js#30237, ideally this get's addressed on the Next.js side.

[im-luka]

Will do. Thank you for your support, it was a big help to me. Keep up the great work! 🚀