La CLI de Lingo.dev et l’API de localisation prennent en charge deux approches pour localiser les e-mails : traduire les fichiers de modèles au moment du build afin de déployer un modèle par langue, ou traduire le contenu à l’exécution avant l’envoi. Dans les deux cas, tout passe par un moteur de localisation configuré, avec les règles du glossaire, la voix de marque et la sélection du modèle appliquées automatiquement.
Choisissez votre approche#
| Approche | Idéal pour | Fonctionnement |
|---|---|---|
| Build-time (CLI) | Fichiers de modèles — react-email, MJML, HTML | Traduisez les fichiers de votre dépôt, puis déployez un modèle par langue |
| Runtime (API) | Contenu dynamique, modèles rendus par l’ESP | Appelez l’API de localisation avant l’envoi, puis transmettez le contenu traduit à votre fournisseur d’e-mails |
Quelle approche choisir ?
Si vos modèles d’e-mails sont stockés dans votre dépôt sous forme de fichiers (HTML, MJML ou composants React), optez pour l’approche build-time. Si le contenu de vos e-mails est généré dynamiquement ou stocké chez votre fournisseur de services e-mail, privilégiez l’approche runtime.
Prérequis#
Chaque traduction passe par un moteur de localisation : c’est la configuration qui détermine le modèle LLM, le glossaire, la voix de marque et les instructions à appliquer. Créez-en un dans le tableau de bord Lingo.dev, puis générez une clé API.
Localisation au moment du build#
La CLI traduit directement les fichiers de modèles d’e-mails. Configurez un bucket adapté au format de votre modèle, exécutez la CLI, puis récupérez des fichiers de modèles par langue à côté de vos modèles sources.
Les modèles react-email sont des composants React qui génèrent du HTML. Extrayez les chaînes à traduire dans des fichiers de ressources JSON à l’aide d’une bibliothèque i18n comme react-i18next, puis traduisez ces fichiers JSON avec la 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"]
}
}
}Au moment du rendu, transmettez la langue à votre composant d’e-mail et chargez le fichier JSON correspondant. La fonction react-email render() produit alors un HTML prêt à l’envoi, adapté à la langue.
Lancez les traductions avec :
npx lingo.dev@latest runLocalisation à l’exécution#
Lorsque le contenu de l’e-mail est dynamique — notifications personnalisées, résumés de contenu généré par les utilisateurs ou texte marketing stocké dans un CMS — traduisez-le à l’exécution avant l’envoi. Cette approche s’appuie sur le modèle décrit dans le guide de l’API de traduction.
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),
});
}Bonnes pratiques#
| Zone | Recommandation |
|---|---|
| Objets | Restez sous les 50 caractères. Utilisez un glossaire pour empêcher la traduction des noms de marque. |
| Texte d’aperçu | Traduisez-le séparément du corps du message : les clients e-mail l’affichent indépendamment. |
| Voix de marque | Configurez le ton par langue dans le moteur de localisation. Un e-mail marketing en japonais nécessite un registre différent de l’allemand. |
| Langues RTL | Testez le rendu dans les clients e-mail pour l’arabe, l’hébreu et le persan. La gestion du dir="rtl" HTML varie selon les clients. |
| Verrouillage des clés | Utilisez les clés verrouillées pour les URL, les noms de produits et les identifiants juridiques qui ne doivent pas être traduits. |
