20 Common WPML Problems and How to Fix Them

By Mansour Jabinpour. Originally published on LumoWP. Republished by LumoWP.

WPML TROUBLESHOOTING

A French page opens, but the header is still English. A translation says “complete,” yet the language switcher refuses to show it. Or the shop works perfectly until a customer changes language at checkout. These are different failures, even when they all look like “WPML is not translating.”

The useful question is where the translation stopped: creating the content, publishing it, choosing the correct language, rendering a template, or delivering a cached response. Changing settings at every layer makes that question harder to answer. Start with one affected URL and one language pair.

This guide brings together recurring patterns from public WPML support discussions and current documentation, with a static review of WPML 4.7.4 source code. It is a practical selection, not a statistical ranking of the twenty most reported bugs. The forum cases are other users’ reports; we have not reproduced every case on a test store. Each section explains what to inspect, what to change when the evidence fits, and how to tell whether the fix worked.

Before changing anything: keep a restorable backup and reproduce the issue on staging. Record one source URL, one target URL and the installed versions. The illustrations below are conceptual explanations, not screenshots of WPML’s interface.

Find your problem

1. Why is a language missing from the WPML language switcher?
2. Why does a translated page return a 404 error?
3. Why does the wrong language appear only for visitors or after caching?
4. Why is a translation stuck at “in progress” or 100%?
5. Why will the Advanced Translation Editor not open?
6. Why will automatic translation not start, even when the account has credits?
7. Why are manual translation edits overwritten?
8. Why can’t I find a text in String Translation?
9. Why is a string translated in the dashboard but still English on the page?
10. Why do the header, footer or page-builder widgets stay untranslated?
11. Why are ACF or custom-field values missing, copied or overwritten?
12. Why are translated WooCommerce variations, prices or stock missing?
13. Why does the cart, checkout or order email switch language?
14. Why does the translated page show the original image—or no image?
15. Why do translated menus or buttons still link to English?
16. Why do hreflang, canonical URLs or translated SEO titles look wrong?
17. Why did WPML stop working after moving or cloning the site?
18. Why do search results or a custom post grid show the wrong language?
19. Why does the site or WordPress admin become slow with WPML?
20. Why does an update cause a fatal error, blank screen or compatibility notice?

Check the version before following a fix

Version matters. The source inspection below uses WPML 4.7.4, while current documentation also describes WPML 5. In 4.x, you will often see WPML → Languages, Translation Management and String Translation as separate screens. Newer documentation uses WPML → Settings and WPML → Translations for several of these tasks. Follow the equivalent screen in your installed version; do not install an old forum workaround just because its error message looks familiar.

Reviewed 18 October 2026. Historical forum reports helped identify the symptoms; current documentation and the inspected code support the diagnostic approach. Several old forum URLs no longer returned live pages during our link check, so the reading links below point to current documentation. This is a source review and troubleshooting guide, not a claim that every historical issue is still present.

1. Why is a language missing from the WPML language switcher?

Start with the destination page, not the switcher’s styling. A language can be enabled site-wide while the particular page has no publicly available translation. A draft, an unfinished review, or a translation linked to a different source page can all send you down the wrong path.

What to check

1. Open the affected source page and follow its translation link. Confirm the destination is the intended page and is published. Check the homepage separately if the problem appears only there.
2. Inspect the switcher’s missing-translation behavior. It can omit a language or lead to that language’s homepage; a homepage link does not prove that the current page has a translation. Also check whether the language is hidden from visitors.
3. If the whole switcher disappears only inside a custom header, check that header’s translated template and display conditions. Purge the affected page cache after correcting the underlying state.

Source check: WPML 4.7.4’s WPML_LS_Model_Build::get_language_items() passes a skip_missing argument derived from the link_empty setting. That explains why an absent language can be deliberate behavior rather than a CSS problem.

How to verify the fix: Open the page while logged out. Switch to the second language and back. Both links should reach the corresponding published page, not silently fall back to the homepage.

Reference: WPML switcher behavior

2. Why does a translated page return a 404 error?

