IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

Modern SharePoint Sites: Multilingual by Default


In most versions of SharePoint on premise, and in classic SharePoint sites, you have to declare the language of the site when you create it.  You can also declare it when you create a modern site such as a Communication site, but with modern sites that has a completely different effect.

In classic sites, the language of the site or site collection determines the template that is used for the site, and that template is very language-specific.  The names of libraries, the sample content and many other components are created in a specific language.  In addition, on premise the possible alternate languages on the site are limited by the SharePoint language packs that have been installed on the farm.  By default when you install a new SharePoint farm, it will install it in one language, with no language packs.  

Installing language packs is a slow and laborious procedure.  They are not bundled.  You must download and install each one separately on all servers, and then when SharePoint updates are released you have to update for each language for which you have language packs in addition to the base update.

Once the language pack is installed, you can create new sites in that language, and you can also make that language an alternate language for sites that were created in another language.  That will allow you to localize certain UI elements so that they display in the user's preferred language, but some user interface elements such as error messages, notifications, and dialog boxes do not display in the user's language but in the site's base language.  Given how laborious is the installation of language packs, farm administrators will only install the minimum number of language packs required.

When a classic site is created, it will be created with a base language and no alternate language.  Someone has to add alternate languages to each site, picking from among the languages whose language pack has been installed.  Classic sites are unilingual by default.  The typical way to make a site multilingual is using Variations: creating multiple subsites each of which are also unilingual but in a different language.

For modern sites, this is turned around.  All language packs, over 50 of them, are always installed.  And when you create a new modern site it automatically has all of the languages selected as alternate languages.  Modern sites are multilingual by default.  This applies to all modern sites, including OneDrive.

In addition, Modern site templates are not very language-specific, so selecting a different base language makes little difference.  

For instance, go to the SharePoint start page and create a new site, but select the Irish language, as shown in the image.


Don't worry if your Irish language skills are a little rusty, you will see barely a word of Irish.  Everything is in English.  Almost everything.  The System account is called "Cuntas an chórais" and if you look on the browser tabs, certain pages are called things like "Irish - Form Templates - Gach foirm".  Even the home page with the Hero web part is in English.  Why is that?  It is because the user interface elements and the site templates are designed to be multilingual.  You created the site in Irish, but SharePoint automatically added all the other languages as alternate languages.

It recognizes that Irish is not one of the languages in your user profile, so it renders everything in your language, including the sample content of the Hero web part.  If you want to see your Irish site in Irish, you have to change your language preference to Irish.

This is part of what multilingual by default means.  You don't have to take a lot of actions to ensure that sites can be used in different languages, they can be used in different languages as soon as they are created, and you have to be aware that they will be used that way.

Next post in this series: Multilingual Features of Hub Sites

Localization of SPFx webparts in Microsoft Teams tabs

This post was prompted by a conversation with Bob German, a Partner Technology Architect for Microsoft.

In his talk at the Collaboration Summit in Branson MO, he touted the localization features of developing custom tabs for Teams using SPFx.

We chatted a bit after that, and discussed the fact that Microsoft Teams has a language setting that is independent of the language settings in the Office 365 user profile, which SharePoint uses.  I was of the opinion that even within a Teams tab, the SPFx webpart would follow the SharePoint language setting.  So let's try it out.

There is some very useful very complete guidance for localizing SharePoint SPFx webparts here

It is simple to create a small example webpart and localize the manifest, the property pane, and the content using the SharePoint guidance.  In this case, it was localized in English and Dutch.  Turning that webpart into a Microsoft Teams tab is just a matter of adding an extra manifest file and zipping it.

Add the webpart's sppkg file to your site catalog and ensure that the “Make this solution available to all sites in the organization” option is checked, so that the web part can be used from Microsoft Teams, then Deploy.


Then in Teams, select "Manage team" then the Apps tab, then "More apps" and "Upload a custom app".  Upload the "manifest.zip" file created earlier, which refers to the app in your app catalog.  Then click on the app name and click on Install, then setup and Save.  Let's have a look.

Here, both my Teams language setting and my SharePoint language setting are English. 

Let's change the Teams language setting.  You can do that by clicking on your picture then on Settings and selecting a new language.


I picked Dutch and re-started the Teams app.  So now the Teams interface, near the top of the screenshot, is mostly in Dutch, while the webpart is still in English.


If we do it the other way around, with the Teams setting in English and SharePoint in Dutch, we have the opposite effect, the Teams interface is in English and the webpart/tab is in Dutch.  So the SharePoint language setting determines the language of the localization of the custom tab.


We will go further still. Go to the SharePoint site that was created when the team was created.  Go to the site settings and remove Dutch as an alternate language of that site without removing it as your personal language preference.


Go back to Teams and now the webpart is back to English.  This is because the language of the tab is not just determined by your Office 365 profile language setting, it is determined by the ability of the associated SharePoint site to render its interface in that language, as though the tab was a webpart on that site.

Many thanks to my colleague Srikanta Barik for his help.

Physical vs Logical Topology: How the move to modern sites changes who is responsible for languages

This is the first of a series of posts based on my talk "Using Communication, Team, and Hub Sites in a Multilingual Organisation".

Once upon a time, large transnational organizations had many separate SharePoint farms in different countries or regions.  This made sense.  A SharePoint farm could only handle a few thousand users comfortably before the complexity and the management of the farm wiped out any economies of scale.  A large global farm meant you had a lot more to worry about.

