Background of the issue:
I'm automatically translating the whole website to 8 other languages. The website is built with ACF components and is still under development. I marked all my ACF fields as 'Same fields across languages', but for some I had to switch to Expert. I am using WPML with ACF ML to manage translations.
Symptoms:
Even when I explicitly marked a Button component setting field as 'Copy', in WPML Editor it's visible to translation and breaks styles on translated pages (e.g. 'blue' style is 'blau' on German pages). This happens on all translated pages.
Questions:
Why are fields marked as 'Copy' still visible for translation in WPML Editor?
How can I prevent style changes on translated pages when using WPML with ACF ML?
We need to replicate this issue on a fresh WordPress installation. Then I'll be able to escalate it to our compatibility team. To achieve this, I created a test website with a clean WordPress installation. You can access it through this link:
hidden link
With this link, you'll be directly logged in.
I've installed the ACF Pro plugin and configured WPML to have English as the default language and French as a secondary language.
Please proceed with the bare minimum setting to replicate this problem.
When everything is finished and you can replicate the problem, please let us know.
Important! Do not import your site to the test site. We must replicate the problem on a fresh, clean WordPress installation.
Hello,
I was NOT able to reproduce the error on the Sandbox website.
Steps I took to reproduce:
1. Create "Gutenberg: Button" Field group with Expert setup as a copy of our theme Field group.
2. Create "Gutenberg: Heading" Field group with Expert setup as a copy of our theme Field group.
3. Create "Gutenberg: CTA" Field group with Expert setup as a copy of our theme Field group.
4. Assign "Gutenberg: CTA" location to "ACF Test" page (couldn't assign it to Block as we do in our themes, as there are no Blocks).
5. Populate "Gutenberg: CTA" fields on "ACF Test" page" with text and choose settings.
6. Save the page and manually create French translation with Advanced Translation Editor (fields that are set to Copy are not visible here at this moment).
7. Change the "Button style" field in "Gutenberg: Button" from Copy to Translate.
8. Save the "ACF Test" page.
9. As "Button style" options are now visible in ATE, manually translate these options and save French translation.
10. Change the "Button style" field in "Gutenberg: Button" back from Translate to Copy.
11. Save the "ACF Test" page.
12. "Button style" options are now again NOT visible in ATE.
I couldn't 100% recreate the way we translated our page:
1. Couldn't assign "Gutenberg: CTA" to Block as we do in our themes, as there are no Blocks available.
2. We used automatic translation with DeepL, not manual translation.
3. We use ACF field settings as JSON, and not in DB, but as the text states on ACF > Tools page: "ACF allows you to register fields via PHP or save field settings as JSON files and WPML integrates with these features. If you select this option, ACF Multilingual will scan your field groups stored in PHP files and the "acf-json" directory. It will then sync any changes to translation preferences. This can harm the site's performance if you have a significant number of fields stored this way."
It seems that the broken part on our website is the update of ATE with changed Translation preferences after saving ACF block. It works on Sandbox, but not on our site. I did the exact steps 7-12 on our site, and all of the fields that have Translation preferences set to "Copy" are still visible in ATE.
Our second-tier supporter explained the following:
For example, if we examine the "file" Custom field, we can see that it has conflicting preferences. In Gutenberg: Section with files - it is set to "1" (which is Copy). And
Gutenberg: Stepper is set to "2" (which is Translate). In all cases, it should be set consistently to COPY in all instances.
The fact that things work on the sandbox site, as you could approve, tells us that WCFML works as expected. I suggest that you carefully examine the fields' translation settings on your site.
After correcting the custom fields translation options, you will need to update the original page and then its translations. If there are translations still in progress or require updating, you will first need to complete them and then proceed with the above.
Please let me know if you have any further questions.
Sorry for my late response. I would like to clarify the issue for your second-tier supporter, as I may not have explained it clearly, or there may have been a misunderstanding.
Almost all of our ACF Field Groups have the `"acfml_field_group_mode": "translation"` setting in their JSON files, which corresponds to the "Same fields across the language" option. According to the documentation (https://wpml.org/documentation/related-projects/translate-sites-built-with-acf/recommended-custom-fields-translation-preferences-for-acf-and-wpml/), this should mean that only Text, Text Area, and WYSIWYG fields are set to Translate, while the rest are set to Copy. As a result, fields set to Copy should not appear for translation in ATE. However, we are still seeing these fields in ATE, even after switching to Expert mode and manually setting them to Copy, they continue to appear.
This is the core issue: the ATE interface is not updating to reflect the ACF Field groups translation settings. It would be very helpful to have a way to force ATE to refresh or update its fields' settings based on the latest ACF Field groups configuration.
Additionally, regarding the sandbox test: since we were unable to fully replicate our translation process, the results may not be directly comparable to our live site. I just wanted to clarify this point.
To illustrate the problem:
1. ACF field translation settings are set to "Same fields across the language" and saved.
2. The Homepage is saved in the English version.
3. ATE for any language still incorrectly displays fields that are set to Copy, which affects the layout on translated pages (these fields are marked with a red rectangle in the attached images).
This issue affects ALL ACF field groups, not just "Gutenberg: Home hero" — that is just one example.
Thank you for providing additional input on your case. I have passed it on to our second-tier supporters and am awaiting their reply. I'll update you once I have it.
Hello,
Please note that this issue constitutes a critical bug which is currently blocking us from properly publishing and launching our website in multiple languages.
Could you please confirm whether this is a known issue and provide an update on the current status of work on fixing this bug?
Additionally, could you let us know when you estimate it will be resolved? Any information about the expected timeline for a solution would be greatly appreciated, as this issue is having a significant impact on our project.
Identifying known issues is one of the first steps we take when handling a new case. If we had suspected it was a known issue from earlier in this ticket, we would have told you about it. You can check our known issue page here: https://wpml.org/known-issues/. Please search for "Advanced Custom Fields" or "ACF". You are more familiar with your custom field settings than we are. Do you see anything that might be related? Moreover, you were unable to replicate this problem on a clean WordPress installation, which means that you are experiencing a unique situation on your site.
Since you're seeing unexpected results, we recommend switching to Expert translation mode and manually selecting only the specific fields that require translation.
In our experience, this approach tends to work best, particularly when working with repeater fields (if that applies to your setup). The default "Same fields across languages" mode automatically assigns translation preferences based on field type, which may not always align with the actual structure of your content. This can sometimes cause issues, especially with complex or nested field groups, such as repeaters or clones.
If even the Expert mode is unhelpful in your case, please allow me to take a copy of your site so I can esclate it to our second-tier support team. For this, I must install a plugin like Duplicator or All In One Migration. Please let me know if you agree.
Please note that my weekend is Friday to Saturday, and I'll be able to continue checking this issue and helping you on Sunday. As for the expected timeline for the solution, this is something we can't predict, mainly as we still don't know the cause of the problem. If the issue is escalated on Sunday, we will likely have a better understanding of the problem by Monday or Tuesday, which should help in advancing it.
I have reviewed the known issues page on your website, but unfortunately, I couldn’t find anything that could help us resolve the issue with the synchronization of ACF field settings and translatable fields in ATE.
As mentioned in my previous replies, I have already tested the Expert mode on multiple ACF Field Groups. However, in each case, it did not fix the issue. Even though we manually set the field values to "Copy", they still ended up being translated in ATE.
One observation I would like to share is that, based on what we’ve noticed, the issue with synchronization only occurs in ACF Field Groups that contain Clone fields. It seems that the problem specifically lies with these Clone fields' translation settings. The fields used as Clone themselves do not seem to cause the issue. For example, the "Gutenberg: Heading" field, which is used as a Clone in many components, when added directly to a page standalone, does not have its settings translated - only its text is which is a correct behavior. Perhaps the root cause of the issue could be related to this.
Additionally, I would like to strongly emphasize that we were unable to fully replicate the way we translated the pages in the sandbox environment. Therefore, it’s important not to assume that the issue doesn’t exist simply because it couldn’t be reproduced in that quick setup.
I would kindly request that you clone our dev site and attempt to resolve the issue in your test environment. The access credentials remain the same.
I've installed the All In One Migration plugin on your site, and now I have a copy of your site. After that, I deleted this plugin.
While being on the plugins sections of your site, I noticed that WPML and String Translation are not updated to their latest versions. Sorry for not seeing it before. You must update all of our plugins to their latest versions and check if the problem pesists.
I also noticed that although you have the ACF admin menu item, the ACF plugin itself is not installed. Can you please explain to me how you achieved this situation where all the ACF options are there, but the plugin itself is not installed?
If the problem persists, please specify the steps again to see the problem. Please mention the involved field groups and the involved specific fields. Also, please tell me which page I should translate with the Translation Editor to see the problem.
I have updated all plugins related to WPML, but unfortunately, this did not resolve the issue.
The ACF plugin is critical for our theme, and it is installed using the "Must-use plugins" mechanism and cannot be disabled. This is an option provided by WordPress and is commonly used.
For your reference, I will outline the steps again to replicate the issue in the ATE editor:
1. Save the "Gutenberg: Heading" or "Gutenberg: Button" fields, which are used as Clone in several other field groups, with all field translation settings set to "Copy".
2. Save the block fields where the "Gutenberg: Heading" block is used as Clone (e.g., "Gutenberg: Home hero"), with the translation settings of the cloned block set to "Copy".
3. Go to the "Home" page, where the "Gutenberg: Home hero" block is used, and save the English version.
4. Edit translation of the page using ATE in any language.
5. The fields of the "Gutenberg: Home hero" section, which are cloned from "Gutenberg: Heading" and are set to "Copy", will be visible here and will be translated (heading level, heading variant, extra classes).
My name is Carlos, and I’ll be assisting you today in place of Itamar.
I’ve reviewed the ACF configuration and was able to reproduce the issue using the latest recommendations. I’ve shared these findings with our 2nd-tier specialists, who will continue the investigation.
We’ll keep you updated and get back to you as soon as we have more information.
