Internationalization Strategy
You are a software engineer specializing in i18n/l10n. Plan a comprehensive internationalization strategy.
Process
Step 1: Assess Scope
| Element |
Questions |
| Target locales |
Which languages/regions? (e.g., en-US, fr-FR, ja-JP, ar-SA) |
| Content types |
UI strings, emails, docs, legal, marketing? |
| Current state |
Any existing i18n? Hardcoded strings? |
| RTL support |
Arabic, Hebrew, or other RTL languages needed? |
| Timeline |
All locales at once or phased? |
Step 2: Design String Management
| Practice |
Details |
| Externalization |
All user-facing strings in resource files, never hardcoded |
| Key naming |
Hierarchical: page.section.element (e.g., settings.profile.title) |
| Pluralization |
Use ICU MessageFormat for plural rules (not if/else) |
| Interpolation |
"Hello, {name}" — never concatenate translated strings |
| Context |
Provide translator notes for ambiguous strings |
| No string reuse |
Same English word can translate differently in context |
String file format:
{
"settings.profile.title": "Profile Settings",
"orders.count": "{count, plural, one {# order} other {# orders}}",
"welcome.greeting": "Hello, {name}!"
}
Step 3: Handle Formatting
| Type |
Approach |
Example |
| Dates |
Intl.DateTimeFormat / locale-aware library |
03/15/2025 (US) vs 15/03/2025 (EU) |
| Numbers |
Intl.NumberFormat |
1,000.50 (US) vs 1.000,50 (DE) |
| Currency |
Currency code + locale formatting |
$1,000 vs 1.000 € |
| Time zones |
Store UTC, display in user's timezone |
— |
| Addresses |
Locale-specific format templates |
— |
| Phone numbers |
E.164 storage, locale-specific display |
— |
Step 4: Plan RTL Support
| Concern |
Solution |
| Text direction |
dir="rtl" attribute, CSS direction property |
| Layout mirroring |
Use CSS logical properties (margin-inline-start not margin-left) |
| Icons |
Mirror directional icons (arrows, progress bars) |
| Bidirectional text |
Handle mixed LTR/RTL content (usernames, code) |
| Testing |
Visual regression tests with RTL locale |
Step 5: Design Translation Workflow
| Phase |
Activity |
Tools |
| Extract |
Pull new/changed strings from code |
i18n CLI tool |
| Export |
Send strings to translators (XLIFF, JSON) |
Crowdin, Phrase, Lokalise |
| Translate |
Professional translation or community |
TMS platform |
| Review |
Native speaker QA |
In-context review tool |
| Import |
Merge translations back to codebase |
CI automation |
| Validate |
Check completeness, placeholders, length |
Automated checks |
Step 6: Test and Validate
| Test |
Method |
| Pseudo-localization |
Replace strings with accented versions (Ĥëľľö) to catch hardcoded text |
| String expansion |
Verify UI handles 30-40% longer text (German, Finnish) |
| RTL layout |
Visual check all pages in RTL locale |
| Placeholder validation |
All {variables} present in translations |
| Missing translations |
CI check for untranslated strings |
| Screenshot testing |
Visual regression per locale |
Output Format
## i18n Strategy: [Application]
### Locales: [Supported languages and regions]
### String Management: [Format, naming, tooling]
### Formatting: [Date, number, currency approach]
### RTL: [Support plan if applicable]
### Translation Workflow: [Process and tools]
### Testing: [Validation approach]
Quality Checklist
Edge Cases
- For user-generated content, don't translate — but handle display direction
- For legal/compliance text, use professional translators (never machine translation)
- If adding i18n to an existing app, extract strings incrementally by feature area
- For email templates, internationalize subject lines and body separately
- For SEO, implement hreflang tags and locale-specific URLs
1---2name: i18n-strategy3description: Plan internationalization — string extraction, locale management, RTL support, date/number formatting, pluralization, and translation workflows. TRIGGER when: user says /i18n-strategy, needs to internationalize an application, or asks about localization, translation, or multi-language support.4---56# Internationalization Strategy78You are a software engineer specializing in i18n/l10n. Plan a comprehensive internationalization strategy.910## Process1112### Step 1: Assess Scope1314| Element | Questions |15|---------|----------|16| Target locales | Which languages/regions? (e.g., en-US, fr-FR, ja-JP, ar-SA) |17| Content types | UI strings, emails, docs, legal, marketing? |18| Current state | Any existing i18n? Hardcoded strings? |19| RTL support | Arabic, Hebrew, or other RTL languages needed? |20| Timeline | All locales at once or phased? |2122### Step 2: Design String Management2324| Practice | Details |25|----------|---------|26| Externalization | All user-facing strings in resource files, never hardcoded |27| Key naming | Hierarchical: `page.section.element` (e.g., `settings.profile.title`) |28| Pluralization | Use ICU MessageFormat for plural rules (not if/else) |29| Interpolation | `"Hello, {name}"` — never concatenate translated strings |30| Context | Provide translator notes for ambiguous strings |31| No string reuse | Same English word can translate differently in context |3233**String file format:**34```json35{36 "settings.profile.title": "Profile Settings",37 "orders.count": "{count, plural, one {# order} other {# orders}}",38 "welcome.greeting": "Hello, {name}!"39}40```4142### Step 3: Handle Formatting4344| Type | Approach | Example |45|------|---------|---------|46| Dates | `Intl.DateTimeFormat` / locale-aware library | 03/15/2025 (US) vs 15/03/2025 (EU) |47| Numbers | `Intl.NumberFormat` | 1,000.50 (US) vs 1.000,50 (DE) |48| Currency | Currency code + locale formatting | $1,000 vs 1.000 € |49| Time zones | Store UTC, display in user's timezone | — |50| Addresses | Locale-specific format templates | — |51| Phone numbers | E.164 storage, locale-specific display | — |5253### Step 4: Plan RTL Support5455| Concern | Solution |56|---------|---------|57| Text direction | `dir="rtl"` attribute, CSS `direction` property |58| Layout mirroring | Use CSS logical properties (`margin-inline-start` not `margin-left`) |59| Icons | Mirror directional icons (arrows, progress bars) |60| Bidirectional text | Handle mixed LTR/RTL content (usernames, code) |61| Testing | Visual regression tests with RTL locale |6263### Step 5: Design Translation Workflow6465| Phase | Activity | Tools |66|-------|----------|-------|67| Extract | Pull new/changed strings from code | i18n CLI tool |68| Export | Send strings to translators (XLIFF, JSON) | Crowdin, Phrase, Lokalise |69| Translate | Professional translation or community | TMS platform |70| Review | Native speaker QA | In-context review tool |71| Import | Merge translations back to codebase | CI automation |72| Validate | Check completeness, placeholders, length | Automated checks |7374### Step 6: Test and Validate7576| Test | Method |77|------|--------|78| Pseudo-localization | Replace strings with accented versions (Ĥëľľö) to catch hardcoded text |79| String expansion | Verify UI handles 30-40% longer text (German, Finnish) |80| RTL layout | Visual check all pages in RTL locale |81| Placeholder validation | All `{variables}` present in translations |82| Missing translations | CI check for untranslated strings |83| Screenshot testing | Visual regression per locale |8485## Output Format8687```markdown88## i18n Strategy: [Application]8990### Locales: [Supported languages and regions]91### String Management: [Format, naming, tooling]92### Formatting: [Date, number, currency approach]93### RTL: [Support plan if applicable]94### Translation Workflow: [Process and tools]95### Testing: [Validation approach]96```9798## Quality Checklist99100- [ ] All user-facing strings externalized101- [ ] Pluralization uses ICU MessageFormat102- [ ] Dates, numbers, and currency use locale-aware formatting103- [ ] RTL support implemented (if applicable)104- [ ] Translation workflow is automated105- [ ] Pseudo-localization catches hardcoded strings106- [ ] String expansion tested for long translations107108## Edge Cases109110- For user-generated content, don't translate — but handle display direction111- For legal/compliance text, use professional translators (never machine translation)112- If adding i18n to an existing app, extract strings incrementally by feature area113- For email templates, internationalize subject lines and body separately114- For SEO, implement hreflang tags and locale-specific URLs
ashutoshsrivastava17