Planung und Durchführung automatischer Übersetzungen in TYPO3 mit DeepL

Wir haben die DeepL-Extensions in einem TYPO3-Projekt eingerichtet, um darin Übersetzungen automatisch generieren zu lassen. Heute erzähle ich euch von unseren Erfahrungen mit DeepL. Ich nehme das auch zum Anlass, den gesamten organisatorischen Ablauf zu beschreiben.

In der TYPO3-Installation lagen alle Inhalte in der englischen Sprache vor und wurden jetzt erstmals auf Deutsch übersetzt. Weitere Sprachen werden im Projekt folgen.

Bevor eine neue Sprache technisch eingerichtet wird, müssen wir diese einmal konkret definieren. Portugiesisch etwa ist auch die Amtssprache in Brasilien. Allerdings gibt es im Brasilianischen viele Unterschiede sowohl in der Umgangssprache als auch bei Fachbegriffen.

Daher ist es durchaus relevant, ob als Ländercode pt_PT (Portugiesisch) oder pt_BR (Brasilianisches Portugiesisch) konfiguriert wird.

Fachbegriffe müssen stets einheitlich übersetzt werden. Produktnamen hingegen sollten möglicherweise nicht in die Zielsprache übersetzt werden. In allen Fällen hilft die Glossarfunktion von DeepL dabei, die korrekte Terminologie zu erhalten.

Für TYPO3 gibt es das kostenlose Add-On "deepltranslate-glossary", dessen Verwendung wir dringend empfehlen. Damit können Glossar-Einträge als Datensatz in TYPO3 angelegt und mit DeepL synchronisiert werden. Bei allen Übersetzungen wird der Glossar dann von DeepL herangezogen.

Euer Kunde sollte daher im Vorfeld einen Glossar mit den wichtigsten Fachbegriffen und anderen bevorzugten Übersetzungen erstellen. Diese werden dann zu Beginn von ihm selbst oder von euch in TYPO3 eingepflegt. Weitere Glossar-Einträge können jederzeit ergänzt werden, wenn sie sich im Laufe der Arbeiten als notwendig herausstellen.

Auch das konkrete Vorgehen bei der Übersetzung sowie Zuständigkeiten werden eingangs mit dem Kunden besprochen: Welche Seiten sollen zuerst übersetzt werden? Wer ist verantwortlich für rechtlich relevante Texte wie die Datenschutzerklärung?

Mit der kostenlosen Version der DeepL API steht euch nur ein Glossar zur Verfügung. Das mag ausreichend klingen, wenn ihr nur mit einer neuen Zielsprache plant – ist es aber nicht:

• Jede TYPO3-Instanz erhält eine abweichende Glossar-ID (Production, Staging, Entwicklungs- oder Abnahme­umgebungen, …)
• Jede Sprache in TYPO3 sorgt für weitere Glossare bei DeepL. Bei Englisch, Deutsch und Spanisch erhaltet ihr bereits vier Glossare (en => es, en => de, de => es, es => de), weil übersetzte Inhalte auch als Ausgangssprache für weitere Übersetzungen gewählt werden können

Je nach Textumfang eurer Website könnt ihr im kostenlosen Plan zudem das monatliche Zeichenlimit erreichen. Vor allem beim erstmaligen Aufbau der neuen Sprachversion mit einigen Testläufen.

Ihr benötigt also einen Pro-Account für die API. Die anfallenden Kosten müsst ihr mit dem Kunden klären: www.deepl.com/en/pro-api#api-pricing

Diese Frage muss nicht schon zu Beginn beantwortet werden, aber euer Kunde sollte um diese Möglichkeit wissen: Was soll mit den Übersetzungen passieren, wenn die Inhalte in der Originalsprache aktualisiert werden?

Mit dem kostenpflichtigen Add-On "deepltranslate-auto-renew" können bestehende Übersetzungen in dem Fall automatisch mit DeepL aktualisiert werden.
Zu beachten ist allerdings: Alle vom Redakteur vorgenommenen Korrekturen und Verbesserungen in der Übersetzung werden dann natürlich überschrieben.

Daher ist im Projekt abzuwägen, ob ein Auto-Renew der richtige Weg ist. Es ist technisch möglich, die Option je Zielsprache ein- oder auszuschalten.

Übersetzungen beschränken sich nicht auf redaktionell pflegbare Seiten und Inhalte. Auch das Website-Template muss (in TYPO3 primär mit XLIFF-Sprachdateien) mehrsprachig eingerichtet sein: Buttons und Texte der Suchfunktion sind dort ebenso hinterlegt wie Hinweistexte für die Barriere­freiheit.
Dazu kommen weitere Komponenten, die berücksichtigt werden müssen.

