Working With MediaWiki by Yaron Koren Read Free Book Online Page A

talk" and "Image talk"
Discussions about uploaded files
NS_MEDIAWIKI
8
"MediaWiki"
System messages and wiki-wide CSS and JS content
NS_MEDIAWIKI_TALK
9
"MediaWiki talk"
Discussions about those system messages
NS_TEMPLATE
10
"Template"
Holds templates
NS_TEMPLATE_TALK
11
"Template talk"
Discussions about templates
NS_HELP
12
"Help"
Pages meant to help the wiki’s users
NS_HELP_TALK
13
"Help talk"
Discussions about help pages
NS_CATEGORY
14
"Category"
Holds categories
NS_CATEGORY_TALK
15
"Category talk"
Discussions about categories

    Most of these namespaces will be discussed in greater detail in later chapters.
    Extensions to MediaWiki can define additional namespaces of their own: some of the extensions that will be covered later in this book, like LiquidThreads, Semantic MediaWiki, and Widgets, do that.
    Administrators can also add their own namespaces to a wiki. When this is done, it’s usually in order to separate out types of content. The Wikimedia website Wikisource, for instance, has, in its English-language version, the namespace "Author", which holds all author pages, so that the URL for the poet Robert Frost is:
http://en.wikisource.org/wiki/Author:Robert_Frost
    Here, the "Author" namespace seems like it’s intended to provide disambiguation, so that a page about, say, a book called "Robert Frost" would automatically have a separate name.
    Personally, I tend to argue against using namespaces for disambiguation alone: it adds more complexity (one more rule for the wiki’s users to remember), it’s a different usage of namespaces than what they were originally intended for, and it’s not usually needed as a disambiguation tool — since for all but the largest wikis, there’s usually not much need to distinguish between two entities with the same name.
    There’s at least one compelling reason, though, to create additional namespaces for regular content, which is setting access control. A number of extensions that provide controls on both viewing and editing of content use namespaces to define which pages get which level of security (see here ). Usually, such extensions allow for defining security levels for categories as well, and sometimes also for individual pages, but namespaces are the most secure approach, since a page is attached to a namespace in a very direct way. For pages that have their security settings defined via categories, there’s always the chance that the category declaration will get accidentally removed in one way or another from a page, thus removing its security settings, at least temporarily. To be sure, for pages with namespace-based protection there’s the risk that someone will accidentally move the page into another namespace; but this is a smaller risk.
    Regardless, for whatever reason, you may want to create one or more additional namespaces for your wiki. In that case, the first step is to choose a number for your namespace; or rather a pair of consecutive numbers, since namespaces almost always come in twos: a namespace for the main content, which has an even number, and the one for its equivalent talk pages, which has the odd number that’s one higher. You of course should choose a pair of numbers that haven’t already been taken: that includes the IDs of all the default MediaWiki namespaces, as well as namespaces taken by any MediaWiki extensions you use, or may use in the future. For security’s sake, you may as well not use namespace numbers taken by any extensions. You can see the complete list of namespace IDs currently used by MediaWiki extensions here:
https://www.mediawiki.org/wiki/Extension_namespace_registration
    Once you’ve decided on a number, or numbers, for your namespaces, you can register them within LocalSettings.php. For every namespace, you should add two lines, which look like the following:
define( "NS_BOOK", 500 );
$wgExtraNamespaces[NS_BOOK] = "Book";
    The way namespaces are structured can lead to one potential awkwardness. Let’s say you create a