How to work with CMS like Strapi using dynamic language-specific slugs or localized pathnames?

[ronfried1]

Handling Locale-Specific Dynamic Slugs in Nested Routes with Strapi and Next.js

I am working on a multilingual application using Next.js (App Router) and Strapi.

My routes are structured as follows:

[locale]/complexes/[slug]

Each language in Strapi has its own unique slug. For example:

English: /en/complexes/some-slug
Spanish: /es/complexes/some-slug-es

When I switch locales, the route doesn't update to the correct slug for the new language. Instead, it reuses the current slugs, resulting in an invalid URL like:

/es/complexes/some-slug

Setup Details

• Frontend: Next.js 14 with App Router and generateStaticParams.
• Backend: Strapi v4 with internationalization enabled.
• Other Tools: next-intl for localization.

Current Implementation:

I'm using generateStaticParams to pre-generate all possible locale-specific paths.

type Props = {
  params: {
    locale: string;
  };
};

export async function generateStaticParams(props: Props) {
  const { locale } = props.params;
  const token = process.env.NEXT_PUBLIC_STRAPI_API_TOKEN;
  const path = `/complexes`;
  const options = { headers: { Authorization: `Bearer ${token}` } };
  const response = await fetchAPI(
    path,
    {
      locale: [locale],
    },
    options,
  );

  return response.data.map((complex: { attributes: { slug: string } }) => ({
    slug: complex.attributes.slug,
    locale,
  }));
}

The primary issue is that the locale switch fails to accurately map the slug to the translated values in the target language. This leads to:

Incorrect URLs for the target locale.
User confusion and potential 404 errors.

How can I ensure that generateStaticParams correctly maps all locale-specific slugs, and renders the right slug per locale?
Is there a better way to dynamically fetch and apply translated slugs during a language switch?
Are there any best practices for handling such multilingual nested routes in Next.js with Strapi?

My app is small for now, but I anticipate that I'll have more dynamic routes in the future, so I want to handle internationalization properly from the start.
I am open to improving my API structure or Next.js implementation if necessary.
Any feedback, examples, or pointers to related issues would be highly appreciated.
Thank you in advance for your time and insights! 😊

[amannn]

Yep, that's indeed a bit of a tricky one!

The next-intl docs on localized pathnames have a brief mention of this:

Furthermore, in case you provide a locale switcher, it might require special care to be able to switch between localized pathnames of the same page. A simplified implementation might always redirect to the home page instead.

Not sure if redirecting to the home page on locale change is an option for you, but it's certainly the simplest implementation for this case.

Alternatively, you could consider intercepting requests for pathnames like /es/complexes/some-slug in the middleware and redirect them to ./some-slug-es. That's at least an option that could work without making your locale switcher page-specific.

[ronfried1]

I wonder what it will take to fully customize a well-structured web app with multiple routes that require similar options. Will there be any future updates to address this use case?

Unfortunately, I need to translate each route in my app. At the moment, I can manage simple routes using localized pathnames and for my nested routes on content pages and, I can intercept the pathname using middleware. however, I'm concerned that this solution may not be sustainable in the long run.

[amannn]

Do you have multiple parts in your app where pathnames are handled by a CMS? I once worked on a website where all content is managed by a CMS (i.e. app/[locale]/[[...slug]]). There we made the decision for the locale switcher to simply switch to the home page always—that simplified things quite a bit.

The middleware solution I've outlined above can work if you have some external content and want a smarter locale switcher. I understand that it's not ideal if you have multiple such areas. With the current capabilities/constraints of Next.js I can currently not really think of a better solution, sorry :-/. Happy to be proven wrong though if you have an idea!