How to Translate Elementor Pages with WPML
Using AI (Without Breaking Layouts)
Elementor stores content differently from the WordPress editor. Most translation tools miss half your page content. Here is how to translate every widget, section, and template without rebuilding anything.
Updated April 2026
Practical Tutorial

If you have ever tried translating an Elementor -built page through WPML, you have probably experienced the frustration firsthand. You set up the translation, run it through whatever method you are using, and the result is a broken page. Half the widgets show untranslated text. The layout shifts. Styling disappears. Sections that looked perfect in the original language are now empty or garbled in the translated version.
This is not a bug in WPML or Elementor. It is a structural problem. Elementor does not store page content in the standard WordPress content field the way the Gutenberg editor does. Instead, it saves everything as serialized JSON data in post meta fields. Every heading, every text editor widget, every button label, every testimonial, every pricing table entry lives inside a nested JSON structure that most translation tools either cannot parse or only partially understand.
This guide explains why Elementor translation is harder than regular post translation, what specifically goes wrong with most approaches, and how to translate Elementor pages through WPML using an AI addon that actually understands the Elementor data structure. We will use NEXU AI Auto Translator for WPML with full Elementor page builder support throughout the walkthrough because it is currently the only AI translation addon that handles Elementor’s JSON structure completely.
Why Elementor pages break during translation
To understand the problem, you need to understand how Elementor stores your content. When you build a page in Elementor, the visual layout you see in the editor gets saved as a structured JSON object in the _elementor_data post meta field. This JSON contains a hierarchical tree of sections, columns, and widgets. Each widget has a settings object that contains its text content, styling parameters, and configuration options all mixed together.
A simple Elementor heading widget might look something like this in the stored data: a widget type identifier, a settings object containing the heading text, the heading tag level (H1, H2, etc.), text alignment, color settings, typography settings, and responsive visibility rules. The translatable text (the heading itself) is buried inside this settings object alongside dozens of non-translatable configuration values.
Now multiply that complexity across every widget on a page. A typical Elementor landing page might contain 30 to 60 widgets: headings, text editors, icon lists, image boxes, testimonials, call-to-action sections, pricing tables, tabs, accordions, and more. Each one has translatable text fields nested inside configuration data that must not be modified during translation.
Many translation tools only translate what is in the main WordPress post content area. For Elementor pages, this field often contains a basic text fallback that does not match what the page actually renders. The real content is in the post meta. If a tool translates only the content field, the frontend page shows untranslated Elementor content because Elementor renders from its own data, not from the WordPress content field.
If a tool does attempt to parse Elementor’s JSON data, it needs to know which fields contain translatable text and which contain configuration values. Translating a color hex code, a CSS class name, or a link URL corrupts the page. A naive approach that translates every string value in the JSON will break styling, links, and widget functionality. The tool needs a whitelist of which settings keys contain human-readable text for each widget type.
Elementor widgets like Tabs, Accordion, Toggle, Price List, and Icon List use repeater fields where each item contains its own set of text fields. These are arrays of objects inside the widget settings. A translation tool that handles top-level widget text but misses repeater items will produce partially translated widgets: the main heading translates but individual tab titles, accordion items, or list entries stay in the original language.
WPML itself has built-in support for Elementor through its String Translation module. When you edit a translated page in WPML’s advanced translation editor, WPML does extract Elementor text fields individually. But this only works for manual translation or WPML’s own credit-based automatic translation. Third-party AI translation addons need their own Elementor parsing logic to achieve the same result through the API. Most do not have it. The ones that do treat it as a core feature rather than an afterthought.
How the NEXU plugin handles Elementor translation
The NEXU WPML AI translator with Elementor widget and template translation takes a different approach from tools that try to translate Elementor content by manipulating the raw JSON directly. Instead, it works through WPML’s own translation infrastructure, which already understands Elementor’s data structure.
When WPML creates a translation job for an Elementor page, it breaks the page content down into individual translatable fields: each heading, each text editor content, each button label, each testimonial quote, each tab title. These fields are presented as a flat list of source text and empty target text pairs. The NEXU plugin receives this list, sends each field (or groups of related fields) to the AI API for translation, and writes the translated text back into the correct target fields.
The critical advantage of this approach is that the JSON structure is never directly manipulated by the translation process. WPML handles the Elementor JSON parsing and reassembly. The plugin handles the actual translation. Each tool does what it is designed for. The result is a translated page that preserves the exact layout, styling, spacing, and widget configuration of the original.

Step-by-step: translating your first Elementor page
Assuming you have WPML and the NEXU plugin installed and configured with your AI API key, here is the process for translating an Elementor-built page.
Navigate to WPML, then Translation Management. In the content filter, find the Elementor page you want to translate. You can filter by post type (pages, posts, or custom post types) and search by title. Check the box next to your page.
Choose the languages you want to translate into. For each language, select the NEXU AI Translator as the assigned translator. This tells WPML to create a translation job that the plugin will automatically pick up and process through your connected AI provider.
Click “Send all translation jobs.” The plugin detects the new job, identifies all translatable Elementor fields through WPML’s infrastructure, and begins sending them to the AI API. For a typical landing page with 30 to 50 widgets, the translation takes two to five minutes per language depending on the AI model and content volume. Monitor progress on the plugin’s queue page.
Once the job completes, open the translated page in preview mode. Every Elementor widget should display translated text in the target language. The layout, spacing, colors, images, and interactive elements should be identical to the original. If you are translating into an RTL language, Elementor’s built-in RTL support should automatically adjust the layout direction.

