Software-Strings und E-Mail-Vorlagen übersetzen

Ziehen Sie die Datei einfach in die Dropzone oder den Upload-Dialog, genau wie bei jedem anderen Dokument. Jeder String wird zu einem eigenen Block, der über seine ID zugeordnet ist. Dieser Key wird beim Export verwendet, um jede Übersetzung wieder an ihren ursprünglichen Platz zu setzen.

• CSV-Spalten werden anhand ihrer Überschriften erkannt: key, id oder Klaviyos block_id; source oder default (oder die erste Sprachspalte); Sprachcodes oder -namen für Zielsprachen; context, location und character limit für Zusatzfelder.
• Spalten mit regionalen Sprachcodes werden genau so verstanden, wie sie geschrieben stehen – es-MX, en-GB, fr-CA, pt_BR landen alle bei der richtigen Sprache. Falls eine Spalte wie ein Sprachcode aussieht, den Transept nicht kennt, meldet das System dies beim Import, anstatt sie einfach zu überspringen. So kann Sie ein Tippfehler nicht unbemerkt eine ganze Sprache kosten.
• Spalten für Kontext und Zeichenlimits sind nicht nur zur Deko da – der Kontext dient der KI als Orientierungshilfe für die Übersetzung, und das Limit wird durch ein automatisches Kürzen mit anschließendem Neuversuch durchgesetzt.

Diese werden als fertige Arbeit übernommen, nicht als Rohmaterial. Eine ausgefüllte Sprachzelle in einer CSV, ein befülltes msgstr in einer PO-Datei oder ein ausgefülltes Target in einer XLIFF wird zur aktiven Übersetzung des Strings – ohne Neuübersetzung, ohne Abrechnung von Credits – und jedes importierte Paar wird in Ihr Translation Memory aufgenommen, sodass es sofort neue Übersetzungen unterstützt.

Eine bewusste Ausnahme: PO-Einträge mit der Kennzeichnung fuzzy gelten nach den gettext-eigenen Regeln als Entwürfe. Transept importiert sie daher als unübersetzt, anstatt eine maschinelle Vermutung eigenmächtig zur geprüften Übersetzung zu erheben. Sobald Sie einen solchen Eintrag übersetzen und exportieren, wird die Fuzzy-Markierung entfernt und das ausgefüllte msgstr geschrieben.

Template-Token – wie Liquid-Tags ({{first_name}} oder {% if %}) oder printf-Konvertierungen (%s oder %(count)d) – werden maskiert, bevor die KI den Text sieht. Das Modell erhält einen undurchsichtigen Marker, den es weder übersetzen noch wahllos umstellen oder stillschweigend löschen kann. Nach jeder Antwort gleicht Transept die Marker mit dem Ausgangstext ab und korrigiert oder verwirft Ergebnisse, in denen Marker fehlen. Der Token-Text selbst wird wortgetreu wiederhergestellt.

Derselbe Schutz gilt für hochgeladene HTML-, Text- oder Markdown-Dateien, die Liquid-Tokens oder Mailchimp-Merge-Tags wie *|FNAME|* enthalten – eine aus Ihrer Plattform kopierte E-Mail-Vorlage wird automatisch übersetzt, wobei jeder Platzhalter erhalten bleibt. Fallback-Texte innerhalb eines Tags sind die Ausnahme, und zwar ganz bewusst: Das friend in {{ first_name | default:"friend" }} ist das, was jeder Empfänger ohne Vornamen liest – daher wird es übersetzt, während der Tag drumherum unverändert bleibt.

Vorlagen, deren gesamte Lokalisierung über Tags oder Bedingungen erfolgt – Braze-Übersetzungs-Tags, Mailchimp-Sprachblöcke –, haben einen eigenen Importpfad. Siehe E-Mail-Vorlagen von Braze und Mailchimp.

Bei einem Strings-Dokument erscheint in der Menüleiste des Editors eine Schaltfläche namens Strings. Sie öffnet eine Tabelle – eine Zeile pro String, mit Key, Ausgangstext und Übersetzung nebeneinander. Diese Ansicht können Sie nach Key oder Text filtern und direkt inline bearbeiten (Zelle anklicken, Text eingeben, Enter drücken). Über den Pfeil in der jeweiligen Zeile gelangen Sie direkt zum entsprechenden Block im vollständigen Editor, falls ein String einmal die umfangreicheren Werkzeuge erfordert: KI-Umformulierungen, Kommentare oder den Versionsverlauf.

In der Datei hinterlegte Zeichenlimits werden als dynamischer Zähler unter jeder Übersetzungszelle angezeigt. So erkennen Sie zu lange Strings direkt beim Tippen – und nicht erst, wenn der Export fehlschlägt.

Im Export-Menü für Strings-Dokumente erscheinen neben den üblichen Formaten zwei Einträge:

• Originaldatei, übersetzt – Ihre hochgeladene CSV-, PO- oder XLIFF-Datei, wobei die Übersetzungen direkt in die Zellen und Einträge eingefügt werden. Alles andere – Spaltenreihenfolge, Kommentare, Formatierung, sogar Eigenheiten bei Anführungszeichen – bleibt bitgenau wie beim Upload. So lässt sich die Datei direkt wieder in das System laden, aus dem sie stammt.
• Strings-Datei (mit Keys) – Transepts .tstrings.json enthält die Übersetzungen aller Sprachen, zugeordnet über die String-ID, in einer einzigen Datei. Dieses Format ist für Pipelines und Skripte gedacht, die den Re-Import über Keys abwickeln.
• Auch die Einträge TMX, XLIFF und CSV unter „Übersetzungsdaten“ nutzen bei Strings-Dokumenten die String-ID als Key für ihre Zeilen. So bleiben die Identitäten bei einem Roundtrip durch ein CAT-Tool erhalten.

Ja. Eine CSV-Datei mit mehreren Sprachspalten wird als ein Dokument pro Sprache importiert und automatisch gruppiert – die Spalten werden zu Sprachversionen, samt bereits ausgefüllter Zellen. Schließen Sie die Lücken mit einem einzigen Workflow-Durchlauf für die gesamte Gruppe und exportieren Sie das Ganze einmalig: Der Export als Originaldatei füllt jede Sprachspalte Ihrer CSV-Datei in einem einzigen Download aus.

Genau dafür gibt es die API: um diesen Ablauf headless zu steuern – Upload, Verteilung, Übersetzung und Re-Export direkt per Skript.