Internationalization and Placeholder Text (Multi-Language UX)

Designing for a global audience means designing for dozens of languages, each with its own character sets, text lengths, and reading directions. When your product will be translated, placeholder text takes on a whole new level of importance—it must help you anticipate and solve layout problems before they reach real users.

This guide covers how to use placeholder text strategically for internationalization (i18n) testing and multi-language UX design.

Why i18n changes everything about placeholder text

Standard Lorem Ipsum sizes like English. When we measured it, 100 words of it rendered within 3–4% of the width of 100 words of English prose. That's what makes it useful for English layouts, and exactly what makes it misleading for translated ones. It tells you nothing about German, Arabic, Japanese or Thai.

Expansion depends on how long the string is

The figure you'll hear most often is "German is about 30% longer than English." For paragraphs that's a fair rule of thumb. For interface text it badly understates the problem, because short strings expand far more than long ones.

The W3C's internationalization article Text size in translation reproduces IBM's guidance on how much extra space translated text needs, by the length of the English source:

A 6-character button label can need two to three times the space. A paragraph needs about a third more. Buttons, tabs, table headers and menu items are nearly all in the top rows of that table, which is why they're where translated layouts break.

The same article gives the example that makes German notorious: "Input processing features" becomes "Eingabeverarbeitungsfunktionen", one 30-character word with no break opportunity. Finnish and Dutch build compounds the same way. The problem isn't only length; it's a long unbreakable string.

A button that reads "Submit" in English becomes "Absenden" in German, "Soumettre" in French and "送信する" in Japanese. Each has a different width, height and rendering behaviour.

If you only test with English-length Lorem Ipsum, you're designing for one language while shipping to many.

Text expansion: the silent layout breaker

Where expansion breaks layouts

1. Navigation menus: labels overflow or wrap unexpectedly
2. Buttons: text gets truncated, or buttons grow too wide
3. Table columns: headers expand beyond the column width
4. Cards: descriptions push content below the fold
5. Tooltips: text overflows the container
6. Form labels: labels misalign with their inputs

Simulating it

Strategy 1: size the test string by the source length

English:    "Save changes"          12 chars
German:     "Änderungen speichern"  20 chars  (+67%)
Test with:  a 24-character string   (200%, per the table above)

A single percentage for everything will be too generous for paragraphs and too stingy for buttons. Use the table.

Strategy 2: pseudo-localization

Pseudo-localization rewrites your real English strings with accented characters and padding, wrapped in brackets:

Original:   "Welcome to our platform"
Pseudo:     "[Wélçömé tö öür plátförm~~~~~~~~~~~~~~~~~]"

This keeps the strings readable for testers, pads them to simulate expansion, exercises accented glyphs (and shows whether they clip against the line above), and makes any string that skipped translation obvious, because it has no brackets.

Strategy 3: real-language placeholder

The generator produces placeholder prose in English, Spanish, French and German as well as Latin. That's useful for checking accented glyphs, hyphenation and the general texture of each language. It's not a way to measure expansion: our language modes are independent prose, not translations of each other, so comparing their lengths tells you nothing about how long a translated string will be. For expansion, use Strategy 1 or 2.

Expansion testing checklist

• Every string under 10 characters tested at 3× its English length
• Strings of 11–30 characters tested at about 2×
• Paragraphs tested at about 1.3×
• At least one long, unbreakable compound word in headings, buttons and table headers
• Table headers tested with the longest real translation you have
• Toasts and notifications tested with expanded text at the smallest viewport

Right-to-Left (RTL) Layout Challenges

Supporting Arabic, Hebrew, Persian, or Urdu means your entire layout must mirror. Placeholder text plays a crucial role in RTL testing.

What Changes in RTL

RTL Placeholder Text Strategies

Option 1: Use actual Arabic/Hebrew placeholder text

Arabic Lorem Ipsum:
هذا النص هو مثال لنص يمكن أن يستبدل في نفس المساحة. 
لقد تم توليد هذا النص من مولد النص العربي.

Option 2: Use bidirectional test strings

Mix LTR and RTL characters to test bidirectional (BiDi) handling:

"Product name المنتج v2.0"
"User محمد added 3 items"

Option 3: Mirror your existing Lorem Ipsum

Take your standard placeholder and reverse the visual flow to test layout mirroring.

RTL Testing Checklist

• Full page layout mirrors correctly
• Text alignment flips to right
• Icons with directional meaning are mirrored
• Navigation flows right-to-left
• Form layouts mirror properly
• Scrollbars appear on correct side
• Breadcrumbs read right-to-left
• Number formatting remains LTR within RTL context

CJK (Chinese, Japanese, Korean) Considerations

CJK languages present unique challenges that Latin-based Lorem Ipsum can't simulate.

Character Width and Height

CJK characters are typically:

• Full-width - Each character occupies a square space
• No word spacing - Characters flow without spaces
• Line breaks anywhere - Can break between any two characters
• Taller line heights - Require more vertical space

Impact on Design

English:  "Welcome to our platform"
Chinese:  "欢迎使用我们的平台"
Japanese: "プラットフォームへようこそ"
Korean:   "플랫폼에 오신 것을 환영합니다"

Notice how:

• Chinese is significantly shorter in character count
• But each character is wider, affecting horizontal layouts differently
• Line height needs increase for readability

CJK Testing Strategies

1. Test with actual CJK text - Lorem Ipsum won't reveal CJK issues
2. Increase line height - Test with 1.6-1.8 for CJK content
3. Check font fallbacks - Ensure CJK fonts load correctly
4. Verify text wrapping - CJK doesn't wrap at word boundaries
5. Test vertical text - Some CJK contexts use vertical writing

