Sitecore on Windows 10: Language Storm

A colleague of mine – Maryna Veller – has discovered and diagnosed a very interesting issue with Sitecore’s language resolution on Windows 10. This blog post is the result of her findings

Sunny Morning

You have a site. Perfectly architected, beautifully built, working like a well oiled machine on Sitecore 8 and Windows 8. The most important section of the site is under:

http://www.yoursite.com/all-products/*

Nothing but a perfect weather in the forecast.

Afternoon Storm

That same site deployed on Windows 10 and a sudden storm:

1443889097

The site is English only with no language embedding into the URLs:

    <linkManager>
      <providers>
        <add name="sitecore">
          <patch:attribute name="addAspxExtension">false</patch:attribute>
          <patch:attribute name="languageEmbedding">never</patch:attribute>
          <!-- ... -->
        </add>
      </providers>
    </linkManager>

What’s going it? Where the hell did the storm come from?

Strip Language

Sitecore would always attempt to resolve a language from the URL unless you set a Languages.AlwaysStripLanguage setting to false:

<!--
  LANGUAGES ALWAYS STRIP LANGUAGE
            This setting specifies if the StripLanguage processor in the <preprocessRequest> pipeline 
            will parse and remove languages from the URL, even when the languageEmbedding attribute 
            of the linkProvider is set to "never". 

            You should only change this setting  to "false" if the default behavior causes problems in your solution.

            Default value: true 
      
-->
<setting name="Languages.AlwaysStripLanguage" value="true"/>

The stripping happens in preprocessRequest and it goes like this:

  • Get the first section of the URL following the domain name
  • Attempt to parse the value as a language
  • Confirm with Language Manager whether it’s a valid language

The last step is fairly simple:

try
{
    return this.GetCultureBuilder(name, false) != null;
}
catch
{
    return false;
}

In our case it will basically check whether a culture can be created off of all-products. The GetCultureBuilder will split the name into a language and a culture using hyphen as a separator. If it can’t find both it will return null otherwise it will consult with the underlying .NET Framework / OS.

It will come down to:

new System.Globalization.CultureInfo("all", false)

Windows 8 vs. 10

On Windows 8 the code above produces the expected CultureNotFoundException. On Windows 10, however, it actually finds something for almost (if not any) three letters combinations.

The following:

System.Globalization.CultureInfo.GetCultures(System.Globalization.CultureTypes.AllCultures);

returns some ~400 entries on 8 and about ~800 on 10.

Umbrella

No idea why the difference in behavior between Windows 8 and Windows 10 but Maryna will sell you an umbrella for free. You can pick one of the following styles to weather the storm:

  • Set the Languages.AlwaysStripLanguage to false
  • Don’t use a hyphen in your landing page name (it really only affects your second level pages)
  • If you really need a hyphen then make sure the first part is neither two nor three characters long. Shorter or longer seems to be fine

Stay dry!

UPDATE: Oh, and one more thing. Once your language was incorrectly resolved, your browsers would carry a yoursite#lang cookie. In our case it would be set to all. To use the umbrella of your choice you first need to clear your cookies.

Pavel Veller

2 comments on Sitecore on Windows 10: Language Storm

Ryan TuckJune 1, 2016 - Reply

A colleague of mine just came across this after upgrading to a new PC, good to know we weren’t the only ones dealing with this weird one 🙂

Ryan TuckJuly 4, 2016 - Reply

Just came across this again, expect this time the site is SC 6.6, on Windows 10, and the Languages.AlwaysStripLanguage setting doesn’t exist. Sigh. Guess I’m going to the umbrella of decompiling and custom preprocessRequest processor 🙁

Add a Comment

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

Or request call back