Multi-language emails have some limitations due to how email clients render content. This article explains what doesn't work and provides workarounds to help you build successful multi-language campaigns.
Subject Lines and Preheader Text
The Limitation
Subject lines and preheader text cannot be changed for different language versions. All recipients see the same subject line and preheader, regardless of which language they select in the email.
Why This Happens
Email subject lines and preheaders are set at the email level, not within the email body. There's no way to make them dynamic based on recipient language preference.
Workarounds
Option 1 - Use neutral language: Choose subject lines that work across all languages or use widely recognized terms:
- "Important Update / Mise Ă jour importante"
- "Q4 2025 Newsletter"
- "Team Announcement"
Option 2 - Include multiple languages: Write the subject line in multiple languages if it's short enough:
- "Welcome / Bienvenue / Bienvenido"
- "New Policy | Nouvelle politique"
Option 3 - Use symbols or emojis: Make the subject universal without words:
- "đą Important Update"
- "đ Celebration Event"
Option 4 - Prioritize your largest audience: Write the subject in the language most recipients speak, then translate everything in the email body.
Unsupported Content Blocks
Several content block types don't support multiple language versions. Here's what doesn't work and how to fix it.
Text Content Blocks
The Limitation
Text content blocks don't support multi-language functionality. Content in these blocks stays in your primary language.
How to Identify Text Blocks
Text blocks are legacy content blocks from an older version of the Email Builder. If you're working with an old template, you may encounter them.
The Workaround
Replace Text blocks with Paragraph or Title blocks:
- Note the content in your Text block before deleting it
- Drag a Paragraph or Title block in its place
- Paste your content
- Reapply formatting if needed
- Translate normally
Tip: Paragraph and Title blocks support all multi-language features, including auto-translation (Grow and Enterprise).
Custom HTML Blocks
The Limitation
Custom HTML blocks don't automatically translate. The HTML code remains unchanged across all language versions.
The Workaround
Include all language versions within your HTML code using <div> tags or conditional logic:
<!-- English version --> <div class="lang-en"> <h2>Welcome to Our Newsletter</h2> <p>Thank you for subscribing.</p> </div> <!-- French version --> <div class="lang-fr"> <h2>Bienvenue Ă notre newsletter</h2> <p>Merci de vous ĂȘtre abonnĂ©.</p> </div> <!-- Spanish version --> <div class="lang-es"> <h2>Bienvenido a nuestro boletĂn</h2> <p>Gracias por suscribirte.</p> </div>
Note: This workaround requires HTML/CSS knowledge. If you're not comfortable coding, avoid HTML blocks in multi-language emails.
Menu Blocks (Anchor Links)
The Limitation
Menu blocks use anchor links to navigate within the email. Anchor links don't work reliably on mobile devices, which is where most people read email.
Why This Matters for Multi-Language
The multi-language menu uses anchor links to let recipients jump between language versions. On mobile, this navigation may not work.
The Workaround
Use the built-in multi-language menu instead of creating your own Menu blocks:
- Don't add Menu blocks to your multi-language emails
- The Email Builder automatically creates a language menu
- Recipients use this menu to navigate between languages
- On mobile, recipients scroll through stacked languages
Alternative: Design your email so the most important content appears near the top in all languages. This helps mobile users who need to scroll.
Tables
The Limitation
Table content doesn't translate automatically. Text inside tables remains in your primary language across all versions.
The Workaround
Manually include all language versions within your table cells:
Best practice: Avoid complex tables in multi-language emails. Use simple layouts with Paragraph and Title blocks instead.
Event Pages and RSVP Forms
The Limitation
When recipients click to RSVP for an event, the event page displays in your primary language only. It doesn't translate.
What Still Works
- Recipients can still RSVP
- You still receive their responses
- The RSVP button in the email can have translated text
- Event details in the email body can be translated
The Workaround
Option 1 - Keep event details in the email: Include all critical event information in the translated email body, not just on the event page.
Option 2 - Use external forms: Link to an external registration form that supports multiple languages (like Microsoft Forms or Google Forms with language options).
Option 3 - Create separate events: If the event is critical, create separate event pages for each language and use different buttons/links in each language section.
Survey Confirmation Pages
The Limitation
When recipients click a survey answer in the email, the confirmation page displays in your primary language only.
What Still Works
- Survey questions in the email can be translated
- Responses are captured correctly
- Analytics work normally
The Workaround
Option 1 - Set expectations: In your translated survey question text, let recipients know the confirmation will appear in English (or your primary language).
Example:
- English: "Click to answer (confirmation page in English)"
- Français: "Cliquez pour répondre (page de confirmation en anglais)"
Option 2 - Use simple confirmation text: Keep your survey confirmation message short and simple so language matters less.
Related: Survey Overview: Reusable vs Single Use Surveys
Language Limit
The Limitation
You can include a maximum of 6 languages per email.
Why This Limit Exists
Email file size increases with each language. More languages mean:
- Larger email files
- Longer load times
- Higher chance of Gmail clipping (102 KB limit)
- More complex navigation for recipients
The Workaround
Option 1 - Export and link externally:
- Instead of one large multi-language email, separate each translation into its own mono-language campaign in the Email Builder
- Export the draft(s) as HTML files
- Upload the HTML files to a centralized location (ex: SharePoint folder, shared Google Drive)
- Copy the share link and add it to your primary email's body
Option 2 - Create multiple emails: If you need more than 6 languages, create multiple email campaigns:
- Email 1: English, Spanish, French, Portuguese, German, Italian
- Email 2: Polish, Dutch, Norwegian, Finnish
Segment your distribution list and send the appropriate email to each group.
Tracking and Analytics Limitations
The Limitation
You cannot see which specific language a recipient viewed. Analytics consolidate all language versions into one report.
What You CAN Track
- Total opens
- Total clicks
- Individual recipient engagement
- Survey responses
- Event RSVPs
- Click maps
- Read time
What You CANNOT Track
- Which language each recipient viewed
- Most popular language version
- Language-specific engagement rates
The Workaround
Option 1 - Use naming conventions: If you need language-specific analytics, create separate campaigns for each language and use consistent naming:
- "Q4 Newsletter - English"
- "Q4 Newsletter - French"
- "Q4 Newsletter - Spanish"
Option 2 - Survey recipients: Add a survey question asking which language they prefer: "Which language do you prefer for company communications?"
Option 3 - Segment by location: If language correlates with location, segment your analytics by recipient location as a proxy for language.
Best Practices for Working With Limitations
- Design for simplicity: Avoid complex layouts, tables, and custom HTML in multi-language emails.
- Test on mobile: Most limitations affect mobile users more than desktop users. Always test on mobile devices.
- Document your workarounds: Create a team guide explaining how you handle each limitation.
- Set recipient expectations: If something won't translate (like event pages), tell recipients in the email.
- Use standard blocks: Stick to Paragraph, Title, Button, and Image blocksâthey have the fewest limitations.
- Keep it short: Shorter emails have fewer issues with Gmail clipping and mobile rendering.