Thanks so much for your reply, that makes sense and I totally understand.
I now just have another query for you if that's ok, so we have the site set-up as 'Same fields across languages' but we are now porting an English page direct to German, then editing the content, which is mostly fine apart from an ACF Link field just won't let us update it, it just keeps reverting back the English content, see screenshot below:
I understand the issue you're having. Since the 'Same fields across languages' is configured for the field group, by default, the translation preference for the Link field is set to "Copy". This is why, the link entered in the default language is always copied to the translation.
To correctly update the link field in the translated version, please follow these steps:
1. Go to "ACF → Field Group" and open the Field Group that contains the specific field.
2. At the top of the page, find the "Translation mode" option and click on "Change Option."
3. Select "Expert" mode from the options provided.
4. Scroll down to the Link field where you input the link.
5. Set the translation preference for that field to "Translate" and save the changes.
6. Open the default page containing the link field in the WordPress Editor.
7. Re-enter the link and save the changes.
8. Update the translation. If you are manually adding the translation using the WordPress Editor, the link field should now be editable, allowing you to add the correct link. If you are using the Advanced Translation Editor, refer to this guide(https://wpml.org/faq/how-to-translate-urls-shortcodes-and-html-attributes-using-the-advanced-translation-editor/#how-can-i-translate-urls-in-the-advanced-translation-editor) for instructions on translating links directly from the Editor.
Please let me know if that helps or if you need further assistance. I'll be happy to help.
Thank you so much for your help here, I completely understand, so we have now changed to expert mode, I then just a few last questions if that's ok, as below:
- In having to change it to Expert mode, it meant we had to go through and review all field settings as result, just to ensure all Link field types were checked, etc. which was a bit of pain.
So it made me wonder, the only issue that caused this was because of the Link field being set to 'copy' but actually on your set-up, shouldn't you allow this to be 'translate' because a Link field, unlike a URL field, will always have a link label, and that label will highly likely be a string which requires translation?
- In setting it to Expert, please can I check we can still benefit from 'You’ll be able to use automatic translation, WPML’s Advanced Translation Editor, and translation services.' in this setting? I believe we can, but wanted to check.
- And finally, you suggested changing this to 'translate' but can I check would we be ok to use 'copy once' as well as there are some cases where we will manually translate and so having it set to the original language to go through would be beneficial, although actually providing we can use the Advanced Translation Editor this would hopefully be irrelevant? As I assume both 'copy once' and 'translate' will work fine with the Advanced Translation Editor?
Many thanks again for your help, it's much appreciated,
Tonya
Sorry, just as a follow on from my response above, we have realised that in swapping to expert mode, it lost a fair few fields from our ACF Flexible content key field.
We have tried this again probably about 5 times with server adjustments around resources each time (disk space quota, PHP max memory limit, disabled Modsec on the domain, increased PHP max_execution_time and also the max number of database connections, increased the mysql max packet size) and a db restore each time, but no luck, it just loses probably over half the fields, they just disappear. Sadly my server team are out of ideas, but have shared this error from the mysql log in case this helps:
2024-04-21 10:31:46 138 [Warning] Aborted connection 138 to db: 'epsnet_wp_l6azk' user: 'epsnet_wp_hjepq' host: 'localhost' (Got an errorreading communication packets)
I am including a screenshot of the before and after as well so you can see the amount of fields before and after.
Really hoping you can pin-point the issue as at the moment we are now at standstill with content entry until we can get this resolved.
Hello Tonya,
I hope you;re doing well. Sorry for the delay in responding due to the weekend.
Let's try to address the concerns you have mentioned in your first message, first!
1. Link Field Settings - Translate vs. Copy: You're correct that a Link field typically includes a label which often needs translation because it is textual content. In most multilingual setups, setting the Link field to 'translate' is preferable to 'copy', as this allows for the label to be translated into various languages, reflecting the language of the user. The 'copy' setting is generally used for fields where the content does not need to change across languages, such as URLs or IDs. However, if your use case involves links where the URL itself changes based on language (like localized pages), then indeed 'translate' should be the default approach.
2. Expert Mode and Translation Features: Switching to Expert mode in ACF should not affect the availability of features such as automatic translation, the use of WPML’s Advanced Translation Editor, or translation services. Expert mode primarily gives you more granular control over how each field behaves with regards to translation. Please make sure that the translation settings for the fields are set to "Translate" to be able to translate the field contents automatically.
3. Using 'Copy Once' Setting: The 'copy once' setting can indeed be useful in scenarios where you might start with a direct copy of the content from the default language and then make manual adjustments or translations as needed. However, if you use the "Copy Once" option for a field, its data won't appear in the WPML Translation Editor. You'll need to manually add translations for the content in that field from the native WordPress editor. For more details, please check the link below.
I hope this makes things clearer! It’s great to see such careful consideration of the details in your configuration. If you have any more questions or need further assistance, feel free to ask.
Missing Fields from the "Flexible Fields" Issue: After reviewing the screenshots, I noticed the problem. The field groups are being saved as JSON files, and their IDs differ between the "Expert" mode and the "Same field across languages" mode. Could you please check the JSON file for the field group (group_6624d42dba994) and ensure it includes all the fields? If any fields are missing, you'll need to add them again to the field group, configure the translation settings for the fields, and save the changes.
Alternatively, you can open the JSON file for the field group (group_65ad81dac51b9) used in the "Same field across languages" mode, copy the fields, and then paste them into the JSON file of the expert-configured field group (group_6624d42dba994).
Please let me know if the information above helps in solving the issue or if you need further assistance in this matter. I will be happy to help.
Thank you for your detailed reply, it's much appreciated.
Now as a result of this, based on point one, when setting 'Same fields across languages' shouldn't your set-up preset the Link fields to 'translate' and not 'copy' as you have it currently? As if it wasn't for this issue, then we could have everything working perfectly. And I'm guessing there's no easy way for us to just adjust this part, and keep 'Same fields across languages' to avoid all these issues?
Also, if the above is not possible, it sounds like, by having to change it to expert mode (due to the limitation above), we now have to re-create all the fields? And sadly there's a lot to re-create. I'm surprised that changing the translation mode causes this, it doesn't seem ideal at all, is there anything that can be done about this? Equally do you know why it saves maybe around 30% of the fields correctly, as you'd think if this was all relating to the ID value it would either save either all or none, and not just some like it is now?
Default Setting for Link Fields: You raise a valid point about the default setting for Link fields. Ideally, in a scenario where you're using 'Same fields across languages', it makes sense for the Link fields to default to 'translate' rather than 'copy', given that the labels typically require translation to match the language of the content. But, since the "Same Field across languages" by default sets fields to 'copy'(Please check the default setting for each mode from here: https://wpml.org/documentation/related-projects/translate-sites-built-with-acf/recommended-custom-fields-translation-preferences-for-acf-and-wpml/ ), there's no straightforward option in the interface to change this default behavior for all Link fields at once.
Field removed in Expert Mode: Typically, when you update the Translation setting for a field group, only the translation settings themselves are modified; the field group's ID remains unchanged. However, in your scenario, the ID of the field group with Expert settings is different from the ID for the "Same fields across languages" setting. Essentially, these are treated as two distinct field groups. Because the field group set to Expert mode does not contain the same fields(Probably a same field group was created previously with "Expert" preference with only a few fields) in its JSON configuration as the field group set to "Same fields across languages," the fields are not displaying as expected.
I appreciate it's not a straightforward change, but as it's arguably a flaw, is this something your development team would consider changing in the future?
Then in terms of this this point: 'Field removed in Expert Mode: Typically, when you update the Translation setting for a field group, only the translation settings themselves are modified; the field group's ID remains unchanged. However, in your scenario, the ID of the field group with Expert settings is different from the ID for the "Same fields across languages" setting. Essentially, these are treated as two distinct field groups. Because the field group set to Expert mode does not contain the same fields(Probably a same field group was created previously with "Expert" preference with only a few fields) in its JSON configuration as the field group set to "Same fields across languages," the fields are not displaying as expected.'
We hadn't changed this prior to this request for it to have saved some fields, so in principle this can't have been saved previously. Also, the database has been restored yet again to original to get the lost fields back. So we have now just changed it from "Same fields across languages" to "Expert Mode" and it hasn't lost any fields at all (see attached). The difference being that we have not been in to update any link fields to 'translate' from 'copy'. So that is the only difference. But the facts here mean the point above surely is not the case then?
Just as another update I have now been in and changed only about 3 Link fields from 'copy' to 'translate' and that is still all working fine, no fields lost at all, etc.
So this does re-confirm that what you described as the problem, is actually not the problem.
But what this means is that we still have the issue where if we want to go in and update a lot more fields, that is when it seems to break down and lose fields, and that is what we really need to get to the bottom of the cause as at the moment we still have more fields to update, but don't want to go through losing them all again, to then have to restore the database yet again, meanwhile all content entry to the website is paused due to this problem.
Thank you for the detailed update, and I appreciate your efforts in clarifying the scenario. I'll try my best to sort this out for you.
From your description, it appears that when switching from "Same fields across languages" to "Expert Mode," and subsequently updating individual fields from 'copy' to 'translate', the system behaves as expected without losing any fields. This is good news as it indicates that the basic functionality related to field translation settings is operating correctly.
Now, considering the issue arises when updating a larger number of fields, it's important to consider all aspects of your setup, including the fact that ACF field groups are also saved as JSON. This detail is crucial because if the JSON files are not correctly synchronized with your database changes, it could lead to inconsistencies and potential loss of fields when those files are auto-loaded by ACF.
Please make sure that the JSON files for your ACF field groups are properly synchronized with your database. When you modify a field group via the admin area, confirm that the corresponding JSON files reflect these changes immediately. I also recommend using the Synchronization feature in ACF to synchronize the field group JSON with your current configuration. After synchronizing, please try to update the fields again. For detailed instructions on how to proceed with synchronization, please check the guide below. This will help you understand and follow the synchronization process step-by-step.
- hidden link
If the issue continues, it would be helpful if you could set up a test site by copying your main site. On this test site, please disable the ACF JSON feature and try to update the translation settings for the fields. This approach will allow us to isolate the problem by eliminating potential conflicts related to the ACF JSON synchronization, providing clearer insights into the underlying issue.
Another approach to help isolate the issue is to update the field settings incrementally. Instead of adjusting a large number of fields simultaneously, consider updating them in smaller groups. This step-by-step method may assist in pinpointing whether a specific field or a certain volume of changes at one time is causing the problem.
Please try the above suggestions and let me know how it goes. I'm committed to helping you resolve this so that you can proceed with updating your site without further disruptions.
Thank you for your reply, and please bear with me, we had to pause work on this problem due to a lot time lost, but will pick it back up early next week once testing has been done on your suggestion.
