Hi,
We are experiencing an issue with translating description fields in our Patterns using WPML.
When translating Patterns, the description fields do not appear in the translations, neither in EN nor in FR.
Increasing the PHP memory limit and clearing WPML caches did not resolve the issue.
We tried deleting the old translated Pattern and translating again after updating the ACF configuration (wpml_cf_preferences), but the description field still does not appear in translations.
As a temporary workaround, creating a new field (e.g., 'Description Content') allowed us to translate only the first line of the description. Removing the old field allowed it to appear, but this worked only once.
The problem seems inconsistent and appears in multiple different blocks within Patterns.
I have made some tests and here are the results. I exported the field group Hero With Icons and imported it into my test site. All the fields appeared correctly and they were translated successfully. This confirms that the issue is not related to the field configuration itself, but to something specific on your site.
You also mentioned that this works on another site, and we already know that changing the field name makes the issue go away. This points to a possible case of duplicate field names with different settings.
For example, there could be another field in a different field group with the main field name icons and a sub-field named description. This would generate a field key like icons_0_description. If that other field is set to copy, then its setting will be applied instead.
Could you please check if any other field groups on your site use the same field names? This will help us confirm if there is a conflict.
i confirm i've multiple fields with the name "description" across multiple ACF blocks. But i've checked and they have all the correct translation mode setting to "translate", no text field across my website is set to copy.
ATE hides the first ACF block "description" field. Here is a video showing this exact behaviour, where initially you can see "Acf/Grid/Description" on ATE editor ( 2nd block ).
After i change "Grid" block position to 2nd in page, the field "Acf/Grid/Description" is hidden.
Also initially the job field "Acf/Jobs/Description" is hidden, and after i change "jobs" block to 2nd position, the field "ACf/Jobs/Description" is now visible.
here is the video where i display this exact behaviour: hidden link
Sorry, but we were checking Hero with the Icons block. I thought the issue was with them.
Now I have checked the page you mentioned in the screencast. In your screencast, I noticed you are not completing the translation but saving it and editing it.
When you edit the translation without completing the previous one the jobs is not udpated and you see old strings.
The strings you see are changed because the value of those strings are changed in String Transaltion but new strings are not registered.
I recommend that you complete the translation before each change.
I made this test again and I see the description from the first block. Please see my screencast hidden link I am using same page you trashed.
Please let me know which block/page I should check and keep it in the page/post list for testing.
I can confirm that the issue is no longer occurring and that the description fields are now consistently displaying in the ATE editor.
That said, Iām still curious about how the issue happened in the first place and why it appears to be suddenly resolved. At the moment, whenever I create a new pattern on any content, the description field displays correctly, whereas previously it did not.
The reason could be that you were seeing old jobs. To make sure you see new jobs, always complete the previous job before updating the content.
OR
It could be that I resaved the custom field settings, which can sync your custom field settings from config to WPML settings. Generally, it saved automatically when you import the field or save the custom fields, but maybe we were having wrong preferences somewhere in the DB.
PS: There is no bug with this feature I have tested this locally on my test site with your custom fields. So maybe it was just a DB glitch.
