Intranets and digital work spaces are in constant change and evolution. Multi-language intranets and workplaces are increasingly a common business requirement. In the classic SharePoint we usually take advantage of the publishing infrastructure and publishing sites, and the variations feature to create a multi-language information structure and experience.

Hierarchy chart showing a top level root site with three variations beneath it. The variations are English, French, and German
Classic SharePoint site variations structure

In SharePoint Online it is still possible to use the same approach, but limited to the classic experience (and publishing sites).

In the modern SharePoint experience there isn’t (for now) a fully integrated way of having multi-language sites and simple content management.

There are some good articles about this subject in the community that worth reading, with techniques, limitations and recommendations (SharePoint Localization – a (somewhat) comprehensive how-to!, MULTILINGUAL AND MODERN SHAREPOINT).

We will talk about our project experience, some of the pieces we use to create a multi-language experience. The pros and cons.

A multi-language modern site approach

A few notes (not exhaustive) about our scenario:

  • Users from multiple countries and different languages;
  • Some content needs to be secured/restricted by user country origin (and other user properties);
  • Decentralized content – documents and resources from one site/functional area may be presented in other sites/areas;
  • Content in each language has to be translated/managed manually;

Information architecture & classification

Based on the existing business requirements, we adopted a flat multi site collection structure (with both modern team sites and communication sites) and some hub sites.

We use English as the default site language and enabled the other languages in Site Setting > Language Settings option.

We added some managed metadata classification fields (using the SharePoint taxonomy feature), to classify content and resources across all sites.

The requirements of the intranet required an extensive use of “related content” / “see also” type of features. So content classification plays an important role here. The classification tree/tags is centralized and managed in one place by the designated owners, assuring consistent metadata across all organization content.

Content security control

In a multiple site collection site structure, user access & permission’s governance it’s a crucial subject. There are different approaches, for different scenarios.

In our case, for content with restricted access by country (or other user property) we take advantage of dynamic Azure AD security groups. Users may change location periodically, so with this feature no manual configuration work is required (like remove user from SharePoint group and add it to other – in multiple site collections), and users will be automatically removed and added to the respective AD groups.

User profile

The user profile service plays an essential role in this process. Each user has it’s own language preferences/properties, given by the user profile “My display Languages“. And depending on the chosen language, user SharePoint interface will be presented in that language (assuming that language is available on the site) – Multiple Language User Interface (MUI) feature.

In our custom elements we read and use some user properties to display a custom content experience/targeted content, using SharePoint Search and KQL.

Pages, documents and resources language classification

The language classification of a page, a document or other type of resource is given using the managed metadata fields mentioned before.

Each element instance (page, document, etc) represents one language. For a page in 3 languages, we need to create 3 pages and make the required classification.

The way content or pages in each site are organized depends on your preferences:

  • Folders – you can have a folder for each language, which it’s a good fit when you need to have segregated permissions – yes, you can have folders in Site Pages library. You also need to have metadata in your pages
  • Metadata – if custom permission are not an issue, you can have a flat page structure organized with metadata. Using views to manage the content;
  • Sub sites – you can also use sub sites for each language, we did not used this one.


We have implemented a dynamic tenant wide menu that depends on user language. The menu options and addresses changes with user language – again, we store and manage the menu taking benefit of the taxonomy features. The Spanish version of the menu will point to the “es” pages, and so on. With this, users will browse in it’s language content and have a unified navigation experience across all sites.

We have also created a redirect mechanism to use in the sites root page, when users access by direct site URL, we can redirect to the right language/page.

Custom web parts

We have created, among others, a search based results web part (see this topic) with the ability to filter by user language (and some other user properties) and other query parameters. We use it to show relevant content in different places, with specific content classification tags. Many of them use SharePoint Search features to create a dynamic experience.

Putting the pieces in place

Connecting all the elements in our solution we were able to create a multi-language site experience, with a simple content management structure, where users will see and navigate trough content in it’s language.

Information classification & metadata plays an essential role, not only for language classification, but also to create a personalized user content experience by filtering content by it’s user properties or other organization rules.

We had to create some custom elements (like webparts and extensions) that detect the user language and adapt the content accordingly.

Out of the box webparts (like Highligthed content webpart) can also be used in this scenario. Metadata is our friend here, and we can configure the webparts to filter by the required metadata fields.

After initial setup and key users training they quickly became independents in creating and managing the content for all languages.

The pros

  • Simple content management
  • Unified content classification experience
  • No over complex solution, not compromising the adoption of a future native SharePoint feature for multi-language

The cons

  • No internal linking between the “same” page in the different languages – like we have with variations;
  • Manual page creation and classification for each language (we ended up creating a powershell script to do that);
  • Custom solution to redirect users in some scenarios – degrading user experience;
  • Requires some additional configuration across sites;

If you have any comments or questions, feel free to comment!

Sharing is caring


MCarolina Trigo (@mcarolinatrigo) · February 5, 2019 at 10:17 am

Check the episode here:

Sam Foster · March 18, 2019 at 12:53 pm

Hi. I just thought I’d drop you a line and make contact. I’m based at Bangor University here in Wales, UK. I’ve just been looking at your post about multilingual Modern SPO sites and wanted to let you know that we’re looking at this at the moment. We have a need to develop a solution for our Intranet which we intend to use modern sites for.

I’ve a developer tenant where I’ve been trying all sorts of things out with regards SPFx, powershell scripts and so on.

I have finally come to terms with the fact that variations are dead to me, and I probably need to think along the lines of metadata columns for the content etc and then implementing an ‘in-page’ language switch.

Do you guys have any code repositories that might contain snippets I could make use of – or anything else you care to share with a weary traveller?

Thanks in advance,

Sam Foster
Corporate Web Manager
Bangor University

    Luis Ribeiro · March 18, 2019 at 5:06 pm

    Hi Sam, thanks for reaching out.

    In fact the “variations” concept does not exist in modern SharePoint and there is no straightforward strategy for having multilingual modern sites.

    We have – like you said – adopted a strategy that relies on content metadata, user profile preferences (user preferred language/SPS-MUILanguages) and some custom webparts/behaviors.

    In simple terms, the core features are:

    • Enable the out of the box language translations for the required languages (SharePoint will show the language defined in the user profile property) (this will automatically translate all the “system” labels for the language defined in user preferences)

    • the navigation menu (that is a custom extension) that shows the information structure for a given language – so when user navigates using the menu, it will land on the correct landing pages (you need to have copies of each page translated to the required languages) – You need to have n menu structure definitions (for each language)

    • a redirecting webpart that is used in key landing pages – that checks the current page language (metadata), the user language (user profile) and if they don’t match, redirect the user to the correct page (defined in webpart properties)

    • some search based content webparts that, in runtime, queries for the content in current user language

    We are planning to share some of these on github, but we still don’t have a date for that.

    I can share some helpful resources:

    • Custom navigation menu extension

    • Custom search webpart

    • Read user profile properties / SPS-MUILanguages

    We hope this can help you to understand a bit better our approach.


SharePoint Dev Weekly - Episode 25 - Office 365 Developer Blog · February 5, 2019 at 9:23 am

[…] SharePoint Online Multi-language Modern Sites – real case, pros, and cons – Luis Ribeiro (DevScope) […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: