Comments on Moserware: Does Your Code Pass The Turkey Test?

good job, this really makes sense

2008-04-22T02:51:00.000-04:00

good job, this really makes sense

mert sakayra: interesting to hear about Flex. You'...

2008-04-08T23:24:00.000-04:00

mert sakayra: interesting to hear about Flex. You're right about it being not just Turkey. The idea is to think about many different locales, but Turkey does seem to highlight a lot of the issues itself.

peshir: Yeah, names are tough. Thanks for the info.

superjason: Agreed.

Where I used to work, we always did QA on a German...

2008-04-08T10:46:00.000-04:00

Where I used to work, we always did QA on a German OS, and a Chinese OS. It's amazing how much you learn by doing that. Chinese is particularly difficult because it's double byte.

The biggest thing that people had to learn, was to always keep everything binary. Only when accepting input or displaying something do you turn it into human readable format.

--SuperJason (blog)

In Holland we use a date format of dd-mm-yyyy and ...

2008-04-08T10:00:00.000-04:00

In Holland we use a date format of dd-mm-yyyy and have things like IJ and ij ligatures which could mess up your Unicode characters.

Something I have not seen mentioned here are assumptions on other culture specific things, like when concerning yourself with names. In Holland someone named "Jan van Dam" would have a first name "Jan" and last name "van Dam" but in a "LastName, FirstName" list would have to be sorted as "van Dam, Jan" under the letter D... ;-)

The main issue of the "Turkey" test is the "I" and...

2008-03-31T01:33:00.000-04:00

The main issue of the "Turkey" test is the "I" and "i" problem ("i" is not lowercase of "I" and vice versa). This is specific to Turkish language. The other problems are specific to more then one countries. There are lots of countries that uses "DD/MM/YYYY" or "DD.MM.YYYY" format.

Until the first release of .Net, Turkish "I" problem could not be solved in Microsoft technologies, and programmers had to do some hardcoding for that problem which led the application to be very specific to Turkey.

There are many other server and development applications that don't work on computers with Turkish region settings. As far as I know Adobe Flex that runs on Eclipse is one of them. When you start coding mxml it has a "Script" tag and the "i" in tag causes compiler error.

I recommend setting your region to Turkey and using "I", "İ", "ı" and "i" everywhere (comments, strings, variable-names etc.) then testing your compiler/environment...

If you are developing international applications and Turkey is one of your targets, be prepared for problems...

One more thing Turkey is in a very strange location, so you have to consider the language problems for Greece, Russia (by the sea), Bulgaria, Armenia, Georgia as well as arabic spoken languages (Syria, Iran and Iraq has borders with Turkey), when you say "Turkey and nearby".

So if you expand your territory to Turkey and nearby region, you'll probably will have to solve all regional issues other than Far East (and may be India region) issues.

"I" and "i" problem is unique to Turkish.

German use the same date and currency format. The ...

2008-03-17T12:29:00.000-04:00

German use the same date and currency format. The 3. and 4. problems are really crazy ^^)

Clifton: I can see your point to a degree. The exa...

2008-03-16T21:32:00.000-04:00

Clifton: I can see your point to a degree. The examples were primarily focused on classic cases where seemingly innocent lines of code can get you in trouble. While looking a bit contrived, they do tend to show up in production code. But you're right, it makes sense to use ISO standards whenever possible. Especially for clear things like XML formatting standards that build on ISO ones. There will still be times where you might look for a configuration file string literal. In this case, it becomes important to not get hit with culture issues.

The whole point of the article is to make sure you're aware of the issue. That in itself is a huge step towards getting things to work right.

@David Nelson -Not at all. For me (in NZ), today i...

2008-03-16T05:19:00.000-04:00

@David Nelson -

Not at all. For me (in NZ), today is the 16th of March. Not March 16th. Although I think that varies as much from person to person as it does culturally...

Got here from Scoble! I'm a web/software developer...

2008-03-15T06:22:00.000-04:00

Got here from Scoble!

