E-Mail-Lokalisierung: Kampagnen-Übersetzung in allen gängigen ESPs

Ich verantworte das Lifecycle-Marketing und habe daher schon unzählige Stunden in Kampagnen-Editoren verbracht. Dabei habe ich die E-Mail-Lokalisierung immer wieder unterschätzt. Eine Landingpage zu übersetzen, folgt meist einem klaren Schema. Bei E-Mail-Kampagnen sieht das anders aus: Hier ist die Arbeit in jedem Tool eine völlig andere, weil jede Plattform ihre eigene Definition davon hat, was eine „Sprache“ eigentlich ist.

Manche Plattformen übersetzen die Texte automatisch. Andere bieten leere Sprach-Slots an, die Sie selbst befüllen müssen. Und bei einer müssen Sie sogar Logik-Verzweigungen direkt in den E-Mail-Body schreiben. Doch eines haben alle gemeinsam: Die Texte sind vollgestopft mit Template-Syntax. Diese muss die Übersetzung absolut unbeschadet überstehen – Zeichen für Zeichen –, sonst schlägt der Versand fehl.

Dieser Leitfaden zeigt Ihnen, wie die gängigen Plattformen wirklich funktionieren, wie Sie Texte exportieren und wieder importieren und welche Aspekte der Lokalisierung überall gleich bleiben.

Drei Arten, wie E-Mail-Plattformen mit Sprachen umgehen

Bevor wir uns die einzelnen Plattformen im Detail ansehen, sollten Sie wissen, mit welcher der drei Architekturen Sie es zu tun haben. Davon hängt Ihr gesamter Workflow ab – und meistens lässt sie sich nicht ändern.

In der mittleren Zeile sind die meisten professionellen mehrsprachigen Programme angesiedelt. Dieser Zeile widmet der Leitfaden auch die meiste Zeit, denn genau dann, wenn die Plattform einem lediglich ein „leeres Raster an Locales“ vorsetzt, wird ein strukturierter Übersetzungs-Workflow unverzichtbar.

E-Mail-Lokalisierung in Braze

Braze nutzt das Tag-and-Fill-Modell und weist die markanteste Syntax von allen auf. Dabei wird jeder übersetzbare Teil einer E-Mail in einen Liquid-Tag mit einer ID eingeschlossen:

{% translation greeting %}Hello!{% endtranslation %}

Die Grundform lautet {% translation ihre_id_hier %}Standardtext{% endtranslation %}, wobei die IDs innerhalb einer Nachricht eindeutig sein müssen. Markierter Text lässt sich über einen Shortcut im Editor umschließen (Cmd+Alt+L unter macOS, Strg+Alt+L unter Windows). Braze selbst nimmt keine Übersetzungen vor: Sie stellen diese per CSV-Upload oder über die Übersetzungs-API bereit, die zum Zeitpunkt der Erstellung dieses Textes im Early Access verfügbar ist.

Die dokumentierten Limits fallen ins Gewicht, sobald eine Kampagne ernst wird:

Verschachtelte Übersetzungs-Tags werden nicht unterstützt. Die Locale wird aus dem Benutzerprofil bezogen (konfiguriert unter Settings → Localization Settings), entweder über die Standardattribute language und country oder über ein benutzerdefiniertes Attribut; wenn beides zutrifft, hat das benutzerdefinierte Attribut Vorrang.

Zwei Besonderheiten von Braze sollten Sie kennen, bevor Sie beginnen:

Das Umschließen einer URL unterbricht das Click-Tracking, sofern der umschlossene Teil nicht auf ? oder & endet. Braze dokumentiert den Workaround direkt:

<a href="https://{% translation id_1 %}example.com{% endtranslation %}?">Shop Now</a>

Öffnen Sie die Übersetzungs-CSV nicht in Excel. Die Braze-eigene Dokumentation rät davon ab, da es zu Darstellungsproblemen bei nicht-englischen Zeichen kommen kann. Dies ist die häufigste Ursache dafür, dass ein Braze-Lokalisierungslauf unbemerkt beschädigt wird, und der Grund liegt bei Excel, nicht bei Braze: Excel stellt Vermutungen zur CSV-Kodierung an und liegt damit falsch.

Die Content Blocks von Braze können eigene Übersetzungen enthalten. So lokalisieren Sie einen gemeinsamen Footer einmalig, statt ihn in jeder Kampagne neu anzulegen. Referenzieren Sie diese als {{content_blocks.${your_block}}}; über Liquid eingefügte Blöcke bleiben verknüpft und werden automatisch aktualisiert, während dies bei Blöcken, die über das Dropdown-Menü des Editors hinzugefügt wurden, nicht der Fall ist. Falls für einen Block keine Übersetzung für eine bestimmte Locale vorliegt, wird er in der Originalsprache ausgegeben, statt einen Fehler zu verursachen.