A 404 is a routing or availability problem. It does not tell you whether the translation engine did a good job. First distinguish a nonexistent destination from a valid translation whose public URL is not resolving.

What to check

1. Copy the translated page’s own permalink from WordPress. Check its publication status and language assignment. Compare it with the URL generated by the switcher. A hand-built /fr/ prefix is not a reliable substitute for the real permalink.
2. For directory-based languages, check the permalink configuration and the web server’s WordPress rewrite handling. Resaving Settings → Permalinks once can refresh WordPress rules; repeatedly saving it will not fix an incorrect server configuration.
3. For separate language domains, verify DNS, HTTPS and that every domain reaches the same intended WordPress installation. A certificate error or a different document root cannot be repaired by retranslating the page.
4. If a slug was changed, inspect redirects and stale navigation links. Test the final destination rather than accepting a redirect to the homepage as a fix.

Keep the existing public URL scheme unless there is a reason to migrate it. Switching every language from directories to domains to fix one page creates a much larger SEO and routing change.

How to verify the fix: Request the final translated URL in a private window. It should return the intended page with HTTP 200, and the language switcher should point to that same destination.

Reference: WPML language URL options

3. Why does the wrong language appear only for visitors or after caching?

If an administrator sees French but a logged-out visitor sees English at the same URL, compare the delivery paths before editing translations. The administrator may bypass full-page caching. A CDN, page cache or cached AJAX fragment may be returning content generated for a different language.

What to check

1. Record the exact URL, cookies relevant to the request, and whether the error affects the whole page or only a fragment such as the mini-cart. Compare a normal guest request with a controlled cache-bypassed request.
2. Check the cache key. Language domains and directories must remain distinct. If language is carried in a query parameter, verify that the cache does not discard that parameter. For AJAX, inspect the request’s language context and the cache plugin’s documented WPML integration.
3. Purge only after fixing the rule, then warm and revisit each language in alternating order. If the first visited language wins for later visitors, the cache separation still needs work.

Do not solve this by caching personalized checkout or cart responses as ordinary public pages. A cookie exclusion reported in one support thread is specific to that cache setup, not a universal rule for every multilingual site.

How to verify the fix: Use two separate guest sessions. Load English, then French, then reverse the order. Check the page and dynamic fragments after each visit.

Reference: WPML performance and per-language caching

4. Why is a translation stuck at “in progress” or 100%?

The percentage in an editor is not the entire job lifecycle. A job can finish at the translation service but fail to return, save, or publish on WordPress. Treat “waiting for review” separately from an actual processing failure.

What to check

1. Find the affected job and record its ID, source page, language pair, status and last update time. Check whether someone still needs to complete or approve it.
2. Open the relevant logs under WPML → Support. In current versions, the communication, Advanced Translation Editor and translation-management job logs answer different questions: did it reach the service, did the editor fail, and did the result return?
3. If the logs identify a connection, account or PHP error, fix that cause first. Retry one affected job and follow it through to a public page. Use your version’s documented safe repair tool only when the symptom matches.
4. If the job exists remotely but cannot be reconciled locally, give WPML Support the IDs and timestamps. Avoid deleting translation records or resending the entire site as a first response.

A queue label is evidence of state, not a diagnosis. “Pending” in a third-party provider queue may be different from “in progress” in WPML’s own job list.

How to verify the fix: The job must finish, the translated post must exist with the intended status, and its frontend content must match the saved translation.

Reference: WPML log reference

5. Why will the Advanced Translation Editor not open?

A blank editor, a failed task request and a permissions error should not receive the same fix. ATE depends on a working connection between the browser, WordPress and the translation service. Inspect the failed request before changing editors.

What to check

