Backend - Wort aus Holz Buchstaben zusammengesetzt. Buchstaben sind vor einem Quellcode Hintergrund plaziert.

SharePoint Online Backend language

The SharePoint Online Backend language is a very important topic – often underestimated and forgotten. The main problem is, that you should be aware of that topic when you have a Microsoft 365 tenant. The Why and How will be clarified in this post.

Table of contents:

Error messages

Compatibility

Best-Practices / State-of-the-art

Damn, I have a wrong backend language! What should I do now?

Error messages

A long time ago, in a galaxy far away…. 😉 No no not such a long time ago (approx. 5 years) nearly all companies had large infrstructure in their datacenters. Only the cool Hipsters and small Start-Ups had a cloud strategy. With their on-premises servers, most companies took care that all servers are installed in English language – American-English. The main reason for that was “when I search for error reasons and solutions, I find good content only in English”. That counted years ago, and it is still the same today. Did you ever research with a German error message? Or even better: Did you try to translate a German error message to English and start a research with your translation? You have a chance of >80% that you are going to fail. This whole topic did not change with the cloud. Once you have English messages and errors, you have a good chance to find articles, how to handle that error (or even fix it).

Learning number 1: English Backend language leads to English errors, that can help to solve problems. The reason is that the chance is high with English messages to find related content.

Compatibility

It is hard to believe, but there are really extenstions that only work with English! Yes, in the year 2021, in which we talk about artificial intelligence, there is software that is so dumb that it cannot support multiple languages. It even requires English language. This feels like IT in the 90s.

To be safe, every server, every system should be with American-English locale. Please don’t forget: Despite it is absolutely stupid if a software is not multi-language, Microsoft is an American software manufacturer! That means that the main tests are performed in environments with American-English locale. Continuing that thinking leads to the conclusion that for this locale there is a good quality assurance. So you can be sure the software will be more stable.

Learning number 2: With an english backend, I have a backend that was tested intensely. So I can be sure that there are less errors and improved stability.

Best Practices / State-of-the-art

No matter how you shift it – similar to the compatibility issue – Microsoft is an American-Emglish software manufacturer. In the USA, surely no one installes a server or anything in a language different that English, for example German, French, Italian, Japanese or other languages.

I have already seen a situation where a Microsoft employee told a customer how terrible it is to have a “non-English” backend. That ended up in highly political discussions why everything is localized in German.

Learning number 3: Best-Practice / State-of-the-art is to setup everything in English (US). 

Damn, I have a wrong backend language! What should I do now?

All starts with the question: How can I control the language? That can be done the easiest way with SharePoint Online Management Shell:

Connect-SPOService -url https://TENANTNAME-admin.sharepoint.com/
Get-SPOSite -Detailed | select url,localeid
Code language: JavaScript (javascript)

As a result you see a list of all SharePoint Online Sites and their language:

The attribute Url contains the web address, the attribute LocaleID contains the language. In my example it is 1033, which is en-US. A full lust can be found several pages throughout the internet, for example here.

In earlier times the only possibility to change the language was opening a support ticket at Microsoft. You can still do that in the Microsoft 365 Admin Portal at Support -> New service request. The next days you will spend explaining a call center that you want to change the backend language, not the frontend. usually you will be shown the frontend language settings and you explain again and again and again that you need to change the backend, not the frontend. After some days you will receive a list of sites that will be re-created. You need to agree that you accept potential data loss because all sites will be deleted and re-provisioned by Microsoft. After all this, the backend will be re-provisioned and you can start from scratch.

If you you prefer not to open a support ticket, you can change the backend language now by yourself (a really good support engineer told me how). You need to know a hidden (but supported!!!) settings page from a previous version of SharePoint. To open it, append the suffix /_layouts/15/settings.aspx to the site address. To open the page, you need permissions, e.g. Site Collection Owner. A complete URL can be like this: https://meintenant.sharepoint.com/_lyaouts/15/settings.aspx.

That opens a settings page where you can easily change the language and the regional settings of the site:

In the menu Regional settings you can change the site locale:

The result is a changed backend language, that you can immediately see in PowerShell:

These steps can be done for each site. If you show your users how, they can even do it by themselves without the help of the IT department (and without data loss). That saves a lot of time and solves all of the problems I’ve mentioned before.

Optionally you can control several other things on that page, e.g. calendar settgings. But that is not important for that article- I only recommend to check the time zone. This way you can make sure all date formats are correctly displayed on your SharePoint page.

Learning number 5: Changing the SharePoint backend language was a mess some time ago, now you can easily perform it by yourself (if you have enough permissions)! 

Published by Andreas

Founder of M365 Evangelists Cloud-Architect, Strategy Consultant, Consultant for Microsoft technologies, Graph API enthusiast, PowerShell enthusiast