Skip to main content
  • EN

We are trying to introduce multilingual Flows to Klaviyo and it seems a lot harder than we would have expected.  Compared to Shopify’s easy multilingual management, trying to do it in Klaviyo gets complicated really fast.  The sign-up form to have users select their Language preference is easy - done, but, from reading Klaviyo documentation and thinking of all the option we can, there seem to be 4 options each with their own pros and cons.

Assume for the purposes of this discussion that we have 5 languages - English, French, Spanish, Italian and Japanese…. with 8 Flows and Flows having Medium Complexity in terms of branching, etc.

 

Option 1 - Use Show Hide Blocks As Klaviyo Recommends

In article “How to Customize Content Based on Language” Klaviyo refers to using Show/Hide Blocks.  In the case of having 5 languages, that would seem like a lot of embedded Show/Hide Codes to add and, do Show/Hide codes work for E-Mail Subject Lines, etc.?   If not, that’s a Show Stopper.  There is no point in sending E-Mails with the subject line in one language.  Has anyone successfully figured out a way to do this?

Option 2 - Set up Multiple Klaviyo Accounts - one for each language

This would seem to have no real benefits  over other options and would be hard to manage I assume since we might have to custom code which account to track a visitor to since our Shopify is multi-lingual.

 Option 3 - Add Conditional Splits to Each Flows Based on Language Variable

This would reduce the complicity from option 1 of having all the Show/Hide Codes embedded in every e-mail and trying to QA them.  But, it would add complexity to the Flow with lots of branches to manage and it would still not address the Subject line issue.

Option 4 - Clone Flows (Entire Flow) - One Clone For Each Language

So this would solve the problems above since you would have 5 abandon cart flows - one for each language, etc.  It would be less complex to manage each one, but it would be 5 to manage if one wanted to update Flow logic.  With all it’s pitfalls, this might be the best option for Quality Assurance and Simplicity, but comes at the cost of having to edit 5 flows each time.

Option 5 - Hope That Klaviyo Has a Plan to support Multilingual Better

It seems odd that there is no option to have “Language Variants” of each E-Mail/SMS, just as there are Variants for A/B testing.  It would seem very elegant to allow users to merely open the variants for each language beside each other knowing with confidence that Klaviyo will present the correct one at run time based on the recipient’s Language..  I understand that it might require “Language” to become a standard supported variable in Klaviyo to support the elegant solution, but I fail to see why this isn’t the case in our multi--lingual world - it is 2022 after all.

 

The issue seems way tougher to deal with than it needs to be.  I would appreciate any and all insights from people that have done this - which method di you use?  Were there any residual issues you couldn’t address?  What did you learn from the experience?

 

Much appreciated.

Hey @Bill C. 

Thank you so much for asking the Klaviyo Community for help with this!

At this time, we do not have the capability to pair the language denoted in the browser URL with the flow content. There is a way to do what you want to do, but it is a little manual. You could create separate paths for your customers based on their locations and tailor the content to match that location's language. I created a TEST flow to demonstrate how you could go about accomplishing this below:

First, you would want to create an "Abandoned Cart Reminder" flow using a "Domestic vs. International Split."

?name=inline-1046809647.png

Once this is made, you can change the conditional split criteria options here to use "Properties About Someone," and "Country Equals."
?name=inline-1124172222.png​


This is an example flow that I made (without modifying any emails) - as long as you modify the emails for each country path, this workaround should be sufficient.  
?name=inline303263603.png​
I can also add that  Klaviyo will be adding a global edit feature for flows that will help you update all of your content all at onces to help save you time and effort so stay tuned as our teams are working to get this done as soon as possible for our customers. Also I have sent a product feature request to our development team with your feedback to simplify this process for our multinational users. Thank you for your feedback to help us make Klaviyo better, We rely on customers like you to keep developing a more robust tool! 

Hi Stephen.   Thanks for your feedback.

I see your idea about branching by location, but we have already chosen the Klaviyo recommendation to ask users to select their Language from a list of choices on their Sign-up Forms.

The logic you outline above is essentially the same as my “Option 3” , except that we would branch the flows on the Language Variable we store, rather than Location.   So my main issue with Option 3 is that, we would need to add a branch an clone every condition and e-mail for every language - at 5 languages, flows could have 10s of elements in a flow, just to maintain the similar logic for different languages.  If we had 20 languages, each flow could end up with 100s of elements in each Flow - it honestly just sounds like a support nightmare….  The complexity gets confounding in a hurry, simply to deal with the situation where people of the world speak more than one language.

 

Is “Option 3” style coding your recommended choice of all the options, because, as I had noted, I was leaning toward “Option 4” as being the best option until Klaviyo delivers a simpler way to deal with multi-lingual.?

