Localization Testing for Multilingual JSON Formatters

Localization testing for multilingual JSON formatters means more than checking whether translated strings exist. A useful test plan verifies that your formatter renders locale-sensitive dates, numbers, lists, plurals, fallback content, and mixed-direction text correctly when real JSON payloads hit the UI.

For most teams, the highest-value improvements are simple: pin the test time zone, cover more than one English locale, exercise plural edge cases, and review at least one right-to-left language. Those four steps catch a large share of production localization bugs.

What Usually Breaks First

• Tests pass locally but fail in CI because the formatter silently used the host machine's default time zone.
• A translation key exists, but the rendered sentence is still wrong because the app concatenates fragments instead of formatting a full localized message.
• Arabic or Hebrew pages show punctuation, SKU codes, or email addresses in the wrong visual order when embedded values are not direction-isolated.
• The JSON contains a value for 1 item and 5 items, but values such as 0, 2, 11, 21, or 1.0 still render the wrong plural form.
• A fallback locale hides missing translations in staging, then broken raw keys appear in production for one region.

Build a Small but High-Value Locale Matrix

You do not need dozens of locales to find real defects. Start with a compact matrix that forces your JSON formatter through different scripts, number systems, date conventions, and plural rules.

Adjust the matrix to your audience, but keep at least one same-language comparison such as en-US vs en-GB and one RTL locale. That is where hidden assumptions show up fastest.

JSON Cases Worth Testing Every Time

Use realistic JSON, not toy strings. A formatter that survives actual product data is far more trustworthy than one that passes a single happy-path snapshot.

{
  "locale": "ar-EG",
  "updatedAt": "2026-03-10T18:45:00Z",
  "cart": {
    "count": 2,
    "subtotal": 12345.67,
    "currency": "EGP",
    "items": ["USB-C Hub", "4K Cable", "SSD Enclosure"]
  },
  "messages": {
    "items": "{count, plural, one {# item} other {# items}}",
    "eta": "{value, number} {value, plural, one {day} other {days}} left"
  },
  "agentNote": "Order #A-1049 ships to Berlin"
}

• Dates and times: confirm the formatter respects locale and an explicit time zone, then compare single values and date ranges.
• Numbers and currencies: verify decimals, group separators, currency symbol placement, negative values, and rounding.
• Lists: do not join arrays with commas by hand. Test conjunctions and shorter UI spaces.
• Pluralized messages: include 0, 1, 2, 5, 11, 21, and at least one fractional value if your product displays measurements or money.
• Fallback behavior: assert the result when a key is missing, a locale is unsupported, or one field is null.
• Embedded mixed-direction text: test order numbers, email addresses, URLs, and Latin product names inside Arabic or Hebrew UI.

Use Current Intl APIs as Test Targets

Modern JavaScript internationalization is broader than just toLocaleString(). If your JSON formatter exposes localized output, these APIs should either power the result directly or shape your expected test assertions.

• Intl.DateTimeFormat: Test locale, calendar, numbering system, and a fixed time zone. Use formatToParts or formatRange when your formatter composes UI from pieces or renders date ranges.
• Intl.NumberFormat: Cover decimal, percent, unit, and currency output. Verify grouping, sign display, narrow symbols, and range formatting where totals or comparisons appear.
• Intl.ListFormat: Use it for locale-correct conjunctions such as 'A, B, and C' instead of joining arrays manually.
• Intl.RelativeTimeFormat: Exercise labels such as 'yesterday', 'in 3 days', or abbreviated forms that many dashboards and feeds rely on.
• Intl.PluralRules: Test count-based messages with locale-specific categories, and include range cases when the UI renders values like '1-2 items'.

A practical rule for stable tests: pass the locale and time zone explicitly into the formatter under test. If the time zone is omitted, date output can vary by environment even when the same JSON input is used.

Plural and Message Formatting Edge Cases

Many teams still test pluralization as if every language were English. That misses a large class of defects. Locale data used by modern formatters supports categories such as zero, one, two, few, many, and other, but not every locale uses the same set or the same rules.

• Test teens and twenties, not just 1 and 2.
• Include fractional values if your app formats prices, sizes, or durations.
• Prefer full localized messages over concatenating translated fragments around variables.
• Review range wording if the UI renders values like 1-2 days or 3-5 results.

RTL and Mixed-Direction Testing

Right-to-left testing is not only about flipping alignment. The harder bugs appear when localized UI contains embedded left-to-right strings from JSON, such as SKU codes, product names, URLs, or addresses.

<p dir="rtl">
  <bdi>Order #A-1049 ships to Berlin</bdi>
</p>

When the direction of injected content is unknown, isolate it instead of assuming the surrounding paragraph direction is enough. In practice, test both Arabic and Hebrew pages with punctuation-heavy strings because visual order mistakes are easier to miss in screenshots than simple translation errors.

Automation, Pseudolocalization, and Human Review

• Unit and integration tests: assert deterministic formatter output from fixed JSON fixtures.
• Pseudolocalization: expand strings, add markers, and run visual regression to catch overflow before real translations arrive.
• RTL screenshots: capture at least one end-to-end flow with real data, not placeholder text.
• Manual linguistic review: native-speaker review remains essential for tone, context, and cultural fit.

Troubleshooting Checklist

• If output differs by machine, inspect locale, time zone, and ICU data before blaming the JSON payload.
• If only one locale fails, compare the raw message pattern first, then the variable values supplied.
• If punctuation looks wrong in RTL, test with direction isolation instead of CSS-only fixes.
• If list output sounds awkward, replace manual joining logic with locale-aware list formatting and retest.
• If keys leak into the UI, make fallback behavior explicit and cover it with assertions.

Release Checklist

• Pin locale and time zone in automated tests so snapshots and assertions are deterministic.
• Run pseudolocalization and at least one RTL locale before release.
• Check dates, numbers, currencies, list output, and pluralized messages from realistic JSON payloads.
• Verify missing-key and fallback behavior intentionally instead of treating it as an edge case.
• Include manual review by a fluent speaker for high-traffic flows and error states.

Bottom Line

A strong multilingual JSON formatter test plan is small, deliberate, and realistic. Cover representative locales, pin environment-sensitive values, use current internationalization APIs as your baseline, and treat plural rules plus mixed-direction text as first-class test targets. That produces a page and a product that actually work for global users, not just for the developer who wrote the formatter.