SharePoint Online Multi-language Modern Sites – real case, pros, and cons

Intranets and digital workspaces 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.

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

In the modern SharePoint experience, there isn’t – at least 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 worth the read, 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, and their pros and cons.

A multi-language modern site approach

A few notes (not exhaustive) about our scenario:

• Users are from multiple countries and speak different languages;
• Some content needs to be secured/restricted by the user’s country of 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 must be manually translated/managed;

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 used English as the default site language and enabled the other languages in the Site Settings > Language Settings option.

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

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 are centralized and managed in one place by the designated owners, assuring consistent metadata across all organization content.

Content security control

In a multiple site collections structure, the user access & permission’s governance is 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 removing a user from a SharePoint group and adding it to another – 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 their own language preferences/properties given by the user profile “My display Languages”. Depending on the chosen language, the SharePoint user 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, 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 is 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 is not an issue, you can have a flat page structure organized with metadata. Using views to manage the content;
• Subsites – you can also use subsites for each language, we did not use this one.

Navigation

We implemented a dynamic tenant-wide menu reliant on on user language. The menu options and addresses changes with user language. Once 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 content in their language and have a unified navigation experience across all sites.

We also created a redirect mechanism to use in the site’s root page. When users access by direct site URL, we can redirect them to the right language/page.

Custom web parts

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

Putting the pieces in place

By 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 through content in their language.

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

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

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

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

The pros

• Simple content management;
• Unified content classification experience;
• Not an over-complex solution and doesn’t compromise 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);
• A custom solution to redirect users in some scenarios – degrading user experience;
• Requires some additional configuration across sites;

If you wish to leave any feedback or ask some questions, feel free to comment!

Sharing is caring