How to internationalize your Next.js SaaS -- reach global customers without rebuilding your app

You are leaving half your market on the table

If your SaaS only works in English, you are already invisible to a large portion of your potential customers. German B2B buyers want software in German. French consumers bounce off English-only signup forms. Spanish-speaking markets are growing faster than most English-speaking ones.

The good news: adding multi-language support -- called internationalization, or i18n -- to a Next.js app is a solved problem. The bad news: if you start from scratch, it takes longer than you expect. You end up rewriting copy, restructuring routes, and hunting down every hardcoded string in every form and error message.

If you are using Next.js Boilerplate, the foundation is already in place. Here is what the process looks like.

What internationalization actually means

You probably think of i18n as "translate the text." That is part of it, but the real work is:

• Detecting which language the user prefers
• Routing them to the right version of each page (e.g. /fr/pricing vs /en/pricing)
• Storing every user-facing string in a translation file instead of in the code
• Handling date, number, and currency formats that differ by locale
• Making sure search engines index your French and German pages, not just the English ones

None of this requires a major rebuild if your codebase is structured cleanly from the start.

How it works in Next.js App Router

Next.js App Router has built-in support for locale-aware routing. You add a [lang] segment to your route tree, and every page automatically knows which locale is active. A middleware file reads the user browser preferences and redirects them to the right language on first visit.

Translation files live in a messages/ folder -- one JSON file per language:

messages/
  en.json
  fr.json
  de.json

A lightweight library like next-intl reads the right file at render time and exposes a t() function. You call t(signup.title) in your component instead of writing the string inline, and the library swaps in the right translation.

// Before i18n
<h1>Create your account</h1>
 
// After i18n -- no rebuild needed to add a new language
<h1>{t(signup.title)}</h1>

That is the whole model. The structural work is setting up the routing and loading the right file. After that, adding a new language is a matter of adding a new JSON file -- no code changes required.

What you need to set up

There are five pieces:

1. A [lang] segment at the top of your app/ folder so every page is locale-aware
2. A middleware file that reads Accept-Language and redirects first-time visitors
3. A translation provider that wraps your root layout
4. One JSON file per language with all your strings
5. SEO metadata that includes hreflang tags so Google indexes each language version separately

The i18n skill in this boilerplate scaffolds all five in one step -- you do not have to figure out the routing or provider setup from scratch.

The SEO benefit is real

If you add French and German pages and include the right hreflang metadata, your site can rank in French and German Google searches. That is free distribution you are not getting today if your SaaS is English-only.

The boilerplate SEO setup already handles metadataBase and alternates.canonical. Extending it to include alternates.languages for each locale is a small, one-file addition.

When should you add i18n?

If you are pre-launch and your target market is clearly English-speaking, you can skip this for now. The DDD-lite module structure in this boilerplate keeps business logic isolated from presentation, so adding a translation layer later is not a painful refactor -- your strings are already in components, not scattered across service files.

If you already have users in multiple countries, or if your market research points to a non-English market as your best growth opportunity, add it now. Retrofitting i18n into a codebase full of hardcoded strings is slow and easy to miss. Starting clean is not.

What you skip when you start from this boilerplate

You do not have to figure out:

• The [lang] routing pattern and how it interacts with layouts
• How to pass the active locale through server components without prop drilling
• Which i18n library works cleanly with App Router and server components
• How to wire hreflang into your existing metadata setup

The boilerplate ships with an i18n skill that handles all of this. You tell it which languages you want, drop in the translation files, and you are done.

---

Get the Next.js Boilerplate and ship your SaaS in the languages your customers actually speak -- without rebuilding your app from scratch.