Problem 1: we are trying to setup a group that contains fields with "copy" and "translate". When we set the group to 'copy' everything works, but also the fields set to "translate" are locked. If we set the group to "not translate" or "translate" we get a weird validation error that one of rows are reaching the limit, while this is not true (see video: hidden link)
Problem 2: we also make use of repeater fields, which contains 2 fields set to 'copy' and 1 to 'translate'. But it seems that when the repeater field is set to 'copy', all fields inside will be set to copy as well. Can we prevent that?
Link to a page where the issue can be seen: we implemented some detour, because of these bugs. So we don't have live environment to show you the problem.
FYI: we have been using WPML for 5 years now and have been seriously struggling with ACFML since the start. This month we where actually on the verge of moving to another translation plugin because the plugin was just very unreliable. Now with the 2.0 version, the plugin seems a bit more stable. So we are willing to give it another chance, but we can't really afford to make more multilingual sites this unreliable. Is this something we can rely on in the near future, the reason we ask if that we posted many support tickets in the past but never got working solutions for years.
As you know, ACFML 2.0 marked a major upgrade to working with ACF, prompted by the experience of users such as yourself that have had problems with the integration in the past.
The changes should make it easier to work with in future, and less prone to problems. If you had a site that was working smoothly with the previous version it should continue to work, but if you are making any updates or changes, it still requires care to make sure the settings are as needed.
There is one key point that can lead to problems that we should verify first.
Is the ACF field group post type itself set as translatable?
In prior versions it was not translatable by default and was recommended that it not be translatable, although there was nothing to stop users from making the field group post type translatable.
With ACFML 2.0 it is no longer possible to have the field groups be translatable, and if on your site they are then you should follow the steps outlined in this linked document to remove any translations of field groups without losing translations of field option labels:
(The Group field is a bit different than the other layout fields, in that it will not have a variable number of sub-fields in the way that a repeater field might; if you set up a Group field with 3 sub-fields then the group will have 3 sub-fields. So I think it makes sense to use Copy when you also intend to Copy the sub-fields so that they are the same across languages, and to use Copy Once when you intend to translate the sub-fields.)
Anyway, please check the translation setting for the field groups themselves (to confirm they are not translatable, and if they are, to use the steps in the linked document above to change that).
Let me know what problems persist after that, if any.
Thanks for you elaborated answer! Below you will my feedback:
1. The ACF field group post type is not set as translatable, we also never found the need to do that in all the years we use WPML. I think the weird error (see problem 1) is showing because of a incompatibility between ACFML and ACF. Could you look into that?
2. You mention, to use the recommended settings for individual fields and thus set "Group" fields to "Copy" or 'Copy once' based on the sub fields. We have always tried to use the recommended settings, but the thing is that we mainly use one parent group with everything inside, so we can get all data in one get_field(). This means that a group always has fields inside that need to be copied and translated. If we set the group to copy the translate fields are locked and if we set it to translate the copy fields are not copied.
How would you recommend we deal with this, just avoid having one parent group?
From a developer eyes view, wouldn't it be more logical to change the way ACFML works and disable the translation setting for certain fields like "Group", "Clone", "Tab" etc? This way copy and translate fields can be combined in one group. For the repeater fields, I understand to keep the ability to copy/ translate and thus all fields inside should be copied
3. One more follow up question: we use to work with ACF flexible layouts to build pages and it was possible to sync these layout but it was not working smooth. Now, we moved to another system where we use ACF composer to build custom Gutenberg blocks with ACF fields. Is there a chance these blocks can also be in sync in the future?
I just created a clean test site and tested all the permutations of translation preferences for the Group field and then fields that are within the groups, and in my case it all appeared to work as expected (although "as expected" means that it doesn't make sense to use the Copy setting for a Group field if some of the sub-fields need a different setting).
I recorded a quick Loom video to talk you through what I did, do you want to take a look and if you have a different experience then we'll need to look into why.
hidden link
1. I'm going to see if I can reproduce problem 1 based on the video you shared earlier.
3. This should already be possible, I've had clients before that are using custom ACF blocks with data coming from assigned field groups, and the field values are offered for translation when editing the content the blocks are added to.
(It's not obvious—given that you would be translating content—that String Translation is needed for this to work, as well as ACFML.)
I'm not seeing any validation errors for the number of rows when I use what I think are the sensible settings for the fields.
I'm using Copy Once for the outer Group field, as well as for the schedule repeater field.
That contains a select field for the day, which is set to translate so that the day labels can be translated, as well as another repeater field for the hours, which is set to copy, because its sub fields (the from and to time fields) don't need translating and should be the same in different languages.
Thanks, just tested and copy once on the group seems to be a solution on how to combine 'translate' and 'copy' fields. Also experimented a bit more with repeater fields, do you agree that in here it's not possible to combine them right?
Concerning the minimum rows reached, I replicated that just now again. This is how my layout looks (can also share the JSON, if possible let me know):
Group (don't translate/ translate)
Repeater (don't translate/ translate)
Text field (any setting)
Repeater (copy with min: 1 and max: 2)
2 timepickers inside (copy)
About the blocks, the translations work (at least when we work with the WP editor). But, if we set all fields to copy for block field groups we get no fields with a lock or copy behaviour.
From your last reply it sounds like you can reproduce the issue when using either Not Translatable or Translate settings, neither of which are recommended.
If you use the recommended settings, do you still see the issue?
Regarding custom ACF blocks where the assigned fields have a Copy setting, when I test this and I translate a post (that contains such a block) using the translation editor, it works, inasmuch as when I later edit the translated post with the WordPress editor I can see that the field value was copied across.
However, the UI for such fields is different than the normal for ACF custom field groups assigned to the post (which appear in metaboxes at the bottom of the screen). In this case they appear in the block sidebar settings, and it is true that in this case the field is not locked in the same way that it would be with a normal post custom field. (My screenshot.)
Is that what you are referring to?
I think I'd need to raise this with the developers, but before I do I wanted to clarify we are talking about the same thing.
The topic ‘[Closed] ACFML has problems when trying to combine "translate" and "copy" setting’ is closed to new replies.
