The Problem
You build a feature for US users. 6 months later, you launch in Japan. Your translators deliver JSON files. Your content sounds mechanical. Users in Brazil complain that pricing doesn't make sense in their region. Support says dates are confusing.
You didn't think about localization until it was a crisis.
The Trap
PMs often treat localization as "translate strings" or "ask a native speaker." Neither is sufficient.
Localization is a product decision, not a translation task. It demands spec clarity on:
- Which regions/languages are in scope?
- What adapts culturally vs. stays fixed?
- How do dates, currency, numbers, measurements display?
- What legal/compliance rules apply per region?
The Shift
Think of localization as "making your product feel native, not foreign, to each user."
This means:
- Strings: Translated, culturally appropriate, gender-aware
- Formatting: Dates, times, currency, phone numbers per locale
- Content: Culturally adapted (examples, references, humor, imagery)
- Design: Right-to-left support, text expansion/contraction
- Legal: Tax, privacy, compliance per region
Actionable Steps
1. Define Scope in PRD
Localization Scope:
- Languages: English (US), Japanese, Portuguese (Brazil)
- Currencies: USD, JPY, BRL (auto-converted, no manual rates)
- Date Format: US (MM/DD/YYYY), JP (YYYY/MM/DD), BR (DD/MM/YYYY)
- Out of Scope: Right-to-left support (Q4)
2. Identify Content Types
| Content Type | Approach | Who Owns? |
|---|---|---|
| UI strings | Translation | Localization team |
| Help articles | Localized docs | Support team |
| Product marketing | Adapted (not just translated) | Marketing |
| Pricing/legal | Legally reviewed | Legal + Localization |
3. Spec Behavior for Different Locales
Feature: Price Display
- US: $99/month (USD, no spaces)
- JP: ¥10,890/月 (JPY, full-width characters)
- BR: R$ 99,00/mês (BRL, comma for decimal, translated unit)
Feature: Date Picker
- US: MM/DD/YYYY, week starts Sunday
- JP: YYYY/MM/DD, week starts Sunday
- BR: DD/MM/YYYY, week starts Monday
4. Create Localization Dependencies
PRD should note: "Feature can't ship until translations for [languages] are complete."
- Budget 2-3 weeks for translation
- Budget 1 week for QA (strings in context, cultural review)
5. Plan for Text Expansion
German translations are ~40% longer than English. Japanese is more dense. English-focused layouts break.
Spec it: "Text fields must support up to 40% expansion; plan UI accordingly."
Key Takeaways
- Localization is product scope, not an afterthought. Define it in the PRD, not 6 months post-launch.
- Translation ≠ localization. Translation is text replacement. Localization is cultural adaptation.
- Build time into shipping timelines. If you're in 3 regions, add 3-4 weeks to feature shipping for translations + QA.