🗺️ Managing i18n Fallbacks in React Microfrontends (Without Duplicating English Files)

🗺️ Managing i18n Fallbacks in React Microfrontends (Without Duplicating English Files)

When your product grows internationally, handling multiple locales efficiently becomes crucial. In a React + i18next setup, the usual fallback chain is easy — until you enter a micro-frontend world with a third-party shell you can’t control.

Here’s what we learned while enabling Canadian English (en-CA) without duplicating our entire en translation set.

💡 The Initial Problem

Our app’s default language was en (US English). When we added support for Canada, we realized that: • The shell (which bootstraps our micro-frontends) is third-party, so we can’t rely on it to load default translations. • Each remote loads translations dynamically based on URL locale (/ca/…, /us/…, etc.). • Since the shell doesn’t preload en, the fallback mechanism never kicked in — i18next couldn’t fall back from en-CA → en. • That tempted us to copy en → en-CA JSON, which works but bloats maintenance.

⚠️ Why Copying Translations Is a Trap

Copying all en keys into en-CA seems quick, but it creates long-term pain:

Problem Description 🔁 Duplication Every update to en must be manually mirrored in en-CA ❌ Drift Easy to miss changes — users may see old text 📦 Bundle size Larger payloads for each locale 🧩 Confusion Difficult to know which file is source of truth

✅ The Better Pattern: Bootstrap + Fallback

Even without shell control, we can still leverage i18next’s fallbackLng logic by bootstrapping the base English bundle within each remote.

Folder structure

/i18n/en/common.json ← base English strings /i18n/en-CA/common.json ← only overrides for Canada /i18n/fr-CA/common.json ← French (Canada)

Remote i18n bootstrap (bootI18n.ts)

import i18n from ‘i18next’; import { initReactI18next } from ‘react-i18next’; import HttpBackend from ‘i18next-http-backend’;

const detectLocale = () => { const path = window.location.pathname; if (path.startsWith(‘/ca’)) return ‘en-CA’; return ‘en’; };

export async function bootI18n() { const lng = detectLocale(); const ns = [‘common’, ‘featureX’];

i18n .use(HttpBackend) .use(initReactI18next);

await i18n.init({ lng, fallbackLng: [‘en’], // 🔑 Core setting supportedLngs: [‘en’, ‘en-CA’, ‘fr-CA’], load: ‘currentOnly’, ns, defaultNS: ‘common’, returnNull: false, interpolation: { escapeValue: false }, backend: { loadPath: (lng, ns) => https://cdn.example.com/i18n/${lng}/${ns}.json, }, });

// Ensure base English is ready await i18n.loadLanguages(['en']); }

✅ If /i18n/en-CA/common.json doesn’t exist, i18next automatically falls back to /i18n/en/common.json.

✅ If it exists but has only partial keys, missing ones come from the base English bundle.

🧩 Handling Local Inline Strings

Some remotes ship their own translations inline (e.g., component-specific). You can register those like this:

i18n.addResourceBundle(‘en-CA’, ‘featureX’, { label: ‘Cheque’, }, true, true);

Only the changed keys (like spelling or currency words) live here; everything else falls back to en.

🚀 Benefits of This Pattern • Single source of truth — en is canonical. • Regional overrides only — en-CA stays tiny. • No shell dependency — remotes self-bootstrap. • Consistent formatting — use locale (en-CA) for date/currency, not for translation duplication.

🧠 Bonus: Locale-Based Formatting

Even if text comes from en, you can still render numbers and dates in Canadian formats:

new Intl.NumberFormat(‘en-CA’, { style: ‘currency’, currency: ‘CAD’ }).format(1234.56) // → “$1,234.56”

That’s handled entirely by Intl, not i18n.

🏁 Summary

Even with a 3rd-party shell, you can keep translations clean, DRY, and scalable.

If your shell is out of your hands, your remotes can still take control of translation quality — not by duplicating, but by leveraging smart fallbacks.