Localisation Testing: Cultural Based Assumptions That Caused Issues?

I saw a tweet from @jennydoesthings this week that has caused me to pause for thought and also taught me a tonne about localisation testing! The Tweet for reference:

I figured that not everyone is on Twitter and I wanted to selfishly bookmark this fantastic thread somewhere :wink: so here I am.

Some things in the thread have come up in discussion here before e.g.

Came up in Fun Postcodes to Use When Testing when I learned that few websites can handle Irish postcodes and more recently in Testing Address Inputs but I’m sure there’s more!

My own addition to the thread from Jenny was based on my experience traveling between 4 timezones in 4 weeks…no user would ever do that, right?

I’ve also encountered issues with name fields having a minimum character length which rejected my last name for being too short.

What examples would you add to the list?


My two favorites were about payment and names. Name variations are extremely important as it’s such a vital part of our identity!

There are interesting cultural expectations around payment. https://twitter.com/rkofman/status/1201570694758379522


If you’re working with anything that has informal discussion or sells different products, even if your market is solely English-speaking, words in UK English may not mean the same as words in US English (and let’s not even talk about Canadian English, Australian English, New Zealand English and so many, many more). https://en.wikipedia.org/wiki/List_of_words_having_different_meanings_in_American_and_British_English_(A–L) is a starting point.


While travelling through India and Nepal, I found an American mapping app to be ineffective for locating local sports shops. It seemed that people would often list their home address rather than the shop address. I couldn’t tell if people were gaming the system for their own benefit (I run a successful shop, which doesn’t actually exist) or if it was just the way things were done in that culture (everyone lists their home address). The end result was that I stopped trusting the search function of the app and didn’t visit these shops.

Also in India, I was fairly reliant on an Indian booking app to book budget (sleeping) hotels. The app was presented in English and worked well. An issue arose when someone would phone me up prior to my stay. Perhaps that wanted to know what time I would arrive, or to tell me that the aircon was broken, but I could never be sure as we did not speak the same language. With a massive Indian market, maybe they did not consider that their guests might not be bilingual. In this case I persisted with the app, but the calls were annoying at best.

For example, in New Zealand a ‘hotel’ is a high-end establishment in which to sleep/wash/eat. But in India a ‘hotel’ is usually a low end restaurant. But if the area is touristy it may have the NZ meaning. In the context of a mapping app, this means that filters and search terms have to be backed up with icons or other aids to identify what they really mean.

Exactly! One of the most popular brands of beer in northeastern Australia could easily fall on the wrong side of morality filters - the brand name is XXXX (pronounced “fourecks”) and it’s typically in bright red with yellow highlighting.

Then there’s clothes sizes. Anyone selling clothing online needs to have a guide to what the sizes mean. An Australian size 16 is not the same as a US size 16.

And so on. The list is for all practical purposes endless.

The best one I remember was a date handling module which had this Pascal set [9,4,7,11] for testing whether the month had only 30 days. Of course this was done 30 years ago and software testing was always done by hand. The product went out for three years, the programmer left and I found the bug whilst perusing the code. No customer noticed!

The programmer was American and the set comes from “Thirty days hath September, April, June and November”. Except that June is month 6 and not 7. The programmer went on to become a very famous professor of Computer Science.

It just goes to show nobody’s perfect!

1 Like

The one I found was the different legal definitions of ‘expiry date’ in the UK and the US. In the US, the expiry (oh, all right, “expiration”) date is midnight of the day before, i.e. an expiry date of 31 January means that the thing is invalid from the 31st. But in the UK, the expiry date is midnight of that day, meaning that the thing is valid for all of the 31st up to midnight.

Most people (in either country) do not realise this, and Microsoft is no help because they assume the US definition is the correct one - it’s in their style guide. Too many devs working in the UK take the Microsoft Style Guide as gospel truth.

If you do a Google search for “UK definitions of expiry date”, you have to search quite a lot to find it, as it’s something only really established in custom and practice. But I know this from my days as a very junior civil servant preparing time-limited certificates (prescription exemption, overseas health insurance certifications and so on) and that was the rule we were taught. And if it’s what the Government does, it’s the (administrative) law.

(Obviously, if you have a contract with a US company - say for your phone or your laptop or their software - then the small print will say that the execution of the contract is governed by US law. But equally, if you are working on an app for a UK company, then the outcomes from that app have to comply with UK law.)

Oh, yeah. I got bit by that one moving from Australia to the USA. Australia takes the UK view on expiry, so when I was testing something US-based involving an expiry I was a bit… surprised when my setup to use today’s date as the expiry date ended up insta-expiring the thing I was testing.

Lesson learned…

1 Like
  • unforseen DateTime formatting may cause issues
    … recently seen “EConvertError - ‘…’ is not a valid date and time”

  • decimal and thousand separators may cause issues
    … recently seen undefined character � instead of ‘none’

  • different OS charsets, system settings and/or driver versions may cause issues
    … recently seen failed to open access database EAccessViolations attributable to different localisations

We had some trouble with shortcuts in browsers. They are often based on words to make them easy to remember like Ctrl+P for Print. The developers used English browsers like Chrome and Firefox and the testers used the German versions. Some shortcuts would then call a build in functionality of the browser instead of working with our software.

I once worked on a software that still had the Japanese Imperial calendar incorporated (don’t know how much in use it is), there was a lot of confusion regarding dates.

1 Like

Different calendars aren’t the only thing that can cause date-related havoc. Australia prefers to express dates by day, month, year (25/12/2019). The US uses month, day, year (12/25/2019). The issues this causes when you’ve moved from one to the other - especially on those days that could go either way without any kind of context - are… interesting. And can become quite exciting.