IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

Do Hub sites support MUI?

Spoiler: they do in part, but very very slowly.

SharePoint Online Targeted Release tenants are starting to get the new Hub Sites that were promised last September.

Hub sites are a way to organize different sites together, without a site hierarchy.  Hub sites are just ordinary sites, typically communication sites, that are designated as hubs.  You can read about search, rollup and inherited theme elements elsewhere.  For the purpose of MUI, what is important is that Hubs have an extra navigation menu, and this navigation menu is inherited by all the sites that are associated with the hub.

Sites that are associated with the Hub, let's call them Spokes, will get this extra navigation menu, but do not have the ability to edit this menu, only the Hub site can edit it.

The Hub navigation menu consists of two parts:  the Hub site display name and the navigation links.

     


The hub site display name defaults to the name of the hub site, but it can be changed by going to the Hub site settings in the gear menu.  Now the bad news: the display name does not support MUI.  It is invariant.

The navigation links can be edited on the Hub site by clicking on "Edit"

This is a multilevel menu, and is similar to other navigation menus on modern sites.  And like other navigation menus, this one is MUI enabled.  You can change your language and change the text of the the navigation menu in that language.

However this menu is more aggressively cached than other menus.  If you change your language preference, it can be quite a while before you see the correct language version of the hub navigation menu appear on the Hub site itself, and don't expect to see it appear on Spoke sites until the next day.


In fact, in the course of testing this, it fails to load the correct language version of the menu more often than not, even on the next day.  I will update this post if I figure out the pattern when it succeeds and when it fails.

Code Redundancy in SharePoint Online Software

 

One of the ways in which writing reliable software for SharePoint Online differs from previous versions of SharePoint is all the extra redundancy that has to be built in.  It's a little like writing software for a space mission, deployed in an environment where it can be subjected to many types of failure and must adapt.  Every action needs at least two ways of accomplishing it in case the first one fails.  It helps that one of our programmers did write software for NASA.

The biggest need for redundancy comes from Modern pages.  Classic pages and modern pages do not have the same API.  Any code that you put on classic pages cannot run on modern pages, and vice-versa.  Except when it does.  There are some cases where it is possible to execute code from a previous classic page when you are on a modern page.  We have gotten very adept at executing JavaScript on pages where that JavaScript is not present.

This is because SharePoint Online does not always fully load a new page, but rather it often simulates transitions from page to page without fully wiping out the current page DOM and page data in the browser.  These transitions, as well as the use of caching including caching of API calls, mean that some events that are normally triggered when loading a fresh page are not necessarily triggered when navigating to that page from another page.

In addition, some of the state information in the APIs is not necessarily correct; it might be a state that was cached from an earlier page even though the state has changed.  Add to that the asynchronous nature of so much of the API, where API calls can return in a different order, or with an error, or not at all, or worse still with missing or invalid information, and you need to build in a lot of fallback strategies.

Finally, Microsoft reserves the right to change master pages and other features unexpectedly, which makes a lot of software fail if it makes assumptions about page layouts or authentication, or even about the simple process of following a hyperlink.  Redundancy is required because changes can occur without warning.

Don't get me wrong, I love the new SPFx and the way that it can execute quickly, before most of the page appears, rather than waiting until the entire page is loaded before running your code.  It's just that you can't assume that it has done its assigned tasks properly, and you have to check on its work and be prepared to re-do it later on in the page life cycle.

Office365™ - office.microsoft.com IceFire Studios is a Microsoft Silver ISV Partner SharePoint™ 2013 - Microsoft.com