Common WPML Plugin Issues & Solutions

Running a multilingual WordPress site with WPML can be powerful, but it is also complex. Based on real support cases from the WPML support forum, users repeatedly encounter similar problems across page builders, custom fields, translations, SEO, performance, language routing, and more.

This guide will explain those issues step-by-step, so you can recognize symptoms early, understand what’s actually happening behind the scenes, and apply proven fixes that will work for you.

1. Page Builder Settings Sync Across Languages (Elementor / WPBakery)

Detection:

• Editing a page in one language automatically changes the content or settings in another language.
• Custom fields inside Elementor widgets display the same value across languages.
• WPBakery pages can only be edited in the default language when WPML is active.

Causes:

WPML supports translating content created with compatible page builders, including Elementor. In a standard translation workflow, the original page’s structure is retained while translatable content is translated into other languages.

This is useful when you want the same design across all language versions. However, problems may occur when:

• A custom page-builder widget contains fields that WPML cannot identify for translation.
• The page uses dynamic content from custom fields with incorrect translation preferences.
• A user tries to maintain an independent translated design while continuing to use WPML’s standard translation workflow.
• A third-party widget or page-builder addon has incomplete WPML compatibility.

For Elementor, WPML supports translating widget content, links, images, templates, and other supported elements through its translation workflow.

Solution:

• Switch the affected page or template to manual translation mode.
• Edit each language version directly using the page builder.
• Avoid using the Translation Editor for pages built with complex widgets.
• Re-save both the original and translated versions after changes.

2. ACF Custom Fields Not Translating or Displaying Correctly

Detection:

• ACF fields appear in the translation editor but not on the frontend.
• Fields translate correctly in one language but not in another.
• Old values continue to appear after updating translations.
• Some fields are completely missing in certain languages.

Causes:

When using Advanced Custom Fields (ACF) with WPML, field translation behavior depends on the settings configured through Advanced Custom Fields Multilingual (ACFML).

ACFML supports four translation preferences:

Preference	How it works
Translate	The field value is translated for each language.
Copy	The original field value is synchronized across languages.
Copy once	The original value is copied initially and can then be edited separately in each language.
Don’t translate	The field is not automatically translated or copied.

For example, a text field containing a product description generally needs the Translate preference, while a field containing a shared numeric value may use Copy.

Problems can occur when a text field is set to Copy, a required field is excluded from translation, or a translation has not been updated after changing field preferences.

Solution:

• Make sure the Advanced Custom Fields Multilingual addon is installed and active alongside ACF and WPML.
• ACFML provides options for maintaining the same content structure across languages or allowing different content in each language.
• Use the recommended settings for the relevant field types. For advanced requirements, ACFML’s Expert mode allows more precise control.
• If a field preference changes, the existing translation may need to be updated for the new configuration to take effect.
• If the translated value is correct in the editor but outdated on the frontend, clear the page cache, hosting cache, or CDN cache as applicable.

3. Translated Pages Redirect or Don’t Load Correctly

Detection:

• Translated pages redirect to the default language.
• Homepage translation loads the wrong URL.
• Translation icons switch between plus, pencil, and circular arrows.

• Pages appear translated, but are inaccessible.

Causes:

• The translated page is still a draft or pending translation.
• The translation job has not been completed.
• The translated page’s URL or permalink configuration is incorrect.
• A redirect plugin or server rule overrides the expected language URL.
• Browser-language redirection changes the page visitors initially open.

Solution:

• Go to WPML > Translations and locate the affected page. Confirm that its translation is completed.
• Open the translated page in the WordPress admin and confirm that it is published.
• Go to WPML > Settings > URLs and SEO and check the configured language URL format.
• If the issue occurs only for certain visitors or browsers, review the visitor-language options in WPML’s settings.
• Check whether your SEO, redirection, security, or caching plugins have rules that affect the translated URL.
• If the translation is incomplete or stuck, review the relevant job status before attempting to restart it. Do not cancel completed translation jobs without understanding the effect.

4. Broken URLs 

Detection:

• Language URLs lead to “Page not found” errors.
• Switching languages results in incorrect domain or subdirectory URLs.
• Translated pages load without images or broken layouts.

Causes:

WPML supports three main language URL formats:

• Directories: example.com/fr/
• Different domains or subdomains: example.fr or fr.example.com
• URL parameters: example.com/?lang=fr

Different URL formats have different server requirements.

For example, directory-based language URLs require a compatible permalink and rewrite configuration. Different domains require appropriate DNS and web-server settings.

Broken URLs can result from incorrect rewrite rules, unsuitable server configuration, migration-related URL changes, or caching.

Solution:

• Go to Settings > Permalinks and click Save Changes without changing the structure. This refreshes WordPress rewrite rules.

• Clear WPML caches under WPML > Support > Troubleshooting.

• Check server requirements. If you use language directories, ensure that your web server supports the required rewrite configuration.
• Review domain configuration, if different domains or subdomains are used for languages, verify that their DNS, SSL certificates, and server configuration are correct.