You had to worry about access via internal networks, you had to worry about security and network latency for people accessing the SharePoint farm from a different office.  You had to worry about access control: who in the organization had enough knowledge of different users across the organization and of various organizational assets stored in the SharePoint sites to manage all of these users across the world and what they are allowed to do, to set up the governance policies and their exceptions?  You had to worry about maintenance windows and support hours when operations spanned many time zones.

Very importantly, you had to worry about data residency.  Many jurisdictions across the world have laws governing where different types of data can be physically stored.  That made it difficult to have a single farm that served several different countries.

The simplest way to deal with all of this was to have separate SharePoint farms in different countries or regions.  This is a physical topology.  The organization has multiple farms, each farm has multiple web application each web application has multiple site collections, each site collection has multiple sites.  All nice and hierarchical.

What if the organization has multiple languages? Where is language in this physical topology?  Every farm that needs more than one language needs to have language packs installed.  Installing those is the responsibility of whoever is managing that farm, in other words it is a country or regional responsibility.  Different farms can have different base languages and different language packs.  Every site has a base language, and the site template from which it is created is language-specific.  When new sites are created on these farms, they support a single language unless significant effort is put into having some support for other languages.  They are unilingual by default.


If you are using Variations, then responsibility for languages is much lower down in the hierarchy.  All Variation labels need to be within the same site collection.  And with Variations, each site is defined by its one language, so each site is unilingual.  Variations creates each site using a language-specific site template.  Therefore, responsibility for the language of the content is at the lowest level of the hierarchy, within a site collection, and few people have to manage more than one language at once.

There are two possible exceptions to this general rule: the content type hub and managed metadata service. Both have multilingual features and both are centrally managed.  In order for syndicated content types and managed metadata to work properly on sites that support a different language, then whoever is managing these central resources must activate those languages and maintain the translations of the terms and column names and so forth being used.  That is an exception, and a topic for another day; in the more general case the physical topology of on premise SharePoint means that language is an issue that is handled locally, within a country and often within a site collection, one language at a time.

SharePoint Online and in particular Modern sites are different.  When you create a tenant, every language pack is already installed.  When you create a modern site, all 50 languages are already activated.  The templates from which modern sites are created are not very language-specific.  There is very little difference between a site created in English and one created in Japanese.  If you go to a site that was freshly created in Japanese, you will see it in English, if English is your preferred language because every language is activated.  Modern sites are multilingual by default.

There are no farms or web applications in SharePoint Online or Office 365, only tenants.  If you use modern sites you are discouraged from using site collections.  You cannot have two modern sites in the same site collection.  There is no hierarchy, it is flat.  Sites can be clustered around hubs, but that is not the same thing as the type of hierarchy that you had with site collections.  And a site that belongs to one hub today can easily move to a different hub tomorrow.  Rather that the inflexible physical topology of on premise farms, you have a flexible logical topology.

There is still the possibility for an organization to have many different tenants, physically hosted in different data centres.  Microsoft offers data centres located in over a dozen different countries.  What is better, having a single tenant for the entire world, or having different regional tenants, each of them physically located near the users you have in that country?  

Even though SharePoint Online resolves a lot of the hosting, security, and scale problems, you still have the issues of data residency laws and of network latency.  But there are so many benefits to having a single global tenant, even more so than in the days of multiple on premise farms.  Because now, the boundaries between regional tenants are impenetrable.  Getting data from across that boundary is just as hard as getting it from the intranet of a competitor.  With multiple regional farms, you could share some services across farms.  But with SharePoint Online, you cannot search across tenants, you cannot easily share content types or metadata, or benefit from other collaboration opportunities of Office 365 like Groups, Teams, and Outlook.  You can't easily transfer staff from one to the other and have information follow them.  Office 365 resolves all the other problems associated with a single farm, is solving the data residency and network latency issues worth keeping regional tenants?

Now even that argument is gone.  For larger organizations, Microsoft now has multi-geo, the ability for the data of specific employees to physically reside in different data centres while still enjoying the benefits of a single global tenant.  A tenant does not need to have all of its data physically residing in one place, and it is easy for an employee to transfer from one region to another.  With a single tenant, you get the added benefits of the ability to share and to find information about documents and about employees throughout the organization.  One tenant to rule them all! One tenant to find them!

The impact of this move from the old physical topology to a more flexible logical topology, with flatter structure and where both sites and users can move easily, is that the issue of multiple languages now shifts being from a purely local issue delegated to site collection administrators to being a central problem that must be tackled by HQ at the corporate level.  The move of modern sites from being unilingual by default to multilingual by default underlines this.

Rather than having language as a leaf node of a hierarchy of farms, web applications, site collections, and sites, support for multiple languages has to be designed into the structure from the start.  If a hub site can have sites that are used by people of different languages, even if the member sites themselves are unilingual, then the hub site needs to be multilingual.  Right now, it is the hub navigation that must be multilingual, and someone needs to think about multilingual news aggregation and filtering news by language, but in the very near future more and more hub site features will be released, all of which will have to support multiple languages.

In the next post, we will discuss in more details what "multilingual by default" means, whether you use PointFire or just out of the box features of SharePoint.

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

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

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.

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 Partner SharePoint™ 2013 - Microsoft.com