The Complete Developer's Guide to Internationalization (i18n) in 2026

Internationalization (i18n) is the process of designing and developing software applications to support multiple languages and regional formats without requiring engineering changes for each new locale. The term "i18n" is a numeronym where "18" represents the eighteen letters between "i" and "n" in "internationalization." Effective i18n separates locale-specific elements (text strings, date formats, number formats, currency) from core application logic, enabling localization (l10n) teams to adapt the product for different markets without modifying source code. Modern i18n architecture in 2026 encompasses translation key management, ICU message format for handling plurals and variables, right-to-left (RTL) layout support, locale-specific formatting, and deployment strategies including over-the-air updates. Proper i18n implementation enables global software distribution, reduces time-to-market for new regions, and prevents expensive refactoring when international expansion becomes a business priority. Understanding i18n fundamentals is essential for developers building products with global ambitions, regardless of whether localization is an immediate priority or a future roadmap item.

This comprehensive guide covers everything from basic concepts through production-ready implementation patterns across modern frameworks.

Why Internationalization Matters

Business Impact:

• Market Expansion: 75% of internet users don't speak English as their primary language
• Revenue Growth: Companies with localized products report 1.5-3x higher international revenue
• Competitive Advantage: Localized experiences reduce friction and increase conversion rates
• User Satisfaction: 72% of users prefer products in their native language (CSA Research)

Technical Benefits:

• Future-Proofing: Avoid expensive refactoring when localization becomes priority
• Code Quality: Separation of concerns improves maintainability
• Scalability: Add languages without code changes
• Testing: Locale-specific logic isolated and testable

Cost of Delayed i18n:

Retrofitting i18n into existing applications typically costs 3-5x more than building it from the start:

• Extracting hardcoded strings from thousands of files
• Refactoring layouts that assume English text length
• Fixing date/number formatting scattered throughout codebase
• Updating test suites and QA processes

Core i18n Concepts

Locale

A locale identifies a language and optional region, formatted as language-REGION:

• en: English (generic)
• en-US: English (United States)
• en-GB: English (United Kingdom)
• es: Spanish (generic)
• es-MX: Spanish (Mexico)
• pt-BR: Portuguese (Brazil)

Best Practice: Use language-only codes (e.g., es) unless regional differences are significant. Over-specifying creates unnecessary translation work.

Translation Keys

Translation keys are identifiers that map to locale-specific strings:

TypeScriptCopy
1// Translation files
2{
3  "en": {
4    "greeting": "Hello, {name}!",
5    "button.save": "Save"
6  },
7  "es": {
8    "greeting": "¡Hola, {name}!",
9    "button.save": "Guardar"
10  }
11}
12
13// Usage in code
14t('greeting', { name: 'Alice' })  // "Hello, Alice!" or "¡Hola, Alice!"
15t('button.save')  // "Save" or "Guardar"

Naming Conventions:

• Hierarchical namespacing: feature.component.element (e.g., dashboard.settings.title)
• Descriptive not literal: user.greeting better than hello_user
• Consistent structure: Establish conventions early and enforce with linting

ICU Message Format

ICU (International Components for Unicode) MessageFormat handles complex translations with plurals, gender, and variables:

Pluralization:

TypeScriptCopy
1{
2  "items": "{count, plural, =0 {No items} one {# item} other {# items}}"
3}
4
5t('items', { count: 0 })  // "No items"
6t('items', { count: 1 })  // "1 item"
7t('items', { count: 5 })  // "5 items"

Select (Gender/Context):

TypeScriptCopy
{
  "task_assignment": "{gender, select, male {He is assigned} female {She is assigned} other {They are assigned}}"
}

Complex Nesting:

TypeScriptCopy
1{
2  "inbox": "You have {unreadCount, plural, =0 {no new messages} one {# new message} other {# new messages}} in {folderCount, plural, one {# folder} other {# folders}}."
3}
4
5t('inbox', { unreadCount: 3, folderCount: 2 })
6// "You have 3 new messages in 2 folders."

Why ICU Format:

• Handles linguistic complexity (languages have different plural rules)
• Prevents concatenation antipatterns
• Gives translators full context and flexibility
• Supported by all major i18n libraries

Locale-Specific Formatting

Dates:

• US: 2/12/2026 (MM/DD/YYYY)
• UK: 12/02/2026 (DD/MM/YYYY)
• ISO: 2026-02-12 (YYYY-MM-DD)

