IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

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

Join us in Paris

IceFire is sponsoring the SharePoint Saturday Paris conference.  The conference is free.

On October 14, come join us at the Tour Montparnasse in Paris, and drop by our table for some maple candy and a look at our latest innovations, PointFire 365 v2.0 and PointFire Translator for SharePoint Online.

SharePoint Saturday Toronto

On Saturday, August 19, 2017, join us at SharePoint Saturday Toronto, at the Microsoft Canada headquarters, 1950 Meadowvale Blvd in Mississauga.

Come by our booth for some delicious pure maple syrup candy. Martin Laplante will be giving a talk entitled SharePoint, SharePoint Online, and multiple languages, what are the options?


Little-Known Setting to Vastly Improve Translation Quality

SharePoint has a machine translation service that can be used to translate certain documents and phrases.  Out of the box, it can be used by Variations to translate pages, and by the Managed Metadata Service to translate terms in the term stores.  Beyond that, it is available through the API, and PointFire products make use of it.

For the past several months, Microsoft has been introducing a far superior machine translation engine.  So far it is available in English, French, Arabic, Chinese simplified (Mandarin),  German, Italian, Japanese, Korean, Portuguese, Russian, and Spanish.

It is not automatically used unless you specifically configure the machine translation service for it.  Simply open a session in the SharePoint Management Shell and issue this commandlet:

Set-SPTranslationServiceApplication "Machine Translation Service" -MachineTranslationCategory generalnn

That's it!  In this case the service was named "Machine Translation Service". For examples of the old vs the new engine, see http://translate.ai 

SharePoint Online uses the old engine, and there is nothing you can do about it. I don't think you can configure the machine translation service for your tenant.  Maybe you can request it nicely or vote it up.

The Secret Language Setting

In addition to the well-known language settings that were discussed in an earlier post, there is a little-known language setting with a different set of advantages and disadvantages.  We call it User Properties.  To get to it, add "_layouts/15/regionalsetng.aspx?Type=user" to a web site URL in SharePoint Online or on 2013 or 2016.  You will see this familiar but subtly different page:


It's quite similar to the User Profile pages, but with some differences, some good and some bad.

Advantages:

  • The effect of a language change here are immediate.  There is no message saying that the changes may take some time to take effect.
  • You do not need to have counter-intuitive settings for your user profile and your Office 365 user settings like we do for the instant toggle trick.

Disadvantages:

  • The setting is site collection specific.  On other site collections, your previous user profile settings still apply
  • The setting page is usually not reachable through the menus, and some parts of it do not work.
  • While changing your user profile will also change your user properties, the reverse is not true.
  • Some software will still follow your user profile settings rather than your user properties.
  • The setting is not synchronized with Active Directory.
  • Once the user profile and user properties are no longer in sync, it is difficult to get the user profile to work correctly again.

How does it work:

What sets the user profile is the User Setting Provider.  Every web application has a User Settings Provider.  By default it's the User Profile User Settings Provider, and that's always the one used on SharePoint Online.  When you change your user profile, it's using the User Profile User Settings Provider.  However if you set up your web application with no User Settings Provider, then the personal menu takes you to _layouts/15/regionalsetng.aspx screen rather than to the user profile screen.

After the User Profile Settings Provider has changed its language setting, a timer job will periodically copy the profile setting to the user properties of all site collections.  This timer job typically runs once every minute, hence the delay between changing your language setting in your profile and having that setting take effect.

When you change your Office 365 account language setting, that new setting propagates in two major steps.  First it copies itself to the User Profile's Display Language setting, then up to a minute later the user profile setting is copied to the user properties of all the sites.  This includes MySite, which is what controls the language settings of the OneDrive for Business accounts.

If you are using PointFire on premise, PointFire's language setting mechanism overrides all three SharePoint language settings, so none of this has any effect, but for PointFire 365, PointFire's language toggle sets the SharePoint Online language settings, it does not override them.

Why are PointFire Add-ins SharePoint-hosted?

SharePoint Add-ins can be developed in one of two ways: Provider-hosted and SharePoint-hosted.  In general, Provider-hosted is easier to develop, easier to test, and easier to distribute, and has a more powerful API.  Provider-hosted can use any programming language and has easier access to data, but SharePoint-hosted can only use Javascript.  But all PointFire products on SharePoint Online use SharePoint-hosted.  Why?

The answer is your information security.  PointFire interacts with and can modify all of your pages and all of your documents and their metadata and your lists and your user profiles.  It needs a lot of access in order to make sure both your UI and your content are in the correct language.  If you use a Provider-hosted add-in, the data required for the add-in to work has to go off your site to a server that is controlled by those who developed the add-in.  The traffic is encrypted and your login is not shared, but it still means that you have to trust those developers to properly secure your data while it's on their server.

We chose the more difficult (for us) SharePoint-hosted model because none of your data and none of our code ever leaves your control.  There is no information, encrypted or not, going to our servers.  All your information stays on your SharePoint tenant or on your browser, as does all of our code.  It's more difficult, but it's worth it to protect your information.

PointFire Translator is out!

One of the components of PointFire 365 v2.0 is being released as a standalone product, available from the Office Store.

Add PointFire Translator, and in your document menu and in your ribbon you can choose a document and have it machine translated in all of your site's languages.  But it doesn't just translate the document, it also translates the text metadata including the title.  It also works on pages, list items, calendars, tasks, etc.

Translation quality is quite good.  It uses Microsoft's state of the art deep learning powered machine translation.  Of course it's always a good idea to edit and approve translations that are created that way.

If you also have PointFire 365, it really shines.  It sets PointFire 365's language metadata columns, so list and libraries are immediately filtered according to the user's language and pages are automatically redirected.

Variations are not required, all of this gets done in the same library, and if you're using PointFire 365, at the same URL.

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