WPML 如何為不同語言版本建立不同的 Elementor 版面

You translate an Elementor landing page, open the French version, move a section and change the button. It looks right. Then someone updates the English page or sends it through translation again, and the French design comes back looking like the original.

The missing decision is usually who owns the translated layout. Are you asking WPML to rebuild a translated version of the source, or are you maintaining a separate Elementor design that happens to be connected to it as a translation?

This guide walks through that decision and the practical setup. We built an English–French demonstration in the permanent Lumo Tutorial Lab, created a duplicate through WPML, made it independent, and saved a different French layout. We then saved an Elementor change on the English source and checked that the French layout data stayed unchanged.

The short answer: choose WordPress Editor for the specific source page, create or open its language version, and use Translate independently if it is still a synchronized duplicate. Then edit the target-language page with Elementor. Keep that page out of source-driven retranslation unless you deliberately want to rebuild it from the source again.

Illustrated comparison based on real lab captures. English original · French original

First, choose the workflow you actually need

An English page and a French page do not need separate designs just because their sentences have different lengths. Sometimes a flexible container and sensible responsive typography solve the problem. Separate layouts make sense when the structure or content genuinely needs to change: a different hero, a local contact route, a different section order, or an offer that needs a different explanation.

Here is the distinction to settle before clicking a translation icon.

The important comparison is not “automatic translation versus good design.” A site can use source-based translation for ordinary pages and independent design for a small number of landing pages. Make the exception deliberate and record it.

WPML's current design-per-language guide identifies manual editing as the route for different layouts and warns that translation-editor or automatic-translation processing can replace a customized design. The warning concerns the page's editing workflow; it is not a reason to disable WPML across the whole site.

What we tested, and what the screenshots show

The working example uses WordPress 7.1.3, WPML Multilingual CMS 4.7.4, WPML String Translation and Elementor Free 4.2.0. These are the installed versions used for this test, not a claim that they are the newest releases. Research was checked on 21 October 2026.

Our English page has a split hero and three cards. The French version has a centered hero, a wide explanatory section and a separate contact prompt. Both belong to the same WPML translation group. The difference is visible in the page structure, not just in the words.

The lab has no real customer data or live payment flow. We did not connect WPML's cloud translation editor, spend translation credits, or run an AI translation request. The tested result is specifically about manual Elementor editing and a subsequent source-page save.

The instructional banners use enlarged, annotated views of real lab captures. Original captures were retained. The cover is a conceptual illustration. Labels and screen positions can differ between WPML releases; use the control names and the state checks below rather than relying only on where a button sits.

Before editing an existing translated page

If the page already contains work you want to keep, begin with a backup that includes the database. Elementor layouts are stored in post metadata; a copy of the visible text alone does not preserve the layout. Keep a reference screenshot of both languages too.

Check whether a translation job for this page is still running or awaiting completion. Settle that job before changing ownership of the layout. A translator completing an older source-based job later is exactly the kind of event you want to avoid after redesigning a manual version. Review the individual job in WPML instead of cancelling unrelated work in bulk.

Write down the source page title, its language, the target language and the intended change. “French landing page: centered hero, shorter introduction, local enquiry button” is a useful brief. “Make French different” gives the next editor very little to work with.

If you have not configured WPML yet, follow our WPML installation and setup walkthrough first. This article starts with working languages and a page that already opens correctly in Elementor.

Step 1: open the source page in the normal WordPress editor

Go to Pages → All Pages and find the original page. Use its ordinary Edit action first. Do not begin inside the Elementor canvas: the choice of translation editor lives in WPML's Language box on the WordPress editing screen.

Confirm the language before changing anything. In our example, the source record is page 86, in English. The French copy later receives its own ID, 93. Your IDs will be different. The title in the top bar and the language in WPML should agree with the version you intend to edit.

If the Language box is not visible, open the document settings sidebar and scroll within it. Depending on the editing screen, meta boxes may appear below the content instead. Also check the editor's panel preferences before assuming that WPML has lost the page's language information.

Inside Translate this Document, choose WordPress Editor. This tells WPML to use the native page-editing workflow. It does not mean you must rebuild an Elementor page using Gutenberg blocks; you can still use Edit with Elementor on the resulting language version.

Step 2: apply the change to only this page

WPML asks how broadly to apply the editor choice. Select Only this page, then Apply. Do not choose all pages or the site's entire content merely to solve one landing-page requirement.

Enlarged guide to the scope dialog. Original lab screenshot

In the tested source, the per-page editor preference is resolved against the original page in the translation group. Treat this as a workflow decision for that page and its translations, not as an isolated font setting for one French widget. If several translators maintain the other languages of the same page, tell them about the change.

