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?