StarfieldWiki:Style Guide

Starfield Wiki's Style Guide is designed to maintain consistency throughout the site. Since editors from all over the world make modifications and additions to Starfield Wiki's articles, it is important for the project to have a uniform format and style. This article summarizes the style guidelines that are recommended for all articles on the site. Articles that follow these guidelines are more likely to be well-received by the rest of the community, and will require other editors to spend less time cleaning them up.

The style of talk pages is less formal than that used for articles. While most of these guidelines are still relevant to talk pages, there are several differences that are noted as appropriate below.

Content
The purpose of the Starfield Wiki is to provide encyclopedia-style content describing Starfield and future games in the series. All articles should be informative and targeted at the site's audience. Information that is only of interest to the writer or to other editors should not be included in articles. The article's talk page is the place to discuss questions about the article's content or style.

Accurate and Verifiable
Starfield Wiki's intention is to provide readers with reliable information about what they will experience while playing the game, and to provide background information about the events and characters in the game. To this end, the information in articles should provide as accurate a description of the game as possible. The information should also be objective, using facts that can be checked and independently confirmed by other players.

Leaks are not an acceptable source of information on Starfield Wiki. Information on the wiki must come from official or officially approved material, game files, or reputable news outlets.

In order to provide readers with the most accurate information about gameplay experience, it is frequently useful to provide statistics that are not directly visible as part of standard gameplay. These statistics are relevant because they control the events that occur while playing the game. For example, a creature's health is not a variable that is seen while playing the game, but it is useful to document the health in order to understand how much damage will be necessary to kill the creature. These statistics are generally extracted from the game's data files using tools such as the in-game console and/or tools released by Bethesda. The in-game console is in general the most authoritative source for information about gameplay statistics. On the other hand, tools such as the Creation Kit provide a more convenient way to access most of this information, and additionally permits viewing of scripts and other data that is not easily accessible from the console. Therefore, we expect to use data extracted from the game extensively to help write Starfield Wiki.

Some common sources of misunderstanding about this guideline include:
 * Random/leveled information: Because Starfield can contain randomized and/or leveled items and creatures, overly specific information (i.e., details of what a single player encountered) is often not accurate.  Therefore, information based solely upon individual player experience is often not appropriate in wiki articles.  In other words, a Starfield Wiki article should only state that a specific creature will be found in a given location if every player of the game will find that specific creature.  If the creature is randomly determined, it may only be possible to make a more general statement (for example, "an undead creature will be found," instead of "a skeleton guardian will be found").
 * Game data discrepancies (statistics): Although game data will be the most common source for information on this site, this information can at times differ with information taken from other sources.  In cases where statistics shown in-game (e.g., using the console) differ from the data extracted from game files, the in-game data is preferable: the purpose of the site is to describe gameplay.  For example: a non-player character's health in-game may differ from the CS value because of abilities that confer a permanent health bonus, or because of autocalculated values.  In such cases, the in-game value should be documented rather than the extracted value.
 * Game data discrepancies (lore): data extracted from game files can also disagree with information provided by books, dialogues, or other sources of lore.  In this case, preference is given to the hard statistics derived from game data files (and, if necessary, verified in-game using the console).  The preferred statistics are those that actually control gameplay; these statistics are also unambiguous, whereas lore can often provide contradictory information.  Notes can be used to provide details on any discrepancies with the lore.  For example, non-player characters have explicitly defined faction memberships that determine many aspects of the character behavior.  These memberships can be unambiguously determined using the in-game console or in the construction set; these sources are preferable to a dialogue in which it is mentioned that the character belongs to a given guild.
 * Relevance of game data for console gameplay: Although the in-game console and construction set are only available to PC players, the information extracted using these tools is equally applicable to gameplay on all platforms.  All platforms share the same fundamental gameplay data.  The console and game data file extraction are merely tools allowing the gameplay data to be read.

Content over Style
The Starfield Wiki makes use of templates and specific layout standards in order to organize and maintain the content of the wiki. If, however, the content of an article is limited by the style, the content should be given priority. If there is an article or a section of the site that compromises content in favor of style, it should be marked for cleanup so that a better balance of content and style can be achieved.

Attribution and Dates
Do not add any attributions (e.g., "written by Nephele") or dates (e.g., "written on Sep. 1st, 2023") when editing an article. The wiki software already maintains an accurate record of all contributions via the history page. Duplicating the information within an article will only clutter the article, adding extraneous editorial information that is not of interest to readers and degrading the article's quality. If you are adding information to a page that comes from another source (e.g., moved from another Starfield Wiki page or based on comments by another person), you can provide the source with proper credit by using the "Edit Summary" field on the edit page.

This rule does not apply to talk pages. On talk pages (discussion pages) you should use attribution to clarify the flow of discussion; simply typing ~ after your message will automatically insert your name and a timestamp.

