Localizzazione delle email: come tradurre le campagne in tutti i principali ESP

Mi occupo di lifecycle marketing, quindi ho passato gran parte della mia vita negli editor delle campagne, e la localizzazione delle email è l'aspetto che continuavo a sottovalutare. Tradurre una landing page è un'attività lineare e definita. Tradurre una campagna email è un lavoro diverso per ogni strumento, perché ogni piattaforma ha deciso autonomamente cosa si intenda per "lingua".

Alcune piattaforme traducono i testi per te. Altre offrono slot vuoti per le diverse lingue e si aspettano che sia tu a riempirli. Una pretende addirittura che sia tu a scrivere le logiche condizionali nel corpo dell'email. Ma, dietro ognuna di esse, si nasconde la stessa insidia: i testi sono pieni di sintassi dei template che deve tornare dalla traduzione intatta, carattere per carattere, altrimenti l'invio fallisce.

Questa guida spiega come funzionano davvero le principali piattaforme, come esportare e importare i testi e quali aspetti del lavoro restano identici ovunque.

Tre modi in cui le piattaforme email gestiscono le lingue

Prima di analizzare le singole piattaforme, è utile capire con quale delle tre architetture hai a che fare. Da questa dipende l'intero flusso di lavoro e, solitamente, non è un aspetto che si può cambiare.

La riga centrale è quella in cui si collocano i programmi multilingua più strutturati, ed è la parte su cui questa guida si sofferma maggiormente: quando "la piattaforma ti offre una griglia vuota di versioni locali", è proprio lì che diventa indispensabile definire un flusso di lavoro per la traduzione.

Localizzazione delle email in Braze

Braze adotta il modello tag-and-fill e ha la sintassi più caratteristica del gruppo. Ogni elemento dell'email da tradurre va racchiuso in un tag Liquid con un ID:

{% translation greeting %}Hello!{% endtranslation %}

Il formato generale è {% translation il_tuo_id_qui %}testo predefinito{% endtranslation %} e gli ID devono essere univoci all'interno di un messaggio. Esiste una scorciatoia nell'editor per racchiudere una selezione (Cmd+Alt+L su macOS, Ctrl+Alt+L su Windows). Braze non traduce nulla in autonomia: le traduzioni vanno fornite caricando un file CSV o tramite l'API per le traduzioni, che al momento della stesura di questa guida è in fase di early access.

I limiti documentati diventano rilevanti quando una campagna entra nel vivo:

I tag di traduzione nidificati non sono supportati. La versione locale viene ricavata dal profilo utente, configurato in Settings → Localization Settings, a partire dagli attributi predefiniti language e country o da un attributo personalizzato; se sono applicabili entrambi, l'attributo personalizzato ha la precedenza.

Ci sono due particolarità di Braze che è bene conoscere prima di iniziare:

Racchiudere un URL in un tag interrompe il tracciamento dei clic a meno che la parte racchiusa non termini con ? o &. Braze documenta direttamente la soluzione alternativa:

<a href="https://{% translation id_1 %}example.com{% endtranslation %}?">Shop Now</a>

Non aprire il file CSV delle traduzioni in Excel. La documentazione stessa di Braze raccomanda di evitarlo a causa di problemi di visualizzazione dei caratteri non inglesi. È il modo più comune in cui un processo di localizzazione di Braze si corrompe senza che nessuno se ne accorga, e la causa è Excel, non Braze: Excel tenta di indovinare la codifica del CSV e sbaglia.

I Blocchi di contenuto di Braze possono includere le proprie traduzioni: in questo modo, è possibile localizzare un piè di pagina condiviso una sola volta anziché per ogni singola campagna. Richiamali come {{content_blocks.${your_block}}}; i blocchi inseriti tramite Liquid restano collegati e si aggiornano in automatico, a differenza di quelli aggiunti tramite il menu a discesa dell'editor. Se un blocco non dispone di una traduzione per una determinata versione locale, viene visualizzato nella lingua originale anziché restituire un errore.

Se preferisci creare delle diramazioni invece di usare i tag, Braze supporta anche la soluzione "fai da te":

{% if ${language} == 'en' %}
English content
{% elsif ${language} == 'es' %}
Spanish content
{% else %}
Fallback content
{% endif %}

