MediaWikiDoc:Subwikis

Techniques: Software: MediaWiki: Subwikis

Benefits of Subwikis

The basic question is this: Is there any need for the idea of subwikis?

I've been experimenting around with loading the same wiki data from different files on the same server, so that I could have:

• Definitely Needed
  • A different logo, different CSS styles (different default and maybe different styles available)
  • Different links on the sidebar (or same links, but they bring up text appropriate to the project)
  • A different default page (Main Page)
• Would be a big help
  • A different default namespace, so that new articles were automatically prefixed with the subwiki's project name, and articles prefixed with that name were automatically shown without it in the title
  • Articles written for the main wiki or for other subwikis would show up with their logo & CSS

I originally started out with the idea of just creating a separate wiki for each project. At some point, squeakymewmew seemed to be unhappy with this idea -- she seemed to want (though it was never 100% clear to me) for all my wiki projects to mingle together indistinguishably in the squadwiki.

I can understand the idea of wanting all those pages to be sociable and mingle with their peers, so as to better enhance the value of the main wiki -- but when each project has its own purpose and vocabulary, this gets very confusing. For example, if you see an article called "shipping", is it an issuepedia article about ethical issues involved in the shipping industry? Or is it a page about vbz.net's shipping policies, or some information about where to ship Sluggite Exchange items? If you have entirely separate wikis for issuepedia and vbzwiki, or at least separate *sections* where it's clear what the context of any article is, there's no ambiguity.

I've pretty much convinced myself, then, that each wikiproject does need to have its own context, where people can safely post an article with a name like "groups" and know that it refers to, say, the Linux "groups" command, because you're in the LinuxWiki.

Furthermore, it looks pretty easy to set up a group of wiki projects so that they can all link transparently to each other -- e.g. with the default config of MediaWiki, you can just say [[WikiPedia:Article Name]] and it will create a link to the appropriate wikipedia article (in English) formatted as an intra-wiki link (as opposed to an external link with the little boxes after).

So the big question then is: what are the advantages, if any, of sharing data between wiki projects? And is it worth the bother of trying to do so? So far, here's what I've come up with:

1. Commonality of users: create an account on one wiki, and you have an account on all of them. Log in to one, you're logged in to all (this may be difficult due to the nature of cookies, but it's still a nice idea.) Even nicer would be if [[User:Yourname]] pointed to the same page, or at least pulled up the same text, across all wikis. Perhaps there's some way to share just the userbase between wikis? I think I've even seen discussion of this in the mailing lists. (Some of the issues regarding this are discussed here.)
2. Interwiki searching: The "main" wiki would let you search all the subwikis, whereas searching one of the subwikis would just search within that context. (Perhaps there would be a "[x] search all wikis" option.) Is this useful? Not sure.
3. Interwiki article movement: In a masterwiki-subwiki arrangement like this, articles which are arguably "interdisciplinary" could be posted in the main wiki, and perhaps later moved to a subwiki if their focus resolved into something more appropriate for one or the other. This would not work as well with separate wikis; the article would have to be replaced with a "forwarding" link on one side, requiring an extra click-through from the user. This could be solved with a little custom-coding to return an http forward instead of a link, but much code would have to be written to allow forwarded pages to be maintained. Also, it often happens that a topic-area starts out small and it only later becomes apparent (after many, many articles have been written) that a separate wiki would be useful -- and while moving a large number of articles from regular space into a namespace isn't exactly quick, it's a lot easier than copying-and-pasting them into the new wiki while leaving forwarding links in the old locations.

So we have two things which might be accomplished in other ways, and one which might not be useful. Suggestions? Thoughts?

That's all from me for now. --Woozle 21:16, 10 Jun 2005 (CDT)

Notes on First Attempt

I was able to get as far as having the front page and other pages of the Hypertwiki to load from a different URL, utilizing a different directory and index.php file on the same server, but I was not able to get it to display nicely (i.e. with the proper stylesheet). Instead, it displayed in the format usually used for printing. I was unable to figure out why it was not displaying correctly; the correct stylesheet data appeared to be loading, the stylesheet's contents appeared correct, and the Page Info tool shows all the images.

