I18N - Internationalisation Woes
Living in the UK gives you a fraction more exposure to the problems of internationalisation than living in the US does. This is probably because a UK centric company has fewer than 100 million potential customers, where as a US centric company has more than 300 million and on average these customers are richer, and the proximity of other countries with significantly different languages and cultures.
One of my big frustrations has always been the US date format. All other common date formats can easily be programmically manipulated without determining their local origin, but the US date throws a spanner in the works. It also sneaks its way into programming languages, such as the mktime function in PHP, tripping me up every so often.
The countries that use MM/DD/YYYY are Belize, Canada, Federated States of Micronesia, Palau, Philippines, and the USA.
Their populations add up to 435,582,899 people. [Belize (307,899), Canada (34,073,000), Federated States of Micronesia (111,000), Palau (20,000), Philippines (91,983,000), and USA (309,088,000)]
The population of Earth is 6,815,472,221 people.
Therefore, only 6.4% of the population of Earth use MM/DD/YYYY
The other 93.6% don't use MM/DD/YYYY
I wish the US would just concede that they were wrong and use DDMMYYYY or YYYYMMDD, unfortunately that doesn't seem plausible so we all get stuck with an annoying format to deal with.
Today I was looking at the HTML5 input type number and wondering why it did not work in Firefox. The issue is primarily an I18N problem. While I have long been aware that some countries use 1,000,000.00 and others use 1.000.000,00 I did not realise the extent of the other versions such as
1,000.000,00
1'000.000,00
1.000,000.00
1 000 000,00
1 000 000.00
10,00,000.00
What a hideous mess... Now you might expect people to be able "work out" what those numbers mean, however, having observed people who have never seen the notation $1000.00 assuming the price is $100000 or even $1000000 when they are scanning through reading, clearly demonstrates an important usability issue.
Google Chrome seem to have gone ahead with a reasonable solution, the UI string is localised, but the submitted string is standard floating point (in most languages) i.e. 1000000.00
Of course with no standardisation and agreement we have what could be a useful field unavailable for use :(
I18N is a pain, but when you realise the costs of a single system e.g. Driving on the left/right, metric/imperial, comma/fullstop numbers they are always high. Perhaps the World Bank should introduce a huge fund, we all agree on these factors and the costs of changing signs etc is drawn from this World Bank fund? OK probably not a great solution, but I am happy to look at anything that gets rid of this fiddly problems.
One of my big frustrations has always been the US date format. All other common date formats can easily be programmically manipulated without determining their local origin, but the US date throws a spanner in the works. It also sneaks its way into programming languages, such as the mktime function in PHP, tripping me up every so often.
The countries that use MM/DD/YYYY are Belize, Canada, Federated States of Micronesia, Palau, Philippines, and the USA.
Their populations add up to 435,582,899 people. [Belize (307,899), Canada (34,073,000), Federated States of Micronesia (111,000), Palau (20,000), Philippines (91,983,000), and USA (309,088,000)]
The population of Earth is 6,815,472,221 people.
Therefore, only 6.4% of the population of Earth use MM/DD/YYYY
The other 93.6% don't use MM/DD/YYYY
I wish the US would just concede that they were wrong and use DDMMYYYY or YYYYMMDD, unfortunately that doesn't seem plausible so we all get stuck with an annoying format to deal with.
Today I was looking at the HTML5 input type number and wondering why it did not work in Firefox. The issue is primarily an I18N problem. While I have long been aware that some countries use 1,000,000.00 and others use 1.000.000,00 I did not realise the extent of the other versions such as
1,000.000,00
1'000.000,00
1.000,000.00
1 000 000,00
1 000 000.00
10,00,000.00
What a hideous mess... Now you might expect people to be able "work out" what those numbers mean, however, having observed people who have never seen the notation $1000.00 assuming the price is $100000 or even $1000000 when they are scanning through reading, clearly demonstrates an important usability issue.
Google Chrome seem to have gone ahead with a reasonable solution, the UI string is localised, but the submitted string is standard floating point (in most languages) i.e. 1000000.00
Of course with no standardisation and agreement we have what could be a useful field unavailable for use :(
I18N is a pain, but when you realise the costs of a single system e.g. Driving on the left/right, metric/imperial, comma/fullstop numbers they are always high. Perhaps the World Bank should introduce a huge fund, we all agree on these factors and the costs of changing signs etc is drawn from this World Bank fund? OK probably not a great solution, but I am happy to look at anything that gets rid of this fiddly problems.
Comments