Wenn Sie lieber verzweigen statt zu taggen, unterstützt Braze auch den DIY-Weg:

{% if ${language} == 'en' %}
English content
{% elsif ${language} == 'es' %}
Spanish content
{% else %}
Fallback content
{% endif %}

Beachten Sie, dass das Attribut innerhalb eines Liquid-Tags schlicht ${language} lautet, während es im E-Mail-Body umschlossen wird: {{${language}}}. Braze empfiehlt, immer einen {% else %}-Zweig einzubauen, da bei manchen Nutzern keine Sprache eingestellt ist, eine nicht unterstützte Sprache vorliegt oder die Sprache auf dem Gerät nicht ermittelt werden kann.

Docs: Braze-Lokalisierung

Customer.io E-Mail-Lokalisierung

Customer.io hat den entgegengesetzten Ansatz gewählt: Die Lokalisierung ist nativ integriert, sie findet direkt im Message-Editor statt, und es gibt einen KI-Button für automatische Übersetzungen. Sie erstellen die Nachricht in einer Standardsprache und fügen Sprachvarianten hinzu, ohne Ihre Kampagne zu verzweigen. Das funktioniert für E-Mail, SMS, WhatsApp, Push und In-App.

Den Namen des Sprachattributs können Sie frei wählen. Unter Workspace Settings → Language settings legen Sie fest, welches Profilattribut die Sprache enthält – das kann language sein, locale oder was auch immer Ihr CRM bereits verwendet. Die Werte müssen entweder ein zweistelliger Code (en) oder ein durch Bindestrich getrenntes Sprach-Region-Paar (en-US) sein. Bei den Werten wird nicht zwischen Groß- und Kleinschreibung unterschieden, sodass sowohl es-MX als auch es-mx funktionieren; der Bindestrich ist jedoch zwingend erforderlich.

Die automatische Übersetzung deckt den E-Mail-Body, Betreffzeilen und Preheader-Texte ab. Nicht abgedeckt ist hingegen die folgende Liste – die man sich am besten an die Wand hängen sollte:

• Bilder (Alt-Texte werden hingegen übersetzt)
• E-Mail-Layouts im Rich-Text- und Code-Editor
• Statischer Liquid-Text, Attributwerte und Filterwerte
• Snippets
• Text in benutzerdefinierten Komponenten, sofern diese nicht vorher entkoppelt werden

Der dritte Punkt verdient ein Beispiel, da er am tückischsten ist. In der Dokumentation von Customer.io zur Lokalisierung wird diese Zeile verwendet:

Bonjour {{ customer.first_name | default:"ami" }}

Das Wort ami dient als Fallback für alle, für die kein Vorname hinterlegt ist. Es ist echter, sichtbarer Text, der in einem Liquid-Filter steckt – und die automatische Übersetzung rührt ihn nicht an. Schicken Sie das an ein deutsches Publikum, und ein Teil Ihrer Empfänger wird mit ami begrüßt. Jeder Fallback-String in jedem default:-Filter muss für jede Variante manuell übersetzt werden, ohne dass das Interface Sie auch nur einmal daran erinnert.

Zwei weitere Einschränkungen, die Sie einplanen sollten: Übersetzungen werden nicht automatisch aktualisiert, wenn Sie die Standardvorlage ändern, und A/B-Tests mit Übersetzungen funktionieren bei einmaligen Sendungen, aber nicht bei API-getriggerten Broadcasts oder Automatisierungen.

Snippets verdienen eine gesonderte Erwähnung. Sie sind der Mechanismus für wiederverwendbare Inhalte ({{snippets.your_snippet}}, standardmäßig 16 KB pro Stück), doch die automatische Übersetzung lässt sie außen vor. Customer.io empfiehlt, die Bedingungen direkt im Snippet selbst zu hinterlegen:

{% if customer.language == 'fr' %}
  Se désabonner
{% elsif customer.language == 'de' %}
  Abmelden
{% else %}
  Unsubscribe
{% endif %}

Ein Customer.io-Programm läuft also meist auf native Varianten für die Nachrichteninhalte hinaus, ergänzt durch manuell gepflegte Bedingungen in jedem geteilten Snippet. Das sollte man wissen, bevor man davon ausgeht, dass der KI-Button den gesamten Bereich abdeckt.

