When a product launches in a new country, the first task people think of is translation. Translate the interface, maybe the marketing site, and you're ready.
Translation is one part. At Travelxp, the product was available in more than 40 countries. Making it work well in each one involved a lot of decisions that had nothing to do with language: how people pay, what content is available where, how prices are shown, what the network speeds are like, and what people expect from an app in that market.
What localization covers
| Area | What changes by market | Why it matters |
|---|---|---|
| Language | Interface text, content metadata, support | The obvious one, and still often done poorly |
| Formats | Dates, numbers, currency, addresses, names | Wrong formats look careless and cause errors |
| Payments | Preferred payment methods, local gateways | Missing the common method loses buyers |
| Pricing | Currency, price levels, taxes | Prices that feel wrong for the market hurt conversion |
| Content | Rights and availability by region | Showing unavailable content frustrates users |
| Infrastructure | Network speed, device mix | A heavy app may struggle on slower connections |
| Legal | Privacy rules, consumer protection, content rules | Not optional |
Design for it from the start
Retrofitting localization is painful. Hard-coded text, date formats baked into the code, layouts that break when text is longer in another language. If there's any chance you'll go international, build with it in mind from early on.
The W3C internationalization resources are a good reference for the technical basics, like handling text direction, character encoding and locale-aware formatting. 1
Translation quality matters
Machine translation has improved a lot, but interface text is short and context-free, which makes it easy to get wrong. A button that says the wrong thing, or a message that sounds rude, damages trust quickly.
I'd have native speakers review interface text, at least for the main markets, and test it in the actual product. A word that's correct in a spreadsheet can be confusing on a button.
Content availability is a product problem
For a streaming service, content rights often vary by country. A title available in one market might not be in another. If the product shows content that the user can't actually play, that's a terrible experience.
The product needs to know what's available where and filter accordingly, everywhere: search, recommendations, home screen rows, even marketing emails. It also makes the recommendation cold start harder, since the pool of titles you can suggest differs by country. This is easy to get wrong in one place and right in the others.
Payments and pricing per market
I covered the payment side in the payment gateway post. The short version: find out how people actually pay in each market and support that. And show prices in local currency with any taxes clearly handled.
Pricing itself might need adjusting. A price that's reasonable in one country can be very high in another. That's a business decision, but the product needs to support it.
Test in the market
Testing from your office won't catch most localization problems. Test with real devices, real network conditions and real users in the market if you can. Different device mixes, slower connections and different usage patterns all show up.
When releasing in many markets, I'd also look at metrics by country after launch. Problems often show up as one market performing much worse than others, which is where the multi-platform release post and breaking metrics down by region help.
Prioritise markets
You probably can't localise fully for every market at once. Prioritise by opportunity and effort. Some markets might get full localization, others a lighter version with key translations and local payments.
Be honest about what a lighter version means for users there. A half-localised product can feel worse than an English one done consistently, so choose carefully which parts to localise first.