One other question regarding the Advanced Custom Fields translation settings. As you can see in the test site, the custom fields are *very* complex. Too complex and bloated really, but I guess that's the nature of this very large multisite that has grown over the years. I have the main "Page Content" field, which is a flexible field, set to "Copy." Some time ago I had it set to "Copy Once" but I suspect that might be what caused our translations to eventually grow out of sync with our English updates over the years. So I have the main flexible field set to "Copy," but most fields within that field are set to "Translate." Except for any other repeatable/flexible fields, which I also have set to "Copy."
For a specific example:
Page content (type: Flexible Content) (translation preference: Copy)
- Download list (type: Layout)
-- Downloads (type: Repeater) (translation preference: Copy)
--- Download (type: Link) (translation preference: Translate)
Do I have that set right? I've read conflicting support/documentation on Copy vs Copy Once, and I'm not entirely clear how to handle nested repeatable fields.
Since this is split into a new topic, I'll add some more context. That "Download list" custom field can be seen in use here:
hidden link
But if we look at the Spanish translation, although the words on this page are properly translated, the links still point to English resources:
hidden link
And the Chinese translation seems to have not translated properly but it *did* get the link destinations correct. It seems to have replaced "Read Online" with the Chinese title of whatever the link leads to:
I think you are right about “Copy Once” causing content to drift out of sync over time. Using Copy for the “structural” container fields is generally the right setup when you want the same layout/rows across languages, and you translate only the text parts via WPML’s Translation Editor.
Guidance may seem conflicting about this because a lot of the “use Copy Once” advice is specifically about workflows where people edit translations in the WordPress native editor and want freedom to change layout/rows per language.
* Copy = keeps the value synchronized across languages (when you update the original, the translation is overwritten with the same change).
* Copy Once = copies only the first time; after that, translations become independent, and later edits in English won’t propagate, which commonly leads to “out of sync” issues over the years.
Our recommendation for Repeater and Flexible Content is:
* Copy if you want the same layout/number of rows across languages
* Copy Once only if you want the layout/rows to differ per language
Your structure is right if your goal is:
* same blocks/rows everywhere (so the page builder structure stays identical), and
* Only specific inner fields (like link text, headings, WYSIWYGs, etc.) are translated in WPML.
For Repeater/Flexible, you can set the main field to Copy/Copy Once and still set translation preferences for sub-fields
That's clear, but can you explain this section on the WPML > Settings page? It does not reflect the settings I have in the ACF page. See attached images.
In the sandbox site we've used in the other ticket: hidden link
It's working as expected. Both places are in sync.
Can you please change the setting in the ACF settings, save, then change it back and save. Then visit the WPML settings page and check if it's OK now.
Please enable the WP debug information so we can see if there is any error:
Please follow the instructions mentioned on this page: https://wpml.org/documentation/support/debugging-wpml/
Then, try to reproduce the issue and check your installation's **wp-content** folder to see if a file named **"debug.log"** was created (it will only be generated if a server error occurs).
If the file was created, please upload it to a platform like **Google Drive** or **Dropbox** (whichever you usually use) and share the link with me (make sure it is publicly accessible) so I can analyze it.
I have managed to isolate the issue (or one of the issues) in a reproducible way! I think the problems are related to the fact that this is a multisite using ACF fields synced with JSON.
"Can you please change the setting in the ACF settings, save, then change it back and save. Then visit the WPML settings page and check if it's OK now." This worked to fix the WPML settings page.
However, by re-saving the ACF fields on one site, the other sites in the multisite network show "Sync available" on the ACF page since the JSONs' modified time is now newer. If I run the sync on one of those sites, then go check the WPML settings page on that site, the page_content field is set to translate for some reason. So I have to go to the ACF page, change-save-unchange-save again, and that fixes the WPML settings page but of course triggers all other sites to show "Sync available" again. So it's an endless circle.
And the issue where pages seemed to "fail" translating seems to occur when I try automatic translations not realizing the page_content field had been set to translate instead of copy, due to the syncing issues.
With this in mind, would it still be helpful for me to enable debug? I wonder if this is a quirk with how this multisite/ACF is set up. Even though it uses JSON syncing, it does not utilize the default acf-json folder to do so, but a custom mu-plugin folder instead, which I suspect is the reason why the attached image doesn't seem to do anything when I try it.
Yes, I think that the mu-plugin folder can be the root cause.
WPML/ACFML doesn’t “scan your server for JSON files anywhere”; it relies on what ACF reports as its Local JSON load points (the folders returned by ACF’s acf/settings/load_json logic). If your multisite uses a custom mu-plugin folder for JSON and that folder is not registered consistently and early (or differs per subsite / load order), then ACFML can end up:
- not seeing the same JSON definitions you think it should,
- or seeing them in a different order
Is it possible for you to check this hypothesis (I don't know the specifics of your setup)? I can provide a fresh multisite install if needed to test it from scratch.
I think a WPML XML config file can help a lot here, specifically as a “lock” so the page_content field can’t keep flipping between Copy and Translate when ACF JSON sync / ACFML scanning runs:
Right now, your problem is not “how do I translate this field?”, it’s “the translation preference keeps getting overwritten by the Local JSON / multisite sync behavior”. A wpml-config.xml can make WPML treat specific custom fields with a fixed rule, regardless of what ends up shown (or temporarily mis-shown) in WPML → Settings → Custom Fields Translation.
Can you please try this:
Create (or update) a wpml-config.xml in the active theme and force the rule for the field key you care about:
<code
<wpml-config>
<custom-fields>
<custom-field action="copy">page_content</custom-field>
</custom-fields>
</wpml-config>
[/php]
That tells WPML: for the meta key page_content, always copy.