Docs: Customer.io-Lokalisierung

E-Mail-Lokalisierung in Klaviyo

Die Funktion von Klaviyo heißt Smart Translations. Sie übersetzt Nachrichteninhalte direkt im Kampagnen- oder Flow-Editor maschinell in über 60 Sprachen. Sie aktivieren sie unter Einstellungen → Konto → Übersetzung mit dem Schalter „Nachrichten übersetzen“. Die Funktion setzt ein kostenpflichtiges Konto voraus und ist in der kostenlosen Testversion nicht verfügbar.

Klaviyo dokumentiert eine spezifische Liste der Elemente, die automatisch übersetzt werden: Textblöcke, Labels und Alternativtexte. Betreffzeilen stehen nicht auf dieser Liste. Prüfen Sie dies also in Ihrem Konto, bevor Sie davon ausgehen, dass eine Kampagne vollständig abgedeckt ist.

Die Sprachermittlung nutzt standardmäßig das Feld „Locale“ des Profils und greift auf „Country“ oder „Language“ zurück, falls diese stattdessen vorhanden sind. Klaviyo akzeptiert BCP-47-Codes (en-GB, es-ES) sowie Klartextwerte wie English oder French.

Zwei Dinge machen die Arbeit mit Klaviyo besonders angenehm. Das erste ist eine „Do Not Translate“-Liste: Markennamen, Produktnamen und alle Begriffe, die ein Modell niemals anrühren soll – einmalig auf Kontoebene festgelegt. Die meisten Plattformen bieten kein Äquivalent dazu, und das ist der entscheidende Unterschied, ob Ihr Produktname in zehn Sprachen derselbe bleibt oder zu zehn verschiedenen Wörtern wird.

Das zweite ist das Menü zum Überschreiben einzelner Elemente. Bei jedem übersetzten Element stehen Ihnen die Optionen Re-translate, Match source, Edit und Ignore zur Verfügung, und Sie können über die Pfeile am oberen Rand des Editors zwischen den Sprachen wechseln. Dadurch wird die Überprüfung zu einer gezielten Kontrolle markierter Stellen statt zu einem kompletten Korrekturlesen.

Klaviyo unterstützt auch einen CSV-Roundtrip – ideal, wenn Sie mit Übersetzern oder externen Tools arbeiten. Unter „Translate“ → Aktionsmenü finden Sie die Option Export CSV, entweder im Smartling- oder im Simple-Format. Die Spalten sind block_id (die eindeutige Kennung für jeden übersetzbaren String), source (der Originaltext) und eine Spalte pro Sprache, die mit dem jeweiligen Sprachcode benannt ist. Die Regeln sind streng und sinnvoll: Bearbeiten oder löschen Sie keine block_id-Werte, fügen Sie keine Zeilen hinzu und ändern Sie die source-Werte nicht.

Eines überrascht Nutzer, die von Braze oder Customer.io kommen, immer wieder: Klaviyo ist nicht Liquid. Es verwendet die Django-Template-Syntax.

{% if person|lookup:'Loyalty Points' > 150 %}
Hey VIP! You've always got free shipping & free returns
{% elif person|lookup:'Loyalty Points' > 0 %}
You have {{ person|lookup:'Loyalty Points' }} points, and you just need 150 to become a VIP!
{% else %}
Have you heard about our VIP program? Join today on our website to start earning rewards.
{% endif %}

Die Tags sehen Liquid zum Verwechseln ähnlich, bis einem der Unterschied zwischen elif und elsif den Nachmittag ruiniert. Eine Personalisierung mit Fallback sieht so aus: {{ first_name|default:'friend' }}.

Docs: Klaviyo Smart Translations · Django-Syntax

E-Mail-Lokalisierung in Mailchimp

Mailchimp bietet keine native Funktion für mehrsprachige Kampagnen. Stattdessen nutzt man bedingte Merge-Tags; der dokumentierte Ansatz besteht darin, alle Sprachen in eine einzige E-Mail zu schreiben und die Auswahl den Bedingungen zu überlassen.

*|IF:MC_LANGUAGE=es|*
Spanish content here.
*|ELSEIF:MC_LANGUAGE=de|*
German content here.
*|ELSE:|*
Display English content for everyone else.
*|END:IF|*

*|MC_LANGUAGE|* enthält den Sprachcode des Kontakts, während *|MC_LANGUAGE_LABEL|* den lesbaren Namen liefert. Mailchimp versucht, die Sprache über den Browser des Abonnenten zu erkennen; alternativ lässt sie sich pro Kontakt unter Profil → Einstellungen → Sprache oder gesammelt per Bulk-Import festlegen. Beachten Sie, dass *|END:IF|* sowohl IF- als auch IFNOT-Blöcke abschließt.

