Rob de Cleen

@moritzcito Thanks for the tip, I will look into it

I do love your plugin, it is great in many respects. Just trying to point out the issues encountered.

While I understand the reasoning behind following the language setting of the user creating the new form, i.e. to present a local language form template, setting the locale this way has (unintended) consequences.
If for example an Italian admin creates new forms (Add button) for EN, DE and FR, they will all get it_IT locale.
If that admin uses a duplicate from a previous EN form (en_US locale) and adapts it to create an NL mail form, it will preserve the en_US locale.

None of these forms will display with their shortcuts on the designated language pages because of a locale mismatch. It would be great if there was a simple dropdown box to set the form locale, either that or maybe rethink the locale approach as a whole. Not every user has the ability to change the form locale in phpmyadmin.

Hi,

I think I have found the issue, it’s in the unnecessary (and inaccurate) locale which CF7 sets (adds) to the forms.
On my devsite (en_US) both forms (EN and NL) had en_GB set as their locale, which is my admin user’s language setting…

If I use phpmyadmin to change (in the postmeta table) the locales to en_US for the EN form, and to nl_NL for the NL form, then the front end correctly shows the EN form on the EN page and the NL form on the NL page, with latest Falang (1.3.66) and latest CF7 (6.1.1).

It seems to be an old issue, found it here:
https://ww.wp.xz.cn/support/topic/contact-form-7-messes-translations-up/

So CF7 mixes up the form locale and the site locale, somehow it does strange things. The forms should have NO locale set in my opinion? Or at least have the option to easily change it? Can this be fixed?

Rob

Related link:
https://ww.wp.xz.cn/support/topic/contact-form-7-loads-wrong-language/#post-17168206

• This reply was modified 8 months, 4 weeks ago by Rob de Cleen. Reason: related link added

Hi, is there any news at all on this issue?

To rule out possible shortcode errors, I have (on a test site) set both the EN and translated NL form on the same page. Then translated the page. With CF7 6.1 only the EN page shows both forms correctly. The NL page (translated page) gives the “form not found” error for both the EN form and the NL form…

Rollback to CF7 6.0.6 and all is okay again…

Theme: Enfold
Plugins:
Akeeba Backup CORE for WordPress
Avia Special Character Converter Plugin Version
Booking Calendar
Catch IDs
Classic Editor
Classic Widgets
Contact Form 7
CookieYes
Disable REST API
Display Posts
Easy WP SMTP
Enable Media Replace
Falang multilanguage for WordPress
Falang Pro
Flamingo
Image Alt Text
Loco Translate
Manual Related Posts
Optimize Database after Deleting Revisions
Phoenix Media Rename
Query Monitor
Really Simple CAPTCHA
Regenerate Thumbnails
Travelers' Map
Widget Options
Wordfence Security
W3 Total Cache
WP Express Checkout
WP Rollback Version
WP Sitemaps Config

But how is this relevant? CF7 6.0.6 works fine, 6.1 has the issue with finding the second contact form…

Thanks for looking into this

• This reply was modified 10 months, 3 weeks ago by Rob de Cleen.

Hi,, thanks for getting back to me. Yes, the specification in the plugin of the thousand and decimal separator works fine, as does the translation of the descriptions in the backend. But for translations to have a different specification of those keys (, instead of . and . instead of ,) those two keys need to be translateable as well (to show on the frontend), which they are not now. So they are now fixed across languages as specified in the backend.

Excellent, thanks for your hard work!