Open main menu

UESPWiki β

UESPWiki:Style Guide

< UESPWiki: Policies and Guidelines

UESPWiki's Style Guide is designed to maintain consistency throughout the site. Since editors from all over the world make modifications and additions to UESPWiki'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.

Layouts for Specific Types of Pages

Content

The purpose of the UESPWiki is to provide encyclopedia-style content describing the Elder Scrolls games. 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

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

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 games. For example, a creature's health is not a variable that is seen while playing the games, but it is useful to document the health in order to understand how much damage (how many weapon hits, or how many spellcasts) 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 the construction set (CS). The in-game console is in general the most authoritative source for information about gameplay statistics. On the other hand, the construction set provides 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, construction set data is used extensively in UESPWiki articles.

Some common sources of misunderstanding about this guideline include:

  • Random/leveled information: Because the Elder Scrolls games 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 UESPWiki article should only state that a specific creature will be found in a given location if every player of the games 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").
  • Construction set discrepancies (statistics): Although the construction set (CS) is the most common source for information on this site, the CS 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 CS, 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 permanent Fortify Health, or because of autocalculated values. In such cases, the in-game value should be documented rather than the CS value.
  • Construction set discrepancies (lore): CS data 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 the construction set (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 construction set data for Xbox, Xbox 360, and PS3 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 (e.g., the .esm game files). The console and construction set are merely tools allowing the gameplay data to be read.

Content over Style

The UESP 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 Feb. 14, 2007") 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 UESPWiki 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 versions of the Elder Scrolls games. 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. A more detailed discussion of this topic is available at Mod Info in Articles.

For some games, separate mod-related namespaces have not been created, so mod-related articles are acceptable in those namespaces. Others, like Arena and Daggerfall, didn't have mod-related namespaces initially, so articles may need to be updated or moved.

Language

UESPWiki 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 the Elder Scrolls games; 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 an Elder Scrolls game, 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 1234 or 1,234—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, This is an "example". is the preferred style, not This is an "example." The purpose of this guideline is primarily to resolve potential disputes between editors.
  • Titles should follow the general convention that a title such as "countess" or "queen" is to be capitalized when making reference to a definite person or their position, as well as when used as a means of directly addressing an individual. For example, "count" is first capitalized as it references the office—Count of Leyawiin—and later as it references the man—Count Marius Caro. Similarly, if speaking directly to him, one would capitalize it as in "Well-met, Count!" However, it would not be capitalized if not directly referring to an individual, as in "Did you hear about the count?"

Writing Style

UESPWiki 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 entered the arena I saw a minotaur". 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 enter the arena you will see a minotaur". 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 arena he will see a minotaur". This however either assumes the gender of the reader or requires the use of an awkward "he/she" or "they" construction. The sentence could be reworded to avoid this, for example: "When the player enters the arena, there will be a minotaur". 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 minotaurs in the arena."

On quest pages, you may use the future tense, e.g. "When you enter the arena you will encounter three minotaurs." 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 UESPWiki 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 the world of Nirn 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 Accurate and Verifiable for details).

However, the Lore namespace is an exception, where the perspective is different from all other UESP namespaces. Within Lore articles, it is more appropriate to write from the perspective of a person living within the Elder Scrolls universe. The articles are still expected to be encyclopedia-style, but designed as if they were reference materials for a citizen of Tamriel. 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

  • Italicize all game dialogue, surrounding the quotes in italics.
  • Italics should be used for the titles of books and lengthy works. This includes the titles of Elder Scrolls games, official add-ons, DLC and Creations, even when only the subtitle (e.g. Morrowind, Oblivion, Skyrim) is written. The name of the series, The Elder Scrolls, should be italicized as well (even when shortened to just Elder Scrolls). Initialisms, most notably ESO and TES, are not italicized.
  • For possessives with italics, use the {{'}} template to surround the possessive apostrophe; this adds a small space to avoid an ugly look. For example, ''[[Morrowind:Morrowind|Morrowind]]''{{'}}s becomes Morrowind's.
  • Never use italics or quotation marks on quest or ship names.
  • 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.

Lists

  • Generally, use bullets for unordered lists and numbers where order is important.

Links

  • Links should generally wrap similar text to the page being linked to. Avoid vague link text like "here" and "this page".
  • Only link up to the apostrophe in possessives. For example, a link to Delphine's article would look like that.
  • Use [[wikipedia: and other interwiki links instead of external links to Wikimedia-based sites.
  • Use https in all external links that support it.

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 UESPWiki 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.

See Also

Retrieved from "https://en.uesp.net/w/index.php?title=UESPWiki:Style_Guide&oldid=3158342"