Broken SharePoint - it's basically an art form

Problematic behavior of web.AddSupportedUILanguage(int lcid) in SharePoint 2013 and 2016

This post was most recently updated on August 31st, 2022.

2 min read.

Every now and then, an API or a method call comes along, that you need to be very careful with. “Microsoft.SharePoint.Client.Web.AddSupportedUILanguage()” seems to be one of them. In this post, I’ll try and document my findings and workarounds for said method! 

Issues and solutions

In SharePoint 2013, web.AddSupportedUILanguage doesn’t actually add new languages

This is a known bug in SharePoint 2013. Adding a new language using just this method call doesn’t work unless the targeted web already has one or more alternate languages.

As a workaround, call this first:

clientContext.Web.IsMultilingual = true;

After that, the languages should be added.

See more:

My theme completely blows up after adding a new alternative language!

Another interesting feature of the localization in SharePoint! I’ve seen this happen with Variations in use multiple times (more info about that can of worms here: SharePoint Localization – a (somewhat) comprehensive how-to!), but it apparently happens when programmatically adding new alternative languages too!

Adding a new language using AddSupportedUILanguage() broke the composed look / theme on this SharePoint site
Adding a new language using AddSupportedUILanguage() broke the composed look/theme on this SharePoint site

The theme, or a Composed Look, as they’re called in SharePoint 2013 and 2016, generates its files for all required languages either when the theme is activated or when the language is added. This doesn’t seem to be the case, when you add a language using the AddSupportedUILanguage() method.

For this case, there are a couple of workarounds.

Time needed: 5 minutes

web.AddSupportedUILanguage(int lcid) workaround 1

  1. Manually reapply the same theme

    Through the GUI, you can actually just navigate to the Design Manager (“Change the look” in the Site Actions menu, located in https://[site_url]/_layouts/15/designgallery.aspx), select the current theme, and go through the process of activating it. That means selecting it, clicking “Try it out”, then selecting “Yes, keep it”.Those pages will look quite broken, though, as the broken theme can affect system pages, too. And probably will. But just plow through!

    "Change the look" is located in the Site Actions -menu
    “Change the look” is located in the Site Actions -menu

  2. Select the current (first) theme in the list

  3. Check out the preview, and click “Try it out”

    Previewing the composed look on your site
    Previewing the composed look on your site

  4. Accept the preview by clicking “Yes, keep it”

    Previewing your new theme
    Previewing your new theme – after clicking “Yes, keep it”, it’ll be applied to your site

  5. After accepting the preview, after a short loading time, your site should work again!

Workaround 2: Programmatically reapply the same theme

If you can’t afford to manually fix each and every site, there’s also a programmatic fix available! And that makes sense because it’s a programmatic action that got you in trouble, to begin with. In my case, I’m using OfficeDev.PnP’s “SetComposedLookByUrl()”-method. More info about the method is here:

After running the code where you call AddSupportedUILanguage(), run the snippet below:

 ClientContext ctx = new ClientContext(siteurl);
 ctx.Web.SetComposedLookByUrl("The name of your custom composed look");
 Console.WriteLine("Composed look changed!");
catch (Exception ex)

This piece of code updates the composed look – or actually just reapplies it – and forces the generation of the theme files for your selected language.

And with that, you should be good!

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments