Changing a WPML custom field's translation preference is not the same as verifying every existing translated record. Before repeatedly saving pages, confirm who owns the field value, whether propagation is still running, and whether the public template displays the stored field you inspected.
First verify that the affected custom post is still visible
A missing admin row is not the same as a stale custom-field value. If a theme or plugin changed wpml-config.xml to make the whole post type translatable, confirm the representative source and target records still appear under the intended language and status filters before testing field propagation.
The WPML custom-post admin-list guide covers this separate configuration failure and the supported repair documented in WPML 5.2.0. Preserve the original IDs. Recreating missing-looking posts can create new records and confuse the field comparison.
Once the records and their translation relationship are confirmed, continue the two-record field fixture below. The acceptance result needs both stable record identity and the intended value ownership. Neither a populated admin list nor a selected Copy preference proves the other condition.
Check the version and intended operation
WPML 5.2 describes background propagation of custom-field preference changes to existing content, with progress visibility. That creates a separate observation step between changing a preference and confirming the final translated value. Check the supported behavior for your installed WPML and field integration versions.
Do not assume a preference change is harmless metadata. Depending on the selected behavior, a source-owned value may replace language-specific data. Establish the intended ownership before applying the change to a field used across many records.
Classify the field before selecting Copy
An internal product reference shared across languages may reasonably have one source owner. A translated subtitle usually needs a language-specific value. A regional contact number or document link may need an explicit business decision rather than automatic copying.
Write down the field name, storage location, source value, translated value, and intended rule. If a field framework provides its own translation configuration, review that integration too. Similar labels can refer to different underlying meta keys, and a repeater or relationship may contain several values rather than one simple string.
| Field purpose |
Question to settle before changing preference |
| Shared internal reference |
Must all languages always match the source? |
| Translated text |
Who edits and approves each language value? |
| Local office information |
Is variation intentional rather than stale data? |
| Linked document |
Should the language point to a different file? |
Use a two-record staging fixture
Create one existing translated record and one fresh test record. Put distinct, non-sensitive markers in the source and target field so replacement is unmistakable. Preserve a recoverable backup and the original preference. Do not use a real contract link or customer address as the marker.
Use the plugin update staging checklist to isolate mail and external integrations before testing. A background content update can trigger other integrations even when the visible change seems small, so record which side effects are disabled and therefore not tested.
Distinguish saving a translation preference from completing propagation and rendering the updated field. Synthetic explanatory visual.
Observe completion instead of repeatedly resubmitting
Save the intended preference through the supported interface. Record the time and any displayed background progress. Allow the documented workflow to advance, then inspect the existing target record. Repeatedly toggling the preference while work is running can obscure which operation produced the final value.
If progress stops, preserve the status and versions for diagnosis. Do not delete queue records, run arbitrary database replacements, or force a full retranslation merely to make the marker change. Those actions can affect more content than the original preference change.
Compare the fresh and existing records. A new translation working while the old one remains unchanged points toward propagation or historical configuration, not necessarily the template. If both stored values are correct but the page is wrong, inspect rendering and cache separately.
Check the actual output field
Open the public language page and identify the displayed marker. Confirm that the template uses the intended meta key and content ID. A builder may display a fallback value, another post's field, or a hardcoded translation. Clearing caches cannot correct a template that reads the wrong source.
After a targeted cache refresh where appropriate, repeat the public check signed out. Verify at least one field that should remain language-specific so a broad configuration change has not unintentionally synchronized unrelated content.
Approve the change with ownership intact
The acceptance result should show the intended shared value on existing translations, preserved local values where required, and agreement between stored data and public output. Keep the original field values available until the owner approves the result. Rolling back plugin files alone may not restore overwritten content.
HandL WP can investigate field propagation or rendering failures using a sanitized field map and fixture. The important handoff is not simply that Copy was selected. It is which values were supposed to change, which must remain different, and where the actual outcome first departed from that rule.
Reference and review date
Primary technical reference. Sources checked October 30, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.
Editorial update November 2, 2026: diagnostic distinctions and related guidance reviewed. Existing publication date and illustrative assets retained.