1. Try one affected job and a small new test job. If only one fails, keep its ID; if every job fails, investigate the account, permissions and connection first. Confirm the translating user has the appropriate language pair and a valid profile email.
2. Check ATE errors and the browser’s Network panel. Record the failing host and status code. A 403 suggests access controls; a timeout suggests a different path. Do not publish request tokens or private payloads in a public ticket.
3. Ask the host to check outbound HTTPS, DNS, TLS certificates and any security rule that blocked the documented service endpoint. Also test a clean browser session without extensions.
4. If the page began failing after a deployment, reproduce it on staging with the same versions and inspect PHP logs. Switching to the Classic Editor can change the workflow without fixing the underlying failure.

Do not disable TLS verification or the site’s firewall globally. A narrowly identified blocked request gives the host something concrete to fix.

How to verify the fix: The editor opens, saves a small change and returns it to the same translated page without another failed request.

Reference: WPML troubleshooting checklist

6. Why will automatic translation not start, even when the account has credits?

“There are credits in my account” and “this site can use this translation service” are not identical statements. The site identity, allocation or billing setup, supported language and selected workflow all matter. A cloned site can also retain confusing relationships to the original account.

What to check

1. Identify which engine is handling the job. WPML’s own automatic-translation billing and a third-party service using your API key are separate systems. Check the balance and limits for the service actually receiving the request.
2. Verify that the current production URL is registered correctly and that any moved-or-copied-site prompt was answered accurately. Check the selected languages and the current engine’s support for them.
3. Translate one short page. If it fails, inspect its exact error: authentication, provider quota, payment, rate limiting or connectivity. Repeated bulk submissions make billing and queue diagnosis harder.

For a bring-your-own-key workflow, our Lumo WPML AI Translation Addon provides a separate provider-backed queue with job logs and retry/resume logic. It is our commercial product, not an official WPML add-on. It still needs a compatible WPML setup and provider access; it does not repair broken URLs or template configuration. Verify compatibility with your installed WPML major version before adopting it.

How to verify the fix: Confirm one successful provider request, one completed job and one correct translated page before increasing the batch size.

Reference: WPML automatic translation

7. Why are manual translation edits overwritten?

This often becomes an ownership problem: which editor is the authoritative place to change this translation? Editing the translated WordPress page directly, then completing an older translation job, can reintroduce content from a different workflow. A synchronized duplicate is another possibility.

What to check

1. Before another update, save the affected text and inspect revisions. Record whether the page was a duplicate, an independent translation, or a page maintained through ATE.
2. For a translation that should mirror the source, make corrections in its established translation editor. For genuinely different content or layouts per language, use WPML’s documented independent WordPress-editor workflow for that page.
3. Check for an older queued job or an automated process that can write the translation later. Changing the source and waiting for the next job is a better reproduction test than repeatedly editing the target in two places.

Newer WPML versions have changed editor behavior. Do not assume that a years-old “switch editors” workaround applies unchanged. Back up the page before changing its translation workflow. For a narrowly scoped title correction with our tool, see changing only a translated title with Lumo.

How to verify the fix: Make a harmless source update on staging, complete the normal translation cycle, and confirm the intended target-language edits survive.

Reference: WPML editor and independent-content workflows

8. Why can’t I find a text in String Translation?

First identify who owns the text. A paragraph in a post, a button in a header template, a theme option and a hard-coded plugin label can look identical on screen while belonging to different translation systems. Scanning every plugin is a poor substitute for that distinction.

What to check

1. Find the exact text in the page or template editor. If it belongs to content, translate that content or template instead of searching only in String Translation.
2. If it is a theme or plugin label, check the relevant text domain and scan that component when appropriate. For a value saved in an option, use WPML’s admin-text translation workflow or the integration supplied by the plugin.
3. For a custom widget or shortcode, ask the developer whether its dynamic value is registered and whether the frontend retrieves the translation. Registration alone does not change what echo outputs.
4. If a form plugin owns the text, check its WPML integration. A missing compatibility add-on can be the real issue.

Keep the original phrase, its owner and the screen where it is configured in your notes. That makes the search reproducible and avoids translating a different copy of the same words.

How to verify the fix: Find the exact source item, translate it once, and check that specific element in the target language while logged out.

Reference: WPML dynamic string registration · Find strings that are not listed

9. Why is a string translated in the dashboard but still English on the page?

