Usability

''Obsolete Extension:UsabilityInitiative was divided into several other extensions. This page is now about the main interface.''

A list of mediawiki gronks (usability-speak for "bugs") as of version 1.4 needs update to list current usability issues.

What usability issues have persisted in mediawiki that could be addressed? Which ones are urgent in an age of smaller screens, much more mobile & verbally controlled access? is there a need to fork mediawiki's front end for mobile in a more serious way?

Please fill out below, this is stub only:

internally inconsistent ontology (page names, commands, URIs)
Nothing destroys namespace faster than a bad example set in the user interface itself.

Social metaphors
Some wiki ideology goes overboard in assuming that certain motives and roles must apply. This shows up in the language.

Assuming "donations" fund the project
The use of charity metaphor to describe all payments for all purposes, assuming that the project is not self-funding, e.g. via bets, paid services, license fees etc., is undesirable and biases against use of mediawiki in private sector projects.
 * WORKAROUND Refer neutrally to "pay" or "order" instead?

No way to easily import whole other wikis via wiki feeds
Similar to the namespace and categorization issue is that whole namespaces can't be overlaid (or underlaid, meaning, only those names that are not defined locally will be looked up from the globals).

Cruft on category pages
"Subcategories There are 4 subcategories to this category."

"Articles in category "Eg" There are 25 articles in this category."

is obviously redundant compared to:

"4 subcategories in this category."

"25 articles in this category."

Inflexible control sections on pages
It should be easier to add more custom controls to the "navigation", "search", "toolbox" and also easier to add extra items along the bottom row with "about", "disclaimers".

Inconsistent use of "delete/d", "permanently delete", "archive/d", "purge", "remove", old"
While relatively good overall official instructions exist and truly clear and excellent user descriptions, the maintenance procedures around spam removal in particular are astonishingly unclear. Many pages exist all over the net with version-specific SQL manipulations that should never be attempted by any user at all no matter how sophisticated or how certain they are using the same version as those instructions allegedly worked on (Mediawiki has many tables that change with every version and some extensions too... the odds of doing SQL purging correctly are low).

Term usage is extremely inconsistent The purge/delete/archive terminology horror gets worse with each release, e.g. a shell tool that purges deleted versions is called deleteArchivedVersions.php which is deeply confusing especially as "purge" already exists in the lexicon in the options that these scripts take, and "remove" (the Unix-y term) is already in the names of removeUnusedAccounts.php etc.). Worst, "old" has totally different meaning in purgeOldText (where it means "purged") vs. deleteOldRevisions (where it means "archived" or "deleted" revisions).  One word, one semantics regardless of permission and account powers!
 * delete, to an ordinary user, means permanent removal, while "archive" means "put in some user-visible place that is harder to access", such as talk page archives
 * to administrators, it has a parallel but quite different meaning: A "delete" moves the page to a place harder to access.  When the time comes to truly eradicate these pages, typically spam, they invoke "deleteArchivedVersions" (?!?!) to permanently remove (or "purge") them.  The script should be "purgeDeletedVersions" obviously, regardless of the unfortunate names of the SQL tables.
 * WORKAROUND: Write a shell script "purgeDeletedVersions" that invokes the options you think appropriate for shell users, and hide or rename deleteArchivedVersions so no one invokes it or is confused by it's absurd name.  Similarly script around "Old" term so it's clear what level of "old" is targetted.  Probably reserve "purge" prefix for scripts that actually irrevocably purge things, or perhaps use prefix "irrevocably"?