Localização de e-mail: como traduzir campanhas nos principais ESPs

Eu lidero o marketing de ciclo de vida, então passei boa parte da vida mergulhado em editores de campanha — e a localização de e-mails era algo que eu vivia subestimando. Traduzir uma landing page é um processo linear, com uma lógica só. Já traduzir uma campanha de e-mail é um trabalho diferente em cada ferramenta que você usa, porque cada plataforma decidiu, por conta própria, o que de fato define um "idioma".

Algumas plataformas traduzem o texto para você. Outras oferecem campos vazios para cada idioma e esperam que você os preencha. Uma delas exige que você escreva a lógica condicional dentro do corpo do e-mail. E, por trás de todas elas, reside o mesmo perigo: o seu texto está repleto de sintaxe de template que deve voltar da tradução intacta, caractere por caractere, caso contrário, o envio falha.

Este guia detalha o que cada uma das principais plataformas realmente faz, como extrair o texto e inseri-lo de volta, e quais etapas do processo são as mesmas em qualquer lugar.

Três formas como as plataformas de e-mail lidam com idiomas

Antes de entrar nos detalhes de cada plataforma, é útil saber com qual das três arquiteturas você está lidando. Isso define todo o seu fluxo de trabalho e, geralmente, não é algo que você possa mudar.

A linha do meio é onde se concentram os programas multilíngues mais sérios, e é nela que este guia mais se detém, pois o momento em que a "plataforma oferece uma grade vazia de localidades" é justamente quando um fluxo de trabalho de tradução se torna indispensável.

Localização de e-mails no Braze

O Braze utiliza o modelo de marcação e preenchimento e possui a sintaxe mais distinta de todas. Você envolve cada parte traduzível de um e-mail em uma tag Liquid com um ID:

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

O formato geral é {% translation seu_id_aqui %}texto padrão{% endtranslation %}, e os IDs devem ser exclusivos dentro de uma mensagem. Existe um atalho no editor para envolver uma seleção (Cmd+Alt+L no macOS, Ctrl+Alt+L no Windows). O Braze não traduz nada por conta própria: você fornece as traduções fazendo o upload de um CSV ou por meio da API de traduções, que, no momento em que este texto foi escrito, está em acesso antecipado.

Os limites documentados tornam-se cruciais quando a campanha se torna realidade:

Não há suporte para tags de tradução aninhadas. A localidade é obtida do perfil do usuário, configurada em Settings → Localization Settings, seja por meio dos atributos padrão language e country ou de um atributo personalizado; quando ambos estão presentes, o atributo personalizado prevalece.

Vale a pena conhecer duas particularidades do Braze antes de começar:

Envolver uma URL interrompe o rastreamento de cliques, a menos que a parte envolvida termine em ? ou &. O Braze documenta a solução alternativa diretamente:

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

Não abra o CSV de tradução no Excel. A própria documentação do Braze recomenda evitá-lo devido a problemas de exibição com caracteres de outros idiomas. Essa é a forma mais comum de um processo de localização do Braze ser corrompido sem que ninguém perceba, e a culpa é do Excel, não do Braze: o Excel tenta adivinhar a codificação do CSV e acaba errando.

Os Content Blocks do Braze podem conter suas próprias traduções, permitindo localizar um rodapé compartilhado de uma só vez, em vez de individualmente em cada campanha. Referencie-os como {{content_blocks.${your_block}}}; blocos inseridos via Liquid permanecem vinculados e são atualizados automaticamente, ao contrário daqueles inseridos pelo menu suspenso do editor. Se um bloco não tiver tradução para uma determinada localidade, ele será renderizado no idioma original em vez de falhar.

Se você prefere ramificar em vez de usar tags, o Braze também permite seguir o caminho manual:

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

Note que, dentro de uma tag Liquid, o atributo aparece de forma simples como ${language}, enquanto no corpo da mensagem ele é envolvido por chaves: {{${language}}}. O Braze recomenda sempre incluir a ramificação {% else %}, pois alguns usuários não têm um idioma definido, utilizam um idioma sem suporte ou estão em um dispositivo onde o idioma não pode ser detectado.

Docs: Localização no Braze

Localização de e-mails no Customer.io

O Customer.io seguiu o caminho oposto: a localização é nativa, integrada ao editor de mensagens, e conta com um botão de tradução automática por IA. Você cria a mensagem em um idioma padrão e adiciona variantes sem precisar ramificar a campanha. O recurso funciona para e-mail, SMS, WhatsApp, push e in-app.