A saved translation can be perfectly valid and still never be requested by the frontend. Common suspects are the wrong domain, a mismatched string name, a wrong source-language assignment, or custom code that prints the original value directly.

What to check

1. Compare the translated entry’s domain and name with the code or component rendering it. Two entries with the same visible English text are not necessarily the same string.
2. Check the entry’s source language and completion state. Then test the correct language URL with the relevant cache bypassed to separate rendering from delivery.
3. For developer-owned dynamic text, use the same stable context and name at registration and retrieval. Register on the setting’s save/update path rather than registering large amounts of text on every frontend request.

Developer example: the following illustrates a dynamic setting after it has been validated and saved. Adapt it inside your own integration; it is not code to paste into an article or a WPML core file. It requires String Translation.

// In the setting's save/update handler:
do_action(
    'wpml_register_single_string',
    'my-site-settings',
    'delivery_notice',
    $saved_notice
);

// Where the notice is rendered:
$notice = apply_filters(
    'wpml_translate_single_string',
    $saved_notice,
    'my-site-settings',
    'delivery_notice'
);
echo esc_html( $notice );

How to verify the fix: Change only this translation to a recognizable test phrase on staging. If the frontend does not change, trace the value actually used by the renderer.

Reference: WPML string retrieval contract

10. Why do the header, footer or page-builder widgets stay untranslated?

Translating a page does not necessarily translate the documents it embeds. A global header, footer, popup or reusable template can have its own translation and display rules. This is especially easy to miss when the page body already looks correct.

What to check

1. Identify the template responsible for the untranslated area. Translate that source template through its supported WPML integration and complete the job.
2. Check the translated template’s conditions and the destination page’s language. A translated header attached to the wrong condition will not help the page you are viewing.
3. For a custom widget, check whether its text fields are declared to WPML. If its content is absent from the translation editor, more automatic-translation credits will not expose it.
4. After the template is correct, refresh the builder’s generated assets if its documentation requires that, and clear the affected cache. Compare desktop and mobile templates separately.

A real support case involved an untranslated header template rather than missing translations in the page itself. That is a useful pattern, not proof that every missing button label is a header problem.

How to verify the fix: Check at least two pages using the template, both languages, and the mobile navigation. The visible label and its link destination must both be correct.

Reference: WPML Elementor integration

11. Why are ACF or custom-field values missing, copied or overwritten?

A field is not automatically a sentence. A headline usually needs translation; a layout flag may need synchronization; an image ID needs the media integration to resolve the appropriate asset. Choosing “Translate” for everything is just as risky as choosing “Copy” for everything.

What to check

1. For ACF, inspect the field group’s translation mode in ACFML. A preset or PHP/JSON configuration may control a field that appears locked elsewhere. Use Expert mode only when you need to own those decisions.
2. Choose behavior by meaning: Translate for language-specific text; Copy for synchronized values; Copy once for an initial value that may diverge; Ignore when it should not be copied through this mechanism.
3. Check parent repeaters and flexible-content structures as well as their subfields. A sensible text-field setting can still be defeated by an incompatible parent configuration.
4. After correcting settings, update and re-complete one affected translation. Verify it before applying the change to hundreds of pages.

Source check: WPML_Copy_Once_Custom_Field::copy() in 4.7.4 checks the target field’s stored values before syncing from the original. Copy once is not the same as continuous synchronization. This core path does not prove every ACF block stores and syncs fields in the same way.

How to verify the fix: Change a source value on staging. Confirm synchronized fields update and deliberately independent fields remain independent.

Reference: Official custom-field translation options · WPML ACF guide

12. Why are translated WooCommerce variations, prices or stock missing?

A translated product is more than a translated description. Its variation relationships, attribute terms and commerce metadata have to remain coherent. Manually setting stock or price system fields to “Translate” can turn a content task into a data-integrity problem.

What to check

