This library is PAINFULLY slow on Nextjs, specially when integrating route based locales. DO NOT USE THIS LIBRARY IF YOU'RE NEW TO INTERNATIONALIZATION...

[Joe-Moussally]

I'm sorry but i have to be this guy, if you're new to translations, internationalization, this library is not for you, even if it seems easy to set up, bugs, cache issues, rtl issues, and other stuff keep adding up, not to mention the compile time that takes longer that a hair salon appointment. DO NOT USE THIS LIBRARY IF YOU'RE NEW TO NEXTJS.

I would instead recommend next-international https://next-international.vercel.app/ , good DX, easy setup, and not a PAINFULLY hard documentation to follow and PAINFULLY slow bottleneck introductions. TOOK ME 2 WEEKS!! 2 WEEKS TO REALIZE THAT THIS LIBRARY IS NOT THAT GOOD, THERE WAS NO HOPE FIXING THOSE PERFORMANCE ISSUES AND RTL ISSUES next-internationalization is MUCH MUCHHH BETTER https://next-international.vercel.app/. It was such a relief integrating it.

PS: If you really insist on using this library, maybe one solution/extra step to keep in mind is you'd need to keep the root layout outside the [locale] folder, and create a LocaleLayout inside the [locale] dynamic route folder, this will increase the performance a bit, but hey... good luck.

[amannn]

Hey buddy, sorry to hear if you had a bad experience!

If you're unsure about setting up an app, you can always start with the App Router with locale-based routing example.

I'd also argue it's pretty fast:

(https://pagespeed.web.dev/analysis/https-next-intl-example-app-router-vercel-app-en/mscblt3svc?form_factor=mobile)

But happy to be proven wrong if you spot something that I've overlooked!

[Joe-Moussally]

Hello @amannn , I apologize in advance for the negative reaction, I've been debugging for 3.5weeks now, looking further into the issue. It seems there's a weird issue I'm encountering is when if I move every route inside a variable route (in this example would be [locale] app router), this move that I followed in the documentation introduced the PAINFULLY slow performance. the generateStaticParams didn't help at all. Upgrading to Nextjs 16 didn't help, I couldn't pin down the issue exactly and can't know and figure out the source, but it happened once I moved everything into the /[locale] path folder. I just decided to use another library, and what's weird is that when I moved to /[locale] the slowdown didn't happen for the other libraries, that's where I assumed the issue is from next-intl.

Maybe there's a weird bug/interaction with other Providers/wrappers I might have, or any libraries I use? If this is something that could help improve the library let me know, I'll try and reproduce it on a public repo because I wouldn't want any other developer to experience what I just encountered. No amount of coffee and short breaks helped me with this :p

[amannn]

All good. One aspect that can improve dev performance in certain scenarios is to use static rendering with setRequestLocale. It avoids reading a request header, and thus improves cacheability (e.g. for later fetch calls). It's the same functionality as e.g. setStaticParamsLocale in next-international (which is also opt-in), so performance should be pretty similar.

In the future with next/root-params, setRequestLocale will no longer be necessary and you'll get this performance benefit OOTB.

Hope this helps!

[mhornbacher]

I can second that, I used next-intl on a pretty serious prototype with close to a thousand translations across various user flows and 3rd party integrations (using it to power Zod translations for example) and our response times where in the <10ms range for cached/static components and ~50-100ms for SSRed pages (most of that was cleanly attributable to other integrations such as our DB calls for auth to complex join tables)