Sendgrid-nodejs: Cómo utilizar versiones de plantillas para compatibilidad con varios idiomas

Hola @ ifndefdeadmau5 ,

Aquí está la documentación de la API sobre esta función. A continuación, se explica cómo utilizar este SDK para realizar esa llamada a la API.

¡Espero que eso ayude!

Con los mejores deseos,

Elmer

Gracias por responderme @thinkingserious ,

Todavía no puedo entender cómo se puede usar realmente 'activar versión de plantilla específica'.
Estaba pensando en el escenario en el que tengo 2 versiones de la plantilla que están escritas en más de 2 idiomas, tal vez inglés y español, o lo que sea.

Luego, hago una llamada a la API de envío de mensajes con versiones de plantilla específicas que coinciden con el idioma del usuario

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);
}

Pero el ejemplo anterior requiere 2 plantillas separadas, no una plantilla de versión diferente. Lo que puede llevar a generar plantillas separadas pero el contenido está relacionado.
¿Que me estoy perdiendo aqui? por favor iluminame.
Gracias de nuevo y esperamos tener noticias tuyas.

Hola @ ifndefdeadmau5 ,

Puede tener varias versiones por plantilla. Luego, puede usar el SDK para activar una versión en particular.

Primero, crearía varias versiones de su plantilla. Luego activaría la versión deseada antes de realizar la llamada anterior.

Con los mejores deseos,

Elmer

Buenos días @thinkingserious ,

Gracias por su rápida respuesta y no había imaginado una solución así.
Ahora entiendo cómo hacerlo, pero una pregunta es ¿por qué no activar todas las versiones de la plantilla la primera vez y luego dejar que el usuario pueda usarla sin molestarse en Activar / Desactivar cosas?

Mi preocupación es, ¿qué pasa si más de dos usuarios que usan diferentes idiomas realizan algunas acciones al mismo tiempo (exactamente lo mismo), por lo que nuestro servidor necesita abordar 2 solicitudes al mismo tiempo? Entonces, ¿qué versión de plantilla se activaría?

a continuación es parte de nuestro código de servidor, para informarle mi situación

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);
}

Hola @ ifndefdeadmau5 ,

Esa es una preocupación válida.

Parece que lo que realmente necesita es nuestro nuevo sistema de plantillas (en beta) . Para unirse a la versión beta, envíe un correo electrónico a [email protected].

Con los mejores deseos,

Elmer

Hola @thinkingserious ,

Lo solicité por correo electrónico a

También estaba buscando plantillas transaccionales para ver cómo podríamos usar versiones de plantilla para diferentes correos electrónicos específicos de la configuración regional.
Estoy de acuerdo, parece extraño tener que activar una versión de plantilla en particular antes de usarla. Esta no es la mejor solución para nuestro software de alta transacción. Espero poder especificar qué versión usar en la solicitud POST /mail/send .

Hola @ andyblack19
No es necesario crear versiones con las nuevas plantillas que hemos introducido. En su cuenta, debería ver una opción para plantillas "transaccionales". Allí puede crear una plantilla que servirá para muchos idiomas. Es probable que desee echar un vistazo a los documentos aquí y un ejemplo aquí .

Leí esa página ... ¡pero me perdí por completo la sección de idiomas múltiples! Gracias por tu ayuda

Parece que el uso de plantillas de modo "Editor de diseño" no es posible con la estrategia de manillar mencionada anteriormente. Si uno quiere tener varias plantillas para diferentes casos de uso con al menos dos idiomas diferentes, ¿se supone que debe copiar y pegar el código de la plantilla en cada plantilla cuando se cambia el diseño general? ¿Por qué no hay forma de tener diseños compartibles de nivel superior?

Además, parece que tiene que localizar el asunto del correo electrónico en el lado del servidor, en lugar de en el contenido de la plantilla, donde ya está configurando el cuerpo de la plantilla para cada idioma. No tiene sentido separar sujeto y cuerpo de esta manera. ¿O he pasado por alto algo?

Hola @raine

Parece que el uso de plantillas de modo "Editor de diseño" no es posible con la estrategia de manillar mencionada anteriormente.

Tiene razón, el diseño específico de la plantilla de idioma que se encuentra aquí no fue diseñado para funcionar en el modo "Editor de diseño". Aún puede crear algo similar en el "Editor de diseño" usando un módulo de código.

Si uno quiere tener varias plantillas para diferentes casos de uso con al menos dos idiomas diferentes, ¿se supone que debe copiar y pegar el código de la plantilla en cada plantilla cuando se cambia el diseño general? ¿Por qué no hay forma de tener diseños compartibles de nivel superior?

