Fr/FlightGear wiki:Manual of Style: Difference between revisions

: As already noted [[#Quotations|above]], we use quotation marks or block quotes (not both) to distinguish long quotations from other text. Multiparagraph quotations are always block-quoted. The quotations must be precise and exactly as in the source (except for certain ''allowable typographical changes'', also noted [[#Typographic conformity|above]]). The source should be cited clearly and precisely.

These rules apply to both round brackets {{xt|( )}}, often called parentheses, and square brackets {{xt|[ ]}}.

Square brackets are used to indicate editorial replacements and insertions within quotations, though this should never alter the intended meaning. They serve three main purposes.

* If any sentence includes material that is enclosed in square or round brackets, it still must end—with a period, or a question or exclamation mark—''after'' those brackets. This principle applies no matter what punctuation is used within the brackets.

* However, if the entire sentence is within brackets, the closing punctuation falls within the brackets. (This sentence is an example.) This does not apply to matter that is added (or modified editorially) at the beginning of a sentence for clarity, which is usually in square brackets.

An ellipsis (plural ''ellipses'') is used to indicate an omission of material from quoted text or some other omission, perhaps of the end of a sentence, often in a printed record of conversation. The ellipsis is represented by '''ellipsis points''': a set of three unspaced periods, surrounded by square brackets {{xt|[...]}}.

Time of day is normally expressed in figures rather than being spelled out. Context determines whether the 12- or 24-hour clock is used.

* 12-hour clock times are written in the form {{xt|11:15 a.m.}} and {{xt|2:30 p.m.}}, or the form {{xt|11:15 am}} and {{xt|2:30 pm}}, with a space before the abbreviation.

* 24-hour clock times are written in the form {{xt|08:15}}, {{xt|22:55}}, with no suffix. Note that {{xt|00:00}} refers to midnight at the start of a date, and {{xt|24:00}} to midnight at the end of a date.

* For full dates, use the format {{xt|10 June 1921}} or the format {{xt|June 10, 1921}}. Similarly, where the year is omitted, use {{xt|10 June}} or {{xt|June 10}}. For choice of format, see below.

* Do not use numerical date formats such as {{!xt|03/04/2005}}, as this could refer to 3 April or to March 4. If a numerical format is required (e.g. for conciseness in long lists and tables), use the YYYY-MM-DD format: {{xt|2005-04-03}}.

* All the dates in a given article should have the same format (day-month or month-day). These requirements do not apply to dates in quotations or titles.

* Otherwise, do not change an article from one form to another without good reason.

* For month and year, write {{xt|June 1921}}, with no comma.

* Abbreviations for months, such as {{xt|Feb}}, are used only where space is extremely limited. Such abbreviations should use three letters only, and should not be followed by a period (full stop) except at the end of a sentence.

* Do not use ''the year'' before the digits ({{xt|1995}}, not {{!xt|the year 1995}}), unless the meaning would otherwise be unclear.

* Decades are written in the format {{xt|the 1980s}}, with no apostrophe. Use the two-digit form ('80s) only with an established social or cultural meaning. Avoid forms such as {{!xt|the 1700s}} that could refer to 10 or 100 years.

* For quantities of bytes and bits, specify whether the binary or decimal meanings of K, M, G, etc. are intended.

=== First-person pronouns ===

Wiki articles must not be based on one person's opinions or experiences. The use of ''I'', ''my'', or similar forms is restricted to user pages and quotations. Also avoid ''we'', ''us'', and ''our'': {{!xt|We should note that some critics have argued against our proposal}} (personal rather than encyclopedic).

=== Contractions ===

Uncontracted forms such as {{xt|do not}} or {{xt|it is}} are the default in encyclopedic style; {{!xt|don't}} and {{!xt|it's}} are too informal.

Foreign words should be used sparingly.

Use italics for phrases in other languages and for isolated foreign words that are not current in English.

Loanwords and borrowed phrases that have common usage in English ({{xt|vice versa}}) do not require italics. A rule of thumb is not to italicize words that appear unitalicized in major English-language dictionaries.

Some topics are intrinsically technical, but editors should try to make them understandable to as many readers as possible. Minimize jargon, or at least explain it. For unavoidably technical articles a separate introductory article may be the best solution. Avoid excessive ''wikilinking'' (linking within the wiki) as a substitute for parenthetic explanations such as the one in this sentence. Do not introduce new and specialized words simply to teach them to the reader when more common alternatives will do. When the notions named by jargon are too complex to concisely explain in a few parenthetical words, write one level down. For example, consider adding a brief background section with {{tl|main}} tags pointing to the full treatment article(s) of the prerequisite notions; this approach is practical only when the prerequisite concepts are central to the exposition of the article's main topic, and when such prerequisites aren't too numerous.

Places should generally be referred to consistently by the same name as in the title of their article. Exceptions are made if there is a widely accepted historical English name appropriate to the given context. In cases where such a historical name is used, it should be followed by the modern name in round brackets (parentheses) on the first occurrence of the name in applicable sections of the article. This resembles linking; it should not be done to the detriment of style. On the other hand, it is probably better to provide such a variant too often than too rarely. If more than one historical name is applicable for a given context, the other names should be added after the modern English name, that is: "historical name (modern name, other historical names)".

* Avoid referring to images as being on the left or right. Image placement is different for viewers of the mobile version of the wiki and might change in the future. Instead, use captions to identify images.

Textual information should almost always be entered as text rather than as an image. True text can be colored and adjusted with CSS tags and templates, but text in images cannot be. 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.

Photographs and other graphics should always have captions, unless they are "self-captioning" images or when they are unambiguous depictions of the subject of the article.

* Captions normally start with a capital letter.

* Most captions are not complete sentences, but merely sentence fragments that should not end with a period. If any complete sentence occurs in a caption, all sentences and any sentence fragments in that caption should end with a period.

* Captions for technical charts and diagrams may be substantially longer than those for other images. Captions for technical images should fully describe all the elements of the image, and the image's significance.

* Do not use lists if a passage is read easily as plain paragraphs.

* Use proper wikimarkup- or template-based list code ''(see [[Help:Formatting#Lists and indentation]])''.

*** ''Other elements'', they are formatted consistently in either sentence case or lower case.

=== Wikilinks ===

'''Make [[Help:Formatting#Links|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.

:* [https://sourceforge.net/p/flightgear/codetickets/ Bug tracker]

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 <code>float</code> or <code>line-height</code> properties because they break rendering on some browsers when large fonts are used.

An HTML entity is sometimes better than the equivalent Unicode character, which may be difficult to identify in edit mode; for example, <code>&amp;Alpha;</code> is understood where <code>Α</code> (the upper-case form of Greek <code>α</code>) may not be.

Make use of [[:Category:Templates|existing templates]] whenever possible to ensure articles are styled in a uniform way. See [[Help:Templates|the Templates Help page]] for a quick introduction to templates.

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

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 <code>font-size: 80%</code>) rather than ''absolutely'' (like <code>font-size: 8pt</code>).

Information should be accessible to all. Do not use color ''alone'' to mark differences in text: they may be invisible to people with color blindness. Also, black-and-white printouts, older computer displays with fewer colors, and monochrome displays (older PDAs and cell phones) cannot show such distinctions.

In addition to vision accessibility problems, usage of only color to encode attributes in tables instead of a separate sortable column, disables the use of the powerful wiki sortability feature on that attribute for all readers. Even for readers with unimpaired color vision, excessive background shading of table entries impedes readability and recognition of wikilinks. Background color should be used only as a ''supplementary'' visual cue, and should be subtle (consider using lighter, less-dominant pastel hues) rather than a glaring spotlight.

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 source mode, not in read mode.

To leave an invisible comment, enclose the text you intend to be read only by editors between <code>&lt;!--</code> and <code>--&gt;</code>. For example: {{xt|<code><nowiki><!--If you change this section title, please also change the links to it on the pages ...--></nowiki></code>}}

This document contains a selection of relevant sections from {{wikipedia|Wikipedia:Manual of Style}}.

* [[FlightGear wiki:FlightGear screenshot categories]]

* {{tl|informative template}} – ''Template documentation guidelines.''

[[Category:Wiki style guides]]