I'm a web/software developer in the UK. I used to work for a large multinational with sites in both the UK and the US. Whilst the problem of date formatting etc did come up, I solved it by adhering to the standards set by the ISO, which is what I guess I'd urge anyone to do. After all, what use is a standard if no one uses it?

I let users know how to enter data in the application by adding appropriate labels to text boxes (e.g. "Date (YYYY/MM/DD)"). This seemed to work quite well but then I never had to deal with anyone in Turkey!

R

Aren't most of your examples showing exactly the w...

2008-03-14T21:59:00.000-04:00

Aren't most of your examples showing exactly the wrong way to fix it?

Your suggestions address what would be needed to make the application work for an American who happens to be living in some other country and running your software on the operating system version for that country. It would absolutely not work the way most people in that country would want!

For example, your proposed code ensures that wherever in the world someone uses your application, it will require them to input dates in American format, enter numeric values like Americans, and so on. The problem is that if a Turkish, English, or German customer enters the date "07.04.2008", you can be virtually certain they want it to be treated as April 7, 2008; if a Turk (or Frenchman) enters "0,50" for the percentage discount, you can be virtually certain they want to give a 1/2 percent discount, not a 50% discount.

Instead, shouldn't you be showing examples of how to change your displays and input validation code to match the local culture? Then you will have a usefully internationalized application.

Rainer said "By the way we had no problems with Y2...

2008-03-14T05:42:00.000-04:00

Rainer said "By the way we had no problems with Y2k at all".

No, we had problems with "day ten thousand" causing havoc on alpha-sorted indexes 4.5 years earlier instead. So don't go making out it is perfect :-)

Since everyone likes bashing the "American" date f...

2008-03-13T18:56:00.000-04:00

Since everyone likes bashing the "American" date format (MM/DD/YYYY), I would just like to point out that it does have a good reason for existing: it mirrors the way most Americans (and most English speakers as far as I know) pronounce dates aloud, e.g. "March Thirteenth, Two Thousand [and] Eight". Since all such formats have to be interpreted relative to pre-conceived ideas, I don't think that format is any less valid than any other. That said, it is terrible for sorting, which is the only reason that I typically don't use it.

It would be worth noting that all those cases ment...

2008-02-22T04:21:00.000-05:00

It would be worth noting that all those cases mentioned above are also valid for other Turkic people using latin alphabet like Azerbaijanis Uyghurs, Tatars etc... (see http://en.wikipedia.org/wiki/Uniform_Turkic_Alphabet)

Great and informative article, right in spot. Thanks!

You need to email me or something. Try my work em...

2008-02-21T18:50:00.000-05:00

You need to email me or something. Try my work email, my middle initial is C.

thanks

2008-02-19T15:13:00.000-05:00

thanks

Niki: Thanks for the CultureInfo.TextInfo.ListSepa...

2008-02-18T07:57:00.000-05:00

Niki: Thanks for the CultureInfo.TextInfo.ListSeparator tip. I didn't know about that member.

Thanks for the concerns about digits in Turkey. As mentioned above in a comment, I qualified the post as "in or around" Turkey since you're absolutely right that most Turkish people use [0-9].

I tried to pick a locale that would highlight a lot of unexpected results and had to stretch it for Turkey for digits.

Again, the overarching theme that I wanted people to take away was the concept of Turkey as a "Sintra Test" in the sense that if you work hard to make your code work well in Turkey by using the best practices outlined in the string paper, your code will probably work anywhere.

2 comments:1) Only 10 digits used in Turkey, so a ...

2008-02-18T07:44:00.000-05:00

2 comments:
1) Only 10 digits used in Turkey, so a regex for [0-9] is sufficient. Perhaps you should've done a bit more research about Turkey and what's used there before naming the test as "the Turkey test". I understand that you're trying to make a point in locale problems but I guess you can name it differently (locale test... middle east test.. eastern europe test w/ Arabic numbers.. etc.)

2)
for the ignorant ones.

This might be also called the Polish test with pun...

2008-02-17T18:54:00.000-05:00

This might be also called the Polish test with pun intended. We Poles write dates just like Turkish people. DD.MM.YYYY.

MM/DD/YYYY format is misleading and counter-intuit...

