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.
<html lang=”en-US">
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.
See the Pen Hyphenation Demo by Stefan Bauer (@StfBauer) on CodePen.14928
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)
Auto hypenated text in brower
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.
<br /><html lang="en">
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.
HTML language attribute on communication site
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.
HTML language attribute set to German on communication site
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.
HTML lang attribute on English Team site set to German, while content remains English
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.
English Team site translated to Japanese – Actual content will still be English not like with default web part
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.
Fluent UI font definition based neglected in SharePoint
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.
Disable translations to keep site in the main intended language – User won’t automatically switch anymore
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.
Disable translations on Communication site to maintain the main language
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.
Adding an additional translation language is also an option
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.
User language will be still used on the page instead of language of the page.
At least the content should be in German and have the right language assigned on the surrounding HTML element.
German content don’t have a specific langauge
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.
Verdict
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.
<html lang="de">
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.
How HTML should look like in SharePoint
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.
In classic sites, the “lang” element in the html tag was the base language of the site, not the language of the user interface nor the language of the content. I was very happy when modern sites at least made it correct for the language of the user interface. http://blog.icefire.ca/post/how-to-achieve-language-specific-styling-in-modern-pages
The other thing that became correct, in my opinion, is that the “dir” element correctly switched the page layout for right-to-left languages like Arabic, Hebrew, and Dari.
The problem, as you say, is when the language of the content does not match the language of interface, or part of the page is in a different language. That is already an accessibility problem. There is no point in having the language correctly identified for the screen reader if it is going to speak a language that the user doesn’t understand. The problem is with mixed-language pages, where the language of the content does not match the language of the interface. Again, in Classic the content editor webpart editor explicitly allowed you to specify the language of any part of the text, and that did put a “lang” element in the specified tag. How is SharePoint supposed to know the language of the webpart title or text? Add it explicitly to the text webpart editor menu, like in classic?
Isn’t it better to correctly match the language of the content with the language of the interface?
There are fixed parts of the so-called user interface which get translated those should match the user interface language, and these sections should get assigned to the language to which it has translated too. Like I mentioned.
The user interface is classic for Hebrew, Arabic and Dari, was correct when you choose the right language template out of the language packs. The dir tag was maybe not there, but the pages were completely mirrored as expected. I research those because I was keen to see how the language packs behave.
Mixed language pages are, like WCAG 2.1 stats, not a problem. The page lang attribute should be correct if you like to meet WCAG A, the pieces of the content should have the right language to fulfil a WCAG AA level. See: https://www.w3.org/TR/WCAG21/#readable
A language switch like it was in classic would help to be more explicit, but cognitive services, for example, could help. It has pretty good language detection.
I agree with you it would be the best scenario that the language of the content matches the user interface, but this is not the case. A German user would get a German user interface with English content on an English site. It would be correct if in this case, only the web core language recognized on HTML instead of the user language, which is pointed out in this article.