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.
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.
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.
- Simple content management
- Unified content classification experience
- No over complex solution, not compromising the adoption of a future native SharePoint feature for multi-language
- 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