2008-02-17T08:03:00.000-05:00

MM/DD/YYYY format is misleading and counter-intuitive, abondon on it :) http://en.wikipedia.org/wiki/ISO_8601 defines YYYY-MM-DD which I prefer

I personally use for dates the number of days sinc...

2008-02-17T04:29:00.000-05:00

I personally use for dates the number of days since the 1 JAN 1968, as in the Pick/Universe world for the internal representation of dates. Makes it easy to calculate 30 or 90 days off a certain date for compares and can be easily converted into any local external date format. Today is day 14658. By the way we had no problems with Y2k at all.

Turkey.

2008-02-17T00:09:00.000-05:00

Turkey.

Great Post! A little not-so-well-known addition: I...

2008-02-16T17:47:00.000-05:00

Great Post! A little not-so-well-known addition: If you parse CSV (comma-separated-values) files, don't assume they're actually separated by commas. In a German locale, for example, they're separated by semicolons. Use CultureInfo.TextInfo.ListSeparator instead of ','.

I agree with using standard formats for dates. I'd...

2008-02-16T14:44:00.000-05:00

I agree with using standard formats for dates. I'd probably use the XML date format so that it's absolutely ambiguous.

Dates are just one thing. With things like string comparisons, it's not intuitive to a guy coming out of college in most places.

As the referenced paper mentions, checking URIs for the "file" protocol(knowingly or unknowingly) using a culture sensitive comparer could be dangerous due to the "Turkish I" issue.

I guess the overarching theme I was going for, and I still stand by it, is that you have to think about the globalization impacts of your code. It's hard to abstract away if your code is to correctly operate around the world.

Oh and btw, "arabic numbers" is a misnomer. The nu...

2008-02-16T14:42:00.000-05:00

Oh and btw, "arabic numbers" is a misnomer. The numbers are Hindu, not arabic. Zero, like the "arabic" numerals, is not arabic at all, but Hindu in origin (it originated in India, in present-day pakistan, before it became islamic, arabic is a double misnomer since they associate themselves as both a religion and an ethnic group, neither of which had anything to do with the idea of Hindu numbers, Hinduism, on the other hand, relates to both the ideology and the ethnicity of the people who came up with the numbers, and the zero)

For the love of insert favorite love, don't do t...

2008-02-16T14:36:00.000-05:00

For the love of *insert favorite love*, don't do this. What this code will do concretely is make your application behave DIFFERENTLY IN DIFFERENT LOCATIONS AROUND THE GLOBE.

Just use the ISO standard, and assume people know the standard.

Because suppose you get a ticket reservation system in this way. It has servers in, say Europe and in America. One is the fallback for the other.

You travel on 4/7/2008, or, if the European server was down at the time of email, something you won't know and have no control over, on 7/4/2008.

Better hope you have a damn broad ping utility standing by for scanning your emails.

Comments on Moserware: Does Your Code Pass The Turkey Test?

good job, this really makes sense

mert sakayra: interesting to hear about Flex. You'...

Where I used to work, we always did QA on a German...

In Holland we use a date format of dd-mm-yyyy and ...

The main issue of the "Turkey" test is the "I" and...

German use the same date and currency format. The ...

Clifton: I can see your point to a degree. The exa...

@David Nelson -Not at all. For me (in NZ), today i...

Got here from Scoble! I'm a web/software developer...

Aren't most of your examples showing exactly the w...

Rainer said "By the way we had no problems with Y2...

Since everyone likes bashing the "American" date f...

It would be worth noting that all those cases ment...

You need to email me or something. Try my work em...

thanks

Niki: Thanks for the CultureInfo.TextInfo.ListSepa...

2 comments:1) Only 10 digits used in Turkey, so a ...

This might be also called the Polish test with pun...

MM/DD/YYYY format is misleading and counter-intuit...

I personally use for dates the number of days sinc...

Turkey.

Great Post! A little not-so-well-known addition: I...

I agree with using standard formats for dates. I'd...

Oh and btw, "arabic numbers" is a misnomer. The nu...

For the love of *insert favorite love*, don't do t...

For the love of insert favorite love, don't do t...