Saskia Teichmann

Thanks for the clarification.

I’d like to point out that Contact Form 7 includes the wpcf7_form_elements filter, which allows developers to execute custom tags and actions within a CF7 form. While detailed documentation on this filter is limited, it is clearly intended for advanced developers who need to extend CF7’s functionality.

Using this filter is a legitimate and supported approach, but the issue remains: when custom shortcodes are executed using this filter, the translation logic doesn’t function correctly and in line with WordPress Codex due to the locale handling within CF7. My workaround addresses this gap, ensuring that translations are properly applied, which is crucial for multilingual sites.

It’s important to note that the incorrect locale assignment affects not only the execution of shortcodes but also the form itself. F.e. If a user has set their admin language to en_US in their profile but creates a Contact Form 7 form on a WordPress installation globally set to de_DE via WP_LANG, the form will be displayed in English on the frontend instead of German as expected. This approach to locale handling is problematic and not compliant with the WordPress Codex, as it prevents the proper loading of the text domain. In a multilingual setup, this behavior is simply unacceptable.

I hope this provides more context on why this issue matters not only for developers using CF7 in custom setups but also for any CF7 user. Thank you for your time and consideration!

• This reply was modified 3 days, 7 hours ago by Saskia Teichmann.

Good morning @takayukister

Thank you for your response. I understand that the form’s locale is set based on the user’s language when the form is created, which aligns with Contact Form 7’s design. However, the issue arises when shortcodes are executed within a form, as this behavior leads to unexpected and inconsistent translation results.

Here’s why it matters:

When a shortcode is executed in a Contact Form 7 form, get_locale() returns either an empty value or a user-based locale, which does not reflect the current site’s language settings (WP_LANG). This mismatch prevents the correct loading of translation files, even when they are fully functional outside the CF7 context. So, even if the expected behavior is for the form to inherit the user’s locale, it breaks the shortcode translation logic that relies on site-wide language settings.

In other contexts (like a regular page or post), the translations work perfectly. The workaround I created ensures that the correct locale and text domain are loaded, providing consistent translations.

Would you be open to considering a solution or modification to address this inconsistency for cases where shortcode translation is crucial?

Thank you again for your attention to this!

Saskia

Issue Description (Detailed Overview in Thread Link 1)

When enabling shortcode execution within Contact Form 7 (CF7) forms, the shortcode output fails to be translated, even though the translation files are correctly set up and functional. If the same shortcode is used outside of CF7, such as on a standalone page or post, the translations work perfectly as expected.

Root Cause Analysis

The issue appears to originate from how your plugin manages internationalization. Specifically, during form creation, the plugin adds a meta_key named _locale to the form’s post_meta data. The value of this meta_key is set to the current user’s locale rather than using WP_LANG, which is the language setting for the WordPress installation.

Consequently, when a shortcode is executed within a CF7 form, get_locale() returns either an empty or incorrect value, as described above. At this point, the required text domain fails to load correctly, despite being properly loaded in other contexts (e.g., when the shortcode is placed on a regular page, get_locale() pulls the correct value from WP_LANG, and the text domain loads successfully).

My Workaround

To address this incorrect internationalization handling by Contact Form 7, I implemented a custom solution in my child theme:

1. Helper Function to Fix the Locale

/**
 * Retrieves the fixed network site locale.
 *
 * Ensures the correct locale is used for the current network site, fixing translation issues within shortcodes.
 *
 * @return string The corrected locale for the current site.
 */
function get_fixed_networksite_locale() {
    // Retrieve the default locale.
    $locale = get_locale();

    // Fix translation issues by fetching the network site's locale.
    $wp_loc = get_blog_option( get_current_blog_id(), 'WPLANG' );

    // Use 'en_US' if the 'WPLANG' option is empty.
    $wp_loc = empty( $wp_loc ) ? 'en_US' : $wp_loc;

    // If the current locale differs from the network site's locale, use the network site's locale.
    $locale = ( $locale !== $wp_loc ) ? $wp_loc : $locale;

    return $locale;
}

2. Helper Function to Ensure Text Domain Is Loaded

/**
 * Ensures the child theme's text domain is loaded.
 *
 * @param string $textdomain The text domain to load.
 */
