IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

A few new languages

Because of recent changes to the Azure Translator Text API, a few new languages in the Western Iranian language group are being added to PointFire Translator.


Two versions of Kurdish are being introduced, Kurdish (Central), language code "ku", also called Sorani,  and Kurdish (Northern), language code "kmr", also called Kurmanji.

In addition, two languages of Afghanistan are being added.  
Dari (prs) and Pashto (ps).  PointFire Translator had already supported Dari and Persian, and Dari is also supported by PointFire 365 and SharePoint.  However, we had been using the same language code and translation engine for both of them, because they are so similar.  
Now Dari will use "prs" and Persian will use "fa" for Farsi, another name for the same language.

SharePoint 2019 Machine Translation Service is back!

When SharePoint 2019 was first released, its Machine Translation Service did not work.  The service could be installed and was running, but most attempts to use of it would result in the error message "The service application required to complete this request is unavailable. Try this operation again later. If the problem persists, contact your administrator."

The ULS log would have a message of "Unimplemented method" with a stack trace in Microsoft.Office.Web.Conversion.Framework.

Microsoft  has now resolved that error!  If you install the July 2020 or later Cumulative Update for SharePoint 2019 then the service is working again.

The Machine Translation Service is used by two optional features of PointFire 2019: the machine translation of user interface elements and the translation of classic pages and documents in SharePoint libraries.


These functions now work as expected.  The next release of PointFire 2019 will have some performance improvements that were delayed because of the difficulty in testing improvements to a feature that very few could use.

Because of the ongoing problem, all users of PointFire 2019 have been able to get free annual licenses for PointFire Translator, which can translate documents, pages, lists, and UI elements in SharePoint 2019 with higher quality than the free Machine Translation Service (although check out this secret setting).  PointFire Translator can also translate modern pages Excel, PowerPoint, and PDFs, which the Machine Translation Service cannot do, and covers more languages.  This free license program will soon end. If your free PointFire Translator license is expiring, contact us about transitioning to the Machine Translation Service or renewing the license.

Supporting another 12 Languages

In the most recent version of PointFire Translator (beta) we are introducing new or enhanced support for 12 new languages.

Of these, four are languages that are supported by SharePoint.  Irish and Kazakh languages are now supported for machine translation.  That means if your SharePoint site supports Irish or Kazakh, PointFire Translator can now translate its pages, documents, and lists, and PointFire 365 will automatically filter and/or redirect as appropriate.  If you want to translate the user interface, contact us, one of the steps is different for those languages than for other languages.

PointFire Translator now supports European Portuguese and Brazilian Portuguese as two separate languages.  Before this, the same translation engine was used for both, a neutral Portuguese that was actually closer to the Brazilian version.

Several new languages have been added to PointFire Translator which are not supported by SharePoint, including Māori (New Zealand), and five languages from India and Pakistan: Marathi, Gujarati, Punjabi, Malayalam and Kannada.  PointFire Translator will happily translate to or from those non-SharePoint languages, but PointFire 365 will be unable to filter by that language code.

All of those new languages have Neural Network engines behind them.  Irish, Brazilian Portuguese, Marathi, Gujarathi, and Māori have a customizable engine, meaning you can re-train it with your own documents to improve the translation quality.


The other two languages, or rather one language and two scripts, are ones that PointFire Translator had supported before and which had stopped working and discontinued.  In preparation for the Galactic Collaboration Summit we decided to brush off our Klingon translator.  This is where we discovered that there had been an undocumented change to Microsoft's Klingon language codes.  So we are happy to announce that we have reinstated Klingon (Latin script) and Klingon (pIqaD script).  If you choose the pIqaD script, make sure that you download a font that supports it, and change the font on the document.  This language only has a statistical translation engine, not a neural translation engine, so the quality is not very good.  But to paraphrase Samuel Johnson, it is like a dog's walking on his hind legs. It is not done well, but you are surprised to find it done at all.

If you're keeping count, that is 73 languages in total.

Changes to Serbian language codes in SharePoint Online

One of the changes that went into general availability last week was the retiring of the "sr-Latn-CS" language code, Locale ID 2074.

"Serbian (Cyrillic, Serbia)" [LCID=10266, language code "sr-Cyrl-RS"] was renamed "Serbian (Cyrillic)" and 
"Serbian (Latin, Serbia)" [LCID=9242, language code "sr-Latn-RS"] was renamed "Serbian (Latin)"


"CS" in the sr-Latn-CS was the former country code for the State Union of Serbia and Montenegro until it was dissolved in 2006 and Serbia and Montenegro became separate countries.  "RS" is the code for "Republic of Serbia" not to be confused with Republika Srpska. I have never noticed any UI difference between sr-Latn-CS and sr-Latn-RS, they were probably identical.  Many users in countries other than Serbia where Serbian is used, such as Montenegro or Bosnia and Herzegovina, tended to use the code because it did not mention Serbia in the name.  In case you're wondering, yes the versions of Serbian used in Bosnia and in Montenegro are different from the one used in Serbia, in fact there are a few more letters in the alphabet.  However they are not supported as distinct languages in SharePoint.


The locale IDs sr-Latn-RS and sr-Latn-BA  still exist in Delve, labelled with the country name for display language and for locales, and if you choose one there is a mapping done to the supported version of Serbian that uses the same script.

SharePoint Multilingual Page Publishing Feature in Detail

The new multilingual page publishing feature for Modern sites is now available in Targeted Release.  This is a good time to go through its main features in a bit more detail.

This SharePoint Online feature enables the publishing and consumption of pages and news in multiple languages in a modern SharePoint communication site. Multi-lingual page publishing means that on modern communication sites, site owners can determine in what languages they want to translate individual pages and news posts. This is different from Variations in that the translated pages are on the same multilingual site, but similar in that it copies pages and you have to translate them to the other language.


Turning it on

This feature must be turned on before it has any effect.  The activation is not, as you might think, in the site features section, but in Language settings.



Language settings was there before, this is where you used to set the Alternate languages for a site.  You can still do that more or less like before if you don't turn the feature on, by clicking on "Show advanced settings"

The new option is called "Enable pages and news to be translated into multiple languages"

The switch to turn on that feature appears on Communication sites, either new ones or existing ones.  It does not appear on Classic sites and it does not even appear on Modern Team sites.


If you click on "Show advanced settings" without enabling the feature, you can pick the list of alternate languages like before, and like before they are all turned on by default.


Parenthesis, what is Overwrite translations at the bottom?  It’s the same as before, with a different wording.  It has to do with what happens when you change MUI-enabled text in the site default language when it has has already been translated, will it leave the translations alone, or will it overwrite them with the new text in the original language as an indication that they need to be re-translated.

The second that you turn on the feature, even if you immediately turn it off again, all the site alternate languages are unselected.  You have to turn them on again one by one, using a different interface if the feature is activated.



 

The list of languages is the same as it was before with one exception, Serbian (Latin) has been dropped.

To select alternate languages, you can type a few letters of the language name or select it from the dropdown list



Selecting a language has two effects: it adds it to the list of alternate languages which determines the languages supported by the multilingual user interface (MUI), and it adds it to the list of languages to which site pages can be translated.

For each language you can select one or more "translator".  These are accounts that are notified by email whenever a page on this site should be translated to that language.  Naming someone as the translator does not give them rights to edit the pages, it simply sends them the email that contains a link to the page.  It is possible to send the email to external users, and it is possible to send it to people with no access to the list or to the site.  Sending it to a group works as well.

However if you type an email that’s not in AAD, then it gives a message when you save “Can’t save setting now.  Try again later”.  Always remember to hit save.



Adding pages

Since this is a Communication site, pages in the site default language can be added to the Site Pages library like before using Add a Page or by creating a News post.  Jumping ahead, creating a page, even with a different language selected, or using a language-specific News web part will always create pages that are assumed to be in the site default language and are in the root directory of the Site Pages library. 



"Translate" pages

You notice in the page menu bar that there is a "translation" button.  This will open a translation pane on the right.


As it clearly explains, this does not actually translate (unless you have PointFire Translator), it creates a nearly exact copy of the page either in all languages or in one language at a time.  You can do this with a draft or a published version, but keep in mind who can and cannot see drafts.  If you do not create them all at once, you can create the others individually or for all remaining languages at once.


All created pages are drafts initially.  It is then possible to get to that page in at least four ways.

1) Follow the "view" link
2) Follow the email link in the email that is sent to translators when the page is created


3) follow the little "Available languages" page navigation dropdown in the top right corner


Notice how this page navigation reminds you which page is published and which is a draft.

4) Navigating to the folder


When a translation page is created, it is put in a language-specific folder, with the same file name.  These folders use the PointFire naming convention, a two-letter code for languages where SharePoint supports only one variant, and language-dash-country or language-dash-script where there are more variants.

When you first visit the language-specific copy, you will notice that the title is changed to “Translate into {Language name}: {Original title}”.  You will also notice a message at the top, "This page has not been translated into {Language name} yet.  Edit to start translation"


This message remains until the page has been Saved once, even if you went in edit mode and changed nothing and it autosaved.  You (or someone else) are responsible for translating the content of the page, its title and the title and content of every webpart.  Remind translators to delete, not translate, the “Translate into {Language name}: ” part of the title.


User Language and Issue with Right-to-Left languages

Depending on the user's SharePoint language, there is a possibility of the user being redirected to the version of the same page in the user's language.  This redirection is not persistent, it is easy to navigate to pages in other languages without changing your own language.

When you go to a page in a right-to-left language while your current language is one that has left-to-right layout, you will see it with a left-to-right layout while editing.  The letters are RTL but the layout is LTR


If your current language is a right-to-left one, then you will see a right-to-left layout.  The layout depends on the user’s language, not the language of the page or of the site.   For those interested in the technical details, the "lang" and "dir" properties of the page's html element follow the user language settings.


Language of the user interface

This may be a good time to point out that while the feature will let you translate and navigate to pages in other languages, what you will see is only the page content in that language, the entire user interface will not switch to that language.  That's why in the first Arabic picture above you see the UI in one language and the content in the other language.  In the second Arabic picture, the content language and the UI language match, because the user's language setting matches the page language.  Changing your own SharePoint language is no easy feat.

Does this feature translate the UI?  No.  There are a number of UI elements that support MUI, and out-of-the-box elements are mostly populated with localized elements, but any customization that you do, for example to the navigation, will not be translated unless you translate it manually.  Here is how to localize your SharePoint navigation, but the same technique should be used for all localizable UI elements, including title/description of sites, lists, columns, content types, and views.

Can you translate custom SPFx web parts?  Almost never.  Whoever developed the webpart might have given you the ability to change certain strings on the page, but developers should probably also follow the guidance to localize the webpart.  This localization will follow the user's language, not the page or site language.
 

Deleting pages

What if you make a change to the original page?  Can you re-copy it to the translations? No (again, unless you have PointFire Translator).  However now is a good time for human translators to discover the new SharePoint page version comparison feature to highlight what has changed and determine what need to be re-translated.

It won’t re-copy unless you delete the translated copy.  The feature adapts well to deleting the translated copy. The “Available languages” menu adapts, as does the translation pane.

If you delete the original, the copies stay.  However they feel some distress.  If you click on the “Available languages” menu while on one of the orphaned copies, it spins and never returns

 

If you turn off the feature, all the pages stay, but most of the language functionality is removed.  The functionality returns if the feature is turned back on again.


 News Webpart language filtering

One cool automatic feature I'm still trying to find the limits of is the filtering of News and Highlighted Content webparts by language.  If you have a News webpart on a default language page, it will only show published news items that are in the default language.  However if that same webpart is on a translated language page, the webpart only shows published news items that are in that language.  The filtering is automatic, there are no explicit filter conditions that are added or can be modified.  If you turn off the feature, then the filtering stops.  Does it work with Hub news or on the SharePoint home page?  Stay tuned, not certain yet.

  

How PointFire Translator completes the functionality

For more details see the blog post about machine translation for multilingual page publishing.  Here is a video that shows how this automatic machine translation works


Essentially, the machine translation process can be completely automated.  When you view the new page for the first time, what you will see is not a copy of the original page for you to manually translate, but a translated page for you to approve and publish.  This saves huge amounts of time and money.

SharePoint’s New Multilingual Publishing Feature and How PointFire Translator Integrates With It

(see also SharePoint Multilingual Page Publishing Feature in Detail)
The initial documentation for Microsoft’s new multilingual pages functionality for modern pages is now available online.  You can find it here.

According to the recent announcement, "this new feature enables the publishing and consumption of pages and news in multiple languages in a modern SharePoint communication site. This is an opt-in feature. Site owners must take action to enable this experience.... We will be gradually rolling out this feature to Targeted Release (entire organization) customers by the end of March 2020. The roll out will be completed for all customers, by the end of May 2020."

When it is activated, site owners will be able to select the languages to which they want modern pages to be translated, and the persons who should be notified when a translation is requested.

 

When a modern page has been created, a translation can be requested.  On the top bar of the page, select the Translation button.


This brings up a translation pane on the right of the page.  To create a page for translation in all the languages configured for your site, select "Create for all languages". Otherwise, you can select the individual languages you want by clicking "Create".

 

If you are one of the people named as a translator for that language, you will get an email that looks like this:

 


The out-of-the-box experience when clicking on the “Start translating” button is to bring you to a copy of the original page in the original language, saved in a language-specific folder of the Page library.  You can start translating this copy of the page, replacing the text in the title and in the various webparts with text in the desired language, provided that you have the required permissions.

This is where PointFire Translator integration comes in.  SharePoint's new out-of-the-box feature does not include machine translation.  If you have version 2.0 of PointFire Tranlator and someone has set up the automation or the scheduling features of PointFire Translator Server, then when you click on “Start translating” in your email you will see not the page in the original language for you to translate, but a freshly translated page for you to check, modify if required, and publish.  It’s that simple.  PointFire Translator will have translated the page, its title, the text within text and hero webparts, webpart titles, translatable text metadata, etc.

If notification was not set up in the OOTB feature, or if you have not enabled the automation or the scheduling features of PointFire Translator, then you will have to initiate the translation manually.  Go to the appropriate Pages library, then pick the folder with the language code corresponding to the desired language.


For those who have used PointFire products before, SharePoint is now using the same language codes that PointFire had been using.  Then within the folder, select the page that you want to translate, and either select “PointFire Translator” in the item menu or click on the item to activate the checkmark in the circle to the left of the item and click on the the “PointFire Translator” button.


Besides the ability to translate the modern pages created by this SharePoint OOTB feature, you can still get the other benefits of PointFire Translator, including the ability to translate classic pages, to translate documents in Word, Excel, PowerPoint, and PDF format, and to translate list items, as well as the ability to translate entire libraries and lists at once rather than single items or wildcard matches.

More detailed information will be posted here when Microsoft makes it public.

Multilingual Publishing for Modern SharePoint Sites

The promised Multilingual SharePoint Pages was finally revealed in public a few hours ago.  Compared to a fully-featured product like PointFire it's a bit, let's say rudimentary, in that the list of what it will not do is longer than the list of what it does, but it's an important part of the multilingual landscape.  The initial release is still months away.

In general terms what can it do?  It does allow modern pages in the site pages library to be copied and manually translated to other languages.  It does allow a user to navigate from one language version of such a page to a different language version by using a language toggle in the page header.  This language toggle is different from the PointFire language toggle (or from the SharePoint 2010 language toggle) in that it navigates to a different language version of the page without changing the language of the user interface.  It does detect the user language, and certain web parts will be given additional ability to filter list of pages by language.

What it is not is a full replacement of Variations for Modern pages.  It does not include multilingual lists or libraries.  It does not include any classic pages.  It does not include automatic redirection to the page in the correct language based on the user's language although it some cases it does go to that page, and it does not include machine translation of either the pages or the UI elements.

In the brief demo by DC Padur of Microsoft, a typical set of steps was shown.

1. Setup


To start, the site-scoped multilingual feature is enabled.  This requires entering the list of supported languages and the email addresses of the translators (not in the screenshot).  Interestingly,  Microsoft's demo showed the configuration screen at the URL where one can currently choose the site's alternate languages, but the interface seems to show a more laborious way of searching for languages and adding them one by one, rather than the current modern experience of activating all languages, and using check boxes to select and unselect.


Setup includes the following feature "If a site user has manually translated site navigation or site info such as Title or Description, overwrite their changes when the same info is updated in the default language.  This setting does not apply to page or news content"  It is not entirely clear what this does.  It sounds like the "Overwrite Translations" message that you see on that page today, but the phrasing is different enough that it might mean something different.  The current message says "User-specified text, such as Title and Description of the site, can be translated into the alternate language(s) supported by the site. Specify whether the changes made to user-specified text in the default language should automatically overwrite the existing translations made in all alternate languages."

2. Starting translation

After a modern page has been created in the site's default language, while in edit mode a site user can begin the translation process.  This creates copies of the page to special folders in the same library that correspond to the desired language of the translation, and sends an email to the translators.  These folders seem to correspond to a 2-character language code.  Subsequent edits to the original page can result in new emails to the translators, but not in a new copy of the page.

The copies of the page are originally in the initial language.  Presumably the translator will have access to the site with sufficient permissions to edit pages and to change the site name and description, and then change all the text that they can find to the target language.


3. Users can switch between different language versions


When a user wants to see a different language version of a page, they first go to the page in the current language, then click on the language selector in the site header, next to "Share site" to see a different language version of the page that has been modified by a translator.  Translators may have a similar experience, allowing them to navigate to a given language version then edit it.

The MUI and user language selection are essentially unchanged.  There is a fair bit of discussion about how they are a key part of the multilingual pages experience, but all of the functionality mentioned is functionality that already exists.

Because the user language and the site language are separate, editors will not see exactly the same screen as the end users.  They will see the content in the user's language, but any navigation, or list names, column headings, and so forth will not necessarily be in the same language.  This is what Microsoft used to call "a mixed-language experience".


The setup step is something worth watching in the next few months.  Will there be a single list of languages supported by a site, or will there be two lists: the list of alternate languages supported by the UI and the list of languages supported by modern site page translation?  Is SharePoint moving away from the "multilingual first" model where all alternate languages are automatically enabled at site creation?  Also what are the consequences of adding or removing languages after pages have already been created?  Will pages in a deleted language be deleted or orphaned?

The "separate folders" approach is a bit old-fashioned.  After decades of telling people to use metadata not folders, SharePoint succumbs to the temptation of using folders to represent language.  It's still better than separate sites like Variations did.

As expected, machine translation is not part of this new feature.  PointFire is announcing today that PointFire Power Translator will be extending its existing machine translation of modern pages to add support for the pages that are created by this new feature.  It will be the same product as currently exists, which already supports modern and classic pages, and also modern and classic lists and metadata, and various document formats, on SharePoint and OneDrive, but with the additional ability to use the "language" folder structure of this Site Pages library.

What about PointFire 365?  For now, organizations will have a choice between the limited functionality of the new multilingual modern pages or the full multilingual SharePoint functionality of PointFire 365.  For some organizations, this manual translation of certain pages and UI elements is sufficient.  We will provide a migration path to upgrade from Microsoft's feature to PointFire 365 for those who later realize that it is not enough.

All the Languages Supported by PointFire.

PointFire 365 and PointFire Power Translator support a lot of languages, but language support is not the same for all languages.  Here is a current chart of which languages are currently supported and to what degree.

Language Quality SharePoint
Afrikaans Neural N
Arabic Neural Y
Azerbaijani  - Y
Bangla Neural N
Basque  - Y
Bosnian (Latin) Neural Y
Bulgarian Neural Y
Cantonese (Traditional) Statistical N
Catalan Statistical Y
Chinese Simplified Neural HP Y
Chinese Traditional Neural Y
Croatian Neural Y
Czech Neural Y
Danish Neural Y
Dari Neural (Persian) Y
Dutch Neural Y
English Neural Y
Estonian Neural Y
Fijian Statistical N
Filipino Statistical N
Finnish Neural Y
French Neural HP Y
Galician  - Y
German Neural HP Y
Greek Neural Y
Haitian Creole Statistical N
Hebrew Neural Y
Hindi Neural HP Y
Hmong Daw Statistical N
Hungarian Neural Y
Icelandic Neural N
Indonesian Statistical Y
Irish  - Y
Italian Neural HP Y
Japanese Neural HP Y
Kazakh  - Y
Kiswahili Statistical N
Klingon Statistical N
Klingon (plqaD) Statistical N
Korean Neural HP Y
Latvian Neural Y
Lithuanian Neural Y
Macedonian  - Y
Malagasy Statistical N
Malay Statistical Y
Maltese Statistical N
Norwegian (Bokmål) Neural Y
Persian Neural N
Polish Neural Y
Portuguese (Brazil) Neural Y
Portuguese (Portugal) Neural (Portuguese) Y
Queretaro Otomi Statistical N
Romanian Neural Y
Russian Neural HP Y
Samoan Statistical N
Serbian (Cyrillic) Statistical Y
Serbian (Latin) Statistical Y
Serbian (Latin, Serbia) Statistical Y
Slovak Neural Y
Slovenian Neural Y
Spanish Neural HP Y
Swedish Neural Y
Tahitian Statistical N
Tamil Statistical N
Telugu Neural N
Thai Neural Y
Tongan Statistical N
Turkish Neural Y
Ukrainian Neural Y
Urdu Statistical N
Vietnamese Neural Y
Welsh Neural Y
Yucatec Maya Statistical N

SharePoint itself supports 51 languages.  PointFire 365 supports all of those languages.  All user interface elements can be shown in any of those languages, all content can be filtered to show content to users in any of those languages.  They are indicated by a "Y" in the "SharePoint" column.

PointFire Power Translator supports even more languages.  If you are unaware of the PointFire products, PointFire 365 is the one that handles localizing the user interface and filtering content by language, while PointFire Power Translator is the one that carries out machine translation of documents and metadata in SharePoint Online and OneDrive, and of the content of any library, list, or classic or modern page in SharePoint Online.  Where the language is one that is supported by PointFire 365, the combination of both products means documents and SharePoint pages immediately show up in any of those languages.  For example if you send a news page to translation using PointFire Power Translator, it will translate it into the other languages of your site within seconds and all users who prefer one of the other languages will see the version in their language rather than the original.

However the quality of machine translation can vary.  In the back end, PointFire Power Translator uses one of four different translation technologies, powered by Azure translation technologies.  The technology that most people are used to, which powered the old Bing and Google translation engines, is statistical machine translation.  This was the state of the art until a few years ago, using syntax-based statistical translation models with a few additional tricks to improve language quality.  It trains on large corpora of text that is already translated, trying to mimic the translation process using statistics.  This technology got better and better over the years.  For several languages we are still using these statistical models.

Around 2015, based in large part on algorithms developed at the University of Toronto and Université de Montréal, Neural Network models emerged as a better alternative to statistical models.  These deep networks require enormous amounts of computing power to train.  Interestingly enough, large software companies like Microsoft and Google tend to publish their results and make their insights and tools available to each other, so that they can each improve on one another's work.  Because of this, neural machine translation technology has progressed quickly.  It still requires massive amounts of computing power to train such models, something like 100 processors for a week for each training run, but Microsoft is a leader in technologies to use less processing power so it uses a fraction of that.  For most major languages, PointFire is using neural translation.