Meist ist es genau diese eine Einschränkung, die den Ausschlag gibt. Eine lokalisierte E-Mail mit einem Betreff in der falschen Sprache wird gar nicht erst geöffnet – da spielt der eigentliche Inhalt dann auch keine Rolle mehr. Deshalb landen die meisten Teams, die Mailchimp für mehr als zwei Sprachen nutzen, am Ende doch bei separaten Kampagnen pro Sprache. Damit bringt der Ansatz mit den bedingten Merge-Tags keinerlei Vorteile mehr. Das sollte man besser schon in der Planungsphase wissen und nicht erst, wenn das Template bereits fertig erstellt ist.

Docs: Mailchimp-Inhalte übersetzen

Iterable E-Mail-Lokalisierung

Iterable verfügt über eine echte Locales-Funktion, und die Dokumentation ist erfrischend direkt darin, was das bedeutet – und was nicht:

Locales übersetzen keine Inhalte.

Sie erhalten das Gerüst für die Varianten; die Übersetzungen liefern Sie selbst. Im Gegenzug teilen sich alle Varianten eine einzige templateId. So bleiben Ihre Kennzahlen gebündelt, statt sich auf zehn verschiedene Templates zu verteilen. Wer schon einmal versucht hat, Berichte für eine Kampagne zu erstellen, die in einzelne Sprachkopien aufgeteilt war, weiß: Allein dafür lohnt sich der Aufwand.

Das Feld muss exakt locale heißen. Iterable weist ausdrücklich darauf hin, dass Nutzer den Varianten nicht zugeordnet werden können, wenn Sie es languagePreference oder anders nennen. Locale-Namen folgen ISO-639 plus ISO-3166 (fr-CA, fr-FR), wobei auch dreistellige Codes unterstützt werden. Local****es können nach der Erstellung nicht mehr umbenannt werden – legen Sie also Ihre Namenskonvention fest, bevor Sie zwanzig davon anlegen. Ein leeres Locale-Feld erhält die Standard-Lokalisierung; bei fehlender Übereinstimmung entscheidet eine Einstellung auf Projektebene, ob der Versand übersprungen oder die Standardversion gesendet wird.

Iterable rät zudem ausdrücklich von Eigenbau-Lösungen ab:

Obwohl Iterable eine flexible Plattform ist und Sie mehrsprachige Inhalte möglicherweise auch mithilfe von Handlebars oder Catalog erstellen können, entsprechen diese Methoden nicht den Best Practices für die Lokalisierung.

Als Templating-Sprache wird Handlebars verwendet, und bei Feldnamen muss die Groß- und Kleinschreibung beachtet werden. Es gibt eine Besonderheit im WYSIWYG-Editor, über die man leicht stolpern kann: Bedingungen müssen in HTML-Kommentare eingeschlossen werden, da der Editor sie sonst unbrauchbar macht.

