Welcome back to Going Multilingual in Sitecore. In this part of the series, we’ll look at how to restrict access to content authors by language. If you are just joining us, please go back and read the introduction where you’ll also find links to each other part of the guide.
By default content authors have the ability to author and publish content for all languages installed in Sitecore. Any time a new language is added, it appears in the language dropdown and the publish dialogs automatically.
It may be desirable to restrict access to authoring and publishing for installed languages. These restrictions can be set using the role manager, user manager, and security editor tools in Sitecore.
First we want to create a new role that will allow editing in each of the installed languages. Open the role manager and click new. Enter the name for the new role and click OK.
Next we will use the security editor to set the language permissions. Click the columns button and check the box next to “language read” and “language write” then click OK. This will show the relevant columns and allow us to make our changes.
Click the account button (person icon) in the upper left corner of the security editor window. Search for Everyone. Select the role sitecore/Everyone and click OK.
Expand System -> Languages and notice the sitecore/Everyone role has access to edit all languages by default. The languages folder is set to allow language read and language write. The children are set to inherit permissions.
We want give the sitecore/Everyone language read and language write access to the English language only and deny language read and language write to the languages folder. Any other installed languages will inherit the permission from the folder if not explicitly set.
Open the account dialog again and search for our newly created role for our installed language.
Give this role language read and language write permissions for the installed language.
Notice the UI is updated to remove references to the installed languages including the version dropdown and the publish dialog.
You can allow editing and publishing in the installed languages by assigning the newly created role to specific users as necessary from the user manager. Find the user you want to edit and double click. In the edit user dialog, select the member of tab and click the edit button. Search for our newly created role. Select it from the list on the left and click the add button. Click OK to close the dialogs and update our user information.
Security settings (roles and permissions) are applied automatically, even to logged in users. Users do not have to log out to before updated permissions take effect.
Note that any content a user can manage based on other assigned roles, they will be able to manage in the installed language. If you need to restrict language access to specific areas of site or pages, you can create other more restrictive roles or update a users permissions directly.
Be sure to follow me to get notices about updates! Thanks for reading, and be sure to leave me comments or questions, I would love to chat with you about Sitecore.
Hey Eric,
This is a great guide, thanks for sharing. I’m wondering if you’ve ever come across the following issue, and how you solved it:
We have a multi-lingual site, with Global English as the fallback language for all regions. We have regional authors who have access to author content in only their local languages. They can create new items in special data sections dedicated to their regions (eg: news articles, career listings, etc), and can create language versions of global content items (eg: main site pages). However, visitors to the site have the ability to browse all content on the site, including content that may be written in a different language to the one the visitor is browsing in.
We do not wish to give local authors (for example, Australian authors who have write access to en-au) the ability to author global english (en) as this will enable them to change the global website content, which should be locked down to global authors only.
However, if we don’t give them that access, then they can’t create global english versions of their items, and visitors will get errors when browsing to their items in another language (eg: https://website.com/en-uk/australia/news-item would fail as the item only exists in en-au).
With the language read and language write settings being a single toggle for the entire tree, I see no way of providing language write access (eg: global english) to only certain parts of the site tree (eg: in the local authors’ content areas) but preventing it in other areas (eg: the global content area and main site tree).
Have you ever come across this conundrum before, and how did you resolve it?
Thanks heaps
Greg
Hi Greg. Thanks for the question! I would solve this problem using the granular permissions in Sitecore.
I would leave english as the only default language assigned to any existing user groups. Then create a user group for each type of access you want to give. These groups can be locked down to region of the site AND languages. So you could create an Australia group that can only author the en-au portion of the site in english and another language. You can have another group that can edit the global site in any language. You can have a third group that can edit the global pages in english only.
Then you can assign the correct group to individual users and the combination of permissions will be applied to their account.
I hope that helps! Feel free to message me again here or find me on twitter @eric_sanner.
Hi Eric,
Thanks for your response.. We ended up solving our problem by introducing another language (which we called Master English). We then set Global English to fallback to Master English, and local languages to fallback to Global English. This gave us the ability to allow all regional editors to create content in a common language (Master English), resulting in content they create being viewable in any language, while at the same time providing our global authors the ability to author content in a language dedicated to them (Global English) which local authors could not change.
Essentially, we created a new language for the Global Region, but had all local languages fall back to that one first (so that content in the site tree had a common fallback) before falling back to the ultimate fallback language – Master English.
It’s pretty complicated, and definitely quite a unique use-case, but in this case this solution worked well for us.