Stringing Along to Disappointment in Silverlight

 

As I write more Silverlight code, I get more frustrated with its quirks.

I love that StringFormat is included in Binding.  However, what I don’t understand and what I don’t like is that StringFormat doesn’t seem to respect the CurrentCulture

Let’s say I have an app that’s tracking GiveCamp participation.  Let’s say that my foreign friends over in Europe organized a GiveCamp, to add an international factor.  Now let’s say that we’re tracking the number of devs working on projects each hour.  And let’s make a Silverlight app for that!

The daily chart may show the number of devs, broken by hour.  On the X axis, I’ll see time in my familiar “8:00 PM” format.  My foreign friends should see that same time as “20:00”.  I set the StringFormat property on my DateTimeAxisLabel (from the Silverlight Toolkit) and it works wonderfully.  

But let’s say I want to add a tooltip to each point to show the time (IndependentValue) and number of devs (DependentValue).  I toss a couple of TextBlocks in my ToolTip template, using StringFormat to format them.  These are the same format strings that I use on my axes, so they should respond similarly, right?  That’s what I would’ve expected.

But as I run my internationalized app, I see “8:00 PM” in my tooltips, and so do my foreign friends!  Wait… what?!?

Time to add code to get internationalization working properly, since WPF and Silverlight aren’t getting it right out of the box.

So here’s my call to the WPF/Silverlight teams – please, for the love of doing what’s right – have the StringFormat formatting default to the CurrentCulture rather than to its current default culture (en-US).  It only seems natural for an app to run on its CurrentCulture, unless the developer specifies otherwise.

The Microsoft response to this Connect ticket by closing it as “By Design” really disappoints me.  I can only hope that the Visual Studio team wakes up and realizes the importance of having WPF and Silverlight apps default to the CurrentCulture from an internationalization point of view.  This  “feature” of defaulting to “en-US” is more of a headache for those of us who do develop for an international audience and probably is just as much of a headache for my developer friends who aren’t in an en-US culture.

Just my 2 cents, from a frustrated Silverlight dev…

 

Leave a Reply

Your email address will not be published. Required fields are marked *