How to utilize template versions for multiple language support

[ifndefdeadmau5]

So it seems I can send different email that is written by different language for each customers(localization) according to the docs, but how can I exactly do that? It says I need to activate and change through API, But I couldn't figure out how to achieve it. or do I need to use substitutions and send message bundles from our backend? Any help would be appreciated!

Technical details:

• sendgrid-nodejs Version: master (latest commit: [13af4a6])
• Node.js Version: 6.12.3

[thinkingserious]

Hello @ifndefdeadmau5,

Here is the API documentation on this feature. Here is how to use this SDK to make that API call.

I hope that helps!

With Best Regards,

Elmer

[ifndefdeadmau5]

Thank you for getting back to me @thinkingserious,

I still cannot figure out how 'activate specific template version' actually can be used. I was thinking of scenario that I have 2 versions of template that is written by more than 2 languages, maybe English and Spanish, or whatever.

Then, I make a message send API call with specific template versions that matches with user's language

export function sendSendGridEmail()
{
  sgMail.setApiKey(config.get('sendgrid.API_KEY'));
  sgMail.setSubstitutionWrappers('{{', '}}');
  const msg = {
    to: 'example_receiver@gmail.com',
    from: 'example_sender@gmail.com',
    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);
}

But above example requires 2 separate templates, not the one template of different version. Which can lead to generate separate templates but content is related. What am I missing here? please enlighten me. Thank you again and look forward to hear from you!

[thinkingserious]

Hello @ifndefdeadmau5,

You can have multiple versions per template. Then you can use the SDK to activate a particular version.

First, you would create multiple versions of your template. Then you would activate the desired version before you made the above call.

With Best Regards,

Elmer

[ifndefdeadmau5]

Good morning @thinkingserious,

Thank you for your quick response and I haven't imagine such a work around. Now I understand how to do it, but one question is why not activate all template versions at the first time then just let user can use it without bothering with Activate/Deactivate things?

My concern is, what if more than two users whose using different languages do some actions at the same time(exactly same), so our server needs to address 2 request at the same time. Then which template version would be activated?

below is part of our server code, to just let you know my 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: 'example@gmail.com',
    from: 'example@gmail.com',
    templateId: PASSWORD_RESET_TEMPLATE_ID,
    substitutions: {
      username: 'Test Username',
    },
  };
  sgMail.send(msg);
}

[thinkingserious]

Hello @ifndefdeadmau5,

That's a valid concern.

It seems that what you really need is our new (in beta) templating system. To join the beta, please email ben@sendgrid.com.

With Best Regards,

Elmer

[ifndefdeadmau5]

Hello @thinkingserious ,

I requested through email to ben@sendgrid.com. Thanks!

[andyblack19]

I was also looking at transactional templates to see how we could use template versions for different locale-specific emails. I agree, it seems strange to have to activate a particular template version before using it. This isn't the best solution for our high transaction software. I'd expect to be able to specify which version to use in the POST /mail/send request.

[kylearoberts]

Hey @andyblack19 No need for versioning with the new templates we have introduced. In your account you should see an option for "Transactional" templates. There you can create one template that will serve many languages. You will likely want to take a look at the docs here and an example here.

[andyblack19]

I did read that page.. but completely missed the multiple language section! Thanks for your help

[raine]

It appears that using "Design Editor" mode templates is not possible with the handlebars strategy mentioned above. If one wants to have multiple templates for different use cases with at least two different languages, are you supposed to be copy pasting the template code to each template when the general layout is changed? Why isn't there a way to have a top level shareable layouts?

Also, it would seem that you have to localize the subject of email at server side, instead of in the template content where you are already setting the template body for each language? It doesn't make sense to separate subject and body in this way. Or have I overlooked something?

[kylearoberts]

Hello @raine

It appears that using "Design Editor" mode templates is not possible with the handlebars strategy mentioned above.

You are correct the specific design of the language template found here was not designed to work in the "Design Editor" mode. You could still create something similar in the "Design Editor" using a Code Module.

If one wants to have multiple templates for different use cases with at least two different languages, are you supposed to be copy pasting the template code to each template when the general layout is changed? Why isn't there a way to have a top level shareable layouts?

This is actually something that has been brought up to our engineers. I would still recommend you use the feedback button when you are logged in to your account to let our engineers know this is wanted. The more people who submit feedback like that the more likely it is that we will see an improvement like that. The feedback button is one of the best ways to get feedback directly to our engineers when it comes to anything outside of code libraries. I personally have put in a vote for something similar to what you are looking for.

