IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

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.

How Much Multilingual Support Do SharePoint Online Communication Sites Have?

Do SharePoint Online modern sites support multiple languages?

Usually in SharePoint Online classic sites there are two types of multilingual support.  One is Variations, where you have different sites for different languages and users are sent to one site or the other depending on their language preference.  Modern sites, including modern Team sites and Communication sites, do not support Variations.  One of the components of Variations is the Machine Translation Service, and that is also available programmatically.  But point it at a page on a Communication page and it will die with an error message.

Not only do modern sites not support Variations, but neither Communication nor Team sites even let you choose the language of the Communication site that you are creating.  It will always use your Office 365 account language setting (Note: not your profile setting, your account setting)

However they do support the Multilingual User Interface (MUI) to a large extent, albeit a little differently from classic sites, and Communication and Team sites do it a bit differently from each other.

When you first create a Communication or Team site, if you check the Site Settings -> Language Settings you will notice that every single Alternate language has already been selected.




That means that if you change your SharePoint language setting you will see a lot of the components of the site in the newly selected language.  Note that on modern sites the language settings are a little more difficult to find than in that article and the language change is slow, but that is for another post.  In a fresh site, you will see even more of the site in your language than on a classic site.  That is because, unlike classic sites, newly created Communication and Team sites don't have a local copy of the site template.  The example home page, with its sample Hero webpart or its sample News webpart, doesn't reside on the site, it's just a pointer to the template, at least until you change something, and only then you get a local copy.  That's probably part of the reason why site creation is so fast.  If you change your language setting before changing anything else, you will see the site using the site template in your own language.  Change one character and it's permanently in that language, because now it's a local copy.

The MUI can be used like on classic sites to change language-specific column names, navigation, etc, with a few exceptions.  Changing the site title in other languages does not work in Communication sites, or rather it works only briefly.  If you change the site title in another language, it appears to be changed, but refresh the page a few seconds later and it has reverted to the title in the original language.  Changing the site title does work on Team sites.

On Team sites, some text on the site menu and in the personal menu do not change language until the next browser session.  


This bug is found on Team sites but does not affect Communication sites

As opposed to classic views, Communication and Team sites modern webparts show dates in a reasonably localized way.  Typically in a classic site if you change your language, the formatting of dates, including the names of days and months does not change to match your language.  It only changes if you also change your regional settings and make them override site settings.  But the new Event webpart has reasonably good localization of dates, it's just a little off with its time formatting.


When you insert events using the Events webpart, the calendar and other date-related display and editing functions follow the user language.  On the same site, look at the event table on which this calendar is based in classic mode and you will see the mismatch between the language of dates and the user language.

On team calendars on Team sites, things are a bit different because the Group Calendar webpart keeps its events in Outlook, not in SharePoint.  In fact it gets a bit confused because of the different way in which SharePoint and Outlook handle languages, and because Outlook has an independent language setting, but the webpart still does a good job at localizing the date and time to the current language.

However on modern sites the content will all be in the wrong language and right now there is nothing that you can do about that <ad> other than to use PointFire to make SharePoint Online sites multilingual.  It solves the content problem, the Variation problem, and the machine translation problem, as well as having a language toggle that doesn't make you wait several minutes for your language change to take effect </ad>.

There are also a couple of instances where having a lot of alternate languages turned on by default interferes with normal  functionality.  For instance, you can't change the site title even in the original language when there are a lot of alternate languages, they have to be turned off.  Also, you have to turn them off to apply a custom theme.  Growing pains.

Finally, what does Microsoft itself intend to do about this lack of multilingual support? There is very little information about this.  We only have the following few words on a dense slide from Ignite in September 2017.


The words "multi-lingual support for Pages" without a target date are all the information that is available right now from Microsoft.  However from early September 2017 to early January 2018, existing multilingual support for the translation of pages was broken, and no one in the world other than users of PointFire Batch Translator was able to translate pages on any SharePoint Online site, so waiting for Microsoft to provide a solution may not be the lowest-risk option.

Communication Sites: How To Make Them Multilingual

In summer 2017 SharePoint Online added a new site type, Communications sites, and ever since they have released more and more functionality for them.

Communication site are a new and simple way to share information with colleagues.  The authoring experience is very slick and visual, and gives immediate feedback.  You know how list and libraries now have a "modern" alternative experience?  Communication sites extend that new experience to sites, pages and webparts.  It's not just a surface change, the foundation underneath is completely new.  Modern webparts have little in common with the classic ones and the technology is completely different.

