Allow only translated pathnames

[mnemosx]

Hi!
Using your middeware with pathnames set up like this:

const handleI18nRouting = createIntlMiddleware({
  locales,
  defaultLocale: SupportedLangs.LV,
  localeDetection: false,

  pathnames: {
    '/': '/',
    '/about': {
      lv: '/par-mums',
      ru: '/o-nas',
    },
    '/contacts': {
      lv: '/kontakti',
      ru: '/kontakti',
    },
    '/faq': {
      lv: '/jautajumi',
      ru: '/voprosi',
    },
  },
});

works really well when I'm trying to access translated paths like http://localhost:3000/lv/jautajumi/ 🙌

There is just one issue -- http://localhost:3000/lv/faq/ remains accessible too! This is not ideal because there are duplicate pages from the SEO standpoint.

What I'd like to see is that only the translated lv and ru links are available, while the English versions that are used as directory names in the App router and as keys in code (about, contacts, faq, etc.) return 404. e.g.:

• /ru/voprosi/ -> renders Russian content
• /voprosi/ -> adds the default prefix which is lv so path /lv/voprosi/ renders 404
• /lv/jautajumi/ -> renders Latvian content
• /jautajumi/ -> adds the default prefix which is lv and renders Latvian content
• /lv/faq/ -> renders 404
• /ru/faq/ -> renders 404
• /faq/ -> either adds a default prefix which is lv and renders 404 or just renders 404 right away

Can this be done?

Adding my folder structure for reference in case it helps:

[amannn]

That's a great point! For the time being, you could implement this in user land, but I think that would be desirable in next-intl core too—I'll move this to a feature request issue.

→ #904

[mnemosx]

For the time being, you could implement this in user land,

How would you recommend implementing this with the current next-intl version?

What I have currently:

import { NextRequest, NextResponse } from 'next/server';
import createIntlMiddleware from 'next-intl/middleware';
import { SupportedLangs } from '@/definitions/enums';
import { PAGES } from './utils/constants';
import { locales } from './i18n';

const handleI18nRouting = createIntlMiddleware({
  locales,
  defaultLocale: SupportedLangs.LV,
  localeDetection: false,

  pathnames: {
    '/': '/',
    '/about': {
      lv: '/par-mums',
      ru: '/o-nas',
    },
    '/contacts': {
      lv: '/kontakti',
      ru: '/kontakti',
    },
    '/faq': {
      lv: '/jautajumi',
      ru: '/voprosi',
    },
  },
});

export default async function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;
  const pathnameIsMissingLocale = locales.every((locale: SupportedLangs) => {
    return !pathname.startsWith(`/${locale}/`) && pathname !== `/${locale}`;
  });

  const segments = pathname.split('/');
  const locale = pathnameIsMissingLocale ? null : (segments[1] as SupportedLangs);
  const routeKey = segments[pathnameIsMissingLocale ? 1 : 2];
  const isRouterKey = Object.keys(PAGES).includes(routeKey); // e.g. ['about', 'contacts', 'faq']

  // This adds the default locale to *translated* routeKey e.g. /jautajumi/ -> /lv/jautajumi/  
  // Without this, the router adds locale, then middleware is run again with
  // translated `routeKey` turned back to the English version, and that leads to 404 :/
  if (!isRouterKey && pathnameIsMissingLocale) {
    const defaultLocale = SupportedLangs.LV;

    return NextResponse.redirect(
      new URL(`/${defaultLocale}${pathname.startsWith('/') ? '' : '/'}${pathname}`, request.url),
    );
  }

  if (isRouterKey) {
    request.nextUrl.pathname = `/404`; // actually could be anything that would lead to `not-found`
  }

  const response = handleI18nRouting(request);
  return response;
}

export const config = {
  matcher: ['/(lv|ru)/:path*', '/((?!api|_next|.*\\..*).*)'],
};

As a result, the default locale is added only to translated routes, e.g.:
/kontakti/ -> /lv/kontakti
/contacts/ -> /lv/404

Still not perfect, because I'd like the URL to stay unchanged when showing a 404 view, and middleware is run at least twice when any change is made. Also, it feels wrong to redirect manually in middleware because router has the default locale feature built into it.

[amannn]

Something like that, yes—assuming PAGES is the same as pathnames above (why not use that instead?). You want to be careful with the matching in case you add dynamic params though.

@RomainGueffier suggested to look into this, maybe we can work out a solution that's built into next-intl and works for you too!

I also made a note about 404/302 handling in the linked thread, maybe we can find a solution that avoids changing the pathname (/404 in your example).

Let's continue the conversation over at #904