Translate Elementor & Divi Templates Without Breaking Layouts

You did everything right. You bought a premium theme, found the .po file, translated it carefully, and uploaded the .mo to your languages folder. Strings in the theme header update correctly. The footer reads in Spanish. Your WooCommerce checkout is localized. But then you open the homepage and every single heading, button, and text block built with Elementor is still in English.

You check the .po file. You can see the English strings in code. You retranslate. Nothing changes. You clear caches. Nothing changes. You convince yourself something is broken until someone in a forum gently points out: Elementor (and Divi, and Beaver Builder, and Bricks) do not store content in .po files. They never have. You have been fighting a problem that is not solvable with the approach you are using.

This guide explains why page builder content is architecturally different from theme and plugin content, the two paths for translating it, and how to keep widget markup intact during translation so your carefully designed layouts do not fall apart.

Why Elementor and Divi Don't Use .po Files

.po files store strings that live in code - __( 'Shop', 'mytheme' ) calls scattered across PHP templates. The build tool WP-CLI can extract these strings into a .pot template, translators work on .po files, and compiled .mo files are loaded at runtime.

Page builder content is different. When you type "Welcome to our store" into an Elementor heading widget, that text is not in any PHP file. It gets saved as JSON (Elementor) or a shortcode blob (Divi) in the wp_postmeta table, associated with the post where you placed it.

Where Page Builder Content Actually Lives

Elementor stores each page's widget tree in postmeta under the key _elementor_data. Open any post in the database and you will find a JSON array describing every section, column, and widget, with settings and content inline:

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi stores its page content as shortcodes embedded in post_content:

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder, and Oxygen follow the same pattern with their own format. None of this content is ever touched by .po / .mo files.

What Does Live in .po Files

The page builder plugin itself has UI strings - button labels in the editor, error messages, admin notices. Those are in .po files and do get translated by your .mo files in wp-content/languages/plugins/. This is usually why people get confused: they translate "Elementor" strings and see the editor UI in Spanish, but the actual content they built with those widgets stays in English.

This distinction is also the root cause of half the tickets in our troubleshooting guide for translations not showing up - the reader expects .mo files to affect content they see on the front end, but the content is in the database, not in code.

What .po Files Actually Cover on a Page-Builder Site

Let me draw a clean line between the two so you know exactly what each file type handles.

.po / .mo files translate

• The theme's template strings: get_template_part, hardcoded text in header.php, footer.php, functions.php.
• Plugin UI strings: WooCommerce checkout, Yoast admin labels, Contact Form 7 field labels.
• Page builder plugin UI: Elementor editor buttons, Divi save confirmation messages.
• Dynamic strings that plugins echo to the front end: WooCommerce "Add to cart," "Out of stock," cart totals.

.po / .mo files do NOT translate

• Heading, paragraph, button text typed into Elementor widgets.
• Image captions, hover effects, accordion titles inside Divi modules.
• Content in reusable templates, global sections, saved blocks.
• Custom CSS labels or inline scripts inside builder widgets.

This is why theme authors' documentation about translation is technically correct but often useless for end users. Our guide on how to localize any WordPress theme covers the theme side thoroughly - this post picks up where that one ends.

Two Paths for Page Builder Localization

There are exactly two ways to translate page builder content, and both have real trade-offs.

Path One: Duplicate Pages per Language

Use a multilingual plugin like WPML, Polylang, or TranslatePress. It creates a copy of every page per language. In Elementor, you duplicate the entire layout and swap the text on each copy. In Divi, you copy the shortcode blob and translate the text between tags.

Pros: Each language can have independently designed layouts (useful when translated text is longer and breaks your original design). Full compatibility with the page builder's visual editor.

Cons: Linear scaling - 5 languages means 5x the layout work. Any design change has to be applied 5 times. Database grows fast. Caching gets harder.

Path Two: String Translation Layer

