IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

How to Achieve Language-specific Styling in Modern Pages

For on-premise SharePoint and to a lesser degree for Classic sites in SharePoint Online, there were several possibilities for language-specific styling.  The page is being displayed in Finnish?  You're going to need more space or smaller print.  Arabic? Things are different in right-to-left, and the fonts are different.


If you're more adventurous, you can use one of the existing language-specific locations for the css that SharePoint provides.  That requires access to the file system.  Not possible in SharePoint Online, and not recommended elsewhere.

For solutions, if you're using publishing and the Design Manager in SharePoint, and a few other cases, you can use language-specific folders in the Style Library.  Those are usually already created for you, and they use the magic "~language" token but it's added for you; just notice the folder names like en-US and de-DE when you originally go to change the css file and reproduce them in the folder that you create.



Sometimes those techniques don't apply and you have to figure out the current language at run time.  In most cases, you can find it in javascript using _spPageContextInfo.currentUICultureName , which is the currently selected language of the UI.  Note, this is not necessarily the same as the web site language, nor the user's regional settings.  It is specifically one of the site alternate languages agreed upon by the site and the user, in which the UI is being displayed.

So if the navigation or site name is being displayed in a particular language, you can style the display of those html elements according to the UI language.

None of this works for Modern pages such as the ones on SharePoint Communication or modern Team sites.  You don't have access to the master page, nor to CSS files and there is no AlternateCSSUrl property.

There is also no _spPageContextInfo object for your javascript to use.  There is an analogous spPageContextInfo object, but it's only available within specific SPFx contexts, and disappears outside those contexts, which might not apply to what you are trying to style or might be a massive inconvenience to implement.

However the new modern pages have a new feature: the html element now correctly  identifies the language of the page.  In older versions of SharePoint, the html element always declared the language attribute as the language in which the site was created, not the current language of the user.  In modern pages, it's the language of the UI.

By having a correct language setting, we can now turn to the wonderful CSS :lang() pseudo-class selector.  The lang attribute is set hierarchically, so everything on the page has that property unless you override it.  You can therefore define CSS styles that apply only when a user of a particular language views the page.


Unfortunately, that only applies to modern pages, and not even all modern pages.  For other pages, JavaScript and the _spPageContextInfo.currentUICultureName value works.  If you have another trick that works, I would love to hear it.

How Much Multilingual Support Do SharePoint Online Communication Sites Have?

Do SharePoint Online modern sites support multiple languages?

Usually in SharePoint Online classic sites there are two types of multilingual support.  One is Variations, where you have different sites for different languages and users are sent to one site or the other depending on their language preference.  Modern sites, including modern Team sites and Communication sites, do not support Variations.  One of the components of Variations is the Machine Translation Service, and that is also available programmatically.  But point it at a page on a Communication page and it will die with an error message.

Not only do modern sites not support Variations, but neither Communication nor Team sites even let you choose the language of the Communication site that you are creating.  It will always use your Office 365 account language setting (Note: not your profile setting, your account setting)

However they do support the Multilingual User Interface (MUI) to a large extent, albeit a little differently from classic sites, and Communication and Team sites do it a bit differently from each other.

When you first create a Communication or Team site, if you check the Site Settings -> Language Settings you will notice that every single Alternate language has already been selected.




That means that if you change your SharePoint language setting you will see a lot of the components of the site in the newly selected language.  Note that on modern sites the language settings are a little more difficult to find than in that article and the language change is slow, but that is for another post.  In a fresh site, you will see even more of the site in your language than on a classic site.  That is because, unlike classic sites, newly created Communication and Team sites don't have a local copy of the site template.  The example home page, with its sample Hero webpart or its sample News webpart, doesn't reside on the site, it's just a pointer to the template, at least until you change something, and only then you get a local copy.  That's probably part of the reason why site creation is so fast.  If you change your language setting before changing anything else, you will see the site using the site template in your own language.  Change one character and it's permanently in that language, because now it's a local copy.

The MUI can be used like on classic sites to change language-specific column names, navigation, etc, with a few exceptions.  Changing the site title in other languages does not work in Communication sites, or rather it works only briefly.  If you change the site title in another language, it appears to be changed, but refresh the page a few seconds later and it has reverted to the title in the original language.  Changing the site title does work on Team sites.

On Team sites, some text on the site menu and in the personal menu do not change language until the next browser session.  


This bug is found on Team sites but does not affect Communication sites

As opposed to classic views, Communication and Team sites modern webparts show dates in a reasonably localized way.  Typically in a classic site if you change your language, the formatting of dates, including the names of days and months does not change to match your language.  It only changes if you also change your regional settings and make them override site settings.  But the new Event webpart has reasonably good localization of dates, it's just a little off with its time formatting.


When you insert events using the Events webpart, the calendar and other date-related display and editing functions follow the user language.  On the same site, look at the event table on which this calendar is based in classic mode and you will see the mismatch between the language of dates and the user language.

On team calendars on Team sites, things are a bit different because the Group Calendar webpart keeps its events in Outlook, not in SharePoint.  In fact it gets a bit confused because of the different way in which SharePoint and Outlook handle languages, and because Outlook has an independent language setting, but the webpart still does a good job at localizing the date and time to the current language.

However on modern sites the content will all be in the wrong language and right now there is nothing that you can do about that <ad> other than to use PointFire to make SharePoint Online sites multilingual.  It solves the content problem, the Variation problem, and the machine translation problem, as well as having a language toggle that doesn't make you wait several minutes for your language change to take effect </ad>.

There are also a couple of instances where having a lot of alternate languages turned on by default interferes with normal  functionality.  For instance, you can't change the site title even in the original language when there are a lot of alternate languages, they have to be turned off.  Also, you have to turn them off to apply a custom theme.  Growing pains.

Finally, what does Microsoft itself intend to do about this lack of multilingual support? There is very little information about this.  We only have the following few words on a dense slide from Ignite in September 2017.


The words "multi-lingual support for Pages" without a target date are all the information that is available right now from Microsoft.  However from early September 2017 to early January 2018, existing multilingual support for the translation of pages was broken, and no one in the world other than users of PointFire Batch Translator was able to translate pages on any SharePoint Online site, so waiting for Microsoft to provide a solution may not be the lowest-risk option.
Office365™ - office.microsoft.com IceFire Studios is a Microsoft Silver ISV Partner SharePoint™ 2013 - Microsoft.com