Best approach for multiple languages

Hi @Lucia937, welcome back to the community.

This is a great topic! Frankly, I was hoping others would share so I can learn too. I’m not aware of any other features that are specific to localization, aside perhaps the recent launch of Portfolios (today!) which only applies if you have separate Klaviyo accounts for each region.

But I’ve done this for my clients with both using Segments or Lists due to their setup or constraints. There are some tradeoffs with each approach, so maybe I can list a few of my experience here to see what works for you since you get to start from scratch.

Using One List, Segmenting by Language Preference

This is the method of using just one List (or the main List), and segmenting that List into multiple Segments one for each language via a custom property you set in their profiles.  This can be done through a Signup Form, or through the preference page (or perhaps via the API).

Pros

• You have one clean and consistent List for all your subscribers (regardless of language) and can make future segmentation and profile management a lot easier. 
• You can use conditional branches in Flows, or use Flow Filters to have separate Flows for each Segment.  
• The user language preference can be changed easily from one to another at any time since it’s just a custom property value.
• Aggregating reporting are all in one, example List Growth, Engagement Reports, Custom Reports, etc.  

Cons

• The single List settings will apply to everyone.  This includes double-optin (or single-optin) consent settings.  As well as List based default sender Contact Name / Email (you have to change it manually if you have different email addresses for each language).  
• Though you can add language preferences in the Preference page, the Klaviyo hosted (default) preference page itself can’t be multi-lingual unless you use hosted pages or your own solution with the API.  
• Some aggregated reports might not be ideal if you can’t break them out by language. (e.g. English vs Spanish, etc).

Using Many Lists, One for Each Language

This is the method where you have different Lists for each language.  This also means there are typically separate Sign Up Forms for each language (one form, one List) or through the API (or third party tools)

Pros

• Finer control of settings and configuration for each language.  For example, for the EU, you may need double-optin for GDPR compliancy, but perhaps in North America, you only want Single Optin.  You can also set default Sender Names / Email Address for each List (from: support@brand.com, support@eu.brand.com, etc) 
• Your consent/preference pages (on the List level) can be customized for each language.
• You can run separate reports for each List so you can see how they behave comparatively. 
• Any List triggered Flows (Specific to each Language) runs faster than a Segment Triggered Flows. (e.g. Welcome Series).  

Cons

• Some reports are better aggregated, so combining separate reports in some use cases can be tedious.
• It can sometimes be difficult to switch people from one language to another, you will have to add them to a List, and remove them from the other.  Otherwise, they may be getting campaign/flow messages from both languages.   This may require API or some front-end to do this programmatically.  
• You will need to manage how to show different Signup Forms on the site for the appropriate language.  Most sites have some sort of sitewide “switch” or “change language” feature, at which you have some way to change the Klaviyo Signup Form in accordance.  This depends highly on how you have your site setup and can be a technical blocker.

In either method, you can decide if you want to have a Flows with Conditional Branches (either by the custom property language value, or being a member of a List) or completely separate Flows (with a Flow Filter) based on their custom property language value. or which List they belong to.

You can read about this post I did between the Branching vs Flows here: 

Hope this helps, and I’m glad you brought it up. I look forward to see any other ways to do localization here.