locale-format-validator

Overview

Locale-specific formatting is a common bug source:

• US user sees 5/4/2026 and reads "May 4." Spanish user sees the same string and reads "April 5."
• German user sees 1,234.56 and may interpret as 1.23456 (the comma is a thousands separator, the period a decimal in DE).
• Japanese user sees a price in dollars instead of yen.

This skill verifies the app uses the right format per locale.

When to use

• The product displays dates, numbers, currencies, or times.
• A bug report says "the date is in the wrong format."
• Pre-release: scheduled locale-format check.

How to use

1. Identify the formatting library the app uses (Step 1); prefer Intl APIs that delegate to CLDR.
2. Fix the expected date, number, and currency strings per target locale from CLDR (Steps 2-4, Step 8).
3. Author tests asserting the rendered date / number / currency per locale (Step 5).
4. Add timezone assertions so timestamps render in the user's timezone (Step 6).
5. Run the tests across the full locale matrix in CI (Step 7).
6. Trace any failure back to CLDR conventions, not hand-coded assumptions.

Step 1 - Identify the formatting library

The Intl APIs (browser-native) are recommended - they delegate to the underlying ICU library for canonical CLDR-based formatting.

Step 2 - Date format expectations per locale

US and DE date formats look superficially similar (differ only in separator) but are unambiguously interpreted only in their locale.

Step 3 - Number format expectations

The Indian grouping (lakh = 100,000 displayed as 1,00,000) is a common bug source for apps using only Western thousands grouping.

Step 4 - Currency expectations

Notes:

• Euro symbol position varies (€-DE vs DE-€ in some renderings).
• JPY has no decimals.
• Currency symbol may precede or follow per locale.

Step 5 - Author tests

import { test, expect } from '@playwright/test';

test('date format per locale', async ({ page }) => {
  // en-US
  await page.goto('/orders/123?lng=en-US');
  await expect(page.getByTestId('order-date')).toHaveText('5/4/2026');

  // de-DE
  await page.goto('/orders/123?lng=de-DE');
  await expect(page.getByTestId('order-date')).toHaveText('04.05.2026');

  // ja-JP
  await page.goto('/orders/123?lng=ja-JP');
  await expect(page.getByTestId('order-date')).toHaveText('2026/05/04');
});

test('currency format per locale', async ({ page }) => {
  await page.goto('/orders/123?lng=de-DE');
  await expect(page.getByTestId('order-total')).toHaveText('1.234,56 €');

  await page.goto('/orders/123?lng=ja-JP&currency=JPY');
  await expect(page.getByTestId('order-total')).toHaveText('¥1,235');   // no decimals
});

test('number format per locale', async ({ page }) => {
  await page.goto('/dashboard?lng=hi-IN&users=1234567');
  await expect(page.getByTestId('user-count')).toHaveText('12,34,567');   // Indian grouping
});

Step 6 - Time + timezone

A separate concern: timestamps must show in the user's timezone:

test('order time displays in user timezone', async ({ page }) => {
  await page.goto('/orders/123?lng=en-US&tz=America/New_York');
  await expect(page.getByTestId('order-time')).toContainText('EST');

  await page.goto('/orders/123?lng=ja-JP&tz=Asia/Tokyo');
  await expect(page.getByTestId('order-time')).toContainText('JST');
});

Step 7 - Locale matrix in CI

- name: Locale-format tests
  run: |
    for locale in en-US en-GB de-DE fr-FR ja-JP zh-CN ar-SA hi-IN; do
      LOCALE=$locale npx playwright test e2e/locale-formats/
    done

Or via Playwright projects:

// playwright.config.ts
projects: [
  { name: 'en-US', use: { locale: 'en-US' } },
  { name: 'de-DE', use: { locale: 'de-DE' } },
  // ...
],

Step 8 - CLDR as source of truth

The Unicode Common Locale Data Repository (CLDR) is the canonical source for locale data. Modern Intl libraries delegate to ICU which delegates to CLDR.

For verification, consult the CLDR data at cldr.unicode.org/. The format conventions in this skill come from CLDR; the actual expected strings should be derived from CLDR per locale, not hand-coded.

Worked example

A de-DE user reports the order total renders as $1,234.56 - US grouping with a leading dollar sign. The expected de-DE rendering (Step 4) is 1.234,56 €.

Author a Playwright test (Step 5): goto('/orders/123?lng=de-DE') and assert order-total reads 1.234,56 €; add a ja-JP case asserting ¥1,235 (no decimals) and a hi-IN case asserting 12,34,567 (Indian lakh grouping). Run the matrix in CI (Step 7). The de-DE case fails because the app hand-coded a universal 1,234.56 grouping. Replacing the format call with Intl.NumberFormat (Step 1) makes all three locales pass.

Anti-patterns

Limitations

• Bicultural users. A Hindi user with English UI prefers Indian grouping; user-preference UI overrides locale auto-detection.
• CLDR updates. New CLDR releases sometimes change formatting; pin a CLDR version for stable test expectations.
• Server-vs-client formatting. Inconsistent if both render formats with different libraries; pick one.
• Intl API gaps. Some niche locales / formats are underrepresented in browser Intl; libraries like FormatJS fill some gaps.

References

• W3C i18n at w3.org/International/.
• CLDR at cldr.unicode.org/.
• i18n-string-coverage, pseudo-localization-runner, rtl-rendering-tester - sibling skills for the broader l10n test surface.