Which Elementor widgets translate and which do not
Not every Elementor widget contains translatable content. Understanding which ones do helps you know what to expect from the translation output and where to focus your review efforts.
Widgets that are purely visual (images, spacers, dividers, decorative elements) do not contain translatable text and are passed through unchanged. The translated page uses the same images, the same spacing, and the same visual structure as the original. Only the text content changes, which is exactly what you want.
Translating Elementor templates, headers, and footers
Pages are just one part of the Elementor ecosystem. Most Elementor-built sites also use custom headers, footers, single post templates, archive templates, and popup templates. These are stored as separate post types in WordPress and need their own translations.
WPML handles Elementor templates through its Translation Management module. The templates appear in the translation dashboard alongside regular posts and pages. You translate them the same way: select the template, choose target languages, assign the AI translator, and send the job. The NEXU plugin’s Elementor template translation feature for WPML multilingual sites processes these template translation jobs identically to page translation jobs.
The one thing to be aware of is translation order. Translate your header and footer templates before translating individual pages. This ensures that when someone visits a translated page, the entire experience, including navigation, footer content, and any template-level content, appears in the correct language. If you translate pages first but not templates, visitors see a translated page body with an untranslated header and footer, which looks unprofessional.
Start with global templates (header, footer), then translate your most important pages (homepage, main landing pages), then WooCommerce templates if applicable, then individual posts and product pages. This way, as each translated page goes live, the full experience is already translated. WPML’s language switcher in your header will also display correctly once the header template is translated.
RTL language support for Elementor pages
If you are translating into Arabic, Persian, Hebrew, or any other right-to-left language, Elementor has built-in RTL support that automatically mirrors the layout when the page is viewed in an RTL language. Text alignment flips, column order reverses, and margins adjust to create a proper RTL reading experience.
The AI translation process does not need to handle RTL conversion. It only translates the text content. Elementor and WPML handle the layout direction change automatically based on the target language. This means your translated Arabic or Persian page will not only have properly translated text but also the correct right-to-left layout that readers of those languages expect.
One thing to watch for: some custom CSS that you may have added to Elementor widgets might use directional properties (like margin-left, padding-right, or text-align: left) that do not automatically flip in RTL mode. If your translated RTL pages show minor alignment issues, check your custom CSS for hardcoded directional values and replace them with logical properties or RTL-aware alternatives.

Common issues and how to fix them
Even with a proper Elementor-aware translation workflow, you may encounter some situations that need attention. Here are the ones we see most often and how to resolve them.
This usually means the translated page exists in WPML but the Elementor data was not properly synced. Go to the translated page in WordPress admin, open it in Elementor, and then close it without making changes. This forces Elementor to regenerate its CSS and sync its data. If the issue persists, delete the translation in WPML and re-create the translation job.
Check whether the untranslated widgets are from third-party Elementor addons (like Essential Addons, JetEngine, or Crocoblock). WPML and the translation plugin can only translate widgets that are properly registered with WPML’s string translation system. If a third-party widget is not registered, its text will not appear in the translation job. Contact the addon developer to request WPML compatibility, or translate those specific strings manually through WPML’s String Translation interface.
Different languages produce different text lengths. German text is typically 20 to 30 percent longer than English. Japanese text is significantly shorter. If your Elementor layout uses fixed heights or very tight spacing, longer translations may overflow containers or shorter translations may leave visible gaps. The fix is to use flexible height settings in Elementor (min-height instead of fixed height) and set adequate padding. This is a design consideration, not a translation issue.
Elementor popups are a separate post type. Make sure WPML is configured to translate the Elementor popup post type (check WPML Settings, then Post Types Translation). Once the post type is enabled for translation, popups will appear in Translation Management alongside your other content and can be translated through the same AI-powered workflow.

Translate your Elementor site without rebuilding a single page
The combination of WPML’s Elementor integration and an AI translation addon that works through WPML’s infrastructure means you can take an entire Elementor-built website and make it fully multilingual without opening the Elementor editor in a translated page even once. Every widget, every template, every popup gets translated through the automated workflow while preserving the exact design you built.
This is what makes the approach practical for real-world sites. An Elementor landing page that took you eight hours to design and build can be translated into five languages in twenty minutes of setup time. The design work is done once. The translations happen automatically. Updates to the original page can be retranslated with a single click through the NEXU WPML AI re-translation tools for Elementor pages and templates.
If you have been avoiding making your Elementor site multilingual because of the layout-breaking problems or the sheer amount of manual work involved, this workflow eliminates both barriers. Your pages translate cleanly, your layouts stay intact, and the whole process runs in the background while you work on other things.
Translate every Elementor widget without touching the editor
Full Elementor JSON parsing. Templates, headers, footers, popups. RTL support. Four AI providers. Automatic background processing. Your layouts stay perfect in every language.

Took me three tries with other guides to finally get full translations without messing up my layouts.
Hey everyone, I've gotta be honest I'm pretty let down by this guide. I really thought it would finally fix my issues with translating Elementor pages, but nope. i followed every single step exactly as written, and I'm still stuck with half my widgets showing up in the original language.
This guide saved me hours of frustration trying to translate an Elementor site for a bilingual client. I'd used WPML before, but Elementor's JSON storage always wrecked my layouts half the text stayed in English, widgets shifted everywhere, and some sections just disappeared. The step by step breakdown here finally explained why that happens and how to fix it