Localisation - things to think about as a Product Manager

I was asked recently from someone on my team "Out of pure interest, what’s your experience with localisation like?".

Cue the PTSD flashbacks...

When you have a piece of software working in one region/country, it's entirely predictable that you'll have this question asked sooner or later. Customers often rarely stick neatly to specific countries or languages, they travel, emigrate, expand, and will want to bring the software they love (hopefully yours) with them.

If you're like me, you might initially think localising a product to a region is as simple as just translating the text. How wrong I was.

During my time at Flipdish, we experienced massive growth and were pulled into many new markets such was the demand for the product we'd built. The points below are what I replied to my team member and are just some of the issues we ran into.

Numbers and currency. €1,000.45 in Ireland is €1.000,45 in France (notice the command and the decimal point swapping positions). Obviously currency symbol needs to be different depending on country
Date formats. 18 July 2024 in Ireland, but July 18 2024 in the US. In Ireland you’d say “18th July”, but Americans would say “July 18"
Time formats. Do you use military time like 23:00 or AM/PM (there are preferences in countries). Also, a real struggle was what timezone do you display. We had customers with stores across timezones, so when looking at an order for a store that happened at 3.00pm GMT (the time we’d see in Dublin), the store is in Paris (GMT+1), and the owner viewing the information is in Dubai, what time do you display? You probably need a setting, or in our case a tooltip that showed all the various times that you might care about.
Then you have the mechanics of getting and validating translations. A small company will just have internal people do it (as you expand into a new country, the sales people will want the product translated correctly, so usually they're most engaged in helping you out) but at a certain point you need to formalise it and probably hire a company for it. The problem then becomes giving them really good context in order to have the correct translation. “Order” displayed in the app, in another language could be very different words depending on if it’s a verb or noun.
Designing and coding for long words. Short words in English can be gigantic in German, for instance, so buttons would overflow etc.
Plurals. I struggle with this in my own apps. Imagine a string that, in English, is just telling the user how many orders they’ve ordered. See below. This is actually quite tricky to code, because you can’t just append a letter in every language to make it the plural version of the word, it’ll depend on the amount and the language.

Anything else?

The above isn't even starting to consider the legal and data compliance that come with going into a new country. In the EU alone most countries have their own interpretation of the e-privacy directive and GDPR which you can very easily violate.

Another issue we had was that the product at the time was heavily reliant on sending SMS’s as part of our flow, but certain countries/regions have specific telecommunications regulations that you could also very easily transgress if you're not paying attention.

For instance, in some regions, marketing SMS cannot be sent after a certain time of day. The system has to handle opting a user out of SMS if they reply with certain words specific to that region. It can get quite tricky.

In conclusion

There's a lot to think about, and ideally, the app is built with internationalisation in mind from the start, so that growth into new markets is as painless as possible.