It seems that there is a bug with webhook condition that’s checking if the Consent field is checked. In English and Croatian language when looking the raw data it clearly says:
“consent_1″:”checked”
But, in german language it says:
“consent_1”: “ausgewählt”
The issue is that the Webhook condition is only checking for the “checked” value and since in german language it is returned differently, the condition is never met. I tried to fix this for more than 2h no solution.
Quick fix: use the forminator-de_DE.po to change “checked” from “ausgewählt” back to “checked” and it works. But if possible please try to fix it in general.
In English it works because “checked” is correct English string. In Croatian it works “out of the box” with “checked” option because Croatina translation is actually very incomplete (currently at only 1% as far as I can see) so the “checked” string is not translated at all yet – which will cause plugin to use original “checked” word.
The German translation is way more complete and the word “checked” is already translated and it should still work just fine (I just tested it on my end and can confirm that) but:
1. if you have created the form using e.g. English or Croatian but switched site to Deutsch after that – it may be necessary to “reset” conditions (remove them and set them again) because they are stored with the form configuration and, especially if there is e.g. object cache on server, it may result in such issues
2. but more importantly (it also applies to point 1 above), it appears to me that you site may be multilingual and if yes – Forminator would need separate forms created for separate languages rather than the same form used and translated, as there’s no full WPML compatibility yet and no implemented compatibility for other multilingual plugins at all.
So basically, if the form was created e.g. in English (or one of the languages that don’t have the “checked” string translated yet) and use the same form with other languages that do have it translated – the issue will happen and that’s also why the “trick” with editing translation file worked.
Ultimately though, even despite incomplete translations it works if the Form is used “in single language” only – if language is being switched while the very same form is used, potential issues are due to no multilingual plugins compatibility (yet).
Hi, Yes, I do use WPML. But, I also have different forms for each language.
The only thing I did was “duplicate” english form and then translated it to german. I tried to “reset the conditions” but here’s the video showing that the “checked” is the condition that will be looked at and if the german translation is not altered (as I suggested but is left as default) the form is returning “ausgewählt” – making the condition not firing since it’s expecting the “checked” value.
I do understand what you said but I still think that conditions should work not by checking the translated value but somehow always have “default language” value checked – don’t know if that’s possible. That way, there would be no problem at all.
This reply was modified 2 years, 11 months ago by sonnic.
This reply was modified 2 years, 11 months ago by sonnic.
I do understand what you said but I still think that conditions should work not by checking the translated value but somehow always have “default language” value checked – don’t know if that’s possible. That way, there would be no problem at all.
I am afraid we don’t have a solution out of the box for that in Forminator since it is mostly related with the translation and multilingual plugins compatibility as Adam already pointed out.
Utilizing the “modified translation files” for German works. Is there any option to at least force specific translation file to be used so that each plugin update doesn’t override edited translation files? (Or any workaround using modified translation files)?
IMHO, I still think that this is a bug in the plugin and that functionality of webhook conditions should not be connected to any kind of translation. The conditions should check the default value (checked/unchecked or anything else) despite any translation/language used.
The translation is connected to MO/PO file this is why when you translated it worked.
Different from the regular select fields, the checkbox has only two states checked and unchecked so to reduce possible issues or conflicts it is easier for the user to skip any further configuration in the conditional and adding a fixed string ( translatable string )
However, I understand your point so I made a couple of tests and could confirm that when we use the native WordPress language in WordPress > Settings the string get translated, so, when I started a fresh site in English, added Portuguese ( as I know “checked” is translated ) and then tested it as well, the string got updated in conditional just fine.
Going further on my test I added to WPML German language and updated the translation using WordPress > Updates > Update translation and created a fresh form, got the conditional translated without any issues:
That said, your fix is correct, to translation be applied we just need to update the PO/MO file, translation are done by community and we don’t have control over the percent of each languange but I can confirm the translation is workign well.
I figured out what’s causing this issue. Using WPML you have the option to create content in different languages, but, as an administrator you can choose which display language you use.
Without WPML, you can choose language for the admin in the admin profile, but when you install WPML you can also choose which language is used as an editing language.
By default, WPML does not set the option in the user profile to “on”: Editing language: Set admin language as editing language. So, since my profile had the “site-default” language selected as editing language, even though I was creating e.g. “german content” the admin UX and everything inside WP was in english (e.g. “Publish button, etc.).
Now here is the problem, your code actually checks this, and this is what’s causing the problem. If you don’t enable Editing language: Set admin language as editing language in your user profile, then, even though you’re creating “German form” it’s inner logic is using “site default language” meaning it was checking if the field is “checked” rather than “ausgewählt”. The fix is, if the WPML is used to handle multi-language content, to enable Editing language: Set admin language as editing language. The only setback here is that the WP admin UX will also use that language.
Now, even though your plugin doesn’t have WPML compatibility, if this is turned on, the “form created in the current editing language” will have it’s inner logic use this language and will check the values in that language.
So, I don’t know if you can improve this to never have this kind of issues, by let’s say have the conditions check the “default language” values always, that way any language displayed will still check the “checked/unchecked” value no matter what the translation of that term actually is, if that makes any sense.
I assume that if there was full WPML support then there would be no issue with “editing language” and “content language”. Imagine you have to edit something in language you don’t understand at all or is using different alphabet, being forced to also have your editor and whole UX in that language complicates things a lot. That’s why I prefer having my editing language always in english, but with WPML until this issue I never had any issues of e.g. creating “german or croatian” content with having the admin/UX still in english.
Hope this clears things. 🙂
Thank you for the help! I love the plugin, the best Forms plugin there is, by far or at least with most needed functions in free version!
This reply was modified 2 years, 10 months ago by sonnic.
Why does the Prefix field in German/other languages does not return “translated” value but is still returning “Mr.” instead of “Herr” even though you choose “Herr” in the dropdown? (same for other languages too).
That’s a great find about the setting and thank you for sharing it! And yes, you are right – once the full compatibility with WPML is added, it won’t be a problem anymore. However, I don’t have ETA on this, I’m afraid. It’s planned for the future and will be implemented but I’m not sure when.
As for the prefix field:
I checked it and it seems that’s a bug that we weren’t aware of yet. I could replicate this and I don’t see any reasonable explanation for this behavior (I mean – nothing that would explain that being done “on purpose”) so I have already reported it to our Forminator Team as a bug.
They’ll look into it and include fix in one of future releases.