Numbers:

• US: 1,234.56
• Europe: 1.234,56 or 1 234,56

Currency:

• US: $1,234.56
• UK: £1,234.56
• EU: 1.234,56 €
• Japan: ¥1,235 (no decimals)

Time:

• 12-hour: 3:30 PM
• 24-hour: 15:30

Use built-in Intl APIs or i18n library helpers:

TypeScriptCopy
1// Native Intl API
2new Intl.DateTimeFormat('en-US').format(date)  // "2/12/2026"
3new Intl.DateTimeFormat('de-DE').format(date)  // "12.2.2026"
4
5new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' })
6  .format(1234.56)  // "$1,234.56"

Right-to-Left (RTL) Support

Languages like Arabic, Hebrew, and Urdu read right-to-left. RTL support requires:

Layout Mirroring:

• Navigation menus flip horizontal position
• Text alignment reverses
• Icons and directional UI elements mirror

CSS Logical Properties:

CSSCopy
1/* ❌ Avoid physical properties */
2.element {
3  margin-left: 16px;
4  text-align: left;
5}
6
7/* ✅ Use logical properties */
8.element {
9  margin-inline-start: 16px;
10  text-align: start;
11}

HTML Direction Attribute:

HTMLCopy
<html dir="ltr">  <!-- Left-to-right (English, Spanish) -->
<html dir="rtl">  <!-- Right-to-left (Arabic, Hebrew) -->

Modern frameworks handle much of this automatically when you set the document direction.

i18n Architecture Patterns

File Organization

Pattern 1: Centralized Translation Files

locales/
  en/
    common.json
    dashboard.json
    settings.json
  es/
    common.json
    dashboard.json
    settings.json

Benefits: Simple structure, easy for translators, centralized management Drawbacks: Can become large, merge conflicts in large teams

Pattern 2: Feature-Colocated

src/
  features/
    auth/
      Login.tsx
      i18n/
        en.json
        es.json
    dashboard/
      Dashboard.tsx
      i18n/
        en.json
        es.json

Benefits: Clear feature ownership, easier refactoring, parallel development Drawbacks: More complex build setup, harder for non-technical translators

Pattern 3: Hybrid Approach

locales/
  common/  # Shared strings
    en.json
    es.json
src/
  features/
    auth/
      i18n/  # Feature-specific
        en.json
        es.json

Benefits: Best of both worlds Recommendation: Use for medium-to-large applications

Translation Loading Strategies

Strategy 1: Bundle All Translations

TypeScriptCopy
1import en from './locales/en.json';
2import es from './locales/es.json';
3
4const translations = { en, es };

• Pros: Simple, works offline immediately
• Cons: Large bundle size, loads unused languages
• Use case: Small apps, <10 languages, <5000 strings per language

Strategy 2: Lazy Load by Route

TypeScriptCopy
1const loadTranslations = async (locale: string, namespace: string) => {
2  const translations = await import(`./locales/${locale}/${namespace}.json`);
3  return translations;
4};

• Pros: Smaller initial bundle, loads on-demand
• Cons: Loading delay, requires bundler configuration
• Use case: Large apps with clear feature boundaries

Strategy 3: Runtime Fetch (CDN)

TypeScriptCopy
1const loadTranslations = async (locale: string) => {
2  const response = await fetch(`https://cdn.example.com/i18n/${locale}.json`);
3  return response.json();
4};

• Pros: Update translations without redeployment, smallest bundle
• Cons: Network dependency, requires fallback
• Use case: Frequently updated content, mobile apps with OTA

Strategy 4: Hybrid (Bundle + OTA)

TypeScriptCopy
1// Bundle baseline translations
2import fallback from './locales/en.json';
3
4// Fetch latest from CDN
5const loadTranslations = async (locale: string) => {
6  try {
7    const response = await fetch(`https://cdn.example.com/i18n/${locale}.json`);
8    return response.json();
9  } catch {
10    return fallback;  // Use bundled fallback if network fails
11  }
12};

• Pros: Best of both worlds—offline support + live updates
• Cons: More complex implementation
• Use case: Production apps requiring reliability and agility

Framework-Specific Implementation

React with next-intl (Next.js App Router)

Installation:

TerminalCopy
npm install next-intl

Configuration:

TypeScriptCopy
1// i18n/request.ts
2import { getRequestConfig } from 'next-intl/server';
3
4export default getRequestConfig(async ({ locale }) => ({
5  messages: (await import(`../locales/${locale}.json`)).default
6}));
7
8// next.config.js
9const createNextIntlPlugin = require('next-intl/plugin');
10const withNextIntl = createNextIntlPlugin('./i18n/request.ts');
11
12module.exports = withNextIntl({
13  // Your Next.js config
14});

Usage:

TypeScriptCopy
1// app/[locale]/page.tsx
2import { useTranslations } from 'next-intl';
3
4export default function HomePage() {
5  const t = useTranslations('HomePage');
6
7  return (
8    <div>
9      <h1>{t('title')}</h1>
10      <p>{t('welcome', { name: 'Alice' })}</p>
11    </div>
12  );
13}

Type Safety:

TypeScriptCopy
1// global.d.ts
2type Messages = typeof import('./locales/en.json');
3declare global {
4  interface IntlMessages extends Messages {}
5}

Now TypeScript will autocomplete translation keys and catch typos.

React with react-i18next

Installation:

TerminalCopy
npm install react-i18next i18next

Configuration:

TypeScriptCopy
1// i18n.ts
2import i18n from 'i18next';
3import { initReactI18next } from 'react-i18next';
4import en from './locales/en.json';
5import es from './locales/es.json';
6
7i18n
8  .use(initReactI18next)
9  .init({
10    resources: {
11      en: { translation: en },
12      es: { translation: es }
13    },
14    lng: 'en',
15    fallbackLng: 'en',
16    interpolation: { escapeValue: false }
17  });
18
19export default i18n;

Usage:

TypeScriptCopy
1import { useTranslation } from 'react-i18next';
2
3function MyComponent() {
4  const { t } = useTranslation();
5
6  return (
7    <div>
8      <h1>{t('title')}</h1>
9      <p>{t('greeting', { name: 'Alice' })}</p>
10    </div>
11  );
12}

Vue with Vue I18n

Installation:

TerminalCopy
npm install vue-i18n

Configuration:

TypeScriptCopy
1// i18n.ts
2import { createI18n } from 'vue-i18n';
3import en from './locales/en.json';
4import es from './locales/es.json';
5
6const i18n = createI18n({
7  legacy: false,  // Use Composition API
8  locale: 'en',
9  fallbackLocale: 'en',
10  messages: { en, es }
11});
12
13export default i18n;
14
15// main.ts
16import { createApp } from 'vue';
17import i18n from './i18n';
18
19createApp(App).use(i18n).mount('#app');

Usage:

VUECopy
1<template>
2  <div>
3    <h1>{{ t('title') }}</h1>
4    <p>{{ t('greeting', { name: 'Alice' }) }}</p>
5  </div>
6</template>
7
8<script setup>
9import { useI18n } from 'vue-i18n';
10
11const { t } = useI18n();
12</script>

React Native with react-i18next

Installation:

TerminalCopy
npm install react-i18next i18next

Configuration with OTA:

TypeScriptCopy
1// i18n.ts
2import i18n from 'i18next';
3import { initReactI18next } from 'react-i18next';
4import * as Localization from 'expo-localization';
5import AsyncStorage from '@react-native-async-storage/async-storage';
6
7// Bundle fallback translations
8import en from './locales/en.json';
9
10// OTA translation loader
11const fetchTranslations = async (locale: string) => {
12  try {
13    const response = await fetch(`https://cdn.example.com/i18n/${locale}.json`);
14    const translations = await response.json();
15    await AsyncStorage.setItem(`i18n_${locale}`, JSON.stringify(translations));
16    return translations;
17  } catch (error) {
18    // Load cached version if available
19    const cached = await AsyncStorage.getItem(`i18n_${locale}`);
20    return cached ? JSON.parse(cached) : null;
21  }
22};
23
24i18n
25  .use(initReactI18next)
26  .init({
27    resources: { en: { translation: en } },
28    lng: Localization.locale.split('-')[0],
29    fallbackLng: 'en',
30    interpolation: { escapeValue: false }
31  });
32
33// Fetch latest translations on app start
34(async () => {
35  const locale = i18n.language;
36  const translations = await fetchTranslations(locale);
37  if (translations) {
38    i18n.addResourceBundle(locale, 'translation', translations, true, true);
39  }
40})();
41
42export default i18n;

Flutter with flutter_localizations

Setup:

YAMLCopy
1# pubspec.yaml
2dependencies:
3  flutter_localizations:
4    sdk: flutter
5  intl: any
6
7flutter:
8  generate: true

