Satisfying the masses

One of the most basic rules of developing software for mass global consumption is that regional differences in date, time, currency and decimal points need to be taken into account.

Yet, software projects often don't pick up on this until it is too late, jeopardising - or at the very least, delaying - the localisation effort, and with it, the company's international launch(es).

Depending on location, dates are displayed as dd/mm/yyyy, mm/dd/yyyy or yyyy/mm/dd, with a variety of separators, such as spaces, slashes or dashes. Ditto times, where a colon, a full stop or a space may be used as separator.

In addition, some countries have unique variances in their calendars. The US week starts on a Sunday, whereas in Europe it begins on a Monday. Russia follows the Julian calendar, while in many other countries the Gregorian calendar is in favour. In some countries, like Egypt, various calendars are in use depending on the context - religious or secular.

Let's run through some scenarios of what can happen when software has been written solely for the domestic market.

A global Web site belonging to a US multinational might, for instance, be written in English and prices will display in US dollars.

What's wrong with that? While it is possible to sell to German buyers in dollar-denominated prices, a buyer would most certainly prefer to buy in the local currency.

Secondly, dollar amounts use commas to separate thousands and full stops to separate units from sub-units (dollars and cents), whereas in Germany, commas are taken as decimal separators, and in France, spaces play the part of the US comma. Hence, a thousand US dollars ($1,000) would be read as 1 US dollar in Germany. And a thousand dollars and 25 cents, according to a German developer ($1.000,25) would look like barely more than a dollar to an American.

Now that the potential for farce and annoyance can be appreciated, it's easier to understand why coding for local audiences is so important.

Number formatting problem scenarios usually develop in one of three different ways:

Enter the imperialist
At the outset of a coding project, developers are seldom sensitive to localisation issues, and start off coding in US dollars or another base currency until someone realises there's a problem. Now, the team has to chase down every instance where US dollars were used and change it to a local currency. This is often not a trivial undertaking, and I wouldn't recommend retrofitting at all.

But let's say the coder is aware of the complexity - he or she now has a choice.

The maverick
Some may jump in and hard-code local date formats for the regions the company is entering. However, these may grow over time and render the code increasingly complex. Developers are often under-instructed in the arcana of software localisation, but many will relish the chance to tame its complexities, which could, unfortunately, have severe repercussions for the outcome of the localisation project.

Developers are often under-instructed in the arcana of software localisation.

Undertaking development of a number display conversion tool is a futile exercise with a high workload and even higher probability of getting it wrong. A huge amount of research will have to be done to find out the date, time and currency settings for the various world regions. Often, it becomes a piecemeal approach of starting in one language and region, then adapting it for another, and again for a third, as the company enters a third region. The result - spaghetti code.

The Zen master
The lazy coder looking for a way around this will quickly figure out there is a hack to all of it: the work has already been done at the operating system (OS) level (eg, Windows, iOS or Android), and it is relatively easy to use API calls that invokes a currency, time or date conversion from the OS every time a number variable is encountered in the code/text, and formats it accordingly.

Of course, users may have personal preferences different from OS settings, and at initial start-up of a device, this choice should be communicated. App settings can in turn override user preferences, so apps too should have a set-up sequence that warns of this and gives the option to customise number formatting anew.

It must be understood that this approach involves a deliberate override of what is available at the OS level. It is therefore advisable to start with the Zen approach, understand it, and if need be, augment or even replace it.

Choice by way of app settings can have other benefits, for example, on phones in Africa - much of the installed base anecdotally owns second-hand phone imports from elsewhere in the world, so settings may already conform to a different region's formats. Again, it is up to the vendor to educate the user on the possibility to change settings.

The best bet would be not to code for one set of regional formats, or for every region from the ground up, when all the work has been done already. It is possible for users to have a measure of customisability in the app without going down the long, wrong road of reinventing the wheel.