Mediawiki gronks

From eg

Jump to: navigation, search

Just as mutt has fleas instead of bugs, mediawiki gronks rather than having bugs or misfeatures or whatever. Using words to describe behaviour that are non-operational is a coder best practice in many shops, since one ape's bug might be another ape's dinner.

Mediawiki gronks as of 1.4 and WORKAROUNDS for them include:

Contents

[edit] internally inconsistent ontology (page names, commands, URIs)

Nothing destroys namespace faster than a bad example set in the user interface itself. Especially where clashing or confusing ontological metaphors apply.

[edit] Capitalization mismatch in command verbs

Notice that "search" appears lowercase in the box, and uppercase on the search button. While "edit" appears lowercase in the edit tab, the parallel term:save is uppercased. Where there's a parallel page name like "Talk:", the verb is "talk for this IP".

WORKAROUND: override everything you have to to get all command verbs lowercase everywhere

[edit] Cruft in the URLs

The obnoxious "/index.php/" appearing in the URI by default, messing up all sane naming and making it very hard to rattle off wiki URIs to newbies on the phone, etc.

WORKAROUND: fix rewrite rules to get rid of this, leaving only /name or /wiki/name - DONE

[edit] Use of the project name in the disclaimer

In the disclaimer, why is it Project:Copyrights and "eg" and not E.g.:copyrights? and "e.g." ?

WORKAROUND: redirect to zooid:copyrights (DONE)

[edit] Page name capitalisation

Always capitalizing the first letter of any page, even temporary pages created when "Editing" or trying to "Save page" or "Show preview"; This makes it quite hard to convince newbies to conserve capitals; It's also quite inconsistent with the (correct) non-capitalization of "article", "discussion", "edit", "navigation", "search" and "toolbox" and even the full commands "talk for this ip" and "create an account or log in" - IP should be capitalized but not "Community", "Current", "Recent", "Random", "Help", "What", "Related", "Special", "Go", "Search", "Save", "Show", "Cancel", "Editing", "About", etc. - most of these are command verbs like the ones on the interface.). Main Page sets a very bad example in this regard.

WORKAROUND: manually fix page names early and convince people that they need lowercase in order to embed links conveniently in sentences (true) and that the giant space goat will eat them in Hell after they die if they do otherwise (not necessarily true, but you can't prove that); Also point out that of major news services only AP and a few US newsires capitalize every word in a name: CTV, CP, Reuters, BBC don't. Now who do you want to be like? (DONE mostly, a few like Web Configuration will disappear during the next refactor).

[edit] FIXED: Capitalization mismatch in Eg:Community Portal menu item

One a wonderful example of how stupid it is to put capitals in names that don't need them, the Community portal link is actually to the page Eg:Community Portal (note that it's a "P" not a "p").

WORKAROUND for older mediawikis: #REDIRECT [[Eg:Community Portal]] from Community portal and Eg:Community portal (DONE)
FIXED in new mediawiki: It's now "debate topics" not "Community Portal" or "portal", which deals with some other problems noted below.

[edit] Link to "talk:" page is labelled "discussion" not "discuss" or "talk"

Creating pages named "talk:" when you click a button named "discussion". Isn't it a sure sign of bad command verbs and bad page names when software puts one word, "discussion", on its user interface, and another word, "talk", on the page name. Why not have the namespace become "discuss:" if it is so important not to say "talk"? Then you could at least say "discuss Main Page" easily, which is harder to do with "talk:Main Page". Just silly, but we're stuck with "talk:" because that's what Wikipedia uses for its talk pages. The inconsistency has caused jamwiki to use "comments:" which is sub-optimal as that is not a verb, and it's plural.

WORKAROUND: can installers change the word "discussion" to "discuss" or "talk" (to match "edit") or "talk:" to "discuss:" easily? (LOW PRIORITY, LET WIKIPEDIA FIX THIS FIRST, debate the issue at talk:discussion if you really care enough to complain to them)

[edit] Link to article is labelled "about" in "project namespace"

