IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

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.

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. 

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

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.

SharePoint Online Language Settings & the Instant Toggle Trick

This series of posts is based on my talk about Language & MUI in SharePoint 2016 & O365

Different components of the Office 365 suite have different ways of setting language.  Even within a single page, different parts of a page can be in different languages because they are government by different settings.  In this post we will talk mostly about how the user’s language is set for the purpose of MUI in SharePoint 2013 and 2016 and in SharePoint Online and other SharePoint-like components like OneDrive for Business.

Alternate languages

Every SharePoint site and Sharepoint-like site has one site language and zero or more alternate languages.  In a normal site, or in OneDrive go to the gear menu -> Site Settings -> Language settings (under Site Administration).  Sometimes it is not in the menu, so instead edit the URL to add “_layouts/15/muisetng.aspx”.  For Group sites, those created by the Group feature, you don’t need to do anything, the sites are created with every language already selected.

In on-premise, the list of potential Alternate languages is determined by the SharePoint language packs that you have installed on the server farm, but in Office 365, all language packs are already pre-installed.

Select the list of languages that you want to be available for MUI on this site.  In another post, we will see how to select the languages using PowerShell.

What sets the user’s MUI language

When alternate languages have been selected for a site, it is possible for different users to see many elements of the user interface in different languages.  The language choice applies to that user only.

There are three major settings that determine the user’s MUI language once the alternate languages have been selected: the browser settings, the User Profile display language settings, and the Office 365 Account language setting.

Browser language settings

Your browser language settings are the lowest-priority setting, and will work for most of SharePoint only when the other two settings do not have a valid value.  I won’t go into the details of how to set your browser’s language preference, but it’s a ranked list.  Your browser communicates to the SharePoint server what is its first, second, third choice, etc.  The first one that matches the site or alternate languages for the site is the one that gets selected.

Note that the list of languages that you can select in your browser doesn’t match the list of languages that SharePoint supports.  The browser lets you select a general language like English (en) or a more specific one like Australian English (en-AU), while SharePoint only supports American English (en-US).  Don’t worry about it, SharePoint does a pretty good job of matching that language to the language it supports.  For languages where SharePoint supports different versions, like Portuguese or Serbian, it will choose the version that you specify if both are available or the one that the site supports if the site only supports one.

Although it’s not the best way to select your language, there are several reasons why you might use the browser settings.  Certain other Office 365 components only support browser settings.  There is at least one component of SharePoint, having to do with the caching of Managed Metadata, that only works properly when the browser setting is set, and it can be used for the “Instant Toggle Trick” that we will see below.

User Profile language setting

In both SharePoint on premise and SharePoint Online, the user can have a user profile where their language preference is stored.  Navigating to a screen that lets you edit this settings may differ depending on how user profiles are managed in your case, but here is the most common location.

Click your name or picture at the top of a SharePoint screen, then select About me.  In SharePoint on premise it will bring you to you’re my site, in Office 365 it will bring you to Delve.  Click “About me” then click “Edit profile”

In SharePoint on premise, on the Edit Details page, you will see “Basic Information”, “Contact Information”, “Details”, “…”.  Click on the ellipsis (three dots) then click Language and Region.

In Office 365, getting to that page is different.  A little further down the Edit Profile page, you will see the text “How can I change the regional and language settings?”  Click on it and it will show the line “Click here, click the ellipsis (...), and then select Language and Region.”  Follow those instructions.  Under “Language” in the section “Language Preferences” you will see “My Display Languages”.  You can change the order of the languages that are there or pick a new language from the list and click on “Add”.  [Note: it can get a little trickier; this assumes that you are using the default UserSettingsProvider.  That’s for another day.]

For some reason, the list of languages that it offers includes a lot of languages that SharePoint doesn’t even support, like Lower Sorbian and Mohawk.  Pick one or more languages that you want, rank them in the order you want, then click “Save all and close”.  It will show you a message saying “Your changes have been saved, but they may take some time to take effect. Don't worry if you don't see them right away.”  It usually takes a few minutes for them to take effect, but sometimes it can be hours.  On some sites like Delve itself the effect is quick, but on others it can take several minutes or longer.


On SharePoint sites that have alternate languages, the first language in the User Profile's language list that matches one of the site languages is the one that gets selected and only when none of them match does it look at the browser settings.

Office 365 Account language setting

Office 365 has an account language setting distinct from the Profile language setting.  As opposed to the other settings it has a single value, it is not a ranked list.  To get to it, click the gear icon, then Office 365 settings.  It is at the bottom of the screen.


When you click on the language, you get yet another different list of languages to choose from, as well as other regional settings.


Two different things happen when you change that language.  First, there are direct effects on the components of Office 365 whose language is controlled by the Office 365 Account language setting.  These are mostly non-SharePoint components, but it includes the name of Office 365 components.  Second, there are indirect effects.  When you change your account settings it will automatically change the list of languages in your Profile to the one language that is in your new Account setting.  That in turn will eventually affect SharePoint and other Office 365 components.

You can go back to the Profile and see that the Lower Sorbian and Mohawk have been replaced with the language that you just chose.  This will eventually have an effect on all your SharePoint sites.  You can change the setting back to whatever you want, but some advice: wait for an hour or so.  If you change your language setting again too quickly, bad things can happen. Bad things like the setting won’t match what’s displayed and might not change at all until you change both settings again, respecting the proper long ritual pauses between changes.

The Instant Toggle Trick

The problem with changing your language setting using either the Profile or the Account setting is all the waiting involved.  If you’re a developer or content author and you need to change language regularly, how can you do it quickly?  The answer is the Instant Toggle Trick™.

1.       Use an Account language setting that has no overlap with your site’s base + alt languages

2.       Make your Profile language setting blank, or one that has no overlap with base + alt languages

3.       Go home, come back tomorrow

4.       Now change browser language settings.  The language change will be instantaneous

Obviously, you can’t train all users to do this and there are certain undesirable side effects.  For instance all your Office 365 settings pages will be in a language other than the ones that you normally use.  But it’s great for developers.


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