Redundancy
New information added to the wiki should not repeat or be redundant with other information already on the site. Adding content to the wiki is only useful if the content is organized and presented in a way that makes it easy for all readers to find the information. This means that generally a topic will have a single page (or a section of a page) where the topic is discussed in full detail. Other pages that discuss that topic should not try to repeat the details, but should instead provide a link to the page with the details. Only information that is directly relevant to a given page should be included on the page.

There are several reasons why redundancy should be avoided. First, if a topic is discussed in detail on multiple different pages, then a reader has to read all of those pages to be sure that he has read all the information. Especially on a wiki, where different editors add information at different times, multiple versions of the same information cannot be efficiently maintained. Transclusions should be used instead of copying in cases where the same information needs to be shown on multiple pages. Second, adding extraneous details makes a page long and difficult to read. Only information of interest to almost all readers should be included: 90% of the readers should not have to wade through uninteresting information just so that 10% of readers can find the information.

Before adding a new note to a page, editors should double check whether:
 * The information is being added to the right page. Is this information directly relevant to the page? Is this where readers are likely to look for the information? If the answer to either of these questions is "no" then add a link to the appropriate page instead.
 * The information is being added in the right section of the page. The "Notes" section of a page is only for miscellaneous information that does not fit anywhere else, and should not be used if there is another section of the page that discusses the topic.
 * The information should be merged into another existing paragraph or note. It is generally better to add a few words to an existing sentence than to write a whole new note that mostly repeats existing information. Don't be afraid to revise what someone else has written; wiki editors are supposed to modify content written by other editors.

Unknown Information
It is acceptable to write an article even if you do not know all of the information necessary to complete the article. However, gaps in the article should not be filled in with approximations or best guesses. It is better to have no information than to have inaccurate information because inaccuracies mislead readers and are hard to find and correct. Uncertain information, or points that need more followup, should be moved to the discussion page where other editors can add their knowledge. In cases where an approximation in the article is the only choice, the approximation should be marked with an appropriate wiki tag, such as Huh or VN, to notify readers that the information is currently not known.

Unofficial Mods
The main game namespaces (other than those ending in "Mod") are devoted to the official version of Starfield. Therefore, the primary focus of all articles should be on the game as distributed by Bethesda, including any official patches, expansions, or plugins created by Bethesda. Third party mods are generally mentioned in game articles only when they are widely used to fix a described glitch or gripe.

Language
Starfield Wiki is written using American English, in particular following grammar and spelling standards appropriate for printed text. Colloquialisms, slang, l33t speak, and other informal or casual styles are not acceptable.

Words should be spelled using the American English spelling, except for terminology and proper nouns that originate from Starfield or Bethesda-published content; game-specific words should always use the in-game spelling. Similarly, capitalization follows standard English rules, except in cases where a proper name or title comes from Starfield, in which case the game capitalization is kept. More specifics on spelling and capitalization, and clarification on in-game spelling variations, are provided at spelling.

Other guidelines include:
 * Numbers should be written out as words if they are used as part of a sentence and can be written out in one or two words, such as nine hundred or twenty-one. For statistics and tables, however, it is proper for the numbers to always be in numerical form. When written in numerical form, numbers with four digits before the decimal point (if any) may or may not use a comma—as in  or  —but should be consistent within an article, making as few edits as possible in order to do so.
 * Quotation marks should use the logical quotation style for punctuation. Therefore, punctuation (e.g., periods, commas, colons) should be placed outside of the quotation marks, unless specified otherwise in the source material. In other words,  is the preferred style, not   The purpose of this guideline is primarily to resolve potential disputes between editors.

Writing Style
Starfield Wiki content should be written in a style appropriate for an encyclopedia. Descriptions should be clear, concise, and authoritative; speculations or uncertain facts should be avoided. Articles should be written for the wiki's readers and should attempt to tell the readers what to expect when they play the game. Instruct and explain to the readers and let the encyclopedia center around them.

No First Person
One of the most common mistakes made by well-intentioned editors is to provide information using a first-person point of view. First-person descriptions are typically used when an editor shares an example of something that happened to them in-game to further illustrate or clarify a point. An example of first-person narration is "When I boarded the ship I saw a pirate". This writing style implies that the events only happened a single time (when the editor was playing the game), and therefore does not provide the reader with a meaningful description of what the reader should expect when playing the game. Content submitted to an article in first-person will often be deleted and moved to the article's talk page until someone can verify the information and rewrite it.

Instead of first-person descriptions, wiki contributions should use second-person or third-person. An example of second-person is "When you board the ship you will see a pirate". This style talks directly to the reader. Although less formal than third-person, second-person descriptions can often be easier to write. This sentence in third-person would be "When the player enters the ship they will see a pirate". But in general, second-person is preferable for articles describing in-game content.

Verb Tense
Generally speaking, most articles should be written in the present tense, e.g. "There are three pirates in the ship."

On quest pages, you may use the future tense, e.g. "When you enter the ship you will encounter three pirates." Future tense may also be used to describe unreleased content, but this should be changed to present tense when said content is released.

Past tense should only be used for historical or lore-related articles or for articles or sections describing deprecated content. Examples of this include notes about locations or characters which appeared in previous games, or for content which was removed from the game for any reason.