O nome do atributo de idioma é você quem escolhe. Em Workspace Settings → Language settings, você informa ao Customer.io qual atributo de perfil armazena o idioma — pode ser language, locale ou o que o seu CRM já utilizar. Os valores devem ser um código de duas letras (en) ou um par idioma-região separado por hífen (en-US). Não há distinção entre maiúsculas e minúsculas, portanto es-MX e es-mx funcionam da mesma forma, mas o hífen é obrigatório.

A tradução automática abrange o corpo do texto, as linhas de assunto e o preheader. O que ela não cobre é esta lista que vale a pena deixar bem à vista:

• Imagens, embora o texto alternativo seja traduzido
• Layouts de e-mail nos editores de rich-text e de código
• Textos estáticos em Liquid, valores de atributos e valores de filtros
• Snippets
• Textos de componentes personalizados, a menos que você desvincule o componente primeiro

O terceiro item merece um exemplo, pois é o mais traiçoeiro. A própria documentação de localização do Customer.io usa esta linha:

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

A palavra ami é o fallback exibido para qualquer pessoa que não tenha o primeiro nome cadastrado. É um texto real, visível para o leitor, e fica dentro de um filtro Liquid, que a tradução automática não altera. Envie isso para um público alemão e uma parte dos seus destinatários será saudada como ami. Cada string de fallback em cada filtro default: precisa ser traduzida manualmente em cada variante, e não há nada na interface que vá te lembrar disso.

Mais duas limitações para se planejar: as traduções não são atualizadas automaticamente quando você altera o template padrão, e os testes A/B com traduções funcionam em envios pontuais, mas não em transmissões acionadas por API ou automações.

Os Snippets merecem uma observação à parte. Eles são o mecanismo de conteúdo reutilizável ({{snippets.your_snippet}}, com 16 KB cada por padrão), e a tradução automática os ignora. A recomendação do Customer.io é colocar as condicionais dentro do próprio snippet:

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

Assim, uma estratégia no Customer.io geralmente se resume a variantes nativas para o corpo das mensagens, somadas a condicionais mantidas manualmente em cada snippet compartilhado. Vale a pena saber disso antes de presumir que o botão de IA dá conta de tudo.

Docs: Localização no Customer.io

Localização de e-mails no Klaviyo

O recurso do Klaviyo chama-se Smart Translations e traduz automaticamente o conteúdo das mensagens para mais de 60 idiomas dentro do editor de campanhas ou fluxos. Você o ativa em Settings → Account → Translation com o botão "Translate messages". Ele exige uma conta paga e não está disponível no período de teste gratuito.

O que o Klaviyo lista como traduzível automaticamente é bem específico: blocos de texto, rótulos e textos alternativos (alt text). As linhas de assunto não fazem parte dessa lista, portanto, verifique isso em sua conta antes de presumir que uma campanha esteja totalmente coberta.

A definição do idioma utiliza o Locale do perfil por padrão, recorrendo a Country ou Language caso esses campos estejam preenchidos. O Klaviyo aceita códigos BCP-47 (en-GB, es-ES) e também valores em texto simples, como English ou French.

Duas coisas tornam o Klaviyo agradável de usar. A primeira é a lista Do Not Translate: nomes de marcas, produtos e qualquer termo que você não queira que o modelo altere, definidos uma única vez no nível da conta. A maioria das plataformas não possui um equivalente, e isso faz a diferença entre o nome do seu produto sobreviver a dez localidades ou se transformar em dez palavras diferentes.

A segunda é o menu de substituição por elemento. Em qualquer item traduzido, você tem as opções Re-translate, Match source, Edit e Ignore, e pode alternar entre os idiomas usando as setas no topo do editor. Isso transforma a revisão em uma conferência rápida dos itens sinalizados, em vez de exigir uma releitura completa.

O Klaviyo também oferece suporte a um fluxo de ida e volta via CSV, que é a melhor opção se você trabalha com tradutores ou ferramentas externas. Em Translate → menu de ações, existe a opção Export CSV, nos formatos Smartling ou Simple. As colunas são block_id (o identificador exclusivo de cada string traduzível), source (o texto original) e uma coluna por idioma, nomeada com seu respectivo código. As regras são rígidas e sensatas: não edite nem exclua valores de block_id, não adicione linhas e não altere os valores de source.

Algo que surpreende quem vem do Braze ou do Customer.io: o Klaviyo não usa Liquid. Ele utiliza a sintaxe de templates do 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 %}

