Sendgrid-nodejs: Como utilizar versões de modelo para suporte a vários idiomas

Olá @ ifndefdeadmau5 ,

Aqui está a documentação da API sobre este recurso. Aqui está como usar este SDK para fazer essa chamada de API.

Espero que ajude!

Obrigado pela atenção,

Elmer

Obrigado por me responder @thinkingserious ,

Ainda não consigo descobrir como 'ativar versão de modelo específica' pode realmente ser usado.
Eu estava pensando no cenário de que tenho 2 versões de template que são escritas em mais de 2 idiomas, talvez inglês e espanhol, ou qualquer outro.

Em seguida, faço uma chamada de API de envio de mensagem com versões de modelo específicas que correspondem ao idioma do usuário

export function sendSendGridEmail()
{
  sgMail.setApiKey(config.get('sendgrid.API_KEY'));
  sgMail.setSubstitutionWrappers('{{', '}}');
  const msg = {
    to: '[email protected]',
    from: '[email protected]',
    subject: 'Sending with SendGrid is Fun',
    text: 'and easy to do anywhere, even with Node.js',
    html: '<strong>and easy to do anywhere, even with Node.js</strong>',
    templateId: isUserLocaleEnglish ? ENGLISH_TEMPLATE_ID : SPANISH_TEMPLATE_ID, // This line!
    substitutions: {
      name: 'Some One',
      city: 'Denver',
    },
  };
  sgMail.send(msg);
}

Mas o exemplo acima requer 2 modelos separados, não um modelo de versão diferente. O que pode levar à geração de modelos separados, mas o conteúdo está relacionado.
O que estou perdendo aqui? Por favor me esclareça.
Obrigado novamente e espero ouvir de você!

Olá @ ifndefdeadmau5 ,

Você pode ter várias versões por modelo. Em seguida, você pode usar o SDK para ativar uma versão específica.

Primeiro, você criaria várias versões do seu modelo. Em seguida, você ativaria a versão desejada antes de fazer a chamada acima.

Obrigado pela atenção,

Elmer

Bom dia @thinkingserious ,

Obrigado por sua resposta rápida e não imagino uma solução alternativa.
Agora eu entendo como fazer isso, mas uma questão é por que não ativar todas as versões do modelo na primeira vez e depois apenas permitir que o usuário possa usá-lo sem se preocupar com Ativar / Desativar coisas?

Minha preocupação é, e se mais de dois usuários que usam idiomas diferentes fizerem algumas ações ao mesmo tempo (exatamente o mesmo), então nosso servidor precisa atender a 2 solicitações ao mesmo tempo. Então, qual versão do modelo seria ativada?

abaixo é parte do nosso código de servidor, apenas para informá-lo sobre minha situação

export async function sendSendGridEmail() {
  const locale = 'ko';
  const isEnglishUser = locale === 'en';
  const PASSWORD_RESET_TEMPLATE_ID = '2096abb7-a9f8-413f-96a1-b9df0644b313';

  const { versions } = await getTemplate(PASSWORD_RESET_TEMPLATE_ID);
  const KO_VER = _.find(versions, { name: 'Korean' }).id;
  const EN_VER = _.find(versions, { name: 'English' }).id;

  await activateVersion(PASSWORD_RESET_TEMPLATE_ID, isEnglishUser ? EN_VER : KO_VER);

  sgMail.setSubstitutionWrappers('{{', '}}');
  const msg = {
    to: '[email protected]',
    from: '[email protected]',
    templateId: PASSWORD_RESET_TEMPLATE_ID,
    substitutions: {
      username: 'Test Username',
    },
  };
  sgMail.send(msg);
}

Olá @ ifndefdeadmau5 ,

Essa é uma preocupação válida.

Parece que o que você realmente precisa é nosso novo sistema de modelos (em beta) . Para participar do beta, envie um e-mail para [email protected].

Obrigado pela atenção,

Elmer

Olá @thinkingserious ,

Solicitei por email para

