WPML Only Part of Page Translated: Why It Happens and How to Fix It

You switch to the translated version of a page, expecting a finished experience—then a heading, button, product detail, or entire section is still sitting there in the original language. The frustrating part is that wpml only part of page translated is rarely one simple error. A page can look fully translated inside the editor while its visible output pulls text from several different places.

That leftover source-language text may belong to an incomplete translation job, a custom field WPML was never told to translate, a page-builder module, a theme template, or even an old cached version of the page. Treating every untranslated fragment as the same problem can turn a quick fix into hours of guesswork.

The clue is usually hiding in where the untranslated text appears and how it was added to the site. Once you identify the layer responsible, the right fix becomes much clearer—and you can stop chasing translations that were never missing in the first place.

First, Identify Exactly What WPML Did Not Translate

When WPML only part of page translated, the missing words are often not missing from WPML at all. They may belong to a template, custom field, or cached version of the page. The fastest fix starts with locating the text’s real source before opening another translation job.

Check whether the untranslated text is inside the page editor

Open the original page and search for the exact sentence, heading, or button label that remains untranslated. Then open its translated version through WPML’s Translation Editor, or the relevant page editor if the site uses an editor-based translation workflow. If the text appears in the original but was not included in the translation job, update the original page, mark the translation as needing an update, and re-open the job.

Also check custom fields. Content stored in ACF fields, SEO fields, excerpts, or builder-specific fields may need separate WPML translation settings. Editing the visible translated page will not help if the source field was never sent for translation.

Look for content coming from templates, widgets, and global sections

A page can look like one document while being assembled from several WordPress items. Headers, footers, reusable blocks, widget areas, Elementor templates, Bricks templates, and global sections are commonly translated separately. If every page shows the same untranslated call-to-action, for example, the problem is almost certainly the global template rather than each page translation.

Find the template or reusable element that produces the text, then translate that item in WPML. This distinction prevents the classic waste of repeatedly re-translating a page whose body content is already complete.

Rule out a caching or language-switching display problem

Before changing settings, clear the WordPress cache, your hosting cache, CDN cache, and browser cache. Then open the translated URL in a private window. A stale cached page can display yesterday’s translation even when WPML has the current version stored correctly. Test the direct translated URL as well as the language switcher; if one works and the other does not, the issue may be routing, redirection, or cache configuration rather than translation content.

Fix the Most Common Reasons Only Part of a WPML Page Is Translated

A page can look 90% translated and still fail where it matters most: the call to action, a product specification, or the text inside a reusable builder block. When you see wpml only part of page translated, do not assume the translation itself is broken. Usually, the missing text lives somewhere different from the main page body.

Complete or resend an unfinished translation job

WPML treats a translation job as a set of individual fields. If a translator skipped one field, left it incomplete, or the original page changed after the job was created, the translated version can show gaps. Update the original page first, then reopen the job in WPML’s Translation Management or translation editor. Translate every required field, confirm completion, and save. If the source content was substantially revised, resend the page rather than trying to patch an outdated job.

Set custom fields and ACF fields to translate

Text stored in custom fields is a frequent culprit because it is not necessarily part of the editor content. In WPML’s Custom Fields Translation settings, set the relevant field to Translate, not Copy or Don’t translate. For Advanced Custom Fields, review the field group as well as repeaters, flexible-content layouts, and nested subfields. Save the setting, update the original page, and retest with a fresh translation job.

Configure the page builder integration

Elementor, Divi, Bricks, and other builders may store content in modules, templates, or reusable elements rather than the page itself. Confirm that your builder is WPML-compatible and that any required integration plugin is active. Then translate global sections, headers, popups, templates, and reusable blocks separately; translating the parent page alone often is not enough.

Translate strings from the theme or another plugin

Buttons, notices, form labels, and template text may belong in WPML String Translation instead of the page translation editor. Identify the responsible theme or plugin text domain, scan it when appropriate, locate the original string, and add or complete its translation. Hard-coded template text will not appear in a page job simply because it appears on that page.

Handle Special Content Types That Commonly Get Missed

Translate menus, media, and linked content