Also, it would seem that you have to localize the subject of email at server side, instead of in the template content where you are already setting the template body for each language? It doesn't make sense to separate subject and body in this way. Or have I overlooked something?

I think you have overlooked something. I know from my own personal testing that handlebars work in setting the subject of a template. Though I may not be understanding your wording correctly. I know the subject has not been visually designed to support this though so it is best to create the code and content in something like a text editor and paste it into the subject field after. This is another area where using the feedback button is recommended. Please feel free to suggest what you think would be a better way of doing this.

Please correct anything I goofed on and give me further details so I can better understand.

Kyle

[esiqveland]

How does the example of multiple languages address translation of the email subject line?

[kylearoberts]

@esiqveland

In the subject line in the template you would use something like this:

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

You basically use the same structure that is in the HTML content. Please let us know if you have further questions.

[tlinhart]

Hi @kylearoberts, is there a way how to check variable value in the conditional? So instead of checking multiple variables like english or spanish, I'd just check if language variable equals en or es. This doesn't make much difference in the template itself, but it does on the backend where I have to translate language code variable into specially named variable in dynamic template data.

I checked Handlebars briefly and it doesn't seem to support it by default. But maybe SendGrid has some custom helpers built in.

[kylearoberts]

@tlinhart

Thanks for the great question. As it stands right now, the system will not work that way, but we will likely have something later on that will allow something like that. When we do make such a change we will likely update our docs and examples for how to use transactional templates.

[bragma]

Hi, I'm currently using the new template system for my multi language emails. The main problem is the subject field limited length. Basically, my subject content is like this:

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

But there are a few problems:

1. The subject field length is not enough for more than a few languages. I had to cut down the text and variable names just to stay within the limits. But this will obviously not work should we have to add a new language.
2. The editor shows a single line field for entering subject which is unsuitable for working with template subjects.
3. The editor subject field happily cuts down text entered from pasting. This will lead to a template error since the syntax will be wrong due to removed template scripting code

[kylearoberts]

@bragma

I have run into the same issue as you. This is also not the first time we have heard this. We love getting feedback like this because it helps us improve our products. I have made sure to get your feedback to our engineering team and I can tell you this is one of the areas they want to improve things. When they get a chance to work on improvements this is likely to be one of them. Thank you again for the feedback.

[tiz-sharp]

@thinkingserious +1 I need localization feature

[JeromeTo]

@thinkingserious huge +1 for this feature. Really nice feature to be able to deal with all the language of an e-mail within the same template but as stated previously it is not usable due to the subject limitation.

[reneweteling]

@thinkingserious mega +1 for this feature - We also need this feature, for us, the use-case is a bit different, we want to offload the creation/maintaining of templates to our marketing guys, only these people aren't programmers, so we need plain WYSIWYG templates per language. Having 1 separate version per language would be the answer to our problem.

The following would be even better:

1 - the ability to set a default version ( when no version is selected, or invalid version is provided the default version would take over ) 2 - just have an extra parameter in the POST /mail/send API to add a version

We have a platform with more than 12 languages and counting (yes we like a challenge) so we need specific marketing people for different languages, they don't code so plain templates. Also, we plan on having a massive amount of users, so first setting the required template to active, then sending an email would result in concurrency problems where wrong templates will be chosen.

Thanks so much,

[ben-grid]

Hey everyone who's contributed to this issue!

We are doing some research with customers to try and understand how we can best solve the problem of localizing/translating emails sent using SendGrid. If you've got some time you can spare we'd love your feedback as we think through how to build this right!

Here's a link to signup for a slot to speak with myself and my team about how you handle translation and localization today: https://calendly.com/travisterwilligar/sendgrid-research?month=2019-09

Thanks so much for your time!

[reneweteling]

@ben-grid just checked the calendy but the times dont work for me, so ill give a short summary of what would be awesome.

We have an e-commerce system with an sandbox and production account. And when we approve of an tempalte we export and import it to production (this is also something that would be a great feature, having sandbox and production templates with a promotion pipeline)

Anyway... currently we have 2 languages, but the task at hand is to move to 5 languages. Currently we have 11 templates. What we do now is the {{if lang.en}} Hi {{else}} Hallo {{/if}} only this will nog work for 5 languages (20 languages in the near future) so now we are going to create separate templates per language, creating 55 templates instead of 11. (horrible)

What would be great!

Option 1: Add a "version" parameter to the API, and just send version provided to. Now we can at least send a spesific version in a written language (versions could be a translated version of the template, fallback would be the active one)

Option 2 Add localized parameters to a template. This way we can use the template for multiple languages by only translating the parameters. Drawback of this approach is that some sentence constructs dont work for each language, so probably you would like to have more felxibility

