Regionalizing Your Mobile Designs, Part 2
Regionalization means considering the entire context of people’s different needs in other parts of the world, not just hiring some service to change the display language.
In Part 1 of this two-part series, I provided an overview of how to regionalize your products—approaching regionalization from a procedural and technical point of view—and detailed the approach you should take.
In this part I get into more details about how to design for different regions, as well as describe how to format specific attributes such as date, time, currency, names, and units of measurement:
About 2 billion people speak right-to-left languages. Global products need to be able to work with flipping the entire UI.
Flip the ENTIRE UI. Right-as-forward should flip, and reveal arrows should be on the left for right-to-left languages.
Conversational UIs like “Send message to” then a picker won’t work for many other languages where the object of the sentence should be first if you just translate. Can you re-order for each language, or should you avoid these pitfalls entirely?
Abbreviations and jargon often do not make sense or do not translate well. Start by making sure the native language of the app works for every user, and it will work better for other languages.
Don’t translate organization names, or localize spelling of common features. Pearl Harbour, for example, is not a real place (see the extra U).
Only about 60% of countries use a comma as a scale delimiter (thousands indicator), and a decimal point to indicate a break between whole numbers. Regionalize all figures so they are easily and accurately read.
Currency symbols are not always in the same place, so must be able to be before or after the value.
Lots of countries share currency symbols. $ is used a lot of places, so if ambiguous (along borders, lots of trade with other countries, etc) use or add the international abbrevion. USD is for US Dollars, for example.
Tip! Once you get currency localization, use it to make all your prices read better. 99¢ is much more easy to read and appealing (more sales!) than $0.99.
Never store dates or times as strings but as temporal data in UTC (Coordinated Universal Time), then let the product localize it and present in the current time zone.
Always display time zone, and UTC offset. Don’t worry about time zone abbreviations being non-global values (lots of repeats) as it’s just enough to reassure users you aren’t giving the wrong time, from the place they traveled last week or where your service is located, but local to them.
24 hour time is “24 hour time,” not military time or anything else. 12 hour time is “12 hour time,” not normal time.
10/1/2020 and 1/10/2020 are the same date in two different regions, but which date? 10 January or 1 October? Don’t just change to the right order for the region, but when you can possibly fit it, just letters for months. 1 Jan 2020 is pretty clear. Also you can often drop years and it will fit just fine.
In some languages such as French, the convention is not to capitalize the names of months. Follow regionalization rules carefully and precisely, don’t assume anything.
Many countries invert the display of given and family names, prefer to use all caps for family names, or have other display conventions with which you may be unfamiliar. Addresses are even more complexly variable.
Don’t impose any formatting on names or addresses unless you literally have to. Only certain banking, credit reporting, and a few other government functions actually need separate fields. Everyone else can just use one big “Name” field, one big “Address” textarea. Users will fill it in right, services like Google Maps and Places can parse it.
Unit sets such as Metric or English are probably not what you’re used to. Never, ever refer to your regional default as Default, Normal, or Standard.
In the US, or where you work with US users, the two labels should be “Metric” and “U.S. Customary.” Imperial or English is something else and not a unit set, respectively.
Explain what the units are when letting users pick a set from a list to make it clearer. Not everyone understands the difference.
There are unusual regional units. “Imperial” and “Latin America” are both unit sets I have also added to products.
Translating values to other unit sets should follow the same rounding rules. 2.1 miles should convert to 3.4 km, not 3.37962 km.
Don’t convert all numbers. Metric thread sizes are nonsense when translated, for example.
Don’t convert degrees of latitude and longitude in positional data. Yes, I’ve seen that.
Spaces in formatted numbers, or value/label pairs must never break or wrap to the next line. Use non-breaking space characters or other formatting techniques. The degree symbol follows without a space 67° F.
The earlier you understand all the complexities of regionalization, the more quickly you can make decisions about how to solve your short-term problems—with the least wasted effort or technical debt—and the better position you’ll be in for either your next major release of an existing product or an entirely new product.
Read More
Learn more about how to think about designing for other regions, other cultures, and the whole world. Just read the whole article at UXmatters.
https://www.uxmatters.com/mt/archives/2021/01/regionalizing-your-mobile-designs-part-2.php