Ansätze für die Verwaltung mehrsprachiger Übersetzungen vergleichen
Bewerten Sie, wie lokalisierte Texte gespeichert, aktualisiert, in der Vorschau angezeigt und versendet werden, damit Sie einen Lokalisierungsansatz wählen können, der zu Ihrem QA-Workflow, Ihrem Kanalmix und Ihrer Aktualisierungshäufigkeit passt.
Über dieses Beispiel
Kitchenerie, ein fiktiver Einzelhändler für Küchenartikel, versendet E-Mails, Push-Benachrichtigungen und In-App-Nachrichten auf Englisch, Französisch und Deutsch. Marketing und Engineering benötigen eine wiederholbare, skalierbare Methode, um Übersetzungen über Campaigns hinweg zu verwalten.
Braze unterstützt mehrere Lokalisierungsmuster:
- Manuelles bedingtes Liquid: Texte werden pro Sprache direkt im Nachrichtentext eingegeben
- Content Blocks: Wiederverwendbare Blöcke (mit oder ohne mehrsprachige Übersetzungs-Tags)
- Kataloge: Strukturierte Übersetzungszeilen, die nach Gebietsschema verschlüsselt sind
- Mehrsprachige Nachrichten: Übersetzungs-Tags, CSV-Uploads und die Übersetzungs-API (Early Access)
- Übersetzungspartner: Smartling, Phrase, Lokalise und weitere
- Connected-Content: Lokalisierte Strings, die beim Versand aus Ihrem CMS oder Ihrer API abgerufen werden
Dieses Beispiel vergleicht die Vor- und Nachteile, damit Sie einen Ansatz wählen können, der zu Ihrem QA-Workflow, Ihrem Kanal-Mix, Ihrer Update-Häufigkeit und Ihren Team-Ressourcen passt. Es ersetzt keine Schritt-für-Schritt-Einrichtung für eine einzelne Methode. Für Anleitungen zu den Features beginnen Sie mit Lokalisierung und Mehrsprachige Nachrichten.
Überlegungen
- Entscheiden Sie, ob Sie eine Vorschau und QA im Dashboard, professionelle Übersetzungs-Workflows, häufige Content-Updates oder Realtime-Texte aus einem CMS benötigen, bevor Sie sich für ein Muster entscheiden.
- Mehrsprachige Nachrichten unterstützen E-Mail, Push, Banner, In-App-Nachrichten und Content Blocks. Beachten Sie, dass SMS und WhatsApp andere Lokalisierungsmuster verwenden. Manuelles Liquid, Content Blocks, Kataloge, Partner und Connected-Content lassen sich kanalübergreifend einsetzen, sofern diese Features unterstützt werden.
- Braze erstellt keine Übersetzungen. Sie stellen die Texte über das Dashboard, CSV, die API, einen Katalogimport, einen Partner-Workflow oder ein externes CMS bereit.
- Manuelles Liquid und Content Blocks mit eingebetteten Bedingungen erfordern mit wachsender Anzahl an Sprachen Namenskonventionen und Prüfprozesse. Mehrsprachige Workflows und Partner-Workflows zentralisieren Updates, erfordern jedoch unter Umständen die Pflege per CSV oder API.
- Connected-Content und einige Partner-Workflows sind von externen Systemen abhängig. Wenn eine API oder ein CMS zum Zeitpunkt des Versands nicht verfügbar ist, werden lokalisierte Inhalte möglicherweise nicht geladen.
- Überschneidungen sind üblich. So können Sie im selben Programm beispielsweise mehrsprachige Tags für E-Mail-Texte, Content Blocks für gemeinsame Fußzeilen und Kataloge für Produkttexte verwenden.
Einrichtung
Schritt 1: Ihre Anforderungen an die Lokalisierung erfassen
| Anforderung | Zu beantwortende Fragen |
|---|---|
| Vorschau und QA | Müssen Marketer jede Locale vor dem Versand im Braze-Editor in der Vorschau prüfen? |
| Umfang | Wie viele Sprachen gibt es und wie oft ändern sich die Texte? |
| Workflow | Benötigen Sie Prüfungen durch Übersetzer:innen, Überarbeitungen und Freigaben? |
| Datenstruktur | Handelt es sich um frei formulierte Marketingtexte oder um strukturierte Produktfelder (Namen, Preise, URLs)? |
| Automatisierung | Sollen Übersetzungen automatisch aktualisiert werden, wenn sich Ihr CMS ändert? |
| Kompetenzen im Team | Kann Ihr Team Liquid, CSV-Uploads, APIs oder Partnerintegrationen pflegen? |
Schritt 2: Ansätze vergleichen
| Dimension | Manuelles Liquid | Content Blocks | Kataloge | Mehrsprachige Nachrichten | Übersetzungspartner | Connected Content |
|---|---|---|---|---|---|---|
| Dashboard-Vorschau/QA | Ja | Ja | Ja | Ja | Je nach Partner | Eingeschränkt – abgerufene Inhalte lassen sich schwerer in der Vorschau prüfen |
| Standard (keine Integration) | Ja | Ja | Teilweise – Katalog-Einrichtung erforderlich | Ja | Nein – Einrichtung beim Anbieter | Nein – API oder CMS erforderlich |
| Kanalabdeckung | Alle unterstützten Kanäle | Alle unterstützten Kanäle | Alle unterstützten Kanäle | E-Mail, Push, Banner, In-App-Nachrichten, Content Blocks | Je nach Partner | Alle unterstützten Kanäle |
| Implementierungsaufwand | Gering | Gering bis mittel | Mittel | Gering | Hoch (abhängig vom Partner) | Mittel |
| Laufender Aufwand (BAU) | Hoch – Bearbeitung pro Nachricht | Mittel – Pflege der Blöcke | Mittel – Updates per CSV oder API | Mittel – CSV-Uploads | Mittel – Verwaltung in der Plattform | Gering – Abruf zum Zeitpunkt des Versands |
| Häufige Updates | Nein | Teilweise | Nein | Teilweise | Ja | Ja |
| Professioneller Übersetzungs-Workflow | Nein | Nein | Nein | Nein | Ja | Nein |
| Strukturierte Daten/Produktdaten | Eingeschränkt | Eingeschränkt | Ja – ideal für schlüsselbasierte Texte | Eingeschränkt | Variiert | Ja – über eine externe Quelle |
| Risiko externer Abhängigkeiten | Keines | Keines | Keines | Keines | Mittel | Mittel – der Versand schlägt fehl, wenn die Quelle nicht verfügbar ist |
| Am besten geeignet für | Wenige Sprachen, seltene Updates | Gemeinsame Komponenten über mehrere Nachrichten hinweg | Viele Locales mit strukturierten Strings | Viele Sprachen mit geringerem Copy-Paste-Aufwand | Übersetzung auf Unternehmensebene mit Freigaben | Dynamische, CMS-gesteuerte Lokalisierung |
Schritt 3: Szenarien im Stil von Kitchenerie einem Ansatz zuordnen
| Kitchenerie-Szenario | Empfohlener Ausgangspunkt |
|---|---|
| Drei Sprachen, wenige Campaigns pro Monat, kleines Marketingteam | Manuelles bedingtes Liquid oder Content Blocks mit Liquid |
| Gemeinsame Kopfzeilen, Fußzeilen und rechtliche Blöcke in E-Mail und IAM | Content Blocks – mit mehrsprachigen Übersetzungen, die im Block gespeichert sind, wenn die Anzahl der Locales wächst |
| Produktnamen, Werbezeilen und Bild-URLs, nach Locale verschlüsselt | Kataloge |
| E-Mail und Push in acht oder mehr Locales mit Vorschau im Editor | Mehrsprachige Nachrichten |
| Zentrales TMS mit Übersetzungs-Workflow und Freigaben | Lokalisierungspartner (zum Beispiel Smartling oder Phrase) |
| Texte, die in einem täglich aktualisierten CMS gepflegt werden | Connected Content |
Schritt 4: Den gewählten Ansatz implementieren
- Manuelles bedingtes Liquid: Verwenden Sie das Profilattribut
languageoder Locale-Attribute mitif/elsif/elsein Liquid. Siehe Alternative Ansätze und Bedingte Logik. - Content Blocks: Erstellen Sie wiederverwendbare Blöcke und blenden Sie bedingtes Liquid optional innerhalb der Blöcke aus. Siehe Content Blocks und den Tab „Content Blocks“ unter Übersetzte Nachrichten versenden.
- Kataloge: Importieren Sie Übersetzungszeilen (zum Beispiel
id,context,language,body) und referenzieren Sie diese mit Liquidcatalog_items. Siehe den Tab „Kataloge“ unter Übersetzte Nachrichten versenden. - Mehrsprachige Nachrichten: Fügen Sie Locales hinzu, schließen Sie Texte in Übersetzungs-Tags ein und laden Sie anschließend eine CSV-Datei hoch. Wenn Sie Early Access zu den Übersetzungs-Endpunkten haben, können Sie Übersetzungen stattdessen per API aktualisieren. Prüfen Sie die Vorschau im Editor mit Mehrsprachige:r Nutzer:in.
- Übersetzungspartner: Konfigurieren Sie die Locales des Workspace und folgen Sie dann der Anleitung zu Ihrer Partnerintegration (zum Beispiel Smartling oder Phrase).
- Connected Content: Rufen Sie Ihr CMS oder Ihre Übersetzungs-API zum Zeitpunkt des Versands auf. Testen Sie gründlich, denn die Vorschau spiegelt Live-Antworten der API möglicherweise nicht wider. Siehe Connected Content.
Informationen zur Orchestrierung von Canvas und Campaigns über Regionen hinweg (eine Journey oder eine Journey pro Land) finden Sie unter Übersetzungsmanagement auf der Seite „Lokalisierung“.