The following is our second-tier supporter's findings about this case.
I checked your site and confirmed that fields set to Copy are still being offered for translation in ATE, which should not happen.
While reviewing your field group settings, I noticed several fields (such as Accordion and Tab fields) are incorrectly set to Do not translate, when they should likely be set to Copy or Copy Once. This could be affecting the nested or cloned fields, so I corrected those settings on my local copy and tested again.
However, correcting these settings alone did not fully resolve the issue.
I also saw that the sandbox you mentioned did not include your custom theme, which is required because it registers the custom blocks used by these field groups. When I added your theme to the sandbox, it crashed.
To continue, I exported a subset of your field groups and your custom theme to a new test site and could reproduce the same problem there.
Interestingly, when I created a new post using the same field groups (outside the custom block setup), everything worked as expected: fields set to **Copy** did not appear for translation in ATE.
This suggests the issue is specific to the combination of your custom blocks and custom field groups, rather than the ACF settings alone.
Could you please clarify how and where your custom blocks (especially the "Home Hero" block) are registered? This will help us focus on the root cause more effectively.
Could you please provide this information to our second-tier supporter?
Our second-tier supporter has found the source of this problem and escalated it to our developers. He explained that the problem is with the prefix of the field name. Please see the attached screenshot. As a workaround, unless it is essential and you cannot, please remove this prefix setting, and it should resolve the problem.
When we have news from our developers about this case, we will update you here.
Yes, however, please know that our developer considers disabling "Prefix Field Names" in the Clone field as a valid workaround. He added that this is the default state. We will publish an errata page about it. To set expectations, I must mention that there will probably not be a permanent fix for this until this weekend. Furthermore, our developers will evaluate the priority of this case, so I can't promise it will be fixed soon.
I'm sorry, but I have no update on this. My previous reply is still valid. From my standpoint, our developers might consider this an edge case and not give it high priority. This may change if we get more reports about this case.
It's hard for me to answer this, as WPML and all of its add-ons are currently deactivated on your site.
It could be due to the Prefix Field Names option. If it is checked, then it is the same issue. If you believe it's a different issue, please let me know.
