Cover the longest language and right-to-left languages

What it is

A risk-based locale and script test matrix validates a product with real combinations of language, script, font, input, and layout direction that trigger different faults. “The longest language” is not a permanent language assignment; it is the geometric worst case for a particular string, translation, font, and container. RTL is likewise more than mirroring a whole page. Useful coverage includes expansion and contraction, right-to-left and mixed-direction runs, CJK text, complex shaping scripts, and every language the product actually supports.

Why it happens

Different dimensions trigger different failures. Long labels compete with adjacent controls; tall glyphs and combining marks stress line boxes; CJK text changes line-break opportunities and density; joining or reordering scripts depend on shaping; RTL surrounding numbers, code, and URLs creates bidirectional boundaries. No locale maximizes every risk, and one language does not produce the longest translation for every message. Test selections therefore come from the string and component inventory, supported locales, font stack, input methods, and critical journeys—not from naming one “hardest language” and touring the happy path once.

Studying it

Build a fault type × language/script feature × component × state × device coverage table. Use historical and seeded defects to estimate the incremental yield of each combination. Strata should cover short-label expansion, long copy on narrow screens, RTL and mixed direction, scripts with different break opportunities, complex shaping and combining marks, font fallback, and input-method editing. Hold task, meaning, and device constant when comparing locales so translation quality or content supply is not mistaken for a script effect. Pairwise or risk sampling should disclose which higher-order interactions remain untested.

Where it stops holding

A language ranked long in a corpus or average cannot guarantee the worst button, error, or legal paragraph; expansion changes with translator, terminology, and context. Script families are heterogeneous, so one RTL, CJK, or complex-script locale cannot represent every language in that category. Synthetic fonts, machine translation, and simulated input help early stress testing but do not replace production fonts, native content, real keyboards and IMEs, or assistive technology. This matrix tests engineering adaptation; it does not determine linguistic correctness or audience acceptance.

Applying it

• Build a risk registry from actual support. Record direction, script, shaping, breaking, fonts, IMEs, numeric mixing, and expected string geometry per locale, then select the smallest set that covers distinct risks across critical components instead of fixing one global “longest language.”
• Keep measured production translations or versioned length distributions for high-risk strings. Exercise worst cases in buttons, labels, tables, navigation, dialogs, and errors; use pseudo-expansion only to supplement gaps in real samples.
• Test whole-layout RTL separately from mixed bidirectional content; CJK breaking and fonts separately from complex-script shaping, marks, and line height; and IME composition, deletion, and caret motion on their own. Include narrow screens, zoom, large text, and screen readers.
• Record locale, font, platform, content version, component state, and fault type in every regression. Gate critical journeys by risk tier and recompute the matrix whenever support, fonts, or components change rather than preserving a historical sample forever.

Related

• Same group: S4.03.1 Pseudolocalization exposes layout failures before translations exist · S4.03.3 Hard-coded text can only be found by running the product
• Adjacent: S1.01.4 Layouts must be tested against the longest language, not the average · S1.02.1 Mirroring applies to layout and direction, not every graphic · S1.03.4 Character count is not proportional to display width
• Search terms: locale test matrix · script coverage · bidirectional text testing