problem Next js dynmic pages with i18n library

Tackling Localization Challenges in Next.js with i18n and Dynamic Routes

When building a multilingual website with dynamic content in Next.js, keeping the localization consistent across different pages is crucial for a seamless user experience. I recently encountered a challenging scenario where the language reverted to the default English (‘En’) upon entering a dynamic page, despite setting up localization with the i18n library. This issue seemed particularly persistent when utilizing getStaticProps and getStaticPaths for generating the pages. Today, I want to share how I navigated through this issue to maintain the expected localization on dynamic pages.

Understanding the Localization Issue

The problem surfaced when navigating into a dynamic page; the language setting would unpredictably switch back to the default (‘En’), even though other parts of the app correctly reflected the user’s language choice. Using useRouter from next/router confirmed that the locale was correctly identified in client-side code, but during the build steps (getStaticProps and getStaticPaths), it seemed to revert or not recognize the selected locale properly.

Let’s explore the code setup that led to this complication:

In my dynamic page, getStaticProps was set up like this:

export const getStaticProps = async (context: any) => {
  const { locale, params } = context;

  // Mock-up function for demonstrating fetching data
  const { data: prj, imageSrc } = fetchDataBasedOnId(params.id);

  const newData = {
    ...prj,
    image: imageSrc,
  };

  return {
    props: {
      ...(await serverSideTranslations(locale, 'common', 'home')),
      data: newData,
    },
  };
};

And getStaticPaths was defined as follows:

export const getStaticPaths = async (context: any) => {
  const { locales } = context;

  const { data } = await getPosts();  // Assume this fetches array of post objects
  const dataIds = data.map((item: any) => item.id);

  const paths = dataIds.flatMap((id: any) =>
    locales.map((locale: any) => ({
      params: { id: String(id) },
      locale,
    }))
  );

  return {
    paths,
    fallback: 'blocking',
  };
};

The Solution to Maintain Localization Consistency

To resolve this issue, I needed to ensure that both the server-side and client-side components of Next.js were aware of the current locale at all times, especially during the static generation process.

1. Proper serverSideTranslations Usage:

Make sure that serverSideTranslations from next-i18next is included and properly awaited in the getStaticProps function. This function is vital for loading the required namespaces and providing the translations based on the selected locale.

1. Correct Locale Handling in getStaticPaths:

It’s essential that each path object includes the locale in the paths generated by getStaticPaths. This inclusion ensures that each static page is generated for every locale with proper locale data attached.

1. Debugging and validating fallback:

Implementing a correct fallback method in getStaticPaths can also affect how the locales are handled. In our setup, using 'blocking' helps in ensuring that if a page isn’t pre-rendered at build time, it will only be displayed once all necessary data is fetched, which includes ensuring the correct locale data is loaded.

1. Testing Across Different Environments:

Finally, thoroughly test the localization across various environments (development, staging, production) to ensure that the locale switching works as expected and persists across page navigations and reloads.

Conclusion

Achieving consistent localization with dynamic routes in a Next.js application can introduce unique challenges, particularly when leveraging static generation methods like getStaticProps and getStaticPaths. By ensuring the correct handling of locales in these functions and systematically testing the environment, you can maintain an excellent multilingual user experience.