Manual of Style

The **Manual of Style** contains the list of standards for creating and/or editing articles, user pages. etcetera. These guidelines should be followed at all times by contributors, as repeated or major violations of the Manual of Style will result in varying degrees of punishment.

**LAST REVISION: 17/10/2023**

Please note that the Manual of Style is subject to change at any time.

## Language

The preferred language for all articles, and everything on this wiki, is American English, and **not** British English. A major word, which is used commonly on this wiki's articles, is **center**, and not British English's **centre**. Please refer to this Wikipedia article for more information on differences between the two.

However, as for dates, we follow Europe's DD/MM/YYYY date format. Additionally, when a timeline is present (two dates next to eachother), connect both of them with a dash. (e.g. 9/15/2023 - 10/2/2023)

## General Article Regulations

This section will detail most basic regulations regarding the creation/editing of articles.

* Contributors should make sure no grammatical or spelling errors are made.
* Contributors should stay away from first-person pronouns, such as "I" or "Me".
	+ All articles should be written in a third-person view whenever possible, though second-person pronouns, such as "you", are occasionally allowed, an example being an article that **needs** to directly refer to the reader, such as this article.
* The Table of Contents (TOC) should be removed from articles that have only 5 headers or less.
	+ Adding `__NOTOC__` anywhere in the article will remove the TOC.
* No explicit language should be included within an article at any point.
* Abbreviations of articles are allowed, but only after they've **already been introduced** with their full name in a prior section of the article.
	+ It is still recommended to use the full name whenever possible.
* Unicode characters should be avoided when possible, outside of certain scenarios when they're needed to describe a key on a keyboard, such as the Windows key. (⊞)
* Everything mentioned in the list below should **always** be capitalized. Anything not in this list does not have to be capitalized if not linked to.
	+ The Names of Elements
	+ All Spells

## Structuring

This section will detail how articles should be structured and formatted, alongside proper usage of typefaces, such as **bold** text.

### Bold

The usage of **bold text** is reserved for the following:

* The first mention of the article's name. (e.g. **Manual of Style**)
* Stats of Weapons (e.g. **23 Damage**.)
	+ This does NOT include stats such as damage, e.g. 22 headshot damage, though the amount of headshots required, for example, would be bolded.
* To emphasize certain words in an article.

### Italics

The usage of *italic text* is reserved for the following:

* Controls/keybinds for certain actions.
* Soundtrack names.

### Links

When adding a link, there should only be one link to a specific article under one heading. Examples of this would be linking to the Wiki Staff page, but not linking to it again until the next header.

**TBA, MORE REGULATIONS WILL BE ADDED LATER.**

## Templates

Templates are used heavily for formatting and organizing articles. You can put a template into an article via two curly brackets, being { and }, then placing the template's name in the middle of them, and filling out the required information if the template has any parameters.

The most frequently used templates in various types of articles will be listed below, and linked to for you to view their respective parameters and information. You can view more templates via searching for them, with the search needing to start with "Template:".

* Weapons - Weapons Template
* Miscellaneous items - Equipment Template
* Features which don't fall into other categories - Feature Template
* Locations - Location Template
* **TBA**

## Header Guidelines

While most of the time, an article will use regular Fandom headers, there are a few exceptions, which will be detailed in this section, alongside when to use headers.

### Custom Headers

The Arcane Vitality Wiki has a custom header template, which can be used via the following code: `{{Header|TEXT}}`. Guidelines on how to use the custom header are as follows:

* At the top of an article, preferably with the text "Description", before any other code.
* To separate multiple tables that are in succession, such as on the Weapons page.

**Custom headers should NOT be used:**

* In place of regular Fandom headers.
	+ Especially not directly next to infoboxes.

**TBA, MORE REGULATIONS WILL BE ADDED LATER.**

## Images and Galleries

This section will detail what makes a high quality image, when to use images, galleries within articles, and images within infoboxes.

### General Image Regulations

* As a starting point, images should be as high quality as possible.
	+ What this means is to take images on max graphics settings, without Arcane Vitality's low graphics mode setting being enabled.
	+ The high quality shadows setting is optional, but highly recommended to be enabled.