Localization Testing with Placeholder Text

The Testing Matrix

For thorough i18n testing, use placeholder text across these dimensions:

Language-Specific Test Cases

German (Text Expansion)

English:  "Settings"
German:   "Einstellungen"
Test:     13 characters against 8 (+63%); leave room for labels of this length

Arabic (RTL + Expansion)

English:  "Search results"
Arabic:   "نتائج البحث"
Test:     Mirror layout + test with Arabic placeholder text

Japanese (Character Width)

English:  "Click here to learn more"
Japanese: "詳細はこちらをクリック"
Test:     Fewer characters but wider rendering

Thai (No Word Boundaries)

English:  "Welcome to our website"
Thai:     "ยินดีต้อนรับสู่เว็บไซต์ของเรา"
Test:     No spaces between words; line breaking is complex

Multi-language placeholder strategies

A pseudo-localization function you can drop into a dev build

This pads each string to the size the table above predicts for its length, swaps vowels and a few consonants for accented forms (keeping capitals as capitals), and wraps the result in brackets so untranslated strings stand out:

const ACCENTS = { a: "á", e: "é", i: "í", o: "ö", u: "ü", c: "ç", n: "ñ", s: "š", y: "ý", z: "ž" };

// Target size after translation, by English length (IBM figures via the W3C).
// Uses the top of each range.
function expansionFactor(length) {
  if (length <= 10) return 3.0;
  if (length <= 20) return 2.0;
  if (length <= 30) return 1.8;
  if (length <= 50) return 1.6;
  if (length <= 70) return 1.7;
  return 1.3;
}

function pseudoLocalize(text) {
  let body = "";
  for (const ch of text) {
    const accented = ACCENTS[ch.toLowerCase()];
    body += !accented ? ch : ch === ch.toUpperCase() ? accented.toUpperCase() : accented;
  }
  const target = Math.ceil(text.length * expansionFactor(text.length));
  const padding = "~".repeat(Math.max(0, target - text.length - 2)); // 2 for the brackets
  return `[${body}${padding}]`;
}

pseudoLocalize("Save");                    // "[Šávé~~~~~~]"                     4 -> 12 chars
pseudoLocalize("Save changes");            // "[Šávé çháñgéš~~~~~~~~~~]"         12 -> 24
pseudoLocalize("Welcome to our platform"); // "[Wélçömé tö öür plátförm~~~~~~~~~~~~~~~~~]"  23 -> 42

Run it over your string catalogue in development builds only. Anything that renders without brackets was hard-coded and skipped translation; anything that clips or wraps badly will do the same in German or Finnish.

Content token variants

If your design system documents components with sample text, include an expanded variant alongside the real translations so every component is reviewed at its worst case:

{
  "button": {
    "submit": {
      "en": "Submit",
      "de": "Absenden",
      "fr": "Soumettre",
      "ja": "送信",
      "ar": "إرسال",
      "test-expanded": "Submit application form"
    }
  }
}

Common i18n Mistakes with Placeholder Text

1. English-Only Testing

Problem: Designs tested only with English Lorem Ipsum break in other languages. Solution: Always test with expanded text and at least one RTL language.

2. Fixed-Width Containers

Problem: Containers with fixed widths truncate translated text. Solution: Use flexible layouts, and test short strings at 2–3× their English length to find the constraints.

3. Concatenated Strings

Problem: Building sentences by joining translated fragments creates grammatical errors.

// ❌ Bad: Word order differs across languages
`${greeting} ${name}, ${welcomeMessage}`

// ✅ Good: Use full template strings per language
i18n.t('welcome_message', { name: userName })

4. Hardcoded Formatting

Problem: Date, number, and currency formats differ by locale.

US:     $1,234.56  |  01/15/2026  |  1,000 items
German: 1.234,56 € |  15.01.2026  |  1.000 Stück
Japan:  ¥1,234     |  2026/01/15  |  1,000個

5. Ignoring Vertical Space

Problem: Translated text may require more vertical space. Solution: Test with line heights of 1.6-1.8 for CJK languages.

Practical Workflow for i18n Placeholder Testing

Phase 1: Design (Use Expanded Placeholder Text)

1. Generate structure with the landing page or UI mockup presets, and write real English for labels
2. Size test strings by the expansion table: about 3× for labels under 10 characters, 2× up to 30, 1.3× for paragraphs
3. Verify layouts accommodate longer content
4. Document max character limits per component

Phase 2: Development (Implement Flexible Layouts)

1. Use CSS that handles variable text lengths
2. Implement text truncation with proper fallbacks
3. Add pseudo-localization to development builds
4. Test with RTL stylesheets

Phase 3: QA (Test with Real Translations)

1. Replace placeholder with actual translations
2. Verify every language passes visual QA
3. Test bidirectional content mixing
4. Validate character encoding across browsers

Phase 4: Ongoing (Monitor Post-Launch)

1. Capture screenshot diffs for each locale
2. Monitor for truncation issues in production
3. Update placeholder tokens as new languages are added

Conclusion

Internationalization makes placeholder text more important, not less. Standard Lorem Ipsum hides the layout problems that surface when real translations arrive. By testing with expanded text, RTL layouts, and CJK characters during the design phase, you prevent expensive rework after launch.

Key takeaways:

• Test expansion by string length: short UI strings can need 2–3× the space; paragraphs about 1.3×
• Test RTL early - Layout mirroring requires structural changes
• CJK needs special attention - Different character widths and line heights
• Automate where possible - Pseudo-localization catches issues in development
• Don't test i18n with Latin: it sizes like English, which is exactly the problem

Your placeholder text strategy should reflect your product's global ambitions. Design for the world, and your layouts will thank you.