1. Check the WooCommerce integration required for your WPML version. Older 4.x installations use the separate WooCommerce Multilingual integration; current WPML documentation and menus differ. Do not mix instructions from incompatible generations.
2. Inspect the original variable product first. Confirm its attributes and variations are valid, then translate the parent product and the necessary attribute terms through the supported workflow.
3. Compare the target product’s variation choices and purchasability. If synchronization is required, use the integration’s documented tool for that specific issue after a backup; do not edit WPML relationship tables manually.
4. Check add-ons that own extra product fields, galleries, bundles or swatches. Their compatibility can determine whether the core product translates while an extension’s data does not.

Stock and currency are different concerns. A translated label does not imply a currency conversion, and the same inventory should not become separate stock just because a product has another language.

How to verify the fix: On staging, select each important variation, add it to the cart, and verify price, stock behavior and product identity in both languages.

Reference: Current WPML WooCommerce workflow

13. Why does the cart, checkout or order email switch language?

The product page is only the first step. A hard-coded checkout URL, an untranslated checkout page, an AJAX fragment without language context or an email extension can each break the language journey later. Test the transaction path, not just the product screenshot.

What to check

1. Verify the cart and checkout destinations exist and are translated and published. Inspect “Buy now” links supplied by the theme or a checkout plugin; they may bypass the normal language-aware URL.
2. Test both the initial checkout and its dynamic updates: shipping changes, validation errors and mini-cart refreshes. Inspect the request that first returns the wrong language.
3. For emails, distinguish customer emails from admin notifications and note how the email was triggered. Check custom strings and email templates in the extension that owns them.
4. If a historical thread names an email bug, check its current fix status and your installed version. Avoid applying an old PHP patch blindly.

Use a staging payment gateway or sandbox and a mailbox you control. Testing translations should not create real customer charges or send test messages to customers.

How to verify the fix: Complete a test order in each target language. Inspect the checkout, confirmation page and intended recipient’s email, including extension-generated text.

Reference: WPML WooCommerce translation

14. Why does the translated page show the original image—or no image?

Separate the file from its text. Translating alt text or a caption does not necessarily replace the image file. Conversely, choosing a different banner does not automatically prove that the frontend is loading that translated asset.

What to check

1. Decide whether you need the same image with translated metadata or a different file for the target language. Use the matching Media Translation workflow for your version.
2. Inspect the element in the browser and identify the actual image URL. A page builder may store a direct URL, a featured-image reference or an attachment ID; a CSS background may use a separate source.
3. For an ACF image field, check ACFML’s field configuration and media integration together. Then update the affected page’s translation through its existing workflow.
4. If the image is missing entirely, verify the asset URL, attachment availability and offload/CDN response before assuming its translation is missing.

Do not bulk-delete apparently duplicate media as a generic repair. Multilingual attachment records and physical files are not the same thing, and a deletion can affect content that still references the asset.

How to verify the fix: Check the downloaded image URL, visible image, alt text and caption in each language. Include mobile backgrounds when the layout uses different assets.

Reference: WPML media translation guide

15. Why do translated menus or buttons still link to English?

A translated label can conceal an untranslated destination. A custom menu URL is just a URL; changing “Contact” to “Contactez-nous” does not guarantee that it now points to the French contact page.

What to check

1. Inspect the actual href. Check the translated menu or navigation block, its assigned location, and the target page’s translation. Use the menu workflow supported by your theme type.
2. Review custom links and buttons separately from page-based menu items. Confirm the target exists before replacing a URL.
3. For developer-generated links, resolve a translated object ID instead of assembling language directories by hand. Choose deliberately whether a missing translation should fall back to the original.

Source check: SitePress::get_object_id() in 4.7.4 uses the requested language and, for translatable types, returns the original only when the fallback flag allows it. The example below deliberately avoids that fallback and only renders a link to a published destination. Replace 123 with the real source page ID.

$target_id = apply_filters(
    'wpml_object_id', 123, 'page', false, 'fr'
);

if ( $target_id && 'publish' === get_post_status( $target_id ) ) {
    printf(
        '<a href="%s">%s</a>',
        esc_url( get_permalink( $target_id ) ),
        esc_html( get_the_title( $target_id ) )
    );
}

