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.
On the 17th the Common Language Data Runtime project at Unicode released version 1.8 of the CLDR.
CLDR 1.8 contains data for 186 languages and 159 territories: 501 locales in all. Version 1.8 of the repository contains over 22% more locale data than the previous release, with over 42,000 new or modified data items from over 300 different contributors.
The data submission phase for CLDR 1.8 should be closed by now (although the survey tool still says it’s accepting submissions). For Dutch (
nl_NL), I’ve been going over quite some items together with the Apple contributor and someone else, so expect quite some improvements on that area. The current release date is aimed at somewhere in March 2010.
Since a few days Google Groups mailing lists stopped having a
Sender header. Aside from being a violation of RFC 5322 in that this is a SHOULD requirement for mailing lists it also breaks labels in Google Mail as well as procmail filtering. Add to that that moderation messages have strange subjects all of a sudden and I wonder which idiot has been messing around with the mail backend at Google without considering the broader implications.
Got to love it when one standard says to either use a date format like CCYY-MM-DD or CCYY-MM-DDTHH:MM:SSZ and the other says only CCYY-MM-DD is allowed. In this case the outside XML container uses the verbose granularity whilst the encapsulated part only uses the small ISO 8601 variant, of which MM and DD are optional too.
In a SIGGraph 2006 presentation by NVIDIA it shows that Microsoft has revisited its stance on how they will support OpenGL within Windows Vista. You may recall when I first wrote about this last year that Microsoft’s initial plan was to layer OpenGL through DirectX.
This time last year…
- The plan for OpenGL on Windows Vista was to layer OpenGL over Direct3D in order to obtain the Aeroglass experience
The situation today…
- OpenGL accelerated ICD now fully supported under Windows Vista
- OpenGL works fully with the Aeroglass compositing desktop
- Performance and stability will rival Windows XP by driver release
So it seems some complaining still works given sufficient pressure.
A few days ago the OpenGL ARB released version 2.1 of the OpenGL standard.
And also, according to a press release on the Khronos website, the Khronos group will now maintain the OpenGL standard.
This might in effect mean that development of the OpenGL standard might speed up.
The files I perused were actually in a zip format so that would explain the binary mode (not that was evident from the extension).
Looking at the format it seems reasonable XML, I just wonder why they needed to brand it as ‘OpenXML’ though…