It must be one of those days where weird problems just crop up…

Got a note today from a customer that he couldn't place an order on our site. He got hung up on the security code field of the form. He would hit the page and see a binding error displayed on the control.

I went out to check this out right away and sure enough I couldn't duplicate it. But he sent a couple of screen shots that clearly showed a problem. On a hunch I noticed his country as part of the email address – Hungarian and set my browser to Hungarian.

Sure enough I saw the failure as well. Now I was able to duplicate the problem. I ran into something similar a while back with Turkish language requests. I switch my ASP.NET operating thread into the locale the user is in so that all content automatically displays the locale specific number and date formatting. Which means this particular request is now running in Hungarian.

I also use custom databinding on my forms where the controls bind to an underlying data source – in this case a DataRow. The field bound is ccsecurity in the SQL Server database, and I bound to ccSecurity. The databinding code gets down to eventually accessing the DataRow with:

DataRow["ccSecurity"];

which fails in Hungarian. However that same code works just fine in English and Western locales. Only if I switch the value to all lower case to match the field name it works:

DataRow["ccsecurity"];

all upper case works to:

DataRow["CCSECURITY"];

but this mixed case fails:

DataRow["ccSECURITY"];

while this works:

DataRow["cCSECURITY"];

Go figure that one out <g>…

Previously in the Turkish language reference the problem was the Turkish I and i which are not the same in the Turkish alphabet. So if you didn't use just the right case it didn't translate quite right.

Ideally we should be culture neutral strings, but who are we kidding that this will happen everytime a DataRow index is accessed by string? Especially if this value is declaratively assigned through the UI as it is in my databinding controls. The next best option is to use all upper case where the Turkish characters are most similar to the Latin alphabet.

That still doesn't explain why some of the odd mixed case scenarios above work and some fail. Even accounting for the character differences it seems the Turkish I should always fail if it's lower case.

On a side note, in the ASP.NET Thread Switch entry above I used some code in Application_BeginRequest to set the thread context which works well. ASP.NET 2.0 introduces a new globalization option to automatically detect and switch the thread context. You can do this on the page or in web.config globally:

<globalization requestEncoding="utf-8" responseEncoding="Utf-8" culture="auto:en-us"/>

Unfortunately in my case I still need to override some of the behavior – specifically the Currency symbol. If you switch the thread context, I want to see numbers and dates properly formatted, but the currency used still needs to by $. So I'd back to overriding the currency symbol in the Application_BeginRequest:

Thread.CurrentThread.CurrentCulture.NumberFormat.CurrencySymbol = "$";

But this doesn't work – when ASP.NET assigns the locale apparently it uses a custom context that is read-only. Bummer…