How to verify the fix: Click each primary navigation item in the second language. Check where it lands, then refresh the destination to ensure the language persists.

Reference: WPML menu translation · wpml_object_id API

16. Why do hreflang, canonical URLs or translated SEO titles look wrong?

Inspect the delivered HTML before changing an SEO setting. A search result can lag behind a page update, and a crawler report can reflect a cached response. A correct dashboard field is only one part of the evidence.

What to check

1. Open the published target-language URL and inspect its title, meta description, canonical and hreflang links. Check the final URLs after redirects, not just the strings shown in a report.
2. For genuinely translated pages intended to be indexed separately, verify that the canonical does not unintentionally consolidate every language into English. Check reciprocal hreflang references and valid language or language-region codes.
3. Use the supported integration for your SEO plugin. Confirm that its fields are included in the translation workflow; editing the visible post title may leave the SEO title unchanged.
4. If multiple plugins or custom snippets emit conflicting tags, identify the owner of each output. Correct that conflict, purge affected caches and crawl again.

Source check: WPML 4.7.4’s WPML_SEO_HeadLangs::must_render() checks publication and content-type conditions. A draft preview is not a reliable place to audit the final published hreflang output.

How to verify the fix: Fetch both published pages again. Each alternate URL should load its intended language and refer back appropriately. Then use your search tooling to request or observe a fresh crawl.

Reference: Google: localized versions and hreflang

17. Why did WPML stop working after moving or cloning the site?

A move and a copy are not the same event. A staging clone should not casually take over production’s translation identity, and a production move should not be treated as a brand-new unrelated project. Registration, translation-service identity and stored content also need to be distinguished.

What to check

1. Confirm whether the original site still exists and which installation is now production. Answer WPML’s moved/copied-site prompt according to that reality, using the workflow for your installed version.
2. Verify the registered URL and site key, including scheme and hostname. Check the translation account connection and any shared-credit arrangement separately.
3. Check that the database migration included translations and their relationships. A new registration key does not reconstruct database content omitted during migration.
4. On a staging clone, inspect scheduled translation activity and outgoing integrations before allowing it to run unattended. If both installations have conflicting service state, ask support to reconcile it rather than guessing at internal IDs.

Do not delete translation records or reset WPML to clear a registration notice. That can turn an account-connection problem into content loss.

How to verify the fix: Open an existing translated page and complete one small test job on the intended installation. Confirm the original or staging copy is not processing the same work unexpectedly.

Reference: WPML troubleshooting and support · WPML 4.9.5 migration changes

18. Why do search results or a custom post grid show the wrong language?

The normal search and a custom widget may use entirely different queries. If the normal archive is correct but a custom grid mixes languages, inspect that grid’s query and cache key before translating all the posts again.

What to check

1. Confirm the requested language and which component builds the result set: WordPress search, a custom WP_Query, an AJAX endpoint or an external search index.
2. Check whether the query suppresses filters. In a developer-owned get_posts() call, explicitly allowing filters can be necessary for WPML’s language filtering. This is not a reason to change every query globally.
3. For an AJAX or REST search, preserve the language context through the supported integration. For an external index, check language indexing and filtering as well as WordPress settings.
4. If results are cached by search term alone, add the relevant language dimension to the integration’s cache design.

Developer example for a grid that should respect the current language. Run it after WordPress has established that language. It does not repair a separate search index or force the correct context into a custom API endpoint.

$items = get_posts( [
    'post_type'        => 'post',
    'post_status'     => 'publish',
    'posts_per_page'  => 6,
    'suppress_filters' => false,
] );

How to verify the fix: Use a unique phrase from one translated post. Test the normal search and custom grid independently in both languages, including cached responses.

Reference: WordPress get_posts reference

19. Why does the site or WordPress admin become slow with WPML?

“Fast with WPML off” is a useful comparison, but it does not yet identify the expensive operation. A plugin integration can multiply queries, a translation request can wait on a remote service, and a cached guest page can hide a slow backend.

