Best Boilerplates for i18n 2026

Your Users Don't All Speak English

English-only SaaS products leave money on the table. The global SaaS market includes millions of users who prefer their native language — and many who require it. Internationalization (i18n) isn't just translation; it's date formatting, number formatting, currency display, RTL layouts, and content adaptation.

Adding i18n to an existing SaaS is one of the most painful retrofits. Every string needs extraction. Every date needs formatting. Every layout needs RTL consideration. Starting with i18n-ready architecture saves weeks of painful refactoring later.

Three boilerplates take i18n seriously: Makerkit, Supastarter, and SaaSrock. Each approaches the problem differently.

TL;DR

Supastarter has the most comprehensive i18n — type-safe translations with next-intl or nuxt-i18n, locale-based routing, RTL support, and translated email templates. Makerkit provides clean i18n via plugin with namespace-based translations. SaaSrock includes multi-language support throughout its 40+ modules. Choose Supastarter for the most complete i18n. Choose Makerkit for clean, modular i18n. Choose SaaSrock for Remix i18n with maximum features.

Key Takeaways

• All three support multiple languages — the differences are in depth, tooling, and developer experience.
• Supastarter's i18n is the most comprehensive — locale routing, type-safe translations, RTL support, and translated emails.
• Makerkit's i18n is the cleanest architecture — isolated in a plugin, namespace-based translations, easy to add/remove.
• SaaSrock includes translations for all 40+ modules — if you use its built-in features, they're pre-translated.
• Type-safe translations are a game-changer — typos in translation keys caught at build time, not in production.
• RTL support is rare — only Supastarter provides meaningful RTL layout support. Adding RTL later is extremely painful.

---

i18n Feature Comparison

Feature	Makerkit	Supastarter	SaaSrock
Translation library	next-intl (plugin)	next-intl / nuxt-i18n	remix-i18next
Type-safe keys	✅	✅	⚠️ Basic
Locale routing	✅ /en/... /fr/...	✅ /en/... /fr/...	✅ /en/... /fr/...
Default locale (no prefix)	✅ Configurable	✅ Configurable	✅ Configurable
Browser detection	✅	✅	✅
User preference storage	✅ Cookie + DB	✅ Cookie + DB	✅ Cookie
Locale switcher UI	✅	✅	✅
Pluralization	✅ ICU format	✅ ICU format	✅ ICU format
Date/time formatting	✅ Intl API	✅ Intl API	✅ Intl API
Number formatting	✅ Intl API	✅ Intl API	✅ Intl API
Currency formatting	✅	✅	✅
RTL layout support	❌	✅	❌
Translated emails	❌	✅	⚠️ Basic
Translated metadata/SEO	✅	✅	✅
hreflang tags	✅	✅	⚠️ Manual
Translation namespaces	✅	✅	✅
Lazy loading translations	✅	✅	⚠️ Manual
Included languages	en	en, de, fr, es, pt, ja, ko, zh	en, es
Translation file format	JSON	JSON	JSON

Translation Architecture

Makerkit uses namespace-based translations isolated in its i18n plugin:

packages/i18n/
├── src/
│   ├── translations/
│   │   ├── en/
│   │   │   ├── common.json
│   │   │   ├── auth.json
│   │   │   ├── billing.json
│   │   │   └── dashboard.json
│   │   ├── fr/
│   │   │   ├── common.json
│   │   │   └── ...
│   │   └── de/
│   └── config.ts

Supastarter includes translations directly in the app with support for both Next.js and Nuxt:

locales/
├── en.json          # or split into namespaces
├── de.json
├── fr.json
├── es.json
├── pt.json
├── ja.json
├── ko.json
└── zh.json

Supastarter ships with 8+ languages pre-translated (at least for the UI shell). Your custom content needs translation, but the framework strings (buttons, labels, error messages) are ready.

SaaSrock includes translations for all its modules:

app/
├── i18n/
│   ├── en.json      # Covers all 40+ modules
│   └── es.json      # Spanish translations

SaaSrock's 40+ modules mean more strings to translate, but the built-in modules come pre-translated in English and Spanish.

Using Translations in Code

Makerkit / Supastarter (next-intl):

import { useTranslations } from 'next-intl';

