Provide a way to change form's locale

[chesio]

This is not really a bug report, more a suggestion.

I recently upgraded to Contact Form 5.7 (5.7.2 to be precise) and suddenly a shortcode placed within one of forms stopped working - the rendered contents have not been translated via __() function anymore and I had to manually change form's locale in the database from de_DE_formal to de_DE to get it working again as the website frontend is set to de_DE locale.

I'm not an expert in l10n stuff in WordPress - I would assume that WordPress should load de_DE_formal translations for all plugins and themes as soon as Contact Form 7 switches the locale to de_DE_formal when rendering the form. But this somehow did not happen. The website has multiple languages on frontend and I am using Polylang for multilanguage, so I cannot rule out the possibility that Polylang somehow interferes here. The site had used de_DE_formal for German at some point, but now uses de_DE instead. Before Contact Form 7 version 5.7 it made no difference.

Anyway, I think it would be nice to have an option to at least inspect and ideally also edit form's locale form WordPress admin. This way one could quickly see whether there may be a problem. An option to select form locale when creating new form would be an extra bonus. I guess I am not the only one that has backend user with en_US set as backend language even on websites that do not have English version on frontend at all (now I always have to change BE user language before creating new form and I forget about it from time to time...).

My environment (just in case):

WordPress: 6.0.3 Contact Form 7: 5.7.2 Polylang: 3.3

Site Language in General Settings is set to de_DE. In addition, en_US and de_DE_formal locales are also installed.

Languages configured (added) via Polylang: de_DE, en_GB, fr_FR.

[takayukister]

I feel rather that this is a matter of locale fallback mechanism such as that which attempts to automatically load the de_DE translation as an alternative when de_DE_formal is missing, and vice versa. I'm not sure if this should be implemented in Polylang or WordPress core, though. At least, I don't think this is the form plugin's matter. You don't think it will be ideal if you have to manually change the locale of a form one by one, do you?

[chesio]

@takayukister Thanks for getting back to me.

The thing is that de_DE_formal translation is not missing, it's just not loaded. As I said, I'm not sure who to blame (WordPress, Polylang or Contact Form 7). I'll see if I find some time to investigate it, but it won't happen soon.

If I may ask: why this locale switching has been introduced in recent version of CF7? If I understand the change correctly, any CF7 form now always renders in the locale/language it has been created in - even if the actual locale of a front-end page with the form is different? I would say it can be a BC break for some websites. I'm not saying BC breaks are bad, I'm just curious (as a fellow WordPress developer) what is the motivation for such change?

Anyway, if you don't see the need for my suggested change, feel free to close the issue.

[takayukister]

To say precisely, there was a bug that a contact form wasn't displayed in its locale. So, I had to introduce a bug-fix in 5.7. Yes, it can be called a backward compatibility break, but it's a necessary BC break.

But, in most cases, the front-end page locale and the contact form locale on the page should be the same. When the both locales are the same, locale switching won't happen. This is why most users have not realized the BC break.

Anyway, if you don't see the need for my suggested change, feel free to close the issue.

I'm interested in this discussion, so let me keep it open. If you will share more detailed information and your findings, I'll be happy to look into it.

[Zodiac1978]

I feel rather that this is a matter of locale fallback mechanism such as that which attempts to automatically load the de_DE translation as an alternative when de_DE_formal is missing, and vice versa.

WordPress is not loading any fallback languages because it is not easy to decide which fallbacks should be used for every language (this could be a very hot topic to discuss). But there are at least two plugins to solve this issue.

Especially useful for formal or other variants: https://wordpress.org/plugins/language-fallback/ from @2ndkauboy and https://wordpress.org/plugins/preferred-languages/ from @swissspidy

Maybe these could be helpful in this case @chesio?

[chesio]

Hi @Zodiac1978, thanks for the links, I'll check them out. I solved this particular problem by changing form's locale to match frontend locale, but they might be useful in other situations.

WordPress is not loading any fallback languages because it is not easy to decide which fallbacks should be used for every language (this could be a very hot topic to discuss).

Yeah, it's been a topic for quite a while, I don't think anything will change in this regard soon: https://core.trac.wordpress.org/ticket/28197

I think however the issue here is a bit different - the locale is being switched by CF7, but the translations for switched locale are not being loaded. I'll give it closer look if I find some spare time.

[swissspidy]

FYI there is a bug in locale switching in WP core 6.1 that will be fixed in the next release. See https://core.trac.wordpress.org/ticket/57116

That might be the culprit here.

[Zodiac1978]

My environment (just in case): WordPress: 6.0.3

Looks like this is not the problem @swissspidy if this was introduced in 6.1.

[chesio]

If this issue is really tied to WP 6.1 then it must be something else. Anyway, thanks for heads up @swissspidy, at least I know that there have been changes to this part of WordPress in recent version.

[chesio]

Small update: I just had the same issue on a website with single language only where contact form had de_DE locale and frontend was set to de_DE_formal locale, so Polylang as source of this issue can be ruled out.

[vhiltunen]

Hi! Found this discussion while investigating strange issue on our site that translations (via __() function ) were not being loaded on certain pages' sidebars. It appeared to be issue with those pages having some (older) CF7 forms which had _locale en_US. Our front-end uses locale fi, and I assume it has always been using, so little strange why any forms had en_US...but who knows. And indeed the issue seemed to be introduced after CF7 5.7 update, as roll-back to 5.64 had no issues. Ended to fix this by updating en_US locale values to fi in db via update_post_meta as suggested. Not nice but seems to work.

But agree with @chesio, that it sounds little strange why someone would like to show contact form in different language than front-end page in general. Especially if user has no UI setting to change the locale of the form.