As tags são parecidas o suficiente com as do Liquid para te enganar, e então a confusão entre elif e elsif estraga a sua tarde. A personalização com um fallback é escrita como {{ first_name|default:'friend' }}.

Docs: Smart Translations no Klaviyo · Sintaxe do Django

Localização de e-mails no Mailchimp

O Mailchimp não possui um recurso nativo de campanhas multilíngues. O que ele oferece são tags de mesclagem condicionais, e a abordagem documentada é escrever todos os idiomas em um único e-mail e deixar que as condicionais façam a seleção.

*|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|* armazena o código do idioma do contato, enquanto *|MC_LANGUAGE_LABEL|* contém o nome legível. O Mailchimp tenta detectar o idioma pelo navegador do assinante; você também pode defini-lo por contato em perfil → Settings → Language, ou em massa na importação. Note que *|END:IF|* encerra tanto blocos IF quanto IFNOT.

Geralmente, é esse limite que define a estratégia. Um e-mail localizado com o assunto no idioma errado perde a abertura antes mesmo que o conteúdo faça diferença. Por isso, a maioria das equipes que trabalha com mais de dois idiomas no Mailchimp acaba criando campanhas separadas para cada língua de qualquer forma, o que torna a abordagem de tags de mesclagem condicionais inútil. É melhor saber disso na fase de planejamento do que só depois de o template estar pronto.

Docs: Traduzir conteúdo no Mailchimp

Localização de e-mails no Iterable

O Iterable possui um recurso de localidades (locales) propriamente dito, e sua documentação é surpreendentemente direta sobre o que isso significa — e o que não significa:

As localidades não traduzem o conteúdo.

Você recebe a estrutura para as variantes; as traduções ficam por sua conta. Em troca, todas as variantes compartilham um único templateId, garantindo que suas métricas permaneçam unificadas em vez de se fragmentarem em dez templates diferentes. Para quem já tentou gerar relatórios de uma campanha dividida em cópias por idioma, só isso já vale a configuração.

O campo deve se chamar exatamente locale. O Iterable deixa claro que, se você o nomear como languagePreference ou qualquer outra coisa, ele não conseguirá associar os usuários às variantes. Os nomes das localidades seguem o padrão ISO-639 mais ISO-3166 (fr-CA, fr-FR), códigos de três letras são suportados e as localidades não podem ser renomeadas após a criação; portanto, defina sua convenção de nomenclatura antes de criar vinte delas. Uma localidade em branco recebe a localização padrão; já uma divergência é regida por uma configuração no nível do projeto, que permite escolher entre ignorar o envio ou enviar a versão padrão.

O Iterable também desaconselha explicitamente o caminho do "faça você mesmo":

Embora o Iterable seja uma plataforma flexível e você possa criar conteúdo em vários idiomas usando Handlebars ou Catalog, essas não são as melhores práticas para localização.

O sistema de templates utiliza Handlebars, e os nomes dos campos diferenciam maiúsculas de minúsculas. Há uma peculiaridade que pode te pegar no editor WYSIWYG: as condicionais precisam estar envoltas em comentários HTML, do contrário, o editor as corrompe.

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

Para o fluxo de ida e volta, o GET /api/templates/email/get extrai o conteúdo do template para os tradutores.

Docs: Vários idiomas no Iterable

Localização de e-mails no Brevo

O Brevo faz parte do grupo de plataformas que traduzem por você e é o concorrente mais direto do Mailchimp nesse recurso específico. Você cria uma única campanha que se adapta ao idioma ou código de país do contato, clica em Add languages e o Brevo duplica a campanha para cada idioma para que você a traduza, manualmente ou com o Aura, seu assistente de IA.

A gama de elementos que você pode variar por idioma é mais ampla do que na maioria das ferramentas: nome do remetente, linha de assunto, texto de visualização e o próprio design do e-mail, além do e-mail de resposta, rastreamento do Google Analytics e uma página de descadastro personalizada. A linha de assunto é o grande destaque, já que é exatamente o que o Mailchimp não consegue fazer.

Os limites documentados: não há suporte para traduções baseadas em arquivos (ou seja, sem fluxo de ida e volta via CSV, o que inviabiliza o Brevo se você trabalha com um fornecedor externo de tradução), o recurso não funciona com campanhas de teste A/B e as seções salvas exigem uma versão para cada idioma. Contatos cujo atributo de idioma não corresponda a nenhuma configuração recebem a versão padrão.

Docs: Campanhas multilíngues no Brevo

Liquid, Handlebars e tags de mesclagem: as partes que devem sobreviver