export function DashboardHeader() {
  const t = useTranslations('dashboard');

  return (
    <div>
      <h1>{t('title')}</h1>
      <p>{t('welcome', { name: user.name })}</p>
      <p>{t('memberCount', { count: members.length })}</p>
    </div>
  );
}

{
  "dashboard": {
    "title": "Dashboard",
    "welcome": "Welcome back, {name}!",
    "memberCount": "{count, plural, =0 {No members} one {1 member} other {# members}}"
  }
}

Type-safe: if you reference t('dashboard.typo'), TypeScript flags it at build time.

SaaSrock (remix-i18next):

import { useTranslation } from 'react-i18next';

export function DashboardHeader() {
  const { t } = useTranslation();

  return (
    <div>
      <h1>{t('dashboard.title')}</h1>
      <p>{t('dashboard.welcome', { name: user.name })}</p>
    </div>
  );
}

Similar API but with weaker type safety — typos in translation keys are caught at runtime, not build time.

---

RTL Support

Right-to-left (RTL) languages (Arabic, Hebrew, Persian, Urdu) require layout mirroring — sidebars on the right, text aligned right, directional icons flipped.

RTL Feature	Makerkit	Supastarter	SaaSrock
dir="rtl" attribute	❌	✅ Automatic	❌
CSS logical properties	⚠️ Partial	✅ Full	❌
Layout mirroring	❌	✅	❌
Icon direction flipping	❌	✅	❌
Arabic/Hebrew included	❌	✅ Arabic	❌

RTL is hard to add later. It requires replacing margin-left with margin-inline-start, padding-right with padding-inline-end, and flipping every directional layout assumption. Supastarter using CSS logical properties from the start means RTL works without CSS changes.

If you have any chance of supporting Arabic, Hebrew, or Urdu markets — start with Supastarter.

---

SEO for Multi-Language Sites

Feature	Makerkit	Supastarter	SaaSrock
Locale-prefixed URLs	✅ /en/blog, /fr/blog	✅ /en/blog, /fr/blog	✅ /en/blog, /es/blog
hreflang tags	✅	✅ Automatic	⚠️ Manual
Translated meta tags	✅	✅	✅
Translated sitemap	✅	✅ Per-locale	⚠️ Manual
Translated OG images	❌	⚠️ Manual	❌
Canonical URLs	✅	✅	⚠️ Manual

For multilingual SEO, hreflang tags tell search engines which version of a page to show for each language. Missing hreflang tags can cause duplicate content penalties or wrong-language results. Supastarter and Makerkit handle this automatically.

---

Translation Workflow

Adding a New Language

Makerkit:

1. Create new JSON files in packages/i18n/translations/[locale]/
2. Add locale to config
3. Deploy

Supastarter:

1. Create new JSON file in locales/[locale].json
2. Add locale to next-intl config
3. Deploy

SaaSrock:

1. Create new JSON file in app/i18n/[locale].json
2. Add locale to i18n config
3. Deploy

All three follow the same pattern. The difference is in how many strings you need to translate — SaaSrock's 40+ modules mean significantly more strings.

Translation Management at Scale

For SaaS products with 10+ languages, managing JSON files manually becomes painful. Consider integrating:

Tool	Purpose	Makerkit	Supastarter	SaaSrock
Crowdin	Translation management	✅ Compatible	✅ Compatible	✅ Compatible
Lokalise	Translation management	✅ Compatible	✅ Compatible	✅ Compatible
i18n Ally (VS Code)	In-editor translations	✅ Compatible	✅ Compatible	✅ Compatible
AI translation	GPT/Claude for drafts	✅ JSON format	✅ JSON format	✅ JSON format

All three use JSON translation files, which are compatible with every translation management platform.

---

When to Choose Each

Choose Supastarter If:

• RTL support is needed — Arabic, Hebrew, or Persian markets
• You want pre-translated UI — 8+ languages included for the framework shell
• Comprehensive i18n matters — locale routing, translated emails, hreflang, everything handled
• Type-safe translations — typos caught at build time
• International markets from day one — not retrofitting later

Choose Makerkit If:

• Clean architecture is priority — i18n isolated in a plugin, easy to add or remove
• You want modular translations — namespace-based, load only what's needed per page
• Type-safe keys — TypeScript catches translation key typos
• You don't need RTL — LTR languages only
• You'll manage translations yourself — clean JSON files per language per namespace

Choose SaaSrock If:

