New Super Mario Bros Versus:Style Guide

This page is a guide on how to properly style the pages in a consistent manner. The *Minecraft* wiki's style guide page is currently acting as a base for this wiki's guide. The Mario wiki's Manual of Style was also looked at for this guide.

This page is currently a WIP. Many sections need to be reworded, altered to fit this wiki better, or completed.

This article aims to provide a comprehensive **style guide** for all Minecraft Wiki articles to follow. There are often disputes over which style rule or formatting to use so an official style guide helps resolve these disputes and reach a consensus.

Although Wikipedia already provides a more general style guide, a more specific one is necessary for *Minecraft*-specific guidelines. As such, only guidelines pertaining to the Minecraft Wiki and its basic formatting rules are included here. If any contradiction arises, this page always has precedence over its subpages and the Wikipedia style guide.

## Redirects

If a redirect leads to another wiki, it must use `{{soft redirect}}`. Redirects can be created if they fit one of the following:

* Alternative spelling of the title, such as "Armour" for "Armor".
	+ Incorrect spelling, typos, and irregular formatting are not allowed.
* Alternative or shortened name, provided the name is common usage, such as "Duck" for "Chicken". Previous in game names are also allowed, such as "Workbench" for "Crafting Table".
* Previous article title, including if the article was moved to another wiki.
	+ An exception is if the previous title was not commonly used.
* Alternative capitalization or form, including changing the title to plural case.
* A part of a merged or multi-topic article, such as a potion or a mentioned feature.

## Article titles

Article titles should generally be in the singular form, except in-game features with plural names (e.g. Boots).

## Writing

This wiki's purpose is to document facts. Therefore, always avoid personal commentary, speculation, and unsourced information. Generally speaking, information does not require sources if they can directly be seen in-game or are otherwise obvious. Other information however, such as quotes from Mojang Studios employees and information that is not widely known, must be sourced with a proper reference. The `{{citation needed}}` template should be placed after any information that requires a source. Do *not* add content to an article without a proper source.

Articles in the main namespace should always be written in the third-person perspective and without terms referential to the reader ("you", "your", etc.). The exception to this is tutorial pages, where in most cases "you" is the most appropriate pronoun to use when referring to the player. Try not to use abbreviations of words either. For instance, sentences like "You shouldn't come close to creepers because they'll explode and kill you." should be written as "A player can be killed by approaching a creeper close enough to cause it to explode."

To emphasize points, *italics* should be used, not **bold** or ALL CAPS.

Tutorial information should be present *only* in tutorial articles. This includes navigational features of blocks or textures. Tutorials may be linked from other articles if relevant though.

### Keeping articles concise and up to date

In short, articles should contain only information that is up to date, i.e., implemented in the latest *full* version of the game. Anything that is outdated should be moved to the History section of the article. When something changes, note the change in the History section and remove the outdated information from other sections of the article. It is unnecessary to mention when a particular feature was implemented; this is once again reserved for the History section of the article. Sentences such as "Trading, which was implemented in 1.3.1, is a feature that allows players to exchange emeralds (previously rubies) for other items." should be written as "Trading is a feature that allows players to exchange emeralds for other items."

The introduction should state the current description of the block with the current release. History information is good, but for clarity, it should be described in the chronological order in a single place: the History section of the article.

#### Future

Content added in future updates should be added as its own section called *Upcoming*. Upcoming features must be noted as well in the history section using the proper upcoming header.

Upon the release of the update, all content that is now outdated must either be moved to the history section or removed.

### Quotes

All quotes should be copied verbatim. Any additional content added within the quotation marks must be enclosed in square brackets. Terminal punctuation must go inside the quote only if it is in the original; otherwise, it must go outside. If the quote contains an error that was present in the original, add `{{sic}}` after that text to show readers that it is not a transcription mistake.

### Spelling

Pages on this wiki should use *American English* unless the in-game name is British English.

The differences between American and British spelling can be subtle. The following examples often arise:

