[Resolved] acfml_should_translate_acf_entity not working as expected.
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is using the
acfml_should_translate_acf_entity
hook to control the translation of ACF fields based on their keys. Despite the function returning false for fields with keys including '_level', these fields still appear in the WPML translation editor. Solution: 1. We recommended verifying the translation settings directly in the PHP code for ACF fields and adjusting them as necessary. Documentation on setting translation preferences for ACF fields created using PHP can be found here: Setting the translation preferences for ACF fields created using PHP code. 2. For fields like links within repeaters, where only the label should be translatable, it's a known issue. A workaround is suggested while a fix is planned for ACFML 2.2.0. More details can be found in this forum post: Translating ACF link field in Advanced Translation Editor.
If this solution does not resolve your issue or seems outdated, please check related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. If the problem persists, we highly recommend opening a new support ticket at WPML support forum.
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.
Background of the issue:
I am trying to use the 'acfml_should_translate_acf_entity' hook for Advanced Custom Fields Multi Language. This code correctly returns true or false on fields that include the key _level. However, the field isn't removed from the WPML translation editor.
if (!empty($acfField['key'])) {
foreach ($excludedPatterns as $pattern) {
if (preg_match($pattern, $acfField['key'])) {
return false;
}
}
}
return $shouldTranslate;
}, 10, 3);
The response from this function: - These are the correct responses - the _level returning false should not appear in the WPML Translation editor at hidden link.
Symptoms:
The function behaves as expected by returning true or false, but fields with keys including _level still appear in the translation editor when they should not.
Questions:
Why are fields with keys including _level still showing in the translation editor despite the function returning false?
1) May I ask why you are using this approach and not setting the field to be translatable or not from ACF group translation settings?
2) Did you make a small change to the default language page, save and then re-translate? It needs an update for ATE editor to start new job, otherwise ,it shows pthe revious job content.
Hello! Thanks for getting back to me. Just to give a bit of detail around this problem:
1) We are using a PHP implementation for all ACF fields, and ACF fields are not created inside of WordPress, do not show up inside of the CMS.
2) I have "Cancelled Translation + Modified Content + Saved Post + Tried Translation Again".
- 2.1) Non of the ACF fields assigned to Gutenberg Blocks show up - in "Settings> Custom Fields Translation"
- 2.2) Additionally I have gone to "Languages > Edit Languages > Updated 1 value" to see if any updates are triggered.
---
I have double run each task mentioned above to double-check if it might resolve the issue, Again, every field shows in the WPML translation editor, rather than just the fields that return true. When running acfml_should_translate_acf_entity it does see every field, and run through them returning a value of either true or false based on the logic 🙂
I've attached an image, in effect the headings should not show as translatable content.
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