In order to get this far, the following changes were needed (some were only to change the wiki's home dir from /wiki to /):

• modifications to localSettings.php -- several fairly obvious changes
• one modification to includes/DefaultSettings.php: "$wgServer = '';"

I hate to give up when it seems so close... but I just don't have the time to come to a deeper understanding of MediaWiki at the moment.

Update: It seems very likely that the entire problem with my earlier attempt was that .htaccess needed to contain a line to tell Apache to deliver .css files as CSS rather than plaintext. Apparently many browsers (including FireFox) will ignore CSS if it isn't sent with the right mime type. --Woozle 15:04, 11 Jun 2005 (CDT)

2005-09-26 A little more clarity

A little more clarity on how wiki software should work, to make it easier to implement subwikis &ndash or, more to the point, to be able to dive into specific subject areas on a wiki without worrying about naming conflicts or contextual miscues (subwikis being more or less an automatic by-product)

For all the following modifications, I am proposing unlinking the URI from the article name; in other words the URI will be stored separately from the article's displayed title, so they don't need to be the same.

Modification 1

Automatic hierarchical topic-spaces with magic delimiter character (we'll use "/" so that to avoid conflict with MW "namespaces")

• An article with the URI "whatever/example/something/stuff" is shown with the title "stuff" but shown as belonging to the category "something" (e.g. with a linkback, though this should probably be definable by skin/stylesheet) which belongs to "example" etc.
• Internal links on the "whatever/example/something/stuff" page are relative to the current URI -- a syntax suggestion (others are possible):
  • [[things]] refers to the URI "whatever/example/something/stuff/things", i.e. a sub-article
  • [[/things]] refers to "whatever/example/something/things", i.e. an article at the same level
    • [[//things]] refers to "whatever/example/things", i.e. a parent-level article (aunt/uncle)
    • [[////things]] refers to "things", i.e. a root-level article
• The root wiki is treated as another wiki named "@", with an automatic interwiki link in the format "@:URI", e.g. "@:whatever/example" would link to "whatever/example"

For longer article titles, the article's URI-name should probably be a shortened version of the title, taking the URI context into account. For instance, "Linux setup and configuration" could have the URI "tech/linux/setup".

Under this scheme, a "sub wiki" becomes almost trivial in that you could have a separate domain (e.g. linux.tech.hypertwiki.org) -- go straight to a given URI (e.g. tech/linux) and it would appear more or less as if the "Linux" page were the homepage of a completely separate wiki. Links to Linux-relevant articles would not have to be carefully named so as to include "Linux" in the title, as they would now.

This would probably also largely remove the need for the "category" system, though there should be some way of displaying all sub-articles. A navbar at the left is what comes to my mind, showing at least the current topic (e.g. "Linux") and a list of short-URI sub-article names, with links, and maybe an "expand" link to show the full tree back to the root (perhaps a "root wiki" link for subwikis, to show the current subwiki's location within the master wiki as well). Other automatic links that might be helpful would be "full tree" (all articles under this one, shown as a tree) and "index" (alphabetic index of all articles at any level under the current context).

Modification 1a

The hierarchy need not even be a tree or even necessarily acyclic in order for this to work. For instance, if we have an article about Durham, NC -- which is part of North Carolina, but also part of the NC Triangle Area and part of Durham County -- we could have the URI "earth/us/nc/durham", but also "earth/us/nc/triangle/" which contains a link to [[durham]] (URI "earth/us/nc/triangle/durham") and "earth/us/nc/durham county/durham" (same). The Durham NC article itself would declare its parents (via a category-like syntax) to be "earth/us/nc", "earth/us/nc/triangle", and "earth/us/nc/durham county" (e.g. "[[parent:earth/us/nc]]" -- though this might actually work better using the article ID scheme in option 2).

The main change here, then, would be the addition of "parent"-declaration syntax and corresponding changes in the database (i.e. any article may have an arbitrary number of children and an arbitrary number of parents, as opposed to an arbitrary number of children and only one parent).

Modification 2

Primary linking by article ID Although I think we should continue to support linking by article name – as this makes it easier to "request" articles, to create requested articles, and to keep track of article requests – perhaps the primary means of referencing other articles should be by using their ID in the database. This would largely negate the need for internal "redirects" and link updates when an article's name changes. It would not remove the need for "disambiguation" pages, but it would reduce the number of times when a disambiguation page was arrived at instead of the intended article.

I would also propose that an article's URI could make use of either the article's ID or title; whether these were kept in separate URI folders (e.g. "sitename.com/a/article_name" vs. "sitename.com/n/3415") would be up to the administrator of each wiki site, in much the same way it is currently their decision to have the wiki located under (e.g.) "/wiki" or "w/" or to just put it in the root folder (as in this wiki). Having them in the same folder would mean that an article's URI could not be just a number (e.g. "2005") because there might be an article ID with the same number, but with the hierarchical naming as discussed in Modification 1 above, this is less likely to be a problem (e.g. "2005" could have the URI "dates/2005", which would not conflict). Additionally, a site admin might decide to have a rigid format for article ID URIs, e.g. "at least 6 digits, leading zeros if needed" would eliminate the conflict with year-named articles even if they were in the "root", as would having a short prefix such as "n" in front of all article-ID URIs ("sitename.com/n3415").

Thus, links to existing articles could be of the form [[article name|link text]] or [[0000|link text]]. Perhaps the wiki software would even expand the latter form to include the article name, for human reference: [[3415 Article Name|link text]] .