* Words ending in "-or": "colour" should be "color", "behaviour" should be "behavior"
* Words ending in "-ter": "centre" should be "center", "metre" should be "meter"
* Direction-indicating words ending in "-ward": "towards" should be "toward", "forwards" should be "forward", "upwards" should be "upward" and so on
* Words ending in the "-st" affectation: "whilst" should be "while", "amongst" should be "among", "amidst" should be "amid"

### Do not capitalize

Various lesser important items, such as coins or throwable shells.

### Do capitalize

**Character names**
* Character names (such as Mario or Luigi) should always be capitalized.
* This includes prefixes used when describing a character with a powerup (such as Fire Mario or Starman Mario).

**Stages**
**Powerups**

**Big Stars**

**Enemies**

**Tiles**

### Section headings

* Article main sections should start with level 2 headings (`== Heading ==`) and increase by one for subsections. *Never* use a level 1 heading (`= Heading =`); this is reserved for the article title.
* Headings should not have links or templates in them; links should be placed underneath, such as in a `{{Main}}` template.
* Although not required, having one space between sections and one space between the equal signs and the section name improves readability.
* Place any hatnotes and images immediately under the section heading, and then a space after those before the section content.
* Do not add blank sections unless tagged with `{{empty section}}` to request prompt expansion.
* For information on which sections should be in which order, see the Article layout section of this style guide.

### Italics

Any instance of "*New Super Mario Bros. Versus* " should be in italics, including any alternate names for the game. Any instance of the name of a videogame should also be in italics. For instance: "*Team Fortress 2*".

### Images

When adding screenshots to an article, make sure the screenshots use vanilla textures and UI. Screenshots that use custom texture/resource packs, UI mods and other custom content are not allowed.

Image captions should not have periods at the end, unless the phrase is a full sentence.

Images added to articles should fit the following guidelines:

* Images should showcase an attribute of the article's topic.
	+ Images should not show unintended strange or humorous behavior, such as mobs "sitting" on stairs.
	+ Images should not have the sole purpose of showcasing a bug, instead report the bug on the github page.
	+ Images showcasing usage of specific features as part of player builds should be avoided.
* Articles should have one image showcasing an individual attribute of the articles content. For example, a zombie wearing armor.
* Images should showcase the most up to date version of the game available for the content.
	+ Images that are outdated are subject to be removed or replaced with current version.

### Linking

*For complete guide to linking, please refer to Wikipedia's Manual of Style for links, although do note that some of the policies about linking listed there are different than many here.*
The use of links is a difficult balance between providing readers enough useful links to allow them to "wander through" articles and excessive linking that can distract them from their reading flow.

Underlinking can cause the reader to become frustrated because questions may arise about the article's contents, which can be resolved only by using the search option or other sources for clarification, interrupting and distracting the reader.

Overlinking may distract the reader because links are usually colored differently causing the eye to shift focus constantly. Additionally, if the same word is linked multiple times in the same paragraph it can cause the reader to question if the links are directing them to different articles or not.

The guidelines for linking are:

* No more than 10 percent of the words in an article are contained in links.
* Unless it affects the sentence's wording and readability in a negative way, two links should not be next to each other in the text so that it looks like one link.
* Links for any single term should not be excessively repeated in the same article. Excessive linking is defined as linking the same term multiple times within a portion of text that can fit on a typical viewer's screen. Remember, the purpose of links is to direct the reader to a new spot at the point(s) where the reader is most likely to take a temporary detour due to needing more information.
* Duplicating an important link distant from a previous occurrence in an article may well be appropriate. If an important term appears many times in a long article, but is linked only once at the beginning of the article, it may actually be underlinked. Indeed, readers who jump directly to a subsection of interest must still be able to find a link. But take care in fixing such problems, the distance between duplicate links is an editor's preference; however, if in doubt, duplicate the term further down the article.