Também estava examinando modelos transacionais para ver como poderíamos usar versões de modelo para diferentes e-mails específicos de localidade.
Eu concordo, parece estranho ter que ativar uma determinada versão do modelo antes de usá-lo. Esta não é a melhor solução para nosso software de alta transação. Eu esperaria ser capaz de especificar qual versão usar na solicitação POST /mail/send .

Ei @ andyblack19
Não há necessidade de controle de versão com os novos modelos que introduzimos. Em sua conta, você deve ver uma opção para modelos "Transacionais". Lá você pode criar um modelo que atenderá a vários idiomas. Você provavelmente desejará dar uma olhada nos documentos aqui e em um exemplo aqui .

Eu li essa página ... mas perdi completamente a seção de vários idiomas! Obrigado pela ajuda

Parece que o uso dos modelos do modo "Editor de Design" não é possível com a estratégia de guidão mencionada acima. Se alguém quiser ter vários modelos para diferentes casos de uso com pelo menos duas linguagens diferentes, você deve copiar e colar o código do modelo em cada modelo quando o layout geral for alterado? Por que não há uma maneira de ter layouts compartilháveis ​​de nível superior?

Além disso, parece que você precisa localizar o assunto do e-mail no lado do servidor, em vez de no conteúdo do modelo, onde já está definindo o corpo do modelo para cada idioma. Não faz sentido separar sujeito e corpo dessa forma. Ou esqueci alguma coisa?

Olá @raine

Parece que o uso dos modelos do modo "Editor de Design" não é possível com a estratégia de guidão mencionada acima.

Você está correto: o design específico do modelo de idioma encontrado aqui não foi projetado para funcionar no modo "Editor de Design". Você ainda pode criar algo semelhante no "Editor de Design" usando um Módulo de Código.

Se alguém quiser ter vários modelos para diferentes casos de uso com pelo menos duas linguagens diferentes, você deve copiar e colar o código do modelo em cada modelo quando o layout geral for alterado? Por que não há uma maneira de ter layouts compartilháveis ​​de nível superior?

Na verdade, isso é algo que foi levado aos nossos engenheiros. Ainda assim, recomendo que você use o botão de feedback quando estiver conectado à sua conta para que nossos engenheiros saibam que isso é necessário. Quanto mais pessoas enviarem feedback como esse, mais provável será que vejamos uma melhoria como essa. O botão de feedback é uma das melhores maneiras de obter feedback diretamente para nossos engenheiros quando se trata de algo fora das bibliotecas de código. Pessoalmente, votei em algo semelhante ao que você está procurando.

Além disso, parece que você precisa localizar o assunto do e-mail no lado do servidor, em vez de no conteúdo do modelo, onde já está definindo o corpo do modelo para cada idioma. Não faz sentido separar sujeito e corpo dessa forma. Ou esqueci alguma coisa?

Eu acho que você esqueceu algo. Sei, por meio de meus próprios testes pessoais, que o guiador funciona para definir o assunto de um modelo. Embora eu possa não estar entendendo suas palavras corretamente. Eu sei que o assunto não foi projetado visualmente para suportar isso, então é melhor criar o código e o conteúdo em algo como um editor de texto e colá-lo no campo de assunto depois. Esta é outra área em que o uso do botão de feedback é recomendado. Fique à vontade para sugerir o que você acha que seria a melhor maneira de fazer isso.

Por favor, corrija tudo o que eu errar e me dê mais detalhes para que eu possa entender melhor.

Kyle

Como o exemplo de tradução de endereços de vários idiomas da linha de assunto do e-mail?

@esiqveland

Na linha de assunto do modelo, você usaria algo assim:

{{#if english}}
Hello
{{else if spanish}}
Hola
{{else if french}}
Bonjour
{{/if}}

Basicamente, você usa a mesma estrutura do conteúdo HTML. Informe-nos se tiver mais perguntas.

Oi @kylearoberts , há uma maneira de verificar o valor da variável no condicional? Então, em vez de verificar várias variáveis ​​como english ou spanish , eu apenas verificaria se a variável language é igual a en ou es . Isso não faz muita diferença no modelo em si, mas faz no backend, onde tenho que traduzir a variável do código do idioma em uma variável com nome especial nos dados do modelo dinâmico.

Eu verifiquei o Guiador brevemente e ele não parece suportá-lo por padrão. Mas talvez o SendGrid tenha alguns helpers personalizados integrados.

@tlinhart

Obrigado pela ótima pergunta. Do jeito que está agora, o sistema não funcionará dessa maneira, mas provavelmente teremos algo mais tarde que permitirá algo parecido. Quando fizermos essa mudança, provavelmente atualizaremos nossos documentos e exemplos de como usar modelos transacionais.

Oi,
Atualmente estou usando o novo sistema de template para meus e-mails multilíngues. O principal problema é o tamanho limitado do campo de assunto. Basicamente, o conteúdo do meu assunto é assim:

{{#if inglês}}
Olá blá blá ...
{{senão se espanhol}}
Olá blá blá ...
{{senão se francês}}
Olá blá blá ...
{{/E se}}

Mas existem alguns problemas:

1. O comprimento do campo de assunto não é suficiente para mais do que alguns idiomas. Tive que cortar o texto e os nomes das variáveis ​​apenas para ficar dentro dos limites. Mas isso obviamente não funcionará se tivermos que adicionar um novo idioma.
2. O editor mostra um campo de linha única para inserir o assunto, o que é inadequado para trabalhar com assuntos de modelo.
3. O campo de assunto do editor reduz alegremente o texto inserido e não a colagem. Isso levará a um erro de modelo, pois a sintaxe estará errada devido ao código de script de modelo removido

@bragma

Eu tive o mesmo problema que você. Também não é a primeira vez que ouvimos isso. Adoramos receber feedback como este porque nos ajuda a melhorar nossos produtos. Fiz questão de enviar seus comentários para nossa equipe de engenharia e posso dizer que esta é uma das áreas em que eles desejam melhorar as coisas. Quando eles têm a chance de trabalhar em melhorias, é provável que seja um deles. Obrigado novamente pelo feedback.

@thinkingserious +1 preciso do recurso de localização

@thinkingserious grande +1 para este recurso.
Recurso muito bom para poder lidar com todo o idioma de um e-mail dentro do mesmo modelo, mas como afirmado anteriormente, não é utilizável devido à limitação do assunto.

@thinkingseriouserious mega +1 para este recurso - Também precisamos deste recurso, para nós, o caso de uso é um pouco diferente, queremos descarregar a criação / manutenção de modelos para o nosso pessoal de marketing, só que essas pessoas não são programadores, portanto, precisamos de modelos WYSIWYG simples por idioma. Ter 1 versão separada por idioma seria a resposta para nosso problema.

O seguinte seria ainda melhor:

1 - a capacidade de definir uma versão padrão (quando nenhuma versão é selecionada ou uma versão inválida é fornecida, a versão padrão assumirá)
2 - basta ter um parâmetro extra na API POST /mail/send para adicionar uma versão

Temos uma plataforma com mais de 12 idiomas e contando (sim, gostamos de desafios), então precisamos de pessoal de marketing específico para diferentes idiomas, eles não codificam modelos tão simples. Além disso, planejamos ter uma quantidade enorme de usuários, portanto, primeiro definir o modelo necessário como ativo e, em seguida, enviar um e-mail resultaria em problemas de simultaneidade em que modelos errados serão escolhidos.

Muito obrigado,

Olá a todos que contribuíram para este problema!

Estamos fazendo algumas pesquisas com os clientes para tentar entender como podemos resolver da melhor forma o problema de localização / tradução de e-mails enviados usando o SendGrid. Se você tiver algum tempo disponível, adoraríamos receber seus comentários enquanto pensamos em como construir isso da maneira certa!

Aqui está um link para se inscrever em um espaço para falar comigo e com minha equipe sobre como você lida com a tradução e localização hoje: https://calendly.com/travisterwilligar/sendgrid-research?month=2019-09

Muito obrigado pelo seu tempo!

@ben-grid acabou de verificar o calendário, mas os tempos não funcionam para mim, então eu darei um breve resumo do que seria incrível.

Temos um sistema de e-commerce com sandbox e conta de produção. E quando aprovamos um tempalte, nós o exportamos e importamos para produção (isso também é algo que seria um ótimo recurso, tendo sandbox e modelos de produção com um pipeline de promoção)

De qualquer forma ... atualmente temos 2 idiomas, mas a tarefa em mãos é passar para 5 idiomas. Atualmente temos 11 modelos. O que fazemos agora é o {{if lang.en}} Hi {{else}} Hallo {{/ if}}, mas isso não funcionará para 5 idiomas (20 idiomas em um futuro próximo), portanto, agora vamos criar modelos separados por idioma, criando 55 modelos em vez de 11. (horrível)

O que seria ótimo!

Opção 1:
Adicione um parâmetro de "versão" à API e apenas envie a versão fornecida para. Agora podemos enviar pelo menos uma versão específica em um idioma escrito (as versões podem ser uma versão traduzida do modelo, o substituto seria o ativo)

opção 2
Adicione parâmetros localizados a um modelo. Desta forma, podemos usar o modelo para vários idiomas, apenas traduzindo os parâmetros. A desvantagem dessa abordagem é que algumas construções de frases não funcionam para cada idioma, então provavelmente você gostaria de ter mais flexibilidade

* Opção 3 O Unicórnio com lágrimas douradas *
Basicamente, tem uma guia de tradução para cada módulo que você insere. Então, quando você insere um módulo como este
este módulo teria vários locais. Basicamente, um clone do original para idiomas diferentes. Você precisa ser capaz de definir o idioma do modelo (definindo todos os módulos para idiomas específicos, incluindo assunto e pré-cabeçalho), talvez colorir os módulos de vermelho se eles ainda não estiverem preenchidos para aquele módulo

Apenas meus 2 centavos, eu adoraria seu feedback sobre isso, se você gostaria de enviar um e-mail, me ligue em

@reneweteling Muito obrigado, isso é muito útil. Estamos trabalhando em um protótipo que provavelmente será mais parecido com as opções 2 e 3 do que 1. Entrarei em contato por e-mail quando tivermos algo que valha a pena receber feedback. Obrigado novamente por sua contribuição!

@reneweteling Eu acho que a opção 1 ou 2 faria o trabalho - uma vez que é muito intuitiva. Opção 3 - bem, é simplesmente bom ter ...

@ ben-grid & @ a-tonchev Obrigado por todo o trabalho árduo! Eu troquei de emprego, então, para mim, isso não é mais relevante. Mantenha o bom trabalho!

Algumas notícias sobre este? A limitação do comprimento do assunto é um problema para mim, levando em consideração que preciso localizar a linha do assunto também e acho que com o novo editor o comprimento do assunto é ainda menor, posso ter cerca de 110 caracteres na linha do assunto.

IMO, parece que a solução mais viável seria gerar todo o lado do servidor de texto e, em seguida, colocá-lo no modelo como parágrafos fragmentados.

Se uma empresa oferece suporte a vários idiomas, seu site já terá uma solução para isso que deve ser do lado do servidor (linguagem de carregamento de XML / banco de dados). Na minha opinião, quaisquer emails relacionados ao mesmo projeto também devem ter seu texto armazenado nesses arquivos de idioma.

Os parágrafos / textos necessários podem ser extraídos desses arquivos, dependendo do idioma do usuário, e então passados ​​como variáveis ​​de modelo para o sendgrid. Sendgrid seria apenas um modelo abrangente (como rodapé etc - apenas estilos e imagens) e até mesmo alguns estilos teriam que ser mantidos no próprio arquivo de idioma - como especificamente quais palavras colocar em negrito etc.

Assim, o modelo terminaria assim: subject HelloLine welcomeparagraph helpparagraph footerslogan . E é isso.

IMO, parece que a solução mais viável seria gerar todo o lado do servidor de texto e, em seguida, colocá-lo no modelo como parágrafos fragmentados.

Se uma empresa oferece suporte a vários idiomas, seu site já terá uma solução para isso que deve ser do lado do servidor (linguagem de carregamento de XML / banco de dados). Na minha opinião, quaisquer emails relacionados ao mesmo projeto também devem ter seu texto armazenado nesses arquivos de idioma.

Os parágrafos / textos necessários podem ser extraídos desses arquivos, dependendo do idioma do usuário, e então passados ​​como variáveis ​​de modelo para o sendgrid. Sendgrid seria apenas um modelo abrangente (como rodapé etc - apenas estilos e imagens) e até mesmo alguns estilos teriam que ser mantidos no próprio arquivo de idioma - como especificamente quais palavras colocar em negrito etc.

Assim, o modelo terminaria assim: subject HelloLine welcomeparagraph helpparagraph footerslogan . E é isso.

Isso não é gerenciável porque você precisa reimplantar o serviço de correio para cada alteração de direitos autorais. Também em algumas empresas, o conteúdo do correio não é responsabilidade dos desenvolvedores, mas do marketing / redatores. Você precisaria reimplantar outra IU para permitir a edição, mas pagamos Sendgrid até mesmo para isso.

Em um projeto, usamos um CMS headless para editar e criar modelos de e-mail para cada idioma. O servidor lê esses modelos de bigode em tempo de execução e gera o corpo do e-mail a ser enviado ao Sendgrid. UX de edição de template do Sendgrid é completamente inútil, então decidimos ir com isso.

@cecchisandrone Concordo que sendgrid poderia ser melhor. Eles precisam adicionar um gerenciamento de linguagem adequado e apenas torná-lo um parâmetro. Mas como eu disse, algumas variáveis ​​que enviamos para eles precisarão ser localizadas de qualquer maneira, como formatos de data / hora, por exemplo.

Conforme afirmado por @ corneliu-gavrilovici
Até vale a pena agora. Em uma atualização recente, o comprimento do assunto ficou ainda mais curto. No momento, estamos usando apenas 2 idiomas e estávamos fazendo da maneira abaixo na área de assunto:

{{#if english}}
Hello blah blah...
{{else if french}}
Hello blah blah...
{{/if}}

Não entendo porque isso foi atualizado, um produto que era utilizável para nós, não pode mais ser usado devido a este assunto. Você fala em sua documentação sobre como lidar com o modelo de vários idiomas, mas ele não pode ser usado corretamente. @ ben-grid
https://sendgrid.com/docs/for-developers/sending-email/using-handlebars/#multiple -languages

IMO, parece que a solução mais viável seria gerar todo o lado do servidor de texto e, em seguida, colocá-lo no modelo como parágrafos fragmentados.
...
Os parágrafos / textos necessários podem ser extraídos desses arquivos, dependendo do idioma do usuário, e então passados ​​como variáveis ​​de modelo para o sendgrid. Sendgrid seria apenas um modelo abrangente (como rodapé etc - apenas estilos e imagens) e até mesmo alguns estilos teriam que ser mantidos no próprio arquivo de idioma - como especificamente quais palavras colocar em negrito etc.

Assim, o modelo terminaria assim: subject HelloLine welcomeparagraph helpparagraph footerslogan . E é isso.
Eu fiz isso no SalesForce usando JS do lado do servidor. O objeto json está no modelo, mas é executado no servidor durante a compilação. É semelhante a ter um recurso de localização real e não depende de publicações de desenvolvimento que você teria em um ambiente ecomm.
Estou ansioso para ver o que a equipe SG apresentou como menções @ben-grid.

+1 recurso de localização. Se tivermos vários idiomas, é uma confusão com muitos if / else.