function ensure_child_theme_textdomain_loaded( $textdomain ) {
    // Use the fixed locale.
    $locale = get_fixed_networksite_locale();

    // Check if the text domain is already loaded.
    if ( ! is_textdomain_loaded( $textdomain ) ) {
        // Construct the .mo file path based on the locale.
        $mofile = sprintf( '%s.mo', $locale );
        $domain_path = get_stylesheet_directory() . '/languages';
        $loaded = load_textdomain( $textdomain, path_join( $domain_path, $mofile ) );

        // Log a message if the text domain could not be loaded.
        if ( ! $loaded ) {
            error_log( "Failed to load text domain: {$textdomain}" );
        }
    }
}

3. Applying the Fix in My Shortcode

/**
 * Outputs the GDPR consent notice for artwork uploads.
 *
 * Generates a GDPR notice with translated text using the 'tm-design' text domain.
 *
 * @return string The GDPR notice HTML.
 */
function tm_upload_dsgvo_ausgabe() {
    // Start output buffering.
    ob_start();

    // Load the text domain for translations.
    ensure_child_theme_textdomain_loaded( 'tm-design' );

    // Construct the GDPR notice with translations.
    $dsgvo_out = '<span class="newline">' . sprintf(
        __( 
            'Yes, I have read and agree to the %1$s and %2$s. I consent to my uploaded file and provided information being used, for example, as an image in the TOPModel Artwork Gallery or for posting on the TOPModel Instagram page.', 
            'tm-design' 
        ),
        get_privacy_html(), // Privacy policy link.
        get_nutzungsbedingungen_html() // Terms of use link.
    ) . '</span>';

    // Output the notice and return the buffered content.
    echo $dsgvo_out;
    return ob_get_clean();
}

// Register the shortcode for use in CF7 forms.
add_shortcode( 'tm-upload-dsgvo', 'tm_upload_dsgvo_ausgabe' );

Demonstration of the Fix

Thanks to this workaround, the shortcode now outputs translations correctly, even within CF7 forms. Here are examples in different languages:

• German (de_DE): Kunstwerke Upload Form
• English (en_US): Artwork Upload Form
• French (fr_FR): Oeuvres d’Art Formulaire
• Spanish (es_ES): Obras de Arte Formulario
• Danish (da_DA): Kunstgenstande Form
• Swedish (sv_SV): Konstverk Form
• Finnish (fi_FI): Taideteokset Form

Final Note

Without this code, shortcodes used in Contact Form 7 forms will not be translated. I am puzzled as to why this issue hasn’t been addressed yet, despite being reported multiple times. I hope this explanation helps, and I would be grateful if you could consider fixing this problem.

Thank you for your attention.

Saskia

P.S.: please find a descriptive gist here: https://gist.github.com/s-a-s-k-i-a/b63668a8fef246293ce8931c80e1b0e2

@takayukister

WordPress 6.7?changes the way translations are loaded, aligning with?best practices for internationalization. This shift affects how and when translation strings should be triggered, aiming to prevent potential issues that arise from loading translations too early.

Thus Contact Form 7 users encounter?warning notices, that look like this:

_load_textdomain_just_in_time was called incorrectly. Translation loading for the <PLUGIN> domain was triggered too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /srv/htdocs/wp-includes/functions.php on line 6087.

What is status quo on this bug @translatepress?

It also is an issue for people using TP with RankMath and stripping categorybase..

It’s working now as expected! Thank you!

Sorry for not getting back to you earlier!

We are using your plugin on a WordPress Site where native locale is set to German (Formal). TranslatePress provides the following languages: English, French, Spanish, Russian

I will let you know if the latest update fixes reported issue.

Thanks for your quick work on this!

I managed to find and fix the issue. For anyone experiencing the same issue:

check if you have WP Armour installed and enabled. If so, please double check, if you have setup the tool properly (meaning: did you setup the honeypot key etc.)

IF you missed setting up the honeypot key, contact form 7 will not validate.

SO: fixed by completing set up enabled plugin WP Armour.

Hello Jainil!

Formcode here:

