MonthDecember 2020

Microsoft 365 & SharePoint Languages Explained

Users in Microsoft 365 (even experienced ones) often get confused as how languages work across the platform. This an important topic specially for organizations that operate across multiple countries, or in countries that have 2 official languages.

There are many areas where a language can be specified in Microsoft 365, and they can be grouped in 3 categories:

  • Group A: Services whos language can be changed in Account Settings.
  • Group B: Services who language can be changed in Delve.
  • Group C: Free For All. (Each service has its own way of setting the language).

We’ll be looking at each one of these categories, and then dig deeper into the new multilingual capabilities of SharePoint.

Group A (Account Settings): These services depend on the current user’s account settings to determine the language. If you login to Microsoft landing page: Office.com, and you want to change the language for that page or the language being used for Forms, Planner, Word Online, Excel Online. Then you need to do this using the account settings of Microsoft 365. To do this, you can follow these steps:

  • Click on your profile image, and click account settings:

  • Next, from “Settings & Privacy” section, click on Languages > Display language. (The display language is the one that is used to change the labels across the platform). Here you can assign the preferred language.

Group B (Delve): To change the language for SharePoint and OneDrive, the process is a bit more involved. There are 2 locations where the user can set the language, either on their browser or in Microsoft Delve. Delve has more priority than the browser language settings, meaning that if the user set their Delve settings to French, SharePoint sites will display in French (if French is supported on the site). If the user hasn’t specified a language in Delve, SharePoint will look for a preferred language in the browser settings. If the user hasn’t set a preferred language in both Delve and the browser, the site will be displayed in its default language.

For quick tests for SharePoint multilingual pages, it’s best to use the browser settings as it’s very quick to reflect the changes. Changing the language in Delve will take around 10 minutes to take effect. To change the language in browser will depend on the browser itself, but for Chrome and Edge, it’s done by clicking on the options menu:

Then searching for “languages”, there we can set our preferred language. OneDrive will pick up this change and will be displayed in the browser language if Delve has no default language (remember Delve has more priority). To change the language in Delve, you can refer to this article: https://support.microsoft.com/en-us/office/change-your-personal-language-and-region-settings-caa1fccc-bcdb-42f3-9e5b-45957647ffd7

Group C (Free For All): Services in this group have their own ways to change languages. For example, Teams will allow you to change the language while using Teams client. Stream will allow to change the languages in Stream itself and same for other services in this category.

In the next post, we will see how multilingual sites work in SharePoint and how they’re affected by the settings discussed in this post (Group B). Till the next time!

Working with XML & PnP Provisioning

If you work with PnP Provisioning Engine that much, you might reach a point where you want to have your configuration sitting in an XML file, and read its settings and pass it to your provisioning engine. However, you might run into some issues when dealing with special characters if you try for example to name your sites something such as “R&D”.

We’ll have a look at a case. Let’s say you have an XML configuration file named config.xml, that contains some settings regarding site urls and site names that you want to use in your provisioning engine. One of the values in XML might look like this:

Config.XML

If you try to read its value like this:

Reading XML file with PowerShell

You’ll end up with such an error:

Cannot convert value “System.Object[]” to type “System.Xml.XmlDocument”. Error: “‘<‘ is an unexpected token. The expected token is ‘;’

This means, that we’ll need to encode our value in XML, so we’ll end up with something like this:

Encoding values in XML

Or we can keep the value is XML as R&D, and replace the & with &amp; in our PowerShell script like the following:

Getting XML as string then replacing invalid characters


Now when we get the right value from $Config in PowerShell, it works just fine, and we’ll have a string as “R&D”. However, when we pass this value to our provisioning template:

It will complain again with such an error:

‘ ‘ is an unexpected token. The expected token is ‘;’.

The reason is, when it’s passed from PowerShell as “R&D” to the provisioning engine, it has to be encoded one more time. To do so, we’ll need to execute this before passing our values to the provisioning engine:

[System.Web.HttpUtility]::HtmlEncode($config.parameters.SiteTitle)

We store this in a variable, and pass it as a parameter to our provisioning engine. It will work like a charm!