Mehrsprachigkeit in MetaModels

MetaModels ist sehr gut auf mehrsprachige Inhalte ausgerichtet. MM stellt für die mehrsprachigen Inhalte eigene Attribute wie z. B. Übersetzter Text, Übersetzter Alias, Übersetzte Datei usw. zur Verfügung. Für Attribute deren Werte unabhängig von einer Sprache sind, wie z. B. Zahlenwerte Produkt-IDs usw. , gibt es diese Varianten nicht.

Die Mehrsprachigkeit in MetaModels ist so konzipiert, dass die mehrsprachigen Felder neben der Fallback-Sprache auch in den gewünschten Übersetzungen ausgefüllt werden. Sollte das bei einem Feld mal nicht der Fall sein, wird im Frontend automatisch der Fallback-Wert ausgegeben. Im Template kann nicht unterschieden werden, ob ein Wert aus der Übersetzung oder vom Fallback kommt.

Bevor man mit der Erstellung der Models startet gilt es gut zu überlegen, ob die Inhalte mehrsprachig abgelegt werden sollen. Die mehrsprachigen Inhalte werden in separaten Tabellen gespeichert und nicht in der eigenen mm_*, so dass ein späterer Wechsel zu einer Mehrsprachigkeit mit entsprechender Nachpflege verbunden ist.

Wenn man einsprachige Werte hat die man speichern möchte, aber die in verschiedenen Sprachen im Frontend ausgegeben werden sollen, ist eine Umstellung auf eine Mehrsprachigkeit unkritisch. Es werden lediglich die Attributsbezeichnungen entsprechend den Sprachen erweitert - siehe unten „Attribute“.

Models

Die Mehrsprachigkeit eines Models wird beim Erstellen festgelegt. Mit Aktivierung der Option „Übersetzung“ kann man eine Liste mit zu pflegenden Sprachen pflegen. Aktiviert man auch die Option „Support für Territory-Angabe in der Sprache“, werden zu den Einträgen der Hauptsprachen wie de, en, fr auch die territorialen Zusätze wie de_DE, de_AT, de_CH usw. in der Liste freigeschaltet.

Eine Sprache ist als Fallbacksprache festzulegen, für die dann auch immer alle Datensätze vorhanden sein müssen. Sollte die Fallbacksprache später gewechselt werden, muss das entsprechend in der DB geprüft und korrigiert werden.

Legt man mehrere Models an, die auch noch durch Relationen verbunden sind, ist es ratsam, bei allen Models dasselbe Sprachenschema und dieselbe Fallbacksprache zu definieren. Es ist auch sinnvoll nur die Sprachen anzulegen, die Contao über seine Startpunkte definiert hat.

Die mehrsprachigen MetaModels sind mit einer farbigen Länderfahne hervorgehoben .

Speicherung in Datenbank

Gespeichert werden die übersetzten Werte in separaten Tabellen tl_metamodel_translated* - je nach Attributstyp können das unterschiedliche Tabellen sein. Somit erscheinen die Werte nicht in der individuellen Tabelle des angelegten Models mm_*. Die Übersetzungstabellen haben eine Referenz zum Attribut att_id und zum Datensatz item_id sowie die Angabe der gespeicherten Sprache langcode.

Die Daten in der definierten Fallbacksprache müssen vorhanden sein, damit auch bei nicht vorhandener Übersetzung eine Ausgabe erfolgen kann. Seit MM 2.4 wird die Fallbacksprache in der Eingabemaske mit „“ im Sprachenwechsler als auch in der Überschrift gekennzeichnet.

Wechselt man in der Eingabemaske von der Fallbacksprache zu einer Übersetzungssprache, werden in den Textfeldern die Eingaben der Fallbacksprache ausgegeben. Damit wird eine Übersetzung der Texte erleichtert. Mehr zum Thema Kennzeichnung im Abschnitt „Eingabemaske / Eingabe“.

Bemerkung

Wird ein Fallbacktext nicht übersetzt, so wird dieser auch nicht in der Übersetzungssprache eingespeichert. Dies ist insbesondere zu beachten, wenn ein Begriff in der Fallbacksprache als auch in der Übersetzungssprache gleich ist wie z. B. „Marketing“ in Englisch und Deutsch.
Wird eine Eingabe nach einer Übersetzung wieder auf den Fallback-Inhalt umgeschrieben, so wird der Eintrag für die Übersetzungssprache in der Datenbank wieder gelöscht.

Bemerkung

Ab MM 2.4 werden beim Kopieren eines Datensatzes alle Sprachen mit kopiert - siehe Issue

Bemerkung

Werden mehrsprachige Models oder Attribute gelöscht, werden nicht alle Inhalte mit gelöscht - hier Hinweise zum Prüfen und Löschen

Seit MM 2.4 gibt es den Parameter „Fallback-Modus deaktivieren“ - ist dieser aktiv, wird ein Wert für eine Sprache dennoch gespeichert, auch wenn dieser gleich dem Fallbackwert ist. Aktiviert ist diese Option z. B. beim Attribut Übersetzte Checkbox.

Attribute

Ist die Option „Übersetzung“ bei einem Model aktiviert, stehen beim Anlegen der Attribute auch die mehrsprachigen Varianten zur Verfügung. Je nach Installation kann das wie folgt sein:

• Übersetzter Alias

• Übersetzte Checkbox

• Übersetzte Datei

• Übersetzte Tabelle multi (MCW)

• Übersetzte Text-Tabelle

• Übersetzte URL

• Übersetzte kombinierte Werte

• Übersetzter Inhalt eines Artikels

• Übersetzter Langtext

• Übersetzter Text

• Übersetzte Einzelauswahl [select] *

• Übersetzte Mehrfachauswahl [tags] *

*: die nicht-übersetzten Attribute Einzelauswahl und Mehrfachauswahl unterstützen per se die Mehrsprachigkeit bei Relationen zu MetaModel-Tabellen. Die beiden hier aufgeführten Attribute sind für Spezialfälle wie z. B. Relationen zu nicht-MM-Tabellen mit mehrsprachigen Inhalten. Diese Tabellen müssen aber eine Spalte mit dem Sprachschlüssel haben. Man kann dafür auch einsprachige MetaModel-Tabellen verwenden mit einem Attribut für den Sprachenschlüssel. Damit ist es möglich je Sprache nicht nur eine entsprechende Übersetzung zu liefern, sondern ganz andere Inhalte. Beispielsweise könnte eine Wanderung für englischsprachige Besucher „linksrum“ und für deutschsprachige Besucher „rechtsrum“ gehen.

Bei einem mehrsprachigen MetaModel stehen bei allen Attributsdefinition für die Felder „Name“ und „Beschreibung“ je Sprache ein Feld zur Verfügung - die Fallback-Sprache ist hervorgehoben dargestellt. Diese übersetzten Angaben werden in der Eingabemaske automatisch in der Sprache ausgegeben wenn die passende Backendsprache im Benutzerprofil ausgewählt ist.

Zudem kann im Template des Renderings über den Knoten attributes auf den übersetzten Wert „Name“ zugegriffen werden - es wird automatisch die Sprache der Contao Frontendausgabe oder der Fallbackwert ausgegeben. Im Template könnte eine Ausgabe wie folgt aussehen:

<p><strong><?= $arrItem['attributes']['name'] ?>:</strong> <?= $arrItem['text']['name'] ?></p>
<p><strong><?= $arrItem['attributes']['city'] ?>:</strong> <?= $arrItem['text']['city'] ?></p>
<p><strong><?= $arrItem['attributes']['description'] ?>:</strong> <?= $arrItem['text']['description'] ?></p>

Damit ist eine bequeme Handhabung der mehrsprachigen „Labels“ in einem Template möglich.

Eingabemaske / Eingabe

In der Eingabemaske im Backend haben die Widgets der mehrsprachigen Attribute zur Unterscheidung ein farbiges Flaggen-Icon . Die Umschaltung der Sprachen erfolgt direkt im Header der Eingabemaske. Die Fallbacksprache ist sowohl im Sprachenwechsler als auch in der Überschrift entsprechend gekennzeichnet.

Beim Neuanlegen eines Datensatzes wird immer erst die Fallbacksprache befüllt - wenn in der Maske noch eine andere Sprache als die Fallbacksprache eingestellt ist, wird mit dem Speichern auf die Fallbacksprache umgeschaltet.

Warnung

Das Speichern eines Datensatzes bzw. einer Eingabe erfolgt nicht automatisch bei der Umschaltung zu einer anderen Sprache - vor dem Umschalten müssen die Eingaben mit „Speichern“ gesichert werden!

Bemerkung

Die folgenden Anzeigen wurden in MM 2.4 eingebaut bzw. angepasst.

Nachdem die Felder in der Fallbacksprache befüllt und gespeichert sind, kann auf eine beliebige andere Sprache gewechselt werden. In den mehrsprachigen Feldern ist zunächst Inhalt aus der Fallbacksprache zu sehen. Zusätzlich wird bei dem Titel der Hinweis eingeblendet, solange kein Inhalt gespeichert wurde, der sich von den Fallbackwerten unterscheidet. Damit soll der Status der Übersetzung leichter erkennbar werden.

Diese angezeigten Fallback-Inhalte werden aber beim Speichern nicht in der jeweiligen Übersetzungssprache in der DB gespeichert - siehe „Speicherung in Datenbank“.

Werden Inhalte in der Übersetzungssprache angelegt und gespeichert, wechselt der Hinweis bei den entsprechenden Eingabefeldern auf .

Je nach Status bei einem Eingabefeld sieht das dann z. B. so aus:

Erweiterungen zum Übersetzen:

Für kontinuierliche Übersetzungen bietet sich die Erweiterung XLIFF-Ex-Import für MetaModels an. Hiermit erfolgt der Austausch über das XLIFF-Format.

Die Dateien werden über die Erweiterung exportiert und nach der Übersetzung wieder importiert - für die Übersetzung können entsprechende Agenturen oder Tools eingebunden werden.

Für die Übersetzung im Backend steht die Erweiterung Translator-Bridge für MetaModels zur Verfügung, welche verschiedene Übersetzungsprovider wie DeepL einbindet. Eine Übersetzung kann je Eingabefeld erfolgen oder über einen Tastenkürzel für die aktive Eingabemaske der ausgewählten Sprache.

BE-Listenansicht

In der Listenansicht im Backend gibt es im Header auch einen Umschalter für die Sprache - werden in der Liste mehrsprachige Attribute ausgegeben, ist dann die Anzeige entsprechend der Sprache.

Filter

Die meisten Filterregeln suchen in der Sprache, die im Frontend gerade die aktive (Contao-)Sprache ist. Bei einigen Filterregeln wie „Einfache Abfrage“, „Einzelauswahl“, „Mehrfachauswahl“, „Textfilter“ gibt es die Option „Alle Sprachen durchsuchen“, sofern ein mehrsprachiges Attribut ausgewählt wurde. Diese Option kann man z. B. bei der Detailseite (s. u.) einsetzen.

Für das Attribut „Übersetzte Checkbox“ gibt es eine eigene Filterregel „Übersetzter Checkbox-Status“.

Bei der Filterregel „Levenshtein-gestützte Suche“ ist es bei der Attributseinstellung „Attribute zum Indexieren“ auch möglich, mehrsprachige Attribute auszuwählen.

Die Filterregel „Loupe-gestützte Volltextsuche“ unterstützt aktuell die mehrsprachigen Attribute Text und Langtext.

FE-Liste / Detailansicht

Im Frontend werden die Inhalte der Attribute analog zu den einsprachigen Attributen in den Templates ausgegeben. Ebenso werden die Attributsbezeichnungen übersetzt an das Template geliefert.

Bemerkung

Ist ein Inhalt nicht übersetzt, wird der Inhalt der Fallbacksprache ausgespielt - das gilt nicht nur für die Attribute mit Texteingaben, sondern auch für Attribute wie übersetzte Datei oder übersetzter Inhalt eines Artikels.

