v7.x compatibility question

[RwwL]

I'm working on an older app that's still on Next.js v10.x and next-i18next v7.x.

I'm in the middle of migrating to Next.js v12.x now, and trying to get a sense of whether I absolutely have to upgrade to a more current i18next now or whether I should be able to keep things running on 7.x for awhile, possibly with some light refactoring, and migrate that part later, since there's already plenty of other things that need attention right away as part of the Next.js upgrade.

Right now the big sticking point with just upgrading next-i18next is the apparent need to add the serverSideTranslations call to every page since it's a large app (100+ pages). I'm still wrapping my head around our entire 7.x setup, but the current state of things in my local app now on 12.x is that direct-loads of pages seem to get all the required translation files through our old setup, but there are also new 404s for some of the locale .json files in the console. Client-rendered subsequent page loads in development seem to be missing all their translations.

Any getting-started guidance I can get from the community on this is very welcome, thanks.

[adrai]

fyi: v7.x was before the major rewrite, that was leveraging the built-in internationalised routing provided by NextJs.

[RwwL]

Yeah, I'll see if I can make the time to try to build that later. Before I do, can I ask one more question? It seems to me like this leftover piece of our old implementation might be obsolete and need to come out, would you agree?

// Ensure that anytime a translation is programmatically updated
// all instances of i18next will re-render with the new data.
i18n.store.on('added', () => {
  i18n.changeLanguage('en');
});

Calling changeLanguage when we're not really changing languages feels a bit like a hack; did our previous developer set this up strangely? It seems that if I'm calling addResources in one place and then using bindI18n: 'languageChanged added' elsewhere then maybe that's all that should be needed?

But apparently not, because if I comment that out then the initial-page-load scenario stops working.

[adrai]

yes, probably a leftover piece

[RwwL]

Well, if I remove it, the only part that's currently working stops working (having the custom keys render on an initial page load in the section that uses them).

[adrai]

like said... a reproducible example would help

[RwwL]

Yeah, I know, thanks. But the time required to build that is probably more than the time it'd take to refactor our app to not use this hot-loaded namespace at all, and simply render the custom values when they exist, and render those strings via useTranslation when they don't. I'll probably go that route, but thanks again very much for your time (both on this thread and the general maintenance of these projects).