5. Search Filters and Dynamic Content Not Working in Translated Pages

Detection:

• Search or product filters work in the default language but not in translated languages.
• AJAX-powered filters return unexpected or empty results.
• Dropdown filters display untranslated options.
• Dynamic content loads from the wrong language.

Causes:

WPML provides a language cookie to help supported themes and plugins identify the current language during frontend AJAX requests.

According to WPML documentation, the option to store a language cookie for AJAX filtering has been enabled by default since WPML 4.5, although it can still be changed.

Other possible causes include missing translations of the filtered content, untranslated taxonomy terms, or incomplete compatibility between WPML and the filtering plugin.

Solution:

• Check AJAX language filtering by navigating to WPML > Settings > Compatibility and look for Store a language cookie to support language filtering for AJAX. Confirm that the setting is appropriate for the plugin you are using.
• Check translated content. Make sure the posts, products, categories, or taxonomy terms required by the filter are translated and published.
• Check whether the problem occurs with all filters or only specific ones.
• Review the filtering plugin’s documentation for WPML integration and supported multilingual configurations.
• Inspect AJAX requests when necessary. Developers can use browser developer tools to check whether the correct language is being passed and whether the request returns valid results.

6. SEO Issues with Browser Language Redirect

Detection:

• SEO tools report language URL or hreflang-related issues.
• Visitors are redirected to a different language based on their browser settings.
• Website crawlers receive unexpected redirects.
• Performance testing tools report additional page loads caused by language redirects.

Causes:

WPML can detect a visitor’s preferred browser language and respond according to the site’s visitor-language settings. The available options include:

• Keep visitors on the page they opened.
• Display a language suggestion bar.
• Automatically redirect visitors to the corresponding language.

WPML’s documentation explains that automatic browser-language redirects can affect how Google indexes the website.

Unlike automatic redirects, displaying a language suggestion bar does not force the visitor to load another language version.

WPML’s current visitor-language documentation states that automatic redirects can cause a browser to load the original requested page and then the redirected language page. This additional page load can also affect some speed-test results.

Solution:

• Review the visitor-language settings from WPML > Settings > URLs and SEO and find the Visitor language section.
• Avoid unnecessary automatic redirects. If indexing consistency is important, consider keeping visitors on the requested URL or using the language suggestion bar.
• Use dedicated language URLs. Ensure that translated pages have accessible URLs that search engines can discover.
• Check hreflang implementation to verify that language alternatives point to the correct translated pages.
• Make sure your SEO configuration does not incorrectly canonicalize translated pages to another language.
• Keep a visible language switcher to allow visitors to choose their preferred language rather than relying entirely on browser detection.

7. WPML Activation Causes Site Crashes or Admin Errors

Detection:

• The website displays a critical error after activating WPML.
• The WordPress dashboard becomes inaccessible.
• Translation operations fail or time out.
• The server returns HTTP 500 or 503 errors during certain operations.

Causes:

These symptoms can have different causes, including PHP errors, incompatible extensions, resource limits, or server-side restrictions.

Multilingual websites can require additional resources, especially when processing large amounts of content or running multiple plugins.

According to WPML’s official minimum requirements:

Requirement	WPML documentation
WordPress memory	128 MB minimum
Recommended WordPress memory	256 MB
WordPress version	6.0 or higher
PHP versions	7.4–8.5
MySQL	5.6 or higher
MariaDB	10.1 or higher

These are documented compatibility requirements, not guaranteed performance targets. A complex website may need more resources.

Solution:

• Review the error generated at the time of the crash. A 500 or 503 error alone does not identify the cause.
• Compare your WordPress, PHP, database, and memory configuration with WPML’s official requirements.
• Check memory availability, if logs indicate memory exhaustion, work with your hosting provider to increase the relevant memory limit.
• Investigate timeouts, if logs show execution-time limits being reached, identify the slow operation before adjusting server limits.
• Update WPML and its addons to compatible versions and review any recently updated plugins or themes.

8. Editing One Language Changes Content in Other Languages

Detection:

• Updating a translated page changes a value in the original language.
• A custom field displays identical content across languages even when different values are required.
• Changes to a synchronized field appear in multiple translations.
• A translated page cannot maintain certain independent settings.

Causes:

WPML can synchronize selected content and custom fields across languages.

For example, an ACF field configured as Copy uses the same value in each language. This is expected behavior and is useful for shared values.

However, problems occur when a field that requires language-specific content is configured to remain synchronized. The correct translation preference depends on the field’s purpose.

Solution:

• Identify the synchronized field to determine whether the unexpected change affects text, a custom field, a page-builder widget, or shared template content.
• Review translation preferences. For custom fields, open the applicable WPML or ACFML translation settings, and choose the correct preference.
• After correcting the field preferences, update the original page and its translations as required.
• Review the resulting values. Confirm that independently editable fields behave as intended in each language.