After applying it, verify that WordPress Editor remains selected and that the target-language translation link opens the native editing route. A translation icon can look similar while leading to a different editor, so check where you actually land.

Checkpoint: you changed a single page's editing workflow. You did not change the global translation method, the default language, or every page on the site.

Step 3: choose a blank translation or a copy of the source

You now have two starting points. They solve different amounts of design work, but both should end as an independently maintained target page.

Route A: start from a blank target-language page

Use the plus icon beside the target language in the source page's Language box. With the native editor selected, this opens a new language-version draft. Give it an appropriate title, confirm its language and source relationship, and save it.

Open that new page with Elementor and build its layout using the normal widgets and responsive controls. This route is useful when very little of the source design should survive. It also avoids bringing across demo sections you would immediately remove.

Check the page layout setting before you start. A canvas page and a page using the theme's ordinary layout do not display the same surrounding header and footer. Choose intentionally; a missing header on a Canvas page is not evidence that the translation has broken.

Route B: duplicate first, then customize

This is the route we exercised in the lab. On the source page, tick Duplicate beside French, then click the Duplicate button. Once WPML finishes, open the French version using its edit/pencil link.

Enlarged guide to the Duplicate controls. Original lab screenshot

At this point the page looks like a useful starting copy. It is also still a duplicate maintained by WPML. That second fact matters more than how the page looks. Do not spend an hour redesigning it while leaving it in that state.

Checkpoint: the target language has its own page record, and you know whether it is a blank translation or a synchronized duplicate. A copied layout is only the starting point.

Step 4: make a duplicate independent before redesigning it

On the target page's normal WordPress edit screen, inspect the Language box. If it says that the document is a duplicate maintained by WPML, click Translate independently. Wait for the action to finish before continuing.

Enlarged guide to independent editing. Original lab screenshot

Reload the editing screen and check the state again. The maintained-duplicate message should no longer be the page's active state. In our test, the French page's duplicate marker changed from source ID 86 to an empty value, while its WPML translation-group relationship remained intact.

That distinction is easy to miss: independent editing does not mean an unrelated page. We still want WPML to know that English and French are language versions of the same content. We are stopping duplicate synchronization, not removing the language connection.

If the target is already a normal independent translation, you may not see this button. That is not automatically an error. Check its current relationship and editor choice instead of duplicating it again. Creating another French page is not a repair for a button that is correctly absent.

The older WPML manual Elementor walkthrough also documents this duplicate-to-independent transition. Its account-specific scope differs from the current general guide; the duplicate warning in your installed interface is the practical state to check.

Step 5: edit the target-language page with Elementor

From the independent target page, click Edit with Elementor. Read the page title in Elementor's top bar before making the first change. In our example it is Northline — Mise en page française, not the English source title.

Start with one visible difference. Change the hero alignment, replace the introduction, or move a section. Save, open the French frontend, and confirm that the change appears on the French URL. Then open English and confirm that you did not accidentally edit its page record.

Annotated guide based on the French Elementor editor. Original lab screenshot

For our demonstration, we changed the French hero to a centered arrangement and replaced the three-card sequence with two wider sections. We used Elementor's native layout, alignment, typography, spacing and button controls. There was no custom design CSS and no change to Elementor or WPML's source files.

Work through content that a translator might not notice in a headline-only review:

• The button's text, destination and anchor must make sense in the target language.
• A replaced section may need a new heading hierarchy and different spacing.
• Image captions, alternative text and text inside graphics need separate review.
• A form's labels can be translated while its recipient, confirmation or error messages still need checking.
• A product link or contact link can lead to the source language even when the surrounding paragraph is correct.

Be especially careful with dynamic widgets. Changing a translated page's static heading does not automatically translate the products, categories, saved templates or custom-field records that another widget queries. Inspect the actual output and the language relationship of those dependencies.

Step 6: test the page on mobile, in its own language

Use Elementor's responsive controls, then inspect the real frontend at a narrow width. Text wrapping, button size and section order need to be judged with the translated text in place. A layout that worked with a short English phrase may need different spacing with the final French wording.

Illustrated phone frame based on the narrow-viewport capture. Original mobile screenshot

Our French frontend was inspected at a roughly 390-pixel mobile viewport without horizontal page overflow. That is a layout check, not a performance benchmark or a guarantee about every device.

Check the longest heading and the longest button label. Tap the primary action. If you have a form, submit a controlled test and inspect the received language and destination. The demonstration's button is an in-page anchor, so we did not represent it as a tested enquiry submission.