Configuration:

YAMLCopy
1# l10n.yaml
2arb-dir: lib/l10n
3template-arb-file: app_en.arb
4output-localization-file: app_localizations.dart

ARB Files:

JSONCopy
1// lib/l10n/app_en.arb
2{
3  "@@locale": "en",
4  "greeting": "Hello, {name}!",
5  "@greeting": {
6    "placeholders": {
7      "name": { "type": "String" }
8    }
9  },
10  "itemCount": "{count, plural, =0{No items} one{1 item} other{{count} items}}",
11  "@itemCount": {
12    "placeholders": {
13      "count": { "type": "int" }
14    }
15  }
16}

Usage:

DARTCopy
1import 'package:flutter_gen/gen_l10n/app_localizations.dart';
2
3class MyWidget extends StatelessWidget {
4  @override
5  Widget build(BuildContext context) {
6    final l10n = AppLocalizations.of(context)!;
7
8    return Text(l10n.greeting('Alice'));
9  }
10}

Flutter's code generation provides full type safety and compile-time validation.

Testing Localized Applications

Unit Testing

Test translation logic in isolation:

TypeScriptCopy
1// React with react-i18next
2import { renderHook } from '@testing-library/react';
3import { I18nextProvider } from 'react-i18next';
4import i18n from './test-i18n';  // Test i18n instance
5
6test('translates greeting correctly', () => {
7  const { result } = renderHook(
8    () => useTranslation(),
9    { wrapper: ({ children }) => <I18nextProvider i18n={i18n}>{children}</I18nextProvider> }
10  );
11
12  expect(result.current.t('greeting', { name: 'Alice' })).toBe('Hello, Alice!');
13});

Component Testing

Test components in different locales:

TypeScriptCopy
1import { render, screen } from '@testing-library/react';
2import { I18nextProvider } from 'react-i18next';
3import i18n from 'i18next';
4
5const renderWithLocale = (component, locale = 'en') => {
6  i18n.changeLanguage(locale);
7  return render(
8    <I18nextProvider i18n={i18n}>
9      {component}
10    </I18nextProvider>
11  );
12};
13
14test('displays title in English', () => {
15  renderWithLocale(<HomePage />, 'en');
16  expect(screen.getByText('Welcome')).toBeInTheDocument();
17});
18
19test('displays title in Spanish', () => {
20  renderWithLocale(<HomePage />, 'es');
21  expect(screen.getByText('Bienvenido')).toBeInTheDocument();
22});

Visual Regression Testing

Catch layout issues with automated screenshots:

TypeScriptCopy
1// Using Playwright
2import { test, expect } from '@playwright/test';
3
4const locales = ['en', 'es', 'de', 'ja', 'ar'];
5
6for (const locale of locales) {
7  test(`homepage renders correctly in ${locale}`, async ({ page }) => {
8    await page.goto(`http://localhost:3000/${locale}`);
9    await expect(page).toHaveScreenshot(`homepage-${locale}.png`);
10  });
11}

Compare screenshots across test runs to detect:

• Text overflow/truncation
• Layout breaks
• RTL issues
• Font rendering problems

Placeholder Validation

Ensure translation variables match source:

TypeScriptCopy
1import en from './locales/en.json';
2import es from './locales/es.json';
3
4function extractPlaceholders(text: string): Set<string> {
5  const regex = /{([^}]+)}/g;
6  const placeholders = new Set<string>();
7  let match;
8  while ((match = regex.exec(text)) !== null) {
9    placeholders.add(match[1]);
10  }
11  return placeholders;
12}
13
14test('Spanish translations have same placeholders as English', () => {
15  for (const key in en) {
16    const enPlaceholders = extractPlaceholders(en[key]);
17    const esPlaceholders = extractPlaceholders(es[key] || '');
18
19    expect(esPlaceholders).toEqual(enPlaceholders);
20  }
21});

CI/CD Integration

Automate translation workflows to maintain velocity.

Continuous Translation Workflow

1. Developer adds new feature with translation keys

TypeScriptCopy
// New feature code
<Button>{t('features.newFeature.submitButton')}</Button>

2. Pre-commit hook validates i18n

JSONCopy
1// package.json
2{
3  "husky": {
4    "hooks": {
5      "pre-commit": "npm run i18n:validate"
6    }
7  }
8}

3. CI pipeline detects missing translations

