Admin: Plugin search does not match translated plugin names in “Installed Plugins” list

[malimart]

When WordPress is used in a non-English language, the Plugins > Installed Plugins screen in the WP admin dashboard displays translated plugin names (from .mo files) if they exist. However, the search box at the top of that screen only matches the plugin’s original (English) name, not its translated name. If you search a plugin by the translated name from the list you get no results.

Expected behavior

When doing a search using the plugin's translated name, the plugin should appear, because the displayed (translated) name matches the search query.

Benefits

• Improves usability for non-English users.
• Aligns the admin search with localized UI expectations.
• Avoids confusion when users see translated names but get no search results.

Technical details

I believe the issue is that the WP_Plugins_List_Table search logic in class-wp-plugins-list-table.php uses the raw plugin headers ($plugin_data['Name'], etc.) from the plugin files, without passing them through translation functions. Therefor, only the original English strings are searchable.

Related tickets

The issue is similar to ​#1496, except it's not related to the plugin directory but the plugin search inside the wp admin.

[dd32]

I have moved this ticket here from ​https://meta.trac.wordpress.org/ticket/8123

To reproduce this, you can use the following playground:
​https://playground.wordpress.net/?language=de_DE&url=%2Fwp-admin%2Fplugins.php%3Fs%3Dnicht

[nikunj8866]

@malimart Could you please provide a specific plugin to reproduce this issue?

I tested using ​Allow Cyrillic Usernames in Russian, but the Installed Plugins page still displays the plugin name in English (​https://prnt.sc/0IUyzf4Cq_nJ).

[malimart]

I think plugin names should not be translated, but if they are, plugins should be searchable by the translated name that is displayed on the plugin list.

Steps to reproduce the issue:

1. Install Event Organiser (​https://wordpress.org/plugins/event-organiser/)
2. Go to wp-admin/options-general.php and change Site Language to Polish (Polski)
3. Go to wp-admin/plugins.php. The Event Organizer plugin is now displayed with its Polish name (Organizator wydarzeń)
4. Copy and paste that name in the plugin search bar. You will get 0 results.
5. You can find the plugin by using its original name Event Organiser.

---

Screenshots

Searching by the original name, 1 result:

Searching by the translated name, 0 results:

[nikunj8866]

✅ Reproduced
I was able to reproduce this issue. On the Plugins → Installed Plugins screen, the search functionality only matches against the original English plugin names.

If the plugin list displays translated plugin names (from .mo files), those names are not searchable, which can be confusing for users viewing the admin in a non-English language.

Notably, the Add Plugins screen search does work with translated plugin names, so the behavior is inconsistent across plugin-related screens.

[nikunj8866]

Add Plugin Search

## Summary

Make the Installed Plugins search (Plugins → Installed Plugins) match the translated plugin name, description, and author that are shown in the list — not only the original (untranslated) values from the plugin file headers.

## Problem

When WordPress runs in a non-English locale, the Installed Plugins list table displays translated plugin names (from the plugin's .mo files). However, the search box only matched against the raw, untranslated plugin headers. Searching for a plugin by the name shown in the list returned _no results_.

This is also inconsistent with the Add Plugins screen, whose search already matches translated names.

In WP_Plugins_List_Table::prepare_items() the search runs against the raw get_plugins() data:

$plugins['search'] = array_filter( $plugins['all'], array( $this, '_search_callback' ) );

…while the data is only passed through _get_plugin_data_markup_translate() for display afterwards:

$this->items[ $plugin_file ] = _get_plugin_data_markup_translate( $plugin_file, $plugin_data, false, true );

So the user sees translated names but searches against untranslated strings.

## Solution

• Pass the plugin file path into _search_callback() using ARRAY_FILTER_USE_BOTH.
• In _search_callback(), in addition to the original header values, also match against the translated plugin data returned by _get_plugin_data_markup_translate().
• The original (untranslated) values are still searched, so finding a plugin by its English/original name continues to work. The second parameter is optional, preserving backward compatibility for any external callers.

The extra translation work only runs while a search is active.

## Testing instructions

Reproduction via WordPress Playground (provided on the ticket):
https://playground.wordpress.net/?language=de_DE&url=%2Fwp-admin%2Fplugins.php%3Fs%3Dnicht

Manual:

1. Install a plugin that ships translations for its name (e.g. Event Organiser).
2. Set Site Language to a locale with that translation (e.g. Polish) in Settings → General.
3. Go to Plugins → Installed Plugins. The plugin shows its translated name.
4. Search for the translated name.
   • Before: 0 results.
   • After: the plugin is found. Searching by the original name still works too.

Automated:

phpunit tests/phpunit/tests/admin/wpPluginsListTable.php

New regression tests cover search by translated name, search by original (untranslated) name, and a non-matching term. The translated-name test fails on trunk and passes with this change.

## Use of AI Tools

• AI assistance: Yes
• Tool(s): Claude Code
• Model(s): Claude Opus 4.8
• Used for: Root-cause analysis, drafting the fix and the PHPUnit regression tests. All changes were reviewed, reproduced live in the wordpress-develop Docker environment (before/after), and verified against PHPUnit and PHPCS by me.

And mind that you want a ticket on trac related to this PR, otherwise it won't be prioritized

Thanks for the heads-up! There is a ticket already, #64188, linked at the top of the description. It's showing the PR and has-patch on the Trac side now too, so it should be on the radar. Appreciate you checking 🙌