Does not support Pages router with Next.js < 13 about next-intl

[amannn]

Hey @sraka1, many thanks for the report! There was an oversight here on my side indeed.

While all of the Pages Router-compatible APIs from next-intl work in Next.js <13, there is one exception: useLocale (which imports from next/navigation). This API is in fact not necessary for the Pages Router, but router.locale should be used instead.

However, Next.js <13 uses the CommonJS entry of next-intl, therefore useLocale isn't removed via tree shaking and that's the reason why you're seeing the error.

The good news is that Next.js 10–12 is still fully supported, but you have to import from use-intl instead of next-intl.

I've just added a corresponding section to the docs: Support for legacy Next.js versions. There's also a working example referenced in the section.

Can you have a look if this works for you?

In the next major version I'll have to adjust the peer dependency version of next-intl to >=13, but use-intl will continue to support older Next.js versions. Note that in case you choose to adopt Next.js >=13 and possibly the App Router, you can seamlessly replace use-intl with next-intl globally and your app will continue to work.

[sraka1]

@amannn excellent, thanks for the explanation. In the meanwhile I reverted to version @2, which seems to also work fine for now. :)

Also, separately, a couple more things:

1. #951 <- I think what the user was alluding here was to import the messages in _app using getInitialProps (deprecated) to remove code repetition on each page using getStaticProps. This works, I've tried it myself. Do you see any issues with it (apart from obviously using a deprecated Next method)?
2. Going from that, I think it would be cool to provide a Pages example for use without the built-in routing from Next - you already provide one for using a single language, which serves as a base. I think it's also valid for SaaS applications (you mention this use case on the App Router pages) where the language selected is not reflected anywhere in the URL. Would you mind if I make a PR with changes to the docs for this use case and perhaps provide an example?
3. This following question pertains to the above case of not using URL based i18n (https://next-intl-docs.vercel.app/docs/getting-started/app-router/without-i18n-routing - App router example, but same applies to Pages); how would you solve changing the user locale with a switcher without reloading the page?

  // Provide a static locale, fetch a user setting,
  // read from `cookies()`, `headers()`, etc.
  const locale = 'en';

AFAIK, this is only executed once per request server-side and thus the messages are loaded (and injected into the DOM) at that time. I really don't want to do set cookie->reload page->see language change but rather instantly just change the language (perhaps we need to reload the messages client-side. Obviously we try implementing this ourselves (the component just needs a locale and messages), but I think it would be cool if you either provide such functionality built-in (perhaps even some opinionated functionality of storing the language setting that works well both SSR and CSR - probably a cookie) or provide a good example. I can also try doing the latter in a PR.

Sorry for the long write-up. Nice library, thanks for your work 👍

[amannn]

@amannn excellent, thanks for the explanation. In the meanwhile I reverted to version @2, which seems to also work fine for now. :)

Sure, that's fine! use-intl received some features and also fixes since v2 though, maybe you could consider updating at some point!

In regard to your other comments:

1. Do you see any issues with it (apart from obviously using a deprecated Next method)?

Definitely ok from my perspective!

it would be cool to provide a Pages example for use without the built-in routing from Next

I think what you're looking for is shown in the App Router migration example. Maybe that helps?

how would you solve changing the user locale with a switcher without reloading the page?

There are existing discussions like #723, does that help? Reloading the page should not be the case (at least with App Router), but Next.js has to re-mount the page.

---

I'm going to close this issue as the original question has been resolved. Hope you can get your project off the ground successfully! 🙌