Some plugins (Polylang Pro, WPML's String Translation module, TranslatePress) can expose individual strings inside page builder widgets for translation, then swap them at render time. You maintain one layout and the plugin translates strings in place.

Pros: Single source of truth for layout. Design changes apply everywhere.

Cons: Lower flexibility when translated text changes length dramatically. Some widgets (complex ones with nested content, dynamic lists, forms) do not expose strings cleanly. Performance cost per render.

Our Polylang vs WPML vs TranslatePress comparison covers the trade-offs of each plugin in more detail.

Keeping Widget Markup Safe During Translation

Whichever path you pick, translated content must preserve the builder's structural markup. If your translator strips an Elementor shortcode, replaces a data attribute, or reorders nested tags, the widget renders broken.

Elementor Danger Zones

Elementor widgets embed shortcodes and dynamic tags inside text settings. A heading widget's title field may contain:

Welcome to <strong>our</strong> [user_name] store

That [user_name] is a dynamic tag - Elementor replaces it with the logged-in user's name at render. If translation mangles it, you get literal "[user_name]" displayed to users.

Icons inside buttons use class attributes that must not be translated. Image alt text is stored separately from the image URL. Column layouts use breakpoint-specific settings (title_mobile, title_tablet) that need individual handling.

Divi Shortcode Nesting

Divi shortcodes nest deeply: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. A translator that treats the blob as plain text will encode square brackets, translate attribute values, or lose closing tags. Any of these corrupts the module and Divi refuses to render it.

The Safe Pattern

For either builder, translation must:

1. Parse the widget format (JSON for Elementor, shortcode AST for Divi).
2. Walk the tree identifying only user-visible text fields.
3. Lock shortcodes, dynamic tags, HTML attributes, and inline CSS.
4. Send only the text surfaces to the translator with context.
5. Reinsert translated text into the original structure.

This is the same principle our engine applies to .po files. The guide to translating .po files without breaking code variables walks through the %s and placeholder patterns in detail - the page builder equivalent is shortcodes and dynamic tags.

A Hybrid Workflow That Actually Works

For most teams, the practical answer is combining both approaches.

Step 1: Translate Theme and Plugin UI via .po Files

Export .pot files from your theme and key plugins (WooCommerce, Yoast, page builder UI). Translate them once via a cloud translator that respects .po format. Drop compiled .mo files into wp-content/languages/. This handles 80% of your site's interface strings with near-zero ongoing maintenance.

Step 2: Pick a Multilingual Plugin for Dynamic Content

Install Polylang or WPML for post, page, and product content. Configure URL structure (/es/, /fr/) and hreflang tags. This gives you the infrastructure for per-language database content.

Step 3: Duplicate Your Page Builder Templates Selectively

For high-traffic landing pages, homepages, and cornerstone marketing content, duplicate the page in each language and translate the widgets manually. You get full design control where it matters.

Step 4: Use String Translation for Repeated Blocks

For global sections, reusable templates, and footer CTAs that appear on every page, use your multilingual plugin's string translation feature. Update in one place, swap at render.

Step 5: Run Quality Checks

Translated page builder content should render without layout shifts. Longer languages (German, Russian) break button widths. Shorter languages (Chinese, Japanese) leave awkward whitespace. Test each template per language before shipping.

Common Pitfalls and How to Avoid Them

A few traps that appear in every page builder localization project.

Image Alt Text Not Translating

Both Elementor and Divi store alt text per widget instance, not in the Media Library. Translating the original image does not translate alt text in every widget that uses it. Update alt text in each duplicated page.

Forms and Custom Fields

Contact forms embedded in page builder widgets have their own strings (labels, placeholders, validation messages). See our guide on translating Gravity Forms and Contact Form 7 for the form side.

Global Widgets and Templates

Changes to a global template propagate to every page using it, including translated copies. This can be useful or catastrophic depending on whether you want shared or separate content. Decide explicitly per template.

Translation Cache Expiration

Page builders cache rendered HTML aggressively. After translating, purge all caches including Elementor CSS cache (Elementor > Tools > Regenerate CSS) and Divi static CSS cache.

Putting It All Together

Translating a site built with Elementor or Divi is not harder than translating a static theme - it just requires the right mental model. Theme and plugin strings live in .po files and travel via .mo files. Page builder content lives in the database and travels via multilingual plugins or manual duplication. Mixing up the two paths is the single most common source of "why aren't my translations working" frustration.

The workflow that wins is boring: static .mo files for everything that lives in code, multilingual plugin for page content, and manual curation for high-value landing pages. No single tool handles all three, and anyone promising you otherwise is selling you something.

Ready to translate your theme and plugin .po files without breaking widget markup? Try SimplePoTranslate free - no credit card required. Upload .po, download safe translations, drop into wp-content/languages/.