Perspective
Most sections of Starfield Wiki are intended to be game guides and therefore should be written from the perspective of a person playing the game. Although articles about people and places loosely describe them as if they were part of a "real world", the primary focus is on helping readers with the game. Therefore, descriptions of the game interface and other aspects of gameplay external to universe of Starfield are appropriate in game articles. In cases where the gameplay facts differ from the lore of the universe, gameplay facts are generally given preference (see for details).

However, the Lore namespace is an exception, where the perspective is different from all other Starfield namespaces. Within Lore articles, it is more appropriate to write from the perspective of a person living within the Starfield universe. The articles are still expected to be encyclopedia-style, but designed as if they were reference materials for an inhabitant of the Settled Systems. Gameplay details should be avoided in Lore articles; game events should be described as historical events from the perspective of an anonymous citizen.

Format
Wiki formatting is used to improve the legibility of an article. Bulleted lists, numeric lists, bolding, italics, and coloring are all tools to help text "pop out" at the reader. When properly used, these tools help the reader to quickly scan a page for the key points, then focus on individual paragraphs of interest. For general guidelines on how to make articles legible, see "How Users Read on the Web" by Jakob Nielsen.

General information on how to implement wiki formatting is provided at Formatting (or an overview at Quick Editing Guide).

Bold

 * Bolding should be used for headings, subheadings, and article names. This is done automatically when using the wiki heading format (e.g., ==heading==).
 * Bold the article name the first time it appears in the page's introductory sentence. Any alternative names in the introductory sentence should also be bolded. (e.g. "Vivec, also known as Vehk, is best known for being one of the three gods in the Tribunal.")
 * Bold the word or phrase being defined in bulleted or numeric lists. (See Criteria for Speedy Deletion for an example.)
 * Do not use a semicolon simply to bold a whole line—this usage renders invalid HTML5. Semicolons can be used as list headers, where list entries are defined underneath using colons.
 * Keywords for which readers are likely to be scanning may be in bold for emphasis, but this should be used sparingly.
 * Avoid using bold formatting for general emphasis.

Italics

 * Italics should be used for the titles of books and lengthy works. This includes the titles of Starfield games and expansion packs. "Starfield" should also be italicized when it refers to the series as a whole. Initialisms are not italicized.
 * Italics can be used for general emphasis, but should be used sparingly (see next section).

Emphasis

 * Never use ALL CAPS for emphasis. It is not encyclopedic or good etiquette.
 * Avoid using either single or double quotation marks for emphasis. (See Quotation marks.)
 * Avoid bolding words for general emphasis, unless giving crucial notice. (e.g. Do not install mods from disreputable sources.)
 * Avoid using double emphasis, such as combining bold and italics (e.g. an example of double emphasis).
 * Do not overemphasize, as each emphasis added will lessen the effect of other emphases and detract from the appearance of the article.
 * While emphasis is to be avoided as much as possible, italics are the preferred method on the wiki.

Headers

 * Headers ( == Header == ) should be used to separate major sections on the page or subsections within a section. Use matched sets of anywhere between two to six equals signs on both sides of the words to use as a header. The equals signs must be at the beginning and end of the line; no other text can be placed on the same line. See Help:Formatting for more guidance.
 * Although wiki syntax supports level one headers ( = Level One = ), they should not be used on a page. The title of the page is a level one header, so everything under it should be level two or higher.
 * As a rule, headers should be nested progressively. In other words, a level two header should have level three headers immediately under it and level four headers under those.

Avoid Cluttering Links
Cross links between wiki pages are important navigational tools, allowing the reader to easily follow up on interesting points and find more detailed information. However, it is possible to fill a page with too many links. More details on how to create links and guidelines on their usage are provided on the Links help page.

Links to other articles should only be created when they are relevant to the content, and will be helpful and informative to the reader. Creating too many links can distract the reader and make the article hard to read; some readers are likely to pause on each link to determine whether the link is of interest. Be sure that any link you add will help readers and be used by readers. You should avoid creating duplicate links in an article. A link can be repeated if it last appeared in a previous section (since many readers will not read all sections of a page), but there is hardly ever a reason to link to the same article more than once in the same section.

Another thing to take into consideration is how relevant a link is to the context. It makes little sense to link to an article about Orcs whenever you mention Orcish Armor. If anything, you'd want to link to a page describing the armor, not Orcs in general. Even then, such a link might be unnecessarily distracting.

Bread Crumb Trails
A bread crumb trail is a navigational tool to help readers quickly link to any parent pages. For example, this page's bread crumb trail (at the top left of the page) allows readers to link to Starfield Wiki and Policies and Guidelines. All pages should have a bread crumb trail, which can usually be added by inserting the appropriate template at the top of the page. For example, this page inserts the Template:Policy Trail (using the tag Policy Trail). A list of the existing bread crumb templates is available in the bread crumb trail category. Bread crumb trail templates usually simultaneously insert the page into the appropriate categories.