<div class="upload-formular tm-form"><div class="tm-form-row"><div class="tm-form-col">[text* your-first-name placeholder "Voornaam*"]</div><div class="tm-form-col">[text* your-last-name placeholder "Achternaam*"]</div></div>
<div class="tm-form-row"><div class="tm-form-col">[text your-instagram-name placeholder "Instagramnaam"]</div>
<div class="tm-form-col">[email* your-email placeholder "E-Mail*"]</div></div>
<div class="tm-form-row"><div class="tm-form-col">[number* your-age placeholder "Leeftijd*"]</div>
<div class="tm-form-col">[text* your-city placeholder "Woonplaats*"]</div></div>
[textarea your-message x4 placeholder "Mocht je bij je foto nog iets willen mededelen ..."][file* file-kunstwerk filetypes:jpg|png id:werksfile limit:512kb]<label for="werksfile" data-multiple-caption="{count} Kunstwerk gekozen"><i class="fas fa-palette"></i> <span>Je kunstwerk kiezen<span class="newline">(Maximaal toegestane bestandsgrootte: 512kb, mogelijke formaten: .jpg- of .png-bestanden)</span></span></label>
<div class="app customCheckbox">[acceptance acceptance-629][/acceptance]<strong>Toestemmingsverklaring gegevensbescherming*</strong> [tm-upload-dsgvo]</div>
[submit "Nu uploaden"]</div>

Other plugins related to CF7: Post My CF7 Form

However I am using this setup on all network sites – this is a multisite installation. Same theme- and plugin code can be found on all language sites (network subsites). All other language sites forms work just fine and validate properly. It is only the dutch site / netherlands, where the form is not acting as expected.

I was able to fix this issue.

Maybe this helps someone and maybe Takayuki will change his plugin code so this issue won’t come up anymore. My fix is just a workaround and is not updateproof. You will have to implement this fix on every contact form 7 update, as the function I am modifying is not pluggable / does not provide a filter:

find contact form 7 plugin directory, navigate to following file:

/wp-content/plugins/contact-form-7/includes/l10n.php

and add following lines to function wpcf7_switch_locale() :

$wp_loc = get_blog_option(get_current_blog_id(), 'WPLANG');
$locale = $locale !== $wp_loc ? $wp_loc : $locale;

this is the modified function:

/**
 * Switches translation locale, calls the callback, then switches back
 * to the original locale.
 *
 * @param string $locale Locale code.
 * @param callable $callback The callable to be called.
 * @param mixed $args Parameters to be passed to the callback.
 * @return mixed The return value of the callback.
 */
function wpcf7_switch_locale( $locale, callable $callback, ...$args ) {
	static $available_locales = null;

	if ( ! isset( $available_locales ) ) {
		$available_locales = array_merge(
			array( 'en_US' ),
			get_available_languages()
		);
	}

	$wp_loc = get_blog_option(get_current_blog_id(), 'WPLANG');
	$locale = $locale !== $wp_loc ? $wp_loc : $locale;

	$previous_locale = determine_locale();

	$do_switch_locale = (
		$locale !== $previous_locale &&
		in_array( $locale, $available_locales, true ) &&
		in_array( $previous_locale, $available_locales, true )
	);

	if ( $do_switch_locale ) {
		wpcf7_unload_textdomain();
		// switch_to_locale( $locale );
		wpcf7_load_textdomain( $locale );
	}

	$result = call_user_func( $callback, ...$args );

	if ( $do_switch_locale ) {
		wpcf7_unload_textdomain( true );
		restore_previous_locale();
		wpcf7_load_textdomain( $previous_locale );
	}

	return $result;
}

This fixed translation issues regarding gettext wrappers inside my custom shortcodes used in CF7 forms.

For some reason you are saving meta data to the post_meta table of each form with key _locale
Depending on current user’s profile language setting during form creation, value of this meta data key will be set.

It would be better if this meta value was pulled from WP_LANG set in current blog’s settings. If that value changes, that meta value should be updated for any form automatically. I am guessing that issues regarding custom shortcodes with gettext wrappers inside their code will then work properly…
@takayukister

We are seeing the same issue. when we enable shortcode execution for CF7 forms, the shortcode output will never be translated, even though perfectly working translation files are in place. When I place the shortcode in question outside cf7 – in some empty page or post, it works just fine and gets translated as expected.
@takayukister So, please help and give this a try on a test installation of your own.
thank you

Same issue as described here: https://www.ads-software.com/support/topic/email-not-sent-30/

Please close this thread and follow at above forum url.

This happens as well as after upgrading to latest version (6.0.0) and when downgrading to last 5.x version.

Same issue here. I am downgrading and waiting for a fix ??