Diese Seite wurde automatisch übersetzt und kann Ungenauigkeiten enthalten. Um einen Übersetzungsfehler zu melden, nutzen Sie das Feedback unten im Inhaltsverzeichnis rechts auf der Seite.
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 Küchenartikel-Einzelhändler, versendet E-Mails, Push-Nachrichten und In-App-Nachrichten auf Englisch, Französisch und Deutsch. Marketing und Engineering benötigen einen wiederholbaren, skalierbaren Weg, um Übersetzungen über Campaigns hinweg zu verwalten.
Braze unterstützt mehrere Lokalisierungsmuster:
- Manuelles bedingtes Liquid: Pro Sprache eingegebener Text im Nachrichtentext
- Content Blocks: Wiederverwendbare Blöcke (mit oder ohne Multi-Language-Übersetzungs-Tags)
- Kataloge: Strukturierte Übersetzungszeilen, die nach Gebietsschema geschlüsselt sind
- Multi-Language-Nachrichten: Übersetzungs-Tags, CSV-Uploads und die Übersetzungs-API (Early Access)
- Übersetzungspartner: Smartling, Phrase, Lokalise und andere
- Connected Content: Lokalisierte Strings, die zum Sendezeitpunkt von Ihrem CMS oder Ihrer API abgerufen werden
Dieses Beispiel vergleicht die jeweiligen Vor- und Nachteile, damit Sie einen Ansatz wählen können, der zu Ihrem QA-Workflow, Ihrem Kanalmix, Ihrer Aktualisierungshäufigkeit und Ihren Teamressourcen passt. Es ersetzt nicht die Schritt-für-Schritt-Einrichtung für eine einzelne Methode. Für Feature-Anleitungen beginnen Sie mit Lokalisierung und Multi-Language-Nachrichten.
Überlegungen
- Entscheiden Sie vor der Wahl eines Ansatzes, ob Sie Dashboard-Vorschau und QA, professionelle Übersetzungsworkflows, häufige Inhaltsaktualisierungen oder Realtime-CMS-gesteuerte Texte benötigen.
- 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 können kanalübergreifend angewendet werden, sofern diese Features unterstützt werden.
- Braze generiert keine Übersetzungen. Sie stellen die Texte über das Dashboard, CSV, API, Katalogimport, Partner-Workflow oder ein externes CMS bereit.
- Manuelles Liquid und Content Blocks mit eingebetteter bedingter Logik erfordern Namenskonventionen und Überprüfungsprozesse, wenn die Anzahl der Sprachen wächst. Mehrsprachige und Partner-Workflows zentralisieren Aktualisierungen, können jedoch CSV- oder API-Pflege erfordern.
- Connected Content und einige Partner-Abläufe sind von externen Systemen abhängig. Wenn eine API oder ein CMS zum Sendezeitpunkt nicht verfügbar ist, können lokalisierte Inhalte möglicherweise nicht geladen werden.
- Überschneidungen sind üblich. Beispielsweise können Sie im selben Programm mehrsprachige Tags für E-Mail-Texte, Content Blocks für gemeinsam genutzte Fußzeilen und Kataloge für Produkttexte verwenden.
Einrichtung
Schritt 1: Erfassen Sie Ihre Lokalisierungsanforderungen
| Anforderung | Zu beantwortende Fragen |
|---|---|
| Vorschau und QA | Müssen Marketer jede Locale im Braze-Composer vor dem Versand in der Vorschau anzeigen? |
| Skalierung | Wie viele Sprachen und wie häufig ändert sich der Text? |
| Workflow | Benötigen Sie Überprüfungen, Revisionen und Freigaben durch Übersetzer:innen? |
| Datenform | Handelt es sich um frei formulierten Marketingtext oder um strukturierte Produktfelder (Namen, Preise, URLs)? |
| Automatisierung | Sollen Übersetzungen automatisch aktualisiert werden, wenn sich Ihr CMS ändert? |
| Team-Kenntnisse | Kann Ihr Team Liquid, CSV-Uploads, APIs oder Partnerintegrationen pflegen? |
Schritt 2: Ansätze im Überblick vergleichen
| Dimension | Manuelles Liquid | Content Blocks | Kataloge | Mehrsprachige Nachrichten | Übersetzungspartner | Connected Content |
|---|---|---|---|---|---|---|
| Dashboard-Vorschau / QA | Ja | Ja | Ja | Ja | Variiert je nach Partner | Eingeschränkt – schwieriger, abgerufene Inhalte in der Vorschau anzuzeigen |
| Standard (keine Integration) | Ja | Ja | Teilweise – Katalog-Einrichtung erforderlich | Ja | Nein – Anbieter-Einrichtung | 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 | Variiert je nach Partner | Alle unterstützten Kanäle |
| Implementierungsaufwand | Niedrig | Niedrig–mittel | Mittel | Niedrig | Hoch (partnerabhängig) | Mittel |
| Laufender (BAU-)Aufwand | Hoch – Bearbeitungen pro Nachricht | Mittel – Block-Pflege | Mittel – CSV- oder API-Updates | Mittel – CSV-Uploads | Mittel – in der Plattform verwaltet | Niedrig – beim Versand abgerufen |
| Häufige Aktualisierungen | Nein | Teilweise | Nein | Teilweise | Ja | Ja |
| Professioneller Übersetzungs-Workflow | Nein | Nein | Nein | Nein | Ja | Nein |
| Strukturierte / Produktdaten | Eingeschränkt | Eingeschränkt | Ja – ideal für schlüsselbasierte Texte | Eingeschränkt | Variiert | Ja – über externe Quelle |
| Risiko externer Abhängigkeiten | Keines | Keines | Keines | Keines | Mittel | Mittel – Versand schlägt fehl, wenn die Quelle nicht erreichbar ist |
| Am besten geeignet für | Wenige Sprachen, seltene Aktualisierungen | Gemeinsam genutzte Komponenten über Nachrichten hinweg | Viele Locales mit strukturierten Strings | Viele Sprachen mit geringerem Copy-Paste-Aufwand | Unternehmensweite Übersetzung mit Freigaben | Dynamische CMS-gesteuerte Lokalisierung |
Schritt 3: Kitchenerie-Szenarien einem Ansatz zuordnen
| Kitchenerie-Szenario | Empfohlener Ausgangspunkt |
|---|---|
| Drei Sprachen, wenige Campaigns pro Monat, kleines Marketing-Team | Manuelles bedingtes Liquid oder Content Blocks mit Liquid |
| Gemeinsamer Header, Footer und rechtliche Blöcke in E-Mail und IAM | Content Blocks – mit mehrsprachigen Übersetzungen, die im Block gespeichert werden, wenn die Locales skalieren |
| Produktnamen, Promo-Zeilen und Bild-URLs nach Locale zugeordnet | Kataloge |
| E-Mail und Push in acht oder mehr Locales mit Composer-Vorschau | Mehrsprachige Nachrichten |
| Zentrales TMS mit Übersetzer-Workflow und Freigaben | Lokalisierungspartner (zum Beispiel Smartling oder Phrase) |
| Texte in einem CMS, das täglich aktualisiert wird | Connected Content |
Schritt 4: Den gewählten Ansatz implementieren
- Manuelles bedingtes Liquid: Verwenden Sie die Profil-Attribute
languageoder Locale mitif/elsif/elseLiquid. Siehe Alternative Ansätze und Bedingte Logik. - Content Blocks: Erstellen Sie wiederverwendbare Blöcke; optional können Sie bedingtes Liquid in Blöcken verbergen. Siehe Content Blocks und den Content-Blocks-Tab unter Übersetzte Nachrichten senden.
- Kataloge: Importieren Sie Übersetzungszeilen (zum Beispiel
id,context,language,body) und referenzieren Sie diese mit Liquidcatalog_items. Siehe den Kataloge-Tab unter Übersetzte Nachrichten senden. - Mehrsprachige Nachrichten: Locales hinzufügen, Texte in Übersetzungs-Tags einschließen und dann eine CSV hochladen. Wenn Sie Early Access zu den Übersetzungsendpunkten haben, können Sie Übersetzungen stattdessen per API aktualisieren. Vorschau mit Multi-language user im Composer.
- Übersetzungspartner: Konfigurieren Sie Workspace-Locales und folgen Sie dann Ihrer Partnerintegration (zum Beispiel Smartling oder Phrase).
- Connected Content: Rufen Sie Ihr CMS oder Ihre Übersetzungs-API zum Versandzeitpunkt ab. Testen Sie gründlich; die Vorschau spiegelt möglicherweise nicht die Live-API-Antworten wider. Siehe Connected Content.
Informationen zur Canvas- und Campaign-Orchestrierung über Regionen hinweg (eine Journey versus eine Journey pro Land) finden Sie unter Übersetzungsmanagement auf der Lokalisierungsseite.
Verwandte Artikel
New Stuff!