On 30/05/05, Erik Moeller erik_moeller@gmx.de wrote:
As part of Wikidata, I'm rather fundamentally redesigning the namespace logic of MediaWiki, and I'd like to invite input, specifically on
- whether I should try to get these changes ready for 1.5, or commit
them to a separate branch,
Well, I believe Brion is keen to see 1.5 ready sooner than later - according to http://mail.wikipedia.org/pipermail/wikitech-l/2005-April/028899.html he was hoping it would be in beta a month ago, so landing a change as fundamental as this is unlikely to be popular with him. And for the record, I think he's right - if the unstable branch stays unstable for too long at a time, features that are fully mature take ages to see the light of day.
- whether there are objections or suggestions regarding any of the below.
Simply put, I am moving namespaces from the language files and from Namespace.php into the database. In my present implementation, the namespaces are loaded from the DB on every request, but I will add support for memcached as well.
Seems reasonably sensible so far.
(ns_target is a new feature I'm working on which allows you to specify a default "destination prefix" for any link from within that namespace. This can be an InterWiki link or a namespace. That will be useful in a variety of contexts, for example, within a Wikibooks module, all links could point to pages within the namespace by default; within a Wikidata page, all links could go to Wikipedia by default, etc.)
That sounds like something a lot of people will like - not so much often-requested, as often-misunderstood-that-it-already-works. One thing occurs to me though - can the "main" namespace have synonyms (or, perhaps, be removed altogether)? This is important because in the Wikibooks scenario (see also something like the Mozilla Wiki, which uses namespaces more-or-less in this idiom), having [[foo]] always point to something completely different to [[:foo]] may not be an ideal way of distinguishing those two pages.
This means that the default namespace name is "File", and that "Image", "Video" and "Sound" redirect to it. No more "Image" prefix for sound files! It's quite a pleasure to see this working. There can be an arbitrary number of namespace synonyms for any namespace.
That's another feature that could be very useful, if used carefully - as well as that situation, there are sites where it would be nice for "Project", "Wikipedia", *and* a translated name *all* to work. I've also considered it would be useful to have abbreviated versions of namespace names - so "WP:" could be an alias for "Wikipedia:"; the existing "shortcuts" could be "Wikipedia:VP" etc but still work, and you could type "WP:Glossary" without anyone having created a shortcut for it.
Of course, as with InterWiki prefixes, the danger is that as soon as someone *removes* such a synonym, all links using it instantly break (or, more confusingly, not instantly, because of caching).
The major part of the effort is getting this to work properly with all language files.
This is mildly off-topic, but why do all language files override methods which differ only in a reference to a global array? Why not just have the array a member variable and use inheritance properly? (The reason I discovered this was identifying a hack in LanguageFr.php::getNsIndex() that was accidentally copied to LanguageOc.php, which makes "Wikipedia:" a synonym for the actual translated name) I believe Special pages do something similar, defining global functions rather than just overriding an inheritted one. Is this because of a flaw in PHP's OOP model, or is it just bad design? [Or am I wrong and this is actually *good* design in some way?]