local variables

Henrik H. A customer asked me to fix some bugs in the application. The main problem was that the C# web app was not tracking the user’s culture settings properly. Henrik consulted the in-house developer who originally created the application and was told, “Sometimes the culture name and his LCID are out of sync. I don’t know why.”

Well, that explanation didn’t make sense to Henrik either. Why did it have a different name? What the heck is an LCID? Why did he think the two variables were synchronized? The only answer lies in the code, so Henrik took a closer look.

    public struct Culture
    
        
        public const string DA = "da-DK";
        
        public const string EN = "en-US";
    

Start with this struct. This isn’t outrageous, but it certainly cheers us up. We save the locale name as an easily accessible target so that localization can search for locale-appropriate strings and formatting. That’s not all that bad in itself, but as we found out with C#, const Structure members are automatically treated as: staticThis is mostly fine in terms of code, but there is one caveat.

Our main English-speaking customers are in the UK, not the US. They don’t actually do business directly in the US. I can imagine that elsewhere in the code you’ll end up having to “fix” the date and number formats, so they’ll stay European.

Oh, just kidding. They did not use the built-in formatting functions and wrote their own date formatting logic.

But let’s see what it really means.

    void Session_Start(object sender, EventArgs e)
    
        
        Session[Global.SESSION_KEY_CULTURE] = Culture.DA;
        if (Session[Global.SESSION_KEY_CULTURE].ToString() == "da-DK")
        
            Application["LCID"] = 1030;
        
        else
        
            Application["LCID"] = 1033;
        
    

This function runs every time a new user opens the page.it is the default Session Set the variable to Danish locale. The prices are quite reasonable for a Danish company. Next, immediately check the variable you just set and see if it is equal to the string literal. "da-DK" (because you’ve already forgotten that you created a constant) and set the “LCID” variable to a cryptic and meaningless number.

And more importantly, set the “LCID” variable to application variable. This is how ASP .Net is created. global variables.Even worse, global variables shared between all user sessions.

This goes a long way toward explaining why locale names and “LCIDs” keep getting out of sync. Every time a new user opens a page, a global variable is set as follows: 1030Danish value, LCID change All currently active users.

And, as mentioned earlier, none of the code uses C#’s built-in localization features, so the rest of the code: Global.SESSION_KEY_CULTURE Sometimes we have values, LCID I cherish other times as well. If you rotate all instances, Application["LCID"] into the Session["LCID"] I’ve come a long way in fixing the immediately There were bugs, but the homegrown localization feature couldn’t eliminate the thicket of localization-based errors.

I don’t think there was enough money in Henrik’s contract for that. Even if he did, would it be worth the price to restore Henrik’s sanity?