Nota che all'interno di un tag Liquid l'attributo è indicato semplicemente come ${language}, mentre nel corpo del messaggio è racchiuso tra doppie parentesi graffe: {{${language}}}. Braze consiglia di includere sempre il ramo {% else %}, perché alcuni utenti potrebbero non avere una lingua impostata, utilizzarne una non supportata o avere un dispositivo da cui non è possibile rilevare la lingua.

Docs: Localizzazione di Braze

Localizzazione delle email in Customer.io

Customer.io ha adottato l'approccio opposto: la localizzazione è nativa, integrata direttamente nell'editor dei messaggi, e include un pulsante per la traduzione automatica tramite IA. Puoi creare il messaggio in una lingua predefinita e aggiungere le varianti linguistiche senza dover creare diramazioni nella campagna. Funziona per email, SMS, WhatsApp, notifiche push e messaggi in-app.

Il nome dell'attributo della lingua lo scegli tu. In Workspace Settings → Language settings indichi a Customer.io quale attributo del profilo contiene la lingua: potrebbe essere language, locale o qualsiasi altro termine già usato nel tuo CRM. I valori devono essere un codice di due lettere (en) o una combinazione lingua-regione separata da un trattino (en-US). Non c'è distinzione tra maiuscole e minuscole, quindi es-MX ed es-mx sono entrambi validi, ma il trattino è obbligatorio.

La traduzione automatica copre il corpo del testo, l'oggetto e il preheader. Ecco invece cosa non viene coperto (un elenco da tenere bene a mente):

• Le immagini, sebbene traduca il testo alternativo
• I layout delle email negli editor rich-text e di codice
• Testo statico Liquid, valori degli attributi e valori dei filtri
• Gli snippet
• Testo dei componenti personalizzati, a meno che non si scolleghi prima il componente

Il terzo punto merita un esempio, perché è il più insidioso. La documentazione stessa di Customer.io sulla localizzazione riporta questa riga:

Bonjour {{ customer.first_name | default:"ami" }}

La parola ami è il valore di fallback mostrato a chiunque non abbia un nome registrato in archivio. Si tratta di testo reale, visibile ai destinatari, che si trova all'interno di un filtro Liquid non toccato dalla traduzione automatica. Invia quel messaggio a un pubblico tedesco e una parte dei destinatari verrà salutata come ami. Ogni stringa di fallback in ogni filtro default: deve essere tradotta manualmente per ogni variante, e l'interfaccia non ti fornirà alcun avviso al riguardo.

Altri due limiti da tenere a mente: le traduzioni non vengono aggiornate automaticamente quando modifichi il template predefinito, e gli A/B test con traduzioni funzionano per gli invii singoli, ma non per i broadcast attivati tramite API o per le automazioni.

Gli snippet meritano una nota a parte. Sono lo strumento per i contenuti riutilizzabili ({{snippets.tuo_snippet}}, 16 KB ciascuno per impostazione predefinita) e la traduzione automatica li ignora. Il consiglio di Customer.io è di inserire le istruzioni condizionali all'interno dello snippet stesso:

{% if customer.language == 'fr' %}
  Se désabonner
{% elsif customer.language == 'de' %}
  Abmelden
{% else %}
  Unsubscribe
{% endif %}

Quindi, un programma Customer.io finisce solitamente per essere composto da varianti native per il corpo dei messaggi e da istruzioni condizionali gestite a mano all'interno di ogni snippet condiviso. È bene saperlo prima di dare per scontato che il pulsante dell'IA copra ogni cosa.

Docs: Localizzazione di Customer.io

Localizzazione delle email in Klaviyo

La funzionalità di Klaviyo si chiama Smart Translations e permette di tradurre automaticamente il contenuto dei messaggi in oltre 60 lingue direttamente dall'editor delle campagne o dei flussi. Si attiva in Impostazioni → Account → Traduzione tramite l'opzione "Traduci messaggi". Richiede un account a pagamento e non è disponibile nella versione di prova gratuita.

L'elenco di ciò che Klaviyo traduce automaticamente è molto specifico: blocchi di testo, etichette e testi alternativi (alt text). Gli oggetti delle email non sono inclusi, quindi verifica bene nel tuo account prima di dare per scontato che una campagna sia interamente coperta.

La risoluzione della lingua si basa sul Locale del profilo; se questo manca, il sistema ripiega su Paese o Lingua. Klaviyo accetta sia i codici BCP-47 (en-GB, es-ES) sia valori in formato testo come English o French.

