Sendgrid-nodejs: Comment utiliser les versions de modèle pour la prise en charge de plusieurs langues

Bonjour @ ifndefdeadmau5 ,

Voici la documentation de l'API sur cette fonctionnalité. Voici comment utiliser ce SDK pour effectuer cet appel d'API.

J'espère que cela aide!

Meilleures salutations,

Elmer

Merci de m'avoir répondu @thinkingserious ,

Je n'arrive toujours pas à comprendre comment «activer une version de modèle spécifique» peut être utilisé.
Je pensais au scénario selon lequel j'ai 2 versions de modèle qui sont écrites dans plus de 2 langues, peut-être l'anglais et l'espagnol, ou autre.

Ensuite, je passe un message à envoyer un appel API avec des versions de modèle spécifiques qui correspondent à la langue de l'utilisateur

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

Mais l'exemple ci-dessus nécessite 2 modèles séparés, pas le seul modèle de version différente. Ce qui peut conduire à générer des modèles séparés mais le contenu est lié.
Qu'est-ce que j'oublie ici? Veuillez m'éclairer.
Merci encore et au plaisir de vous entendre!

Bonjour @ ifndefdeadmau5 ,

Vous pouvez avoir plusieurs versions par modèle. Ensuite, vous pouvez utiliser le SDK pour activer une version particulière.

Tout d'abord, vous créez plusieurs versions de votre modèle. Ensuite, vous activeriez la version souhaitée avant d'effectuer l'appel ci-dessus.

Meilleures salutations,

Elmer

Bonjour @thinkingserious ,

Merci pour votre réponse rapide et je n'ai pas imaginé un tel travail.
Maintenant, je comprends comment le faire, mais une question est: pourquoi ne pas activer toutes les versions de modèle à la première fois, puis laisser simplement l'utilisateur peut l'utiliser sans se soucier d'activer / désactiver les choses?

Ma préoccupation est la suivante: que se passe-t-il si plus de deux utilisateurs utilisant des langues différentes effectuent des actions en même temps (exactement la même chose), de sorte que notre serveur doit répondre à 2 demandes en même temps. Alors quelle version de modèle serait activée?

ci-dessous fait partie de notre code serveur, pour simplement vous informer de ma situation

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

Bonjour @ ifndefdeadmau5 ,

C'est une préoccupation valable.

Il semble que vous ayez vraiment besoin de notre nouveau système de modèles (en version bêta) . Pour rejoindre la version bêta, veuillez envoyer un e-mail à

Meilleures salutations,

Elmer

Bonjour @thinkingserious ,

J'ai demandé par e-mail à [email protected]. Merci!

J'examinais également des modèles transactionnels pour voir comment nous pourrions utiliser des versions de modèles pour différents e-mails spécifiques aux paramètres régionaux.
Je suis d'accord, il semble étrange d'avoir à activer une version de modèle particulière avant de l'utiliser. Ce n'est pas la meilleure solution pour notre logiciel de transactions élevées. Je m'attendrais à être en mesure de spécifier la version à utiliser dans la requête POST /mail/send .

Salut @ andyblack19
Pas besoin de versionnage avec les nouveaux modèles que nous avons introduits. Dans votre compte, vous devriez voir une option pour les modèles "Transactionnels". Là, vous pouvez créer un modèle qui servira de nombreuses langues. Vous voudrez probablement jeter un oeil à la documentation ici et un exemple ici .

J'ai lu cette page ... mais j'ai complètement manqué la section multilingue! Merci pour ton aide

Il semble que l'utilisation de modèles en mode "Editeur de conception" n'est pas possible avec la stratégie de guidon mentionnée ci-dessus. Si l'on souhaite avoir plusieurs modèles pour différents cas d'utilisation avec au moins deux langues différentes, êtes-vous censé copier-coller le code du modèle dans chaque modèle lorsque la mise en page générale est modifiée? Pourquoi n'y a-t-il pas un moyen d'avoir des mises en page partageables de haut niveau?

