Lost in translation

Is translating your emails enough to connect with a global audience?

In his Unspam 2025 talk, Rob Gaer, a veteran email developer and lifecycle marketer at Miro, breaks down what it really takes to build localized emails that connect and convert. With years of experience and a healthy dose of humor, he walks the crowd through real-world challenges, proven methods, and practical tips for scaling multilingual email programs without losing your mind or your message.

TL;DR:

• Localization isn’t just translation. It’s design, data, and cultural context.
• Simple, clear source content is your foundation.
• Conditional logic and fallback strategies are your best friends.
• Choose the right localization method: dedicated templates, inlining, or dynamic mapping.
• When done right, localized emails build trust, boost engagement, and drive results.

Get ready to rethink what localization really means and how to make your email program speak your audience’s language.

Rob Gaer: Hello, everyone. My name is Rob Gaer, and I am here to talk about email localization and tell you a little about myself. I've been working with email since 2006, and in that time, I've held many different titles, such as email designer, marketer, specialist, and developer.

And I've worked across many different industries. For the last six years, I've been working a lot with multilingual emails, which is convenient because I'm talking to you about that today. I joined Miro in 2021 in the lifecycle marketing team. During that time, I helped build their email design system. I work very heavily with data-infused transactional emails and on their onboarding flow. Finally, I worked extensively with their localization team and learned a lot about how localization works at Miro. We're an innovation workspace with over 90 million users worldwide, and our email program supports eight languages. I've divided today’s discussion into three sections: why you should make a case for localizing, what I’ve learned about localized content, and finally, how to build localized emails. But before I begin, I want to inspire you with a quote I wrote with my friend Claude.

So why make the case for localizing? I like to start with fun facts, so let's do that. Did you know that there are over 7,000 languages today? And, you know, I don't suggest supporting them all in your email localization platform, but this is a pretty mind-blowing fact for me. There are almost 200 languages spoken in the US alone. Companies that provide localized materials have a competitive advantage with their audience.

Most online consumers prefer to buy when content is presented in their native language, and a healthy chunk of me doesn't want to buy at all. By the way, the little robot friend in the top left was generated with Miro AI, and my prompt was to illustrate a cute little robot with a globe in its belly.

It symbolizes email localization, and this is what it gave me. So that was pretty cute. Speaking of Miro, we did our own A/B testing to test the efficacy of our localization efforts. We tested English content in our control group versus a user's preferred content in the variant group, and we got some interesting results.

We saw a significant improvement in our open rate with one test—it doubled its effectiveness. We also got a nice boost to our click rates. Finally, we saw a healthy, about 25% bump for our primary testing metrics. And I gotta tell you, this is not too surprising because people want stuff in their language. To summarize, localization will boost your market reach and have a tangible business impact.

Delivering content in a user's preferred language will help build trust with your audience and provide a more consistent user experience. Finally, localized emails will help drive higher engagement by meaningfully connecting with recipients. So, what have I personally learned about localized content? So, full disclosure with you, I'm not a copywriter or a content writer, so this is the perspective of an email developer who has to work with localized content, so grain of salt, and I always think of the acronym K.I.S.S. when I work with localized content. 

And what does that mean? Well, it can mean keeping it super simple—short, straightforward, simple, and smart. Here are three good pieces of advice when writing source content for localization. In this context, it's not a band from the seventies, and I like the emoji. The person in the top right is very concerned with Gene Simmons's antics here, as most people probably would be. But, K.I.S.S. has a traditional meaning: keep it simple, stupid, but it's not a very nice thing to say. So let's just say keep it simple, silly. And that's the strategy for source content. So, you want to use clear, concise language and simple sentence structure. Avoid idioms, cultural references, slang, or complex metaphors that won't translate well into other languages.

Speaking of translations, one strategy is to avoid word-for-word translations. For example, our localization managers adapt English messaging based on cultural context and the preferences of their audience. Whether they support or don't support something, they consider local communication styles and the overall expectations of that audience. And, this last point is for me, but conditional text is complicated when you start to localize it. Some things that seem simple in English, like adding an S to a word when you have numerical data above one, it’s super easy in English, but it isn't very easy when you start localizing that, because some languages will have different plural forms based on the count.

Some languages have gender rules and different word orders, which can get complicated. My general strategy in dealing with this conditional text is to separate those lines into separate items. So, like using the plural example, if I have a statement with a singular word and then one with a plural, I will separate those as different conditions, and I just find that it's a much easier way to localize this content. And in terms of layout considerations, some languages have long words. For instance, German and Polish have roughly 30% longer word length, and hyphenation will be your friend here. So you definitely wanna check those out. And if you're a designer and put text in your graphics, you should also remember to localize those.