* Images should **always be named** to what the image is describing before being uploaded. File names like **"Screenshot (902)"** or **"WIN\_20238172\_11\_19\_03\_Pro.png"** are hard to find, and aren't helpful.
* Unless it's an image of a location, or another case where the removal of the background wouldn't be necessary, the background of images, **are to be removed.**
	+ It is recommended to accomplish this through a site such as remove.bg, just make sure you correct any mistakes it may make.
* Images should all either be in the .png, .jpg or .jpeg format, with the former being especially preferred.
	+ Images not using any of these three formats will be deleted and replaced. (If necessary.)

#### Locations

* For images of locations, the use of cinematic mode (*Shift + X* on PC) is vital when taking images, as it hides almost all UI elements.
	+ it's recommended to turn off any settings that add things to the screen, such as the FPS counter, as that will not be removed by cinematic mode.
* Getting as much of the location as possible in the image is recommended, this is primarily done by going to a corner of the room that showcases most major features of it.
* All images of locations should be taken in first person, to avoid the user's avatar being visible.

#### Images in Infoboxes

* Images within infoboxes shouldn't be very big in terms of height, as this may stretch out the infobox significantly.
* Multiple images in an infobox should be close to pixel size in eachother, as to avoid the images moving as much as possible, when swapping between them.
	+ While the pixel size can be changed through certain sites, it is recommended to just have the images be similar in pixel size when taking them, as modifying it through a site can only do so much.

### Images in Articles

When putting an image in the article itself, typically for the purpose of describing something, you should make it a **thumb image**, which will make it appear to the side of the article.

The code for making a thumb image is as follows:

```

```

Preferably all thumb images should be on the right instead of the left, though either is acceptable. Make sure to **adjust the pixel size** depending on how large you need the image to be, just don't go overboard, usually between 150 - 300 px is acceptable.

### Galleries

While some images, such as those used to describe certain things in an article can be put inside of the article itself; most images should go in a gallery.

Note that galleries, and by extension the gallery header, should **always** be at the bottom of an article, under all other information. The code used to make a gallery is as follows:

```
<gallery>
Example1.png|Example Text 1.
Example2.png|Example Text 2.
Example3.png|Example Text 3.
Example4.png|Example Text 4.
</gallery>

```

Galleries should **always be at the bottom of an article**, though above navigation templates and categories. Additionally, unlike other forms of adding images, adding File: before an image is not necessary.

#### Tabbers

Tabbers are used heavily in galleries, as to reduce the space galleries take up when viewing it, and just general organization. Adding a tabber is simple. An example:

```
<tabber>
<gallery>
Example1.png|Example Text 1.
Example2.png|Example Text 2.
Example3.png|Example Text 3.
Example4.png|Example Text 4.
</gallery>
<gallery>
Example1(Legacy).png|Old Example Text 1.
Example2(Legacy).png|Old Example Text 2.
Example3(Legacy).png|Old Example Text 3.
</gallery>
</tabber>

```

If you wish to add videos to a gallery, make a tabber specifically dedicated to videos, however do **not** include the normal gallery code, as galleries do not support videos. Just opt for the regular File: method instead.

#### Complex Tabbers

Complex Tabbers are occasionally used for further organization of large galleries. Complex Tabbers are bit harder to understand and/or make, however they're still fairly simple. An example:

```
<tabber>
{{#tag:tabber|Lower Ranks=
<gallery>
Cadet.png|Cadet.
Private.png|Private.
Corporal.png|Corporal.
Sergeant.png|Sergeant.
Staff Sergeant.png|Staff Sergeant.
Example1.png|Example Text 1.
</gallery>

{{!}}-{{!}}
Officer Ranks=
<gallery>
Lieutenant.png|Lieutenant.
Captain.png|Captain.
Major.png|Major.
Colonel.png|Colonel.
General.png|General.
Example2.png|Example Text 2.
</gallery>
     }}

```

Breaking it down, `{{#tag:tabber|SAMPLE TEXT=` is put under the main tabber category, being `|-|TEXT=`, to make a sub-tabber; then continuing the tabber as normal.

However, to make a second sub-tabber, `{{!}}-{{!}}` is added after ending the first sub-tabber's gallery, then making another sub-tabber under it, an example above being `Officer Ranks=`, rinse and repeat. To end the complex tabber completely, close it with }}, then continue the rest of the tabber. More can be made afterwards using the same process.