Wir haben eine Checkliste für neue Sprachen erstellt, die in etwa diese Punkte umfasst:

• Konfiguration der Sprache in der Site Configuration
• Solr Core für den Suchindex der neuen Sprache
• Übersetzung der Frontend-Labels in der locallang.xlf
• ggf. weitere Übersetzungen in TypoScript (_LOCAL_LANG)
• Übersetzungen der Kontaktformulare und der damit versandten E-Mails
• Übersetzung des Cookie Consents
• Anlegen der gewünschten Begriffe im DeepL-Glossar

Besonders zu beachten sind rechtlich relevante Inhalte, vom Cookie Consent bis zur Datenschutz­erklärung. Im besten Fall kann die Rechts­abteilung des Kunden oder eine beauftragte Fachkraft eine vollständige, rechtssichere Übersetzung liefern. Oder sie nimmt eine eingehende Prüfung einer automatisiert übersetzten Fassung vor.

Dieser Abschnitt richtet sich an TYPO3-Integratoren und Entwickler. Die Projektleiter unter euch dürfen ohne schlechtes Gewissen zum nächsten Abschnitt springen.

Zur Installation bereit stehen die folgenden TYPO3-Extensions:

Die Dokumentation beschreibt die notwendigen Schritte: https://docs.typo3.org/p/web-vision/deepltranslate-core/5.1/en-us/Administration/Configuration/Index.html

Wie in der Dokumentation beschrieben, unterstützt die DeepL-Extension Backend-Felder vom Typ "Input" und "Text" (inkl. Richtext). Voraussetzung ist, dass die Felder mit 'l10n_mode' => 'prefixLangTitle' konfiguriert sind. Unter Umständen müsst ihr dies mittels TCA Overrides anpassen. Andernfalls werden die Inhalte des Feldes nicht übersetzt.

$GLOBALS['TCA']['tx_news_domain_model_news']['columns']['teaser']['l10n_mode'] = 'prefixLangTitle';
$GLOBALS['TCA']['tx_news_domain_model_news']['columns']['bodytext']['l10n_mode'] = 'prefixLangTitle';
$GLOBALS['TCA']['tx_news_domain_model_news']['columns']['description']['l10n_mode'] = 'prefixLangTitle';
$GLOBALS['TCA']['tx_news_domain_model_news']['columns']['alternative_title']['l10n_mode'] = 'prefixLangTitle';

Eigentlich logisch: Solange die übersetzte Version der Website noch im Aufbau ist, möchten wir sie wahrscheinlich nicht schon Besuchern zeigen. Wie immer ihr eure Navigation in TYPO3 also erstellt – sorgt dafür, dass die neue Sprache dort nicht schon auswählbar wird.

Das kann übersehen werden: TYPO3 ergänzt automatisch Tags im Quelltext, wenn es für eine Seite Versionen in anderer Sprache gibt.

<link rel="alternate" hreflang="en-US" href="https://www.example.org/about-us/">
<link rel="alternate" hreflang="de-de" href="https://www.example.org/de/ueber-uns/">
<link rel="alternate" hreflang="x-default" href="https://www.example.org/about-us/">

Mit diesen Tags merkt Google, wenn ihr Übersetzungen anlegt. Und dann tauchen die übersetzten Seiten schneller in Suchergebnissen auf, als ihr "noindex" sagen könnt.

Wir haben daher einen kleinen Event Listener im Sitepackage ergänzt, mit dem die gewünschten Sprachen aus der Generierung der hreflang-Tags herausgenommen werden.

<?php

declare(strict_types=1);

namespace Mfd\MySitepackage\EventListener;

use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Frontend\Event\ModifyHrefLangTagsEvent;

/**
 * Filter/remove certain languages from the generated hreflang tags.
 * Used to prevent publishing page translations while a new frontend language is still set up.
 */
#[AsEventListener(
    identifier: 'my-sitepackage/hreflang-tag-filter',
    after: 'typo3-seo/hreflangGenerator',
)]
final readonly class HrefLangTagFilter
{
    public function __invoke(ModifyHrefLangTagsEvent $event): void
    {
        $defaultLanguages = [
            'en-US',
            'x-default'
        ];
        $disabledLanguages = [
            'de-DE',
            'fr-FR'
        ];

        $hrefLangs = $event->getHrefLangs();

        // Remove unwanted language codes from array:
        $filteredHrefLangs = array_diff_key($hrefLangs, array_flip($disabledLanguages));

        // Check if the remaining languages are only the default.
        // In that case, no hreflang tags should be rendered.
        $remainingKeys = array_keys($filteredHrefLangs);
        sort($remainingKeys);
        sort($defaultLanguages);
        if ($remainingKeys === $defaultLanguages) {
            $filteredHrefLangs = [];
        }

        $event->setHrefLangs($filteredHrefLangs);
    }
}

