[Resolved] Use of the wpml_cf_preferences and consequences
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is developing a site and using WPML to streamline the translation workflow. They have a custom field to set a menu on a specific post type and want the same menu on translated pages without needing to translate the menu name or set it manually each time. They are experiencing issues with unnecessary translation requests for some values. Solution: We explained that there isn't a specific option to control this behavior directly when it's set to 2, as the ACF translation is activated regardless of the input provided. We suggested using the "Different fields across languages" option, which allows translating the input method directly as a string. For more details, see the documentation on translating ACF field labels with WPML.
If this solution does not apply to your case, or if it seems outdated, we recommend opening a new support ticket. We also highly suggest checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Symptoms:
I keep sending some values for translation when these are not needed.
Questions:
What does wpml_cf_preferences do?
What can I expect from using wpml_cf_preferences?
How can I avoid repeatedly asking for translation for the menu name and setting it manually?
Hello!
wpml_cf_preferences sets the custom field behaviour - whether it is copy, translate or to be ignored.
It is the same as setting the custom field from WPML > Settings > Custom field translations, except that it is done in the config.
The menu usually is a taxonomy term and not related to custom fields.
If however, you have a field which contains a menu name inside of it, then perhaps that field should be set to "Copy" and have value of 'wpml_cf_preferences' => 1 (provided that the menu name is absolutely 1:1 the same between languages).
That's correct. The value "0" indicates that it will be ignored and not available for translation. You can find more details here: WPML ACF Translation Settings.
- 0 would basically remove the menu from the translations
- 1 would add the (translated) menu in the translation
- 2 would offers choice for the menu I want to add.
It's worth mentionning that, after changing the value, we get a notice from the top bar, that >WPML is uptating this custom field along what's just been set.
Only after that, I can see the difference from the ATE.
Now, sorry, I have another question...
When I put the value back to "2", and once the WPML update process is done, I do get the menu entry from the ATE (that's what I expected).
However, from the ATE, it's displayed as an open field, so that I can put whatever I want as a translation, even non existing choices.
For fields for which limited choices are set in the ACF setup, it would rather make sense to get a dropdown menu with these choices.
I did a test, if I put a value that's not among the predefined field choices, it just gives nothing in the frontend.
there isn't a specific option to control this behavior. When it's set to 2, the ACF translation is activated regardless of the input you provide within the segment. This ensures you have complete control over your translation.
Imposing a predefined input limitation could create issues for other clients with different requirements. For example, consider a scenario involving a post ID. If the post ID is 15 and the translation result is 20, incorrect input would lead to the same problem. In this requirement, you usually need to add an ID or input because WPML doesn't know it's connected to another resource.
I kind of understand what you explain, but I'm specifically talking about a restricted field here.
While I understand your point about the post ids, we tackle this issue differently.
In our case, we never provide a post ID through WPML, it'd just be too complex for a standard / non developer translator. Here, to set this menu, we provide a value (which corresponds to a menu, or no menu at all), and these value are the same whatever the language, so that it provides the right menu, in the right language, whatever the language. I'm not the developer, but I suppose these values are mapped to the right correponding IDs in the backend.
By the way, what I point here is that if an ACF is a dropdown menu, and if it's offered for translation as translated, then its translation options should also be a dropdown menu, offering this dropdown menu's restricted choices translation.
I can't think of any reason why we would want to set a value that doesn't belong to the restricted choices defined for this field.
Allowing open input where only restrited choices are expected is just a open door to issues, which we should be able to prevent.
I understood what you mean regarding the post ID—it was just an example. However, at this time, we don't have any plans to modify the editor's interface to include an option for selecting values. Additionally, this information isn't included in the translation file our editors receive.