Das bedeutet, wenn z. B. bei der Übersetzungssprache keine eigene, sprachenspezifische Datei ausgewählt, werden alle Dateien aus der Fallbacksprache ausgegeben.

Aus welcher Sprache der Inhalt kommt, kann im raw-Knoten des Ausgabearrays im Knoten langcode abgefragt werden.

Hat man eine Detailseite bei der man üblicher Weise ein Datensatz per Alias anzeigen lassen möchte, soll man mit dem Sprachenwechsler zu der Detailseite in einer anderen Sprache wechseln können.

Erweiterungen wie „ChangeLanguage“ „sieht“ nur die in Contao angelegte Seite - z. B. https://my-domain.tld/en/dessert/details - ohne den Alias der Filterung.

Um der Erweiterung den Wert für die anderen Sprachen mit auf den Weg zu geben und entsprechend zu filtern, gibt es mehrere Möglichkeiten:

1. Filterregel „Einfache Abfrage“ die Option „Alle Sprachen durchsuchen“

Zunächst müssen alle Detailseiten der einzelnen Sprachen über die Seiteneigenschaften verknüpft werden - Button „Seite in Hauptsprache“. Zudem muss im Feld „Query-Parameter beibehalten“ der „URL-Parameter“ aus der Filterregel eingetragen werden (alias). Als URL-Parameter darf nicht „auto_item“ eingetragen werden, da ChangeLanguage damit nicht arbeiten kann.

Zudem wird die Filterregel „Einfache Abfrage“ erstellt oder angepasst. Der URL-Parameter darf nicht als auto_item eingetragen sein und die Option „Alle Sprachen durchsuchen“ muss aktiviert sein. Damit kann die Filterung mit allen Sprachvarianten erfolgen also mit

https://my-domain.tld/en/dessert/details/alias/marinated-strawberries als auch mit
https://my-domain.tld/de/dessert/details/alias/marinated-strawberries bzw.

https://my-domain.tld/en/dessert/details/alias/marinierte-erdbeeren als auch mit
https://my-domain.tld/de/dessert/details/alias/marinierte-erdbeeren.

2. Hook „changelanguageNavigation“

Möchte man die Option „Alle Sprachen durchsuchen“ nicht aktivieren oder mit auto_item als „URL-Parameter“ arbeiten, so kann man bei dem Sprachenwechsler „ChangeLanguage“ für jede Sprache der Filterparameter (z. B. Alias) über einen Hook passend austauschen - siehe Doku

Als Einstieg das Snippet: man muss prüfen, ob man sich auf der passenden Detailseite befindet z. B. ID 3, 15, 36 für die einzelnen Sprachenseiten. Mit dem aktuellen Wert des Filterparameters und der aktuellen Sprache kann der passende Wert für die jeweilige andere Sprache ermittelt werden. Diese Abfrage hängt vom jeweiligen Aufbau der MetaModels ab. Der Hook wird für jede Sprache in dem Sprachenwechsler einmal aufgerufen.

public function __invoke(ChangelanguageNavigationEvent $event)
{
    // ...

    // Right page?
    $listPageIds = [3, 15, 36];
    if (!\in_array($targetPageId = $event->getNavigationItem()->getTargetPage()->id, $listPageIds, true)) {
        return;
    }

    // Get alias value.
    $currentAliasValue = Input::get('auto_item');

    // Search for attribute value in target language.
    // $newAliasValue = ....

    // Set alias value for target language/page.
    $event->getUrlParameterBag()->setUrlAttribute('auto_item', $newAliasValue);
}

Mit dieser Variante werden auch die Angaben für hreflang in den Meta-Daten korrekt gesetzt - siehe SEO.

Frontend-Editing (FEE)

Mit MM 2.4 wird auch die Mehrsprachigkeit bei der Frontendbearbeitung unterstützt - mehr zu dem Thema - inkl. der Anzeige der Fallbacksprache und Übersetzungsstatus - siehe Frontend-Editing.