Jump to content

Wiki:Manual of Style

From Community Wiki | Soulbound: Online
This page is an official policy of the Soulbound Wiki. It has wide acceptance among editors and describes the standard all articles are held to. Follow it when writing or editing. Propose changes on the talk page first.
This page is about the wiki's writing style. For the index of all editing policies, see Wiki:Style guide.


The Manual of Style (often abbreviated MoS) sets out how articles on the Soulbound Wiki are written, titled, structured and categorised. Its purpose is consistency: a reader should be able to move from any page to any other and find the same conventions, and an editor should never have to guess how something is done. The wiki follows the Old School RuneScape Wiki conventions except where Soulbound differs; when a case is not covered here, match how the OSRS Wiki does it.

For the specific policies that expand on the sections below, see Wiki:Redirecting, Wiki:Categorisation and Wiki:Disambiguation. All four are indexed at Wiki:Style guide.

Page titles

Page titles are the most important convention on the wiki, because everything else — links, redirects, categories and searches — depends on getting them right.

  • The canonical title is the exact in-game name. Match the game's spelling, capitalisation and apostrophes precisely. Verify the name against the current game data, not against the old wiki: many existing titles are wrong or refer to renamed content.
  • One canonical page per subject. Every other spelling of that subject is a redirect to the canonical page — never a second article. This includes straight versus curly apostrophes (' versus ), differences of case, common misspellings, plurals, abbreviations and superseded names.
  • Use sentence case for item and most article titles: capitalise the first word and proper nouns only, unless the game itself capitalises the name differently. Where the game's own capitalisation is unusual, follow the game.
  • Do not include a leading "The" unless it is part of the in-game name.
  • Disambiguate collisions parenthetically — for example Ember (item) versus Ember (NPC). A dedicated disambiguation page is created only when a name has three or more meanings; for exactly two, place an {{Otheruses}}
hatnote on each. Where a quest shares a name with a location or item, the quest takes the bare name and the others take qualifiers.
  • No cross-namespace redirects — a title in the main namespace must not redirect to a project or template page, and vice versa.
Example. The quest known in-game as A Pirate's Life for Me has appeared on the old wiki under four titles. Pick the one that matches the game exactly (straight apostrophe, in-game capitalisation) and redirect the other three to it.

Language and tense

  • Write in British English. Use armour, colour, defence, jewellery, -ise endings and so on.
  • Use the present tense for content that is live in the current game. Use the past tense for content that has been removed, and the future tense only for content that has been officially confirmed as upcoming.
  • Use the serial (Oxford) comma: "swords, axes, and maces".
  • 'Italicise the titles of the game and other media. Write Soulbound in italics; item and NPC names are not italicised in body prose.
  • Bold the article's title once, at its first mention in the lead paragraph, and nowhere else.
  • Spell terms out in body prose. Avoid in-line abbreviations; where an abbreviation is genuinely common, introduce it in parentheses at first use and use it thereafter.
  • Write plainly and factually. Do not paste raw generated prose. Every statistic and name is taken from game data, not invented, and the writing is aimed at a player looking something up, not at an essay.

Article structure

Every article follows the canonical section order for its content type, documented at Wiki:Layout guide (page-type layouts). Whatever the type, every article ends with the same universal tail, in this order:

  1. Changes — the update history of the subject.
  2. Trivia — verifiable, sourced trivia only.
  3. References — the <references /> list.
  4. Navbox footer — the navigation box grouping the subject with its siblings.

General rules:

  • Every article carries a right-rail infobox — it is the visual signature of the page type and the source of the page's categories.
  • Keep body prose scannable. Push metadata into the infobox, push optional depth into collapsible sections, and push cross-links into the navbox footer.
  • Spin large sub-topics out. Use a {{Main}}
hatnote to point at a dedicated sub-page rather than letting a parent article grow unwieldy.
  • Lead paragraph first. Open with a single sentence saying what the subject is; do not start an article with a heading.

Images

  • Every item, NPC and quest should carry its real in-game sprite or icon. Prefer PNG with a transparent background and consistent framing.
  • Reuse before re-uploading. Thousands of files already exist on the wiki, many unused or mislinked; search for an existing file before uploading a new one.
  • Name files predictably so they can be found and reused: File:<Item name>.png for an item icon, File:<NPC name> chathead.png for a chathead.
  • An article with no image is flagged automatically. The infobox stamps the hidden Category:Pages needing an image category when its image field is blank — do not add that category by hand. See Categorisation § Maintenance categories.

Categories

Categorisation has its own policy at Wiki:Categorisation; in brief:

  • Categories are applied by the infobox automatically, not typed by hand. This is how the wiki stays consistent at scale.
  • An article sits in several categories at once: its primary type, its subtype or slot, its rarity, and any maintenance queues it currently qualifies for.
  • Maintenance categories are hidden (__HIDDENCAT__) and are self-populating work queues — stubs, missing data, missing image, needs review — not part of the browsing taxonomy.
  • Never fork a category into singular and plural, or into apostrophe variants. Follow the single agreed tree in Wiki:Categorisation.

Infoboxes and templates

  • Use the canonical infobox family, one template per content type (for example {{Infobox Item}}

, {{Infobox NPC}} , {{Infobox Quest}} ). Do not use the legacy X Infobox / XInfobox / …Seq / …Test generations — they are being retired.

  • Heavy rendering logic lives in one central template or module, so a single fix propagates to every page. High-traffic templates are admin-protected.
  • Test template changes on Wiki:Sandbox first, confirm the rendering, then roll the change out.

Sourcing and accuracy

  • Never trust an existing page's facts. Much of the wiki predates the current version of the game.
  • Every quantitative claim traces to current game data — a statistic, recipe, drop, reward or requirement must be sourced from the live game, not copied from an older page or guessed.
  • If a fact cannot be sourced, flag it rather than invent it. Tag the page for review (see the review queue) instead of writing something unverified.

See also