I18n Pitfalls: Solving Navigation Menu and Layout Translation Issues in Next.js

Hello! Today, I want to share a technical troubleshooting story from the development journey of hafuture. The topic is "Synchronizing Layout Components in a Multilingual Environment."

Discovery: "The Content is Korean, but why is the Menu in English?"

hafuture is a platform providing various utility tools for text processing, PDF editing, and calculations for a global audience. Therefore, perfect support for Korean, English, and Japanese was our top priority.

We implemented internationalization (i18n) using the next-intl library. However, while testing the blog page one day, we noticed something strange. When accessing /ko/blog, the blog post body and title were correctly in Korean, but the Header menu at the top and the Footer at the bottom were still in English.

Even when switching languages through the globe icon, only the URL changed—the common layout elements remained stubborn. It felt like the layout was living in a different time zone.

Root Cause Analysis: Missing Client-Side Context

There were two main reasons:

1. Missing Locale in NextIntlClientProvider: Although we were loading and providing all messages in layout.tsx, we weren't explicitly telling NextIntlClientProvider which language (locale) to use. Consequently, client components like the Header and Footer defaulted to English.
2. Ambiguous Message Loading: Omitting arguments when calling getMessages() in server components carried the risk of returning messages for the default language if the request context wasn't captured correctly.

Solution: Explicit Locale Injection

To solve this, we updated the code with these steps:

1. Updating Root Layout

First, we changed RootLayout to pass the locale directly from the URL to NextIntlClientProvider. This ensures all nested client components share the same language context.

// src/app/[locale]/layout.tsx
<NextIntlClientProvider locale={locale} messages={messages}>
  <Header />
  {children}
  <Footer />
</NextIntlClientProvider>

2. Strengthening Blog Page Translation Logic

On the blog list page, we explicitly specified the locale, using getTranslations({ locale, namespace: "Blog" }), to guarantee accurate language data during Server-Side Rendering (SSR).

3. Simplifying Language Switcher Logic

We removed complex path parsing logic and relied on next-intl's built-in features. This also resolved some unnecessary routing errors.

Results and Lessons Learned

After the fix, switching languages on the blog page instantly translated "Text Tools" to "텍스트 도구" and "Blog" to "블로그" (and respective Japanese terms).

The two big lessons from this task are:

• I18n Strategies depend on Component Type: Server components need request context, while client components need shared context through providers.
• Explicit is better than implicit: Rather than expecting automatic handling, passing locale information explicitly is much better for debugging and maintenance.

I hope this post helps developers aiming for global services. Supporting multiple languages is more than just changing text—it's the first step in respecting the user's environment!

Thank you.