YAMLCopy
1# .github/workflows/i18n.yml
2name: i18n
3on: [pull_request]
4jobs:
5  validate:
6    runs-on: ubuntu-latest
7    steps:
8      - uses: actions/checkout@v4
9      - run: npm install
10      - run: npm run i18n:check-missing
11      - name: Comment missing keys
12        uses: actions/github-script@v7
13        with:
14          script: |
15            const missing = require('./i18n-missing.json');
16            const comment = `Missing translations: ${JSON.stringify(missing, null, 2)}`;
17            github.rest.issues.createComment({ ...context.repo, issue_number: context.issue.number, body: comment });

4. TMS auto-generates translation tasks

IntlPull and similar TMS platforms can:

• Auto-detect new keys via API or Git integration
• Create translation tasks for configured languages
• Notify translators via email/Slack
• Track translation progress

5. Translations merged back automatically

YAMLCopy
1# .github/workflows/sync-translations.yml
2name: Sync Translations
3on:
4  schedule:
5    - cron: '0 */4 * * *'  # Every 4 hours
6jobs:
7  sync:
8    runs-on: ubuntu-latest
9    steps:
10      - uses: actions/checkout@v4
11      - name: Pull latest translations
12        run: npx intlpull pull
13      - name: Create PR if changes
14        uses: peter-evans/create-pull-request@v5
15        with:
16          commit-message: 'chore: update translations'
17          title: 'Update translations from IntlPull'

Automated Deployment

Option 1: Bundle with Code

Translations deployed with application:

• Simple, reliable
• Requires deployment for translation updates
• Suitable for infrequent changes

Option 2: CDN with Cache Busting

TypeScriptCopy
const version = process.env.TRANSLATION_VERSION || 'latest';
const translations = await fetch(`https://cdn.example.com/i18n/${locale}/${version}.json`);

Deploy translations independently:

• Faster translation updates
• Requires cache invalidation strategy
• Suitable for frequently updated content

Option 3: OTA with IntlPull

TypeScriptCopy
1import { IntlPullOTA } from '@intlpull/ota';
2
3const client = new IntlPullOTA({
4  apiKey: process.env.INTLPULL_API_KEY,
5  locale: userLocale
6});
7
8await client.fetchLatestTranslations();
9const t = client.getTranslation('key');

Translations update without deployment:

• Instant fixes for translation errors
• A/B test messaging variants
• Requires OTA infrastructure (IntlPull provides this)

Best Practices

1. Never Concatenate Strings

TypeScriptCopy
1// ❌ Bad: Doesn't work in many languages
2const message = t('welcome') + ' ' + userName + '!';
3
4// ✅ Good: Use ICU variables
5const message = t('welcome', { userName });
6// Translation: "Welcome, {userName}!"

Different languages have different word orders and grammar rules.

2. Avoid Splitting Sentences

TypeScriptCopy
1// ❌ Bad: Assumes English word order
2<p>
3  {t('you_have')} {count} {t('new_messages')}
4</p>
5
6// ✅ Good: Complete translatable unit
7<p>
8  {t('inbox_summary', { count })}
9</p>
10// Translation: "{count, plural, one {You have # new message} other {You have # new messages}}"

3. Provide Context to Translators

JSONCopy
1{
2  "button.save": {
3    "value": "Save",
4    "context": "Button label for saving user profile changes",
5    "maxLength": 20
6  }
7}

Context helps translators choose appropriate terminology and avoid errors.

4. Handle Pluralization Properly

English has two plural forms (one, other). Other languages have more:

• Polish: 3 forms (one, few, many)
• Arabic: 6 forms (zero, one, two, few, many, other)

Always use ICU plural format:

TypeScriptCopy
t('items', { count })  // ICU handles language-specific plural rules

5. Design for Text Expansion

Translated text is often longer than English:

• German: +30% average
• Spanish: +20% average
• French: +15% average

Design UI to accommodate:

• Flexible layouts (avoid fixed widths)
• Truncation with tooltips for overflow
• Test with longest expected translations

6. Separate Formatting Logic

TypeScriptCopy
1// ❌ Bad: Mixes formatting and translation
2t('price', { value: `$${price.toFixed(2)}` })
3
4// ✅ Good: Let i18n handle formatting
5t('price', { value: price })  // With ICU: "{value, number, ::currency/USD}"

7. Use Translation Keys, Not English Strings

