Farming Simulator Wiki talk:Manual of Style

MOS Suggestion

Here is content from a MOS I built for another wiki years ago at w:c:warmetal:War Metal Wiki using relevant bits from Wikipedia, in case some of the content is of value for consideration here (I've replaced War Metal terminology with FS):

This is a style guide for all Farming Simulator Wiki articles.

This guide helps editors produce articles with consistent, clear, and precise language, layout, and formatting. The goal is to make Farming Simulator Wiki easier and more intuitive to use. Consistency in language, style, and formatting promotes clarity and cohesion; this is especially important within an article.

Basics

Writing should be clear and concise. Plain English works best: avoid ambiguity, jargon, vague wording, unnecessarily complex wording, slang or otherwise sloppy language.

Articles Versus Talk Pages

Wiki articles should not be treated the same as talk pages, blog or forum posts which are one person's point of view, but rather should be the result of a collaborative effort to provide information for the community that stems from the community.

Just The Facts

Avoid conjecture, opinions and assumptions (stick to the facts). Basically, avoid making statements or drawing conclusions based on your own experiences that can be argued or debated. This type of content belongs in talk pages, forum posts, or your user blog page.

Third Person

Write in the third person. Avoid personalizing articles by referring to yourself (i.e. "I used this strategy and it worked well for me").

Keep It Simple

The simplest markup is often the easiest to edit, the most comprehensible, and the most predictable. Markup may appear differently in different browsers. Use HTML and CSS markup sparingly; in particular, do not use the CSS float or line-height properties because they break rendering on some browsers when large fonts are used.

Article Titles, Headings And Sections

Article Titles

The principal criteria are that a title be recognizable (as a name or description of the topic), natural, sufficiently precise, concise, and consistent with the titles of related articles. If these criteria are in conflict, they need to be balanced against one other.

The following points are critical:

Capitalize the first letter of each word in the title, unless the title is represented differently in the game, in which case matching the game takes precedence.
Do not use A, An, or The as the first word, unless by convention it is an inseparable part of a name.
Titles should normally be noun or noun phrase: Early Life, not In Early Life.
The final visible character should not be a punctuation mark unless it is part of a name (Saint-Louis-du-Ha! Ha!) or an abbreviation (Inverness City F.C.), or a closing round bracket or quotation mark is required (John Palmer (schooner)).

This guide applies to all parts of an article, including the title. See especially punctuation, below.

Section Organization

Introductory Text

An article should begin with an introductory lead section, which does not contain section headings. The Wikia related articles feature will summarize the introduction text only if it appears before the first heading. The remainder is divided into sections, each with a section heading (see below) that can be nested in a hierarchy. If there are at least four section headings in the article, a navigable table of contents is generated automatically and displayed between the lead and the first heading.

Main Article

If the topic of a section is also covered in more detail in a dedicated article, show this by inserting {{main|Article name}} directly under the section heading.

Appendices And Footers

Optional appendix and footer sections containing the following lists may appear after the body of the article in the following order:

internal links to related English Wikipedia articles (section heading "See Also");
notes and references (section heading "Notes");
internal links organized into navigational boxes

Section Headings

Headings are produced by typing multiple equal signs. A primary section heading is written ==Title==, a subsection below it is written ===Title===, and so on (a maximum of five levels is possible). Spaces between the equal signs and the heading text are optional, and will not affect the way the heading is displayed. The heading must be typed on a separate line. Include one blank line above the heading for readability in the edit window. (Only two or more consecutive blank lines will add more white space in the public appearance of the page.)

Some provisions in Article titles (above) generally apply to section headings as well, but the following points apply specifically to section headings:

Headings should not refer redundantly to the subject of the article, or to higher-level headings, unless doing so is shorter or clearer.
Section and subsection headings should preferably be unique within a page; otherwise section links may lead to the wrong place, and automatic edit summaries can be ambiguous.
Headings should not contain images.

Before changing a section heading, consider whether you might be breaking existing links to that section. If there are many links to the old section title, create an anchor with that title to ensure that the links still work.

Abbreviations

Write out both the full version and the abbreviation at first occurrence: When an abbreviation is to be used in an article, give the expression in full at first, followed immediately by the abbreviation in parentheses (round brackets). In the rest of the article the abbreviation can then be used by itself.

Non-breaking spaces

A non-breaking space is recommended to prevent the end-of-line displacement of elements that could be awkward at the beginning of a new line. This can be produced with the HTML code  .

Punctuation

Slashes

Generally avoid joining two words by a slash, also known as a forward slash or solidus ( / ). It suggests that the two are related, but does not specify how. It is often also unclear how the construct would be read aloud. Replace with clearer wording.

An example: The parent/instructor must be present at all times. Must both be present? (Then write the parent and the instructor.) Must at least one be present? (Then write the parent or the instructor.) Are they the same person? (Use a hyphen: the parent-instructor.)

In circumstances involving a distinction or disjunction, the en dash is usually preferable to the slash: the digital–analog distinction.

An unspaced slash may be used:

to separate the numerator and denominator in a fraction ( 7/8 )
where a slash occurs in a phrase widely used outside Farming Simulator Wiki, and a different construction would be inaccurate, unfamiliar, or ambiguous

Do not use the backslash character ( \ ) in place of a slash.

Prefer the division operator ( ÷ ) to ( / ) when representing elementary arithmetic in general text: {{{1}}}.

And/Or

Avoid the construct and/or. In general, where it is important to mark an inclusive or, use x or y, or both, rather than x and/or y. For an exclusive or, use either x or y, and optionally add but not both, if it is necessary to stress the exclusivity.

Where more than two possibilities are presented, from which a combination is to be selected, it is even less desirable to use and/or. With two possibilities, at least the intention is clear; but with more than two it may not be. Instead of x, y, and/or z, use an appropriate alternative, such as one or more of x, y, and z; some or all of x, y, and z.

Sometimes or is ambiguous in another way: Wild dogs, or dingoes, inhabit this stretch of land. Are wild dogs and dingoes the same or different? For one case write: wild dogs (dingoes) inhabit ... (meaning dingoes are wild dogs); for the other case write: either wild dogs or dingoes inhabit ....

Number Signs

Avoid using the # symbol (known as the number sign, hash sign, or pound sign) when referring to numbers or rankings. Instead use the word "number", or the abbreviation "No." The abbreviation is identical in singular and plural.

Terminal Punctuation

Periods (also called "full stops"), question marks, and exclamation marks are terminal punctuation, the only punctuation marks used to end sentences in English.
In some contexts, no terminal punctuation is necessary. In such cases, the sentence often does not start with a capital letter. Sentence fragments in captions or lists should in most cases not end with a period. See Formatting of captions and Bulleted and numbered lists below.
Clusters of question marks, exclamation marks, or a combination of them (such as the interrobang), are highly informal and inappropriate in Farming Simulator Wiki articles.
Use the exclamation mark with restraint. It is an expression of surprise or emotion that is often unnecessary and inappropriate.

Spacing

In normal prose, never place a space before commas, semicolons, colons, or terminal punctuation, but place a space after them.

Spaces Following Terminal Punctuation

The number of spaces following the terminal punctuation of a sentence in the Wiki markup makes no difference on Farming Simulator Wiki because MediaWiki condenses any number of spaces to just one when rendering the page (see Sentence spacing).

Dates

For dates, use {{#formatdate:YYYY-MM-DD|mdy}}. This allows dates to be displayed in the format specified by the user in their Wikia preferences, and a default for those without set preferences, without an account or who are logged out. Dates
For example:
- {{#formatdate:2012-03-25|mdy}}
- → March 25, 2012 (your pref), March 25, 2012 (default)
Invalid date formats will not work and will show the passed date untouched. This is why it is important to standardize on passing a single (known good) date format: YYYY-MM-DD.
User account date preferences are set through Special:Preferences.

Current

Use of the term "current" should be avoided. What is current today may not be tomorrow; situations change over time. Instead, use date-specific or game version-specific text.

Incorrect:	Currently, this item does not appear in the game...
Correct:	As of February 14, 2012, this item does not appear in the game...
Correct:	As of Farming Simulator 15, this item does not appear in the game...

Currency

There are multiple symbols for currency available within Farming Simulator. For the sake of consistency, the dollar sign ($) is to be used within the Farming Simulator Wiki. It is to appear before the numerical value. To match the in-game display of currency, commas are to be used to separate thousands of dollars. Since no values less than one dollar are displayed within the game, none are to be displayed within the Wiki, including '.00' (i.e. $1.00). There is to be no space between the dollar sign and the value.

Numbers

In general, write whole numbers one through nine as words, write other numbers that take two words or fewer to say as either numerals or words, and write all other numbers as numerals: 1/5 or one fifth, 84 or eighty-four, 200 or two hundred, but 3.75, 544, 21 million).
In general, use a comma to delimit numbers with four or more digits to the left of the decimal point: 12,345 or 1,000.
In general, use decimals rather than vulgar fractions with measurements. Keep articles internally consistent.
Write out "million" rather than "M" and "thousand" rather than "K".
Write 3% or three percent but not three % or 3 % with a space. "Percent" is the preferred spelling. In ranges of percentages written with an en dash, write only one percent sign: 3–14%.

Common Mathematical Symbols

For a negative sign or subtraction operator, use a minus sign (−). You can input a minus sign by either keying in − or by clicking on it in the insert box available from the edit window toolbar. Do not use an en dash (–), do not use a hyphen (-) unless writing code, and do not use an em dash (—).
For a multiplication sign, use ×, which can be input by clicking on it in the insert box available from the edit window toolbar or by keying in × (however, the letter x is accepted as a substitute for by in such terms as 4x4).

Common mathematical symbols
Name	Operation	Other use	Symbol	CER	NCR	Unicode	As binary operator (e.g., 1 + 1)	As unary operator (e.g., +1)
Plus sign	Addition	Positive sign	+	+	+	U+002B	Spaced	Unspaced
Minus sign	Subtraction	Negative sign	−	−	−	U+2212	Spaced	Unspaced
Plus or minus	Addition or subtraction	Positive or negative sign	±	±	±	U+00B1	Spaced	Unspaced
Minus or plus	Subtraction or addition	Negative or positive sign	∓	—	∓	U+2213	Spaced	Unspaced
Multiplication sign, cross	Multiplication, vector product	—	×	×	×	U+00D7	Spaced	—
Division sign, obelus	Division	—	÷	÷	÷	U+00F7	Spaced	—
Equal sign	Equation	—	=	—	=	U+003D	Spaced	—
Not equal sign	Non-equation	—	≠	≠	≠	U+2260	Spaced	—
Approximate sign	Approximation	—	≈	≈	≈	U+2248	Spaced	—
Less than sign	Inequation	—	<	<	<	U+3C	Spaced	—
Less than or equal to	Inequation	—	≤	≤	≤	U+2264	Spaced	—
Greater than sign	Inequation	—	>	>	>	U+3E	Spaced	—
Greater than or equal to	Inequation	—	≥	≥	≥	U+2265	Spaced	—

Spelling

Farming Simulator Wiki uses US English spelling, as many game elements use this spelling. While writing using UK or Canadian English is commonplace, editors should understand that spelling in articles may be changed to US English for consistency.

When editing in source mode, some Web browsers will automatically check your spelling for you as you type.

Grammar

Official names

Official names of game elements should not be altered, either in spelling or case, even if they are misspelled or use different case than has been standardized here.

Pronouns

The possessive its (the dog chased its tail) has no apostrophe. (It's is the short form of it is or it has: it's a nice day, it's been a nice day.) Hers, ours, yours, theirs, and whose likewise lack apostrophes. Possessives of non-personal pronouns such as everyone are formed as if they were nouns (everyone's mother, nobody's hat, anyone else's opinion, the others' husbands).

First-Person Pronouns

Farming Simulator Wiki articles must not be based on one person's opinions or experiences, so never use I, my, or similar forms (except in quotations).

Also avoid we, us, and our wherever possible.

Second-Person Pronouns

Do not use the second person (you, your); it is often ambiguous and contrary to the tone of Farming Simulator Wiki (see also Instructional and presumptuous language, below).

Use the third person (a noun, or player, he, one, etc.): instead of When you complete the mission, you receive 1400 gold, use When players finish the mission, they receive 1400 gold, or A player completing the achievement receives 1400 gold.
The passive voice may sometimes be used instead: When the mission is completed, 1400 gold is received.

Vocabulary

Contractions

Uncontracted forms such as do not or it is are the default in formal style; don't and it's are too informal. But contractions should not be expanded mechanically. Sometimes rewriting the sentence as a whole is preferable; and occasionally contractions provide the best solution anyway.

Contested Vocabulary

Avoid words and phrases that give the impression of straining for formality, that are unnecessarily regional, or that are not widely accepted.

Instructional And Presumptuous Language

Avoid such phrases as remember that and note that, which address readers directly in a patronizing tone. Similarly, phrases such as of course, naturally, obviously, clearly, and actually make presumptions about readers' knowledge, and call into question the reason for including the information in the first place. Do not tell readers that something is ironic, surprising, unexpected, amusing, coincidental, etc. This supplies a point of view. Simply state the sourced facts and allow readers to draw their own conclusions.

Avoid Entering Textual Information As Images

Textual information should almost always be entered as text rather than as an image. Images are not searchable and are slower to download. Any important textual information in an image should also appear in the image's alt text, caption, or other nearby text.

Captions

Images should not have captions when they are unambiguous depictions of the subject of the article. For example, in a Tyrant Raid article no caption is necessary for an image of the raid.
If a caption is included, it must be preceded with the name of the contributor, linked to their user page. This is to prevent the misrepresentation that the contributor of the image (whose name is included by default in a captioned image) also created the caption.

Unordered And Ordered Lists

Do not use lists if a passage is read easily as plain paragraphs.
Do not leave blank lines between items in an unordered (bullets) or ordered (numbered) list unless there is a reason to do so, since this causes MediaWiki to interpret each item as beginning a new list.
Use numbers rather than bullets only if:
- a need to refer to the elements by number may arise;
- the sequence of the items is critical; or
- the numbering has some independent meaning, for example in reference to a listing of mission numbers.
Use the same grammatical form for all elements in a list, and do not mix sentences and sentence fragments as elements.
- When the elements are complete sentences, each one is formatted with sentence case and a final period.
- When the elements are sentence fragments, the list is typically introduced by a lead fragment ending with a colon. When these elements are titles, they retain the original capitalization of the titles. Other elements are formatted consistently in either sentence case or lower case. Each element should end with a semicolon, with a period instead for the last element. Alternatively (especially when the elements are short), no final punctuation is used at all.

Links

Make links only where they are relevant and helpful in the context: Excessive use of hyperlinks can be distracting, and may slow the reader down. Redundant links clutter the page and make future maintenance harder. High-value links that are worth pursuing should stand out clearly.

Linking to section's': A hash sign (#) followed by the appropriate heading will lead to a relevant part of a page. For example, [[Wikipedia:Apostrophe#Use in non-English names]] links to a particular section of the article Apostrophe.

Initial capitalization: Farming Simulator Wiki uses MediaWiki software, which does not require that WikiLinks begin with an upper-case character. Only capitalize the first letter where this is naturally called for, or when specifically referring to the linked article by its name: Snakes are often venomous, but lizards only rarely (see Poison).

Check links: Ensure that the destination is the intended one and not a redirect, disambiguation page or poorly-chosen article.

External links

Links which are neither internal to Farming Simulator Wiki or mw:Interwiki are considered external links. These should not be inline, but should be contained within <ref></ref> tags. At the end of the article, include a ==Notes== section and the <references/> tag.

Formatting

Modifications in font size, blank space, and color (see Color coding, below) are an issue for the Farming Simulator Wiki site-wide style sheet, and should be reserved for special cases only.

Fonts

Typically, the use of custom font styles will:

reduce consistency, since the text will no longer look uniform;
reduce usability, since it might be impossible for people with custom stylesheets (for accessibility reasons, for example) to override it, and it might clash with a different theme as well as inconvenience people with color blindness (see below); and
cause disputes, since other editors may disagree aesthetically with the choice of style.

Outside article text, different font sizes are routinely used in navigation templates and infoboxes, tables (especially in larger ones), and some other contexts where alternatives are not available (such as table captions). Specify font sizes relatively (for example in CSS with font-size: 80%) rather than absolutely (like font-size: 8pt).

Italics

Emphasis: Italics may be used sparingly to emphasize words in sentences (whereas boldface is normally not used for this purpose). Generally, the more highlighting in an article, the less its effectiveness.

Line Breaks

Line breaks in source mode are needed for:

Readability in source mode (separating templates, sections, etc.) It is important to recognize that a single line break in source mode has no effect on the display generated by MediaWiki, but it does increase readability for editors using source mode by breaking up source into smaller, more manageable logical blocks.
Table rows (for readability); each cell may require a line break to aid in tracking details.
Hard line breaks to control text with the <br> or <br />tag (either is acceptable, as MediaWiki converts the tag when generating the HTML source for the page).
If you need to use <br clear="all|left|right">, consider using one of {{clr}}, {{clrl}} or {{clrr}} instead to reduce hard-coding of HTML tags.

Color Coding

Avoid changing the color of text as it can cause problems with style sheets and the Wiki theme, especially when global style changes are made.
Do not use the same colors for text that are used for links. This is another reason to avoid changing the color of text, as if global style changes are made to link colors, conflicts with colored text can cause confusion.

ALL CAPS

It can be tempting to write one or more words in ALL CAPS for the sake of making the text stand out. Unfortunately, it is commonly understood as yelling on the Internet and is not appropriate within a well-written page for reasons which include the following:

Readers/Editors who tend to ignore what is written will often continue to ignore what is written even when it is written ALL IN CAPS.
Readers/Editors who pay attention to what is written do not need to be yelled at and should not be subjected to it; they will read and pay attention to well-written content.

Therefore, the only acceptable use of ALL CAPS is when copying game content which appears that way.

Scrolling Lists And Collapsible Content

Scrolling lists and boxes that toggle text display between hide and show should not conceal article body text content, including reference lists and image captions. These should be reserved for tables which contain mainly images and navigation boxes.

Invisible Comments

Editors use invisible comments to communicate with each other in the body of the text of an article. These comments are visible only in the Wiki source (that is, in edit mode), not in read mode.

Invisible comments are useful for flagging an issue or leaving instructions about part of the text, where this is more convenient than raising the matter on the talk page. They should be used judiciously, because they can clutter the Wiki source for other editors. Check that your invisible comment does not change the formatting, for example by introducing white space in read mode.

To leave an invisible comment, enclose the text you intend to be read only by editors between .

Signatures

Do not sign any content within Wiki articles (this is reserved for talk pages and forum posts). Credit for image captions and automatically included credit for images displayed as thumbnails are the exceptions.

Unicode

An HTML entity is sometimes better than the equivalent Unicode character, which may be difficult to identify in edit mode.

Navigation menu

Search