Best practice for multilingual marketing activities?

[Justin_Norris1]

No matter how you slice it, localization and multi-language stuff is a significant extra effort. Uni-lingual companies don't know how easy they've got it .

We've built out some fairly complex programs for clients using a single multi-lingual program template, with all assets made dynamic with a language segmentation, and then tokenizing the whole thing so you skip the editors completely (never touching the editors is key for making this efficient).

We have kept all the tokens at the main program level, still keeping common tokens universal but having localized versions for everything that requires it. If you have a very clear naming convention, it is quite manageable and fast to deploy.  

I really like the idea of nesting the email programs to be able to re-use all token names (as in Frank's approach), but seems like this only works for batch and blast. We also try to reduce the number of smart campaigns etc. that need to be activated. Basically the fewer things you need to touch and change, the faster it is and the less risk of error.

Iryna Zhuravel​ I would be interested to hear more about your experiences, pain points, and the benefits you're hoping to gain with scripted tokens vs. dynamic content.

The ability to "segment" by multiple variables using the velocity tokens I am aware of and it is a benefit for sure.

[Victor_Herrero]

Hi @Iryna_Zhuravel4 , 

Could you maybe share an example of how scripted tokens make things more scalable or an example use case? 

I think tokens can be intimidating for a lot of people using Marketo, and script tokens even more so. 

The way I understand it is: 

Instead of making emails dynamic you use a static version of them and all text blocks are a script tokens? 

How do you handle common "tokens" like dates and times ? Do you reference the field directly from the code? Because you can't put tokens inside tokens (sadly).

And the blocks... do they look at some translation file for each email to show based on some "preferred language" field on the record? Or maybe you are using localized tokens? 

Also @SanfordWhiteman did that infographic ever see the day of light? Or maybe a blog post? 🙂 

Thanks! 

[SanfordWhiteman]

---

Instead of making emails dynamic you use a static version of them and all text blocks are a script tokens? 

---

I prefer to call it "a different type of dynamic" as opposed to static.

A Velocity-powered email can be way more dynamically personalized than "Dynamic Content" allows - for example, using the intersection of multiple fields + multiple segments at the same time to determine final content.

---

Do you reference the field directly from the code? Because you can't put tokens inside tokens (sadly).

---

Well, you can reference Velocity variables set in one {{my.token}} from other Velocity {{my.tokens}}. So it is a form of tokens inside tokens.

---

Also @SanfordWhiteman did that infographic ever see the day of light? Or maybe a blog post?

---

We never did it, but maybe I'll reach out to Frank... been awhile since this post!

[Victor_Herrero]

Sorry for taking this long, I was expecting an email notification. 

A Velocity-powered email can be way more dynamically personalized than "Dynamic Content" allows - for example, using the intersection of multiple fields + multiple segments at the same time to determine final content.

With regard to this, I think I see what you mean. In a dynamic email you can basically use one segmentation, like say language. But if you had content A and B in each language, you couldn't reach that depth, and you would need a more complex segmentation combining both language and somehow also A and B contents. So I take it that this would be achieved making use of your "tokenception"? 

Have contents A and B in a script and have one version of this per language, then reference that token based on language segmentation (for instance) and let the script token give your lead A or B based on whatever rule in the script? 

Maybe even ditch the segmentation altogether and use a script token (or several) for the email body that changes based on your country field. 

Is there an example of tokens referenced in tokens that you can show me? Even a simple one? Maybe in your blog? 

Do they have to be on the same folder (scope) ? 

This is perhaps what you mean https://nation.marketo.com/t5/Product-Discussions/Referencing-local-tokens-in-an-email-Velocity-emai...

[SanfordWhiteman]

Yes, that thread has examples of what I mean. 

You can also use #define in {{my.token1}}:

#define( $en_US )
Choose your favorite color.
#end
#define( $en_UK )
Choose your favourite colour.
#end

And access those as $en_US and $en_UK in {{my.token2}} (if you include {{my.token1}} in the email first of course).

[Victor_Herrero]

That looks really interesting! Thank you for sharing 🙂

That would mean you can create a token where you define variables, then include it inside the email (even if it doesn't really output anything, just contains variables) and start referencing when appropriate. 

For instance: 

{{my.contentVariations}} - contains &varA_EN, &varB_EN, &varA_ES and &varB_ES of the content (probably also a default value).

{{my.emailBody_EN}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_EN or $varB_EN

{{my.emailBody_ES}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_ES or $varB_ES

...

Then you would need an email containing {{my.contentVariations}} whose body is another script, similar to a switch in javascript, where the cases are your preferred language, and for each case you serve a different {{my.emailBody_**}}. Is that more or less the direction? What you meant with adding levels of dynamism by referencing tokens inside tokens? 

[SanfordWhiteman]

---

{{my.contentVariations}} - contains &varA_EN, &varB_EN, &varA_ES and &varB_ES of the content (probably also a default value).

{{my.emailBody_EN}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_EN or $varB_EN

{{my.emailBody_ES}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_ES or $varB_ES

...

Then you would need an email containing {{my.contentVariations}} whose body is another script, similar to a switch in javascript, where the cases are your preferred language, and for each case you serve a different {{my.emailBody_**}}. Is that more or less the direction? What you meant with adding levels of dynamism by referencing tokens inside tokens? 

---

You don't put the {{my.token}} itself inside another token.

It's the variables that are shared across tokens. 

So you include the {{my.tokens}} one after the other, and then each subsequent token can access all the vars defined in earlier tokens.

When done properly you end up with 

1. {{my.Global Config}} (this top-level token is for global settings, not "data" per se but things like field mappings & friendly names)
2. {{my.Local Config}} (lower Program-level token, where you may overwrite the Global settings if necessary)
3. {{my.Localized Content}} (defines the locale-specific content, no output}}
4. {{my.Content Chooser}} (the code that determines which content to output}}