Designing for the Whole World
Living and working across the world brings many pleasures. “Travel opens your mind”, they say. What makes you want to close it again and throw away the key is having to design for all the world's local and cultural particularities in one system.
It's not good enough to simply ignore these differences and expect people to meet your cultural standards.
Here's a short list of eight quick tips to help you build an application that you can sell to The Whole World! (Insert maniacal laughter here).
1. There is no standard shape for a name
Getting user details? We’ll need first name, middle initial, last name. We should also validate that people aren't sticking special characters in there - we want clean data for marketing later after all. If we get this right, we could even build family structure in our database around the surname!
Great! Unless you're Portuguese, or Chinese, or Icelandic, or from countless other countries. Patrick O'Malley doesn't want to be Patrick Omalley in your app and João Vinicius da Silva Conceição would like to explain that da Silva is not two names but one, nor is it a middle name and he feels quite offended that he has to become Joao D. Conceicao to buy from your shop.
It's not a safe assumption that everyone in a family will have the same surname. In Iceland they take their father’s first name as the basis for surnames. Famous Icelandic singer Björk Guðmundsdóttir (or Bjork Guðmundsdottir if you didn't handle special characters properly) has that surname because her father's first name is Guðmundur and she is his daughter (dóttir).
Here's a good article that explains name complexity further.
2. Words are vastly different lengths in different languages
Although you should be sparing with the size of your input fields, remember to treat for the longest expected input across all the languages you support. This goes for any text and labels on your page: "Reset" fits nicely on your button but "Visszaállítása" might not.
There are many tools to keep track of all the text you have in your application and to collaborate on translations. On my last project we used Transifex without any serious complaints, but there are many others. Have a look and see which suits your needs.
You may also have to deal with languages that read in different directions - right to left, top to bottom. In that case, best to consult an expert in that language. It could require a completely different localised version of the layout.
3. Numbers look different in different countries
In the US and UK, numbers have thousands separated by commas, with decimals using a decimal point (period). However it's common in many places for it to be the other way around, like this: 4.500.000,00. You can't expect the users to adjust to fit your prefered pattern; be flexible.
4. Money looks funny abroad
If you're displaying information about money, format it to look like money. "$1.7" looks weird. Be careful with rounding: ask your business experts what to do. Make sure you take internationalization into account too: 1 USD converts to over 20000 Vietnamese Dong, so be sure your pages, inputs, reports etc. can cope with the largest and smallest numbers you're going to expect. Some currencies don't have smaller denominations e.g. cents or pennies. Think about that when internationalising too, as decimals may not be appropriate at all.
5. Currency exchange is a nightmare, but if you get it right you can reach a lot more customers
If you plan to sell internationally, plan to deal with different currencies early. Think about how you account for exchange rates fluctuations: do you convert on day of sale, day of billing, or the day you do your accounts?
Customers tend to dislike the uncertainty of exchange rates. Businesses who display prices and charge in their customer's home currency consistently report higher sales than those who fix their prices in one currency. This may require you to deal with more than one payment processing system. Try to design your system so that your payment processing tool is interchangeable.
6. Dates and times are harder than you think
Your development team and your data centre for your online store are in Arizona, so let's use Mountain time. That should avoid confusion.
But Arizona doesn't observe Daylight Savings, while the majority of Mountain time zone states do. Oh, there is also the Navajo Nation in AZ that does observe Daylight Savings.
How do we handle an order from New Zealand where it's already tomorrow? Or in Hawaii where it's still yesterday? In a few years time, how do we handle an order from Moonbase 1?
Try to think about the issues related to your project: How will you handle the 13 accounting months for your Swedish subsidiary alongside the 12 calendar months for US HQ? How about different start and end dates for fiscal years across countries?
Invest some time thinking about these problems before you get too far into a certain approach. Consider using UTC and converting in the client to whatever format is appropriate to the user. Even that isn't a silver bullet: Do you process an order from "tomorrow" that came from New Zealand as if it was really placed “tomorrow”, or with the date where the order is being processed "today"?
Also remember that across the world, dates and formats are different. DD/MM/YYYY, MM/DD/YYYY, YYYY/MM/DD. Will you need to support the Hebrew calendar, Lunar Hijri calendar, Minguo calendar..?
7. Not everyone knows how long a foot is
Measurement systems vary across the world. You should internationalise your application appropriately. You won't have much success in asking a German to use inches and feet when ordering network cable, nor expecting an American to comfortably order their lengths of standard construction 2"x4" when you've described them as 50.8mm x 101.6mm. Applications that handle this properly show both values, let you search across both values, allow the user to choose their preferred measurement system and let you convert between them easily.
8. Your masterful puns do not work in other languages
Monster.com's "Your Calling is Calling" is a great example of this: There are not many languages where this translates at all, let alone succinctly. If you’re going to have a pun, accept that you’re probably going to struggle to translate it or replace it with something boring. The Merchant of Tennis, Prints Charming, I Feel Like Crêpe -- I’m looking at you as the best worst offenders.
Hopefully this article helps you reflect on how you can approach your next international project or product. It’s certainly not an exhaustive list, nor does it provide much in the way of solutions but I hope these tips help you to reach more users and enjoy internationalisation stress-free. If you’ve got stories about other internationalisation pitfalls, please add them to the comments!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.