Then in March 2018 Microsoft announced it had achieved "Human Parity" for some translation tasks.  Mind you this is a controversial claim and neither the humans with whom parity was achieved nor the people doing the rating of translation quality were professional translators, but we use the "HP" label to refer to the technology being used, not necessarily to the quality level.  These initial engines were not suitable for production, they were far too massive.  Microsoft then improved on the size and performance of these complex models, using groundbreaking techniques.  For example they use a large deep neural network to train a much faster wide shallow network, gaining a huge performance improvement and improved translation quality.  They train a separate neural network to detect and correct errors in the input data.  They use the trick that so many of us have used to hilarious effect: it translates sentences from English to another language, then translates that translation back to English to see whether it is the same.  These new "human parity" engines have been sweeping international competitions of translation quality and, as opposed to a lot of the other entries, these are available in production.  Chinese and German were released in late November 2018, and French, Hindi, Italian, Spanish, Japanese, Korean and Russian, to/from English are now available.  More details on the Microsoft Translator blog if you are interested.

The highest quality of any translation engine on earth is still not good enough for you?  We offer an even higher quality.  Using Microsoft's Custom Translator, you can re-train an existing neural machine translation engine using your own professionally translated documents so that it adopts your vocabulary and your style.  If you're keen, you can even train it on a different dialect or language.  PointFire Power Translator supports these custom models as well as the standard ones in the table above.

There is a lot of overlap between the languages supported by PointFire 365 and those supported by PointFire Power Translator.  Some of them are the same language, but some of them have a mapping that you may need to be aware of.  For example, SharePoint supports Dari but not Persian, while the translator supports Persian and not Dari.  Written Persian and written Dari are close enough that we have declared them to be the same.  When you check the translations, keep it in mind.  SharePoint supports two versions of Portuguese.  The translator supports only one. It is a hybrid but it looks more like Brazilian Portuguese.  We use the same engine for both, but it's a good idea to check the translations.  For Norwegian, SharePoint explicitly uses bokmål, while the translator uses a different language code that may refer to nynorsk.  From the limited knowledge of Norwegian available to our team, the language code looks like a mistake and we believe that both use bokmål.

The Balkans present their own challenges.  Certain languages of former Yugoslavia are similar to certain other languages. It's a sensitive subject so we will not discuss in writing how we bridge some of the gaps between language codes.  However it has been made clear to us that using a Bulgarian translation engine for the Macedonian language is not acceptable and therefore we do not provide machine translation functionality for Macedonian, until a compatible translation engine specific to the Republic of North Macedonia is available.

There are a number of languages for which PointFire Power Translator can provide translations of SharePoint or OneDrive documents, but which SharePoint itself does not support.  The Item Language column of these translations will be tagged with the language code of these languages, whether or not it is an allowable language code in PointFire 365.  Be aware that PointFire 365 will not filter these documents.  These languages include Icelandic, Kiswahili, and Maltese.  There are in theory two versions of Klingon, one that uses the Latin alphabet and the other that uses the Klingon scripts.  We regret that the version using the Klingon font, if you have installed this font, is no longer working :-(  and we have not invested the time to find out why.

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

SharePoint 2019 Machine Translation Service is broken

It's been a busy week at PointFire, with three version releases.  Version 2.2.3 of PointFire 365 came out, with several improvements, the much anticipated version 1.1.0 of PointFire Power Translator, and the final beta of PointFire 2019.  PointFire 2019 v1.0 was scheduled to be released this week, but instead it still remains in beta.  The reason: SharePoint 2019's Machine Translation Service is broken.

The list of deprecated features for SharePoint 2019 was clear; it said "The Machine Translation Service will remain supported but deprecated for the SharePoint Server 2019 release."  But version after version, farm after farm, we could never get the service to work on SharePoint 2019 farms.  Finally a week ago our support ticket with Microsoft reached a conclusion:  the Machine Translation Service does not work.  At all, under any configuration they tried.  The product group is aware.

PointFire 2019 has the option of using the Machine Translation Service for certain translations.  The other option (besides, you know, humans) is to use PointFire Power Translator with its better speed, accuracy, scriptability and flexibility.  The benefit of the Machine Translation Service is that it is free.  But we can't release something with a feature that we never fully tested.  Microsoft might, but not us.  So PointFire 2019 is still officially in beta, and we will see in a few weeks whether we remove the option or whether SharePoint 2019 gets fixed.

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