<!--{{#if activeUser}}-->
    <div>Hi active user!</div>
<!--{{else}}-->
    <div>Hi inactive user</div>
<!--{{/if}}-->

Für den Roundtrip lassen sich Template-Inhalte über GET /api/templates/email/get für Übersetzer extrahieren.

Docs: Iterable in mehreren Sprachen

Brevo E-Mail-Lokalisierung

Brevo gehört zu den Plattformen, die die Übersetzung direkt im Tool ermöglichen, und ist bei dieser speziellen Funktion der direkteste Konkurrent von Mailchimp. Sie erstellen eine einzige Kampagne, die auf den Sprach- oder Ländercode des Kontakts reagiert, klicken auf Sprachen hinzufügen, und Brevo dupliziert die Kampagne pro Sprache. Die Übersetzung erfolgt dann manuell oder mit dem KI-Assistenten Aura.

Die Auswahl an Elementen, die sich pro Sprache anpassen lassen, ist umfangreicher als bei den meisten anderen Anbietern: Absendername, Betreffzeile, Vorschautext und das E-Mail-Design selbst, dazu Antwortadresse, Google-Analytics-Tracking und eine eigene Abmeldeseite. Besonders hervorzuheben ist die Betreffzeile, da Mailchimp genau das nicht leisten kann.

Die dokumentierten Einschränkungen: Dateibasierte Übersetzungen werden nicht unterstützt (somit gibt es keinen CSV-Roundtrip, was Brevo für die Zusammenarbeit mit externen Übersetzungsdiensten ausschließt), A/B-Tests sind nicht möglich, und für gespeicherte Abschnitte muss jeweils eine eigene Version pro Sprache erstellt werden. Kontakte, deren Sprachattribut keine Entsprechung findet, erhalten die Standardversion.

Docs: Mehrsprachige Kampagnen in Brevo

Liquid, Handlebars und Merge-Tags: Was erhalten bleiben muss

Ganz gleich, welche Plattform Sie nutzen – für den eigentlichen Übersetzungsschritt gibt es eine strikte Vorgabe: Ihr Text enthält Template-Syntax, und jedes einzelne Zeichen davon muss exakt so zurückkommen, wie es eingegeben wurde. Ein übersetztes {% endif %} führt unweigerlich zu einem fehlerhaften Versand.

So sieht die Syntax auf den verschiedenen Plattformen in diesem Leitfaden aus:

Drei Fehlerquellen sind für fast alles verantwortlich, was hier schiefgeht.

Das Modell übersetzt das Token. Man erhält {{ prénom }} oder {% si %} zurück, und der Versand schlägt fehl oder der Text wird wortwörtlich ausgegeben. Jedes ernstzunehmende Tool maskiert Token, bevor der Text an ein Modell geht, und stellt sie danach wieder her, damit das Modell sie nie als Wörter wahrnimmt.

Das Modell verschiebt das Token. Da sich die Wortstellung zwischen Sprachen legitimerweise ändert, sollte sich ein Token auch bewegen. Problematisch wird es, wenn es in den falschen Teilsatz rutscht oder ein {% if %} und sein {% endif %} in der falschen Reihenfolge landen. Die Position ist entscheidend; die Lösung besteht darin, zu prüfen, ob die Menge der ausgegebenen Token mit der Menge der eingegebenen übereinstimmt, und den Block andernfalls neu zu verarbeiten.

Die Anzahl der Token ändert sich. Besonders gefährlich ist ein verlorenes Token, da die E-Mail trotzdem gerendert wird – nur eben ohne Namen oder ohne einen bestimmten Zweig. Deshalb ist das Zählen wichtiger als das bloße Drüberschauen.

Und die Regel, die alle drei Punkte abdeckt: Bedingte Verzweigungen sind separate Strings. In dieser Zeile stecken zwei unabhängige Textpassagen. Bekommt ein Übersetzer oder ein Modell das Ganze als einen einzigen Block vorgesetzt, wird das Ergebnis für beide Teile schlechter ausfallen, als wenn man sie einzeln und mit Kontext übergibt:

{% if ${loyalty_tier} == 'gold' %}Gold members get an extra 10%.{% else %}Join Gold for an extra 10%.{% endif %}

HTML-E-Mails und String-Tabellen sind zwei völlig verschiedene Aufgaben

An diesem Punkt gabelt sich der Weg, was über das gesamte Setup entscheidet – und meistens bemerkt man das erst auf halber Strecke.

Manche E-Mail-Inhalte sind ein Dokument: ein HTML-Template, eine gerenderte E-Mail – etwas mit Struktur und einem Lesefluss, der sich von oben nach unten zieht. Man möchte sie als zusammenhängenden Text übersetzen, da die Überschrift und der Fließtext zusammengehören. Ein Übersetzer, der beides vor Augen hat, trifft bessere Entscheidungen als jemand, der nur den einen oder den anderen Teil sieht.

Andere E-Mail-Inhalte sind eine String-Tabelle: eine Liste mit Keys, in der jede Zeile für sich steht. cta_button, subject_line, footer_unsub. Diese bringen Metadaten mit, die wichtiger sind als der eigentliche Text: ein Key, der sich niemals ändern darf, ein Kontexthinweis und oft ein Zeichenlimit, da eine zu lange Betreffzeile im Posteingang abgeschnitten wird.

Braze-CSVs, Klaviyo-CSVs und jedes Lokalisierungsformat aus der Softwarewelt (gettext PO, XLIFF) sind String-Tabellen. HTML-Templates sind Dokumente. Behandelt man eine String-Tabelle als Dokument, verliert man die Keys; behandelt man ein Dokument als String-Tabelle, zerstückelt man den Text in zusammenhanglose Fragmente.

Deshalb haben wir die Unterstützung für String-Dateien in Transept als eigenständigen Pfad entwickelt, statt sie in den Dokumenten-Import zu integrieren. Eine CSV mit E-Mail-Texten wird als Raster dargestellt: Key, Ausgangstext und Übersetzung, mit dem Zeichenlimit als Live-Zähler und dem Kontexthinweis zu jeder Zeile.

Das Entscheidende dabei ist, dass die Datei das System in genau der Form wieder verlässt, in der sie eingegangen ist. Man exportiert die übersetzte Originaldatei mit den Keys und Spalten genau dort, wo die Plattform sie erwartet, anstatt ein Ergebnis zu erhalten, das man anschließend mühsam von Hand umformatieren muss.

Was wir bei der Entwicklung der E-Mail-Unterstützung für Transept gelernt haben

Wir haben den Import von String-Dateien genau für diesen Workflow eingeführt, und dabei kamen Dinge ans Licht, die ich so noch nirgendwo dokumentiert gesehen habe. Das sind unsere eigenen Erkenntnisse, direkt aus unserem Code und unseren Testläufen.

„50% off“ ist technisch gesehen eine printf-Konvertierung

Software-Strings verwenden häufig printf-Platzhalter: %s, %d, %1$s. Wenn man diese vor der Übersetzung maskiert, akzeptiert die naheliegende Regex den vollständigen Satz an printf-Flags, wozu auch das Space-Flag gehört (% d gibt ein Leerzeichen vor positiven Zahlen aus). Das ist gültiges printf, und es zu akzeptieren, ist durchaus vertretbar.

Für Marketingtexte ist das allerdings eine Katastrophe. Wenn das Space-Flag akzeptiert wird, enthält 50% off einen Treffer: % o wird als oktale Konvertierung mit Space-Flag interpretiert. Das Gleiche gilt für 100% organic. Ebenso für Up to 70% off – die mit Abstand häufigste Formulierung in Werbe-E-Mails.

Wir haben beide Varianten getestet:

Das Maskieren von % o verwandelt Ihre Rabattzeile in einen Platzhalter und liefert dem Modell einen verstümmelten Satz. Wir schließen das Space-Flag ganz bewusst aus und verlieren dadurch nichts: Keine echte String-Tabelle verwendet es.

Brazes Personalisierungs-Tag hat drei schließende geschweifte Klammern

Diesen Fall haben wir erst beim Schreiben dieses Leitfadens entdeckt – ein gutes Argument dafür, Leitfäden zu schreiben.

Die Braze-Syntax lautet {{${first_name}}}. Zählen Sie die schließenden Klammern: erst die } des Attributs selbst, dann die zwei, die den Liquid-Output-Tag beenden. Drei hintereinander.

Fast jeder Liquid-Tokenizer scannt nicht-gierig bis zum ersten }}. Bei {{${first_name}}} schließt er eine Klammer zu früh ab: Er erfasst {{${first_name}} und lässt eine einzelne } im zu übersetzenden Text zurück. Der Token wirkt verarbeitet, doch die verwaiste Klammer landet als Fließtext beim Modell – und kommt von dort verschoben, verdoppelt oder gar nicht mehr zurück.

