IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

New product releases for SharePoint Online and SharePoint 2019

PointFire Power Translator is Released 

9 months ago we showed how PointFire Power Translator can be used to translate modern SharePoint pages. Nothing else does this. It uses the latest neural network translation engines, not the old Bing engine.  Thanks to all the beta testers, the final product is simpler to install and easier to use.
 
It's still command-line, but the GUI version, integrated into SharePoint, is coming out in beta this month.

Download free trial



PointFire 365 v2.2 update
 
The latest version of PointFire 365 for SharePoint Online has simpler installation and licensing, better support for mobile, and improvements in Manage Variations and in date/number formatting.
 
The PowerShell scripts for provisioning and upgrading have been enhanced.


PointFire 2019 is coming!

SharePoint 2019 is coming, and PointFire 2019 will not be far behind.  It has all the features of PointFire 2016 and more!  Support for modern sites and improved interface translation are going to be among the new features.  If you would like to get access to beta versions before everyone, contact sales @ icefire.ca

Come see us in a city near you


We are continuing to sponsor SharePoint shows throughout the world.  Come see the latest PointFire tools in person!  If you're in Belgium, we're sponsoring the free event SharePoint Saturday Brussels on Oct 20, 2018.  We're sponsoring SPS Ottawa on November 10, and SPS Detroit on December 8.

The European SharePoint Conference is November 26-29 in Copenhagen, and our CEO Martin Laplante is giving a non-commercial talk about multilingual features of SharePoint Online. Come hear the talk and visit our booth.

Modern Sites Will Let You Choose Site Language: Why It's Not A Big Deal

For the past two years, when you were creating a new modern Team or Communication site, SharePoint would not let you specify the language of the site.  This was unlike classic sites, when the language could always be chosen.  But soon in Targeted Release, the modern site creation dialog will include "Select a language" with a dropdown of 50 languages.  How useful is that feature?

Not very useful.  This is because classic sites and modern sites are different, and modern sites were never very language specific, unlike classic sites.

Modern sites get created with MUI and all alternate languages activated

In classic sites, when you create a site, it has a default site language and no other language.  If you want to use the MUI (multilingual user interface) you have to install language packs (if on premise) and then activate the alternate languages that you want on every site, then make sure that users have their language preferences set.

In modern sites, all of the alternate languages are already set when the site is created.  Setting the user language in the user profile or in the browser is still as troublesome as ever but, since organizations with Office 365 tend to have one global tenant, where before they would have had many regional server farms, there is a greater possibility that users will have set their language preference that differs from the default language.

When alternate languages are set and user language settings are set, then the MUI springs into action, displaying the site's MUI-enabled UI elements in the user's language rather than the site language.  That includes out-of-the-box navigation, and names of lists, libraries, columns, etc, and almost all menus.

There are no Variations

For Classic sites, the site default language had to be set if you wanted Variations to work.  Each Variation label needed to have a different language-region combination.  Each one of them had a fixed site template which only needed to work in that label's language, while Variations deposited content into that fixed site template container.

But Modern sites do not support Variations, and never will.  So that reason for having a site language does not apply.

Modern site templates are mostly language-independent

Classic sites had lots of language-specific text in their templates.  That meant that the MUI never quite translated the entire interface, because a lot of strings were hardcoded in the template.  But modern sites have a lot less that is language-specific.

For example, if you create a new modern site it will have a sample Hero webpart in it, which comes with a lot of sample text like "Welcome! Click Edit at the top right of the page to start customizing" or "Make an impression", "Share your strategy", and so on.  Now change your profile language and reload the same page.  If you haven't changed the Hero webpart yet, then entire text of the Hero webpart will switch to the new language.  The Hero webpart template is not language-specific. This is discussed in How Much Multilingual Support Do SharePoint Online Communication Sites Have?

The same thing happens for most out-of-the-box modern webparts, apart from the odd bug which will be cleaned up eventually.  Similarly for dates: date formatting in modern webparts that have dates by and large follows the language of the user, unlike dates in classic webparts.

The only major difference when you create a modern site in a different language is that the URLs and internal names of standard lists an libraries, like "Shared Documents" and "Site Assets" will be created in the language of the site.  The title that is visible to users will change according to the user's language, so it will always be called "Site Assets" in English, while it is called "Éléments du site" in French, that is just the MUI doing its bit, but the name that is visible to programmers will be different.  That is more of a hindrance than a help, programmers have to deal with the fact that the list/library URLs are not fixed.

So what do you gain when you use this new SharePoint Online functionality?  Not much, really.  If you're a programmer it is helpful to test what happens to your customizations and apps if someone installs them on a tenant whose default language is different from your own, but for normal use, it doesn't change anything.

What would be nice would be if developers would routinely follow guidance about making custom webparts and customizations language-independent.  It is possible to localize SPFx webparts if you really set your mind to it, but it requires extra effort since the process is quite involved.  It's not as simple as using .resx files, but the principle is the same.  Then it won't matter what is the language of the site, the entire UI, including the UI of the customizations, will be language-independent.

It's official, Variations are a deprecated feature

SharePoint 2019 public preview is out!

It brings most of the SharePoint Online experience to the on-premise environment.  But as a follow-up to the announcement 4 weeks ago about the retirement of the machine translation service and possible end of Variations, in SharePoint 2019 the list of deprecated features includes this:
  • Machine Translations (and Variations)
    The Machine Translation Service will remain supported, but deprecated, for the SharePoint Server 2019 Public Preview release.