Linking to a redirect is preferred over using a piped link except in templates and other pages that are transcluded. When a piped link is unavoidable, it should not point to a redirect. If a redirect can be avoided using a suffix on the link, that is preferred. E.g. Using `[[Creeper]]s` instead of `[[Creepers]]` is desired.

### Date formatting

To avoid ambiguation, most dates should be written in "Month DD, YYYY" format, *e.g.* "December 10, 2011". Do not use superscripts or suffixes such as "April 23rd" or "4th of May". If a numeric or terse date is needed (such as in a table), then use YYYY-MM-DD, always with 2 digits for month and day (*e.g.*, 2011-12-10 or 2012-05-04). Besides being the ISO standard, dates in this format naturally sort properly, say if the table column is later made sortable.

Try to avoid seasons for dates such as "Summer 2021" or "Fall 2022". On Earth, the northern and southern hemispheres have opposite seasons. Instead use phrases like "Mid-2021" or "Late 2022".

### Commands

In-game commands should be in a specific format for ease of understanding. Literal keywords that must be typed in chat do not have any brackets for formatting applied (e.g., `/data merge`). Variables must be inside angle brackets and should be italic (e.g., `<*target*>`). Optional content must be inside square brackets, but these brackets should not replace any angle brackets (e.g., `[<*scale*>]` is an optional variable whereas `[scale]` is an optional keyword). A list of valid keywords should be placed in parentheses with each option separated by a pipe (e.g., `(eyes|feet)`. In the example `/advancement (grant|revoke) <*targets*> only <*advancement*> [<criterion>]`, `/advancement` and `only` are literals to be typed exactly as-is in chat, `(grant|revoke)` is a list of choices for literal text where either `grant` or `revoke` must be typed in chat, `<*targets*>` and `<*advancement*>` are required variables that must be replaced with valid values, and `[<*criterion*>]` is an optional variable that must be replaced with a valid value.

## Files

File names should be consistent so they are easier to find. Files used in the infobox of articles should be titled with the exact name of the subject as seen ingame using en-US (when possible), and must be an isometric render. Old revisions of files should take the format of "*Subject* JE*X* BE*Y*", where *X* and *Y* are the revision numbers for Java Edition and Bedrock Edition, respectively. This number is incremented each time the texture is updated in game (e.g., not in teaser images). "*Subject*" should redirect to the most recent revision. If the current textures for Java Edition and Bedrock Edition differ, "*Subject*" redirects to the Java Edition texture, while "*Subject* BE" redirects to the Bedrock Edition texture. Textures added in snapshots should follow this naming convention, though "*Subject*" should not redirect to the texture until it is included in a full release.

For example, the texture files for cobblestone would go as follows:

* "Cobblestone JE1.png"
* "Cobblestone JE2.png"
* "Cobblestone JE3 BE1.png"
* "Cobblestone JE4 BE2.png"
* "Cobblestone JE5.png"
* "Cobblestone JE6 BE3.png"
	+ "Cobblestone.png" redirects here.

The "*Subject* JE*X* BE*Y*" files should be used in places where the texture shouldn't change if the texture is updated, such as history sections and version guides. The "*Subject*" files should be used in places where the texture should always be up to date, such as infoboxes.

## Article layout

For the sake of consistency, all articles of a specific type should follow a general layout.

1. Hatnotes (i.e. notes that belong at the very top of an article page)
2. Message boxes
3. Infoboxes
4. Introduction with a general description
5. Article body
6. See also
7. Notes and references
8. Applicable footer navboxes
9. DEFAULTSORT
10. Categories
11. Interwikis

Be smart when adding a message box: too many boxes at the top of a page or a section is not useful, and they can clutter the page descriptions in search results. If there is already one, move the ones that are not necessary for the reader lower on the page, for example in a relevant section or at the end.

### Specific layouts

If an article does not contain a layout currently, one can be proposed on the talk page; otherwise, attempt to use a layout that follows a similar style to an existing layout. Current article layouts include:

* Stages
* Powerups
* Enemies
* Versions