Sobald die neue Sprachversion der Website vorbereitet ist, wird die Sprache wieder aus dem Event Listener entfernt. Macht dies also zu einem Teil eurer Checkliste.

Wir empfehlen, mit einigen ausgewählten Seiten zu starten, die für den Kunden besonders wichtig sind. Sie sollten möglichst auch einige Glossarbegriffe enthalten. Lasst die erstellten Übersetzungen anschließend durch eure Redakteure prüfen. Wenn notwendig, erweitert den Glossar. Dann folgt der nächste Seitenbereich.

Durch das schrittweise Übersetzen von Inhalten können Probleme frühzeitig erkannt und auf den weiteren Seiten vermieden werden.

News (und andere Plugin-Datensätze) werden zentral in einem Ordner gespeichert und dann auf verschiedenen Seiten referenziert. Es ist sinnvoll, diese Inhalte recht frühzeitig in ihren Ordnern zu übersetzen. Dann sind die Übersetzungen bereits vorhanden, wenn ihr die dazugehörigen Seiten übersetzt. Sonst zeigt das ins Deutsche übersetzte News-Plugin im Frontend noch die englischen Originale an.

Deutsch ist eine Sprache, in der Begriffe schnell eine gewisse Länge erreichen. Dabei meine ich nicht die kuriosen Extremfälle wie die ehemalige "Grundstücks­verkehrs­genehmigungs­zuständigkeits­übertragungs­verordnung".
Schon die Übersetzung von "product portfolio" (7 + 9 Zeichen) zu "Produktportfolio" (16 Zeichen ohne Leerzeichen) kann zu anderen Zeilen­umbrüchen führen. Oder zu Layout­problemen in schmalen Teaser-Boxen.

Dann ist es gut, wenn man im Textfeld die Möglichkeit hat, Soft-Hyphens für bedingte Umbrüche zu setzen. Das ist allerdings ein redaktioneller Eingriff, der bei der abschließenden Prüfung manuell erfolgt.

Je kürzer der Originaltext, desto mehr Interpretations­spielraum hat DeepL für seine Übersetzung. Viele Begriffe lassen sich auf verschiedene Weise übersetzen und können dann ganz unterschiedliche Bedeutungen haben. Hier kommt es schnell zu fehlerhaften bis komischen Ergebnissen.

• Aus "Quality policy", also einer Richtlinie, wird "Qualitätspolitik"
• Aus "Light is the new green", einem Hinweis auf umweltfreundliche Leichtfahrzeug­räder, wird "Licht ist das neue Grün"
• Aus "[Client name] on the road" (gemeint: "unterwegs"/"auf Achse"/"auf Reisen") wird "[Kundenname] auf der Straße"

DeepL neigt also dazu, Begriffe eher wortwörtlich als sinngemäß zu übersetzen.

Hin und wieder kommt es vor, dass die Verwendung des DeepL-Buttons keine Übersetzungen zurückliefert. Die Datensätze der Zielsprache enthalten dann den unveränderten Originaltext.

In dem Fall half es bislang immer, den "Glossare synchronisieren"-Button zu betätigen und die Übersetzung danach erneut anzustoßen.

Die Praxis zeigt: Egal, wie aktiv euer Kunde an seiner Website arbeitet – bei der Arbeit an Übersetzungen wird er immer Inhalte finden, die veraltet sind oder überarbeitet werden sollten. Dies kann den weiteren Übersetzungsvorgang zumindest verzögern.

Ich selbst nutze DeepL seit Jahren beruflich wie privat, vor allem für Übersetzungen von Deutsch zu Englisch. Und doch verwende ich nie das erste zurück­gelieferte Ergebnis. Ich passe Sätze und Formulierungen nach meinem Empfinden an, korrigiere vereinzelt auch Grammatik. Teilweise lasse ich Übersetzungen von Grammarly erneut prüfen.
Fun Fact: Genau so ist auch die englische Version dieses Artikels entstanden.

Sind automatisierte Übersetzungen in TYPO3 also empfehlenswert? Ja, ganz klar. Es ist eine deutliche Arbeits­erleichterung und Zeitersparnis.
Muss es dabei die vollautomatische Lösung sein oder sollten Redakteure jede Übersetzung abschließend prüfen? Diese Frage müsst ihr im Projekt gemeinsam mit eurem Kunden beantworten.