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#
| Ansatz | Am besten geeignet für | So funktioniert's |
|---|---|---|
| Build (CLI) | Vorlagendateien – react-email, MJML, HTML | Übersetze Dateien in deinem Repository und deploye Vorlagen pro Sprache |
| Laufzeit (API) | Dynamische Inhalte, von ESPs gerenderte Vorlagen | Rufe vor dem Versand die localization API auf und übergib die übersetzten Inhalte an deinen E-Mail-Anbieter |
Welcher Ansatz?
Wenn deine E-Mail-Vorlagen als Dateien in deinem Repository liegen (HTML, MJML oder React-Komponenten), nutze den Build-Ansatz. Wenn deine E-Mail-Inhalte dynamisch erzeugt oder in deinem E-Mail-Service-Provider gespeichert werden, nutze den Laufzeit-Ansatz.
Voraussetzungen#
Jede Übersetzung läuft über eine Lokalisierungs-Engine – die Konfiguration, die festlegt, welches LLM-Modell, Glossar, welche Markenstimme und welche Anweisungen angewendet werden. Erstelle sie im Lingo.dev-Dashboard und generiere einen API-Schlüssel.
Lokalisierung beim Build#
Die CLI übersetzt E-Mail-Vorlagendateien direkt. Konfiguriere einen Bucket, der zu deinem Vorlagenformat passt, führe die CLI aus und erhalte Vorlagendateien pro Sprache direkt neben deinen Quellvorlagen.
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.
{
"$schema": "https://lingo.dev/schema/i18n.json",
"version": "1.15",
"locale": {
"source": "en",
"targets": ["es", "fr", "de", "ja"]
},
"buckets": {
"json": {
"include": ["emails/locales/[locale].json"]
}
}
}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.
Führe Übersetzungen so aus:
npx lingo.dev@latest runLokalisierung 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.
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#
| Bereich | Empfehlung |
|---|---|
| Betreffzeilen | Halte 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. |
| Markenstimme | Konfiguriere den Ton pro Sprache in der Lokalisierungs-Engine. Marketing-E-Mails auf Japanisch brauchen ein anderes Register als auf Deutsch. |
| RTL-Sprachen | Teste 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üsselsperrung | Verwende gesperrte Schlüssel für URLs, Produktnamen und rechtliche Kennungen, die nicht übersetzt werden sollen. |
