The "We'll Localize Later" Trap

Timeline:

Week 1: Launch search feature (US only) Week 2: "Wow, search is great. Can we launch in Japan?" Week 3: PM: "Sure, ship it!" Week 8: Localization team discovers 500 issues:

  • Dates hard-coded as MM/DD/YYYY
  • Currency hard-coded as USD ($)
  • Phone number validation only allows US format
  • UI text doesn't expand for longer languages
  • Japanese needs right-to-left support

Result: 4 weeks of rework. Feature delayed another month for Japan launch.

Cost: Lost revenue from Japan. Engineering time wasted on refactoring. Trust broken.

Framework: Localization-Ready PRD

Dimension 1: String Management

Not just: Translation

WRONG:
- Copy text
- Hire translator
- Ship translated version

RIGHT:
- Identify strings that need localization
- Mark hard-coded vs. configurable
- Plan for context (same English word = different Japanese translation)
- Handle pluralization (1 item vs. 2+ items differ across languages)
- Mark gender-aware strings (Spanish has male/female variants)

EXAMPLE:

English: "You have 1 message"
Spanish: "Tienes 1 mensaje" (informal) vs. "Tiene 1 mensaje" (formal)
Japanese: "メッセージが1件あります" (no gender, different phrasing)
Chinese: "你有1条信息" (simplified) vs. "你有1條信息" (traditional)

PRD must specify: Which form do we use per language? Informal? Formal? Regional variant?

Dimension 2: Formatting (Date, Time, Currency, Numbers)

NOT JUST: Translation

WRONG:
Date: US = MM/DD/YYYY (3/15/2026)
Date: Japan = MM/DD/YYYY (3/15/2026)  [Same, user confused]