So be very careful when using text when you know the content will be localized. Finally, text styling is pretty challenging when you don't read the language or understand the alphabet of the language that you're using. So work. I work closely with language managers to ensure that all your bolds, italics, and text links are in the correct position. Okay, so I have some real-world examples to share with you that encapsulate all these ideas. One of them is the Miro welcome email, which looks like a Miro board.

I want to point out a few things. All of the text you see here is live text, with the exception of two elements. One is the UI in the top left, where it says "greetings." The bounding box with the four cursors around it is also a background graphic with the headline overlaid. Right away, I mean, we used straightforward wording here: "Welcome aboard" and "Let’s get started." The call to action is to begin creating in Miro, so we like to keep things simple. Two little more factoids: the cursor below the CTA is actually HTML, and "Miro Hero" is the fallback name in case we don't have the subscriber's name.

Finally, the Miro team in the from address is also a detail that we localize. So let's look at this: German. Right away, I had to shrink the headline in German because it was long and would go outside the bounding box. The same goes for French. This one was kind of weird because the call to action got a little longer, and the subheadline got a little shorter.

Spanish is kind of wordy. Japanese is an interesting one to work with. I do not read Japanese, and I do not understand the alphabet, but it looks kind of cool. So, I had to work closely with the localization manager to ensure everything was QAing correctly.

Portuguese, another kind of wordy one, Korean. Okay, this is interesting because our localization manager added that little. A wavy emoji is added to the headline because you know that that speaks better to the audience she supports. Finally, Polish. I don't know how I got this headline to fit our standard headline size, but it did.

Another thing to note is the hyphen in the subheadline because long words will break your layout. So, Hyphenation will be your friend. To summarize, keep things simple. Think about using simple language in the welcome email, especially in the headline. Our localization managers adapted the messaging to their audience.

They didn't just translate one-to-one. I had to modify the layouts to account for when languages would have a longer translation, and finally, all the graphics we had to localize to give it that full, polished, and complete look. So now, let's move on to the section on building localized emails.

I don't know about you, but these two look like they're having fun. I can tell they're working on something email-related because that's how I look when I'm doing email stuff. Okay, so prerequisites. To send content in a user's preferred language, you need to know your user's preferred language.

I've seen or used three different methods for getting this kind of content. The first is by region. The idea around regionalization is that you localize your email into the predominant language of the region and then send it to the area. But this approach is flawed because it doesn't account for why your subscribers are in the region or their preferred language.

So, anecdotally speaking, I've been living in the Netherlands for the last six years. But I'm not fluent by any means, and I get many Dutch emails, including my mortgage statement and utility emails. And those are the kinds of things I'd like to understand better. So, how can we get a more accurate idea of our users' language? One way would be to detect their browser language. The idea here is to detect the subscriber's browser language when entering your website or app. Then, you store this for later use, and then you know you use it.

But then, the third method is my favorite: asking them. For example, ask them to sign up in the preference center or the little pop-up that says, "Sign up for the newsletter." Maybe put a little dropdown that says, "What language would you like this?" And then they'll tell you, and you'll know.

Okay, so now we're gonna talk about email development. So I want to share with you my mantra that I say a lot at work lately, which is “Emails are fucking complicated”. I mean, they are like, you can have data issues and rendering issues and deliverability issues and domain issues and subscription issues, and just things that are broken problems and emails are fucking complicated.

But don't panic—I'm here to help you. I have three different methods to localize email content that I will share with you today. The first is dedicated templates, where you create one template per language you support. That's kind of it. That's the whole strategy, like one email per language. There are benefits and drawbacks to this. One is that it's easy and gives you total control over your layouts. If you don't support a large language set, it's probably better than not localizing.

And for your analytics team, it's a bit cleaner. As you know, each email will be separated. So the segmented language audience will be separated. The downsides are that version control and maintenance can give you nightmares when you have so many different versions. For instance, if you have a brand update, you have to do it, and another thing is that your user journeys will grow exponentially if you use individual templates. So if you're working on an onboarding journey, that's it, and support five emails, that's like 20 templates. Overall, it just won't scale that well. But what is a method that will scale a bit better, a bit better? And I'll tell you it's what I call inlining.

So, the concept here is that you have a single email, nest all of your localized content in one template, and then use your ESP scripting language to show that content based on your user's language data. And I made this little graphic to symbolize what it's like to have one email. There's the global header and footer, and then inside the body is this fake, liquid syntax. I wrote about how we got our German, French, Spanish, Japanese, and finally English. There are pros and cons to this as well. It's more scalable than method one. It resolves to a single email to manage, making it much more flexible for version control and maintenance. It's also pretty well suited for multi-step user journeys.

