The end of the year is typically a time for reflection and planning. Planning is much easier than reflection :) so here’s my list of the top ten MediaWiki extensions that Wikimedia Commons (hereafter, just “Commons”) needs.
Ah, SUL. No acronym brings wry grimaces to the face of a Wikimedian better than this one, and perhaps no issue better demonstrates the consequences of the Wikimedia Foundation’s shoestring budget. Bug 57, Single user login, unified login, CentralAuth — whatever you call it, it should mean that an account created at any Wikimedia wiki allows one to log in at any Wikimedia wiki. Promised since at least 2006, you can currently take part in the testing at test.wikipedia, so there is progress. The full spec is on meta at Help:Unified login.
Why is this relevant to Commons? Because it’s the most likely wiki that editors are likely to use after their “home wiki”. SUL can reasonably be expected to indirectly promote uploading at Commons for Wikimedians, as another barrier to doing so is removed. (Spare a thought especially for the Spanish and Portuguese Wikipedians, who have disabled local uploads entirely.)
#1. Image search
AKA inbuilt Mayflower. Mayflower exists, is open source, and rocks the socks of everyone who uses it. All that’s needed is for some bright spark to specialpage-ize it, and then a little fairy dust to have that as the default search engine/page to be used within Commons.
#2. Multilingual categories/tagging
Commons is a multilingual project, but since category redirects don’t work as desired, any given category can only work if everyone uses the same name. The category needs to “work”, so that a visitor can go there and expect to find all the media relevant to that concept. But the redirect/alias bizzo also needs to “work”, so a user can tag /categorise their files using their native language.
The urgency of this task is the great shame of a multilingual project having to enforce a single language description on its users. Seriously uncool.
#3. Rating system
Someone did contact me about making progress in coding this up, but I haven’t heard a progress report lately, so it’s definitely something I need to follow up. As Commons grows, it becomes the case that for any given query there may be dozens or even hundreds of relevant files. So having a rank-by-quality or rank-by-average-rating option in the search engine can make a dramatic improvement to the search results.
People love rating stuff, so hey, free data on quality. Off the top of my head I can’t think of any other image database that has a rank-by-rating option but I would be pretty surprised if no one had done it yet.
#4. SVG editing as text
#5. SVG display – pick language labels
#6. SVG display – animated SVGs
These three are naturally related, and arise from the project that’s currently occupying my thoughts (if not my time). SVGs are like the wiki version of an image, as I recently said, because they are so easy to edit. You can open a SVG in a text editor and twiddle with it and save it, and you’ve got a brand new SVG.
But, that’s kind of annoying if MediaWiki wants you to download the file first, and then re-upload it again. Instead, it would make more sense to be able to edit an SVG in a wiki page — exactly the same in fact. Have the edits be recorded in the image history just like text page revisions. It would be a little bit tricky because you would still want to retain the ability to upload a new version of the file, but is surely doable.
From there, it should only be a small hop-step-and-a-leap to a special page extension that allowed one to easily translate text labels inside SVG diagrams.
Take for example this diagram of a biycle. There are currently five different files: Bicycle diagram-en.svg, Bicycle diagram-es.svg, Bicycle diagram-fi.svg, Bicycle diagram2-fr.svg, Bicycle diagram-pl.svg. But there is no need to have five different files. Instead, it would be better to condense all the labels within a single document and extend the image syntax to allow something like this:
So the main part of this request is for the image syntax extension. A tool could be hacked up fairly easily for easy label-translating on the toolserver, I think, although of course it would be preferable within MediaWiki natively.
#7. Gallery preview
The idea of InstantCommons is to let any MediaWiki wiki use Commons media as easily and transparently as the Wikimedia wikis do — that is, ‘‘as if the media were uploaded locally’‘. Such a feature would be of immediate interest to Wikitravel and Wikia, both non-Wikimedia projects, and really be a huge leap forward in Commons’ success at sharing free content.
Current status is unknown, but there’s some code in SVN.
#9. Native CheckUsage
As a consequence of #8, this one becomes much more pressing. CheckUsage exists on the toolserver and tells you in which projects a Commons image is being used. Indirectly that tells you how many people you’re likely to piss off if you delete the image without delinking it first.
This is basic necessary functionality for the Commons community. It would be like if you removed the ability to unblock users. We have the ability to do the damage, but we also need the ability to survey the scene and minimise it. So, it is an uncomfortable situation that we rely on half-hacked-up tools for such a critical task, and it would only be moreso the case if InstantCommons was enabled.
ImportFreeImages allows the user to search Flickr and transfer an image locally all within MediaWiki. Because Flickr enables Creative Commons licensing, it is a major source of freely-licensed media. But there are two problems. One is that Flickr also allows non-free licensing, so we have major headaches in teaching people the fine distinction between tiny icons. The second is just that it’s annoying to have to manually save the image locally, upload it again, make sure you copy all the relevant author info and so on, and asking people to do that leaves a lot of room for mistakes.
So ImportFreeImages saves all those problems, and because you can restrict which licensed-images you want it to show from Flickr, you can solve the licensing confusion as well. It acts as a filter on Flickr, and just makes the whole thing a breeze for the user. So — awesome.
There are at least 55,000 images from Flickr in Commons at the moment. (Around 2.5% of the total.) It’s common enough, and causes enough confusion, that the community has built a plethora of tools to try and make it easier:
- Flickr upload bot in conjunction with a toolserver tool
- FlickrReviewR bot trys to automatically confirm any Flickr licensing claims
- Trusted users double-check any that FlickrReviewR couldn’t automatically confirm
(The main reason Commons instituted the flickrreview system was because Flickr lets people change their licenses without any kind of historical display, which is seriously uncool, as far as trying to figure out if a stated license was ever valid goes.)
If we had ImportFreeImages, we could more or less forbid people from manually uploading Flickr images, and goodbye Flickr hassle!
So that’s my list. There are other things that I want, such as structured data, but I don’t really see it as likely to happen by the end of 2008. 2010, maybe. These ones all seem within reach (OK, with the exception of #2, but you have to dream big, right?). If there’s anything you think I missed, drop me a note and let’s hear it.
Elsewhere on the web...
Commenting is closed for this article.