When you first created your tenant, a default language was probably set for that tenant based on your location, and this was then used when provisioning your root SharePoint site to set up language-specific templates that then get used by all sites.  Changing that initial default language is difficult, but not impossible, and involves deleting all of your sites.

‍

However, when it comes to SharePoint sites, whenever you create a new SharePoint site, it gives you the option of which base language you want to use for that site.

‍

You can create that site in English, you can create it in French, German or whatever language you want as the base language of that site, but in addition to the base language, you can also support multiple other languages with most of the features (not all) that are available in the base language.

‍

When you are creating sites in your tenant you have to make some decisions for each site about what is going to be the base language and what is going to be the supported additional languages.

‍

For some organization-wide sites, you may want to support several languages but you probably want an authoring language which headquarters speaks, be that English or German or whatever else, as the base language for those sites.

‍

On the other hand, for divisions, regional sites, country-specific sites and so forth, you may want to enforce the rule that everybody uses the same base language as HQ or alternatively you may allow specific sites to have a different base language in which everything is going to work.

You will then have to determine which languages, on a site by site basis, you are going to support. There are five things that are important when it comes to language support: 

1. Alternate languages of the site, for the purposes of multilingual user interface
2. Multilingual Page Publishing is a feature that you may want to use. You can still have multilingual sites without turning on that feature but it is a popular way to enable different page languages for different people
3. Term sets. If you’re using term sets for managed metadata or for other purposes, you probably want to set that up to be multilingual to have different text in different languages.  Term sets can be at the site level or at the tenant level, but at the tenant level you have to set up the language settings, sites can’t do it.
4. Content types.  If you’re going to use them, then when you set up the content type gallery, you have to take some steps to make sure that it is going to be multilingual so the content types and the columns they use are going to be multilingual.
5. User profiles: you want to make sure that user profiles’ users have the correct language to begin with and that they have the ability to change their language if that’s required.

‍

1. Alternate Languages

‍

Every site has got a base language that cannot be changed once it’s set, and it has alternate languages, which are other languages that it can support, and which can be changed later.

‍

To get to that setting you go to “Site Information”, then “view all site settings”.

Under “site administration” you’ll see something called language settings.

If you click on “Show advanced settings”, you will see a list of languages. If your site is not more than 5 years old or so, you will see all of the languages checked. There are certain sites that are created by default with all alternative languages already set and there are other types of sites, more unusual but there used to be more in the past, that by default will only support one language.

‍

‍

You don’t necessarily want to support all languages because it’s a lot of work to support 50 languages and you don’t want to have the overhead if nobody is going to use them. You will probably want to cut that down to a handful of languages, just the ones that you need.

‍

Once you have set up the alternate languages, you can set up the multilingual user interface (MUI) for those languages, on a site-by-site basis. You can populate the multilingual user interface by changing your language then editing every UI element, typically hundreds of them. For a few of them, if you have Multilingual Page Publishing turned on, then there is also an alternative way to edit those localizations.  That’s for another post.

‍

‍

2. Multilingual Page Publishing

‍

The other thing that you have to look at is Multilingual Page Publishing.

For certain types of pages like modern site pages and for news posts, you have the ability to translate them to other languages. By “translate”, Microsoft means that you’re the one doing the translating. It’s just going to copy the page and will ask you to carry out the actual  translation. But you have to set up the languages that you’re going to support for that. 

‍

So like the previous section, you will go to the “Language Settings” under “Site Administration”, but this time you can slide the slider that says “Enable translations into multiple languages”. 

Once you turn that on, the first thing it will do is turn off all language support for all other languages. 

‍

But fear not because it will then give you the opportunity to add languages again one by one.

First it wipes out support for all other languages and then it  lets you add languages.  For each language, it will let you add an email for somebody to notify when it’s time to translate a page.

‍

‍

Having done that, when you create a page in your site pages library, you will see something in the command bar called “Translation” and if you click on that, it will let you copy that page.

It creates a copy of that page in some language-specific folders and will send out that email, then somebody somewhere is going to be asked to translate that page to French, to German or whatever language it is that you have selected.

‍

‍

When a user comes to that site, if the page is available in their language, then, following the user’s current language settings, the page will show in that language.

‍

