|
Dokumentation
Demo buchenPlattform
PlattformMCPCLIAPIWorkflows
Leitfäden
Changelog

Lokalisierung

  • Überblick
  • Translation API
  • Lokalisierung für Web-Apps
  • Lokalisierung für mobile Apps
  • iOS mit String Catalogs
  • Android mit strings.xml
  • E-Mail-Lokalisierung
  • Statische Inhalte (z. B. .md, .json)
  • Next.js mit Markdoc
  • Rails mit i18n

Workflows

  • Engine-Setup mit MCP
  • Jira-Triage
  • CI/CD

E-Mail-Lokalisierung

Die Lingo.dev CLI und die localization API unterstützen zwei Ansätze für die E-Mail-Lokalisierung: Übersetze Vorlagendateien beim Build, um Vorlagen pro Sprache auszuliefern, oder übersetze Inhalte vor dem Versand zur Laufzeit. Beide laufen über eine konfigurierte Lokalisierungs-Engine, auf die Glossarregeln, Markenstimme und Modellauswahl automatisch angewendet werden.

Wähle deinen Ansatz#

AnsatzAm besten geeignet fürSo funktioniert's
Build (CLI)Template-Dateien: react-email-JSON-StringsÜbersetze Dateien in deinem Repository und deploye Vorlagen pro Sprache
Laufzeit (API)Dynamische Inhalte, von ESPs gerenderte VorlagenRufe vor dem Versand die localization API auf und übergib die übersetzten Inhalte an deinen E-Mail-Anbieter

Welcher Ansatz?

Wenn dein übersetzbarer E-Mail-Content als Ressourcendateien in deinem Repository liegt, nutze den Build-Time-Ansatz. Wenn dein E-Mail-Content dynamisch generiert wird oder bei deinem E-Mail-Service-Provider gespeichert ist, nutze den Runtime-Ansatz.

Voraussetzungen#

Jede Übersetzung läuft über eine Lokalisierungs-Engine – die Konfiguration, die festlegt, welches LLM-Modell, Glossar, welche Markenstimme und welche Regeln verwendet werden. Erstellen Sie sie im Lingo.dev-Dashboard und installieren und authentifizieren Sie anschließend die CLI:

bash
npm install -g @lingo.dev/cli
lingo login

Die CLI setzt Node 22+ voraus. Setze in CI LINGO_API_KEY, statt lingo login auszuführen.

Lokalisierung beim Build#

Die CLI übersetzt E-Mail-Content aus JSON-Ressourcendateien. Extrahiere deinen übersetzbaren Text in JSON, richte die CLI darauf aus und erhalte für jede Sprache eigene Dateien neben deiner Quelldatei.

react-email-Vorlagen sind React-Komponenten, die zu HTML gerendert werden. Extrahiere übersetzbare Strings mit einer i18n-Bibliothek wie react-i18next in JSON-Ressourcendateien und übersetze die JSON-Dateien anschließend mit der CLI.

Führe lingo init aus, um die Konfiguration zu erstellen, und lingo link, um deine Organisation und Engine zu verknüpfen. Die erzeugte .lingo/config.json sieht so aus:

json
{
  "orgId": "org_abc123",
  "engineId": "eng_abc123",
  "sourceLocale": "en",
  "targetLocales": ["es", "fr", "de", "ja"],
  "files": [{ "pattern": "emails/locales/en.json" }]
}

Die Sprache steckt im Pfad: Die CLI ersetzt die Quell-Sprache im Muster durch jede Zielsprache, sodass aus emails/locales/en.json emails/locales/es.json, emails/locales/fr.json und so weiter werden. Checke .lingo/config.json in dein Repository ein.

Übersetze beim ersten Durchlauf alle Sprachen, danach nur noch die Änderungen:

bash
lingo push --backfill-missing   # first run / new locale
lingo push                      # delta on later runs

Beim Rendern übergibst du die Sprache an deine E-Mail-Komponente und lädst die passende JSON-Datei. Die react-email-render()-Funktion erzeugt sprachspezifisches HTML, das direkt versendet werden kann.

Um Ergebnisse aus dem letzten Push-Durchlauf jederzeit abzurufen, verwende lingo pull. Um zu prüfen, ob die Übersetzungen auf dem neuesten Stand sind, ohne Änderungen zu schreiben (zum Beispiel in CI), verwende lingo check.

Lokalisierung zur Laufzeit#

Wenn E-Mail-Inhalte dynamisch sind – etwa personalisierte Benachrichtigungen, Zusammenfassungen nutzergenerierter Inhalte oder in einem CMS gespeicherte Marketingtexte –, übersetze sie vor dem Versand zur Laufzeit. Das baut auf dem Muster auf, das im Leitfaden zur Translation API beschrieben ist.

javascript
async function sendLocalizedEmail(userId, templateId, content) {
  const user = await db.users.findById(userId);

  const response = await fetch("https://api.lingo.dev/process/localize", {
    method: "POST",
    headers: {
      "X-API-Key": process.env.LINGODOTDEV_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      engineId: "eng_abc123",
      sourceLocale: "en",
      targetLocale: user.locale,
      data: {
        subject: content.subject,
        preheader: content.preheader,
        body: content.body,
      },
    }),
  });

  const { data } = await response.json();

  await emailProvider.send({
    to: user.email,
    subject: data.subject,
    html: renderTemplate(templateId, data),
  });
}

Best Practices#

BereichEmpfehlung
BetreffzeilenHalte sie unter 50 Zeichen. Verwende ein Glossar, damit Markennamen nicht übersetzt werden.
VorschautextÜbersetze ihn getrennt vom Nachrichtentext – E-Mail-Clients zeigen ihn unabhängig davon an.
MarkenstimmeKonfiguriere den Ton pro Sprache in der Lokalisierungs-Engine. Marketing-E-Mails auf Japanisch brauchen ein anderes Register als auf Deutsch.
RTL-SprachenTeste die gerenderte Ausgabe in E-Mail-Clients für Arabisch, Hebräisch und Persisch. Die Handhabung von HTML-dir="rtl" unterscheidet sich je nach Client.
SchlüsselsperrungVerwende gesperrte Schlüssel für URLs, Produktnamen und rechtliche Kennungen, die nicht übersetzt werden sollen.

Nächste Schritte#

Translation API
Vollständiger Leitfaden für die Lokalisierung zur Laufzeit per API
Markenstimmen
Lege Ton und Formalitätsgrad pro Zielsprache fest
Glossare
Steuere, welche Begriffe übersetzt werden und welche unverändert bleiben
GitHub App
Automatisiere die Übersetzung von E-Mail-Templates bei jedem Pull Request

War diese Seite hilfreich?

Max PrilutskiyMax Prilutskiy·Aktualisiert vor 13 Tagen·4 Min. Lesezeit