SharePoint Online for a long time, has multilingual support. On classic experience, there were language packs and Variations available for that. Yet also the modern experience has multilingual capabilities for that.
It might look that SharePoint is well capable of providing the language chosen by the user for the user. While I had to take a closer look under the hood over the last couple of month, multilingual and SharePoint has a complicated relationship.
For a better understanding, let’s take a quick view of how HTML documents in general handles languages and then let’s review what it means for design as well as accessibility. The way it is implemented now in SharePoint.
Multi-lingual in HTML
Documents such as Word, PDF, and others have mostly one primary language. The content of these documents written, for example, in English (en, en-US), German (de, de-at, de-ch), French (fr, fr-fr, fr-ch). In a Word Document, this defined for example, what language gets used for a spell- / grammar-checking.
Web documents also know as HTML pages have one primary language as well, and defined on the root of the document.
This HTML language definition, which hides in the source code, defines the language of the document.
While a developer can be sloppy and always use, for example, ‘en-US’ even if there is German content on the page, the so defined language would not impact the user the regular user that much. So why bother then?
The regular seeing user won’t be affected by this because it is just a meta-information for them, but it has indeed impact users with limited accessibility.
For visually impaired people that rely on assistive technologies, the correct language is crucial. It defines how the content will read by assistive technologies like text-to-speech language, for example. Léonie Watson has an excellent short article on using the HTML lang attribute.
That the language is on HTML elements is essential for readability is also mentions in the Web Accessibility Guidelines – 2.1.
Besides the accessibility benefit, it has benefits for other people too. The language defines how words potentially get hyphenated.
Here is one example of how language affects the text flow.
If you don’t see any hyphens in the text above, the this most likely the that there is a bug in you browser. The text would look normally like this: (to see full support check out caniuse.com)
While the German words in the English text block look and are technical, not wrong, but the German text block has a better reading flow, makes it easier for a user to read the content.
Now with the essential knowledge on multilingual in HTML set, we take a closer look into the implementation of SharePoint. So we compare the SharePoint implementation to typical web implementation.
Microsoft Word, by the way, has similar behaviour. You can define the base language of a document. Still, you can also specify, for example, a paragraph, or even a single word to have a different language than the rest of the document. It helps you with spell-checking a document too.
How SharePoint behaves with multilingual
Let us take a look at how SharePoint behaves in case of multilingual. For now, we focus on the base implementation that is available all across SharePoint, may it be a modern Team Site or Communication sites.
Every SharePoint page is at its core nothing else than an HTML document. This document should have a concrete language assigned.
Consider the following scenario; you create a new Team Site using English as the core language. You add all the content in English, for example, news, documents or additional pages. The assumption would be that the HTML language tag would always be the following.
Based on this the correct font renders, the built-in browser spell checking works correctly, hyphenation on long works optimised and let’s not forget Text-To-Speech uses the right language.
Communication Site behaviour
Sadly SharePoint follows a different behaviour on Communication Sites. The language defined for rendering the page follow the user’s preference, and leads to the problems mentioned before.
The previous picture shows parts of the page and what happens with the HTML tag, when a user with English language preferences comes to the page. The following image shows the same result with a user with a German language preference.
So even if the content is all English, the HTML language tells the browser otherwise. Not only is it wrong information but also breaks accessibility in this case.
Of course, the content translates to German, but the problem arises, when content gets added. There might be only English content on this site, but the browser still identifies it as English.
Team site behaviour
Team sites show the exact behaviour as Communication sites. The content rendered with the user preferred language too instead of the language defined by the content.
The HTML changed to “de-DE” even thou the content is in English. Not with the default configuration but once the content filled onto the site.
Design issues caused by this behaviour
Besides the wrong technical definition of the language of a site, this behaviour also causes a Design issue. It is not an obvious design issue and will only become eminent, for western languages, such as English or German.
It has an impact on languages such as Arabic, Japanese or Chinese. The browser detects and(/or) CSS define based on the HTML language tag which font to use to render the page. So the language has a direct impact on the readability of the content.
In the Japanese example, the system font “Hiragino Kaku Gothic ProN” gets used at least on a Mac. This behaviour is also the same on Windows but might use a different font.
What SharePoint should use instead, and this is new that all correct font definitions have removed from SharePoint overall, is the definition of Fluent UI, serving different web fonts for other HTML lang tags or languages.
This definition is far from optimal from a Design and Development perspective, which might cause performance issues. It is still better than have no definition overall.
While writing this blog post, SharePoint does not use any of these font definitions. It seems that SharePoint now renders without web fonts overall.
Over the past two months, I saw a version different version of fonts that in SharePoint. The most critical issue I have seen was that SharePoint rendered Segoe UI for a Japanese text, make the text unreadable because there is no Japanese optimised Segoe UI available and should exchange with the font defined in Fluent UI.
At one customer, I even had to fix the and overwrite SharePoint’s font rendering for Japanese to make the text readable.
Solution for Team Sites
It teams sites we can avoid this unpleasant behaviour. Like in the on-premises days SharePoint comes with all available Language Packs and language support configured for all newly created Team sites. This language support can be disabled.
The Settings > Site Information > View all site settings > under Site Administration > Language Settings, you will find the currently configured settings.
So all available languages are configured uncheck all languages and save it. Now SharePoint will render the page only in the primary language used during creation. Sure you won’t get some information translated automatically but it serves the content better and will not mix up English and German content in an unpleasant way.
Disabling multilingual support will also improve the accessibility in any case and text rendering in some cases.
Solution for Communication sites
A communication site is an entirely different story. By default, this site template behaves precisely like a Team Site. There is only one difference because this site template officially supports multilingual pages.
Unchecking the languages would have the same effect here. Enabling page translation might have the same impact here, but you have to select at least an additional language.
By doing so and don’t provide multilingual content, you might think that a page defined as English render the right language on an HTML level. Well, it still has the user language but not the content language on the page.
At least the content should be in German and have the right language assigned on the surrounding HTML element.
SharePoint sadly don’t behave this way and causing issues with accessibilities, text rendering and so on.
I searched the DOM structure up and down but haven’t found anything that would suggest otherwise.
So SharePoint don’t have multilingual support? Well, yes, from the perspective of an information architect, but it is not black and white here.
The only explanation I have for this behaviour is how you plan an application like SharePoint if you plan the information architecture as an application, multilingual works perfectly.
All menus and application content get translated depending on the language the user selected.
I would expect that my user interface would show “Folgen” in German instead of “Follow” and “Teilen” instead of “Share”.
Here is the catch-22, it behaves exactly like an application, but the user also creates content in SharePoint using a specific language. Would it act like a web content management system or information system, then the application support would come short.
So overall SharePoint supports a multilingual user interface but not multilingual content.
What needs to happen here, then? Remember the example I showed with the hyphenation previously? Ever section on a page can have its language definition, and this would be the solution.
The parts of the user interface, which are part of “SharePoint – the Application” would need to have the language definition of the user attached to it. HTML and the content need to follow the actual language.
On a communication page translated to German, this needs to be.
Even if all toolbars and menus get rendered in English, the same would be suitable for Teams sites as well.
So the Command Bar aka “Befehlszeile” in German would be rendered like this when it comes with the correct language.
Multilingual with the current implementation works for all “regular” user, but it could be improved in case of accessibilities by a lot, design and text rendering.
It would be nice to see that at least the multilingual solution would improve in the right way, because it only serves pages with content on it, without multilingual support.