On the topic of sensible date and temperature defaults in applications and websites

Something that can always get me a bit frustrated is the choice of defaults used in applications.

Dates: Aside from Belize, Canada, the Federated States of Micronesia, Palau, the Philippines, and the United States are the only countries using a date format where the month is the first entry, followed by day, and lastly year (mm/dd/yyyy). To put to numbers that’s about 436 million people who use this versus 6.35 billion that don’t (ratio of about 14:1). Of that 6.35 billion about 3.8 billion use a date format where day is first, followed by month, and lastly year (dd/mm/yyyy — ratio of about 9:1 to the month first users). About 1.81 billion use a form where the year is first, followed by month, and lastly day (yyyy/mm/dd, roughly equivalent to ISO 8601 — ratio of about 4:1 to the month first users). (Note: these 1.81 billion have a slight overlap with the 3.8 billion due to some countries having two date formatting forms in use or due to two or more distinct scripts with different date formatting styles.) So using a format where the month is first is only confusing for the majority of the world’s population. If you need a default date, use the ISO 8601 format — not only is it less ambiguous, it also allows for much better chronological sorting.

Temperature: Aside from Belize and the United States (I so far managed to find), the worldwide standard for temperature is Celcius, not Fahrenheit. If you are using Fahrenheit you are putting 6.48 billion people at a disadvantage solely against something like 313 million people. That’s a ratio of about 22:1, meaning you put 22 people at a disadvantage for every one person you are trying to please.

Disclaimer: do note that this of course only makes sense if you are appealing to an international audience. If you are just targetting a specific country you will of course default to what they use. On the other hand, properly fixing your code to be i18n-ready is the way to go anyway.

Help flu research in BE, IT, NL, and PT

For a few years now there’s been a website in the Netherlands and Belgium that asks participants to fill out their details on a weekly basis with regard to cold and influenza symptoms.

After that there was a Portuguese site doing the same thing.

And now there is an Italian site as well.

There is still not much known about migratory patterns and occurences of the flu within the world, these websites will help create more understanding, so please help them out. It will take a maximum of 5 minutes per week, but the information is very useful for scientists (virologists).

Office 2003, Visual Basic editor and AppLocale

So I was working with a Japanese .xla (Excel add-in) file. I needed to look at something in the source so I fired up the Visual Basic editor within Excel. Upon investigating the form and the various captions it turns out that the Visual Basic editor only displayed them in gibberish (typical decoding issues) or question marks (substituting the .notdef glyph for codepoints). So it seems the Visual Basic editor is either not multi-byte capable (typing directly a string in Japanese into the caption yielded question marks) or it is bound to the locale of the system.

I then remembered AppLocale and fired up Excel through it, setting it to think it is on a Japanese system. Then within Excel I proceeded to start the Visual Basic editor and, sure enough, the text was showing me the Japanese I needed.

I am not sure if I should find this lame or understandable.

Wah Nam Hong (華南行) in Rotterdam

Here in Rotterdam we have a Chinese supermarket called in Dutch phonetic Cantonese ‘Wah Nam Hong’, which in Jyutping (waa4 naam4 hong4) stands for the hanzi 華南行. Literally translated 華南 stands for South China and matches the obvious Cantonese heritage. The stands for a profession or business line.

What is interesting to me is that in Japanese (日本語) you read 華南 as かなん and it means South China as well. However, would be こう or ぎょう and has not retained the profession/business line meaning at all.