Lavorare con Klaviyo è piacevole per due motivi. Il primo è la lista di termini da non tradurre: nomi di brand, di prodotti e qualsiasi termine che non vuoi che un modello tocchi mai, da definire una sola volta a livello di account. La maggior parte delle piattaforme non offre nulla di simile, ed è ciò che permette al nome del tuo prodotto di rimanere intatto in dieci varianti locali invece di trasformarsi in dieci parole diverse.

Il secondo è il menu di sovrascrittura per singolo elemento. Su ogni elemento tradotto sono disponibili le opzioni Ritraduci, Copia dall'originale, Modifica e Ignora, e puoi spostarti tra le lingue usando le frecce in alto nell'editor. Questo trasforma la revisione in un rapido controllo delle voci segnalate, anziché in una rilettura completa.

Klaviyo supporta anche la gestione tramite CSV (round-trip), la soluzione ideale se collabori con traduttori o utilizzi strumenti esterni. In Traduzione → menu delle azioni, troverai la voce Esporta CSV, disponibile nei formati Smartling o Semplice. Le colonne sono block_id (l'identificativo univoco di ogni stringa traducibile), source (il testo originale) e una colonna per ogni lingua, denominata con il relativo codice. Le regole sono ferree ma sensate: non modificare né eliminare i valori block_id, non aggiungere righe e non alterare i valori source.

Un aspetto che sorprende chi proviene da Braze o Customer.io: Klaviyo non è Liquid. Utilizza la sintassi dei template di Django.

{% if person|lookup:'Loyalty Points' > 150 %}
Hey VIP! You've always got free shipping & free returns
{% elif person|lookup:'Loyalty Points' > 0 %}
You have {{ person|lookup:'Loyalty Points' }} points, and you just need 150 to become a VIP!
{% else %}
Have you heard about our VIP program? Join today on our website to start earning rewards.
{% endif %}

I tag sono talmente simili a quelli di Liquid da trarre in inganno, finché la differenza tra elif e elsif non ti rovina il pomeriggio. La personalizzazione con un valore di fallback si scrive così: {{ first_name|default:'friend' }}.

Docs: Klaviyo Smart Translations · sintassi Django

Localizzazione delle email in Mailchimp

Mailchimp non offre una funzionalità nativa per le campagne multilingue. Utilizza invece i merge tag condizionali: l'approccio documentato consiste nell'inserire tutte le versioni linguistiche in un'unica email, lasciando che le istruzioni condizionali selezionino quella da visualizzare.

*|IF:MC_LANGUAGE=es|*
Spanish content here.
*|ELSEIF:MC_LANGUAGE=de|*
German content here.
*|ELSE:|*
Display English content for everyone else.
*|END:IF|*

*|MC_LANGUAGE|* contiene il codice lingua del contatto e *|MC_LANGUAGE_LABEL|* il nome leggibile. Mailchimp cerca di rilevare la lingua dal browser dell'iscritto; puoi anche impostarla per ogni singolo contatto in Profilo → Impostazioni → Lingua, oppure massivamente in fase di importazione. Ricorda che *|END:IF|* chiude sia i blocchi IF sia quelli IFNOT.

Spesso è proprio questo limite a far pendere l'ago della bilancia. Un'email localizzata con l'oggetto nella lingua sbagliata si gioca l'apertura prima ancora che il testo possa fare la sua parte; ecco perché la maggior parte dei team che gestisce più di due lingue su Mailchimp finisce comunque per creare campagne separate. A quel punto, l'approccio dei merge tag condizionali non ha portato alcun vantaggio. È un dettaglio che conviene conoscere in fase di pianificazione, piuttosto che a template già ultimato.

Docs: Tradurre i contenuti in Mailchimp

Localizzazione delle email in Iterable

Iterable dispone di una vera e propria funzionalità dedicata ai locale, e la sua documentazione è piacevolmente schietta su ciò che questo comporta (e cosa no):

I locale non traducono i contenuti.

La piattaforma fornisce la struttura per le varianti, ma le traduzioni spettano a te. In cambio, tutte le varianti condividono lo stesso templateId: in questo modo le metriche restano unificate, invece di frammentarsi in dieci template diversi. Per chiunque abbia provato a generare report per una campagna suddivisa in copie per ogni lingua, questo vantaggio da solo ripaga ampiamente la configurazione.

Il campo deve chiamarsi esattamente locale. Iterable specifica chiaramente che, se lo chiami languagePreference o in qualunque altro modo, non sarà in grado di associare gli utenti alle varianti. I nomi dei locale seguono gli standard ISO-639 e ISO-3166 (fr-CA, fr-FR); sono supportati i codici a tre lettere e, poiché i locale non possono essere rinominati dopo la creazione, è opportuno definire la propria convenzione di nomenclatura prima di crearne una ventina. Se il campo locale è vuoto, viene utilizzata la localizzazione predefinita; in caso di mancata corrispondenza, un'impostazione a livello di progetto stabilisce se saltare l'invio o inviare la versione predefinita.

Iterable sconsiglia esplicitamente anche l'approccio "fai da te":

Sebbene Iterable sia una piattaforma flessibile e consenta di creare contenuti in più lingue utilizzando Handlebars o Catalog, queste non sono considerate best practice per la localizzazione.

Il sistema di templating è Handlebars e i nomi dei campi sono sensibili alle maiuscole e minuscole. C'è un'insidia nell'editor WYSIWYG che potrebbe crearti problemi: le istruzioni condizionali devono essere racchiuse tra commenti HTML, altrimenti l'editor le corrompe.

<!--{{#if activeUser}}-->
    <div>Hi active user!</div>
<!--{{else}}-->
    <div>Hi inactive user</div>
<!--{{/if}}-->

Per la gestione del flusso (round-trip), l'endpoint GET /api/templates/email/get estrae il contenuto dei template per i traduttori.

Docs: Iterable in più lingue

Localizzazione delle email in Brevo

Brevo si posiziona tra le piattaforme che gestiscono la traduzione per te ed è il concorrente più diretto di Mailchimp per questa specifica funzionalità. Crei un'unica campagna che si adatta alla lingua o al codice paese del contatto, clicchi su Aggiungi lingue e Brevo duplica la campagna per ogni lingua affinché tu possa tradurla, manualmente o con Aura, il suo assistente IA.

La varietà di elementi che puoi differenziare per lingua è superiore alla media: nome del mittente, oggetto, testo di anteprima e il design stesso dell'email, oltre a reply-to, tracciamento di Google Analytics e pagina di disiscrizione personalizzata. L'oggetto è l'elemento più rilevante, dato che è proprio ciò che Mailchimp non consente di fare.

I limiti documentati: non sono supportate le traduzioni basate su file (quindi niente round-trip via CSV, il che esclude Brevo se lavori con un fornitore di traduzioni esterno), non funziona con le campagne di test A/B e le sezioni salvate devono essere create per ogni singola lingua. I contatti il cui attributo lingua non corrisponde a nessuna delle configurazioni ricevono la versione predefinita.

Docs: Campagne multilingue di Brevo

Liquid, Handlebars e merge tag: le parti che devono restare intatte

Indipendentemente dalla piattaforma utilizzata, la fase di traduzione vera e propria ha un requisito imprescindibile: il testo contiene elementi di sintassi del template e ogni singolo carattere deve essere restituito esattamente com'era in origine. Tradurre un tag come {% endif %} significa compromettere l'invio dell'email.

Ecco come si presenta la sintassi nelle diverse piattaforme trattate in questa guida:

Quasi tutti i problemi che si verificano in questo ambito sono riconducibili a tre tipi di errore.

Il modello traduce il token. Ti ritrovi con {{ prénom }} o {% si %}, e l'invio fallisce oppure viene visualizzato il testo letterale. Qualsiasi strumento degno di nota maschera i token prima che il testo raggiunga il modello e li ripristina in seguito, in modo che il modello non li tratti mai come parole comuni.

Il modello sposta il token. L'ordine delle parole cambia legittimamente da una lingua all'altra, quindi è normale che un token si sposti. Il problema sorge quando finisce nella proposizione sbagliata, o quando un {% if %} e il suo {% endif %} si ritrovano invertiti. La posizione è fondamentale; la soluzione consiste nel verificare che il set di token in uscita corrisponda a quello in entrata e, in caso contrario, elaborare nuovamente il blocco.

Il numero di token cambia. La perdita di un token è l'eventualità più pericolosa, perché l'email viene comunque generata, ma con un nome o una ramificazione mancante. Ecco perché contare i token è più importante che fare un controllo a occhio.

Ed ecco la regola che vale per tutti e tre: le ramificazioni condizionali sono stringhe separate. In questa riga sono presenti due frammenti di testo indipendenti: se un traduttore o un modello riceve l'intero contenuto come un unico blocco, farà un lavoro peggiore su entrambi rispetto a chi riceve ogni parte separatamente e con il relativo contesto:

{% if ${loyalty_tier} == 'gold' %}Gold members get an extra 10%.{% else %}Join Gold for an extra 10%.{% endif %}

Email HTML e tabelle di stringhe: due compiti diversi

C'è un bivio in questo percorso che determina l'intera configurazione, e spesso lo si scopre solo a metà strada.

Alcuni contenuti delle email sono dei documenti: un template HTML, un'email renderizzata, qualcosa con una struttura e un flusso che si sviluppa dall'alto verso il basso. È preferibile tradurli come un testo unitario, perché il titolo e il corpo sottostante sono legati tra loro, e un traduttore che può vederli entrambi prenderà decisioni migliori rispetto a chi ne visualizza solo uno alla volta.

In altri casi, il contenuto delle email è una tabella di stringhe: un elenco basato su chiavi in cui ogni riga è a sé stante. cta_button, subject_line, footer_unsub. Questi elementi portano con sé metadati che contano più del testo stesso: una chiave che non deve mai cambiare, una nota di contesto e, spesso, un limite di caratteri, perché un oggetto troppo lungo finisce per essere troncato nella posta in arrivo.

I CSV di Braze e Klaviyo e tutti i formati di file di localizzazione del mondo del software (gettext PO, XLIFF) sono tabelle di stringhe. I template HTML sono documenti. Se trattate una tabella di stringhe come un documento, perderete le chiavi; se trattate un documento come una tabella di stringhe, smembrerete il testo in frammenti scollegati.

Ecco perché in Transept abbiamo sviluppato il supporto per i file di stringhe come un percorso a sé stante, invece di integrarlo nell'importazione dei documenti. Un CSV con i testi delle email viene visualizzato come una griglia — chiave, sorgente, traduzione — con il limite di caratteri indicato da un contatore in tempo reale e la nota di contesto associata a ogni riga.

L'aspetto fondamentale è che il file venga restituito con la stessa struttura con cui è arrivato. Esporti il file originale tradotto, con le chiavi e le colonne posizionate esattamente dove la piattaforma se le aspetta, anziché esportare un file da dover poi rielaborare a mano.

Cosa abbiamo scoperto integrando il supporto per le email in Transept

Abbiamo rilasciato la funzione di importazione dei file di stringhe proprio per questo flusso di lavoro e, durante il processo, sono emersi dettagli che non ho mai visto documentati altrove. Si tratta di osservazioni dirette, frutto del nostro codice e dei nostri test.

Tecnicamente, "50% off" è una conversione printf

Le stringhe software usano spesso segnaposto printf: %s, %d, %1$s. Se si mascherano questi elementi prima della traduzione, la regex più ovvia accetta l'intero set di flag di printf, incluso lo space flag (% d stampa uno spazio davanti ai numeri positivi). Si tratta di sintassi printf valida e accettarla è una scelta difendibile.

È anche un disastro per i testi di marketing. Accettando lo space flag, 50% off contiene una corrispondenza: % o viene interpretato come una conversione ottale con flag dello spazio. Lo stesso vale per 100% organic e per Up to 70% off, che è la costruzione in assoluto più comune nelle email promozionali.

Abbiamo fatto una prova in entrambi i modi:

Mascherare % o trasforma la riga dello sconto in un segnaposto, consegnando al modello una frase mutilata. Abbiamo scelto di escludere deliberatamente lo space flag senza perdere nulla: nessuna vera tabella di stringhe lo utilizza.

Il tag di personalizzazione di Braze ha tre parentesi graffe di chiusura

Lo abbiamo scoperto scrivendo questa guida, il che è un ottimo motivo per scriverne.

La sintassi di Braze è {{${first_name}}}. Contate le parentesi graffe di chiusura: quella dell'attributo }, poi le due che chiudono il tag di output di Liquid. Tre di fila.

Quasi ogni tokenizer Liquid esegue una scansione non-greedy fino alla prima occorrenza di }}. Di fronte a {{${first_name}}}, che chiude una parentesi in anticipo: il sistema cattura {{${first_name}} e lascia una } isolata nel testo da tradurre. Il token sembra gestito, ma quella parentesi superstite finisce al modello come semplice testo e ritorna spostata, duplicata o del tutto sparita.

{{${first_name}}}, your spring sale starts now

  non-greedy scan  →  token: {{${first_name}}     leftover: "}, your spring sale starts now"
  brace-aware scan →  token: {{${first_name}}}    leftover: ", your spring sale starts now"

Al nostro è capitata proprio la prima. Lo abbiamo individuato e risolto permettendo un livello di annidamento all'interno del token, e abbiamo aggiunto la sintassi esatta di Braze alla suite di test. Se gestite i vostri strumenti email, testateli specificamente con {{${attribute}}}, perché la forma semplice {{ attribute }} funziona correttamente e maschera completamente il bug.

Le virgolette nei segnaposto corrompono le risposte JSON

Quando si invia un batch di stringhe a un modello e si vincola la risposta al formato JSON, una virgoletta " senza escape all'interno di una stringa di risposta chiude la stringa in anticipo, scartando il resto del batch. Abbiamo riscontrato questo problema con segnaposto che contenevano attributi tra virgolette e lo abbiamo riprodotto in circa il 58% delle esecuzioni con un modello.

La soluzione non consiste nel migliorare le istruzioni di escape nel prompt, ma nel rendere il formato di trasmissione privo di virgolette, così che l'errore non possa verificarsi: il modello vede sempre e solo segnaposto senza virgolette e la forma canonica originale viene ripristinata successivamente. Istruire un modello a non corrompere il JSON funziona quasi sempre, il che rappresenta il peggior profilo di affidabilità possibile, perché gli errori passano inosservati.

Le voci fuzzy sono un segnale, non una traduzione

Se le stringhe provengono da file PO di gettext, le voci presentano un flag fuzzy che significa "corrispondenza automatica, non confermata da un revisore". Trattare le voci fuzzy come traduzioni definitive equivale a importare una serie di congetture come lavoro approvato.

Le escludiamo dal popolamento iniziale, le traduciamo da zero e rimuoviamo il flag fuzzy in fase di esportazione, poiché a quel punto la voce è stata revisionata e l'indicazione non è più veritiera.

Best practice per la localizzazione delle campagne email

Le abitudini che distinguono un programma fluido da uno problematico, elencate in ordine approssimativo in base a quanti grattacapi permettono di evitare.

Stabilite i codici locale una volta sola, a livello di profilo. A due lettere o con specifica regionale, mantenendoli coerenti ovunque. La maggior parte dei casi in cui "la traduzione non compare" è dovuta a un profilo nl-BE abbinato a un messaggio in nl.

Definite il contesto di ogni stringa prima di inviarla in traduzione. Un traduttore che vede Shop the sale in un foglio di calcolo non può sapere se si tratti di un pulsante, un titolo o un link, né che ha solo diciotto caratteri a disposizione. Ogni piattaforma che offre un campo per il contesto o la descrizione vi sta chiedendo l'elemento che più di ogni altro migliora la qualità del risultato, eppure non lo compila quasi nessuno.

Rispettate i limiti di caratteri come un vincolo fondamentale. Il tedesco occupa da 1,5 a 2 volte lo spazio dell'inglese. Una CTA che rientra nei limiti in inglese finirà per debordare, e un oggetto che sembra perfetto verrà troncato a metà parola nella posta in arrivo. Associate il limite alla stringa, così chi traduce potrà tenere d'occhio il contatore.

Mantenete un elenco dei termini da non tradurre. Nomi di prodotti, termini del brand, nomi di funzionalità. Klaviyo ha questa funzione integrata; su altre piattaforme si trova nel vostro glossario. In ogni caso, mettetelo per iscritto prima del primo invio, non dopo aver trovato il nome del vostro prodotto declinato in sei varianti diverse.

Traducete i fallback. Ogni filtro default:, ogni ramo {% else %}, ogni "Ciao" che compare quando manca il nome. Queste sono le stringhe che non appaiono mai in anteprima, quindi non vengono mai revisionate, e finiscono proprio ai destinatari di cui sapete meno.

Riutilizzate le vostre decisioni tra un invio e l'altro. I testi delle campagne si ripetono costantemente: lo stesso footer, la stessa dicitura per la disiscrizione, la stessa impostazione stagionale ogni anno. Una memoria di traduzione permette di definire "Acquista i saldi" una volta sola e di mantenerlo per tutte le campagne successive, invece di finire con tre varianti diverse perché tre processi distinti hanno portato a tre decisioni differenti.

Effettuate un invio di prova in ogni lingua prima dell'invio effettivo. Eseguite il rendering del template reale con un profilo vero per ogni lingua. Le logiche condizionali che sembrano corrette nell'editor possono presentare errori che solo il rendering è in grado di evidenziare; questo è il passaggio che permette di individuare un fallback non tradotto o un ramo corrotto quando rimediare non costa ancora nulla.

Domande frequenti

Cos'è la localizzazione delle email?

La localizzazione delle email è il processo di adattamento di una campagna email a una lingua e a un mercato diversi: dai testi all'oggetto e al preheader, fino ai fallback di personalizzazione e alle convenzioni di formattazione del locale di destinazione. Si distingue dalla semplice traduzione perché un'email contiene elementi di sintassi del template (merge tag, logiche condizionali Liquid o Handlebars) che devono restare intatti, oltre a vincoli come la lunghezza dell'oggetto che la traduzione è tenuta a rispettare.

Quali piattaforme email traducono le campagne automaticamente?

Klaviyo (Smart Translations, oltre 60 lingue), Customer.io (traduzione automatica tramite IA per email, SMS, WhatsApp, push e in-app) e Brevo (tramite l'assistente Aura) generano traduzioni all'interno dell'editor. Braze e Iterable forniscono la struttura per i locale, ma richiedono che le traduzioni siano fornite dall'utente. Mailchimp non dispone di una funzione nativa per le campagne multilingua e si affida ai tag merge condizionali.

Posso tradurre l'oggetto di un'email su Mailchimp?

No. La documentazione di Mailchimp specifica che non è possibile tradurre l'oggetto, poiché i tag merge condizionali non funzionano nel campo dell'oggetto. Per inviare oggetti localizzati tramite Mailchimp, è necessario creare una campagna per ogni lingua, segmentata in base al campo lingua del contatto.

Come evitare che la traduzione corrompa i tag Liquid?

Mascherate i token prima che il testo raggiunga il modello di traduzione, così che non vengano scambiati per parole, poi ripristinateli e verificate che il set di token in output corrisponda a quello iniziale prima di accettare il risultato. Anche tradurre ogni ramo condizionale come una stringa a sé stante, invece di passare l'intera riga {% if %}...{% endif %} come un unico blocco, migliora la qualità perché ogni segmento viene tradotto come la frase autonoma che è a tutti gli effetti.

Qual è la differenza tra un'email HTML e una tabella di stringhe?

Un'email HTML è un documento: una prosa coesa e strutturata, da tradurre preferibilmente nel suo insieme affinché il contesto si mantenga tra il titolo e il corpo del testo. Una tabella di stringhe è invece un elenco basato su chiavi in cui ogni riga è a sé stante e include una chiave che non deve mai cambiare, solitamente una nota di contesto e spesso un limite di caratteri. Le esportazioni CSV di Braze e Klaviyo, i file PO di gettext e gli XLIFF sono tutti esempi di tabelle di stringhe. I due formati richiedono approcci differenti: trattare una tabella di stringhe come un documento fa perdere le chiavi, mentre trattare un documento come una tabella di stringhe ne frammenta la prosa.

È meglio usare l'esportazione CSV o le API della piattaforma per le traduzioni?

Il CSV è la scelta più pratica quando la traduzione è affidata a una persona o a un fornitore esterno, ed è il metodo documentato da Braze e Klaviyo. Il ricorso alle API è preferibile quando il processo è ricorrente o il volume è tale da rendere la gestione manuale dei file un collo di bottiglia. Braze offre un'API per le traduzioni (in accesso anticipato al momento della stesura) e Iterable espone il contenuto dei template tramite GET /api/templates/email/get. Brevo non supporta nessuna delle due opzioni: non prevede la traduzione basata su file, quindi le campagne devono essere tradotte direttamente nell'interfaccia.

Quante lingue può supportare una singola campagna email?

Dipende dalla piattaforma. Braze consente fino a 200 locale per area di lavoro e 200 tag di traduzione per messaggio. Klaviyo copre oltre 60 lingue tramite Smart Translations. Customer.io accetta diverse centinaia di codici lingua e lingua-regione. In pratica, il limite della piattaforma è raramente il vero ostacolo; il vero vincolo è il numero di lingue che si riesce a mantenere revisionate e aggiornate man mano che il testo originale cambia.