What Are I18n and L10n?
Internationalization (I18n) is the engineering process of designing and building software so it can be adapted for different languages and regions without code changes. The “18” refers to the 18 letters between the “I” and “n” in “internationalization.”
Localization (L10n) is the process of adapting an internationalized application for a specific locale — translating text, adjusting date/number formats, handling cultural conventions, and meeting local regulations.
Think of I18n as building a car with a swappable dashboard (steering wheel can go left or right, instruments can display km or miles). L10n is configuring that car for a specific country (right-hand drive for UK, km/h for France).
I18n vs L10n Testing
| Aspect | I18n Testing | L10n Testing |
|---|---|---|
| Focus | Does the code support multiple locales? | Is the specific locale adaptation correct? |
| When | During development | After translation |
| Tests | String externalization, encoding, format handling | Translation quality, cultural appropriateness |
| Who | Developers and QA | Translators, native speakers, QA |
| Tools | Pseudo-localization, lint rules | Translation management systems, native reviewers |
What to Test: I18n Issues
String Externalization
All user-facing text should be in resource files, not hardcoded in source code.
How to test:
- Use pseudo-localization to reveal hardcoded strings (they will not be transformed)
- Search source code for hardcoded user-visible strings
- Check that error messages, tooltips, button labels, and email templates are externalized
- Verify string concatenation is not used for sentences (word order varies by language)
Bad: "Welcome, " + userName + "! You have " + count + " messages."
Good: i18n("welcome_message", {name: userName, count: count})
Resource: "welcome_message": "Welcome, {name}! You have {count} messages."
Character Encoding (UTF-8)
All text processing must correctly handle Unicode characters.
How to test:
- Enter characters from various scripts: Chinese (中文), Arabic (العربية), Japanese (日本語), Korean (한국어), Hindi (हिन्दी)
- Test emoji: 👋🌍🎉
- Enter special characters: ñ, ü, ö, å, ß, ç, ø
- Submit forms with these characters and verify they are stored and displayed correctly
- Check database columns use UTF-8 encoding
- Test search functionality with non-Latin characters
- Verify PDF generation handles Unicode correctly
Date, Time, and Number Formats
Different locales use different formats:
| Format | US | Germany | Japan | Arabia |
|---|---|---|---|---|
| Date | 03/19/2026 | 19.03.2026 | 2026/03/19 | ١٩/٠٣/٢٠٢٦ |
| Time | 7:30 PM | 19:30 | 19:30 | ٧:٣٠ م |
| Number | 1,234.56 | 1.234,56 | 1,234.56 | ١٬٢٣٤٫٥٦ |
| Currency | $1,234.56 | 1.234,56 € | ¥1,234 | ١٬٢٣٤٫٥٦ ر.س |
How to test:
- Change the locale/language setting and verify all dates, times, numbers, and currencies update
- Verify time zone handling (user in Tokyo sees their local time, not server time)
- Test calendar components with different first-day-of-week (Sunday in US, Monday in Europe, Saturday in Middle East)
Text Expansion and Contraction
Translated text is often longer or shorter than the original English:
| Language | Average expansion from English |
|---|---|
| German | +30% |
| French | +20% |
| Spanish | +20% |
| Portuguese | +25% |
| Finnish | +30-40% |
| Chinese | -50% (but may need more vertical space) |
| Japanese | -30% |
| Korean | -10% |
| Arabic | +25% |
How to test:
- Verify UI elements handle longer text without breaking layout (buttons, menus, tables)
- Check that text is not truncated without ellipsis or tooltip
- Test with pseudo-localization that expands text by 30-40%
- Verify fixed-width elements accommodate variable text lengths
Right-to-Left (RTL) Languages
Arabic, Hebrew, Farsi, and Urdu are read right-to-left. This affects the entire UI layout.
What changes in RTL:
- Text alignment flips (right-aligned instead of left)
- UI layout mirrors (sidebar moves to the right, back arrows point right)
- Progress bars fill from right to left
- Bidirectional text (RTL text with embedded LTR numbers or English terms)
How to test:
- Switch to an RTL language (Arabic or Hebrew)
- Verify the entire layout mirrors correctly
- Check that numbers and embedded English words display correctly within RTL text
- Test navigation, breadcrumbs, and pagination direction
- Verify icons that imply direction are mirrored (arrows, back/forward)
Currency
- Display the correct currency symbol and format per locale
- Handle currency conversion if applicable
- Position of currency symbol varies (€10 in France, 10€ in Germany)
- Some currencies have no decimal places (JPY, KRW)
Cultural Sensitivity
- Colors have different meanings (red = luck in China, danger in Western cultures)
- Images and icons should be culturally appropriate
- Names and addresses have different formats per country
- Not all cultures use first name / last name format
Pseudo-Localization
Pseudo-localization is a technique that transforms English text into an accented version that is still readable but simulates the effects of translation.
Original: “Save Changes” Pseudo-localized: “[Šàvé Çĥàñĝéš!!!!!!]”
The transformation adds:
- Accented characters: Reveals encoding issues (ñ, ü, ö)
- Text expansion (~40%): Reveals truncation and layout issues
- Brackets: Reveals concatenated strings (brackets should surround complete phrases)
- Exclamation marks: Makes expanded text visually obvious
Benefits:
- No need for translators — developers can test I18n immediately
- Readable by English speakers
- Catches 80% of I18n issues before any translation work begins
- Can be automated in CI/CD
Tools for L10n/I18n Testing
| Tool | Purpose |
|---|---|
| Pseudo-localization libraries | Generate pseudo-localized strings (pseudo-localization npm packages) |
| i18n lint rules | Detect hardcoded strings in code |
| Crowdin / Transifex / Lokalise | Translation management platforms |
| BrowserStack | Test in different locale environments |
| Unicode CLDR | Reference data for locale formats |
Exercise: L10n Test Checklist for a Multi-Language Web App
Create a comprehensive L10n testing checklist for a web application that needs to support English, Spanish, German, Arabic, and Japanese.
Application Context
A B2C e-commerce platform with: product listings, shopping cart, checkout with payment, user profiles, email notifications, and customer support chat.
Task
Create a checklist covering all L10n/I18n dimensions with specific test cases for each supported language.
Hint: Think About Every User Touchpoint
Consider: UI text, forms, dates/times, currencies, emails, PDFs, search, sorting, error messages, notifications, and user-generated content. Arabic requires special attention for RTL layout.
Solution: Complete L10n Test Checklist
1. String Externalization
- Run pseudo-localization — verify all UI text is transformed (no hardcoded strings remain)
- Check email templates in all 5 languages
- Verify error messages are translated
- Check PDF invoices generate in the customer’s locale
- Verify push/SMS notifications are localized
2. Character Encoding
- Create user profile with German name (Müller, Größe)
- Create product review in Japanese (日本語のレビュー)
- Search for products with Arabic characters
- Verify database stores and retrieves all characters correctly
- Test CSV export with multi-language content
3. Date/Time/Number Formats
- EN: March 19, 2026 / $1,234.56
- ES: 19 de marzo de 2026 / $1.234,56
- DE: 19. März 2026 / 1.234,56 €
- AR: ١٩ مارس ٢٠٢٦ / ١٬٢٣٤٫٥٦ ر.س
- JA: 2026年3月19日 / ¥1,234
- Verify time zones show user’s local time
- Test calendar first day of week per locale
4. Text Expansion
- Navigation menu items in German (30% longer) — no overflow
- Button labels in Spanish — no truncation
- Table headers in all languages — columns adapt
- Mobile layout tested with expanded German text
- Tooltip text in Finnish (40% longer) — fully visible
5. RTL Layout (Arabic)
- Entire layout mirrors correctly
- Shopping cart flows right to left
- Checkout steps progress right to left
- Product images remain correctly positioned
- Bidirectional text (Arabic price with numerals) displays correctly
- Navigation arrows and icons are mirrored
- Form labels align correctly (right side)
6. Currency
- USD: $1,234.56
- EUR: 1.234,56 €
- JPY: ¥1,234 (no decimals)
- SAR: ١٬٢٣٤٫٥٦ ر.س
- Currency symbol position correct per locale
- Price sorting works correctly across currencies
7. Cultural Sensitivity
- Product images appropriate for all target markets
- No culturally offensive color combinations
- Address form adapts per country (zip vs postal code, state vs prefecture)
- Name fields handle single-name cultures (Indonesia)
- Phone number format supports international formats (+81, +49, +966)
8. Sorting and Collation
- Product sorting alphabetically correct in German (ä after a, not after z)
- Japanese sorting uses correct collation (kana order)
- Arabic search finds results with and without diacritics
- Spanish sorting handles ñ correctly (between n and o)
Total test cases: 45+ across 8 dimensions. Priority: String externalization and RTL layout first (highest bug density), then formats and encoding.
Pro Tips
- Pseudo-Localize in CI/CD: Integrate pseudo-localization into your build pipeline. Run your E2E tests with pseudo-localized strings to catch layout issues automatically.
- Test with Native Speakers: Automated tools cannot catch awkward translations, cultural insensitivity, or context-dependent meaning. Have native speakers review translations in context.
- Separate I18n from L10n Testing: Test I18n first (does the code support localization?) before testing L10n (is the specific localization correct?). I18n issues are code bugs; L10n issues are content bugs.
- Use ICU MessageFormat: Instead of string concatenation, use ICU MessageFormat for complex strings with plurals, gender, and variable insertion. It handles the vast differences in grammar between languages.
- Do Not Forget User-Generated Content: Users will enter text in any language. Verify that search, sorting, filtering, and display work correctly with mixed-language content.