Site language vs. admin language

  • ixiter

    (@ixiter)


    2 weeks, 3 days ago

    My site language is English, but my admin user language is German.

    When I create or edit a form, WPForms currently uses the admin user language instead of the site language.

    Example:
    When I create a contact form from a template, the generated help texts use German texts like “Vorname” and “Nachname”.
    For an English website, I would expect labels like “First Name” and “Last Name”.

    Please consider changing this behavior so that templates, labels, placeholders, and other generated texts use the configured WordPress site language instead of the admin user language.

    Alternatively, it would also help to provide an option in WPForms to choose which language should be used for generated form content.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Support Amjad Ali

    (@amjadali688)

    2 weeks, 2 days ago

    Hi @ixiter ,

    Thanks for taking the time to share this feedback

    What you’re seeing is currently expected behavior in WordPress. The admin user language dictates the language used in your dashboard, menus, settings, and also the default/generated content inside the WPForms builder. That’s why template fields are being created in German for your user account.

    The front-end content shown to visitors will still follow the site language, but the form builder itself uses the logged-in user language.

    At the moment, WPForms doesn’t include a separate option to force generated form content to always use the site language instead of the admin user language. I’ll share your feedback with the team.

    Thanks!

    Thread Starter ixiter

    (@ixiter)

    2 weeks, 2 days ago

    Hi @amjadali688,

    thank you for your reply.
    I am looking forward for your decision in the team how to handle this issue.

    Hopefully you agree to my point of view, that site language should priorize when creating any content for the site, while admin language helps the admin to understand features and workflows better.

    Plugin Support Kenneth Macharia

    (@kmacharia)

    1 week, 4 days ago

    Hi @ixiter,

    Thanks for getting back to us, and for the thoughtful explanation!

    You’re actually right to push back on this a bit. While what you’re seeing is technically standard WordPress behavior (since WordPress 4.7, the admin area uses get_user_locale() to determine the locale, which returns your user language first and only falls back to the site language if no user language is set).

    WordPress does provide a switch_to_locale() function specifically for situations where the user’s language shouldn’t take precedence. Core itself uses it for things like email notifications, where the content should match the recipient’s language rather than the logged-in user’s. Your case is very similar: form labels and template content are ultimately site-facing, so there’s a reasonable argument that WPForms could use get_locale() (the site language) instead of get_user_locale() when generating that content.

    I’ve gone ahead and logged this as a feature request with our development team. Your reasoning is solid and I think it makes a strong case, whether that means having template generation default to the site language or providing an option to choose. I can’t promise a timeline, but it’s on the radar.

    Thanks again for taking the time to explain this so clearly!

    Thread Starter ixiter

    (@ixiter)

    1 week, 4 days ago

    Hi @kmacharia and WPForms support team,

    thank you very much for the detailed explanation and for taking the time to discuss this internally with the team.

    I really appreciate the thoughtful way you approached the issue and the technical background you provided regarding get_user_locale(), get_locale(), and switch_to_locale(). Your explanation makes perfect sense, and I’m glad my concerns were understood in the broader context of site-facing content versus admin UI language.

    It’s also great to hear that the request has been logged as a feature request for the development team. I genuinely appreciate the openness and constructive handling of the topic.

    I’m looking forward to a possible solution or improvement in the future — hopefully sooner rather than later 🙂

    Thanks again for the excellent support and communication!

Viewing 4 replies - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.