▶When should I start internationalization, at launch or after?
Start before launch if you plan global from day one. Build i18n from the beginning (string externalization, locale detection) at near-zero cost. Retrofitting is 5-10x harder: hardcoded strings scattered across components, RTL forgotten, pluralization rules ignored. Plan for i18n in your architecture, even if you don't ship other languages immediately.
▶What are the biggest RTL (Arabic, Hebrew) gotchas?
RTL is more than flipping layouts: text direction, number placement, currency symbols ($ after number in RTL), form field ordering, table column reversal, icon mirroring (arrows, checkmarks). Pseudo-localization testing is crucial, many apps only flip the layout and leave numbers/icons broken. Use CSS `direction: rtl` + logical properties (`margin-inline-start` not `margin-left`). Test with actual RTL languages, not just a reversed English string.
▶How do plural rules work across languages?
English: singular (1 item) vs plural (0, 2+ items). But Russian has 3 forms (1, 2-4, 5+ items). Arabic has 6 plural forms. ICU MessageFormat handles this: `{count, plural, one {1 item} other {# items}}`. Most i18n libraries (i18next, react-intl) use ICU plurals. Never write custom plural logic, it's locale-dependent and breaks.
▶Machine translation (Google Translate, DeepL) vs human translators, when do I use which?
Machine translation is 80% good for high-traffic, simple content (help text, buttons, notifications). Human translation is mandatory for brand voice, marketing copy, legal/compliance docs, culturally-sensitive content. Hybrid approach: MT for first draft + human review (cheaper than from-scratch). Test MT quality on 50-word samples before committing to full rollout.
▶Locale switcher UX, where should it live?
Footer or settings, never the hero. Most users don't switch languages frequently. Provide a fallback (detect browser language + allow manual override). Sticky choice across sessions via localStorage or user profile. Never auto-switch based on IP alone, VPN + expat users = wrong locale. Use hreflang to signal locale variants to search engines.
▶Currency and number formatting, how granular should it be?
Use Intl.NumberFormat (JavaScript) or locale libraries, never hardcode. US: 1,234.56. Germany: 1.234,56. India: 12,34,567. Currency symbols vary too: $USD, £GBP, €EUR (varies by country), ₹INR, ¥CNY/JPY. Don't just swap the symbol, use locale-aware Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).
▶SEO with multiple languages, how do I structure URLs and headers?
Use hreflang in HTML head and XML sitemap to signal alternate language versions: <link rel="alternate" hreflang="es" href="https://example.com/es/page"/>. Structure URLs by language: /en/page, /es/page, /fr/page (subdirectory) or subdomains (en.example.com). Each language version gets its own language tag in HTML (<html lang="es">). Don't mix languages on one page. Google Search Console: verify each language variant separately.