Two things that suck about CurrentUICulture, (Part 2, aka On judging a book by its cover)

by Michael S. Kaplan, published on 2007/01/10 06:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/01/10/1442693.aspx

Back in Part 1 of this two part series where I started talking about how there are Two things that suck about CurrentUICulture, I talked about the first thing -- the fact that the CultureInfo object is just way too big for the limited intended requirements of the user interface language.

Now in this post I will talk about the second thing that sucks about CurrentUICulture.

What really sucks the most about it -- the name.

Colleague Nathan said it quite well (his final conclusion that I marked in red, not the first part!):

The most common misuse I’ve seen for CurrentCulture vs CurrentUICulture is thinking that string will be displayed in a GUI then use CurrentUICulture, but if it is to write to a file or event log, etc.. then use CurrentCulture.

I’ve seriously reviewed code where the UI layer uses CurrentUICulture for everything and the underlying bizlogic layer uses CurrentCulture for everything.  And the justification is “the UI layer should go with CurrentUICulture and everything not directly UI should use CurrentCutlure.

So while you may understand that UI means any string that the user may see regardless of how it will be presented, others may understand it differently.

Personally I think having 2 current culture properties was a design mistake by the .NET team.  No one has really been able to explain very well to me why 2 are needed.  If 2 are really needed then they should have given them better names, like CurrentCulture and CurrentResourceCulture so the names can indicate their use.  And of course MSDN about the properties isn’t very helpful in deciding when you need to use 1 or the other.

Now like I said the red part is the part I agree with. :-)

We always tell people to not judge a book by its cover. But as I pointed out in Part 1, CultureInfo is the wrong book anyway. So the only defense we have, the only way to keep people away, is to have a name that better suggests what the intent is, so that people can use it correctly. And more importantly stay the hell away from it when they are not specifically trying to do something with resources.

The fact that the name can lead people to so reasonably use it for different purposes than were originally intended not because they had strong feelings about being different but because they just read the purposes differently from the name is proof enough.

I am okay with people disagreeing with me, truly I am. But the engineer in me (the little guy who says the glass is neither half full nor half empty -- you just have twice as much glass as you need) if offended by the fact that people can make the wrong decision based on what the name of the property is....

Or, as Principal SDE Michael said it:

It seems unreasonable to expect people to remember/follow the rules if they don’t understand the why of the rules.

Maybe it’s because I’m not an internationalization expert. Maybe it’s because I don’t know why a user would set the CurrentCulture and the CurrentUICulture to be different. I’m just a mono-lingual programmer trying to write correct code. To do that I need to understand the why.

I should NEVER have a resource string like: “Angle of rotation must be between 0.0 and {0}”; I should have “Angle of rotation must be between {0} and {1}” and pass in min and max values, even though the minimum value is hard coded.

I guess one source of my confusion is/was the name CurrentUICulture. Given its name, it seems like that’s the one I should use for UI (like formatting a string to show the user). (Of course that left me with absolutely no use for CurrentCulture, another source of confusion.)

He is 100% right, of course -- and I could get off on a whole new series explaining the problem the name of CurrentCulture, too, just like he mentioned. But I think the point has been made. :-)

Now looking back at the serious undercurrent of the non-serious talk about the dual suckage of a particular property, the two basic issues I was pointing out were:

• The object under the property is really the wrong object for the job
• The property is named in a way that can lead people to use it the wrong way

I suppose if what I am against is not only what a property is called but also what it is, then perhaps it is more than just two things. But I honestly only care about either problem insofar as they can mislead developers and potentially cause mistakes to be made in their applications. So I guess you could just say there is just that one thing that really annoys me. One thing with subparts. :-)

Thinking about the language for a bit, and extending the notion of programming being a dialect, what happens when the wrong word (or the wrong object) is put in somewhere like this? It is not so easy to change, even if everyone is misusing it. Because even if you accept programming languages as languages, they are clearly much more rigidly structured by rules that are harder to flout with impunity on a widespread basis (I can only think of one exception to this, one that I'll talk about another day!).

Clearly documentation could help mitigate this, And to be honest, the docs and the tooltip for CurrentUICulture try:

Gets the System.Globalization.CultureInfo that represents the current culture used by the Resource Manager to look up culture-specific resources at run time. 

But as many have indicated, the docs do not really clarify things much here for people. Even if they clearly indicate what the intent is, it is too easy to look at the wrong name and the wrong object and come to the wrong conclusion.

Also for another day, I'll say more about the actual scenarios requiring two settings here. That one is at least going to easily fill up a topic if not a series of them. :-) 

This post brought to you by 𝌽 (U+1d33d, a.k.a. TETRAGRAM FOR CLOSED MOUTH)

# bg on 10 Jan 2007 7:51 AM:

# Phil Jollans on 10 Jan 2007 10:36 AM:

# Michael S. Kaplan on 10 Jan 2007 11:01 AM:

# Shreekar on 11 Jan 2007 7:12 AM:

# Michael S. Kaplan on 11 Jan 2007 7:32 AM:

referenced by

go to newer or older post, or back to index or month or day