This is the second shoe to drop from the Variations centipede.  This means that the Machine Translation Service is still there in SharePoint 2019 and they will repair it if it breaks, but no new features will be developed.  Among the features that will not be developed is the ability for modern sites to participate in Variations, and for modern pages to be translated using the Machine Translation Service.  And since "Classic is dead like Latin" you can expect all new features to be produced as Modern pages and to have less and less of SharePoint supported by Variations before the plug is finally pulled.

Some people are saying Microsoft wouldn't drop these essential features without a replacement.  The SharePoint 2019 announcement does not suggest any alternative for those that need the feature.  The SharePoint Online deprecation announcement does suggest investigating the Bing translation APIs, but that suggestion simply will not work.  I will spare you the obligatory ad, you know where to find the one alternative to Variations.

Machine Translation Service, Variations are on the way out

A few days ago, Microsoft made the following announcement:

Update for Machine Translation Services from SharePoint Online
MC143381
Plan For Change
Published On : 28 June 2018
Action required by
We will be removing the user interface entry point for Machine Translation Services from SharePoint Online, beginning September 2018.
How does this affect me?
With this change, your organization will no longer be able to perform manual, on-demand translation service activities in SharePoint Online. This change will affect your user’s ability to create new variation labels in order to schedule translation activities or workflows. The update will not affect your user’s ability to leverage Multilingual User Interface (MUI) capabilities in SharePoint Online or its related APIs. Also, it will not impact any previously created variation labels or the ability to schedule translation activities or workflows based on previously created variation labels. After this change is made, your users will not be able to create new variation labels.
This sounds the death knell for machine translation of Variations, and probably Variations itself.  Already, modern sites like Communication sites and Team sites cannot use Variations, and the Machine Translation API does not work on modern pages.  When this announcement says "your users will not be able to create new variation labels", it is referring to classic sites.

The only remaining alternative for multilingual sites in SharePoint Online will be to use PointFire 365 and PointFire Power Translator, which work on modern sites and pages, including modern communication sites, because they don't rely on Variations or the Machine Translation Service.

The announcement also says "Instead of using on-demand, manual translation services, we recommend your organization use Bing translation API’s."

Why don't you try that?  The rest of us will wait here.  And by the way it's now called the Microsoft Translator Text API.  You're back!  All sorts of error messages?  Come back when you've done all the buffering, parsing, and escaping to have it run error-free.  Back again?  And hardly anything translated?  Yes, most of the text on the page isn't in the aspx file in translatable form.  You need to use PointFire Power Translator, no other Microsoft or third party tool does it.

Update: see this discussion about what this announcement meant about "your users will not be able to create new variation labels.https://techcommunity.microsoft.com/t5/SharePoint/SharePoint-Online-Variations-alternative/td-p/212239

Is there Persian (Farsi) language support for SharePoint?

SharePoint sometimes has separate language packs for several variants of closely related languages, like Brazilian and European Portuguese, or several varieties in the Serbo-Croatian family of languages.  In other cases, you have to live with a different variant of your language, so for instance people in the UK must use the American flavour of English with American spelling and vocabulary, and Flemish-speaking Belgians must use Dutch, with all its differences in vocabulary.

For Persian, the language spoken in Iran, there is no direct support.  However in SharePoint 2013 and 2016 and in SharePoint Online, you do have the option of selecting Dari.  Dari is a language of Afghanistan, the native language of about 20% of the population.  It is also known as Dari Persian, Afghan Persian, and simply Farsi.  Although the spoken version sounds quite different from Iranian Persian spoken in Tehran, the written language is nearly the same.  Download the SharePoint Dari Language Pack and use it instead of Persian.

For languages where SharePoint supports a slightly different version of the language that you want, PointFire gives you the option in a lot of cases to override specific text from SharePoint's language packs and use your different text instead.

Join us in Las Vegas

On May 21- 23, 2018, come celebrate the return of the SharePoint Conference in Las Vegas!  Co-produced by Microsoft, this event features top names from Microsoft and top experts from the world of SharePoint, OneDrive, and Office 365.

Come visit us, we're at the rightmost entrance to the Marquee ballroom as you make your way to the food.  Also watch for our video in the registration area.


We are thrilled to announce the world renowned B-52s will headline at SharePoint Conference North America - Join us for Burgers and Brews with a special performance by The B-52s at an exclusive super-sized poolside SharePint party at the MGM Grand.  Attendance is included with your conference pass and restricted to attendees only. 

 

It is well known that the B-52s are The World’s Greatest Party Band. And nearly forty years and over twenty million albums into their career, there can be no doubt as to why they remain one of rock music’s most beloved and enduring bands.

 

From groundbreaking songs like “Rock Lobster,” “Dance This Mess Around” and “Private Idaho“ to chart-topping hits like “Love Shack” and “Roam” and “Deadbeat Club” the B-52s’ unforgettable dance-rock tunes start a party every time their music begins.

 

Join your fellow SPCNA attendees for an exclusive party poolside to eat, drink, and rock out to the incredible B-52s. 

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.

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.
Office365™ - office.microsoft.com IceFire Studios is a Microsoft Silver ISV Partner SharePoint™ 2013 - Microsoft.com