Skip to content

PATTERN Cited by 1 source

Shift-left internationalization validation

Intent

Detect and correct non-localizable source messages while developers still own the code, rather than asking translators or downstream QA to reconstruct intent after translation intake. The pattern turns internationalization quality into an authoring and review concern.

Shape

message authoring → editor diagnostics → pull-request checks → translation intake
                         │                     │
                         └── fix before translation ──────┘

Checks that matter

Atlassian's disclosed validation targets untranslated code text, fragment-based string composition, missing plural rules, and messages without sufficient context. The precise rule implementation is not public. The key design point is that checks run both in the editor and during code review, providing fast local guidance and a shared merge gate. (Source: sources/2026-08-06-atlassian-scaling-localization-at-atlassian-keeping-translation-at-the-pace-of-ai-era-development)

Why it scales

A malformed English source string creates repeat work in every target locale. Making the source localization-ready once prevents repeated translator investigation, improves AI draft quality, and reduces the cost of handling growing product-string volume.

For legacy defects, Atlassian pairs inventory visibility with AI bulk fixes submitted as developer-reviewed pull requests. That backfill is complementary to prevention: it reduces accumulated debt while the editor and review checks keep it from returning.

Risks

  • Overly noisy diagnostics encourage suppression rather than correction.
  • Checks must understand the project's message and placeholder syntax.
  • A syntactically valid message can still lack product meaning, so validation should require actionable descriptions rather than merely parseability.

Seen in

Last updated · 619 distilled / 1,953 read