An article suddenly becomes an "about" in project namespace, despite the fact that there is a page linked by default in the user interface, labelled project:About. Meanwhile there's a "help namespace" which is separate again.

WORKAROUND: can installers change the word "about" to "article" and leave it there, so that the default link to project:About is no problem (LOW PRIORITY, LET WIKIPEDIA FIX THIS FIRST,

[edit] Inflexible "Special" page names setting bad precedents

The mediawiki special pages are named badly, this is "special" not in a good way. For instance Special:Uncategorizedpages or Special:Recentchanges disobey every naming convention possible. This is exceptionally problematic as other users will copy these bad conventions fixed in the wiki software

WORKAROUND: REDIRECT reasonable names like uncategorized page to Special:Uncategorizedpages, and consider using project namespace since ultimately the special pages are reporting aspects of the project, as noted below

[edit] inconsistent tense and point of view

Use of first person, second person and third person must be sorted out especially as it has license implications in some public wikis where tense sets license, e.g. this wiki. Extreme point of view, e.g. new troll point of view needs support.

[edit] Sense of "Help" inverted to mean "learn"

Unlike all the command verbs, e.g. "verb:search", "term:go", "verb:talk", "verb:log in", "verb:cancel", "verb:save", "verb:show", "verb:edit", the term:help is used to mean "get help" rather than "I help", totally inconsistent with all other usage. It should be explicitly "get help" or else another verb should be used instead.

WORKAROUND redirect Help:Contents to category:learn since "I learn" is the intent. (DONE)

[edit] "Editing help"

Just what does this mean? Editing a help page? Help with editing any page? It means both since it shows up with both meanings.

WORKAROUND just don't name pages "help", and redirect those hardwired in help:namespace

[edit] weak or misleading metaphors

Metaphors that seemed in the past to have helped new users learn wiki are now retarding them by imposing ontological metaphors on debates, e.g. the embodimentwiki.org analysis of stupid mediawiki metaphors that bias their debates.

[edit] Tool metaphors

[edit] Use of word "toolbox"

WORKAROUND change the name of the box to "corpus" because it's mostly about corpus statistics
WORKAROUND change the new of the box to "trollbox" - this will appeal to the target audience

[edit] Spatial metaphors

Using spatial metaphor ("go", "here", "navigation") thoughtlessly in command verbs, e.g. "what links here" which means "what people link to this page" and has nothing to do with any "here" that one can find on a map. The horror that will result when locale is fully supported with geospatial features cannot even be comprehended: "here" will mean... what?!!? A word like "portals" or "starting points" can replace "navigation"

WORKAROUND: Use on this page and link to this page and complain bitterly to the mediawiki gurus about this stupidity (PLEASE DO, IF YOU CAN FIGURE OUT HOW TO DO THAT)

[edit] Use of the word "go"

WORKAROUND: change to "now" or "find", there's no reason not to search on what's not found or go directly to uniquely found items

[edit] Use of the word "here"

WORKAROUND: Replace "what links here" with what links to this page or similar, as embodimentwiki.org did. Or use the ubiquitous coined term:backlink or term:refer.

[edit] Use of the word "move"

WORKAROUND: Replace "move" with rename which is much more clearly within the wiki

[edit] Use of the word "navigation"

WORKAROUND: change the name of the box to "where/when/who"

[edit] Casual abuse of spatial metaphor in documentation and edit summary

WORKAROUND: When making reference to pages, especially in an edit summary, avoid term:location and term:where and say "within which context" or "on which page" or whatever you have to do to avoid implying that a page is a spatial location. Complain bitterly about such abuses of spatial metaphor in FOSS, e.g. DOAP

[edit] Social metaphors

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

[edit] The "lock page" function is labelled "protect page"

Other wikis, notably tikiwiki, refer to this function as lock pages: a lock equivalent to a lock on a door is being applied, which prevents editing on the pages. A door metaphor is at least operational, though it has some spatial problems potentially too by implying that editing a page is like entering a room (this can conflict with the idea that to view a page is like entering a room). However, while there may be better words than either, the phrase "protect page" implies that the persons with infrastructure owners trust necessarily are protecting something valuable or useful against people who would disrupt or damage it. This is certainly not the case ever time that edits to a page have been prevented.

For instance, it's quite common for pages describing events to be locked by sysops who wish their version of those events to remain unchallenged. This may protect the sysops but it doesn't protect the page's integrity nor the wiki's credibility.

WebDAV will probably set a standard for use of verb:lock.

WORKAROUND Use [[lock page]] wherever the function is referenced, and make note of the issue in documentation, indicating that verb:lock is the preferred verb/term.

[edit] The "block account" or "lock account" function is labelled "ban"

editors note: it is not clear whether this is still a problem with current releases.

It's absurd to imagine that blocking a user account prevents the return of a user. A ban is a governance or management action, not a technical action. To implement a ban requires many blocks, if that user is persistent, and it will almost certainly have collateral damage such as encouraging sysop vigilantism. Operationally, what has happened is that a user account has been blocked (if they can still log in but not edit) or locked (if they cannot log in at all).

WebDAV may set a standard for use of verb:lock.

WORKAROUND Just ignore any edict or person who uses the word "ban", and keep creating sock puppet accounts with names that mock the practice, until the correct terminology is in use. If people object, tell them you don't understand what "ban" means, and ask them to get a court order if they actually want to implement what a "ban" would mean in the real world.
Pretending not to know what somebody means by a word, just because you disagree with their right to use that particular word, is childish behaviour, and I can't see how it squares with being an ethical troll - it makes you look like a fool rather than building support. The same goes for the creation of sock puppets just to get the last word, when your point has been clearly expressed already. As for the rest of this, I could be wrong, but I just disagree that it is necessary in the large majority of cases - if you disagree with a large body of people, you should check yourself first, engage them non-confrontationally second, and mock them from outside third, confronting their norms only as necessary to prevent direct harm or when it's actually funny. But this necessitates having an actual sense of humor...

[edit] List of open links is labelled "wanted pages"

Calling the list of open links "Special:Wantedpages" is biased: who wants them? Not everyone wants everything filled in by whoever's around, and "most wanted" is very biasing as it seems to imply that anyone who puts any crap on that page is satisfying a need necessarily. This usage seems to echo a print publisher's prejudices towards closure, and may encourage premature closing of open links, discouraging discourse and leaving them open until their definition is constrained.

Aside from raising an issue, there are persistent reasons other than "Wanting that page to exist" to open a link to it. Admittedly these are few, but in coder best practice it is very common to have a lot of "don't care" slots in the architecture, and that is most easily symbolizing in a wiki by leaving an open link. A more objective name for the list is simply: Special:open_links and who cares how they are sorted?

WORKAROUND Use [[Special:Wantedpages|all open links]] instead (DONE, in the few places it's linked)

[edit] FIXED: Use of the word "community"

Putting "E.g.:Community portal" on the "navigation" (see below) menu. The people who use a given wiki may or may not see themselves as a "community". If they do, those who use the wiki may or may not be representative of it. Wikipedia used "Village_pump" and that is better at least for being obviously a metaphor. The "community" nonsense is dangerous in that it seems to authorize heavy-handed "policing" behaviour that is reasonable when a lot of lives are at stake, but is not reasonable when it's just people talking in a wiki

WORKAROUND for older mediawiki: Create your own names for discussions, e.g. Sysop Discussion or zooid:trollgnaw, that suggest that more than one "community" is allowed to exist (DONE)
FIXED in new mediawiki: It's now "debate topics" not "Community Portal" or "portal", which deals with some other problems.
to advocate: Complain bitterly to SOIC and other abusers of this term who just don't get it.

[edit] 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?

[edit] Assuming "most viewed" is "popular"

Referring to most viewed pages as Special:Popularpages as if pages that are heavily viewed are necessarily "popular" rather than say controversial (an entirely commercial model of attention) is undesirable especially when pages may be most viewed due to some ruleset.

WORKAROUND Use [[Special:Popularpages|most viewed pages]] instead (DONE, in the few places it's linked)

[edit] Abuse of "history" to mean versions

The term:history is a big thing. A list of all versions is a rather smaller thing. One can refer to "version 34332" much more easily than "oldid 34332 in page history" and it's hard to avoid the word version anyway when using the verb:revert and so on. The word "history" is dangerously overloaded noise. If a broader word than "versions" or "edits" is required, then "changes" (as is used in seedwiki) will do.

WORKAROUND Explain page history distinctly from real history in this wiki's own context, e.g. systemic bias of written material, etc. Encourage use of "versions" (or at least "page history") in the meantime, and eventually eliminate the word "history" from the user interface entirely in favour of "changes" or "versions".

[edit] Inflexible category and namespace system

Mediawiki-based services emphasize social software features while content management seems to lack, e.g. inability to incorporate dynamic input from RSS feeds keeps it behind tikiwiki (contrast a simple tikiwiki page with four RSS feeds on it). Focusing on peer contact may well be an advantage as gACL and other hard security distractions tend to be minimized. However there are some inexcusable stupid misfeatures:

[edit] "special" (but not "Special") project and "help" namespaces

While treating a project namespace and help namespace as "special", notably in naming of talk pages, there is no provision for other normative namespaces being treated in the same way, e.g. specifying that a position:namespace should have a position_talk:namespace to discuss it.

WORKAROUND: put up with talk:position:namespace for now. Warn users of every normative namespace that they may run into strange talk page name behaviour.

[edit] Not integrated with other "special" pages

If there's going to be a special namespace for information about the project, one would think it would at least include all mediawiki special pages despite bad names noted above. So mediawiki reports information about the wiki database into this "Special:" namespace, which is not the "special" project namespace. It would be helpful to be able to take the information from the wiki software, and decisions from the project contributors, and keep it integrated.

WORKAROUND: REDIRECT reasonable names like project:uncategorized page to Special:Uncategorizedpages

[edit] Namespace regression limits and hardwired exceptions

Preventing three-level regress of talk pages for the "E.g.:" namespace but not for any other namespace, as if the only POV that mattered was that of the sysops who control that service name, or the developers who coded particular priveleged names in as exceptions (like [[User_talk:]]).

WORKAROUND: manual redirects to pages like zooid_talk:ethic instead of (what mediawiki creates) talk:zooid:ethic (DONE, each new zooid:name requires another such redirect, so if you create zooid:newpage you must replace talk:zooid:newpage content with the exact content:
#REDIRECT [[zooid_talk:newpage]]
and in the summary line when you check this in, say:
#REDIRECT [[zooid_talk:workaround]] to pre-empt one of worst [[mediawiki gronks]]
Organizatinally, it amounts to preferential treatment of one "overarching" perspective. It might be fascist, or some such assumptions might be required to make computers go at all. Maybe all discussions that are not pre-authorized and pre-empted by sysops should be subject to endless regress, since the sysops end that regress by brute force. For now:
WORKAROUND: just declare "E.g." to be "zooid" (PLEASE DO) and all will be well, assuming no more than the usual troll-sysop struggle.

[edit] Separate or additional categories can't be assigned to a redirected name

You can't assign categories to a redirected name. That is, the name cannot appear in the categories unless it is associated with at least a one-liner article on a different page altogether. This is extremely clumsy and debilitating when multiple levels of category abstraction are required.

What links to this page does separate the redirects, therefore, so should the categories: When extremely specific concepts are explained that are a subset of the concerns in the article, and which make little sense to explain on their own, usually these are related to some domain or narrow problem that takes a very specific perspective. If use of that term in particular has any operational implications, then users need to track all use of that term without confusing it with all reference to that concept, i.e. all linkage to the more general article explaining it.

Some cases illustrating the problem:

  • When explaining technical terms there are very often multiple similiar names, used by different vendors, consortium or accredited standards regime. When generic terms are used in the articles, the category scheme can't be used to automatically generated portals from the POV of each, which would much ease translation and dialogue.
  • More generally, common concepts in more than one ontology or culture, it's most desirable to write a single article comparing and constrasting both. To put the majority of the analysis in one or the other's terms is prejudicial enough without forcing the less commonly used term out of visibility altogether. For instance, a term like ijma in Arabic means roughly "consensus" in English so it would be ideal to apply categories like "Arabic" and "Islam" to ijma without having to apply those to consensus in general. The category scheme becomes useless to assemble glossaries unless a redirect can be categorized with at least some additional categories that don't apply to the article (even if all those in the main article do necessarily apply, which is a reasonable argument to make)
  • Most obviously, when you want to redirect a trollish phrase to an English one (that way, only the trollish phrase would actually be in category trollish, while the English article may well be in category trolling).
WORKAROUND: Describe any trollish or "foreign" phrases with at least a one liner stub that links to the English article, rather than redirecting to that article. Link to this page to explain how stupid this is and explicitly apologize for having to have so many categories on one little stub.

[edit] GFDL corpus namespace is polluted by bad categories

This is more of a Wikipedia problem that infects other wikis. The GFDL corpus namespace is great, but, it's constantly polluted by bad categories, almost as bad as the GFDL corpus content itself (which seems to smear poo on the glory that is the namespace).

WORKAROUND: adopt target categories when on patroll, give a Wikipedia category no status and bitterly undo any effort to apply Wikipedia's non-operational category scheme to other wikis

[edit] No way to require categories to be applied to all articles in a namespace

Even when a category has exactly the same name as a namespace, e.g. [[category:term]] and term:namespace, there is no way to simply indicate that all articles in the namespace are to be automatically assumed to be in that category. It would be easy enough to assume so unless otherwise directed (by some notation like -[[category:term]]), especially if this feature can be turned on and off.

WORKAROUND: Explain in each category header that it includes one or more namespaces also, where this applies. (DONE).

[edit] Non-obvious notation to mention a category as an internal link

Commonly users want to refer other users to an entire category, but to do so they need to use the [[:category:CATEGORY_NAME]], which is not obvious, or create an external link, which is inadvisable. If they don't, they'll just end up putting the page they are trying to create the link on, IN that category, which is confusing even for very experienced users. The external link is ugly and misleading.

WORKAROUND: Create an internal link which is nothing but a redirect to each category's external URI. That way at least the ugliness is on one page, not many, and the internal link tracxking features will also work to track references to an entire category.
WORKAROUND: Create an internal link which is nothing but a redirect to each

[edit] 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).

This inexcusable oversight is now a gronk, since getwiki and tikiwiki both do wiki feeds fairly well, making them better choices than mediawiki for those who need to nest wikis. The feature of XML import of a whole external wiki seems to have been omitted deliberately by mediawiki coders, who are loyal to the Wikimedia Foundation more than to the user base: to maintain its status as central arbiter of the GFDL corpus, vile creeps sponsored by Wikimedia have time and again demanded that even very improved articles at other public wikis where the article is being actively improved, link "back" to Wikipedia. This would be very hard to enforce if everyone was importing everything everywhere, and many different wikis became authoritative in narrow domains.

WORKAROUND: Use getwiki and hope mediawiki has this feature before you need to use your DB commercially. The Special:Export page, which does nothing useful, seems to promise some such feature.
WORKAROUND: Use tikiwiki and hack up the support for mediawiki data yourself - good luck!
WORKAROUND: Use GFDL corpus namespace conventions exclusively and tolerate many open links, hoping that someday someone will solve this (DONE though it's not really a solution).

[edit] Suboptimal use of screen space

[edit] 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."

[edit] 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".

[edit] Poorly named and documented maintenance scripts

[edit] Inconsistent use of "delete/d", "permanently delete", "archive/d", "purge", "remove", old"

While relatively good overall official instructions exist [1] 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

  • 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.

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!

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"?
Retrieved from "http://let.sysops.be/wiki/Mediawiki_gronks"
Personal tools