Option 3 The Unicorn with golden tears Basically have a translation tab for each module you drop in. So when you insert a module like this this module would have multiple locales. Basically a clone of the original for a different languages. You need to be able to set the language of the template (setting all modules to a specific languages including subject and preheader) maybe coloring modules red if they are not filled in for that module yet

Just my 2 cents, i would love your feedback on this, if you would like to mail, hit me up at rene@wetelilng.com id love to provide some insight. Thanks and hope there will be a solution fast. And if not some insight in how its going to be tackeled so that we can prepare,

[ben-grid]

@reneweteling Thanks much, that's very helpful. We are working on a prototype that's probably going to be more akin to option 2 and 3 than 1. I'll hit you up via email when we have something worth getting feedback on. Thanks again for your input!

[a-tonchev]

@reneweteling I think option 1 or 2 would do the job - since it is very intuitive. Option 3 - well, it is just nice to have...

[reneweteling]

@ben-grid & @a-tonchev Thanks for all the hard work! ive switched jobs though so for me, this is not relevant any more. Keep up the good work!

[corneliu-gavrilovici]

Any news on this one? The subject length limitation is a problem for me taking in consideration that I need to localize the subject line also and I think with the new editor the subject length is even smaller, I can have around 110 chars in the subject line.

[worthy7]

IMO, It seems that the more workable solution would be to generate all text server side, then just slot it into the template as chunked paragraphs.

If a company is supporting multiple lanugages, then their website will already have a solution to this which should be server side (loading languages from XML/database). In my opinion, any emails related to the same project should also have their text stored in these language files.

The neccessary paragraphs/text can then be pulled from those files depending on the users language, then passed as template variables to sendgrid. Sendgrid would just be an overarching template (like, footer etc - just styles and images) and even some styles would have to be kept in the language file itself - like specifically which words to bold etc.

So the template would end up like: subject HelloLine welcomeparagraph helpparagraph footerslogan. And that's it.

[cecchisandrone]

IMO, It seems that the more workable solution would be to generate all text server side, then just slot it into the template as chunked paragraphs.

If a company is supporting multiple lanugages, then their website will already have a solution to this which should be server side (loading languages from XML/database). In my opinion, any emails related to the same project should also have their text stored in these language files.

The neccessary paragraphs/text can then be pulled from those files depending on the users language, then passed as template variables to sendgrid. Sendgrid would just be an overarching template (like, footer etc - just styles and images) and even some styles would have to be kept in the language file itself - like specifically which words to bold etc.

So the template would end up like: subject HelloLine welcomeparagraph helpparagraph footerslogan. And that's it.

This is not manageable because you need to redeploy mail service for every copywriting change. Also in some company, mail content is not responsibility of developers but marketing / copywriters. You would need to redeploy another UI to allow editing that, but we pay Sendgrid even for that.

[raine]

In one project, we use a headless CMS for editing and creating email templates for each language. The server reads these mustache templates at runtime and generates the email body to be sent over to Sendgrid. Sendgrid template editing UX is completely useless so we decided to go with this.

[worthy7]

@cecchisandrone I agree sendgrid could be nicer. They need to add in proper language management and just make it a parameter. But like I said, some variables we send to them will need to be localized anyway, like date/time formats for example.

[JeromeTo]

As stated by @corneliu-gavrilovici It's even worth now. In a recent update the length of the subject got even shorter. We are only using 2 languages for now and we were doing it the way below in the subject field:

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

I don't get why this was updated, a product that was usable for us, can't be use anymore due to this matter. You speak in your documentation on how to deal with multiple languages template but it is not properly usable. @ben-grid https://sendgrid.com/docs/for-developers/sending-email/using-handlebars/#multiple-languages

[jlovemec]

IMO, It seems that the more workable solution would be to generate all text server side, then just slot it into the template as chunked paragraphs. ... The neccessary paragraphs/text can then be pulled from those files depending on the users language, then passed as template variables to sendgrid. Sendgrid would just be an overarching template (like, footer etc - just styles and images) and even some styles would have to be kept in the language file itself - like specifically which words to bold etc.

So the template would end up like: subject HelloLine welcomeparagraph helpparagraph footerslogan. And that's it. I have done this in SalesForce using Server-side JS. The json object is in the template but runs on the server during compilation. It is similar to having a real localization feature and it is not dependant on development publishes you'd have in an ecomm environment. I'm looking forward to see what the SG team has come up with as @ben-grid mentions.

[leoplct]

+1 localize feature. If we have several languages it's a mess with some many if/else.

[gunnartorfis]

Has any work been done to support localization? @ben-grid