Per discussion with PeteMall and Jane in IRC, since sorting and pagination on the plugins screen is stateless, we should remove sorting on the plugin name column. Sorting, then making any action, will cause you to lose the action, which is lame.

Maybe it's time to make it not stateless anymore and save it as a user setting? Or at least make the sortable columns filterable (empty by default?) so a plugin can implement sorting. For example, a plugin could allow sorting plugins by their activation date.

Also lame, is that unlike on other screens that might be sorted by something else by default, the screen is already sorted by name. So the most this can do anyway is sort by name descending. Or as I like to call it, scroll to the bottom and use your imagination.

The sorting is still not correct when you have translated plugin names. However, this can be solved by having sortable columns and a default order of ?orderby=name&order=asc. It's very annoying when you have lots of plugins and you need to find plugins somewhere on the page. And no, Cmd+F is not a solution.

This second patch defaults to order by name, which fixes the behavior for translated plugin names. If we only implement this, I can live with it. Although sorting by description would be nice too (like with taxonomies)…

Totally forgot that I can use the "manage_{$this->screen->id}_sortable_columns" filter if I want to add an additional sortable column (e.g. activation date).

The _order_callback() function didn't seem to be being used elsewhere. I'm not sure if sortable plugin data could include non-string data (at least data that won't sort with strcasecmp() - if so, then the patch won't work.