Skip to content

What is the Turkey test?

The Turkey Test
What is The Turkey Test?

Hi! This article will cover the topic of Turkey Test. Have you heard about it? Well, you should. Passing it will almost guarantee that your application will work with any locale.

Disclaimer: You should know, that my background is polish. Therefore, I can confirm that half of turkish problems will arise with polish locale.

Turkey Test – where does it come from?

Turkey Test doesn’t come from “large bird in the genus Meleagris as it would suggest the cover photo. It’s connected with Turkey, turkish culture and how they represent data.

Many years ago, when software development was just meeting L10n and I18n problems it appeared, that most of them was somehow related to turkish locale codenamed Tr-tr.

Turkey Test was firstly used by Jeff Moser in his post Does Your Code Pass Turkey Test? on February 2008. Month later, in march 2008 Jeff Atwood from Coding Horror summarized turkey problem and mentioned some bugs in well-known software related to turkish locale from year 2005. Every source in the web about Turkey Test goes back to posts of those two gentlemen.

Should I still worry about it?

The problem isn’t outdated. It’s coming from the different understanding of dates, numbers, different character sets and so on (we’ll look at it in a minute) and nothing has changed in this matter over the years. If your application is ready for turkish locale, it should work well with almost every other locale in the world.

So do I pass it?

You must be ready to cover the differences in locale-understanding. Let’s begin The Turkey Test! What problems might arise?

1. Lowercase and uppercase “I” letter

Turkish dotted and dotless I
Turkish dotted and dotless I

We are used to converting lowercase i into uppercase I. Unfortunately, turkish alphabet defines it in different way. Unicode standard defines it as:

So, if your code rely on string comparison, and i believe that it does at some point – try to avoid mistakes like this:

If you run into this with turkish locale, your switch will just end without redirecting, because it will convert REDIRECT into redırect.

2. Properly parsing dates with specifying the format

Consider that you have some date string, and you need to convert it into object. For example, in US, you would have date string formatted which look like this: “05/07/2015” which is seventh of may 2015. Americans write dates in month/day/year format, but in Turkey it would be day.month.year. So parsing this date with turkish locale will most probably result in getting object as fifth of july 2015. How to prepare for this? You always need to specify format for which you are parsing date or use locale-aware libraries.

To show you how relevant this is, please see below image. It shows what order of day, month and year is used all over the world.

Date format by country indicates month/day/year order, and (which covers Turkey) day/month/year order. If you want to go global – you must consider this difference.

3. Group delimiters in numbers

In United States one million could be represented like 1,000,000.00, so it’s 1000000 and 0 on decimal places. “,” is used to split every group of digits (hundreds, thousands and so on) and “.” is delimiter of decimal places.

Here we go – Turkey representation:


That’s right – symbols are swapped. So how would your code work if it’s not aware of number format?

As you can see – $1M income would become just $1 income. Well, that’s unexpected. How people are dealing with this? One of spread-all-over universal solutions to parse numbers in different formats is to change all comas to dots and remove all but last.

It would work probably in most cases, I’m not aware of any delimiters other than coma, dot and space. Have you seen others in your country?

But even if this works – we could stumble across last of our Turkey Test problems to solve.

4. “There’s more than 0-9 digits out there”

This one’s a bit tricky. As we’re using nowadays math, it’s very easy to believe that there are only ten digits, from 0 to 9. And that’s a huge mistake. In Turkey it could be as well from ٠ to ٩. But let’s go a little further, in Thailand you’ll need to handle digits from to . All those digits have decimal meaning, so be ready for it. Full list of accepted Unicode digits can be found here.

For example, let’s say you need to parse user input into int value, so you’re validating it with regex, right?

Here’s the question. Should it parse such number? As far as i’m concerned, I would assume that such accepted digits, which have decimal representation will be:

  • matched as digits in \d regular expression,
  • properly parsed to their int value,

Unfortunately, the regex matching will depend on used Regex engine. For example, in Java \d will be understood as [0-9] – above code won’t match it (same in Javascript). I can’t find information about other languages – if you’re struggling with this – please post a comment.

But let’s assume, that somehow your turkish number passed validation. Here comes the second part – parsing it to int value.

MSDN mentions, that such try in .NET would raise FormatException. What should be your steps in such case?

  1. Verify if your regex engine matches digitis other than 0-9
  2. If so, be sure to test your number formatting or value casting with Turkey digits – does it work in your programming language?
  3. If not – try to be consistent. Validate and parse in the same manner, and for example modify your regex from \d to [0-9]


To sum it all up, remember about:

  1. There’s dotted and dottless İ
  2. Turkish use different date formats
  3. Parse numbers according to their format
  4. 0-9 are not only digits in the world

And I didn’t mentioned RTL layouts, character sets or persian calendar! Stay tuned.

At the end, I wish you that your application will run smoothly independently of user’s locale. That your users input will properly convert to dates and numbers. Please tell me, what kind of locale-specific problems you bumped into? If you’re from Turkey – do you have your own US Test?

Photo by Tim Sackton licensed under CC BY-SA 2.0