Remove the WordPress Login Language Switcher Without Changing Site Language

WordPress automatically outputs a language dropdown on the login screen when installed translations provide additional language choices. While this feature helps multilingual administrative teams choose their preferred interface language prior to authenticating, many single-language public websites and specialized portals find the extra control redundant or visually distracting. Removing this selector does not alter the site locale configured in your general administration settings, nor does it affect individual user profile preferences once authenticated.

By understanding how core processes the login template, administrators can cleanly suppress the dropdown menu using native filters rather than masking elements with custom stylesheets or modifying core application files.

How the Login Language Switcher Operates in WordPress Core

The login language dropdown was introduced into core in version 5.9.0. During the generation of the login template, WordPress runs internal footer routines to construct links, policy notices, and localization controls. Specifically, the login_footer() function verifies whether an interim login modal is active and queries installed translation files.

If installed translation files provide additional choices, core prepares the markup for the select menu. However, before generating the form controls, the system evaluates the login_display_language_dropdown filter hook, which passes a boolean flag defaulting to true. When this filter returns false, WordPress skips rendering the dropdown container entirely.

Crucially, hiding or removing this selector is purely a presentation change on the authentication screen. It does not restrict users from setting different languages in their dashboard profiles, and it does not revoke any translation capabilities. Distinguishing interface visibility from underlying system configuration ensures administrative workflows remain intact, much like separating screen display from true capability management as explored in our guide to WordPress roles and capability changes.

Method 1: Disabling the Dropdown via a Code Snippet

The cleanest and most resource-efficient method to eliminate the language switcher is hooking into core via a custom functionality plugin, a must-use (MU) plugin, or the active child theme functions file. A programmatic filter avoids loading additional query parameters or third-party background tasks.

Step 1: Determine the Execution Location

Avoid editing parent theme files or core files such as wp-login.php directly, because future updates will overwrite manual edits. Instead, create a lightweight must-use plugin in wp-content/mu-plugins/ or place the code inside your active child theme functions.php file. A must-use plugin executes before standard plugins and cannot be deactivated by mistake from the dashboard.

Step 2: Add the Core Filter Hook

To suppress the language dropdown, return false whenever core evaluates the display condition. Add the following PHP snippet inside PHP code. A new MU-plugin file needs an opening <?php tag; do not add a second opening tag inside an existing PHP block. Keep file access available to undo a syntax error:

add_filter( 'login_display_language_dropdown', '__return_false' );

This single line instructs WordPress to halt the output of the language form on wp-login.php. Because __return_false is a built-in WordPress helper function, no secondary callback declaration is required.

Step 3: Verify Intermediate Arguments (Optional)

In advanced workflows where an administrator wants to alter the choices inside the dropdown rather than removing it entirely, WordPress supplies the login_language_dropdown_args filter hook. This hook modifies the associative array passed to wp_dropdown_languages(). However, when the objective is total removal of the element, returning false via login_display_language_dropdown remains the authoritative standard.

Method 2: Evaluating Maintenance Plugins

For organizations that manage login interfaces through graphical dashboards rather than custom PHP files, several plugins exist as candidates to evaluate:

• Disable Login Language Switcher: A single-purpose utility designed specifically to call the core hook without manual coding.
• Custom Login Page Customizers: Broader administrative extensions that provide form controls for removing default elements, adding logos, and modifying structural layouts.
• Code Snippets Managers: Database-backed snippet engines that permit adding PHP hooks through the admin console without requiring direct server access.

When evaluating these options, review update frequencies and code footprints. A plugin that injects excessive CSS or JavaScript to hide elements visually is less efficient than one invoking the native boolean filter.

Visibility Masking vs. Structural Removal

Some developers attempt to hide the language switcher by enqueueing a stylesheet with rules like .language-switcher { display: none; }. While visually effective on modern browsers, CSS masking carries functional disadvantages:

The core filter avoids emitting unnecessary markup. Properly applied display: none also hides the control from ordinary interaction and accessibility APIs, but leaves it in the source. For broader layout considerations regarding device performance and dynamic stylesheets, review our analysis of WordPress CSS delivery and interactive states.

Hypothetical Scenario: Multi-Site Corporate Portal

Consider a hypothetical Canadian manufacturing firm, Northern Equipment Parts, operating a central distributor portal on WordPress. The installation contains Canadian English and Canadian French language packs because remote representatives generate localized PDF orders within their user accounts.

During a usability review, internal support noticed that outside logistics contractors frequently switched the login screen dropdown to French inadvertently. This changed the login labels on shared depot terminals, generating confused helpdesk tickets from English-speaking warehouse staff.

The engineering team considered uninstalling the French translation files from the server, but doing so would break localized invoice generation for French-speaking clients. Instead, the team placed an administrative file named disable-login-language.php in the wp-content/mu-plugins/ directory containing the login_display_language_dropdown filter. As a result:

• The login screen no longer showed the dropdown. The filter did not itself force a particular locale or block a language query parameter.
• French-speaking distributors maintained their individual profile language preferences once logged into the dashboard.
• Server-side language packs remained fully active for scheduled tasks and document exports.

Troubleshooting Common Implementation Issues

If the dropdown menu remains visible after adding the filter, work through the following technical diagnostic steps:

• Aggressive Full-Page Caching: Login pages should generally bypass page caching, but reverse proxies or server caching rules (such as Varnish or Nginx microcaching) may serve a cached HTML snapshot of the login page. Purge edge and server caches after implementing your code.
• File Execution Scope: If you placed the snippet inside a child theme functions.php, verify that the child theme is currently active. If a staging environment switched back to the parent theme, functions inside the child theme folder will not execute.
• Filter Precedence and Priority: Another active plugin might be executing with a later priority or hooking into login_language_dropdown_args. Test execution by assigning a late priority to your call: add_filter( 'login_display_language_dropdown', '__return_false', 999 );.
• PHP Syntax Errors: Ensure code snippets do not include closing PHP tags followed by trailing whitespace, which can trigger HTTP header warnings during login redirect sequences.

Pre-Deployment Verification Checklist

Review this short checklist prior to deploying modifications to a live production server:

1. Core Version Checked: Confirm the WordPress instance runs version 5.9.0 or higher where the filter hook exists.
2. Deployment Method Selected: Place code in an MU plugin or custom site plugin to prevent loss during theme updates.
3. Cache Cleared: Flush server-side object caching and browser sessions.
4. Authentication Tested: Test standard login, password reset links, and interim session popups across desktop and mobile devices.
5. Profile Verification: Log in as an administrative user and verify that profile language preferences remain fully functional in user settings.