En outre, il semblerait que vous deviez localiser le sujet de l'e-mail côté serveur, plutôt que dans le contenu du modèle où vous définissez déjà le corps du modèle pour chaque langue? Cela n'a pas de sens de séparer le sujet et le corps de cette manière. Ou ai-je oublié quelque chose?

Bonjour @raine

Il semble que l'utilisation de modèles en mode "Editeur de conception" n'est pas possible avec la stratégie de guidon mentionnée ci-dessus.

Vous avez raison, la conception spécifique du modèle de langage trouvé ici n'a pas été conçue pour fonctionner en mode "Editeur de conception". Vous pouvez toujours créer quelque chose de similaire dans «l'éditeur de conception» à l'aide d'un module de code.

Si l'on souhaite avoir plusieurs modèles pour différents cas d'utilisation avec au moins deux langues différentes, êtes-vous censé copier-coller le code du modèle dans chaque modèle lorsque la mise en page générale est modifiée? Pourquoi n'y a-t-il pas un moyen d'avoir des mises en page partageables de haut niveau?

C'est en fait quelque chose qui a été présenté à nos ingénieurs. Je vous recommande toujours d'utiliser le bouton de commentaires lorsque vous êtes connecté à votre compte pour informer nos ingénieurs que cela est souhaité. Plus il y a de gens qui soumettent des commentaires comme celui-là, plus il est probable que nous verrons une telle amélioration. Le bouton de rétroaction est l'un des meilleurs moyens d'obtenir des commentaires directement à nos ingénieurs lorsqu'il s'agit de tout ce qui se trouve en dehors des bibliothèques de code. J'ai personnellement voté pour quelque chose de similaire à ce que vous recherchez.

En outre, il semblerait que vous deviez localiser le sujet du courrier électronique côté serveur, plutôt que dans le contenu du modèle où vous définissez déjà le corps du modèle pour chaque langue? Cela n'a pas de sens de séparer le sujet et le corps de cette manière. Ou ai-je oublié quelque chose?

Je pense que vous avez oublié quelque chose. Je sais par mes propres tests que les guidons fonctionnent pour définir le sujet d'un modèle. Même si je ne comprends pas correctement votre libellé. Je sais que le sujet n'a pas été visuellement conçu pour prendre en charge cela, il est donc préférable de créer le code et le contenu dans quelque chose comme un éditeur de texte et de le coller dans le champ sujet après. C'est un autre domaine dans lequel l'utilisation du bouton de rétroaction est recommandée. N'hésitez pas à suggérer ce que vous pensez être une meilleure façon de procéder.

Veuillez corriger tout ce sur quoi j'ai gaffé et me donner plus de détails afin que je puisse mieux comprendre.

Kyle

Comment l'exemple de plusieurs langues aborde-t-il la traduction de la ligne d'objet de l'e-mail?

@esiqveland

Dans la ligne d'objet du modèle, vous utiliseriez quelque chose comme ceci:

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

Vous utilisez essentiellement la même structure que celle du contenu HTML. S'il vous plaît laissez-nous savoir si vous avez d'autres questions.

Salut @kylearoberts , y a-t-il un moyen de vérifier la valeur de la variable au conditionnel? Donc, au lieu de vérifier plusieurs variables comme english ou spanish , je vérifierais simplement si la variable language est égale à en ou es . Cela ne fait pas beaucoup de différence dans le modèle lui-même, mais c'est le cas sur le backend où je dois traduire la variable de code de langue en variable spécialement nommée dans les données de modèle dynamique.

J'ai vérifié brièvement Handlebars et il ne semble pas le prendre en charge par défaut. Mais peut-être que SendGrid a des assistants personnalisés intégrés.

@tlinhart

Merci pour la bonne question. Dans l'état actuel des choses, le système ne fonctionnera pas de cette façon, mais nous aurons probablement quelque chose plus tard qui permettra quelque chose comme ça. Lorsque nous apporterons une telle modification, nous mettrons probablement à jour nos documents et exemples sur la façon d'utiliser les modèles transactionnels.