Independentemente da plataforma utilizada, a etapa de tradução propriamente dita tem um requisito rígido. O seu texto contém sintaxe de template, e cada caractere dela precisa retornar exatamente como entrou. Um {% endif %} traduzido resulta em falha no envio.

Veja como é a sintaxe nas plataformas abordadas neste guia:

Três modos de falha explicam quase tudo o que dá errado aqui.

O modelo traduz o token. Você recebe {{ prénom }} de volta, ou {% si %}, e o envio falha ou renderiza o texto literal. Qualquer ferramenta que se preze mascara os tokens antes que o texto chegue ao modelo e os restaura depois, para que o modelo nunca os veja como palavras.

O modelo move o token. A ordem das palavras muda naturalmente entre os idiomas, então o token deve se mover. O problema é quando ele vai parar na oração errada, ou quando um {% if %} e seu {% endif %} terminam em uma ordem diferente. A posição é fundamental; a solução é verificar se o conjunto de tokens de saída corresponde ao que entrou e reprocessar o bloco quando isso não acontecer.

A contagem de tokens muda. O token perdido é o mais perigoso, pois o e-mail ainda é renderizado, mas com um nome ou uma ramificação a menos. É por isso que a contagem é mais importante do que o "olhômetro".

E a regra que abrange os três: ramificações condicionais são strings separadas. Nesta linha, há dois trechos de texto independentes, e um tradutor ou modelo que receba tudo como um bloco só fará um trabalho pior em ambos do que se recebesse cada um separadamente, com contexto:

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

E-mails em HTML e tabelas de strings são duas tarefas diferentes

Há uma bifurcação neste caminho que define toda a sua configuração, e as pessoas geralmente a descobrem na metade do processo.

Alguns conteúdos de e-mail são documentos: um template HTML, um e-mail renderizado, algo com estrutura e fluidez que se lê de cima a baixo. Você quer que eles sejam traduzidos como prosa contínua, pois o título e o corpo abaixo dele formam um conjunto, e um tradutor que consegue ver ambos toma decisões melhores do que um que vê cada parte isoladamente.

Outros conteúdos de e-mail são uma tabela de strings: uma lista indexada por chaves em que cada linha é independente. cta_button, subject_line, footer_unsub. Elas vêm com metadados que importam mais do que a prosa: uma chave que nunca deve mudar, uma nota de contexto e, muitas vezes, um limite de caracteres, pois uma linha de assunto longa demais acaba sendo cortada na caixa de entrada.

CSVs do Braze, CSVs do Klaviyo e todos os formatos de arquivo de localização do mundo do software (gettext PO, XLIFF) são tabelas de strings. Seus templates HTML são documentos. Trate uma tabela de strings como um documento e você perderá as chaves; trate um documento como uma tabela de strings e você retalhará a prosa em fragmentos desconectados.

É por isso que criamos o suporte a arquivos de strings no Transept como um fluxo próprio, em vez de incorporá-lo à importação de documentos. Um CSV com o texto do e-mail é exibido como uma grade: chave, origem, tradução, com o limite de caracteres mostrado em um contador em tempo real e a nota de contexto anexada a cada linha.

O ponto fundamental é que o arquivo seja exportado exatamente com a mesma estrutura em que chegou. Você exporta o arquivo original traduzido, com as chaves e colunas nos locais esperados pela plataforma, em vez de exportar algo que precise ser reformatado manualmente depois.

O que descobrimos ao implementar o suporte a e-mail no Transept

Lançamos a importação de arquivos de strings justamente para esse fluxo de trabalho, e o processo revelou detalhes que eu ainda não vi registrados em lugar nenhum. São descobertas nossas, extraídas do nosso próprio código e das nossas baterias de testes.

"50% off" é, tecnicamente, uma conversão de printf

Strings de software costumam usar placeholders de printf: %s, %d, %1$s. Se você estiver mascarando esses marcadores antes da tradução, a regex óbvia aceita o conjunto completo de flags do printf, o que inclui a flag de espaço (% d imprime um espaço antes de números positivos). É um printf válido, e aceitá-lo é justificável.

Isso também é um desastre para o copy de marketing. Com a flag de espaço aceita, 50% off gera uma correspondência: % o é interpretado como uma conversão octal com flag de espaço. O mesmo acontece com 100% organic e com Up to 70% off, que é a construção mais comum em e-mails promocionais.

Testamos das duas formas:

Mascarar % o transforma sua linha de desconto em um placeholder e entrega uma frase mutilada ao modelo. Rejeitamos a flag de espaço deliberadamente e não perdemos nada: nenhuma tabela de strings real a utiliza.

A tag de personalização do Braze tem três chaves de fechamento

Encontramos este aqui enquanto escrevíamos este guia, o que é um ótimo argumento para se escrever guias.

A sintaxe do Braze é {{${first_name}}}. Conte as chaves de fechamento: a do próprio atributo }, e depois as duas que fecham a tag de saída do Liquid. Três seguidas.

Quase todo tokenizador de Liquid faz uma varredura não gulosa até o primeiro }}. Diante de {{${first_name}}}, isso fecha uma das chaves antes da hora: ele captura {{${first_name}} e deixa uma } avulsa no texto traduzível. O token parece ter sido processado. A chave perdida vai para o modelo como texto comum e volta movida, duplicada ou simplesmente desaparece.

{{${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"

A nossa ferramenta fez exatamente isso. Nós detectamos o erro, o corrigimos para permitir um nível de aninhamento dentro do token e adicionamos a sintaxe exata do Braze à suíte de testes. Se você mantém seu próprio ferramental de e-mail, teste-o especificamente com {{${attribute}}}, pois o formato simples {{ attribute }} funciona perfeitamente e oculta o bug por completo.

Aspas dentro de placeholders quebram respostas JSON

Quando você envia um lote de strings para um modelo e restringe a resposta ao formato JSON, uma " não escapada dentro de uma string de resposta fecha a string prematuramente e descarta o restante do lote. Deparamo-nos com isso em placeholders que continham atributos entre aspas, reproduzindo o erro em cerca de 58% das execuções em um dos modelos.

A solução não passa por melhorar as instruções de escape no prompt, mas sim por tornar o formato de transmissão livre de aspas para que a falha não ocorra: o modelo passa a ver apenas placeholders sem aspas, e a forma canônica original é restaurada posteriormente. Orientar o modelo a não quebrar o JSON funciona na maior parte do tempo, o que é o pior perfil de confiabilidade possível, já que as falhas passam despercebidas.

Entradas "fuzzy" são um sinal, não uma tradução

Se as suas strings vêm de arquivos PO do gettext, as entradas trazem uma flag fuzzy que significa: "isso foi uma correspondência automática, um humano ainda não confirmou". Tratar entradas "fuzzy" como traduções finalizadas é o mesmo que aceitar um monte de palpites como trabalho aprovado.

Nós as excluímos da carga inicial, traduzimos tudo do zero e descartamos a flag fuzzy no fluxo de retorno, pois, a essa altura, a entrada já foi revisada e a marcação deixa de ser verdadeira.

Boas práticas para a localização de campanhas de e-mail

Os hábitos que separam um programa tranquilo de um problemático, em ordem aproximada de quanta dor de cabeça eles poupam.

Defina seus códigos de localidade de uma vez por todas, no nível do perfil. Sejam eles de duas letras ou com especificação de região, mantenha a consistência em toda parte. A maioria dos casos em que "a tradução não apareceu" ocorre quando um perfil nl-BE encontra uma mensagem em nl.

Forneça contexto para cada string antes de enviá-la para qualquer lugar. Um tradutor que vê Shop the sale em uma planilha não faz ideia se aquilo é um botão, um título ou um link, nem que dispõe de apenas dezoito caracteres de espaço. Toda plataforma que oferece um campo de contexto ou descrição está solicitando justamente o que mais melhora a qualidade do resultado, e quase ninguém o preenche.

Respeite os limites de caracteres como uma prioridade absoluta. O alemão costuma ocupar de 1,5 a 2 vezes o espaço do inglês. Um CTA que cabe em inglês acabará estourando o layout, e um assunto que parece adequado será truncado no meio de uma palavra na caixa de entrada. Envie o limite junto com a string para que quem for traduzir possa acompanhar o contador.

Mantenha uma lista de termos não traduzíveis. Nomes de produtos, termos de marca, nomes de recursos. O Klaviyo já tem isso integrado; em outras plataformas, essa lista fica no seu glossário. De qualquer forma, registre esses termos antes da primeira execução, e não depois de encontrar o nome do seu produto em seis variantes diferentes.

Traduza os fallbacks. Cada filtro default:, cada ramificação {% else %} e cada "Olá" que aparece quando o nome está ausente. Essas são as strings que nunca aparecem em um preview, por isso nunca são revisadas, e acabam sendo enviadas justamente para os destinatários sobre os quais você menos tem informações.

Reutilize suas decisões em todos os envios. O texto das campanhas se repete constantemente: o mesmo rodapé, a mesma linha de cancelamento de inscrição, a mesma abordagem sazonal todo ano. Uma memória de tradução permite que você defina "Shop the sale" uma única vez e mantenha o padrão em todas as campanhas seguintes, em vez de o termo se fragmentar em três variantes porque três execuções diferentes tomaram decisões distintas.

Faça um envio de teste em todos os idiomas antes do envio real. Renderize o template propriamente dito com um perfil real em cada localidade. Condicionais que parecem corretas no editor falham de formas que só a renderização revela, e este é o passo que detecta um fallback não traduzido ou uma ramificação quebrada enquanto ainda não custa nada.

Perguntas frequentes

O que é a localização de e-mails?

A localização de e-mails é o processo de adaptar uma campanha para outro idioma e mercado: o texto, o assunto e o preheader, os fallbacks de personalização e as convenções de formatação da localidade de destino. Ela se diferencia da tradução simples porque um e-mail carrega sintaxe de template (merge tags, condicionais Liquid ou Handlebars) que deve permanecer inalterada, além de restrições como o comprimento do assunto, que a tradução precisa respeitar.

Quais plataformas de e-mail traduzem campanhas automaticamente?

O Klaviyo (Smart Translations, mais de 60 idiomas), o Customer.io (tradução automática por IA em e-mail, SMS, WhatsApp, push e mensagens in-app) e o Brevo (por meio de seu assistente Aura) geram traduções dentro do editor. O Braze e o Iterable oferecem a estrutura para as localidades, mas esperam que você forneça as traduções. O Mailchimp não possui um recurso nativo para campanhas multilíngues e depende de tags de mesclagem condicionais.

Posso traduzir a linha de assunto no Mailchimp?

Não. A documentação do Mailchimp afirma que não é possível traduzir a linha de assunto, pois as tags de mesclagem condicionais não funcionam no campo de assunto. Para enviar linhas de assunto localizadas pelo Mailchimp, você precisa de uma campanha por idioma, segmentada pelo campo de idioma do contato.

Como evitar que a tradução quebre minhas tags Liquid?

Mascare os tokens antes que o texto chegue ao modelo de tradução para que ele nunca os trate como palavras; depois, restaure-os e verifique se o conjunto de tokens na saída corresponde ao da entrada antes de aceitar o resultado. Traduzir cada ramificação condicional como uma string individual, em vez de enviar toda a linha {% if %}...{% endif %} como um bloco único, também melhora a qualidade, pois cada ramificação é traduzida como a frase independente que de fato é.

Qual é a diferença entre um e-mail HTML e uma tabela de strings?

Um e-mail HTML é um documento: prosa contínua com estrutura, melhor traduzido integralmente para que o contexto se mantenha entre o título e o corpo. Já uma tabela de strings é uma lista indexada por chaves em que cada linha é independente, contendo uma chave que nunca deve mudar, geralmente uma nota de contexto e, frequentemente, um limite de caracteres. As exportações em CSV do Braze e do Klaviyo, arquivos PO do gettext e XLIFF são todos tabelas de strings. Os dois formatos exigem abordagens diferentes: tratar uma tabela de strings como um documento faz com que as chaves se percam, e tratar um documento como uma tabela de strings fragmenta a prosa.

Devo usar a exportação em CSV ou a API da plataforma para as traduções?

O CSV é a escolha prática quando a tradução é feita por um humano ou um fornecedor externo, e é esse o método documentado pelo Braze e pelo Klaviyo. Um fluxo via API é melhor quando o processo se repete periodicamente ou o volume é alto o suficiente para que o manuseio manual de arquivos se torne um gargalo. O Braze oferece uma API de traduções (em acesso antecipado no momento da redação deste texto) e o Iterable expõe o conteúdo dos templates por meio de GET /api/templates/email/get. O Brevo não oferece suporte a nenhum dos dois: ele não possui tradução baseada em arquivos, portanto as campanhas devem ser traduzidas na interface.

Quantos idiomas uma única campanha de e-mail pode suportar?

Depende da plataforma. O Braze permite até 200 localidades por workspace e 200 tags de tradução por mensagem. O Klaviyo abrange mais de 60 idiomas por meio do Smart Translations. O Customer.io aceita centenas de códigos de idioma e de idioma-região. Na prática, a restrição raramente é o limite da plataforma; o desafio é a quantidade de idiomas que você consegue manter revisados e atualizados à medida que o texto original muda.