Namespaces

Pages on a MediaWiki wiki are grouped into collections called “namespaces” which differentiate between the purpose of the pages at a high level. Pages in certain namespaces can also have special properties or behave differently when they interact with other pages.

Namespaces are indicated in page titles by prefixing the page name with <namespace>:, so the prefix Help: in this page's title (Help:Namespaces) indicates that this page is in the Help namespace. Each namespace is identified by a number and a name, which can be translated and can also have some aliases.

A page whose name is not prefixed by a namespace lies in the mainspace. Note, however, that colons and prefixes can also appear in page titles without indicating a namespace: the page Foo:Namespaces is a page located in the mainspace because the namespace “Foo” does not exist. Similarly the page Help:Foo:Namespaces is in the “Help” namespace.

Source: MediaWiki Help:Namespaces

The concept of Namespaces is probably unique to MediaWiki. It is certainly a powerful and useful feature. Security can be assigned to each Namespace so that it can be public or restricted; content can be segregated into 'collections' by topic, and access controlled.

Namespaces are Numbered

MediaWiki ships with 18 built-in namespaces:

16 "real" namespaces, corresponding to actual pages, numbered 0 to 15, and grouped in subject/talk pairs^[1]
2 "virtual" namespaces (one for dynamically generated special pages, and one serving as an alias for direct file links), numbered -1 and -2, respectively. Since these namespaces don't correspond to pages stored in the database, one cannot create or delete pages in these namespaces, and there are no corresponding discussion namespaces.^[1]
Namespaces numbered 100-199 are reserved for site-specific namespaces, although there are some extensions that don't follow this convention. Extension writers use higher numbers, up to 32767.^[2]
Numbers from 3000 to 4999 are reserved for system administrators to define their custom namespaces.^[2]

Namespaces are identified by a Number and allocated a name or an alias: names can be changed but the Number must remain constant.

Content namespaces are allocated an even number; associated Talk or discussion pages are allocated an odd number.

Custom Namespaces are defined in LocalSettings.php.

A list of namespaces is shown when opening Tools --> Special Pages --> All Pages.

Content can be moved between namespaces.

Namespaces and the mh370wiki.net website

The table below lists the Namespaces used for content which is publicly accessible.

Section	Description	Namespace Prefix
Main Content	Contains all general articles Includes the Timeline.	No prefix
News	News and Media Statements from official sources, related to MH370	MH370News:
Safety Investigation Report (2018)	Includes extracts from the Safety Investigation Report which are then used as references or quoted in other articles.	SIR 2018:
Factual Information (2015)	Contains extracts from the Factual Information documents which were released in 2015. These extracts were used as references or quoted in other articles but have mostly been superseded by the Safety Investigation Report (2018)	FI 2015:
Communications	This section contains transcripts of voice communications, text of ACARS messages, metadata from satellite communications and information related to communications with flight MH370.	Communications:
Passengers	This section contains information about each passenger from Passenger Manifests and Seating Plans plus other details published in media articles.	Passenger:

Hidden Namespaces and Transclusion

In addition to the default namespaces in the MediaWiki installation, the mh370wiki.net website there are several 'hidden' namespaces; content namespaces which require a user account and log-in to access.

However, a significant proportion of the 'hidden' content is actually visible to anonymous users because it is transcluded into pages with visible namespaces.

For example:-

Reusable content, such as a Table from an official report, may be stored in a 'hidden' content namespace but transcluded into other pages as required. This ensures that a 'master' copy is formatted correctly and will always be the same when re-used.
The visible content in the MH370News: namespace is mostly transcluded from a content namespace which holds more than the visible content. For example, a media statement obtained from an original page source code will likely include custom css, or links which are outdated or not functional. The original is stored unchanged, and an edited version stripped of custom formatting is transcluded into the publicly accessible page.
The information displayed for each Passenger, or Crew Member on-board MH370 is collated from many sources. The displayed information is a transcluded subset of all that has been collected and stored in a 'hidden' content namespace.
Tooltips are transcluded into Glossary pages, and appear in context on all visible pages, but the tooltips (using the Extension Lingo) are in pages organised by topic in their own 'hidden' namespace. Instead of just one page for a glossary the mh370wiki.net website has over 50 pages in the tooltips section.
References are in the Main namespace, or NS_Main, but the references are indexed or cross-linked by Reference IDs. Each ReferenceID is a page in a 'hidden' content namespace. The content is transcluded as required.

To use a floating iceberg as an example, the visible content of the mh370wiki.net website is like the tip of the iceberg; a significant proportion of the website is not visible but supports the accessible pages through transclusion.

Hidden 'Workspaces'

Based on experience with the mh370wiki.net website, this website also has a hidden namespace for draft content. This is like a workspace where articles can be started but remain unpublished, where ideas can be kept before they are developed into an article format, and where formatting or features can be tested before being applied.

However, instead of moving a completed article from the draft area I found it better to copy the content into the final page. This avoids a redirect.