Documentation/General Housekeeping

If you have a question regarding specifics that aren't covered let someone know via the link provided in Documentation and it will get added.

**As an important note**: If any of the below is something you're not familiar with, or otherwise confusing, don't worry about it and do your best. We appreciate contributions to the wiki even if you're not able to make it perfect from the start and one of the wiki managers (or another contributor) will make any required fixes to it later.

#### General Housekeeping

While extensive information on a topic is appreciated, please keep single article sizes to a minimum. This assists with mobile compatibility in information display and helps to prevent users being overloaded with massive lengths of text.

If it's not absolutely necessary to include all of the details in the one article please consider breaking them off into a separate article with links where appropriate (or transclusion)

As a matter of irony, please ignore this article being a massive wad of text and completely going against what has been stated above.

#### Linking and Creation of Articles

Where able please create all articles as whole words with spaces (such as this article being `General Housekeeping` and not `GeneralHousekeeping`. The extra space isn't harmful to the addressing of the article and helps keep everything standardised. It also permits article links without requiring the additional link name text parameter if the link text would be the same as the article name (ie. capitalised).

Article names should also not contain any special characters unless required - an example of an article that would better fit with numbers is Patch Notes/v1.0.10, but we currently do not require naming things such as Recycler (Tier 4).

Articles should also be categorised if there is a current category set up that covers them. Please see Documentation/Categories for notes on what categories to add and how.

Wherever possible articles should be created with names as if they were folders on your computer. These will be relatively standard prefixes, some examples are:
This page: `Documentation/General Housekeeping`

Other article examples:

```
Survivors/Leader
Survivors/Stats
Survivors/Skill Tree

(Not yet implemented)
Items/Meals/Boiled Rice
Items/Crops/Rice Seeds

```

Etc.

When creating the article please note that the explicit address it is given does not have to match the article title, but should be something that makes sense within the standard naming system we have in place. Where you want your article to have a better title displayed at the top of the page (Instead of 'This/Is/An/Article Name') you can use the following wikitext at the top of the article's source:

`<noinclude>{{DISPLAYTITLE:The Title You Want To Show}}</noinclude>`

The 'noinclude' markup to prevent it being included in transclusion of a page (including one page inside another) as it will end up overriding the other pages title.

#### Article Content Transclusion

Transclusion is the whole or partial inclusion of one article into another. This works using a specific piece of markup in the source of an article that points to another article just like a link does. However, this type of article link causes the entirety (or part) of the linked article to appear as part of the normal flow of an article when viewed.

Making each article as small and specific as possible allows and then transcluding it into other articles for viewing allows us to centralise information - this means that when something changes we will only have to update one or two articles, rather than every single article the information was originally added to.

The syntax for transclusion is:

`{{:Article/Name/Here}}`

An example of this is the patch notes page (compare what you see when viewing the article vs what you see with the source editor) - That article has no actual content of its own, only transclusions of each individual patch notes article, but when viewed it automatically fills itself out for the end user to see.

Unfortunately transclusion cannot be done via the visual editor and must be done via source editing.

#### Uploading Files and Naming Syntax

Contrary to the above, file names will eventually have a standard syntax (many of them already do) and it is preferred shortened names be used without spaces and special characters. Once a naming standard has been set up please continue to use it, if you want examples of this refer to existing file names used in major articles.

Where able, please also upload images in 'True Color' (24-bit) PNG (preferably at least optimised). Unless the image actually contains <256 colours (or very close to) and no transparency, please do not use 8-bit palettised images. This also goes for JPG/JPEG and GIF images, where-ever possible keep it to PNG and WebP (lossless or quality 100). If you want to upload animated content please use file formats that support full colour and transparency (not GIF).

#### General Formatting and Wikitext Markup

##### Sections

Where able please break your information down into sections (using a section header) as it permits ready access via the Table of Contents for users who do not wish to scroll through information higher in the article. You can create a section by using the header markup.

##### Headers

Please use the smallest headers for sections (within reason - if it makes sense for the header to be large, make it large). The table of contents will automatically convert these into a tree based on the largest and smallest header used (it is safe to use a level 4 header without any level 3 or above headers, the same applies to a level 1 header and a level 4 header withough a 2 or 3).

##### Article links

In main body text (where possible) please add article links to key words at least once in the article so that users can access more detailed information without having to search for it. Please do NOT add article links to every reference to an item within an article, or in large groups of keywords that are close together. One link per reference every now and then is suitable and preferred.

##### Tables

Please make large tables collapsible ( class="mw-collapsible h4" ) and add a caption ( |+ Caption ) to the top of the table before the list of column headers even if the table begins directly below a section header. This allows the collapse/expand functionality to be moved into the table header itself rather than on the section header.

When using the source editor table code should have a single blank space after any markup

##### Sections and Tables

Where possible please add a section header above any table that is not small, this permits users to jump to the table from the Table of Contents. If using the source editor it is preferred that section headings have a single blank space either side between the markup and title to aid readability.

#### Links for Formatting and Markup

Some helpful links for learning Wikitext (there is likely to be duplicate information across them), tags and formatting are:

Wikipedia Wikitext Guide

Mediawiki Wikitext Formatting Guide

Wikipedia Wikitext Cheat Sheet

There may be many things not covered in those links, but you're likely to be able to find out how to do it by having a search around on the internet.

#### Line Breaks

If you're not using the source editor, some of these issues may be introduced unintentionally by the Visual Editor system. You won't be blamed for it, and it will eventually get cleaned up later.

If you **are** using the source editor, single line breaks should occur using the <br> tag only. The tag is already void (self closing, standalone) and while it does not require the self closing / ( <br /> ) it can still be left in. This isn't HTML 5 compliant, but the site does make use of XML where it's fine. If it becomes an issue we can revisit this.

Extra empty lines are suitable if there should be a blank line, do not use additional <br> elements for the extra spacing. If your text can (or should) be displayed directly underneath the previous line please do not use an empty line as a break it ss a double-height break and interferes with the general flow of an article.

#### Style Tags

We have a lot of styling in the wiki as we're trying to keep it true to the in-game style of writing and general display. If you find yourself adding a lot of styling (via `style="tag: parameter; tag: parameter; tag: parameter;"`) it likely should be converted to a CSS class for site-wide use and to cut down on article code. (There may be a lot of this already used in articles early on, but it will eventually be converted to CSS classes later.)

There will eventually be a document containing a list of existing CSS classes for styling, what circumstances they should be used in. If you're already familiar with CSS and want to know beforehand, take a look at the Mediawiki:Common.css file.

#### Element Tags

This section specifically refers to the source editor and wiki markup, CSS and HTML, if these don't apply to you feel free to ignore this.

As stated above regarding line breaks, some elements can be written as self-closing (but preferably shouldn't be outside of XML in a Portable Infobox).

An example of an element that normally would have a begin tag, an end tag, and content in between but doesn't would be our FontAwesome icons where the element itself displays the image:

<span class="fab fa-steam-square></span>

This requires no content inside the span elements to accomplish the task, some users may be familiar with turning this into a self-closing tag:

<span class="fab fa-steam-square />

Unfortunately this syntax is not HTML 5 compliant and no longer used outside of XML (which on Fandom, is (to my knowledge) largely only used within a Portable Infobox template.

The wiki article markup will allow it and properly parse it, but the article will get marked as having invalid tags and flagged for correction.