Article
2 comments

Multilingual support review of SharePoint Online – An information architecture perspective

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.


<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.