A page can be 100% translated in the editor and still look unfinished to visitors. Navigation labels, featured-image text, captions, alt text, and related-post links often sit outside the page’s main translation job. That is a common reason for the wpml only part of page translated problem.

Check each menu in WPML’s menu synchronization tools, then confirm that linked pages, posts, and products have translations assigned in the target language. Review media separately as well: an image may display correctly while its attachment title, caption, or alternative text remains in the original language. A “Read more” card that links to an untranslated post is not a styling bug; it is a missing language association.

Check WooCommerce and dynamic plugin content

Commerce pages are especially deceptive because much of what shoppers see is generated elsewhere. Product tabs, attributes, variation labels, checkout fields, filter widgets, and account-area text may be controlled by WooCommerce or an extension rather than the page builder.

Identify which plugin owns the untranslated element before changing anything. Then follow that plugin’s documented WPML compatibility workflow, including any required string-translation, taxonomy, or product-translation settings. For sites already using WPML, LATW AI Translator for WPML can speed up page, product, metadata, and string translation through WPML’s workflow, but WPML remains the required multilingual framework and each compatible extension still needs proper configuration.

Review shortcodes, dynamic tags, and external embeds

Shortcodes can hide the real source of the problem. A shortcode may reference an original-language post ID, pull a default-language option from plugin settings, or output text supplied by a third-party service. Dynamic tags have the same weakness: they are only as multilingual as the data they retrieve.

Test the shortcode on its own in the target language. Check its settings, referenced IDs, and any custom fields, then consult the plugin’s documentation for WPML support. For external maps, forms, booking widgets, or video embeds, translation may need to happen in the external platform—not in WordPress at all.

Verify the Fix and Prevent Partial WPML Translations Going Forward

Run a front-end QA check in every language

A translation can look complete in the WPML editor and still fail where visitors actually see it. When wpml only part of page translated is the symptom, test the published URL rather than trusting the editing screen alone. Open each target language in a private browser window, clear any page cache, and check both desktop and mobile views.

• Page body, including accordions, tabs, pop-ups, and dynamically loaded sections
• Global headers, footers, templates, forms, buttons, and menus
• SEO title, meta description, slug, social fields, and canonical language URLs
• Media alt text, captions, image-based text, and embedded video labels
• Internal links, especially links inside reusable blocks and builder components

This takes minutes on a landing page and can prevent weeks of lost conversions caused by one untranslated “Buy now” button.

Treat source changes as translation changes

WPML cannot translate content that did not exist when the translation was completed. A newly added source-language block, revised ACF field, or edited Elementor or Bricks component can leave an older translation marked incomplete or simply out of date. Build a simple publishing rule: whenever the original page changes, flag its translations, update them promptly, then repeat the front-end check. This is especially important for global templates, where one edit may affect dozens of pages.

Reduce translation cost without leaving WPML

If your site already relies on WPML, LATW AI Translator for WPML is an optional add-on that works inside WPML’s existing translation workflow; it is not a standalone multilingual plugin. WPML continues to manage languages, URLs, and translation relationships, while LATW can translate page content, metadata, SEO fields, taxonomies, ACF fields, and WPML strings using your own supported AI or translation-provider API key.

That BYOK approach avoids relying solely on costly credit bundles and sends content directly from WordPress to the selected provider. It can speed up bulk work, but automation is not permission to skip review: dynamic widgets, conditional content, and template-based sections still deserve a human check before publishing.

Make Translation QA Part of Your Publishing Workflow

When WPML only part of page translated appears to be the problem, the real cause is usually that different pieces of the page come from different places: the editor, a page builder, a template, custom fields, widgets, or string translation. Treat the page as a set of sources rather than a single block of text. Find where the untranslated text originates, translate it in the matching WPML workflow, clear every relevant cache, and then check the live page in each language.

That final front-end check matters after every meaningful content, template, or plugin update. It catches the gaps your editor view cannot always reveal and turns multilingual maintenance into a repeatable process instead of a last-minute repair. A translated page is not finished when the job says complete; it is finished when every visitor can read it as intended.