SaaS Internationalization: Localization and Multi-Currency Pricing
Translating to English is only step one of i18n. This guide focuses on three things that actually move the needle: engineering-grade localization, multi-currency pricing, and SEO alignment with hreflang.
i18n engineering structure
Recommended: extract every user-visible string into resource files (JSON / ARB / Strings) sliced by locale. Use react-i18next, next-intl, or equivalent on the frontend; route backend API errors through resource files too. Don't scatter translations across JSX.
Two approaches to multi-currency pricing
Approach A: show fixed local-currency prices per region without live FX (Notion, Linear). Pros: stable and feels fair to users; cons: business team must maintain regional pricing. Approach B: base currency + live FX (Stripe Tax + auto FX plugin). Pros: simple engineering; cons: prices look like odd decimals. Approach A is preferred — pricing should be a product decision, not FX noise.
hreflang and SEO alignment
Each locale page must have a self-referencing canonical and hreflang for the matching language. Don't point a Chinese page's canonical to its English version. Only include translated pages in your sitemap; partials should be noindex or omitted. URL paths like /zh/ and /en/ are most stable for SEO.
Pitfalls
(1) Storing translations in DB columns instead of resource files breaks static loading and fallback. (2) Single global locale state breaks SSR — server cannot resolve locale. (3) Forgetting to translate metadata (title/description) results in Chinese text in Google's English search results.