Office 365: Die bevorzugte Sprache eines Benutzers

In der globalisierten Welt von heute sind Firmen und damit Anwender in der Microsoft Cloud in unterschiedlichen Sprachen im Tenant unterwegs.

Jeder Nutzer kann seine bevorzugte Sprache in den Einstellungen seines User-Accounts festlegen. Dazu muss der Anwender in die Ansicht „My Account“ (https://portal.office.com/account/) gehen. Der Klickpfad dahin sieht wie folgt aus:

  1. Klick auf das Nutzerprofil-Foto rechts oben in der Leiste
  2. Klick auf „My account“
  3. Klick auf das Zahnrad-Symbol rechts oben in der Leiste
Spracheinstellung im O365 Benutzerprofil

Die dort gesetzte Sprache wird abgekürzt im Benutzerprofil in Azure AD gespeichert. Es trägt den Namen PreferredLanguage und ist via PowerShell (Azure AD PowerShell Modul) auslesbar und auch setzbar.

Hinweis: So könnte man also auch automatisiert aus einem anderen IT-System (HR-Datenbasis) das Feld vorbefüllen.

Zusätzlich ist es möglich, diese Sprache auch über die OfficeGraph API auszulesen.

Der API-Aufruf zum Auslesen des Felds PreferedLanguage lautet:


https://graph.microsoft.com/v1.0/me/preferredLanguage

Dies ist der Direktlink zur der Konfigurations-Seite der Prefered Language im Nutzerprofil von SharePoint Online:

https://tenantname-my.sharepoint.com//_layouts/15/editprofile.aspx?UserSettingsProvider=dfb95e82-8132-404b-b693-25418fdac9b6

Das Wichtige, was man als Admin verstehen muss ist, dass diese Einstellung für das reine Frontend von Office 365 gilt jedoch nicht weiter synchronisiert wird. Für die Anzeige in SharePoint Online ist das folgende Profilfeld im Nutzerprofil dort maßgeblich:

PreferedLanguage im Nutzerprofil von SPO

Für die neue Mehrsprachigkeits-Lösung (siehe folgenden Artikel) in SharePoint Online ist also diese Einstellung maßgeblich!

SharePoint Online: Mehrsprachigkeit in Websites

Endlich hat Microsoft es geschafft, die Unterstützung von mehrsprachigen Websites in SharePoint Online für Modern UI umzusetzen. Bisher gab es eine Open-Source Lösung aus der PnP Community, welche in dem früheren Artikel bereits beschrieben wurde.

Das Feature besitzt die ID 50217 in der Microsoft Roadmap (Hyperlink) und es wird derzeit für Targeted Release Tenants bis Ende März 2020 ausgerollt.

Die Funktionalität

Die Unterstützung von Mehrsprachigkeit in Websites bedeutet, dass der Content (News-Artikel und Content Pages) in unterschiedlichen Sprachen redaktioniert und publiziert wird. Anschließend wird entweder automatisch nach eingestellter Sprache des Nutzers (SPO Nutzerprofil) oder manuell durch ein Sprach-Umschalter auf der Website der Content angezeigt.

Sprachumschalter
Sprachumschalter

Einrichtung der Mehrsprachigkeit

In den Website-Einstellungen muss der Website-Administrator unter der URL „/_layouts/15/muisetng.aspx“ die Einstellungen für Mehrsprachigkeit festlegen. Dort kann der Website Administrator also die unterstützten Sprachen festlegen. Die Standard-Sprache der Website wurde ja bereits beim Anlegen der Website festgelegt. Nun müssen also zusätzliche weitere Sprachen hinzugefügt werden.

Einstellungen für Mehrsprachigkeit in einer Website
Einstellungen für Mehrsprachigkeit in einer Website

Zu jeder ausgewählten Sprache für die Website wird dann der Redakteur, der die Übersetzung liefert festgelegt. Das können auch mehrere Nutzer pro Sprache sein.

Der Workflow für Redakteure

Die Redakteure haben nach erfolgreicher Einrichtung auf jeder Page ein zusätzlichen Button in der Headline „Übersetzung“.

Neuer Button zum Anlegen einer Übersetzung für eine Page
Neuer Button zum Anlegen einer Übersetzung für eine Page

Wenn eine Sprachvariante (Kopie) einer Seite für eine zusätzliche Sprache angelegt wird, erfolgt eine automatische Mailbenachrichtigung an den festgelegten Übersetzer für diese Sprache mit der Aufforderung die Seite zu übersetzen und zu redaktionieren.

Dialog hinter dem Button "Übersetzung"
Dialog hinter dem Button „Übersetzung“

Die Technik dahinter

Das Mehrprachigkeit-Konzept funktioniert folgendermaßen: Es werden für jede Page oder News verschiedene Sprachkopien gespeichert mit den jeweiligen übersetzten Inhalten. Die Sprachkopien einer Page werden in Unterordnern in der SitePages Bibliothek abgelegt. Es gibt also je Sprache ein eigenen Unterordner.

Das URL Beispiel für die Homepage der Website in deutscher Sprache ist dann also /SitePages/de/Home.aspx

Bei ankommenden Besuchern einer Website wird die eingestellte bevorzugte Sprache(n) im SPO Nutzerprofil ausgelesen und gematcht mit den verfügbaren Sprachen auf der Website. Wenn es einen Volltreffer (bevorzugte Sprache des Users = unterstützte Sprache in Website vorhanden) gibt, dann wird diese auch ausgeliefert. Die Sprachen im SPO Nutzerprofil eines Anwenders sind nach einer Prioritätenreihenfolge gespeichert. Nach dieser Reihenfolge wird auch beim Ausliefern des Contents entschieden, welche Sprache ausgeliefert wird.

Das SPO Profil ist für ein ANWENDER SEHR VERSTECKT – hier die direkte URL:

https://tenantname-my.sharepoint.com//_layouts/15/editprofile.aspx?UserSettingsProvider=dfb95e82-8132-404b-b693-25418fdac9b6

Leider ist das Verhalten in den Browsern derzeit noch nicht konsistent. Im folgenden Screenshot sieht man dieselbe Website im Edge und im Chrome darunter für den identischen Nutzer.

Unterschiedliches Verhalten in Browser (Edge vs. Chrome)
Inkonsistentes Browserverhalten

Weiterführende Information

https://support.office.com/en-us/article/make-modern-sharepoint-pages-available-in-different-languages-2bb7d610-5453-41c6-a0e8-6f40b3ed750c#bkmk_translators

SharePoint Online: Home Sites

Die logische Evolution der Hub-Sites (Link zum Artikel zu Hubsites aus 2017) in SharePoint Online im Jahre 2019 sind die neuen sogenannten Home Sites.

Use Case für Home Sites:

Eine unternehmensweite Portal-Startseite verlinkt mit der SharePoint Kachel für alle Anwender, die selbst anpassbar sind

Funktionale Aspekte:

  • Leider nicht 😦: die Startseite der Homesite ist verlinkt in Titel-Leiste und mit Kachel im App-Launcher Menü
  • Automatische Markierung von publizierten News in dieser Website als organisatorische News
  • Der Search Scope für Endanwender ändert sich von Site Level auf den kompletten Tenant in dieser Homesite
  • Home Button in SharePoint App
  • Die Communication Website ist erreichbar unter tenantname.sharepoint.com
  • die bisherige SharePoint Home SharePoint.aspx wird in die Homesite eingeplanzt

Technische Aspekte:

  • Eine und wirklich nur eine Communication Website pro Tenant kann zur Home Site erhoben werden
  • Die Website erhält dadurch eine neue URL. Die alte URL „/sites/sitename“ ändert sich zu tenantname.sharepoint.com
  • Diese Communication Site darf nicht Mitglied in einem Hub sein
  • Diese Communication Site kann Hub Site und Home Site zugleich sein
  • Das „Hochheben“ kann die Rolle „SharePoint Admin“ über SharePoint Online Management Powershell oder im Admin-Center
  • Durch das „Hochheben“ erhält die Communication Website spezielle Features
  • In der Navigationshierarchie wird automatisch ein Eintrag „Mein SharePoint“ mit der URL: https://tenantname.sharepoint.com/_layouts/15/sharepoint.aspx?source=homesite gesetzt, die die SharePoint Home anzeigt
  • Die SharePoint Home Seite lässt sich leider nicht bearbeiten

Der Aufruf in der PowerShell:

Set-SPOHomeSite -HomeSiteUrl "https://tenantname.sharepoint.com/sites/myWebSite"

Weiterführende Informationen:

https://docs.microsoft.com/en-us/SharePoint/home-site

SharePoint Online: Unterschied zwischen Page und News

Intro

In SharePoint Online werden Pages (also Artikel-Seiten) angelegt in Communication Sites, um redaktionellen Content und Newsbeiträge zu speichern. Irgendwie unterscheiden Sie sich, aber wie?

Wie unterscheidet sich eine Content Page und eine News Page voneinander?

Der einzige Unterschied ist eine numerische Eigenschaft im Datenfeld „Promoted State“ – in der deutschsprachigen Oberfläche heißt das Datenfeld: „Höher gestufter Zustand“

Wie wirkt sich der Wert aus?
Der News-WebPart zeigt nur Newsbeträge an und keine Pages. Wie macht er das!? Indem er Pages, die den Status „2“ gesetzt haben, anzeigt. Also folgt daraus – bei publizierten News-Artikeln ist in dem Feld per default der Wert „2“ gesetzt.

Alle Newsbeiträge, die noch im Entwurfsmodus sind, haben den Wert „1“. Newsbeiträge, die bereits publiziert wurden und dann wieder zurückgezogen wurden durch „Unpublish“ behalten unsinnigerweise den Wert „2“.

Alle Pages, die also keine News sind haben den Wert „0“.

Wie sehe ich den Wert?
Man kann sich das Feld anzeigen lassen in der Ansicht der Seitenbibliothek – in der Modern UI ist es als Metadatenfeld auswählbar – in der Classic UI beim Zusammenbauen einer Ansicht leider nicht.

Wie kann ich den Wert verändern?

  • Idee 1 – Quick Edit View in der Seitenbibliothek – funktioniert nicht 😦
  • Idee 2 – Gruppierte Ansicht nach „Promoted State“ und anschließend Drag & Drop des Artikels – funktioniert nicht 😦
  • Idee 3 – Nach dem Publizieren der Page gibt es in der rechten Spalte die Möglichkeit „Post as News on this site“ – funktioniert 🙂

SharePoint: Gefilterte Suche in einer Website anbieten

Use Case: Man bietet den Anwendern innerhalb einer SharePoint Online Website eine vorgefilterte Suchmöglichkeit auf bestimmte Inhalte einer Art (Klassifizierung, Sprache, etc.) an.

Konfiguration der vorgefilterten Suche

Konfiguration einer Filterung mittels einer sogenannten „Result Source“ (im deutschen UI als „Ergebnisquelle“ übersetzt) in einer Website. In dieser wird die gefilterte Suchabfrage konfiguriert, die später beim Eingeben eines Suchbegriffs durch den Anwender angewendet wird. Also abstrakt:

<suchbegriff des anwenders> + filter1 + filter2

Ein konkretes konfiguriertes Beispiel aus der Praxis:

{searchTerms} LanguageVariantOWSTEXT:"de-de"  Title=FAQ* 

Suchfunktion bereitstellen in Website

Es kommt zum Einsatz die Search WebParts für Modern UI in SharePoint Online aus dem Patterns & Practices Projekt. Diese sind kostenlos und fertig kompiliert und sofort bereit zum Einsatz.

Dokumentation: https://microsoft-search.github.io/pnp-modern-search/

Binaries: https://github.com/microsoft-search/pnp-modern-search

Diese WebParts müssen dem Office 365 Tenant hinzugefügt werden im App Catalog von SharePoint Online. Anschließend kann man sie lokal in einer gewünschten Website im Seitenbearbeitungsmodus auf einer Page seiner Wahl hinzufügen. Anschließend wird die GUID der erzeugten Result-Source im Konfigurations-Dialog des SearchBox WebPart eingetragen. Voila 🙂