Comments on: Forthcoming features to look out for http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/ Ponderances of a MediaWiki developer Fri, 07 Aug 2009 18:25:33 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: David Gerard http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/comment-page-1/#comment-36 David Gerard Mon, 30 Apr 2007 15:34:11 +0000 http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/#comment-36 <i>"It might be good if we could provide better documentation on the whole setup process for those who *are* interested, however."</i> That'd be fantastic. Particularly for corporate intranets, who will have <i>no</i> qualms about free-as-in-Java, but who do notice how badly the MySQL text search sucks. I know, I've had 'em asking me about the text search at work. (I'm currently trying to inveighle a position where my group, and particularly me, run MediaWiki as the standard in-house wiki software for the whole company.) “It might be good if we could provide better documentation on the whole setup process for those who *are* interested, however.”

That’d be fantastic. Particularly for corporate intranets, who will have no qualms about free-as-in-Java, but who do notice how badly the MySQL text search sucks. I know, I’ve had ‘em asking me about the text search at work. (I’m currently trying to inveighle a position where my group, and particularly me, run MediaWiki as the standard in-house wiki software for the whole company.)

]]> By: robchurch http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/comment-page-1/#comment-35 robchurch Mon, 30 Apr 2007 00:14:57 +0000 http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/#comment-35 Well, one reason I can think of is that it requires quite a bit of setup; a lot of our third party users won't be in a position to compile and run a Java-based search daemon on their servers. It might be good if we could provide better documentation on the whole setup process for those who *are* interested, however. Well, one reason I can think of is that it requires quite a bit of setup; a lot of our third party users won’t be in a position to compile and run a Java-based search daemon on their servers.

It might be good if we could provide better documentation on the whole setup process for those who *are* interested, however.

]]> By: David Gerard http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/comment-page-1/#comment-34 David Gerard Sun, 29 Apr 2007 23:15:36 +0000 http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/#comment-34 Search that doesn't suck? OH DEAR GOD YES PLEASE. Silly question: why is the Lucene search not in the default Mediawiki tarball, which just uses the shitty-beyond-ht://dig MySQL search? Search that doesn’t suck? OH DEAR GOD YES PLEASE.

Silly question: why is the Lucene search not in the default Mediawiki tarball, which just uses the shitty-beyond-ht://dig MySQL search?

]]> By: robchurch http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/comment-page-1/#comment-33 robchurch Sun, 29 Apr 2007 15:46:26 +0000 http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/#comment-33 There's an OpenID extension in Subversion (http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID) developed by Evan Prodromou. I haven't used it myself, but I have heard that others have got it working, and I presume Wikitravel use it. I don't know if there are plans to integrate the efforts of the Semantic MediaWiki and similar projects into the mainline code. Semantic MediaWiki itself is an extension, which we could install on a Wikimedia site if that site required it, although it's not the most efficient extension in the world. One problem with all these different approaches to semantic data is that users don't see a clear use case for them, which makes it much less convincing as a worthwhile feature. "Semantic features" need to be broken down into clear task-oriented use cases with definite, perceivable benefits, otherwise our users aren't going to touch them, and it'll be an academic exercise. There’s an OpenID extension in Subversion (http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID) developed by Evan Prodromou. I haven’t used it myself, but I have heard that others have got it working, and I presume Wikitravel use it.

I don’t know if there are plans to integrate the efforts of the Semantic MediaWiki and similar projects into the mainline code. Semantic MediaWiki itself is an extension, which we could install on a Wikimedia site if that site required it, although it’s not the most efficient extension in the world.

One problem with all these different approaches to semantic data is that users don’t see a clear use case for them, which makes it much less convincing as a worthwhile feature. “Semantic features” need to be broken down into clear task-oriented use cases with definite, perceivable benefits, otherwise our users aren’t going to touch them, and it’ll be an academic exercise.

]]> By: Joe http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/comment-page-1/#comment-32 Joe Sun, 29 Apr 2007 13:20:57 +0000 http://blog.anubite.co.uk/index.php/2007/04/28/forthcoming-features-to-look-out-for/#comment-32 On the single User login: any idea if media wiki sites will be able to use openID any time soon? I've been looking at the ultimate wiktionary and the Semantic wikipedia sites too. Any idea when those idea for structuring data might get incorporated? Joe On the single User login: any idea if media wiki sites will be able to use openID any time soon?

I’ve been looking at the ultimate wiktionary and the Semantic wikipedia sites too. Any idea when those idea for structuring data might get incorporated?

Joe

]]>