User:Bbbbbbbbba/Proposal of manual of style

From Glitch City Wiki
Revision as of 13:18, 21 December 2020 by glitchcitywiki>Bbbbbbbbba (Created WIP page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page describes the preferred conventions of writing at Glitch City Wiki.

These rules are not considered mandatory constraints for new content, so if you want to add something to the wiki and do not have time to read this page through, do not let the worry that you may break a rule here stop you from contributing. On the other hand, if you want to write in a style that does not look like some other page on this wiki, but is consistent with this style guide, then you can rest assured that the other page is wrong.

In fact, these rules are better thought of as guidelines on when it is acceptable to make style changes on existing pages. In general, you should not make style changes on existing pages without good reasons, but the existing page not conforming to these rules is a good reason. Consistency may also be a good reason, but if you are adding new content to a page, try to make your content consistent with the existing style, not vice versa.

Golden rule: accessibility

The ultimate goal of any manual of style is to improve the accessibility of the text, i.e., to make it easier to read and understand, and also make it easier to use otherwise (like when searching). In general, when all text on a website follow the same style, people will know what to expect, and their cognitive load would be reduced.

However, there may be special cases where following the usual style would impede readability even more. If you are sure that you have encountered one of those cases, feel free to deviate from these rules. (In some cases you may want to add an invisible comment to show other editors your thoughts.) Conversely, when making style changes to conform to these rules, please also put in some thought to make sure that you are not sacrificing readability.

Also, in many cases, different people would find the most accessible way to present something to be different. For example, a person who grew up in the US may find it jarring to use single quotes as outer quotation marks, but another person who grew up in the UK may find it equally jarring to use double quotes as outer quotation marks. As another example, casual players may find technical phrases obtuse and difficult to parse, but technically-minded glitch researchers may find them clearer and more concise than everyday speech. Therefore, this document reflects our attempt to balance between different reader demographics, which is of course not perfect. If you believe one of the rules in this document could use some improvement, please discuss with us through the GCRI Discord or on Glitch City Wiki talk:Manual of style.

General rules

Since Glitch City Wiki is a small wiki, we prefer not to make our rules up from scratch, but to follow the examples of other successful wikis. Therefore:

The rest of this page will mostly be rules specifically on writing about glitches, including their procedures, results, and explanations. However, there may also be cases where we explicitly override guidelines from one of the above documents, and obviously this page takes precedence. Conversely, we may also repeat some of those guidelines in this page if we believe they are especially relevant to this wiki and more important to follow.

Introduction

See: Wikipedia:Manual of Style/Lead section

The introduction should serve to give an overview of the subject of the article. Generally, it should begin by briefly defining the term or glitch being discussed, which is named in boldface. Any alternative names of the subject, or related terms defined in the same article, should also be named in boldface. For related terms defined in a different article, obviously a link should be used.

  • Example:
    • The trainer escape glitch is a glitch in Pokémon Red, Blue, and Yellow that allows the player to leave a map after being seen by a trainer, but before the trainer battle starts. By performing certain actions and then returning to that map, the player can trigger a battle, which notably can be against any valid Pokémon in the game, as well as most glitch Pokémon. In its most common variant, it is also known as Trainer-Fly. It also used to be known as the Mew glitch, because historically it was the first known method to obtain Mew within those games.
  • Avoid spending a sentence stating that "[Subject of the article] is a glitch (in certain versions of the game)." The extension of the term "glitch" is so broad that this is not an interesting statement. Instead, try to define the glitch and show its significance, usually either by summarizing what it does, or by noting its most remarkable consequences.
  • Conversely, also avoid diving immediately into technical details in the first sentence. If what a glitch does exactly is too hard to summarize, then consider the "noting its most remarkable consequences" approach.

Third person point of view

Similar to on Wikipedia, first-person and second-person pronouns should generally be avoided.

  • The author's we is acceptable and is the most common exception to the above rule.
  • Meanwhile, the editorial we is generally not acceptable, especially since it usually reflect a violation of the neutral point of view policy (but see below about policy documents).
  • When referring to the person who is assumed to be performing a glitch (or some other procedure), use "the player" instead of "you". To refer to the player again, use the singular they, or just spell out "the player" again (when the singular they may be awkward). Alternatively, rephrase the sentence to eliminate the need to explicitly refer to the player, which is often possible, such as in the following example.
    • Incorrect: You must use a Pokémon with a Special of 21 to get a Mew.
    • Correct: Using a Pokémon with a Special stat of 21 results in a Mew.
  • Complicated procedures are often described as a numbered list or bulleted list (usually the former, unless the procedure is very long, such as a speedrun route) of steps, and for each step an imperative sentence should be used. This creates a mild implicit reference to "you", but is considered preferable to the verbosity of stating "The player should ..." for each step. However, explicit references to the player should still be worded as "the player".
    • Example:
    1. Walk a step up.
    2. Immediately after the step has finished, press Start. The player can "buffer" this button press by pressing and holding Start while still in the middle of the step.
  • In policy documents, such as this page, this rule does not apply, meaning that you can use the editorial we to refer to the Glitch City Wiki community as a whole, and "you" (instead of "the editor") to refer to the reader that is assumed to be editing a page. This is to avoid distancing the readers and to remind them that every new user of this wiki is also a potential editor.

Quotations

See: Wikipedia:Manual of Style#Quotations

Use double quotes as the outermost quotation marks, which is the dominant usage pattern in American English, but also has some acceptance in British English. However, when it comes to the order of punctuation around quotation marks, follow the so-called "British practice", which is also known as "logical quotation". This means that do not put punctuation marks inside quotation marks unless they actually belong there:

  • Incorrect: During the old man's catching demonstration, the player's name is temporarily changed to "OLD MAN."
  • Correct: During the old man's catching demonstration, the player's name is temporarily changed to "OLD MAN".
  • Correct: When the player saves the game in Pokémon Gold, Silver and Crystal, the game prints "SAVING… DON'T TURN OFF THE POWER."

Regardless of logicalness, avoid using two end marks (?, !, or .) both inside and outside the quotation marks:

Ambiguities may arise if the quoted text ends with an end mark, but not to end a sentence. Such ambiguities can be avoided by adding a parenthesized remark:

  • Problematic: Name the player character "♀:<MN>a.".
    • Even if we use end marks both inside and outside the quotation marks, it can look like a typo.
  • Better: Name the player character "♀:<MN>a." (ending with a period).

Links

Technical language

Terminology and Nomenclature