next-international: Client Components mismatching translations during static rendering

After executing next build, if I open the .next/server/app/en.html file, I can see that the keys inputted into the t function of useI18n are exposed. In other words, the translated values are not displayed. The t function of getI18n works properly. Is this a known issue?

About this issue

Original URL
State: closed
Created 9 months ago
Reactions: 1
Comments: 32 (31 by maintainers)

Most upvoted comments

I got something working with React’s use() hook and will make a PR this weekend to hopefully fix the issue, and remove the need for fallbackLocale

QuiiBz on Sep 28, 2023

I’ve looked a bit and the issue occurs when using a client component while pre-rendering a page. Because locales are lazy-loaded on the client, the fallbackLocale is used in all pages.

An easy fix would be to set the correct fallbackLocale based on the current locale params:

<I18nProviderClient fallbackLocale={params.locale === 'en' ? en : fr}>
  {children}
</I18nProviderClient>

QuiiBz on Sep 27, 2023

Can you share the PR/commit that have this error? I don’t have it on the example app.

I’m refactoring a lot of things in my project, I’m not sure that it comes from the current Next-International RC.

gustaveWPM on Oct 1, 2023

The issue with this approach is that all locales are now loaded client-side, and that’s not something we want. We have to find a way to trigger to dynamically load the requested locale and wait until it’s complete to continue pre-rendering (the current behavior doesn’t wait and pre-renders immediately, causing it to show the keys OR the fallback locale).

QuiiBz on Sep 27, 2023

I think that’s because you have a 'use client' in your root layout, so your pages are also client and thus when pre-rendered, uses the fallbackLocale.

I’m wondering how Next.js behaves if we trigger a loading state to force the correct locale to load completely before pre-rendering a page. I’ll dig later.

QuiiBz on Sep 25, 2023