Question

Previously, I had no problem with this code in my view, and, it always properly reflected the user’s language preference set in IE9:

@using (Html.BeginForm("Edit", "Revision", FormMethod.Post, new { id = "RevisionMain" }))
{
    @Html.Hidden("UICultureLanguage", CultureInfo.CurrentUICulture.Name)

...
}

I recently added this code, and was also working for me previously. However, in between the last time this seemed to work, and the time it broke, the only thing my company did, was upgrade to Telerik Kendo; I don’t see how that could have affected this, but the problem is that the above code and the below code, no longer properly reflect the user’s language settings as chosen in IE9…

I have a code block in my view uses CultureInfo.CurrentUICulture.Name, but it appears to always be set to en-US, regardless of what I set my IE9 language preferences to. Note: this code is embedded in a @section:

**@section JQueryScripts** {
    <script src="@Url.Content("~/Scripts/jquery-1.7.2.min.js")" type="text/javascript"> </script>
    <script src="@Url.Content("~/Scripts/jquery-ui-1.8.11.min.js")" type="text/javascript"> </script>
    <script src="@Url.Content("~/Scripts/jquery.validate.1.9.js")" type="text/javascript"> </script>
    <script src="@Url.Content("~/Scripts/jquery.validate.unobtrusive.js")" type="text/javascript"> </script>
    <script src="@Url.Content("~/Scripts/jquery.unobtrusive-ajax.min.js")" type="text/javascript"> </script>
    @* Language support for numerics that use ',' instead of '.' for decimal separator *@
    <script src="@Url.Content("~/Scripts/jquery.validate.globalized.number-mvc4.js")" type="text/javascript"> </script>
    @* Language support for jQuery datepicker *@
    @{
        var currentUiCultureName = CultureInfo.CurrentUICulture.Name;
        var scriptFile = @Url.Content("~/Scripts/jquery/ui/1.8.1/i18n/jquery.ui.datepicker-" + currentUiCultureName + ".js");
        // var scriptFile = @Url.Content("~/Scripts/jquery/ui/1.8.1/i18n-minified/jquery.ui.datepicker-" + currentUiCultureName + ".min.js");
        // Note: If we have a language other than english (en/en-US), include the appropriate .js file to
        // support the jquery datepicker.  Nothing needed to include for english because A) english is
        // the default language supported by the jquery datepicker and B) there is no physical .js file for
        // english because it is not needed (see A).
        //
        // Attention: If a language is not supported, let the javascript error come up, so we know that the
        // language needs to be supported.
        //

        if (!currentUiCultureName.Equals("en", StringComparison.OrdinalIgnoreCase) &&
            !currentUiCultureName.Equals("en-US", StringComparison.OrdinalIgnoreCase))
        {
            <script type="text/javascript" src="@scriptFile"> </script>
        }
    } 
}

My web.config currently has the following settings in globalization:

<globalization enableClientBasedCulture="true" uiCulture="auto" culture="auto" requestEncoding="utf-8" responseEncoding="utf-8" fileEncoding="utf-8" />

I also set CultureInfo.CurrentCulture to CultureInfo.CurrentUICulture in my controller, so that my model binds correctly for dates and my numeric values:

protected override void OnAuthorization(AuthorizationContext filterContext)
        {
            base.OnAuthorization(filterContext);

            // For model binding.
            Thread.CurrentThread.CurrentCulture = Thread.CurrentThread.CurrentUICulture;
        }

Very important to note: For some reason, if I set break points in both the OnAuthorization AND the code block in the jQueryScripts @section, OnAuthorization gets hit 3 times (I do have some ajax calls that may be causing this ($(document).ready(…), but have to verify, never noticed this before) – but Thread.CurrentThread.CurrentUICulture seems to only reflect the user’s language preference properly on the LAST call, and the break point that I placed in the jQueryScripts @section, which queries CultureInfo.CurrentUICulture, gets hit on AFTER THE FIRST call to OnAuthorize. I know that OnAuthorize is not setting CurrentUICulture, but just pointing out that it seems that the user’s language settings are being recognized in the controller, but not in the view. Very perplexying…any thoughts?

Answer 1

ANSWER

Would you believe that in my case, it appears to have been a Group Policy issue, which prohibited IE9 language changes being from being recognized by the web application on my local machine. Very odd, although the AD profile I had been using has had various issues since I first picked it up.