Users also have the ability, with a little language toggle, to change the language of the content. The toggle navigates to a different copy of the page in another language without changing the user interface language. That is not necessarily a good thing but it is not something  that you can turn off.

‍

‍

3. Term Sets

‍

The next thing you will want to look at is term sets if you’re using managed metadata or if you’re using term sets for anything else.

‍

Go to the SharePoint Admin Center to set term sets in multiple languages. 

You then click on “Term store” and when you go to the top level taxonomy there and edit it, you can set the default language of these term sets or of the entire term store and then add what it calls “working languages”, which is the equivalent of alternate languages on sites.

‍

‍

Any term that you have within the term set will have the ability to show different texts in different languages, which is a useful feature.

Also in the term store interface, when you edit the term set, you can click on the “Advanced” tab and then find “Manage” under  “Translation” and there’s a feature there where it will populate your term set with translations in all the other working languages of that term store. 

‍

‍

It is a very slow process that often fails the first time. Try it again, it is going to work for the rest of the day and suggest translations. 

‍

‍

You can also review translations if you don’t agree with them and change them.  This is a feature of SharePoint out-of-the-box.

‍

‍

4. Content Types

‍

Next thing you’re going to do, if you’re using content types, you want to make sure the content types are multilingual. That is to say by the time they come down to a site, when a user of a different language tries to use that content type, everything associated with the content type, its name and description and the  column names and descriptions are available in the user’s language. 

‍

That’s actually quite a difficult thing to do:

‍

If you go to the SharePoint “Admin Center” and then the content type gallery and edit the content type, it will only edit in the current language.

‍

‍

What you have to do is actually go and change your language in your profile, which is a time consuming process and can take 15 minutes or an hour. You can then go back to the admin center and edit again, this time you would be editing in that other language and make sure to get all of the columns and the descriptions and so forth. 

There is some inheritance in content types, try to do it from top to bottom in terms of inheritance to make sure that you inherit the translations from the content type and columns from which you are inheriting. It’s a lot less work and will synchronize together better. There is nothing worse than doing all that work and then synchronization kicks in and overwrites it with something else.

It is difficult to do it that way.

‍

An easier way is to go directly to the hidden site which is called contentTypeHub, it’s a normal SharePoint site, and there you can edit all the content types manually the way that you would do on site-level content type. It is a lot easier to edit that way than edit the content type gallery.

‍

‍

‍

5. User Profiles

‍

The last thing is User Profiles. When users go into a site and the site supports multiple languages they will see things in their own language.

‍

How do you determine what their own language is? Is it the language of the operating system, of the language of their browser, something else?

‍

It is a complicated formula but the basic feature is that if they have a preferred display language in their user profile, that is going to override anything else that it could be.

If however they have no preferred language, then SharePoint  looks at the browser’s preferred languages, the browser itself might go look at the operating system or it might not, and if it’s not there then it will use the base language of the site.

What you really want to do is have people have their language defined in their user profile that is synchronized with their user profile in Azure active directory so you can populate it  directly when you provision the accounts.

‍

You also want to make sure that all users have permission to change their own language by granting “Edit Personal User Information”. When they don’t have the permission, they can still do it but it’s slow and confusing and just takes a long time and shows up at some point in the future. You can’t actually prevent them from doing it but if you explicitly allow then you’ll have a much easier time.

‍

‍

The out of the box “read-only” SharePoint group definition does not allow users to change their own preferred language. You will probably want to change that and give them the explicit permission to change their own language. Unfortunately, the permission is defined at the site level. The only difference it will make is the speed at which their preferred language will kick in if they ever decide to change it.

‍

‍

There's an easier way

‍

If you use PointFire, all of this is easier. Alternate languages of the site get set when PointFire 365 is activated, and the whole multilingual user interface is populated with translations.

‍

Whether you use Multilingual Page Publishing or not, PointFire Translator Express will let you translate pages, either by pressing a button, or automatically with a Power Automate Flow.

‍

Content types and their columns get translated, either at the site level or in the content type gallery or both.  It’s easy!  Press some buttons and you’re done.

‍

User profiles: PointFire 365 has its own language toggle that instantly changes your language and synchronizes with the user’s profiles. It also handles date, numeric and currency formatting, and UI language and content language always match.

‍

‍

I hope this helped. If you have any questions, write me at sales@icefire.ca and I'd be happy to assist.

‍