The downside is that you need to know scripting and have your subscribers' language data to show them the correct content. When you have a bunch of nested information, it can create massively large files. But the good news is that when it sends, it'll render out all the unused data, and they'll get a regular email. So don't worry about that. But overall, you must do a lot of Q&A, which will require much manual effort. It's a headache for the analytics team because they get one email, and then they must dig deeper to find all the segmented data. But don't worry. I have some tips for inlining here.

Overall, conditional statements are super flexible. You can nest them with HTML tags, around blocks, or around design system modules. They also work well with localized images. One strategy I employ is using English as a fallback, so you can see my little code block here. The EL statement, the English headline, is hidden down there. I do that because if we miss any language data, all the content will fall back to English, and the user will not get a blank email. Full disclosure here: this is the system that Miro is using right now to localize our email, but we've been investigating a more scaled-up method of how we can do that. 

I've used dynamic content mapping in the past. It's a system where your content and your presentation are separated and then come together at the end of deployment. It's like a Luke-Leia situation. They're separated at birth and come back at the end to save the day and all that. It’s a data-driven mapping system that connects translated text to dynamic templates. This is hard to explain. I think I designed this section three or four times, but hopefully, this will make sense to you.

At its core are three basic components: a source template, a translation document, and a dynamic template. Let's talk about those. Your source template will determine how your localized content will look. It's the origin of the email. It's where you're going to be doing most of your content and design work. It's basically a fully functional email in your primary language: English, in my case. The translation document could be like a table or a JSON, extracting all the source content from your source template and mapping it into the documents. So, if we're looking at the table here, you can see there are different column headers, a key, and then different language values that will come into play later here.

All that content is mapped to a different row. So, you can change the number of rows you might have depending on your design. For this example, I have headline, body one, CTA, and body two. A JSON is another translation document you can use. However, the way that it organizes data is slightly different.

So there's an object. And it's for EN, it's for English. Inside that object are all these string values that your dynamic template will extract and get injected into. How you extract this content can be done by parsing or tagging, or maybe you have an AI friend, or sometimes you have to do manual labor. The final component is the dynamic template, which is your source template converted into something with tokens or variables that form key-value pairs. With your translation document, we have our source template, translation document, and dynamic template. The translation document will have your source content.

You need to send it out to get localized, and when you get it back, it is filled with localized content. Depending on whether you use tables or JSON, you can map it into your dynamic template differently. So, if you're using a table, CSV, tab-delimited text, or a data extension or something like that, you'll use a lookup function to match your subscriber's language data, and then it'll find the row. Then the different key-value maps of the keys will inject that content into your dynamic template. This methodology is very similar to JSON, except that for JSON, you use a for loop. So a for loop will loop through this JSON data. When it hits a match, it will then take that content in the object map and inject it back into the dynamic template.

I'm not showing you a third little piece here, like a mapping thing that tells the system what content to put where. It's boring, so I didn't want to put it here. There are pros and cons. This method is highly scalable. If you have an integration working, it will enable hands-free copy updates. As you add new content, a dynamic template will automatically pick this up. The downside is that it's tough to set up correctly. It will add a large degree of complexity to your email production process and require constant testing to ensure that the data flow is working correctly and users are getting the correct content. And it's pretty resource-intensive.

But don't worry. I have some tips for you here. So, how do you set up your tech stack? Well, that totally will depend on your tech stack. Your ESP might work better with tables, or it might work better with JSON. ESPs will integrate differently with different TMS platforms. And a TMS platform is a translation management service. The idea behind the integration here is you want to get a push-pull mechanism working. When you have your source document that has your primary language content, you want to push that to your TMS system.

Then your localization team will do their business in the system, and when they're all done, you'll get the pull mechanic back into your ESP, and that is how you will get all that content into your dynamic template. This will require a ton of testing because there are many moving parts, and you want to be sure that you are showing the right content for the right users.

A little side tip around RTL languages. This is a unique challenge, but one method is to wrap a conditional statement around different blocks that might be pre-programmed for RTL. You can also try doing this in a system like Taxi for Email, where you have different modules that you can toggle for other things. Another way you could potentially try doing this is using conditional logic to change the LTR/RTL style in the HTML itself.

However, your mileage may vary here because some platforms, like Salesforce, will allow you to do that, whereas others will not. To summarize, dedicated templates will be easy but not super scalable. Inlining will add more scalability to your flow but increase the complexity and require a lot of manual effort. Finally, dynamic mapping is a huge lift to set up, but once it's set up correctly, it will be highly scalable and dynamic.

To wrap up what I've been talking to you about for I don't know how long, localizing emails will boost your email performance and have a positive business impact. The strategy for content writing is to keep things super simple and be wary of how localization can impact your layouts. I also shared three different methods for localizing your emails, and you should consider the one that works best for you. And then, you know, just localize those emails. I'm gonna share this super awesome quote with you one more time. And I think that's it. So thank you very much.