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.
@Eduardo et. al
Itâs a matter of hierarchy, one looks for the most granular/sensical description of your nationalityâŚI for instance am an Solarian/Earthling,Northern Hemispherian,Northern American,American,Californian,Orange Countyian,Costa Mesaian,Fairview StreetianâŚI should just call myself a Fairview Streetian but youâd most likely have to be a Costa Mesaian to understand that, and then an Orange Countian to understand that. If you walk back up the tree to American, that name would have the greatest chance of understanding regardless of your own locale. So while culturaly you may consider yourself an American, you under this easily understood naming convention would be a Chilean. Itâs by no means an attempt at minimizing your Americanâness itâs simple a matter of facilitating communications.
This whole globalization thing is a fad anywayâŚitâs all going to implode and weâll have regional standards only again. This is the internetâs biggest downfall, global voice but local context.
BTWâŚthis is the OTHER Ryan SmithâŚsigh see naming is such a painâŚ
Most of the cases discussed in this article are ordinary internationalization issues but Turkish I problem is something different and interesting. This especially plagued java applications. Whenever String.toUpperCase() or String.toLowerCase() methods are used, code that contain âidâ fails. If the string that is converted is not for the user and related to application logic, you must use these methods according to English locale. There is a detailed article about this at http://java.sys-con.com/read/46241.htm .
Also whenever a search query is made in an multi-language content (e.g. a music archive that contains both Turkish and English albums), you must assume that all the versions of #305;, i, I and #304; must be treated as the same character.
Over here we use DD/MM/YYYY, and we use commas for decimals and we usually donât group digits, but when we do, we use dots. And yes, we use the metric system. So, Turkey isnât THAT unique. But that wasnât the point of this.
BTW, in Argentina we call us people âyankisâ in formally and âestadounidensesâ or ânorteamericanosâ informally.
Why simply Turkey? Itâs not like theyâre unique.
Most of continental Europe (and East of there) uses a period to separate number groups, and a comma for âdecimalâ numbers. Also, very few places in the world write the date mm/dd/yyyy like you Americans do.
To say that Turkey is the odd-one out is to either be grossly misinformed, or largely ignorant of the rest of Europe. Not picking on you, as such, but rather questioning why this is about Turkey, not just about general internationalisation.
Itâs convenient because:
Turkey is similar enough to other Latin alphabets that itâs not a giant engineering nightmare to get it to work (see: Arabic or Hebrew).
The Turkish-I problem ( http://en.wikipedia.org/wiki/Turkish_dotted_and_dotless_I ) causes failures in naive string comparisons, whereas other Latin alphabets donât.
The Turkey Test gets you 90% of the way to the goal of internationalizing most apps.* We know French and Spanish are going to work. Why not test with the most difficult (but realistically difficult) locale first?
Well, you see, the Turkish flag appears to be a C and a star, meaning their countryâs programming language is C*, whose last revision was 14 years ago. This is a matter of old, depreciated code!
This post was a Turkish Delight until I read all the America bashing in the comments.
i like the above answering post, reasoning doesnât seem out of place in the main article though.
@Jeff:
theyâre quite unique, if they have a character where lowercase(char) != char65char90?char+97-65:char;
sorry, I just love to smite aggressive people
As a Turkish software developer, I really appreciate this post but I am sorry to see that the allegory is easy to miss. Get ready to be flamed by angry Turks.
And I wish youâd known better about Midnight Express before mentioning it even in a joke. It is simply a Hollywood exaggeration/mud.
Iâll add Turkey to my test cases. Thanks from Sweden with posted 14-03-2008, 14-03-08 or 08-03-14 as some put it. Looking at the best before stamp on food wraps and it says 090308 scratching my head.
Typical amarican ignorance. More languages use dd.mm.yyyy than mm/dd/yyyy, Just think about writing an hour after the minute and you know why. 
With number format its the same thing. If you use roman characters, use the appr. format to.
OMG.
In addition to java, I should learn Turkish too?
Great article, as a Turkish developer you explained the problem better than me.
The only really useful date format is YYYY/MM/DD because it the only one that sorts properly as text. Go South Africa!
I gave a software demo in France one time only to have mass confusion five minutes unto my talk because the audience could not follow what I was doing. I had typed a decimal number, and an i18n bug would not let them do the same. To make matters worse, there was a combination of Microsoft code and custom code validating the input. The Microsoft code (correctly) disallowed periods as decimal separators on a French computer, and the custom code (incorrectly) disallowed commas. So the audience couldnât use either the French or American convention for decimals. The solution was for everyone to change the locale on their OS. They said they routinely had to do this to use American software. What an embarrassment.
â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.â
Wow, THATâs really strange! I bet they even have the metric system!
(Like every single country except for Myanmar and the US and A).
The examples you gave above are used in many countries in Europe, so that should not
and cannot be the reason.
Rationalizing mm/dd/yyyy âŚ
This makes sense when you are primarily talking mm/dd. As in, âMarch 3â. The most important thing is the month. It should go first. People who say â3 Marchâ are just plain silly and inefficient 
The â/yyyyâ at the end instead of at the start is obviously a historical error, presumably as logical as Intel putting the most significant byte in the bass-ackwards position in x86.