March 13, 2008
Software internationalization is difficult under the best of circumstances, but it always amazed me how often one particular country came up in discussions of internationalization problems: Turkey.
For example, this Rick Strahl post from mid-2005 is one of many examples I've encountered:
I've been tracking a really funky bug in my West Wind Web Store application that seems to crop up only very infrequently in my error logs. In a previous post I mentioned that I had instituted some additional logging features, specifically making sure that I would also log the locale of the user accessing the application.
Well, three bug reports later I noticed that all errors occurred with a Turkish (tr) browser. So I changed my browser's default language to Turkish and sure enough I could see the error occur.
Or, say, this 2005 post from Scott Hanselman:
I had blogged earlier about a bug in dasBlog that affected Turkish users. When a Turkish browser reported an HTTP Accept-Language header indicating Turkish as the preferred language, no blog posts would show up. As fix, I suggested that users change their blog templates, but I knew that wasn't an appropriate fix.
I understand that Turkish prisons are not to be trifled with, but the question remains: why do Turkish people take such cruel and perverse delight in breaking our fine software? What's wrong with Turkey?
As with so many other problems in software development, the question shouldn't be what's wrong with Turkey, but rather, what the hell is wrong with software developers? Some of this is sort of obvious if you have any cultural awareness whatsoever.
- In the United States, we would typically format today's date as 3/14/2008. In Turkey, they format it as 14.3.2008.
- In the United States, we use commas to group digits, like so: 32,768. In Turkey, they group digits using a period, so the same number would be entered as 32.768.
These minor formatting differences are usually not a big deal for output and display purposes, but it's a whole different ballgame when you're parsing input. You'd naturally expect people to input dates and numbers in the format they're used to. If your code assumes that input will be in typical American English format, there will be… trouble.
Most languages have this covered; there are functions that allow you to read or write dates and numbers appropriately for various cultures. In .NET, for example, it's the difference between these two calls:
Because no culture is specified, the first call will parse the number according to the rules of the default culture that code is running under. Let's hope it's running under a Turkish version of Windows, so it can parse the number correctly. The second call, however, explicitly specifies a culture. The "invariant" culture is every American programmer's secret dream realized: we merely close our eyes and wish away all those confusing languages and cultures and their crazy, bug-inducing date and number formatting schemes in favor of our own. A nice enough dream while it lasts, but instead of rudely asking your users to "speak American" through the invariant culture, you could politely ask them to enter data in ISO international standard format instead.
Anyway, point being, this kind of culture support is baked into most modern programming languages, so all you need to do is make sure your developers are aware of it – and more importantly, that they're thinking about situations when they might need to use it.
But all that date and time formatting stuff is easy. Or about as easy as i18n ever gets, anyway. Strings are where it really starts to get hairy. Guess where this code fails?
case "integer" : ;
If you guessed Turkey, you're wrong! Just kidding. Of course it fails in Turkey. When we convert the string "integer" to upper and lower case in the Turkish locale, we get some strange characters back:
"INTEGER".ToLower() = "ınteger"
"integer".ToUpper() = "İNTEGER"
It's sort of hard to see the subtle differences here unless we ratchet up the font size:
|I → lowercase → ı
|i → uppercase → İ
There's obviously no way these strings are going to match "integer" or "INTEGER" respectively. This is known as the Turkish I problem, and the solution should feel awfully familiar by now:
That will produce the expected output, or at least, the output that matches the comparison in the original code snippet.
This is, of course, only the tip of the iceberg when it comes to internationalization. We haven't even touched on the truly difficult locales like Hebrew and Arabic. But I do agree with Jeff Moser – if your code can pass the Turkey test, you're doing quite well. Certainly better than most.
If you care a whit about localization or internationalization, force your code to run under the Turkish locale as soon as reasonably possible. It's a strong bellwether for your code running in most – but by no means all – cultures and locales.
Posted by Jeff Atwood
Except RTL setups, Turkey Test IMHO will cover most of the internationalization issues in your code. The big and the priceless one is #305;#304; problem, however. Here are two quick examples in two well-known software I have encountered in time:
Visual Studio (SDK Actually)
Here is the bug I submitted just three days ago:
VSCT compiler incorrectly changes the case of the path of additional include files when the regional options set to Turkish, resulting in compile time errors
The thing is, a freshly created DSL Tools project does not even compile on VS if the locale is Turkish :)
Resolution? Create C:\Program F#304;les\... and copy some files to make sure they're found.
SubText (and SQL Server)
I was evaluating blog software, and was really interested in SubText. I couldn't be able to execute the setup, however, since all the DB schema creation scripts were broken on my setup. If you define a column named "id" and refer it as "Id" in a query (or an SP schema etc.), SQL Server chokes big time.
The #305;#304; problem is the tornasole paper of the internationalization quality of your software, if you're interested. Yes, other languages have other special characters, and so does Turkish. We have also "#287;#286;#351;#350;", but the problem is only in Turkish, AFAIK, a standard English letter has a different UCase and LCase representation.
The thing is, we have spent millions of millions of dollars worth of time here in Turkey during the last 10-20 years to solve simple issues like this one. And it would be great if you, the fellow developer, spend a little more time to write international-aware software, if it's applicable.
Thanks a lot for mentioning these issues. Will help in the awareness front.
The movie is a thing of the past, actually. It might be a true story or not, I don't know or care. The thing was, It was the only movie about Turkey back in the time, so it was almost impossible for us to explain ourselves to outside world when there is such a movie from a well-known director.
For years, it was (and it appears that is, still) always one of the first topics on the table when you met a foreigner and say "I'm from Turkey". It's event the only non-technical reference you can come-up with to cheer up the post:) In a blog post titled "What's Wrong With Brazil?", I'm guessing that anyone's non-tech references would be Adriana Lima, samba, carnival etc., and I'm sure bad things also happen there, as in everywhere. It appears that, the movie in question will haunt us for a long time, which is very sad.
Imagine if the only detail you had was that these were all posted in 2008. That's not valuable information.
It sure beats only knowing they were written in March?
There's a difference between internal dates and presentational dates. Internally dates *should* (imho) be stored according to the ISO standard: YYYYMMDDHHMMSS. At work I fetch files from an american business, they name their files 03152008.zip - thank you very much for making it easy to sort them with ls. When presenting dates it should be unambiguous, preferrably with the month presented in text and the year with four digits.
As a swede todays date could be written as 15/3-08 or 15 march 2008 or 2008-03-15. I usually group big numbers with space: 20 000 000.
"Of course we could always use the Integer based seconds since 1/1/1980 system"
I thought that was 1970. (At least in Java, it is, and I think, and Hope, that it s the same in all programming languages)
But then you have this (From Microsoft Excel:Mac Help):
Excel supports two date systems, 1904 and 1900. The default date system for Microsoft Excel for the Macintosh is 1904. The default date system for Microsoft Excel for Windows is 1900.
And I wonder why it isn't 1000.
presumably as logical as Intel putting the most significant byte in the bass-ackwards position in x86.
Uh, that one makes perfectly sense, there are (or maybe more were, with older less powerful x86 CPUs) cases (esp. extreme optimizations) where you might want to use the same variable as 8, 16, 32 or even 64 bit variable - e.g. because you know at that stage it fits into 8 bits, or because you need the value modulus 256 or.... With little-endian they all have the same address, with big endian you must adjust the address each time.
Oh, and on the topic, I still can not understand why all languages default to the internationalized string functions.
Most of the code will be internal data manipulation that is more likely to need something ASCII-compatible, exactly that internal code is _much_ more likely to break very seriously by the string functions changing their behaviour than the display code (there e.g. using ASCII instead of Turkish localized ones would only make things look weird, the user would not have any real problems, and in the worst case the real problems would be noticed very quickly and easily).
And lastly, just converting those few basic string functions will not get you really closer to making your program work internationally.
So why the hell could someone consider making the localized, non-ASCII string functions the default a good idea? Even more when creating a completely new language, they could have easily make .ToUpper have a well defined, never changing behaviour that could be used for e.g. config files that never change and any other logic, and have a e.g. .ToUpperL (L for localized) for anything that deals with user stuff.
John Ferguson: "I'm trying to convert the world to yyyymmdd. Works in a standard numerical sort."
But this will break in less than 8000 years. Why are developers always so short-sighted?
boz: "PaulG, you are unbelievably ignorant."
Thanks for the Wiki. I stand informed and corrected (but never "unbelievably ignorant"), and only regarding the movie. Turkish prisons are still bad now, and were bad before the movie.
Stay on topic and save your ignorant insults for someone who deserves it.
Just a thought - the 14.3.2008 format is used in places other than Turkey too. For example, um, in India. Really, this is a case of USA-majority programmers thinking that theirs is the only way things are done.
Wow, if ever a US programmer wanted an excuse not to care about internationalization, the whiny replies to this post certainly provide one. It seems that instead of being helpful, most people prefer being indignant and insulting, especially if they can tie that in with some good ol' fashioned Merika bashing.
I like Windows because I can set the Internationalization to the US, but still set the date to YYYY-MM-DD. I think this is some ISO standard. I've used it since Y2K. But I've found that it is also completely unambiguous. I've never encountered anyone who has confused the order of MM-DD in that string.
I stay away from YYYY/MM/DD because the slashes seem to either sometimes confuse people, or tempts people to shorten it to YY/MM/DD, which sucks because that makes three different orders with slashes in them. I've also seen software that sees the dashes and gets YYYY-MM-DD right, but sees the slashes and gets YYYY/MM/DD wrong.
I've also found that when you put YYYYMMDD in filenames without dashes or slashes, somehow people can figure that out for the most part, especially if you are dealing with years in the 1970-2010 range. But no matter what the separator, you get free file sorting by date if you lead your files that way.
very interesting issue. i'm from switzerland and we even have stranger formats. e.g. although we are in europe (not EU), we write
if you set your osx to the swiss locale, the built in calculator will produce wrong results when calculating with floats. it won't let you use coma as the decimal divider but will fail if you use a dot. (it will produce wrong results!) The only solution to this is to delete the swiss localisation from the calculator.app bundle.
as for all the discussion about turkish prisons and amerika-bashing... c'mon, aren't we over that? don't we all know that nobody, neither turkey, rest of europe and also the us do have a dirty west when it comes to human rights and democracy? and, as i experienced it, when i worked with us-americans, it isn't that polite and common to speak about politics in professional environments. i guess there's a good reason for this!
"you could politely ask them to enter data in ISO international standard format instead."
I don't do much web development, but I was under the impression people could specify their preferred culture in most modern browsers, and you can use that to parse locale specific information. I'm sure ASP.NET has things to help you do that.
Or the shorter "INTEGER".ToLowerInvariant() in the specific case of strings. But you can pass InvariantCulture as an argument to lot's of objects ToString methods.
I'm moving over to YYYY/MM/DD because I find it to be more unambiguous. No-one (afaik) uses YYYY/DD/MM so you can't get muddled up. And I find days and months to be equality important, sometimes I want to know what day and sometimes the month. In a case of equality here surely it makes sense to place it in order of magnitude instead ;)
As useful as it is, it irritates me that the InvariantCulture is so American centric (see dates).
I think you slipped here.
You sound like an american who is the center of the world.
Many european countryes use another date format than america.
And the dot vs comma is the same...this is rather pointless wining, i could say the same thing about americans "why do they write their dates like that" and that is why i put always the date format behind the field (YYYY.MM.DD for example)
Jeff's not whining, he's point out that Americans have to take this into consideration if they expect their software to work outside of the US. Guess what? Most Americans don't know a whole lot about the myriad of ways in which other countries do their date formats and things like that. Guess what? I bet most Europeans only have a limited knowledge of the same thing. Ease up.
You're all lucky to not have to deal with asian internationalization.
Japan and China have more than one local within a single program, and quite frequently this happens.
So ein Kse @ Yanqui
Nehmen wir mal Washington:
20,9% der Einwohner sind deutscher Abstammung und stellen damit die grte Gruppe. Es folgen die Gruppen der Englisch- (12,9%) und Irischstmmigen (12,6%). Hispanics sind mit 9,1% und Asiaten mit 6,6% der Bevlkerung noch zahlreicher als die Norwegischstmmigen (6,3%). Der Anteil der Afroamerikaner liegt mit 3,4% deutlich unter dem nationalen Durchschnitt. 1,5% sind Indianer und 0,4% der Bevlkerung stammt von Bewohnern der Pazifikinseln (wie z.B. Hawaii) ab. Kurz: Redmond ist zu 30 % deutsch..
Das heit: gerade mal die Tradition von unter 13 % wrden die verkorksten Datenformate rechtfertigen.
Das mit den Sekunden ist der grte Schwachsinn berhaupt und nur bei Unixfans gerechtfertigt. Das zeigt deutlich, wie ewig gestrig dieser Beitrag nur gemeint sein kann.
Und zu Werten:
1 Kilometer = 1000 Meter
1 Dezimeter = 0,1 Meter
1 Centimeter = 0,1 Decimeter, 0,01 Meter
1 Millimeter = 0,001 Meter
1 Nanometer = 10^-9 Meter
Die kleineren wirst du kennen. Der rest wie Meilen ist Mischmasch, der nicht mal einheitlich ist.
1 Tonne = 1000 Kilogramm
1 Kilogramm = 1000 Gramm
1 Pfund = 500 Gramm
Sollte auch nicht so schwer sein.
Zeit und Zahlen:
Sonntag, 16. Mrz 2006 17:29 Uhr
1,489 = Preis in Euro fr einen Liter Super.
Viel Spa beim Nachdenken.
Turkish people can easily say whats wrong with america according to this blog... I read the whole thing but didnt make sense to me even one sentence. answer is simple... its because you are comparing US with Turkey... which means u r comparing two countries which maybe you shouldnt but instead you could just accept them as the way they are.
btw Midnight Express is just Hollywood. even the guy himself explained this many many times... go to youtube and search for his own video.
America is the biggest player in the software industry (as well as many industries), so that it should be natural to accept its ways as standards, at least when culture doesn't impose anything.
For instance, I would sure drop my French habits of writing numbers 123.922,023...
Unfortunately, one some topics, American standards are so bad (e.g about dates and units), other countries (you probably now know that you were totally wrong about talking about the turkish exception) will never accept them.
Jeff, please accept my apologies for being a troll on this forum. What seemed like the height of biting satire last night (after a few too many beers, admittedly) just seems like buffoonery this morning. You could even delete these comments if you like, as they contribute nothing useful to the discussion. Thanks,
I'm sick and tired of all this Euro-centric old-world cultural imperialism! In America, we use the Standard (or "Imperial", for you limey bastards) System of measurment because it's part of our cultural heritage (thanks to the aforementioned limey bastards - long live the British Pound!). What right does anyone have to try and tell us that we're "wrong" when all we're doing is upholding the traditions and cultural values of our ancestors? Just because our history doesn't go back for centuries and centuries of inbreeding, religious wars, and the divine rights of kings, doesn't mean we don't know a thing or two about the price of rice in China. There's a reason we kicked you a**holes out of the New World and that reason is called The Metric System, which is really just a crutch for people too stupid or lazy to count past ten. As for dates, everybody knows that the only accurate way to store date values is as an integer representing the number of seconds since January 1st, 1970; so all of your so-called localization issues are really just UI skins for the data layer, which any half-competent programmer can implement for the intended audience. My point is this: if you're going to pirate American software, the least you can do is learn the proper American string-formatting for date values.
As for all the Turkey Apologists: regardless of the relative merits (or lack thereof) of Turkish Prisons, let's not forget that you can be remanded to one for simply "Insulting Turkishness". I won't pretend to know the precise definition of "Turkishness", but if you want a shortcut that will allow you evaluate the conditions inside of Turkish prisons firsthand, all you have to do is mention the Armenian Genocide of 1915 (certain historical facts are apparently contrary to the concept of Turkishness). Or you can just ask Elif Shafak, or Orhan Pamuk, or Hrant Dink (no, wait, you can't ask Dink because he was assassinated by a self-proclaimed Turkish nationalist). At least in America, despite our mm/dd/yyyy ways, we can tell the difference between fiction (Midnight Express) and wholesale slaughter (the Armenians). I can't decide who deserves each other more: Turkey, or the EU.
@poule: no it isn't . In the meantime more software and hardware is produced in India, China and the Tiger states. US is the biggest player with taking on new debts. Software for clinical use is except of GE mostly not made in US. Maybe they don't trust in US software?
Guys, I dunno what's the problem, but here in Russia we format dates the same way they do in Turkey, only we have a space as a group delimiter. We also have a habit so set up our browsers to our preferred (Russain) locale, like most of normal people are used to do. So what? None of the good blogs or web apps rejects our locale or neglects, so the problem is not in Turkey or any other country or their locale or uppercase peculiarities - the problem is in programmers, who do this strange uppercases to variable type names (why would one need it and how can it matter?).
"What right does anyone have to try and tell us that we're "wrong" when all we're doing is upholding the traditions and cultural values of our ancestors?"
That's a good point for me to remember when mocking you guys :D
That's true though. I think it's rediculous for culture's to standardise, it's a culture after all. That's why we do internationalisation in the first case. So keep writing your dates in confusing formats :D I understand
Where are the good old days of spawning code and sites and gizmos without a care in the world. And now all at once we have to consider that someone wants to use our stuff!
And what is worse: 'the' user doesn't exist. And he certainly isn't the power-user he should be to understand our reasoning.
Now our sites have to be Turkish-proof (great country, loved to work there, but hated typing reports on a Turkish qwerty keyboard) Fool-proof, Granny-proof (like that one as an idea), accessible, usable, useful ...
Someone mentioned postal codes? I have given up hope on those ever getting standardized (you know like one number meaning one community and vice-versa) in my own country (Belgium), let alone worldwide.
A tradition is an answer to a question that has been forgotten. That's why RWW will never get a serious answer.
A lot of people blame America, lazy programmers, bad libraries, etc. Blame blame blame.
Internationalisation and globalisation are difficult. There are some terrific tools out there, and some things are dead easy. However, like all programming, it's also far too easy to have 1 line of code destroy all the other hard work in a program. Not supporting my video card is annoying, but that 1 stupid defect will enrage people because, of all things, it neglects their culture.
And we all know that people are very touchy.
As I read through the postings it occurs to me that there is even distribution of idiots from every culture. How is that for internationalization?
Great posting, Jeff.
Interesting and informative post, however from a programming point of view (and not from a political point of view - that would be an entirely different debate, more suited for many other blogs, and unfortunately found in probably over half the comments in this blog), there is nothing WRONG with Turkey.
There IS something DIFFERENT with Turkey, something that some (not everybody develops software for the international -let alone national- market) software developers need to be aware of.
We, Turks, approximately celebrate Pi day on July 22.
It is interesting to see that Turkey flag on a blog I often read.
This localization things make us crazy as Trkish developers occasionally. Workarounds, troubles, amazing bad results, etc.etc.
BTW, I think Jeff did mention Midnight Express thing to get more attention, especially from Turkish developers.
It's funny movie as Kerem says but the thing is funnier than this is many people know / imagine Turkey according to that movie.
One of these days the W3C will get around to ratifying the humor tag.
Doh...that would be the h u m o r tag
Silly html filter... nevermind...joke is verging on the ridiculous now.
This thing haunted us for a week until we figured it out.
We learned something from it. Never use Java reflection if you want to sell to turkey. Especialy don't use properties starting with a lowercase "i" in its name...
The funny thing is, this behaviour is not only coupled with the language setting of your machine, but also with the timezone!!! So if you have an english Windows XP in the turkish timezone, then you'll get this trouble.
Greetings from Germany,
the home of the 's and beer,
It seems its the first time Jeff Atwood has even encountered any language other than English. If he had done, so he would have known that each language has its unique alphabet letters and each culture can have its own way of things just like US.
Thus problem mentioned here does not have anything to do with Turkey. Thus it is wrong to say what's wrong with Turkey. Instead what we should ask is that why does not every country follow the only great US standards.
I once stumped a friend with this riddle:
You speak only English, but you know three words in Turkish. What are they?
I finally had to tell her:
Keep up the good work.
hxr: I guess you're just another ignorant then :)
These people actually program? I thought they just pray all day :)
So you have realized that other countries exist besides the United States? Wow! That's nice.
I'm not from US, but from some pretty small country. And yeah - it was a joke ;)
A nice i18n topic. I wish I have seen it before all the unnecessary flaming comments.
"BTW, only in USA a Billion is 10^9, in the rest of the world a billion is 10^12."
Well, not only in USA. In Brazil a billion is 10^9.
A thought provoking article and comments.
Leads me to think that it is impossible to target the whole world with an application, there will always be something missed. For example, I live in Adelaide, a city 9.5 (nine and a half) or 10.5 hours away from UTC/GMT. There are heaps of programs and hardware gizmos (eg my ADSL modem) which don't allow for half-hour time offset.
A comment on the idea of the American date format evolving from "tradition": rubbish. It has always been a bugbear of mine that so many US standards have departed from tradition or existing standards for no good reason. Why is there a US gallon? Why did early modems use Bell standard tones instead of CCITT? Truth is, Americans revel in doing things differently for the sake of it, to hell with standards. (And Microsoft make an art form of it.)
The US date format makes for lots of confusion when working for an American company in Australia, that's for sure.
As for the German post, the metric measure of distance is "metre", not "meter". Good thing you didn't give examples of volume, where you might have made the same mistake. Shame on you if you are European.
"they're quite unique, if they have a character where lowercase(char) != char65char90?char+97-65:char;"
Unique? Yes. Odd? No.
Modern Turkey adopted the Latin alphabet in 1928, way before ASCII was born (1960?) and before ordering the Turkish alphabet such that the uppercase/lowercase 'i' would be exactly 0x20 characters apart could even be considered :)
I'll try to grossly(*) explain the logic behind this seemingly backwards mapping between the uppercase and lowercase 'i':
In Turkish, the 6 vowels can be grouped in pairs of "thick" and "thin" sounds:
- A (thick), E (thin)
- I (thick), #304; (thin)
- O (thick), (thin)
- U (thick), (thin)
With the exception of 'A' and 'E':
1. When you take a "thick" vowel and adorn it with dots, it becomes "thin".
2. The alphabet is ordered such that each "thick" vowel is followed by its "thin" version:
A, B, C, , D, E, F, G, #286;, H, I, #304;, J, K, L, M, N, O, , P, R, S, #350;, T, U, , V, Y, Z
a, b, c, , d, e, f, g, #287;, h, #305;, i, j, k, l, m, n, o, , p, r, s, #351;, t, u, , v, y, z
The lowercase of 'I' being '#305;' and of '#304;' being 'i' is perfectly consistent in terms of the phonetic makeup of the Turkish language -- and not necessarily consistent with spacing uppercase/lowercase letters 32 bytes apart in ASCII (*AMERICAN* Standard Code for Information Interchange) ;)
(*) I have no recollection (from school) of the correct terms I should be using instead of "thick" and "thin", but I hope I made my point.
This American developer has been encouraged to note that all the anti-American/Waah-You-Guys-Are-Imperialists negative comments have been written in English.
I would think the irony there would prevent bitter developers from posting comments.
The dot of the i is very important for us and it is very different. If you say "s#305;k#305;ld#305;m" it means "i am bored", if you say "sikildim" it means "i am f**ked". It is also important for the software development. You must be very carrefull about that letter. I always prefer to use "I", the uppercase of this letter so there is not a problem.
(For what it's worth, I'm a UK citizen who uses dd/mm/yyyy to comply with the rest of the country, but would rather the world standardised itself and started using yyyy/mm/dd. I also believe that we don't need any numerical seperator besides the decimal point - what is so confusing about 2000000 compared to 2,000,000 anyway?)
I agree with you on the date thing. But please come to Zimbabwe. I just got $ 18750000000.00 put into my account. I then transferred $ 15000000000 to my mother. Paid my golf subs, $ 1840650000.00 and my security company $775000000.00. By the way a coke now costs $ 85000000.00. Now with separators
Yah I agree with you entirely. Numerical separators are completely pointless and we should get rid of them.
(btw, the 18 billion dollars is about 75
I'm not the only one that immediately thought of this post after reading the Gizmodo article, huh? For those that aren't willing to click the links Mike and Jeff left above, it is about a Turkish separating couple which was arguing over SMS. The guy sent a message where a SINGLE CHARACTER got mangled and caused the meaning to change from (this is a translation obviously) "you change the topic every time you run out of arguments" to "you change the topic every time they are f****ng you". She told her father who became enraged and when the boyfriend went to apologize, a stabbing match ensued.
Just a small side note:
1) Germany also has a date of dd.mm.yyyy, however a time of HH:MM:SS. This is historically. At the time, you first care for the most important part: The current hour of the day (what do you care for minutes or seconds if you don't know the hour?). Then you may want to have a more detailed information, like where are we within the hour (minute) and finally, where are we within this minute. Should apply the same way to dates, shouldn't it? But there is one big difference: Most people know what year we currently have, so this is the most unimportant information. And most of the time (except for some people studying philosophy for 20 years or more) people also know what month we currently have. So the day is considered the most important information here. ISO threw all this away and says, the correct way to internationally format date and time is: yyyy-mm-dd HH:MM:SS - always going from coarse to fine grained units. This is BTW the default format I use myself wherever possible on my computer. It's also easy to cut away from left to right (don't need the year, leave it out, don't need the month, leave it out, don't care for the day, leave date out).
2) Date and lower-/upper-case are problems, but you don't even have to go that far. Actually the time format alone will do it. German time format is a 24 hour clock, US is a 12 hour clock with AM and PM. Alone the fact that developers can't get that right is driving me crazy. The German day goes from 00:00:00 to 23:59:59, so by just saying "We have 16 o'clock" people know at once, it's 4 PM and not 4 AM, without mentioning AM or PM. Also makes calculations easier, like how many hours passed between 6 and 16 o'clock? 16 - 6 = 10, easy, huh? Not so easy with 6 AM and 4 PM. There you need to do 4 - 6 (+ 12) = 10 (but + 12 only if one time is AM and the other one PM, if both are AM or PM, then there is no + 12).
IN DEFENSE OF M/D/Y (Over D/M/Y)
Disclaimer: I'm British.
Although both formats aren't really that good (yyyy-mm-dd is preferable and ISO safe), M/D/Y makes more sense (as M is the more significant value). Where this breaks apart is the Y, but both formats get this wrong.
Imagine if the only detail you had was that these were all posted in 2008. That's not valuable information.
Far more valuable than knowing that your post was on the 15th (uhmmm... 15th of what month and year).
Ultimately, Time is sequential and should be displayed in one direction. This means we shouldn't start at Day, go up to Year and then drop off a cliff and go to hours.
I say the most straightforward system is the Japanese system (I'm sure Chinese is similar).
I'm pretty sure that you all can figure out what goes where... even if you can't read the characters.
Here's another Attempt... since this form didn't handle the Japanese Characters:
Replace the letters for the characters and you have the original.
funny thing is we havent any problems with dot or commas until microsoft introduces the regional Settings in control panel.
sometimes i'm missing the good, old and simple dos days.
I run into a funny problem with some strings that I transformed to Upper (i.ToUpper different than I) , but was because I forgot to remove Culture='auto' from aspx page.
I'm trying to convert the world to yyyymmdd. Works in a standard numerical sort.
@Vgvlgyi: "My family name is "Vgvlgyi"" Sounds funny, a typical Finnish could pronounce it "Vakvlkky" or even "Vlkky" (which leads to "Plkky" that means a piece of tree trunk), because our language is pretty straight forward, not filled with intricasies like your language.
"with" "hand": Also we don't set different words after each other, but we bend the words where the base of the word also changes a bit. "Ksi" means "Hand", but "Kdess" means "At hand". But there are exceptions: "Car - In car" is "Auto - Autossa" not "Audessa". That makes it somewhat more difficult to build translators and other logical text manipulators.
@The pitfalls of software development: Line break character, date time formats, and comma/period problem. These things are very small issues, but they cause really much headache and hassle. Someone should do something about them... And we need a line break key in the keyboard that represents a line break without breaking the line before the text is presented to the user. And the am/pm? Why can't you use 20:00 for 8:00 pm? That would be really easy.