In building a "modern" experience, one thing that has gone by the wayside is multilingual functionality.  There is no Variations, no machine translation, and the MUI only partially works.  The only way to have a multilingual Communications site is to use PointFire.  And PointFire really delivers, it is easy and fun to use.  Just look at this video.


If you've used other versions of PointFire, either on premise or SharePoint Online, the language toggle works the same way: you select a language in your personal menu, and when your language preference is changed, you will see the entire page in your new language, both the interface and the content.

When you look at lists or libraries, only the items that are in your language are visible to you, although all language-specific versions of the content reside in the same list or library.  Same for modern webparts.  Like for classic webparts, any modern webpart can have a language associated with it, the language(s) in which it will appear.  A page can contain a webpart that only appears in English, one that only appears in French, and one that only appears in Dutch.  Alternatively, you can have different localized pages, each having a localized webpart, and the one you see is the one in your language.  Like in other versions of PointFire, list view webparts are filtered by language, both in classic and modern experience.  And for both classic and modern experiences, all localizable elements of the user interface are put it a list, machine translated, and, after you confirm the translations are correct, applied to the site.

Perhaps the most exciting news about this impressive multilingual capability is the brand new PointFire Batch Translator.  It also works on Communication sites.  Nothing else does; the internals of Communications sites are quirky and undocumented.  SharePoint's Machine Translation Service uses the old Bing translation engine, but PointFire Batch Translator uses the latest deep neural network models.  For Asian languages than means good quality translation, not virtual gibberish.  You can compare the two on the translate.ai site.  Unlike the Machine Translation Service, translation is not delayed or throttled.  It's scriptable using PowerShell, and it supports many other document types, including Excel, PowerPoint, and PDF.

The Batch Translator is available in beta right now.  If you would like to try it, contact sales@icefire.ca  All other functionality mentioned is in the official release of PointFire 365.

PointFire 365 v2.0 is released

Nearly 3 years ago, we put together a roadmap for what we wanted to see in a SharePoint Online version of PointFire.  Today, we deliver the last of the features on that original roadmap.

At the time of the original roadmap, several of the features were technically impossible.  Today, some of the features are still impossible, but we implemented them anyway.  The software changes the time zone over and over until it time travels to when Microsoft supports these functions.

As SharePoint Online expanded its programmability, more and more became possible, and after a few false starts and several months of beta testing, version 1.0 came out over a year ago.  It was only the major features and some were slow or limited, but it found several takers.  Versions 1.1 and 1.2 covered more and more ground.


Version 2.0 has several major new features.  One of them is the instant language toggle.  This is one of the impossible features.  It is not possible to change your language quickly, it should take a few minutes for the language change to take effect. But PointFire has a little spinner animation that implants a hypnotic suggestion that the language has already changed.  It won't work if you don't stare at the spinner animation but no one can help it.

Another feature is a rich set of PowerShell scripts to provision and manage PointFire features.  PointFire is an enterprise solution, and entreprise solutions need this.

The big new feature is translation of the user interface.  It's as simple as 1, 2, 3.

1) Scour the site for translatable text elements and puts them into the Multilingual Translations list
2) Machine translate the text to all the site's languages.  In addition to machine translation it also looks up built-in translations and translations coming from the top level site's translations list.  You can check the translations list before and after the machine translation.
3) Apply those translations to the interface

UI translation covers the following elements

  • Site names and descriptions
  • List/Library/Calendar names and descriptions
  • View names
  • Column names and descriptions
  • Content type names and descriptions
  • Most types of navigation
  • Custom Actions
  • Selected webpart names
All this in addition to the existing features, webpart visibility by language, filtering of lists, libraries, and calendars by language, language filtering of content search webparts, and machine translation for documents, list items, pages, and events, including translation of all text, richtext, and html metadata.

Coming up in the next few weeks: PowerShell scriptable machine translation.  This uses the new neural translation engine, which is much better than the previous machine translation engines, and in addition to text, html pages, and Word documents, it handles PDF, Excel, and PowerPoint.

Also in the pipeline, version 2.1 is coming in a few weeks will have support for modern lists, libraries, and pages, including the new Communication sites.  Stay tuned!


European SharePoint Conference, Dublin Nov 13-16 2017

We're sponsoring #ESPC17 - November 13-17 in Dublin. Use code ESPC17SP & get a 10% discount. Click on the banner


http://bit.ly/1SnX9tr
Office365™ - office.microsoft.com IceFire Studios is a Microsoft Silver ISV Partner SharePoint™ 2013 - Microsoft.com