9. ACF Fields Missing in Some Languages

Detection:

• An ACF field group appears when editing the original page but not a translated page.
• Certain ACF fields are missing from the translation workflow.
• A translated page displays an empty section where custom field content should appear.
• ACF field groups behave differently between language versions.

Causes:

This issue differs from an existing field displaying the wrong translation. Missing ACF fields or field groups can result from field-group configuration, translation preferences, location rules, or the way field groups are registered.

ACFML provides translation options for field groups, including:

• Same content in every language, translated: Maintains a shared content structure while translating the applicable values.
• Each language has its own content: Allows separate content management across languages.
• Expert: Provides individual field-level configuration for more advanced requirements.

The selected option determines how different field types are managed.

Solution:

• Open the affected field group from ACF > Field Groups and select the relevant field group.
• Check the translation option. Confirm that the selected ACFML translation mode matches how you want to manage the content.
• Check whether the field group is assigned to the expected post type, template, or other content location.
• Check the individual field settings. Review the field preferences, particularly when using Expert mode.
• Review programmatically registered fields. If a developer registers ACF fields through PHP or Local JSON, the translation settings may need to be defined in the field-group configuration.
• After correcting the configuration, update the original page and its translation, then verify the result.

10. Layout or Design Breaks After Translation

Detection:

• Translated pages have different spacing or alignment.
• Some widgets, sections, or images do not appear correctly.
• Text overlaps or extends outside its container.
• Headers, footers, or templates appear in the wrong language.
• The translated page does not match the intended design.

Causes:

Page-layout problems can have several causes.

For example, translated text may be longer than the original text, affecting buttons, headings, or fixed-width elements. Other possible causes include:

• Missing or untranslated dynamic content.
• Incorrectly configured custom fields.
• Unsupported or improperly registered third-party page-builder widgets.
• Incorrect template assignments.
• Missing fonts for the target language.
• CSS or JavaScript conflicts affecting translated pages.

Not all layout differences indicate a WPML translation failure. Some require responsive design adjustments or better support for languages with different writing directions.

Solution:

• Compare the original and translated pages. Identify which section, widget, or component is displaying incorrectly.
• Confirm that the affected content is translated and the translation has been updated.
• Review page-builder compatibility. If the problem affects a custom widget, check its WPML integration and whether its translatable fields are registered.
• For Elementor, verify the relevant header, footer, and saved templates through WPML’s translation workflow.
• Inspect fonts and text spacing, ensure that the selected fonts support the translated language and that elements can accommodate longer text.
• Check dynamic content. If a widget uses ACF fields or another external data source, verify the translated values and their configuration.
• If the translated content is correct but styling is outdated, use the relevant page builder’s asset regeneration tools and clear applicable caches.

11. Some Plugin Strings Cannot Be Translated

Detection:

• Button labels, form messages, or plugin settings remain in the original language.
• A particular text string cannot be found in WPML’s translation interface.
• A saved string translation does not appear on the frontend.
• JavaScript-generated text remains untranslated.

Causes:

Not every piece of text on a WordPress website is stored inside a post or page. Themes and plugins also contain text strings, such as:

• Button labels.
• Form validation messages.
• Widget headings.
• Plugin settings.
• Theme options.
• JavaScript-generated interface text.

WPML uses String Translation to manage translatable text outside regular page and post content. A string may be missing because it has not been registered, is stored in plugin settings, comes from JavaScript, or is not exposed through a supported translation mechanism.

Solution:

• Check that WPML String Translation is active.
• Open the Strings interface from WPML > Translations > Strings and search for the untranslated text.
• Filter the results using the text domain or translation-status filters.
• Register missing admin strings. If the text comes from plugin settings, widgets, or theme options, use the Admin Texts Translation utility available from the Strings section.
• Check JavaScript strings. If the missing text is generated through JavaScript, go to WPML > Settings > String Translation and enable Detect strings in JavaScript files. Follow WPML’s documented registration and scanning workflow.
• Translate the registered string. Once the text appears in the Strings interface, add or update its translation.
• Clear relevant caches and check the translated text on the frontend.

Additional Tips to Prevent WPML Issues

Although WPML problems can have different causes, following a few practices can make multilingual websites easier to maintain.

• Update WordPress, WPML, its addons, and related plugins after testing for compatibility.
• Use the correct settings for text fields, structural data, and shared values.
• Avoid switching between WPML’s Translation Editor and independently edited translations without understanding how each method works.
• Check URLs, layouts, forms, filters, menus, and other dynamic elements in every supported language.
• Test configuration changes and plugin conflicts before applying them to a live website.
• Error logs can help distinguish PHP failures from memory limits or timeouts.

Final Thoughts

WPML is a feature-rich multilingual plugin, but many issues arise from hidden translation states, page builder synchronization, custom field misconfiguration, or URL and cache dependencies.

Understanding how WPML handles translations internally makes troubleshooting far easier and prevents recurring problems.