• You're using Remix — SaaSrock is the most i18n-capable Remix boilerplate
• You need all modules translated — SaaSrock's 40+ modules include translation strings
• Spanish is a priority market — English + Spanish included by default
• Feature-rich B2B SaaS with CRM, help desk, etc. — all translatable

---

Why Start with i18n Architecture from Day One

The case for starting i18n-ready mirrors the multi-tenancy argument: retrofitting it onto an established codebase is disproportionately painful compared to building on i18n foundations from the beginning.

Without i18n foundations, every user-facing string is a hardcoded English literal. Adding a second language requires:

1. Audit every component — find all hardcoded strings across hundreds of files and extract them into JSON translation namespaces
2. Add locale routing — restructure every route to support /en/, /fr/, /de/ path prefixes without breaking existing links
3. Handle date and number formatting — replace hardcoded locale assumptions with Intl.DateTimeFormat and Intl.NumberFormat
4. Update SEO metadata — add hreflang tags, per-locale sitemaps, and translated Open Graph tags to every page
5. Localize transactional emails — every password reset, welcome, and invoice email needs translated templates
6. Handle RTL if needed — replace all directional CSS properties with logical properties throughout the entire design system

For an established SaaS codebase, this work typically takes 4-8 weeks and is highly disruptive because it touches nearly every component, route, and email template simultaneously. Teams often discover edge cases (date pickers, number inputs, pluralization logic) that weren't obvious during initial development.

Starting with Supastarter, Makerkit, or SaaSrock means this infrastructure is already in place from the first commit. The locale routing, type-safe translation keys, and properly formatted dates are there. Adding a new language is a single JSON translation file.

For bootstrapped founders, the practical argument is clear: the EU is a significant developer market, much of it preferring non-English interfaces. Japanese, Korean, and Brazilian Portuguese markets pay well for properly localized SaaS products. Starting i18n-ready positions your product to capitalize on those markets without requiring an architectural refactoring sprint.

Choosing Your i18n Library in 2026

The three most common i18n library choices in Next.js SaaS boilerplates, with different trade-offs:

next-intl (used in most Next.js App Router boilerplates in 2026, including Makerkit and Supastarter): tight integration with Next.js App Router, TypeScript-first with generated type definitions for translation keys, server-component-compatible for SSR with zero hydration overhead. The useTranslations hook and type-checked t() function catch missing translation keys at compile time — a significant advantage over runtime key lookups. Next-intl is the most actively maintained option specifically for the App Router context.

react-i18next (the legacy default, still in many Pages Router and older App Router boilerplates): battle-tested, enormous community, extensive plugin ecosystem (language detection, plural forms, context). The trade-off: it was designed for React before Server Components, and using it in RSC requires the client wrapper. For teams migrating from Pages Router or with extensive existing i18n configurations, it's often the practical choice.

Paraglide JS (emerging in 2025-2026): takes a different approach — instead of a runtime translation lookup, Paraglide compiles translations into tree-shakeable JavaScript modules. The result: zero runtime overhead for unused translations, maximum bundle efficiency. Paraglide is particularly strong for statically generated multilingual sites. It's less mature than next-intl but growing in adoption for edge-first and SSG-heavy deployments.

For boilerplates using i18n: next-intl is the current default for App Router projects, and the correct recommendation for teams starting new Next.js SaaS products in 2026. The type safety alone — catching t('missing-key') errors at compile time rather than as blank strings in production — justifies the migration from react-i18next for new projects. react-i18next remains valid for teams with significant existing localization work and established workflows around its CLI tools and PO file format.

Compare i18n features across 50+ boilerplates on StarterPick — filter by language support and localization features.

Review Supastarter and compare alternatives on StarterPick.

See how these three i18n-ready boilerplates rank in the full market in the best SaaS boilerplates guide, and compare their pricing and architecture depth in the best premium SaaS boilerplates guide.

For the full stack context — how i18n choice interacts with database architecture, auth, and deployment — see the Next.js SaaS tech stack 2026 guide.

The EU market, Japanese market, and Brazilian Portuguese market each represent significant revenue opportunity for SaaS products that localize well. The 4-8 week cost of retrofitting i18n onto an established codebase makes the case clearly: start with i18n foundations in the boilerplate, even if you launch in English first. The incremental cost of adding a second language to a properly structured codebase is 1-2 days of work, not weeks.