Salut,
J'utilise actuellement le nouveau système de modèles pour mes e-mails multilingues. Le problème principal est la longueur limitée du champ sujet. Fondamentalement, le contenu de mon sujet est comme ceci:

{{#if english}}
Bonjour bla bla ...
{{else if espagnol}}
Bonjour bla bla ...
{{else if french}}
Bonjour bla bla ...
{{/si}}

Mais il y a quelques problèmes:

1. La longueur du champ sujet n'est pas suffisante pour plus de quelques langues. J'ai dû réduire le texte et les noms de variables juste pour rester dans les limites. Mais cela ne fonctionnera évidemment pas si nous devons ajouter une nouvelle langue.
2. L'éditeur affiche un champ à une seule ligne pour saisir le sujet qui ne convient pas pour travailler avec des sujets de modèle.
3. Le champ d'objet de l'éditeur supprime le texte saisi lors du collage. Cela entraînera une erreur de modèle car la syntaxe sera incorrecte en raison du code de script de modèle supprimé

@bragma

J'ai rencontré le même problème que vous. Ce n'est pas non plus la première fois que nous entendons cela. Nous aimons recevoir des commentaires comme celui-ci car cela nous aide à améliorer nos produits. Je me suis assuré de transmettre vos commentaires à notre équipe d'ingénierie et je peux vous dire que c'est l'un des domaines dans lesquels ils souhaitent améliorer les choses. Lorsqu'ils auront la chance de travailler sur des améliorations, ce sera probablement l'une d'entre elles. Merci encore pour les commentaires.

@thinkingserious +1 J'ai besoin d'une fonction de localisation

@thinkingserious énorme +1 pour cette fonctionnalité.
Fonctionnalité vraiment intéressante pour pouvoir gérer toute la langue d'un e-mail dans le même modèle mais comme indiqué précédemment, elle n'est pas utilisable en raison de la limitation du sujet.

@thinkingserious mega +1 pour cette fonctionnalité - Nous avons également besoin de cette fonctionnalité, pour nous, le cas d'utilisation est un peu différent, nous voulons décharger la création / maintenance de modèles à nos responsables marketing, seuls ces personnes ne sont pas des programmeurs, nous avons donc besoin de modèles WYSIWYG simples par langue. Avoir 1 version séparée par langue serait la réponse à notre problème.

Ce qui suit serait encore mieux:

1 - la possibilité de définir une version par défaut (lorsqu'aucune version n'est sélectionnée ou qu'une version invalide est fournie, la version par défaut prendrait le relais)
2 - il suffit d'avoir un paramètre supplémentaire dans l'API POST /mail/send pour ajouter une version

Nous avons une plate-forme avec plus de 12 langues et comptage (oui, nous aimons les défis), nous avons donc besoin de spécialistes du marketing pour différentes langues, ils ne codent pas de modèles aussi simples. De plus, nous prévoyons d'avoir un grand nombre d'utilisateurs, donc d'abord définir le modèle requis sur actif, puis envoyer un e-mail entraînerait des problèmes de concurrence où de mauvais modèles seront choisis.

Merci beaucoup,

Salut à tous ceux qui ont contribué à ce numéro!

Nous faisons des recherches avec les clients pour essayer de comprendre comment nous pouvons au mieux résoudre le problème de la localisation / traduction des e-mails envoyés à l'aide de SendGrid. Si vous avez un peu de temps, nous serons ravis de recevoir vos commentaires pour réfléchir à la manière de construire ce droit!

Voici un lien pour vous inscrire à une place pour parler avec moi et mon équipe de la façon dont vous gérez la traduction et la localisation aujourd'hui: https://calendly.com/travisterwilligar/sendgrid-research?month=2019-09

Merci beaucoup pour votre temps!

@ ben-grid vient de vérifier le calendrier mais les horaires ne fonctionnent pas pour moi, alors je vais faire un bref résumé de ce qui serait génial.

Nous avons un système de commerce électronique avec un bac à sable et un compte de production. Et lorsque nous approuvons un tempalte, nous l'exportons et l'importons en production (c'est aussi quelque chose qui serait une excellente fonctionnalité, avoir des modèles de bac à sable et de production avec un pipeline de promotion)

Quoi qu'il en soit ... actuellement, nous avons 2 langues, mais la tâche à accomplir est de passer à 5 langues. Actuellement, nous avons 11 modèles. Ce que nous faisons maintenant, c'est le {{if lang.en}} Bonjour {{else}} Bonjour {{/ if}} seulement cela ne fonctionnera pas pour 5 langues (20 langues dans un proche avenir) donc maintenant nous allons créer modèles séparés par langue, créant 55 modèles au lieu de 11. (horrible)

Qu'est-ce qui serait génial!

Option 1:
Ajoutez un paramètre "version" à l'API et envoyez simplement la version fournie à. Maintenant, nous pouvons au moins envoyer une version spécifique dans une langue écrite (les versions pourraient être une version traduite du modèle, la version de secours serait la version active)

Option 2
Ajoutez des paramètres localisés à un modèle. De cette façon, nous pouvons utiliser le modèle pour plusieurs langues en ne traduisant que les paramètres. L'inconvénient de cette approche est que certaines constructions de phrases ne fonctionnent pas pour chaque langue, donc vous voudriez probablement avoir plus de flexibilité

* Option 3 La Licorne aux larmes d'or *
En gros, ayez un onglet de traduction pour chaque module que vous déposez. Ainsi, lorsque vous insérez un module comme celui-ci
ce module aurait plusieurs locales. Fondamentalement, un clone de l'original pour une langue différente. Vous devez être en mesure de définir la langue du modèle (définir tous les modules dans une langue spécifique, y compris le sujet et le pré-en-tête), peut-être colorier les modules en rouge s'ils ne sont pas encore remplis pour ce module

Juste mes 2 cents, je serais ravi de vos commentaires à ce sujet, si vous souhaitez envoyer un e-mail, contactez- moi à

@reneweteling Merci beaucoup, c'est très utile. Nous travaillons sur un prototype qui ressemblera probablement plus aux options 2 et 3 qu'à 1. Je vous contacterai par e-mail lorsque nous aurons quelque chose qui vaut la peine d'avoir des commentaires. Encore merci pour votre contribution!

@reneweteling Je pense que l'option 1 ou 2 ferait l'affaire - car elle est très intuitive. Option 3 - eh bien, c'est juste agréable d'avoir ...

@ ben-grid & @ a-tonchev Merci pour tout le travail acharné! Cependant, pour moi, ce n'est plus d'actualité. Continuez votre bon travail!

Des nouvelles sur celui-ci? La limitation de la longueur du sujet est un problème pour moi étant donné que je dois localiser également la ligne d'objet et je pense qu'avec le nouvel éditeur, la longueur du sujet est encore plus petite, je peux avoir environ 110 caractères dans la ligne d'objet.

OMI, il semble que la solution la plus viable serait de générer tout le texte côté serveur, puis de l'insérer dans le modèle sous forme de paragraphes fragmentés.

Si une entreprise prend en charge plusieurs langues, son site Web aura déjà une solution à ce problème qui devrait être côté serveur (chargement des langues à partir de XML / base de données). À mon avis, tous les e-mails liés au même projet devraient également avoir leur texte stocké dans ces fichiers de langue.

Les paragraphes / texte nécessaires peuvent ensuite être extraits de ces fichiers en fonction de la langue de l'utilisateur, puis passés en tant que variables de modèle à sendgrid. Sendgrid serait juste un modèle global (comme, pied de page, etc. - juste des styles et des images) et même certains styles devraient être conservés dans le fichier de langue lui-même - comme spécifiquement les mots à mettre en gras, etc.

Ainsi, le modèle se terminerait par: subject HelloLine welcomeparagraph helpparagraph footerslogan . Et c'est tout.

OMI, il semble que la solution la plus viable serait de générer tout le texte côté serveur, puis de l'insérer dans le modèle sous forme de paragraphes fragmentés.

Si une entreprise prend en charge plusieurs langues, son site Web aura déjà une solution à ce problème qui devrait être côté serveur (chargement des langues à partir de XML / base de données). À mon avis, tous les e-mails liés au même projet devraient également avoir leur texte stocké dans ces fichiers de langue.

Les paragraphes / texte nécessaires peuvent ensuite être extraits de ces fichiers en fonction de la langue de l'utilisateur, puis passés en tant que variables de modèle à sendgrid. Sendgrid serait juste un modèle global (comme, pied de page, etc. - juste des styles et des images) et même certains styles devraient être conservés dans le fichier de langue lui-même - comme spécifiquement les mots à mettre en gras, etc.

Ainsi, le modèle se terminerait par: subject HelloLine welcomeparagraph helpparagraph footerslogan . Et c'est tout.

Ce n'est pas gérable car vous devez redéployer le service de messagerie pour chaque modification de rédaction. Dans certaines entreprises également, le contenu du courrier n'est pas la responsabilité des développeurs mais des rédacteurs marketing / rédacteurs. Vous devrez redéployer une autre interface utilisateur pour permettre la modification, mais nous payons même Sendgrid pour cela.

Dans un projet, nous utilisons un CMS sans tête pour éditer et créer des modèles d'e-mails pour chaque langue. Le serveur lit ces modèles de moustache au moment de l'exécution et génère le corps de l'e-mail à envoyer à Sendgrid. L'édition de modèle Sendgrid UX est complètement inutile, nous avons donc décidé de le faire.

@cecchisandrone Je suis d'accord que sendgrid pourrait être plus agréable. Ils doivent ajouter une bonne gestion de la langue et en faire un paramètre. Mais comme je l'ai dit, certaines variables que nous leur envoyons devront de toute façon être localisées, comme les formats date / heure par exemple.

Comme indiqué par @ corneliu-gavrilovici
Cela vaut même la peine maintenant. Dans une mise à jour récente, la longueur du sujet est devenue encore plus courte. Nous n'utilisons que 2 langues pour l'instant et nous le faisions de la manière ci-dessous dans le domaine du sujet:

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

Je ne comprends pas pourquoi cela a été mis à jour, un produit qui était utilisable pour nous, ne peut plus être utilisé à cause de ce problème. Vous parlez dans votre documentation sur la façon de traiter le modèle de plusieurs langues mais il n'est pas correctement utilisable. @ ben-grid
https://sendgrid.com/docs/for-developers/sending-email/using-handlebars/#multiple -languages

OMI, il semble que la solution la plus viable serait de générer tout le texte côté serveur, puis de l'insérer dans le modèle sous forme de paragraphes fragmentés.
...
Les paragraphes / texte nécessaires peuvent ensuite être extraits de ces fichiers en fonction de la langue de l'utilisateur, puis passés en tant que variables de modèle à sendgrid. Sendgrid serait juste un modèle global (comme, pied de page, etc. - juste des styles et des images) et même certains styles devraient être conservés dans le fichier de langue lui-même - comme spécifiquement les mots à mettre en gras, etc.

Ainsi, le modèle se terminerait par: subject HelloLine welcomeparagraph helpparagraph footerslogan . Et c'est tout.
J'ai fait cela dans SalesForce en utilisant JS côté serveur. L'objet json est dans le modèle mais s'exécute sur le serveur lors de la compilation. C'est similaire à avoir une véritable fonctionnalité de localisation et cela ne dépend pas des publications de développement que vous auriez dans un environnement ecomm.
J'ai hâte de voir ce que l'équipe SG a proposé comme le mentionne @ ben-grid.

+1 fonction de localisation. Si nous avons plusieurs langues, c'est un désordre avec beaucoup de if / else.