For Arabic, Persian or another right-to-left language, also inspect reading direction, icon placement and the ordering of related elements. Avoid forcing a whole page into a direction just to fix one mixed-language label. Use the theme and builder's supported controls and test numbers, email addresses and short Latin strings where they appear.

Step 7: prove that the layout stays independent

Do this on staging before handing the page to a client. Save a recognizable design change on the target page. Capture it, then make a small ordinary change on the source page and save that source page with Elementor.

Open the target again. It should retain the design you intentionally gave it. This is more useful than assuming independence because a checkbox looked correct earlier.

Our lab check used these records and produced the following result:

Matching hashes demonstrate that this source save did not rewrite the stored French layout in this test. They do not prove that a future bulk translation job, another plugin or a manual overwrite can never change it. We did not execute an Advanced Translation Editor job as part of this check.

Give the page an owner and a maintenance note: “Manual French layout; update in Elementor; review separately after source changes.” An independent page gains freedom and also gains a separate review obligation. A new feature added to English will not design or translate its French explanation for you.

What the WPML source code tells us

Conceptual diagram: editor ownership and duplicate synchronization are separate decisions.

We reviewed the installed 4.7.4 source to understand the states behind the interface. These are implementation observations for that version, not instructions to edit WPML's files or a promise that private metadata names will never change.

1. Editor choice and duplicate status are different controls

In classes/post-edit-screen/class-wpml-tm-post-edit-tm-editor-mode.php, WPML checks the original page's _wpml_post_translation_editor_native preference before falling back to broader post-type and global settings. In that implementation, yes selects the native editor and no selects the translation editor.

This is why “Only this page” is worth choosing carefully. It is a scoped editing preference, not a command that rewrites the whole site's translation configuration.

The duplicate relationship is represented separately. In classes/class-wpml-translate-independently.php, the action behind the independent-editing control removes this marker:

delete_post_meta( $post_id, '_icl_lang_duplicate_of' );

That line explains what we observed in the test: stopping synchronization did not require deleting the French page or disconnecting its translation group. Use the UI for the real operation; do not replace it with an unguarded database update.

2. Elementor layout is structured data

In addons/wpml-page-builders/classes/Integrations/Elementor/class-wpml-elementor-data-settings.php, the integration identifies Elementor's layout field:

const META_KEY_DATA = '_elementor_data';

The layout is a tree of containers, widgets and settings, not merely the text visible in the WordPress content editor. A process that rebuilds a translation from the source tree can bring back the source arrangement along with translated strings. Directly changing the target's JSON is not the normal editing workflow; Elementor should save its own document.

This also explains why changing the translation policy of every Elementor custom field is a poor first response. You would be altering shared integration behavior to solve one page's requirement. Check editor ownership, duplicate state and the actual target record first.

3. The public copy API makes the distinction explicit

WPML's documented wpml_copy_post_to_language filter accepts a third argument that determines whether the copy is marked as a duplicate. The installed hook implementation removes the duplicate marker when that argument is false.

This is useful background for developers automating imports. It is not an instruction to run the copy filter repeatedly on an existing redesigned translation: a copy operation is a write, and an existing target must be identified and protected first. The UI procedure above is enough for this tutorial.

Optional: audit the relationship without changing it

For a developer handoff, the following PHP file can be run with WP-CLI on staging. Replace the example IDs with your own. It reads language relationships and layout fingerprints; it does not create translations, change editor settings, or remove metadata.

<?php
// Run with: wp eval-file wpml-layout-audit.php
// Read-only. Replace these IDs with the two pages being checked.
$source_id = 86;
$target_id = 93;

if ( ! defined( 'ICL_SITEPRESS_VERSION' ) ) {
    throw new RuntimeException( 'WPML must be active.' );
}

$report = [];
foreach ( [ $source_id, $target_id ] as $id ) {
    $details = apply_filters( 'wpml_element_language_details', null, [
        'element_id'   => $id,
        'element_type' => 'post_page',
    ] );
    $layout = (string) get_post_meta( $id, '_elementor_data', true );
    $report[ $id ] = [
        'language'     => $details->language_code ?? null,
        'trid'         => $details->trid ?? null,
        'duplicate_of' => get_post_meta( $id, '_icl_lang_duplicate_of', true ),
        'has_layout'   => $layout !== '',
        'layout_hash'  => $layout === '' ? null : hash( 'sha256', $layout ),
    ];
}
$report['source_native_editor_flag'] = get_post_meta(
    $source_id, '_wpml_post_translation_editor_native', true
);
echo wp_json_encode( $report, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES );

The language details use WPML's documented retrieval hook. The two metadata flags are version-specific implementation details, so confirm them against the version you are inspecting. An empty per-page editor flag can mean that WPML is using a broader setting; it does not, by itself, prove which editor is effective.