RIGHT:
Date: US = MM/DD/YYYY (3/15/2026)
Date: Japan = YYYY/MM/DD (2026/3/15)  [User's native format]

Currency:
US: $1,234.56
Germany: 1.234,56 € (decimal = comma, thousands = period)
India: ₹ 1,23,456 (different grouping: 3, 2, 2 digits)

Phone:
US: (123) 456-7890
Japan: 090-1234-5678
Brazil: (11) 1234-5678

PRD MUST SPECIFY:
- Date format per locale
- Currency symbol + decimal/thousands separator
- Phone validation rules
- Number formatting (1,000 vs. 1.000)

Dimension 3: Content Adaptation (Not Just Translation)

WRONG: Literal translation

"Check out our cool new feature!"
→ Spanish: "¡Comprueba nuestra nueva función interesante!"

User feels: Stilted, not native.

RIGHT: Culturally adapted

English: "Check out our cool new feature!"
Spanish: "Descubre la novedad que revolucionará tu trabajo"
(Same meaning, locally appropriate tone)

EXAMPLES OF ADAPTATION:

UI: "Apply now"
→ US: "Apply now" (action-oriented)
→ Japan: "お申し込み" (more formal, respectful)

Joke: "That feature is broken like my computer"
→ US: Relatable, funny
→ Germany: Remove (humor doesn't translate; sounds unprofessional)

Image: US flag for English
→ Problem: Non-English speakers see US flag, think "English-only product"
→ Solution: Use generic "EN" symbol, or language name text

Pricing: "$9.99/month"
→ US: $9.99 (currency = profit margin psychology)
→ Japan: ¥1,000 (psychological pricing differs by culture)

Dimension 4: Design (Right-to-Left, Text Expansion)

LAYOUT:

English (left-to-right):
[Logo] [Menu] [Checkout Button]

Arabic (right-to-left):
[Checkout Button] [Menu] [Logo]

PRD: "Specify which languages need RTL support. Year 1: English + Spanish (LTR). Year 2: Arabic + Hebrew (RTL)."

TEXT EXPANSION:

English: "Save" (4 characters)
German: "Speichern" (9 characters)
Chinese: "保存" (2 characters)

Spec: "UI buttons must accommodate 150% text expansion (German). Test layout with longest language."

ACCESSIBILITY:

RTL support requires:
- Flipped navigation
- Flipped icons (arrow left/right reversed)
- Text alignment reversed

Spec: "RTL support for Arabic/Hebrew, Year 2 milestone"

Dimension 5: Legal & Compliance

PRIVACY:

US: CCPA (California privacy law)
EU: GDPR (strict data protection)
China: PIPL (data localization required)

PRD: "If user is in China, data must be stored in China data center (PIPL compliance)."

TAXES:

US: Sales tax varies by state (8 numbers to configure)
EU: VAT rules (different per country, reverse charge for B2B)
Brazil: ICMS tax (complex state-based rules)

PRD: "Pricing feature must support tax configuration per region. US: state-level. EU: country-level."

LEGAL TEXT:

US: "By using this product, you agree to..."
EU: "You can opt out anytime. To delete your data..."
Brazil: "We comply with LGPD (Brazilian privacy law)..."

PRD: "Legal text must be localized and legally reviewed per region."

Real-World Example: Localization-Ready PRD

Scenario: Payment Feature Launch

Bad PRD (No Localization):

FEATURE: Payment Processing

BEHAVIOR:
- User enters card number
- System validates
- Payment processed
- Receipt shown

CODE: All hardcoded for US

Result:

  • Japan launch: Need JPY currency support
  • Germany launch: Need EUR + VAT support
  • RTL languages: Entire checkout layout needs rework

Good PRD (Localization-Ready):

FEATURE: Payment Processing

SUPPORTED REGIONS (Phase 1):
- US (USD)
- Japan (JPY)
- Germany (EUR)
- Brazil (BRL)

PHASE 1 SCOPE:
- Currency: Auto-convert to user's locale
- Date: Show in user's locale (MM/DD vs. DD/MM)
- Tax: US (state-based), EU (country-based VAT), Brazil (ICMS)

OUT OF SCOPE (Phase 2):
- Right-to-left (Arabic, Hebrew)
- Local payment methods (WeChat Pay, Alipay for China)
- Bank transfer support (Germany, Netherlands require this)

SPECIFIC BEHAVIORS:

Payment Amount Display:
- US: $9.99 USD
- Japan: ¥1,000 (no fractional yen)
- Germany: 9,99 € (comma decimal, period thousands separator)
- Brazil: R$ 49,99 (R$ symbol, comma decimal)

Receipt Date:
- US: 03/15/2026
- Japan: 2026/03/15
- Germany: 15.03.2026
- Brazil: 15/03/2026

Tax Display:
- US: Subtotal $9.99 + Tax $0.74 = Total $10.73
  (Show state code: CA = 7.4%)
- Germany: Subtotal €9.99 + VAT (19%) €1.90 = Total €11.89
  (Show B2B reverse-charge option)
- Brazil: Subtotal R$49.99 + ICMS (18%, SP state) = Total R$58.99

Legal Text (localized):
- US version: "By paying, you agree to Terms of Service"
- EU version: "You can cancel within 14 days per EU Consumer Law"
- Brazil version: "We comply with LGPD. Your data..."

ENGINEERING REQUIREMENTS:

Strings: Use i18n library (not hard-coded)
Currency: Support 3-decimal places (JPY), 2-decimal (USD/EUR/BRL)
Date: Locale-aware formatting
Tax: Configuration per country (not hard-coded)
Legal: Version control for legal text per region
Testing: Test with real users in each region (not just translation)

Result:

  • When Japan launches: Add JPY, it works
  • When Germany launches: Add EUR + VAT, it works
  • When Brazil launches: Add BRL + ICMS, it works
  • No rework needed. Localization-ready architecture.

Anti-Pattern: "Translate It Later"

The Problem:

  • PM ships English-only feature
  • 6 months later: "Let's launch in Japan!"
  • Everything is hard-coded
  • 4 weeks of rework
  • Budget blown

The Fix:

  • Think about localization upfront
  • Spec it in PRD (which regions, which languages)
  • Build with i18n from day 1
  • No "convert to i18n later" rework

Actionable Steps

Step 1: Define Localization Scope in PRD

## Localization

PHASE 1 (Launch):
- Languages: English
- Currencies: USD
- Tax: US only

PHASE 2 (3 months post-launch):
- Languages: English, Japanese, German
- Currencies: USD, JPY, EUR
- Tax: US, Japan, Germany

PHASE 3 (6 months post-launch):
- Languages: +Spanish (Spain), Portuguese (Brazil)
- Currencies: + EUR (Spain), BRL (Brazil)

NOT IN SCOPE (2025):
- Right-to-left languages
- Chinese (Simplified/Traditional)

Step 2: Create i18n Checklist

BEFORE LAUNCH:

Strings:
- [ ] All user-visible text in i18n library (not hard-coded)
- [ ] No assumptions about string length (German is 30% longer)
- [ ] Context provided for translators (e.g., "Save = Save button, not save a file")
- [ ] Pluralization rules defined (1 item vs. 2+ items)

Formatting:
- [ ] Date format per locale (not hard-coded)
- [ ] Currency symbol + decimal/thousands per locale
- [ ] Phone validation rules per locale
- [ ] Number formatting per locale

Content:
- [ ] Cultural review: Any idioms/jokes that don't localize?
- [ ] Imagery: Any cultural specificity?
- [ ] Tone: Is translation style appropriate for each culture?

Design:
- [ ] Text expansion tested (German is 150% English length)
- [ ] Layout responsive (strings longer/shorter than English)
- [ ] No text in images (images can't be localized)

Legal:
- [ ] Legal text reviewed by lawyer in each region
- [ ] Privacy policy localized per region
- [ ] Tax compliance verified per region

Step 3: Configure Region-Specific Behavior

PRD SECTION: Region-Specific Behavior

CURRENCY DISPLAY:

IF user.country = "US":
  price.format = "$X.XX"
ELSE IF user.country = "Japan":
  price.format = "¥X" (no decimal)
ELSE IF user.country = "Germany":
  price.format = "X,XX €" (comma decimal)

TAX CALCULATION:

IF user.country = "US":
  tax = price * state_tax_rate
  show: "Subtotal + Tax = Total"
ELSE IF user.country = "Germany":
  tax = price * 0.19
  show: "Subtotal + VAT (19%) = Total"
  offer: "B2B reverse-charge option"

Step 4: Brief Localization Team Early

Don't wait until launch:

EMAIL: "Heads up - Planning localization"

Hi [Localization Lead],

We're shipping a payment feature next month. Want to plan for Japan/Germany
localization (3 months post-launch).

Key questions:
1. Any UX patterns that don't work in Japanese? (RTL, text expansion)
2. Any legal requirements we should bake in? (Tax, privacy)
3. Timeline: If we spec now, how long to localize?

Quick 30-min sync this week?

Step 5: Test With Native Speakers

Before each localization launch:

TEST PLAN:

- [ ] Test with 5 native speakers (language + culture)
- [ ] Check for: Confusion, tone issues, cultural insensitivity
- [ ] Record feedback: "What's confusing?"
- [ ] Iterate until native speakers say "This feels native"

(Not just "Does it translate?" but "Does it feel right?")

PMSynapse Connection

Localization planning is tedious. PMSynapse's i18n Planner auto-generates scope: "You're launching in 3 regions. Here's your localization checklist: currency formats, tax rules, legal requirements, language-specific behaviors." By automating i18n planning, PMSynapse prevents last-minute localization crises.

Key Takeaways

  • Localization is a product decision, not a translation task. Plan upfront, not retroactively.

  • Hard-coded strings are the enemy. Use i18n from day 1.

  • Currency, date, tax formats matter. Not just strings; behavior must change per locale.

  • Cultural adaptation beats literal translation. Make users feel native, not foreign.

  • Brief localization team early. Don't discover issues at launch. 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.

# Specifying for Localization: The PM's i18n Pre-Flight Checklist

## Article Type

**SPOKE Article** — Links back to pillar: /prd-writing-masterclass-ai-era

## Target Word Count

2,500–3,500 words

## Writing Guidance

Reference PRD Section 9.3 Internationalization. Provide a practical i18n checklist covering: string externalization, date/number formatting, text expansion, RTL layout, cultural sensitivity. Soft-pitch: PMSynapse reminds PMs to consider i18n requirements during specification.

## Required Structure

### 1. The Hook (Empathy & Pain)

Open with an extremely relatable, specific scenario from PM life that connects to this topic. Use one of the PRD personas (Priya the Junior PM, Marcus the Mid-Level PM, Anika the VP of Product, or Raj the Freelance PM) where appropriate.

### 2. The Trap (Why Standard Advice Fails)

Explain why generic advice or common frameworks don't address the real complexity of this problem. Be specific about what breaks down in practice.

### 3. The Mental Model Shift

Introduce a new framework, perspective, or reframe that changes how the reader thinks about this topic. This should be genuinely insightful, not recycled advice.

### 4. Actionable Steps (3-5)

Provide concrete actions the reader can take tomorrow morning. Each step should be specific enough to execute without further research.

### 5. The Prodinja Angle (Soft-Pitch)

Conclude with how PMSynapse's autonomous PM Shadow capability connects to this topic. Keep it natural — no hard sell.

### 6. Key Takeaways

3-5 bullet points summarizing the article's core insights.

## Internal Linking Requirements

- Link to parent pillar: /blog/prd-writing-masterclass-ai-era
- Link to 3-5 related spoke articles within the same pillar cluster
- Link to at least 1 article from a different pillar cluster for cross-pollination

## SEO Checklist

- [ ] Primary keyword appears in H1, first paragraph, and at least 2 H2s
- [ ] Meta title under 60 characters
- [ ] Meta description under 155 characters and includes primary keyword
- [ ] At least 3 external citations/references
- [ ] All images have descriptive alt text
- [ ] Table or framework visual included