What to check

1. Separate three measurements: a warm guest page, an uncached or logged-in page, and the specific slow admin action. Keep the URL, language, dataset and server conditions comparable.
2. On staging, profile database queries by component and caller, PHP execution and external HTTP requests. Record repeated expensive work, not just the total number of queries.
3. Test suspected integrations one at a time. A documented forum case traced slow admin search to a compatibility layer in another plugin, so attribution matters.
4. Check available memory, worker saturation and database resources against the measured workload. Evaluate persistent object caching where appropriate, but verify language correctness after enabling it.

Profiling tools add overhead. Use them to identify the work, then repeat timing without the profiler before claiming a speed improvement. Do not present a cached TTFB as proof that translation jobs or the admin are fast.

How to verify the fix: Repeat the same action several times under comparable conditions, report a typical result and inspect the slowest traces. The improvement should survive with the diagnostic plugin turned off.

Reference: WPML performance triage

20. Why does an update cause a fatal error, blank screen or compatibility notice?

A blank screen is a symptom, not a reason to press every troubleshooting button. Find the actual PHP error and the component named in its stack trace. Partial updates, incompatible component versions and third-party code can produce similar-looking failures.

What to check

1. Record the last working versions and the exact deployment or update that preceded the failure. Check WordPress recovery information and the server PHP error log. Keep errors out of public page output.
2. On a staging copy, verify a compatible set of WPML, its required integrations, WordPress, PHP and the theme. Complete any interrupted plugin file update using trusted packages.
3. Search WPML’s current known-issues list for the exact component and error. Check the fixed version before considering a historical workaround.
4. If the site must be recovered, use a tested backup or a controlled rollback plan that accounts for database changes. Do not mix an old plugin directory with a newer database state casually.

Reset WPML is not an ordinary repair step. It removes WPML data and belongs in a deliberate recovery or removal plan, not a routine response to a failed update. Likewise, never run every advanced cleanup tool just because it is available.

How to verify the fix: Reproduce the original action successfully on staging, inspect logs for the same error, then validate representative translated pages and commerce flows after the controlled production change.

Reference: WPML current known issues

What we checked in the source code

The source notes refer to the local WPML 4.7.4 package, not an assertion about every later release. We inspected these implementation points without changing plugin files. The three code examples are illustrative integrations; adapt and test them in staging before deployment.

Area	File / implementation	Observation
Language switcher	classes/language-switcher/class-wpml-ls-model-build.php	get_language_items(): skip_missing is derived from switcher settings.
Copy once fields	classes/custom-field-translation/class-wpml-copy-once-custom-field.php	copy(): checks target values before synchronization.
Translated IDs	sitepress.class.php	get_object_id(): language lookup and optional original-ID fallback.
SEO language tags	classes/seo/class-wpml-seo-headlangs.php	must_render(): publication and content-type conditions.
Query handling	classes/query-filtering/class-wpml-query-parser.php	adjust_taxonomy_query(): checks suppress_filters for this adjustment path.
Dynamic strings	wpml-string-translation/inc/functions.php	wpml_translate_single_string_filter(): passes context, name and language to retrieval.

We also inspected Lumo AI Translation Addon 3.20.28, including process_job() in includes/class-ai-processor.php. It distinguishes provider translation from saving the result to WPML and has a path for reusing a saved result after a WPML save failure. That supports the limited queue description above; it is not a benchmark or a guarantee of compatibility with an untested WPML major version.

Fix one failure, then test the whole language journey

The fastest useful repair is usually a small one supported by evidence: publish the missing destination, correct one template, fix one cache rule, or resolve the request that blocked a job. Translating the entire site again can hide the original cause while adding new work.

If you need help, prepare one source URL, one target URL, the expected result, the actual result, exact reproduction steps, versions and the relevant job or log timestamp. Redact credentials and customer data. That is far more actionable than “WPML does not work.”

If you are still configuring the basic language structure, start with our WPML installation and setup guide. Once the structure is right, use the relevant section above to test one failure at a time.