To repeat our check, save the report before and after a controlled source edit and compare the target's hash. A different hash tells you that something changed; it does not identify the writer. Investigate the exact save, job or plugin responsible before assigning a cause.

What about different headers, footers and Theme Builder templates?

A page's body and the template around it are separate problems. Editing the French page's hero does not automatically produce a French header or a different single-post template. Global fonts, site settings and reusable components also remain shared dependencies unless their own workflow provides an appropriate language-specific version.

For Elementor Pro Theme Builder, WPML's separate-template procedure sets display conditions on the original-language template, creates the secondary-language template without another set of conditions, and then connects the templates as translations from the original template's Language box.

Follow that procedure for the relevant template type and verify its frontend assignment. It is a Pro-specific documented workflow; our page-body demonstration used Elementor Free and did not test a Pro header/footer assignment. Third-party theme builders have their own condition systems and should not automatically inherit this recipe.

Keep the distinction visible during troubleshooting: wrong content inside the page points you toward its translation record; a wrong header or footer can point toward a template relationship or display condition instead.

Where Lumo WPML AI Translation fits—and where to keep manual control

If your other pages should retain the same arrangement, Lumo AI Translation Addon for WPML is a relevant option for the translation work. It is a Lumo product, separate from WPML's official add-ons. It should not be presented as a tool that automatically invents a different layout for each audience.

We also reviewed the local 3.20.28 source. In the Elementor-handling branch of includes/class-ai-processor.php, it reads the original page's Elementor data, applies translated widget fields and writes the resulting data to the target. There is also a fallback that copies the original structure when no extracted widget translations are available in that branch.

The practical implication is straightforward: do not assume retranslation preserves a manually rearranged target layout. Use source-based translation where matching structure is wanted. If you use AI to prepare the first translation before redesigning, review the result, establish the manual workflow, and keep that customized page out of later source-based processing unless you intend the structural replacement.

That is a source-code observation, not a claim that we ran a paid AI request in this lab. For a broader look at the translation workflow, see our AI translation with WPML tutorial.

Troubleshooting: diagnose the state before changing the settings

My layout goes back after someone translates the page again

Check whether the affected page is still being opened or processed through a source-based translation workflow. Confirm the per-page editor choice and review any outstanding jobs. Restore the intended target layout from a suitable revision or backup after settling the writer that replaced it. Merely clearing a browser cache will not recover a layout whose stored data was overwritten.

I can still see the maintained-duplicate message

You have not reached the independent state yet. Use Translate independently on the target page, wait for completion and reload. If the control fails, inspect the response and permissions; do not repeatedly duplicate the page. Our WPML troubleshooting guide covers broader language and translation failures.

Elementor looks right, but the frontend shows the old design

First check the URL, language and page ID. If the correct document is saved but old styling remains, use Elementor's supported Clear Files & Data tool and clear the relevant page caches before retesting. Elementor's official cache guidance documents that operation. It addresses generated assets; it does not make a synchronized duplicate independent.

The layout is independent, but an image or link is still wrong

Inspect the widget's actual source. A dynamic image may come from a related product or custom field, a button may contain a literal source-language URL, and a reusable template may need its own translation. Editing the surrounding paragraph does not correct those references. Test the rendered link destination rather than only the label in the editor.

I expected the next English change to appear in French

Independent layouts require manual maintenance. Decide which changes are relevant, update the French page deliberately and test it again. If the pages should always mirror each other, reconsider whether separate manual layouts were necessary. Do not switch back and run a translation job casually after investing in a custom target design.

Final checks before you publish the language version

Check the normal frontend, not only Elementor's preview. Both language versions should open, the switcher should connect the intended pair, and every important action should lead to the right language or destination.

• Confirm the target page is published and is still connected to the intended source.
• Check headings, text direction, mobile spacing, images, alternative text and local contact details.
• Review reused templates, forms and dynamic content separately.
• Verify the target's title, description and translated URL where your SEO setup provides them.
• Inspect language annotations and canonical output on the real pages. Do not canonicalize an ordinary translated French page to English simply because English is the source.
• Repeat the controlled source-save check and record who maintains each manual version.

Google's localized-version guidance explains how language alternatives are connected, while its canonical guidance calls for an appropriate same-language canonical when using language annotations. These are output checks, not a promise that a different layout improves rankings.

The useful end state is simple: visitors get a page designed for their language, WPML still knows which pages belong together, and editors know exactly which workflow is allowed to change each layout. Set that ownership first. The Elementor design work becomes much easier to maintain afterward.