{{${first_name}}}, your spring sale starts now

  non-greedy scan  →  token: {{${first_name}}     leftover: "}, your spring sale starts now"
  brace-aware scan →  token: {{${first_name}}}    leftover: ", your spring sale starts now"

Genau das ist bei unserem Tool passiert. Wir haben den Fehler behoben, indem wir eine Verschachtelungsebene innerhalb des Tokens zugelassen haben, und die exakte Braze-Syntax in unsere Testsuite aufgenommen. Falls Sie eigene E-Mail-Tools betreuen, testen Sie diese gezielt mit {{${attribute}}}, denn die einfache Form {{ attribute }} funktioniert reibungslos und kaschiert den Fehler vollkommen.

Anführungszeichen in Platzhaltern führen zu Fehlern in JSON-Antworten

Wenn Sie einen Batch von Strings an ein Modell senden und die Antwort auf JSON festlegen, beendet ein nicht maskiertes " innerhalb eines Antwort-Strings diesen vorzeitig und der Rest des Batches wird verworfen. Wir stießen auf dieses Problem bei Platzhaltern, die Attribute in Anführungszeichen enthielten, und konnten es bei etwa 58 % der Durchläufe mit einem Modell reproduzieren.

Die Lösung liegt nicht in besseren Maskierungsanweisungen im Prompt. Vielmehr muss das Übertragungsformat anführungszeichenfrei gestaltet werden, damit der Fehler gar nicht erst auftreten kann: Das Modell sieht nur Platzhalter ohne Anführungszeichen, und die kanonische Form mit Anführungszeichen wird erst im Nachhinein wiederhergestellt. Ein Modell per Prompt anzuweisen, das JSON-Format nicht zu verletzen, funktioniert meistens – und das ist das schlechtestmögliche Zuverlässigkeitsprofil, da man die Fehler gar nicht bemerkt.

Fuzzy-Einträge sind ein Signal, keine Übersetzung

Stammen Ihre Strings aus gettext-PO-Dateien, enthalten die Einträge ein Fuzzy-Flag. Es signalisiert: „Dieser Treffer wurde automatisch zugeordnet und noch nicht von einem Menschen bestätigt.“ Werden Fuzzy-Einträge wie fertige Übersetzungen behandelt, übernimmt man eine Menge bloßer Vermutungen als geprüftes Ergebnis.

Wir schließen sie vom Seeding aus, übersetzen sie komplett neu und entfernen beim Export das Fuzzy-Flag. Zu diesem Zeitpunkt ist der Eintrag schließlich geprüft und die Markierung hinfällig.

Best Practices für die Lokalisierung von E-Mail-Kampagnen

Gewohnheiten, die den Unterschied zwischen einem reibungslosen Ablauf und einem mühsamen Prozess ausmachen – grob sortiert nach dem Ärger, den sie ersparen.

Legen Sie Ihre Sprachcodes einmalig auf Profilebene fest. Ob zweistellig oder mit Regionszusatz – Hauptsache konsistent. Die meisten Fälle, in denen „die Übersetzung nicht angezeigt wurde“, liegen daran, dass ein nl-BE-Profil auf eine nl-Nachricht trifft.

Schreiben Sie Kontext für jeden String, noch bevor er irgendwohin geht. Ein Übersetzer, der Shop the sale in einer Tabelle sieht, hat keine Ahnung, ob es sich um einen Button, eine Überschrift oder einen Link handelt – oder dass ihm nur achtzehn Zeichen zur Verfügung stehen. Jede Plattform, die ein Kontext- oder Beschreibungsfeld anbietet, bittet Sie um genau das, was die Qualität der Ergebnisse am stärksten verbessert, und doch füllt sie fast niemand aus.

Behandeln Sie Zeichenbeschränkungen als zentrale Vorgabe. Deutsche Texte sind etwa 1,5- bis 2-mal so lang wie englische. Ein CTA, der im Englischen passt, sprengt im Deutschen den Rahmen, und eine Betreffzeile wird im Posteingang mitten im Wort abgeschnitten. Geben Sie das Limit mit dem String weiter, damit die übersetzende Person den Zeichenzähler sieht.

Pflegen Sie eine „Do-not-translate“-Liste. Produktnamen, Markenbegriffe, Funktionsbezeichnungen. Klaviyo hat diese Funktion bereits integriert; auf anderen Plattformen ist sie Teil Ihres Glossars. So oder so: Legen Sie die Liste vor dem ersten Durchlauf fest – und nicht erst, wenn Sie Ihren Produktnamen in sechs verschiedenen Varianten vorfinden.

Übersetzen Sie die Fallbacks. Jeden default:-Filter, jeden {% else %}-Zweig und jedes „Hallo“, das erscheint, wenn der Name fehlt. Das sind die Strings, die nie in einer Vorschau auftauchen und daher nicht geprüft werden – dabei erreichen sie genau die Empfänger, über die Sie am wenigsten wissen.

Nutzen Sie getroffene Entscheidungen für alle Sendungen. Kampagnentexte wiederholen sich ständig: derselbe Footer, derselbe Abmelde-Hinweis, jedes Jahr der gleiche saisonale Rahmen. Ein Translation Memory sorgt dafür, dass Sie „Shop the sale“ einmal festlegen und dies für jede weitere Kampagne gilt, anstatt dass drei Varianten entstehen, weil bei drei Durchläufen drei unterschiedliche Entscheidungen getroffen wurden.

Führen Sie vor dem eigentlichen Versand einen Testlauf in jeder Sprache durch. Rendern Sie das tatsächliche Template mit einem echten Profil für jedes Locale. Bedingungen, die im Editor korrekt aussehen, können beim Rendern Fehler zeigen, die nur so sichtbar werden. In diesem Schritt fangen Sie unübersetzte Fallbacks oder fehlerhafte Zweige ab, solange es noch nichts kostet.

Häufig gestellte Fragen

Was ist E-Mail-Lokalisierung?

E-Mail-Lokalisierung bezeichnet die Anpassung einer E-Mail-Kampagne an eine andere Sprache und einen neuen Markt: von der Copy über die Betreffzeile und den Preheader bis hin zu Personalisierungs-Fallbacks und den Formatierungskonventionen des Ziel-Locales. Sie unterscheidet sich von einer reinen Übersetzung dadurch, dass die Template-Syntax (etwa Merge-Tags oder Liquid- und Handlebars-Bedingungen) zwingend erhalten bleiben muss, während gleichzeitig Vorgaben wie die Länge der Betreffzeile einzuhalten sind.

Welche E-Mail-Plattformen übersetzen Kampagnen automatisch?

Klaviyo (Smart Translations, über 60 Sprachen), Customer.io (automatische KI-Übersetzung für E-Mail, SMS, WhatsApp, Push und In-App) sowie Brevo (über den Aura-Assistenten) generieren Übersetzungen direkt im Editor. Braze und Iterable stellen zwar die Strukturen für verschiedene Locales bereit, setzen aber voraus, dass Sie die Übersetzungen selbst liefern. Mailchimp verfügt über keine native Funktion für mehrsprachige Kampagnen und setzt stattdessen auf bedingte Merge-Tags.

Kann ich eine Mailchimp-Betreffzeile übersetzen?

Nein. Laut der Dokumentation von Mailchimp ist eine Übersetzung der Betreffzeile nicht möglich, da bedingte Merge-Tags im Betreff-Feld nicht funktionieren. Um lokalisierte Betreffzeilen über Mailchimp zu versenden, benötigen Sie eine eigene Kampagne pro Sprache, segmentiert nach dem Sprachfeld des Kontakts.

Wie verhindere ich, dass die Übersetzung meine Liquid-Tags zerschießt?

Maskieren Sie Token, noch bevor der Text das Übersetzungsmodell erreicht, damit dieses sie nicht fälschlicherweise als Wörter interpretiert. Stellen Sie diese im Anschluss wieder her und vergewissern Sie sich, dass die Token im Output exakt denen im Input entsprechen, bevor Sie das Ergebnis übernehmen. Die Qualität verbessert sich zudem spürbar, wenn Sie jeden bedingten Zweig als eigenen String übersetzen, anstatt die gesamte {% if %}...{% endif %}-Zeile als einen einzigen Block zu übergeben. So wird jeder Zweig als der eigenständige Satz übersetzt, der er ist.

Was ist der Unterschied zwischen einer HTML-E-Mail und einer String-Tabelle?

Eine HTML-E-Mail ist ein Dokument: zusammenhängender Fließtext mit Struktur, der am besten im Ganzen übersetzt wird, damit der Kontext zwischen Überschrift und Textkörper gewahrt bleibt. Eine String-Tabelle hingegen ist eine Liste mit Schlüsseln, in der jede Zeile für sich steht. Sie enthält einen Schlüssel, der niemals geändert werden darf, meist eine Kontextnotiz und oft eine Zeichenbegrenzung. CSV-Exporte von Braze und Klaviyo, gettext-PO-Dateien und XLIFF sind allesamt String-Tabellen. Beide erfordern eine unterschiedliche Handhabung: Behandelt man eine String-Tabelle wie ein Dokument, gehen die Schlüssel verloren; behandelt man ein Dokument wie eine String-Tabelle, wird der Textfluss zerrissen.

Sollte ich für Übersetzungen den CSV-Export oder die API der Plattform nutzen?

CSV ist die praktikable Wahl, wenn ein Mensch oder ein externer Dienstleister die Übersetzung übernimmt; so wird es auch von Braze und Klaviyo dokumentiert. Ein API-basierter Workflow ist besser geeignet, wenn der Prozess regelmäßig erfolgt oder das Volumen so groß ist, dass die manuelle Dateiverarbeitung zum Engpass wird. Braze bietet eine Translations-API an (zum Zeitpunkt der Erstellung dieses Textes im Early Access), und Iterable stellt Template-Inhalte über GET /api/templates/email/get bereit. Brevo unterstützt beides nicht: Es gibt keine dateibasierte Übersetzung, daher müssen Kampagnen direkt in der Benutzeroberfläche übersetzt werden.

Wie viele Sprachen kann eine einzelne E-Mail-Kampagne unterstützen?

Das hängt von der Plattform ab. Braze erlaubt bis zu 200 Locales pro Workspace und 200 Translation-Tags pro Nachricht. Klaviyo deckt über 60 Sprachen mittels Smart Translations ab. Customer.io unterstützt mehrere hundert Sprach- und Regionencodes. In der Praxis ist selten das Plattform-Limit der begrenzende Faktor; vielmehr geht es darum, wie viele Sprachen man bei Änderungen am Ausgangstext noch zuverlässig prüfen und aktuell halten kann.