En realidad, esto es algo que se ha planteado a nuestros ingenieros. Aún así, le recomendaría que use el botón de comentarios cuando haya iniciado sesión en su cuenta para que nuestros ingenieros sepan que es necesario. Cuantas más personas envíen comentarios como ese, más probable es que veamos una mejora como esa. El botón de comentarios es una de las mejores formas de enviar comentarios directamente a nuestros ingenieros cuando se trata de cualquier cosa fuera de las bibliotecas de código. Yo personalmente he votado por algo similar a lo que está buscando.

Además, parece que tiene que localizar el asunto del correo electrónico en el lado del servidor, en lugar de en el contenido de la plantilla, donde ya está configurando el cuerpo de la plantilla para cada idioma. No tiene sentido separar sujeto y cuerpo de esta manera. ¿O he pasado por alto algo?

Creo que ha pasado por alto algo. Sé por mis propias pruebas personales que los manillares funcionan para establecer el tema de una plantilla. Aunque puede que no esté entendiendo tu redacción correctamente. Sin embargo, sé que el tema no ha sido diseñado visualmente para admitir esto, por lo que es mejor crear el código y el contenido en algo como un editor de texto y luego pegarlo en el campo del tema. Esta es otra área donde se recomienda usar el botón de comentarios. No dude en sugerir lo que crea que sería una mejor forma de hacerlo.

Por favor, corrija todo lo que haya cometido y bríndeme más detalles para que pueda comprenderlo mejor.

Kyle

¿Cómo aborda el ejemplo de varios idiomas la traducción de la línea de asunto del correo electrónico?

@esiqveland

En la línea de asunto de la plantilla, usaría algo como esto:

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

Básicamente, usa la misma estructura que está en el contenido HTML. Háganos saber si tiene más preguntas.

Hola @kylearoberts , ¿hay alguna manera de verificar el valor de la variable en el condicional? Entonces, en lugar de verificar múltiples variables como english o spanish , simplemente verificaría si language variable es igual a en o es . Esto no hace mucha diferencia en la plantilla en sí, pero sí en el backend donde tengo que traducir la variable de código de idioma a una variable con un nombre especial en los datos de la plantilla dinámica.

Revisé Manillar brevemente y no parece admitirlo de forma predeterminada. Pero quizás SendGrid tenga incorporados algunos ayudantes personalizados.

@tlinhart

Gracias por la gran pregunta. Tal como está ahora, el sistema no funcionará de esa manera, pero es probable que más adelante tengamos algo que permita algo así. Cuando hagamos un cambio de este tipo, probablemente actualizaremos nuestros documentos y ejemplos sobre cómo usar las plantillas transaccionales.

Hola,
Actualmente estoy usando el nuevo sistema de plantillas para mis correos electrónicos en varios idiomas. El principal problema es la extensión limitada del campo temático. Básicamente, el contenido de mi tema es así:

{{#if english}}
Hola bla bla ...
{{else if spanish}}
Hola bla bla ...
{{else if french}}
Hola bla bla ...
{{/Si}}

Pero hay algunos problemas:

1. La extensión del campo de asunto no es suficiente para más de unos pocos idiomas. Tuve que reducir el texto y los nombres de las variables solo para mantenerme dentro de los límites. Pero obviamente esto no funcionará si tuviéramos que agregar un nuevo idioma.
2. El editor muestra un campo de una sola línea para ingresar el tema que no es adecuado para trabajar con temas de plantilla.
3. El campo de asunto del editor corta felizmente el texto ingresado después de pegarlo. Esto dará lugar a un error de plantilla ya que la sintaxis será incorrecta debido al código de secuencia de comandos de la plantilla eliminado

@bragma

Me he encontrado con el mismo problema que tú. Esta tampoco es la primera vez que escuchamos esto. Nos encanta recibir comentarios como este porque nos ayudan a mejorar nuestros productos. Me he asegurado de enviar sus comentarios a nuestro equipo de ingeniería y puedo decirles que esta es una de las áreas en las que quieren mejorar las cosas. Cuando tengan la oportunidad de trabajar en mejoras, es probable que este sea uno de ellos. Gracias nuevamente por los comentarios.

@thinkingserious +1 Necesito la función de localización

@thinkingserious enorme +1 para esta función.
Una característica realmente agradable para poder tratar con todo el idioma de un correo electrónico dentro de la misma plantilla, pero como se dijo anteriormente, no se puede usar debido a la limitación del tema.

@thinkingserious mega +1 para esta función: también necesitamos esta función, para nosotros, el caso de uso es un poco diferente, queremos descargar la creación / mantenimiento de plantillas a nuestros chicos de marketing, solo que estas personas no son programadores, por lo que necesitamos plantillas WYSIWYG sencillas por idioma. Tener 1 versión separada por idioma sería la respuesta a nuestro problema.

Lo siguiente sería aún mejor:

1: la capacidad de establecer una versión predeterminada (cuando no se selecciona ninguna versión, o se proporciona una versión no válida, la versión predeterminada tomaría el control)
2 - solo tenga un parámetro adicional en la POST /mail/send API para agregar una versión

Tenemos una plataforma con más de 12 idiomas y contando (sí, nos gustan los desafíos), por lo que necesitamos personas de marketing específicas para diferentes idiomas, que no codifican plantillas tan simples. Además, planeamos tener una gran cantidad de usuarios, por lo que primero configurar la plantilla requerida como activa, luego enviar un correo electrónico resultaría en problemas de concurrencia donde se elegirán plantillas incorrectas.

Muchas gracias,

¡Hola a todos los que contribuyeron a este problema!

Estamos investigando un poco con los clientes para tratar de comprender cuál es la mejor manera de resolver el problema de localizar / traducir los correos electrónicos enviados mediante SendGrid. Si tiene algo de tiempo, nos encantaría recibir sus comentarios mientras pensamos en cómo construir esto correctamente.

Aquí hay un enlace para registrarse en un espacio para hablar conmigo y con mi equipo sobre cómo manejan la traducción y la localización hoy: https://calendly.com/travisterwilligar/sendgrid-research?month=2019-09

¡Muchas gracias por tu tiempo!

@ ben-grid acaba de comprobar el calendario, pero los tiempos no funcionan para mí, así que daré un breve resumen de lo que sería increíble.

Contamos con un sistema de comercio electrónico con sandbox y cuenta de producción. Y cuando aprobamos una plantilla, la exportamos e importamos a producción (esto también es algo que sería una gran característica, tener sandbox y plantillas de producción con una canalización de promoción)

De todos modos ... actualmente tenemos 2 idiomas, pero la tarea que tenemos entre manos es pasar a 5 idiomas. Actualmente contamos con 11 plantillas. Lo que hacemos ahora es el {{if lang.en}} Hola {{else}} Hola {{/ if}} solo que esto no funcionará para 5 idiomas (20 idiomas en el futuro cercano) así que ahora vamos a crear plantillas separadas por idioma, creando 55 plantillas en lugar de 11. (horrible)

¡Qué sería genial!

Opción 1:
Agregue un parámetro de "versión" a la API y simplemente envíe la versión proporcionada a. Ahora podemos enviar al menos una versión específica en un idioma escrito (las versiones podrían ser una versión traducida de la plantilla, la alternativa sería la activa)

opcion 2
Agregue parámetros localizados a una plantilla. De esta forma podemos usar la plantilla para varios idiomas traduciendo solo los parámetros. El inconveniente de este enfoque es que algunas construcciones de oraciones no funcionan para cada idioma, por lo que probablemente le gustaría tener más flexibilidad.

* Opción 3 El Unicornio con lágrimas doradas *
Básicamente, tenga una pestaña de traducción para cada módulo que ingrese. Por lo tanto, cuando inserte un módulo como este
este módulo tendría varias configuraciones regionales. Básicamente, un clon del original para diferentes idiomas. Debe poder configurar el idioma de la plantilla (configurando todos los módulos en un idioma específico, incluido el tema y el preencabezado), tal vez colorear los módulos en rojo si aún no están completados para ese módulo

Solo mis 2 centavos, me encantaría sus comentarios sobre esto, si desea enviarme un correo electrónico, envíeme un mensaje a

@reneweteling Muchas gracias, eso es muy útil. Estamos trabajando en un prototipo que probablemente será más parecido a la opción 2 y 3 que a la 1. Lo contactaré por correo electrónico cuando tengamos algo sobre lo que valga la pena recibir comentarios. ¡Gracias de nuevo por tu aportación!

@reneweteling Creo que la opción 1 o 2 funcionaría, ya que es muy intuitiva. Opción 3: bueno, es bueno tener ...

@ ben-grid & @ a-tonchev ¡Gracias por todo el trabajo duro! Sin embargo, he cambiado de trabajo, así que para mí, esto ya no es relevante. ¡Sigan con el buen trabajo!

¿Alguna novedad sobre este? La limitación de la longitud del tema es un problema para mí, teniendo en cuenta que también necesito localizar la línea de asunto y creo que con el nuevo editor la longitud del tema es aún menor, puedo tener alrededor de 110 caracteres en la línea de asunto.

En mi opinión, parece que la solución más viable sería generar todo el lado del servidor de texto, luego simplemente colocarlo en la plantilla como párrafos fragmentados.

Si una empresa admite varios idiomas, entonces su sitio web ya tendrá una solución para esto, que debería estar del lado del servidor (cargando idiomas desde XML / base de datos). En mi opinión, cualquier correo electrónico relacionado con el mismo proyecto también debería tener su texto almacenado en estos archivos de idioma.

Los párrafos / texto necesarios se pueden extraer de esos archivos según el idioma del usuario y luego pasar como variables de plantilla a sendgrid. Sendgrid sería solo una plantilla general (como, pie de página, etc., solo estilos e imágenes) e incluso algunos estilos tendrían que mantenerse en el archivo de idioma, como específicamente qué palabras en negrita, etc.

Entonces, la plantilla terminaría como: subject HelloLine welcomeparagraph helpparagraph footerslogan . Y eso es.

En mi opinión, parece que la solución más viable sería generar todo el lado del servidor de texto, luego simplemente colocarlo en la plantilla como párrafos fragmentados.

Si una empresa admite varios idiomas, entonces su sitio web ya tendrá una solución para esto, que debería estar del lado del servidor (cargando idiomas desde XML / base de datos). En mi opinión, cualquier correo electrónico relacionado con el mismo proyecto también debería tener su texto almacenado en estos archivos de idioma.

Los párrafos / texto necesarios se pueden extraer de esos archivos según el idioma del usuario y luego pasar como variables de plantilla a sendgrid. Sendgrid sería solo una plantilla general (como, pie de página, etc., solo estilos e imágenes) e incluso algunos estilos tendrían que mantenerse en el archivo de idioma, como específicamente qué palabras en negrita, etc.

Entonces, la plantilla terminaría como: subject HelloLine welcomeparagraph helpparagraph footerslogan . Y eso es.

Esto no es manejable porque necesita volver a implementar el servicio de correo para cada cambio de redacción. Además, en algunas empresas, el contenido del correo no es responsabilidad de los desarrolladores, sino de los redactores y del marketing. Debería volver a implementar otra interfaz de usuario para permitir la edición, pero pagamos a Sendgrid incluso por eso.

En un proyecto, usamos un CMS sin cabeza para editar y crear plantillas de correo electrónico para cada idioma. El servidor lee estas plantillas de bigote en tiempo de ejecución y genera el cuerpo del correo electrónico para enviarlo a Sendgrid. La UX de edición de plantillas de Sendgrid es completamente inútil, así que decidimos ir con esto.

@cecchisandrone Estoy de acuerdo en que sendgrid podría ser mejor. Necesitan agregar una gestión adecuada del idioma y convertirla en un parámetro. Pero como dije, algunas variables que les enviamos deberán ser localizadas de todos modos, como los formatos de fecha / hora, por ejemplo.

Como dijo @ corneliu-gavrilovici
Incluso vale la pena ahora. En una actualización reciente, la duración del tema se acortó aún más. Solo estamos usando 2 idiomas por ahora y lo estábamos haciendo de la siguiente manera en el campo de asunto:

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

No entiendo por qué se actualizó esto, un producto que era utilizable para nosotros, ya no se puede usar debido a este asunto. Habla en su documentación sobre cómo tratar con la plantilla de varios idiomas, pero no se puede utilizar correctamente. @ ben-grid
https://sendgrid.com/docs/for-developers/sending-email/using-handlebars/#multiple -languages

En mi opinión, parece que la solución más viable sería generar todo el lado del servidor de texto, luego simplemente colocarlo en la plantilla como párrafos fragmentados.
...
Los párrafos / texto necesarios se pueden extraer de esos archivos según el idioma del usuario y luego pasar como variables de plantilla a sendgrid. Sendgrid sería solo una plantilla general (como, pie de página, etc., solo estilos e imágenes) e incluso algunos estilos tendrían que mantenerse en el archivo de idioma, como específicamente qué palabras en negrita, etc.

Entonces, la plantilla terminaría como: subject HelloLine welcomeparagraph helpparagraph footerslogan . Y eso es.
He hecho esto en SalesForce usando JS del lado del servidor. El objeto json está en la plantilla pero se ejecuta en el servidor durante la compilación. Es similar a tener una función de localización real y no depende de las publicaciones de desarrollo que tendría en un entorno de ecomm.
Estoy ansioso por ver lo que el equipo de SG ha propuesto como lo menciona @ ben-grid.

+1 característica de localización. Si tenemos varios idiomas, es un desastre con muchos if / else.