Hi,
You're right, there are quite a few optimizations that can be taken into account on article save. It is possible that on the full wikipedia the code would need to be extremely complex to manage the partial updates, but I haven't looked thru the code, just thought of it as a suggestion. It would be handy on any mediawiki db - and superb on wikipedia itself.
I've read a few of the Wikiwyg emails (there have been rather a lot, and rather a lot of supurious debate!). My 2c on Wikiwyg is that most editing tasks would be best achieved not from a Fckedit style editor, but from an augemented text editor. The first steps are already there with the (mostly useless) toolbar, but it could do a lot more before complex wysiwyg would be needed.
Ideas:
* A quick button to create a correctly formatted table. Asking for number of cols and rows. I find this a total pain, and it has rendered tables worthless to me, as a small change breaks the table. It could work as a DIV dialog or popup like fckedit. * Namespace/interwiki suggestion when entering names (though obviously what we have just been talking about is a step beyond!) * Should also work with template insertion. Ultimately should scan the template via XMLHttpRequest and give a list of template parameters back to the user. * Hot keys to make bold, italic, links etc (these may be there, but I haven't noticed them).
I notice that the wikiwyg stuff doesn't actually work that well - the indent in particular is lost, and if it is reduced to bold, italics and bullets it seems a little pointless - certainly a lot of effort. Most of the articles people complain about editing in Wikitext are filled to the gunnels with templates and extensions (like ref). An editor that handles those well is a tricky beast to design, let alone write. HTML editors - which are much more mature - tend to quickly revert to the source, since it often is the best way to handle such things.
However HTML editors work best when they suggest, and prod you along. I'd say any Wiki editor needs to look more down those lines - things like an auto preview of a template in a popup div would be far more useful that the traditional word ribbon.
One issue I have with developing all of these is the speed of MW startup. It cannot really be used to make AJAX type requests in its current form, as pages often take seconds to render. Not sure the best way to speed this up. The parser seems to be the slowest point in most of my profiles, but simple too much code to run thru for AJAX requests at the moment.
Best regards,
Alex Powell
On 8/16/06, Steve Bennett stevage@gmail.com wrote:
On 8/16/06, Alex Powell alexp700@gmail.com wrote:
I was wondering if it had an extension to keep its index up to date - an "OnArticleSave" hook. With that a really useful place to hook it in
That would be cool. Only three cases would need to be treated:
- brand new article: update the index taking into account that the new
article may be a redirect
- article that was a redirect is now a real article
- article that was a real article is now a redirect
This would affect a very small number of article saves, maybe like 1 in 100 or less? Obviously this level of integration is going to require serious support from the developers.
would not be just the search, but also the edit box. Little bit of js that checks for the user inputting [[, and then the suggest code kicks in with possible article matches. It would make article linking a lot easier.
This sounds like something better left for the likes of Wikiwyg?
Steve _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l