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 template — chaînes JSON react-email | 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 le contenu traduisible de vos e-mails se trouve dans votre dépôt sous forme de fichiers de ressources, utilisez l’approche au moment du build. Si le contenu de vos e-mails est généré dynamiquement ou stocké chez votre fournisseur de services d’e-mail, utilisez l’approche à l’exécution.
Prérequis#
Chaque traduction passe par un moteur de localisation : c’est la configuration qui détermine le modèle de LLM, le glossaire, la voix de marque et les règles à appliquer. Créez-en un dans le tableau de bord Lingo.dev, puis installez et authentifiez le CLI :
npm install -g @lingo.dev/cli
lingo loginLa CLI nécessite Node 22+. En CI, définissez LINGO_API_KEY au lieu d’exécuter lingo login.
Localisation au moment du build#
La CLI traduit le contenu des e-mails à partir de fichiers de ressources JSON. Extrayez votre contenu traduisible en JSON, pointez la CLI dessus, et obtenez des fichiers par langue à côté de votre source.
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.
Exécutez lingo init pour générer le fichier de configuration et lingo link pour lier votre organisation et votre moteur. Le fichier .lingo/config.json obtenu ressemble à ceci :
{
"orgId": "org_abc123",
"engineId": "eng_abc123",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [{ "pattern": "emails/locales/en.json" }]
}La langue figure dans le chemin : la CLI remplace la langue source dans le modèle par chaque langue cible. Ainsi, emails/locales/en.json produit emails/locales/es.json, emails/locales/fr.json, etc. Validez .lingo/config.json dans votre dépôt.
Traduisez toutes les langues lors de la première exécution, puis uniquement ce qui a changé lors des suivantes :
lingo push --backfill-missing # first run / new locale
lingo push # delta on later runsAu 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.
Pour récupérer à tout moment les résultats du dernier push, utilisez lingo pull. Pour vérifier que les traductions sont à jour sans écrire de modifications (par exemple en CI), utilisez lingo check.
Localisation à 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. |