TypeScriptCopy
1// ❌ Bad: English as key (hard to change, unclear context)
2t('Save')
3
4// ✅ Good: Semantic key
5t('button.save')

Common Pitfalls

Hardcoded Strings

Problem: Strings embedded in code that aren't translatable.

Detection:

TerminalCopy
1# ESLint rule for React
2{
3  "rules": {
4    "react/jsx-no-literals": ["error", {
5      "ignoreProps": true
6    }]
7  }
8}

Solution: Extract all user-facing strings to translation files.

Date/Number Formatting Issues

Problem: Using incorrect locale for formatting.

TypeScriptCopy
1// ❌ Bad: Hardcoded US format
2const formatted = `${month}/${day}/${year}`;
3
4// ✅ Good: Locale-aware formatting
5const formatted = new Intl.DateTimeFormat(locale).format(date);

Missing RTL Support

Problem: UI breaks in RTL languages.

Solution:

• Use CSS logical properties
• Test with dir="rtl" early
• Mirror directional icons and layouts

Incomplete Translations

Problem: Missing translation keys cause fallback to source language mid-sentence.

Solution:

• Validate translation completeness in CI
• Use fallback language hierarchy (es-MX → es → en)
• Alert developers to missing keys in development

Tools and Resources

Translation Management Systems

• IntlPull: Developer-first TMS with Git sync, OTA, AI translation
• Lokalise: Popular with strong integrations
• Phrase: Enterprise-focused
• Crowdin: Community-oriented

Linting and Validation

• eslint-plugin-i18next: Detect missing translations, hardcoded strings
• i18n-ally: VS Code extension for inline translation editing
• Translation validation scripts: Custom CI checks for completeness

Testing Tools

• Playwright/Cypress: E2E testing across locales
• Percy/Chromatic: Visual regression testing
• i18next-parser: Extract translation keys from code

Learning Resources

• Unicode CLDR: Locale data standards
• ICU Message Format Guide: Official specification
• Framework documentation: next-intl, react-i18next, Vue I18n official docs

Frequently Asked Questions

When should I implement i18n in my application?

Implement i18n infrastructure during initial development, even if localization isn't immediate. Retrofitting i18n costs 3-5x more than building it from the start. At minimum, use an i18n framework and avoid hardcoded strings. Full localization can wait until product-market fit, but the technical foundation should exist from day one.

What's the difference between i18n and l10n?

Internationalization (i18n) is the technical process of designing software to support multiple locales without code changes—extracting strings, handling date/number formatting, RTL support. Localization (l10n) is adapting the internationalized product for specific markets—translating content, cultural adaptation, local compliance. i18n is engineering work done once; l10n is ongoing work for each new market.

Should I use framework-native i18n libraries or general-purpose ones?

Prefer framework-native solutions when available (next-intl for Next.js, Vue I18n for Vue, flutter_localizations for Flutter) as they integrate better with framework features (SSR, routing, build optimization). Use general-purpose libraries like i18next for React apps without framework-specific needs or when you need maximum flexibility across different platforms.

How do I handle pluralization in different languages?

Never implement plural logic manually. Use ICU MessageFormat, which handles language-specific plural rules automatically. English has two forms (one/other), but Arabic has six, Polish has three, and Japanese has one. ICU format: {count, plural, one {# item} other {# items}} works correctly in all languages when used with proper i18n libraries.

What's the best way to organize translation files?

For small apps (<5000 strings), use centralized files organized by namespace (common, dashboard, settings). For larger apps, use feature-colocated translations where each feature owns its i18n files. Hybrid approaches work well: shared strings centralized, feature-specific strings colocated. Choose based on team structure and workflow—translators prefer centralized, developers prefer colocated.

How do I test i18n implementations?

Three-layer approach: (1) Unit tests for translation logic and placeholder validation, (2) Component tests rendering in different locales, (3) Visual regression tests to catch layout issues. Automate placeholder validation to ensure all translations have correct variables. Test RTL languages explicitly. Use tools like Playwright for multi-locale E2E testing with screenshot comparison.

Should I bundle translations or load them dynamically?

Small apps: bundle all translations (simple, works offline). Large apps: lazy load by route/feature (smaller initial bundle). Production apps: hybrid approach with bundled fallback + CDN/OTA updates (reliability + agility). Consider OTA systems like IntlPull for mobile apps to update translations without app store reviews. Choose based on bundle size constraints, update frequency, and offline requirements.