When using on-demand ISR and i18n routing, localized paths must be revalidated manually?

[sumul]

I'm using both on-demand ISR and internationalized routing (with sub-paths) for https://figure.game/. On-demand ISR is how I deploy new daily puzzle data at midnight UTC every day, which works beautifully. The built-in i18n routing is working perfectly as well.

I just ran into a little gotcha when using both together: the localized versions of my routes weren't getting revalidated (so no new puzzle today for Spanish-speaking players). I think I've sorted it out, but wanted to get some feedback on my approach and also share this in case it's helpful for anyone else who runs into this issue.

From the documentation on i18n routing, I had assumed that revalidate() would update getStaticProps for all locales. I think this bit, which seems to only apply to the initial build, is where I made this false assumption:

For Automatically Statically Optimized and non-dynamic getStaticProps pages, a version of the page will be generated for each locale.

When I double-checked the on-demand ISR documentation, this comment in the example code clued me in:

// this should be the actual path not a rewritten path
// e.g. for "/blog/[slug]" this should be "/blog/post-1"

I believe the solution is iterate over the i18n locales when revalidating paths:

// /pages/api/isr-api-route.js
import { i18n } from "../../next.config";
const REVALIDATE_PATHS = ["/", "/congrats"];

export default async function handler(req, res) {
  // ...

  // Make path components out of each i18n locale (plus blank for default)
  const locales = ["", ...i18n.locales.map((l) => `/${l}`)];

  // Revalidate each path and its localized version
  for await (const locale of locales) {
    for await (const path of REVALIDATE_PATHS) {
      await res.revalidate(locale + path);
    }
  }

  // ...
}

Does this seem like the right approach, or is there a better way?

[bhavesh-chaudhari]

Any update on this?

[aleksakojadinovic]

Apparently when using domain-based routing the problem is even worse. It seems impossible to revalidate routes other than lose for default locale.

[aleksakojadinovic]

Yeah it should work with subdomains as well, a few of my locales are also subdomain-routed.

The way I figured it out is by browsing the .next build folder and checking the contents of .next/server/pages directory. If you have a folder for each of your supported locales there then it should work, because apparently the revalidation paths match this folder structure rather than the actual URL, which is a little bizzare if you ask me, but oh well :)

[shinwonse]

Thank you for your kind explanation. But I have a one question. res.revalidate get one parameter which name is urlPath. Is it okay give full url to res.revalidate?

import type { NextApiRequest, NextApiResponse } from 'next';

import nextConfig from '../../../next.config';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.query.secret !== 'notion') {
    return res.status(401).json({ message: 'Invalid token' });
  }

  const domains = nextConfig.i18n.domains;
  const urls: string[] = domains.map((domain: { defaultLocale: string; domain: string }) => {
    const baseUrl = domain.domain;
    const path = `/privacy-policy/${req.query.slug}`;
    return `${baseUrl}${path}`;
  });

  try {
    await Promise.all(urls.map(url => res.revalidate(url)));
    return res.json({ revalidated: true });
  } catch (err) {
    return res.status(500).json({ message: 'Error revalidating' });
  }
}

This is my code, thanks!!

[aleksakojadinovic]

I've never tried it but it probably won't work with full url such as mysite.com/en/some/path but rather /en/some/path. Therefore instead of using

const baseUrl = domain.domain;
// ...

I think it should be

const baseUrl = domain.defaultLocale; // <--- Just the locale prefix, not the full URL
const path = `/privacy-policy/${req.query.slug}`;
return `/${baseUrl}${path}`;

Notice that even though your actual URL could be es.mysite.com/some/path, you still need to specify the revalidation path like /es/some/path. This is because within the request itself Next.js is not aware of your actual domain, this is handled by your proxy depending on your production setup, so you should keep your paths relative.

[shinwonse]

@aleksakojadinovic Thank you!!!!!!! I finally solved it with your solution. You saved my time 🙏

[aleksakojadinovic]

No problem, glad to help :)