Thank you for sending my e-mail forward to review as a feature request.  I am hopeful that Klaviyo tackles this item, but, in the interim, I need to work with what I have.

You mention Klaviyo will be adding a global edit feature for flows that will help you update all of your content all at once to help save you time and effort so stay tuned as our teams are working to get this done as soon as possible for our customers. This sounds awesome, I think, but I would be curious to get a bit of an understanding of how it might apply to this use-case and whether  it would inform any of our choices about how to design our multilingual flows in the next few weeks so we can be ready to take advantage of the feature when it arrives.   Would if be possible to get some information about how the feature will work (under NDA is fine) or be included in an early beta test to use it. If it is a week away from launch, I’d hold off on our multilingual project.  If it’s a month, we need to go anyway, but would be guided by any design practices that allow us to build supportable Flows. If it’s 6 months away, it is maybe less topical.

 

I welcome any and all feedback on whether Option 4 from my original e-mail is the best route - it’s not great, but, it still feels like the best of the available choices.  But, I’d rather hear the pitfalls in case I have a huge blind spot.

 

PLEASE add support for Shopify multi language stores to your roadmap. I know many US based stores are blessed with just having one language but here in Europe a typical store has customers speaking German, French, Italian etc and we need to optimise for them. Also Shopify is adding more and more support for international cross border selling, so even your US customers will need this feature.

We have the same problem, here in Canada there is French and English in the same country. We will go with option 4 for the moment but it is tedious. It should be a core feature.

Thanks for posting here, I will apply this in my case too, hope this will help me out. 

We have the same problem, here in Canada there is French and English in the same country. We will go with option 4 for the moment but it is tedious. It should be a core feature.

I have the same issue but how do you separate the flow based on language? Do you ask for the prefered language in the newsletter pop up? What about people who directly purchase from the websitem how do you know which language they prefer?

We are trying to introduce multilingual Flows to Klaviyo and it seems a lot harder than we would have expected.  Compared to Shopify’s easy multilingual management, trying to do it in Klaviyo gets complicated really fast.  The sign-up form to have users select their Language preference is easy - done, but, from reading Klaviyo documentation and thinking of all the option we can, there seem to be 4 options each with their own pros and cons.

Assume for the purposes of this discussion that we have 5 languages - English, French, Spanish, Italian and Japanese…. with 8 Flows and Flows having Medium Complexity in terms of branching, etc.

 

Option 1 - Use Show Hide Blocks As Klaviyo Recommends

In article “How to Customize Content Based on Language” Klaviyo refers to using Show/Hide Blocks.  In the case of having 5 languages, that would seem like a lot of embedded Show/Hide Codes to add and, do Show/Hide codes work for E-Mail Subject Lines, etc.?   If not, that’s a Show Stopper.  There is no point in sending E-Mails with the subject line in one language.  Has anyone successfully figured out a way to do this?

Option 2 - Set up Multiple Klaviyo Accounts - one for each language

This would seem to have no real benefits  over other options and would be hard to manage I assume since we might have to custom code which account to track a visitor to since our Shopify is multi-lingual.

 Option 3 - Add Conditional Splits to Each Flows Based on Language Variable

This would reduce the complicity from option 1 of having all the Show/Hide Codes embedded in every e-mail and trying to QA them.  But, it would add complexity to the Flow with lots of branches to manage and it would still not address the Subject line issue.

Option 4 - Clone Flows (Entire Flow) - One Clone For Each Language

So this would solve the problems above since you would have 5 abandon cart flows - one for each language, etc.  It would be less complex to manage each one, but it would be 5 to manage if one wanted to update Flow logic.  With all it’s pitfalls, this might be the best option for Quality Assurance and Simplicity, but comes at the cost of having to edit 5 flows each time.

Option 5 - Hope That Klaviyo Has a Plan to support Multilingual Better

It seems odd that there is no option to have “Language Variants” of each E-Mail/SMS, just as there are Variants for A/B testing.  It would seem very elegant to allow users to merely open the variants for each language beside each other knowing with confidence that Klaviyo will present the correct one at run time based on the recipient’s Language..  I understand that it might require “Language” to become a standard supported variable in Klaviyo to support the elegant solution, but I fail to see why this isn’t the case in our multi--lingual world - it is 2022 after all.

 

The issue seems way tougher to deal with than it needs to be.  I would appreciate any and all insights from people that have done this - which method di you use?  Were there any residual issues you couldn’t address?  What did you learn from the experience?

 

Much appreciated.

Nice list, but i have a question: Why do you say that option 3 does not address the subject line issue? If you brand per language then you can set up the subject line to whatever you want for each email, no? or am i missing something?

Any update here guys? With ChatGPT nowadays it’s so easy to start selling internationally, so having an easy way for signup forms/flows/campaigns is an absolute must!  

Reply


Terms & ConditionsCookie settings