Internationalization & Localization

Market Selection Matrix Core Method

Use when: deciding which international markets to enter first.

Score potential markets on:

• Market size — TAM for your product category in that market.
• Language overlap — English-speaking markets (UK, Australia, Canada) require no translation.
• Existing demand signals — organic traffic, inbound inquiries, existing users from that region.
• Competitive landscape — is the market open or dominated by local incumbents?
• Regulatory complexity — GDPR (EU), LGPD (Brazil), PIPL (China) add compliance requirements.
• Payment infrastructure — can users pay with local methods? Credit cards aren't universal.

Start with the market that has the highest score on demand signals and lowest on regulatory complexity. The UK, Canada, and Australia are common first targets for US-based products (English, similar business culture, familiar payment methods). EU markets offer large TAM but require GDPR compliance. Asian markets offer massive scale but often require deep localization and local partnerships.

i18n Readiness Audit Core Method

Use when: assessing whether your product's codebase can support internationalization.

Audit:

• String externalization — are all user-facing strings in a translation file, or hard-coded? Hard-coded strings are the #1 i18n blocker.
• Date/time formatting — do you handle different date formats (MM/DD/YYYY vs DD/MM/YYYY), time zones, and calendar systems?
• Number formatting — decimal separators (US: 1,000.50 vs EU: 1.000,50), currency symbols, and their placement (before vs after).
• RTL support — can your UI render right-to-left for Arabic and Hebrew?
• Text expansion — German text is typically 30% longer than English. Do your UI components handle this without breaking?
• Character encoding — does your system handle Unicode, including CJK characters, emoji, and accented characters?

Localization Priority Framework Framework

Use when: deciding how deeply to localize for a specific market.

Localization has levels: Level 1 — Language: translate all UI strings and help documentation. This is the minimum for non-English markets. Level 2 — Formats: local date/time, numbers, currencies, address formats, phone number formats. Level 3 — Content: localized marketing, onboarding flows, example data, and templates. Level 4 — Cultural adaptation: imagery, color meanings, metaphors, humor, and social norms adapted for local culture. Level 5 — Market-specific features: local payment methods (iDEAL in Netherlands, PIX in Brazil), local integrations (WeChat in China), and region-specific compliance features.

Level 1-2 is the minimum for serious market entry. Level 3 significantly improves conversion. Level 4-5 is necessary for markets with strong cultural differences or local competitors.

Cultural Adaptation Checklist Tool

Use when: localizing beyond language translation.

Check:

• Colors — red means danger in the West, good fortune in China. Green means "go" in the US, can mean Islam in some contexts.
• Icons — a mailbox icon looks different in every country. A thumbs-up is offensive in some cultures.
• Imagery — stock photos should reflect local demographics. A US-centric team photo won't resonate in Japan.
• Examples and templates — sample data should use local names, addresses, and scenarios.
• Legal copy — terms of service, privacy policy, and disclaimers must comply with local laws, not just be translated from English.
• Social proof — testimonials and case studies from local or culturally similar companies carry more weight than US-only references.

Multi-Currency Architecture Technique

Use when: supporting pricing and payments in multiple currencies.

Decisions to make:

• Display currency — show prices in the user's local currency (using exchange rates) or set fixed prices per currency? Fixed prices are more predictable for users but require manual price updates when exchange rates shift.
• Billing currency — bill in local currency (requires local payment processing) or in USD/EUR with conversion at charge time? Local billing reduces friction but adds complexity.
• Revenue recognition — how do you report multi-currency revenue internally? Usually convert to a base currency (USD) at transaction-time exchange rate for consistency.