Draft:Manual of Style

Sometimes the MoS provides more than one acceptable style or gives no specific guidance. The principle that "When either of two styles is acceptable it is inappropriate for a BattleIntelligence editor to change from one style to another unless there is some substantial reason for the change."

Edit-warring over style, or enforcing optional style in a robot-like fashion without prior consensus, is never acceptable.

Unjustified changes from one acceptable, consistently-applied style in an article to a different style may generally be reverted. Seek opportunities for commonality to avoid disputes over style.

If you believe an alternative style would be more appropriate for a particular article, seek consensus by discussing this at the article's talk page or – if it raises an issue of more general application or with the MoS itself – at BattleIntelligence talk:Manual of Style. If a discussion does not result in consensus for the change at the article, continue to use the already-established style there. If discussion fails to reach a consensus regarding which of two or more competing styles to use at all, then default to the style that was used in the first post-stub version of the article in which one of the applicable styles appeared. (This fall-back position does not give unchallengable primacy to that particular style during consensus discussion, nor give the editor who imposed that earliest style any more say in the discussion.)

For retention of an article's established national variety of English (and potential reasons to change it), see § National varieties of English.

Article titles, sections, and headings

MOS:AT

Article titles

A title should be a recognizable name or description of the topic, balancing the criteria of being natural, sufficiently precise, concise, and consistent with those of related articles.

For formatting guidance see the BattleIntelligence:Article titles § Article title format section, noting the following:

Capitalize the initial letter (except in rare cases, such as Template:FormattingError), but otherwise follow sentence case (Template:FormattingError), not title case (Template:FormattingError), except where title case would be expected were the title to occur in ordinary prose. See BattleIntelligence:Naming conventions (capitalization).
To italicize, add {{italic title}} near the top of the article. For mixed situations, use, e.g., {{DISPLAYTITLE:Interpretations of ''2001: A Space Odyssey''}}, instead. Use of italics should conform to BattleIntelligence:Manual of Style/Text formatting § Italic type.
Do not use articles (a, an, or the) as the first word (Template:FormattingError, not Template:FormattingError), unless it is an inseparable part of a name (Template:FormattingError) or title of a work (Template:FormattingError, Template:FormattingError).
Normally use nouns or noun phrases: Template:FormattingError, not Template:FormattingError.
The final character should not be punctuation unless it is an inseparable part of a name (Template:FormattingError, Template:FormattingError) or an abbreviation (Template:FormattingError), or when a closing round bracket or quotation mark is required (Template:FormattingError).
Whenever quotation marks or apostrophes appear, add a redirect for the same title using apostrophes.

Subject both to the above and to BattleIntelligence:Article titles, the rest of the MoS, particularly § Punctuation, applies also to the title.

See also BattleIntelligence:Manual of Style/Titles of works, for cases where an article about a published work has a title that coincides with the work's title.

Section organization

MOS:SO

An article's content should begin with an introductory lead section – a concise summary of the article – which is never divided into sections (see BattleIntelligence:Manual of Style/Lead section). The remainder of the article is typically divided into sections.

Infoboxes, images, and related content in the lead section must be right-aligned.

Certain standardized templates and wikicode that are not sections go at the very top of the article, before the content of the lead section, and in the following order:

A short description, with the {{Short description}} template
A disambiguation hatnote, most of the time with the {{Hatnote}} template
No-output templates that indicate the article's established date format and English-language variety, if any (e.g., {{Use dmy dates}}, {{Use Canadian English}})
Banner-type maintenance templates, Dispute and Cleanup templates for article-wide issues that have been flagged (otherwise used at the top of a specific section, after any sectional hatnote such as {{main}})
An infobox, which is optional (except in special cases like {{Taxobox}} and {{Chembox}}, or a variant thereof, at applicable articles); usually also includes the first image
An introductory image, when an infobox is not used, or an additional image is desired for the lead section (for unusually long leads, a second image can be placed midway through the lead text)

If an article has at least four section headings, a navigable table of contents appears automatically, just after the lead.

If the topic of a section is covered in more detail in a dedicated article (see BattleIntelligence:Summary style), insert {{main|Article name}} or {{further|Article name}} immediately under the section heading.

As explained in detail in BattleIntelligence:Manual of Style/Layout § Standard appendices and footers, several kinds of material (mostly optional) may appear after the main body of the article, in the following order:

Books or other works created by the subject of the article, under a section heading "Works", "Publications", "Discography", "Filmography", etc. as appropriate (avoid "Bibliography", confusable with reference citations)
Internal links to related English BattleIntelligence articles, with section heading "See also"
Notes and references, with a section heading "Notes" or "References" (usually the latter), or a separate section for each in this order ; avoid "Bibliography", confusable with the subject's works
Relevant books, articles, or other publications that have not been used as sources; use the section heading "Further reading"; be highly selective, as BattleIntelligence is not a bibliographic directory
Relevant and appropriate websites that have not been used as sources and do not appear in the earlier appendices, using the heading "External links", which may be made a subsection of "Further reading" (or such links can be integrated directly into the "Further reading" list instead); link templates for sister-project content also usually go at the top of this section when it is present (otherwise in the last section on the page)
The following final items never take section headings:
- Internal links organized into navigational boxes
- Stub templates, if needed
- Authority control metadata, if needed, using {{Authority control}} (distinguishes uses of the same name for two subjects, or multiple names for one subject)
- Categories, which should be the very last material in the article's source code

Stand-alone list articles have some additional layout considerations.

Section headings

Section headings should generally follow the guidance for article titles (above), and should be presented in sentence case (Template:FormattingError), not title case (Template:FormattingError).

MOS:BLANKLINE

The heading must be on its own line, with one blank line just before it; a blank line just after is optional and ignored (but do not use two blank lines, before or after, because that will add unwanted visible space).

For technical reasons, section headings should:

Be unique within a page, so that section links lead to the right place.

MOS:NOSECTIONLINKS

Not contain links, especially where only part of a heading is linked.
Not contain images or icons.
Not contain <math> markup.
Not contain citations or footnotes.
Not misuse description list markup (";") to create pseudo-headings.
Not contain template transclusions.

These technical restrictions are necessary to avoid technical complications and are not subject to override by local consensus.

As a matter of consistent style, section headings should:

Not redundantly refer back to the subject of the article, e.g., Template:FormattingError, not Template:FormattingError or Template:FormattingError.
Not refer to a higher-level heading, unless doing so is shorter or clearer.
Not be numbered or lettered as an outline.
Not be phrased as a question, e.g., Template:FormattingError, not Template:FormattingError.
Not use color or unusual fonts that might cause accessibility problems.
Not be wrapped in markup, which may break their display and cause other accessibility issues.

These are broadly accepted community preferences.

MOS:SECTIONCOMMENT

An invisible comment on the same line must be inside the == == markup:

Template:FormattingError
Template:FormattingError

It is more usual practice to put such comments below the heading.

MOS:SECTIONANCHOR

<section begin="heading links" />Before changing a heading, consider whether you might be breaking existing links to it.<section end="heading links" /> If there are many links to the old title, create an anchor with that title to ensure that these still work. Similarly, when linking to a section, leave an invisible comment at the heading of the target section, naming the linking articles, so that if the heading is later altered these can be fixed. For (a combined) example:

which will be saved in the article as:

The advantage of using {{subst:Anchor}}, or simply inserting the <span> tags directly, is that when edits are made to the section in the future, the anchor will not be included in page history entries as part of the section name. When {{Anchor}} is used directly, that undesirable behavior does occur. Note: if electing to insert the span directly, do not abbreviate it by using a self-closing tag, as in ==Implications<span id="Consequences" />==, since in HTML5 that XML-style syntax is valid only for certain tags, such as <br />. See BattleIntelligence:Manual of Style/Linking § Avoiding broken section links for further discussion.

Heading-like material

The above guidance about sentence case, redundancy, images, and questions also applies to headers of tables (and of table columns and rows). However, table headings can incorporate citations and may begin with, or be, numbers. Unlike page headings, table headers do not automatically generate link anchors. Aside from sentence case in glossaries, the heading advice also applies to the term entries in description lists. If using template-structured glossaries, terms will automatically have link anchors, but will not otherwise. Citations for description-list content go in the term or definition element, as needed.

National varieties of English

MOS:ENGVAR

National varieties of English (for example, American English or British English) differ in vocabulary (elevator vs. lift ), spelling (center vs. centre), and occasionally grammar (see § Plurals, below). Articles such as English plurals and Comparison of American and British English provide information about such differences. The English BattleIntelligence prefers no national variety over others.

An article's date formatting (Template:FormattingError vs. Template:FormattingError) is also related to national varieties of English – see MOS:DATEFORMAT and especially MOS:DATETIES and MOS:DATEVAR.

Consistency within articles

Within a given article the conventions of one particular variety of English should be followed consistently. Exceptions include:

Quotations, titles of works (books, films, etc.) should be as given in the source (but see § Typographic conformity, below);
Proper names use the subject's own spelling, e.g., Template:FormattingError; Template:FormattingError;
For articles about chemistry-related topics, the international standard spellings Template:FormattingError, Template:FormattingError, Template:FormattingError (and derivative terms) should be used, regardless of the national English variant employed in the article generally. See BattleIntelligence:Naming conventions (chemistry) § Element names.

Opportunities for commonality

MOS:COMMONALITY

For an international encyclopedia, using vocabulary common to all varieties of English is preferable.

Use universally accepted terms rather than those less widely distributed, especially in titles. For example, [[Glasses|Template:FormattingError]] is preferred to the national varieties Template:FormattingError (British English) and Template:FormattingError (American English); [[Ten million|Template:FormattingError]] is preferable to [[crore|Template:FormattingError]] (Indian English).
If a variant spelling appears in a title, make a redirect page to accommodate the others, as with artefact and artifact, so that all variants can be used in searches and linking.
Terms that differ between varieties of English, or that have divergent meanings, may be glossed to prevent confusion, for example, Template:FormattingError.
Use a commonly understood word or phrase in preference to one that has a different meaning because of national differences (rather than Template:FormattingError, use Template:FormattingError or Template:FormattingError, as appropriate), except in technical contexts where such substitution would be inappropriate (Template:FormattingError; Template:FormattingError).
When more than one variant spelling exists within a national variety of English, the most commonly used current variant should usually be preferred, except where the less common spelling has a specific usage in a specialized context, e.g., connexion in Methodist connexionalism.

For assistance with specific terms, see Comparison of American and British English § Vocabulary, and American and British English spelling differences; most dictionaries also indicate regional terms.

Strong national ties to a topic

MOS:TIES

An article on a topic that has strong ties to a particular English-speaking nation should use the (formal, not colloquial) English of that nation. For example:

For topics with strong ties to Commonwealth of Nations countries and other former British territories, use Commonwealth English orthography, largely indistinguishable from British English in encyclopedic writing (excepting Canada, which uses a different orthography).

Retaining the existing variety

MOS:RETAIN

When an English variety's consistent usage has been established in an article, maintain it in the absence of consensus to the contrary. With few exceptions (e.g., when a topic has strong national ties or the change reduces ambiguity), there is no valid reason for changing from one acceptable option to another.

When no English variety has been established and discussion does not resolve the issue, use the variety found in the first post-stub revision that introduced an identifiable variety. The established variety in a given article can be documented by placing the appropriate variety of English template on its talk page.

An article should not be edited or renamed simply to switch from one variety of English to another. {{subst:uw-engvar}} may be placed on an editor's talk page to explain this.

Capital letters

BattleIntelligence article titles and section headings use sentence case, not title case; see BattleIntelligence:Article titles and § Section headings. For capitalization of list items, see § Bulleted and numbered lists. Other points concerning capitalization are summarized below. Full information can be found at BattleIntelligence:Manual of Style/Capital letters. The central point is that BattleIntelligence does not capitalize something unless it is consistently capitalized in a substantial majority of independent, reliable sources.

Capitalization of The

Generally, do not capitalize the word the in mid-sentence: Template:FormattingError, not Template:FormattingError. Conventional exceptions include certain proper names (Template:FormattingError) and most titles of creative works (Template:FormattingError – but be aware that the may not be part of the title itself, e.g., Template:FormattingError).

There are special considerations for: band names · institution names · nicknames · titles of works · trademarks.

Titles of works

The English-language titles of compositions (books and other print works, songs and other audio works, films and other visual media works, paintings and other artworks, etc.) are given in title case, in which every word is given an initial capital except for certain less important words (as detailed at BattleIntelligence:Manual of Style/Capital letters § Composition titles). The first and last words in an English-language title are always capitalized.

Correct: Template:FormattingError
Correct: Template:FormattingError

Capitalization in foreign-language titles varies, even over time within the same language; generally, retain the style of the original for modern works, and follow the usage in current English-language reliable sources for historical works. When written in the Latin alphabet, many of these items should also be in italics, or enclosed in quotation marks.

Correct: Template:FormattingError
Correct: Template:FormattingError

Titles of people

In generic use, use lower case for words such as president, king, and emperor (Template:FormattingError; Template:FormattingError; Template:FormattingError).
Directly before the person's name, such words begin with a capital letter (Template:FormattingError, not Template:FormattingError). Standard or commonly used names of an office are treated as proper names (Template:FormattingError; Template:FormattingError; Template:FormattingError). Royal styles take capitals (Template:FormattingError; Template:FormattingError); exceptions may apply for particular offices.

Religions, deities, philosophies, doctrines

Religions, sects, and churches and their followers (in noun or adjective form) start with a capital letter. Generally, "the" is not capitalized before such names (Template:FormattingError, not Template:FormattingError).
Religious texts are capitalized, but often not italicized (Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError). Do not capitalize "the" when using it in this way. Some derived adjectives are capitalized by convention, and some are not (Template:FormattingError, but Template:FormattingError); if unsure, check a dictionary.
Honorifics for deities, including proper names and titles, start with a capital letter (Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError). Do not capitalize "the" in such cases or when referring to major religious figures or characters from mythology (Template:FormattingError, Template:FormattingError, Template:FormattingError). Common nouns for deities and religious figures are not capitalized (Template:FormattingError; Template:FormattingError; Template:FormattingError).
Pronouns for figures of veneration or worship are not capitalized, even if capitalized in a religion's scriptures (Template:FormattingError).
Broad categories of mythical or legendary beings start with lower-case letters (Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError), although in works of fantasy, such as the novels of J. R. R. Tolkien and some video games, initial capitals are sometimes used to indicate that the beings form a culture or race in a fictional universe. Capitalize the names or titles of individual creatures (Template:FormattingError, Template:FormattingError) and of groups whose name and membership are fixed (Template:FormattingError, Template:FormattingError). Generalized references are not capitalized (Template:FormattingError; Template:FormattingError; Template:FormattingError).
Spiritual or religious events are capitalized only when referring to specific incidents or periods (Template:FormattingError and Template:FormattingError; but Template:FormattingError and Template:FormattingError).
Philosophies, theories, movements, and doctrines use lower case unless the name derives from a proper name (Template:FormattingError) or has become a proper name (Template:FormattingError, a system of political thought; Template:FormattingError, a political party). Use lower case for doctrinal topics or canonical religious ideas (as opposed to specific events), even if they are capitalized by some religious adherents (Template:FormattingError, Template:FormattingError, Template:FormattingError).
Platonic or transcendent ideals are capitalized in the context of philosophical doctrine (Template:FormattingError, Template:FormattingError); used more broadly, they are in lower case (Template:FormattingError). Use capitals for personifications represented in art (Template:FormattingError).
Eponyms are capitalized ([[Edwardian era|Template:FormattingError]], [[De Morgan's laws|Template:FormattingError]], [[Alice in Wonderland syndrome|Template:FormattingError]], [[Plaster of Paris|Template:FormattingError]], [[Platonic idealism|Template:FormattingError]], [[Draconian constitution|Template:FormattingError]]), except in idiomatic uses disconnected from the original context and usually lower-cased in sources ([[Platonic relationship|Template:FormattingError]]; Template:FormattingError). An entire phrase in which an eponym is an adjective is not capitalized except when the phrase is itself a proper name (e.g., the title of a published work: [[The China Syndrome|Template:FormattingError]]).

Calendar items

Months, days of the week, and holidays start with a capital letter (Template:FormattingError, Template:FormattingError; Template:FormattingError refers only to the US Independence Day – otherwise Template:FormattingError or Template:FormattingError).
Seasons are in lower case (Template:FormattingError; Template:FormattingError; Template:FormattingError), except in personifications or in proper names for periods or events (Template:FormattingError; Template:FormattingError).

Animals, plants, and other organisms

MOS:LIFE

When using taxonomic ("scientific") names, capitalize and italicize the genus: Template:FormattingError, Template:FormattingError. (Supergenus and subgenus, when applicable, are treated the same way.) Italicize but do not capitalize taxonomic ranks at the level of species and below: Template:FormattingError, Template:FormattingError, Template:FormattingError; no exception is made for proper names forming part of scientific names. Higher taxa (order, family, etc.) are capitalized in Latin (Template:FormattingError, Template:FormattingError) but not in their English equivalents (Template:FormattingError, Template:FormattingError); they are not italicized in either form, except for viruses, where all names accepted by the ICTV are italicized (Template:FormattingError).

Cultivar and cultivar group names of plants are not italicized, and are capitalized (including the word Group in the name); cultivar names appear within single quotes (Template:FormattingError), while cultivar groups do not (Template:FormattingError).

English vernacular ("common") names are given in lower case in article prose ([[Plains zebra|Template:FormattingError]], [[Mountain maple|Template:FormattingError]], and [[Southwestern red-tailed hawk|Template:FormattingError]]) and in sentence case at the start of sentences and in other places where the first letter of the first word is capitalized. They are additionally capitalized where they contain proper names: [[Przewalski's horse|Template:FormattingError]], [[California condor|Template:FormattingError]], and [[Fair-maid-of-France|Template:FormattingError]]. This applies to species and subspecies, as in the previous examples, as well as to general names for groups or types of organism: [[Bird of prey|Template:FormattingError]], [[Oak|Template:FormattingError]], [[Great apes|Template:FormattingError]], [[Bryde's whales|Template:FormattingError]], [[Livestock guardian dog|Template:FormattingError]], [[Poodle|Template:FormattingError]], [[Van cat|Template:FormattingError]], [[Wolfdog|Template:FormattingError]]. When the common name coincides with a scientific taxon, do not capitalize or italicize, except where addressing the organism taxonomically: Template:FormattingError Non-English vernacular names, when relevant to include, are handled like any other foreign-language terms: italicized as such, and capitalized only if the rules of the native language require it. Non-English names that have become English-assimilated are treated as English ([[Ayahuasca|Template:FormattingError]], [[Okapi|Template:FormattingError]]).

Create redirects from alternative capitalization and spelling forms of article titles, and from alternative names, e.g., Adélie Penguin, Adelie penguin, Adelie Penguin and Pygoscelis adeliae should all redirect to Adélie penguin.

Celestial bodies

The words sun, earth, moon and solar system do not take capitals in general use (Template:FormattingError; Template:FormattingError). They are capitalized when the entity is personified (Template:FormattingError) or when used as the name of a specific body in a scientific or astronomical context (Template:FormattingError; but Template:FormattingError).

Names of planets, moons, asteroids, comets, stars, constellations, and galaxies are proper names, and therefore capitalized (Template:FormattingError). The first letter of every word in such a name is capitalized (Template:FormattingError and not Template:FormattingError; Template:FormattingError, not Template:FormattingError). Words such as comet and galaxy should be capitalized when they form part of a proper name, but not when they are used as a generic term (Template:FormattingError; Template:FormattingError).

Compass points

Do not capitalize directions such as north, or their related forms (Template:FormattingError), except where they are parts of proper names (Template:FormattingError, Template:FormattingError, Template:FormattingError).

Capitalize names of regions if they have attained proper-name status, including informal conventional names (Template:FormattingError; Template:FormattingError), and derived terms for people (e.g., a Southerner as someone from the Southern United States). Do not capitalize descriptive names for regions that have not attained the status of proper names, such as Template:FormattingError.

Composite directions may or may not be hyphenated, depending on the variety of English adopted in the article. Template:FormattingError and Template:FormattingError are more common in American English; but Template:FormattingError and Template:FormattingError in British English. In cases such as Template:FormattingError and Template:FormattingError, use an en dash; see § En dashes: other uses.

Proper names versus generic terms

Capitalize names of particular institutions (Template:FormattingError; Template:FormattingError) but not generic words for institutions (Template:FormattingError). Do not capitalize the at the start of an institution's name, regardless of the institution's preferred style. There are rare exceptions, when a leading The is represented by a T in the organization's acronym: Template:FormattingError.

Treat political or geographic units similarly: Template:FormattingError; Template:FormattingError. Do not mimic the style of local newspapers which refer to their municipality as the City or The City; an exception is the City of London, referred to as Template:FormattingError in a context that already makes the subject clear, as distinct from London and Greater London. When in doubt, use the full name for accessibility reasons; users of text-to-speech systems usually cannot hear a difference between city and City.

Ligatures

MOS:LIGATURE

Ligatures should be used in languages in which they are standard (hence Template:FormattingError is preferable to Template:FormattingError) but not in English (Template:FormattingError or Template:FormattingError, not Template:FormattingError), except in proper names (Template:FormattingError, not Template:FormattingError).

Abbreviations

Abbreviations are shortened forms of words or phrases. In strict analysis, they are distinct from contractions, which use an apostrophe (e.g., won't, see § Contractions), and initialisms. An initialism is formed from some or all of the initial letters of words in a phrase. Below, references to abbreviations should be taken to include acronyms, and the term acronym to apply also to initialisms.

Write first occurrences in full

When an abbreviation will be used in an article, first introduce it using the full expression:

Do not use capitals in the full version merely because capitals are used in the abbreviation: Template:FormattingError.

Except in special circumstances, common abbreviations (such as Template:FormattingError, Template:FormattingError, Template:FormattingError) need not be expanded even on first use.

Plural forms

Pluralize acronyms by adding -s or -es: Template:FormattingError. (Do not use apostrophes to form plurals: Template:FormattingError.)

Punctuation and spacing

An abbreviation may or may not be terminated with a full point (also called a period or full stop). A consistent style should be maintained within an article. North American usage is typically to end all abbreviations with a period/point (Template:FormattingError) but in common British and Australian usage, no period/point is used if the abbreviation (contraction) ends in the last letter of the unabbreviated form (Template:FormattingError) unless confusion could result. This is also common practice in scientific writing. Regardless of punctuation, words that are abbreviated to more than one letter are spaced (Template:FormattingError not Template:FormattingError or Template:FormattingError). There are some exceptions: Template:FormattingError (see above) for "Philosophiae Doctor"; Template:FormattingError for "Bachelor of Veterinary Medicine". In most situations, BattleIntelligence uses no such punctuation inside acronyms and initialisms: Template:FormattingError, not Template:FormattingError

US and U.S.

Template:FormattingError is a commonly used abbreviation for Template:FormattingError, although Template:FormattingError – with periods and without a space – remains common in North American publications, including in news journalism. Multiple American style guides, including The Chicago Manual of Style (since 2010), now deprecate "U.S." and recommend "US".

For commonality reasons, use Template:FormattingError by default when abbreviating, but retain Template:FormattingError in American or Canadian English articles in which it is already established, unless there is a good reason to change it. Because use of periods for abbreviations and acronyms should be consistent within any given article, use Template:FormattingError in an article with other country abbreviations, and especially avoid constructions like Template:FormattingError. In longer abbreviations that incorporate the country's initials (Template:FormattingError, Template:FormattingError), never use periods. When the United States is mentioned with one or more other countries in the same sentence, Template:FormattingError (or Template:FormattingError) may be too informal, especially at the first mention or as a noun instead of an adjective (Template:FormattingError, not Template:FormattingError). Do not use the spaced Template:FormattingError or the archaic Template:FormattingError, except when quoting. Do not use Template:FormattingError or Template:FormattingError except in a quotation, as part of a proper name (Template:FormattingError), or in certain technical and formal uses (e.g., the ISO 3166-1 alpha-3, FIFA, and IOC country codes).

Circa

To indicate approximately, the use of {{circa}}, showing as Template:FormattingError, is preferred over circa, c., ca., or approx.

Avoid unwarranted use

Avoid abbreviations when they might confuse the reader, interrupt the flow, or appear informal. For example:

Do not use Template:FormattingError for Template:FormattingError except in an infobox or table (in which case use {{abbr|approx.|approximately}} at first occurrence: Template:FormattingError).
Do not use the legalism Template:FormattingError for Template:FormattingError.

Do not invent

Avoid devising new abbreviations, especially acronyms. For example, Template:FormattingError is good as a translation of Template:FormattingError, but neither it nor the reduction Template:FormattingError is used by the organization or by independent sources; use the original name and its official abbreviation, Template:FormattingError.

If it is necessary to abbreviate in a tight space, such as a column header in a table, use widely recognized abbreviations. For example, for Template:FormattingError, use Template:FormattingError and Template:FormattingError, with a link if the term has not already been written out in the article: Template:FormattingError. Do not make up initialisms such as Template:FormattingError.

HTML tags and templates

Either <abbr> or {{abbr}} can be used for abbreviations and acronyms: <abbr title="World Health Organization">WHO</abbr> or {{abbr|WHO|World Health Organization}} will generate WHO; hovering over the rendered text causes a tooltip of the long form to pop up.

Ampersand

In normal text and headings, use and instead of the ampersand (&): Template:FormattingError, not Template:FormattingError. But retain an ampersand when it is a legitimate part of the style of a proper noun, the title of a work, or a trademark, such as in Up & Down or AT&T. Elsewhere, ampersands may be used with consistency and discretion where space is extremely limited (e.g., tables and infoboxes). Quotations may be cautiously modified, especially for consistency where different editions are quoted, as modern editions of old texts routinely replace ampersands with and (just as they replace other disused glyphs, ligatures, and abbreviations). Another frequent permissible but not required use is in short bibliographic references to works by multiple authors, e.g.: Template:FormattingError.

Italics

Template:/titles hatnote include

Emphasis

Italics are used for emphasis, rather than boldface or capitals. But overuse diminishes its effect; consider rewriting instead.

Use <em>...</em> or {{em|...}} for emphasis. This allows user style sheets to handle emphasis in a customized way, and helps reusers and translators.

Correct: Template:FormattingError
Correct: Template:FormattingError

Titles

MOS:NOITALIC

Use italics for the titles of works (such as books, films, television series, named exhibitions, computer games, music albums, and artworks). The titles of articles, chapters, songs, episodes, storylines, research papers and other short works instead take double quotation marks.

Italics are not used for major religious works (Template:FormattingError, Template:FormattingError, Template:FormattingError). Many of these titles should also be in title case.

Words as words

Use italics when mentioning a word or character (see Use–mention distinction) or a string of words up to one sentence (Template:FormattingError; Template:FormattingError). When a whole sentence is mentioned, double quotation marks may be used instead, with consistency (Template:FormattingError; or Template:FormattingError). Quotation marks may also be used for shorter material to avoid confusion, such as when italics are already heavily used in the page for another purpose (e.g., for many non-English words and phrases). Mentioning (to discuss grammar, wording, punctuation, etc.) is different from quoting (in which something is usually expressed on behalf of a quoted source). Quotation is done with quotation marks, never italics, nor both at once (see § Quotations for details).

A closely related use of italics is when introducing or distinguishing terms: Template:FormattingError

Scientific names

Use italics for the scientific names of plants, animals, and all other organisms except viruses at the genus level and below (italicize Template:FormattingError and Template:FormattingError, but not Template:FormattingError). The hybrid sign is not italicized (Template:FormattingError), nor is the "connecting term" required in three-part botanical names (Template:FormattingError).

Quotations in italics

MOS:ITALQUOTE

Do not use italics for quotations. Instead, use quotation marks for short quotations and block quoting for long ones.

Italics within quotations

Use italics within quotations to reproduce emphasis that exists in the source material. If it is not clear that the source already included italics (or some other styling) for emphasis, add the editorial note Template:FormattingError after the quotation.

If adding emphasis that was not in the original, add the editorial note Template:FormattingError after the quotation.

Template:FormattingError

Effect on nearby punctuation

MOS:ITALPUNCT

Italicize only the elements of the sentence affected by the emphasis. Do not italicize surrounding punctuation.

Incorrect: Template:FormattingError (The question mark applies to the whole sentence, not just to the emphasized that, so it should not be italicized.)
Correct: Template:FormattingError
Correct: Template:FormattingError (The commas, the period, and the word and are not italicized.)

Quotations

Brief quotations of copyrighted text may be used to illustrate a point, establish context, or attribute a point of view or idea. While quotations are an indispensable part of BattleIntelligence, try not to overuse them. Using too many quotes is incompatible with an encyclopedic writing style and may be copyright infringement, and so most of the content should be in the editor's own words. Consider paraphrasing quotations into plain and concise text when appropriate (while being aware that close paraphrasing can still violate copyright). It is incorrect to put quotations in italics unless the material would be italicized for some other reason.

Original wording

Quotations must be verifiably attributed, and the wording of the quoted text must be faithfully reproduced. This is referred to as the principle of minimal change. Where there is good reason to change the wording, bracket the changed text; for example, Template:FormattingError might be quoted as Template:FormattingError. If there is a significant error in the original, follow it with {{sic}} (producing Template:FormattingError ) to show that the error was not made by BattleIntelligence. However, insignificant spelling and typographic errors should simply be silently corrected (for example, correct Template:FormattingError to Template:FormattingError).

Use ellipses to indicate omissions from quoted text. Legitimate omissions include extraneous, irrelevant, or parenthetical words, and unintelligible speech (Template:FormattingError and Template:FormattingError), but do not omit text where doing so would remove important context or alter the meaning of the text. Vulgarities and obscenities should be shown exactly as they appear in the quoted source; BattleIntelligencens should never bowdlerize words (Template:FormattingError), but if the text being quoted itself does so, copy the text verbatim and use {{sic}} to indicate that the text is quoted as shown in the source.

In direct quotations, retain dialectal and archaic spellings, including capitalization (but not archaic glyphs and ligatures, as detailed below in § Typographic conformity).

Point of view

MOS:QUOTEPOV

Quotation should be used, with attribution, to present emotive opinions that cannot be expressed in BattleIntelligence's own voice, but never to present cultural norms as simply opinional:

Acceptable: Template:FormattingError
Unacceptable: Template:FormattingError

Concise opinions that are not overly emotive can often be reported with attribution instead of direct quotation. Use of quotation marks around simple descriptive terms can imply something doubtful regarding the material being quoted; sarcasm or weasel words such as supposedly or so-called, might be inferred.

Permissible: Template:FormattingError
Unnecessary and may imply doubt: Template:FormattingError
Should be quoted: Template:FormattingError

Typographic conformity

MOS:CONFORM

A quotation is not a facsimile and, in most cases, it is not a requirement that the original formatting be preserved. Formatting and other purely typographical elements of quoted text should be adapted to English BattleIntelligence's conventions without comment, provided that doing so will not change or obscure meaning or intent of the text. These are alterations which make no difference when the text is read aloud, for example:

Normalize dashes and hyphens: see § Dashes. Use the style chosen for the article: unspaced em dash or spaced en dash.
Convert apostrophes and quotation marks to BattleIntelligence's style:
- These should be straight, not curly or slanted. See § Quotation marks.
- When quoting a quotation that itself contains a quotation, alternate between using double and single quotes for each quotation. See § For a quotation within a quotation for details.
When quoting text from non-English languages, the outer punctuation should follow the Manual of Style for English quote marks. If there are nested quotations, follow the rules for correct punctuation in that language. If there are multiple styles for a language, the one used by the BattleIntelligence for that language is preferred unless the punctuation itself is under discussion.
Template:FormattingError
Remove spaces before punctuation such as periods and colons.
Generally preserve bold and italics , but most other styling should be altered. Template:FormattingError, Template:FormattingError within words, Template:FormattingError, Template:FormattingError, Template:FormattingError, etc. should generally be normalized to plain text. If it clearly indicates emphasis, use italic emphasis ({{em}}) or, in an already-italic passage, boldface (with {{strong}}). For titles of books, articles, poems, and so forth, use italics or quotation marks following the guidance for titles. Italics can also be added to mark up non-English terms, for an organism's scientific name, and to indicate a words-as-words usage.
Expand an abbreviation (not already used in the content before the quotation) as a square-bracketed change, or explain it using {{abbr}}.
Normalize archaic glyphs and ligatures in English that are unnecessary to the meaning. Examples include æ→ae, œ→oe, ſ→s, and þe→the.

See BattleIntelligence:Manual of Style/Titles § Typographic conformity for special considerations in normalizing the typography of titles of works.

However, national varieties should not be changed, as these may involve changes in vocabulary. For example, a quotation from a British source should retain British spelling, even in an article that otherwise uses American spelling. (See § Consistency within articles.) Numbers also usually should not be reformatted.

Direct quotation should not be used to preserve the formatting preferred by an external publisher (especially when the material would otherwise be unchanged), as this tends to have the effect of scare-quoting:

Acceptable: Template:FormattingError
Unacceptable: Template:FormattingError

Italics can be used to mark a particular usage as a term of art (a case of "words as words"), especially when it is unfamiliar or should not be reworded by a non-expert:

Permissible: Template:FormattingError

When quoting a complete sentence, it is usually recommended to keep the first word capitalized. However, if the quoted passage has been integrated into the surrounding sentence (for example, with an introduction such as "X said that"), the original capital letter may be lower-cased.

It is normally unnecessary to explicitly note changes in capitalization. However, for more precision, the altered letter may be put inside square brackets: "The" → "[t]he".

Template:FormattingError

Attribution

The reader must be able to determine the source of any quotation, at the very least via a footnote. The source must be named in article text if the quotation is an opinion (see BattleIntelligence:Neutral point of view § Attributing and specifying biased statements). When attributing a quotation, avoid characterizing it in a biased manner.

Quotations within quotations

See § For a quotation within a quotation.

Linking

Be conservative when linking within quotations; link only to targets that correspond to the meaning clearly intended by the quote's author. Where possible, link from text outside of the quotation instead – either before it or soon after. (If quoting hypertext, add an editorial note, Template:FormattingError or Template:FormattingError, as appropriate, to avoid ambiguity as to whether the link was made by the original author.)

Block quotations

Format a long quote (more than about forty words or a few hundred characters, or consisting of more than one paragraph, regardless of length) as a block quotation, indented on both sides. Block quotations should be enclosed in {{blockquote}}.

Do not enclose block quotations in quotation marks (and especially avoid large, decorative quotation marks; those provided by the {{cquote}} template have been disabled in mainspace). Block quotations using a colored background are also discouraged.

Use {{blockquote}} and so on only for actual quotations; indentation for other purposes is done differently.

It is conventional to precede a block quotation with an introductory sentence (or sentence fragment) and append the source citation to that line. Alternatively, the {{blockquote}} template provides parameters for attribution and citation which will appear below the quotation. (For use of dashes with attributions, see § Other uses (em dash only).) This below-quotation attribution style is intended for famous quotations and is unusual in articles because it may strike an inappropriate tone. A quotation with no cited source should be flagged with {{quote without source}}, or deleted.

Line breaks and indentation inside a {{blockquote}} or <blockquote> are generally ignored; use ‎<poem> or {{poem quote}} for poetry, lyrics, and similar material:

{{blockquote|<poem>
What this grim, ungainly, ghastly, gaunt, and ominous bird of yore
            Meant in croaking "Nevermore."
</poem>}}

This gives: Template:FormattingError

Or quote such material inline, with line breaks indicated by {{nbsp}}/, and paragraph or stanza breaks by {{nbsp}}//.

Pull quotes do not belong in BattleIntelligence articles. These are the news and magazine style of "pulling" material already in the article to reuse it in attention-grabbing decorative quotations. This unencyclopedic approach is a form of editorializing, produces out-of-context and undue emphasis, and may lead the reader to conclusions not supported in the material.

Foreign-language quotations

Quotations from foreign-language sources should appear with a translation into English, preferably a modern one. Quotations that are translations should be explicitly distinguished from those that are not. Indicate the original source of a translation (if it is available, and not first published within BattleIntelligence), and the original language (if that is not clear from the context).

If the original, untranslated text is available, provide a reference for it or include it, as appropriate.

When editors themselves translate foreign text into English, care must always be taken to include the original text, in italics (except for non-Latin-based writing systems, and best done with the {{lang}} template which both italicizes as appropriate and provides language metadata); and to use actual and (if at all possible) common English words in the translation. Unless you are certain of your competency to translate something, see BattleIntelligence:Translation for assistance.

Punctuation

MOS:PUNCT

Apostrophes

Use straight apostrophes (Template:FormattingError), not curly apostrophes (Template:FormattingError). Do not use accent marks or backticks (Template:FormattingError) as apostrophes.
Templates such as {{'}} and {{'s}} are helpful when an apostrophe (or single quote) appears at the beginning or end of text in italics or bold, because italics and bold are themselves indicated by sequences of single quotes. Example: Template:FormattingError (markup: ''Dynasty''{{'s}} first season).
Letters resembling apostrophes, such as the [[Template:Okinaokina]] (Template:FormattingError – markup: {{okina}}), saltillo (Template:FormattingError – markup: {{saltillo}}), Hebrew ayin (Template:FormattingError – markup: {{ayin}}) and Arabic hamza (Template:FormattingError – markup:{{hamza}}), should be represented by those templates or by their Unicode values.
Templates cannot be used in article titles; if necessary, use the corresponding Unicode character directly. Per BTW:TITLESPECIALCHARACTERS, also make a redirect from the ASCII form to aid searches. Forms without apostrophe-like characters are sometimes preferred by BTW:COMMONNAME (e.g. Hawaii but not [[KealiTemplate:Okinai Reichel]]).
For Wade–Giles romanizations of Mandarin Chinese, use {{wg-apos}}.
For languages with ejective consonants and the like, use {{hamza}}.
For the Cyrillic soft sign, when indicated at all, use {{softsign}} or {{hamza}}.
For usage of the possessive apostrophe, see § Possessives.
For further treatment of apostrophe usage (possessive, elision, formation of certain plurals, foreign-language issues) see the article Apostrophe.

Quotation marks

In the material below, the term quotation includes conventional uses of quotation marks such as for titles of songs, chapters, episodes, and so on. Quotation marks are also used in other contexts, such as in cultivar names.

Quotation characters

Use Template:FormattingError quotation marks, not Template:FormattingError ones. (For single-apostrophe quotes: Template:FormattingError, not Template:FormattingError.)
Do not use accent marks, backticks (Template:FormattingError), low-high (Template:FormattingError) or guillemet (Template:FormattingError) marks as quotation marks (except when such marks are internal to quoted non-English text – see MOS:CONFORM). The symbols Template:FormattingError and Template:FormattingError seen in edit window dropdowns are prime and double prime: these are used to designate units of angular measurement, and not as apostrophes or quote marks.
Quotation marks and apostrophes in imported material should be changed if necessary to comply with the above.

Double or single

Most quotations take double quotation marks (Template:FormattingError). Exceptions:

Plant cultivars take single quotation marks (Template:FormattingError; see BattleIntelligence:Naming conventions (flora)).
Glosses that translate or define unfamiliar terms take single quotes; simple glosses require no comma before the definition (Template:FormattingError). The {{Gloss}} template can be used for this; e.g. casa {{gloss|house}} yields: casa Template:Gloss.

For a quotation within a quotation

Use single quotes:

Template:FormattingError

For deeper nesting, alternate between single and double quotes:

Template:FormattingError

For quote marks in immediate succession, add a sliver of space by using {{" '}}, {{' "}}, or (as in the example just given) {{" ' "}}:

Template:FormattingError Markup: He announced, "The answer was 'Yes!{{' "}}
Template:FormattingError (simply jamming things together looks awful in most fonts)
Template:FormattingError (a regular space is too much)

Article openings

In the bolded text typically appearing at the opening of an article:

Any quotation marks that are part of the title should be in bold just like the rest of the title (from "A" Is for Alibi: Template:FormattingError).
Quotation marks not part of the article title should not be bolded (from the article Jabberwocky: Template:FormattingError; from Babe Ruth: Template:FormattingError).

Punctuation before quotations

Template:/titles hatnote include

MOS:QUOTEPUNCT

If a non-quoted but otherwise identical construction would work grammatically without a comma, using a comma before a quotation embedded within a sentence is optional:

Template:FormattingError (Cf. the non-quotation Template:FormattingError)
Template:FormattingError

The comma-free approach is often used with partial quotations:

Template:FormattingError

A comma is required when it would be present in the same construction if none of the material were a quotation:

Template:FormattingError

Do not insert a comma if it would confuse or alter the meaning:

Template:FormattingError (Accurate quote of a statement about some children – specifically those children "who are coming to terms ...")
Template:FormattingError (Changes the meaning to imply Jenner was expressing concern about all children, while separately observing that children, in general, "are coming to terms ...")

It is clearer to use a colon to introduce a quotation if it forms a complete sentence, and this should always be done for multi-sentence quotations:

No additional punctuation is necessary for an explicit words-as-words scenario:

Template:FormattingError

Names and titles

Quotation marks should be used for the following names and titles:

Articles and chapters (books and periodicals italicized)
Short stories (books and periodicals italicized)
Sections of musical pieces (pieces italicized)
Individual strips from comics and webcomics (comics italicized)
Poems (long or epic poems italicized)
Songs (albums, song cycles, operas, operettas, and oratorios italicized)
Individual episodes of television and radio series and serials (series title italicized)

Correct: Template:FormattingError

Do not use quotation marks or italics for:

Ancient writings
Concert tours
Locations
Myths and epics
Prayers

Many, but not all, of the above items should also be in title case.

Punctuation inside or outside

Lua error in mw.title.lua at line 230: too many expensive function calls.

Use the "logical quotation" style in all articles, regardless of the variety of English in which they are written. Include terminal punctuation within the quotation marks only if it was present in the original material, and otherwise place it after the closing quotation mark. For the most part, this means treating periods and commas in the same way as question marks: keep them inside the quotation marks if they apply only to the quoted material and outside if they apply to the whole sentence. Examples are given below.

Correct: Template:FormattingError (question mark applies to whole sentence)
Incorrect: Template:FormattingError (incorrect to apply the question mark to the quotation)
Correct: Template:FormattingError (question mark applies to quoted material only)

If the quotation is a single word or a sentence fragment, place the terminal punctuation outside the closing quotation mark. When quoting a full sentence, the end of which coincides with the end of the sentence containing it, place terminal punctuation inside the closing quotation mark.

If the quoted sentence is followed by a clause that should be preceded by a comma, omit the full stop (period). I.e., do not replace the stop/period with a comma inside the quotation. But other terminal punctuation, such as a question mark or exclamation mark, may be retained.

If the quoted sentence is followed by a clause identifying the speaker, use a comma outside the quotation mark instead of a full stop inside it, but retain any other terminal punctuation, such as a question mark.

Do not follow quoted words or fragments with commas inside the quotation marks, except where a longer quotation has been broken up and the comma is part of the full quotation.

Quotation marks and external links

External links to article titles should have the title in quotes inside the link. The CS1 and CS2 citation templates do this automatically, and untemplated references should do the same.

Correct: Template:FormattingError (Using {{cite news}})
Correct: Template:FormattingError (Untemplated)
Incorrect: Template:FormattingError (Untemplated)

Quotation marks and internal links

Internal links (wikilinks) accompanied by quotation marks should usually have the quotes outside the link. This applies to titles of works in quotation marks (songs, episodes, etc.)

Correct: Template:FormattingError (Using "[[ ]]".)
Incorrect: Template:FormattingError (Using [[" "]].)

However, quotation marks are needed inside wikilinks when the quotation mark is part of the link, or where the linked display text includes quotation marks indicating slang, nicknames, common names, or similar usage.

Brackets and parentheses

Lua error in mw.title.lua at line 230: too many expensive function calls. This section applies to both round brackets Template:FormattingError, often called parentheses, and square brackets Template:FormattingError.

If a sentence contains a bracketed phrase, place the sentence punctuation outside the brackets Template:FormattingError However, where one or more sentences are wholly inside brackets, place their punctuation inside the brackets. There should be no space next to the inner side of a bracket. An opening bracket should usually be preceded by a space. This may not be the case if it is preceded by an opening quotation mark, another opening bracket, or a portion of a word:

There should be a space after a closing bracket, except where a punctuation mark follows (though a spaced dash would still be spaced after a closing bracket) and in unusual cases similar to those listed for opening brackets.

Avoid adjacent sets of brackets. Either put the parenthetical phrases in one set separated by semicolons, or rewrite:

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:

To clarify: Template:FormattingError, where this was the intended meaning, but the type of school was unstated in the original sentence.
To reduce the size of a quotation: Template:FormattingError may be reduced to Template:FormattingError. When an ellipsis (Template:FormattingError) is used to indicate that material is removed from a direct quotation, it should not normally be bracketed.
To make the grammar work: Referring to someone's statement Template:FormattingError, one could properly write Template:FormattingError.

If a sentence includes subsidiary material enclosed in square or round brackets, it must still carry terminal punctuation after those brackets, regardless of any punctuation within the brackets.

However, if the entire sentence is within brackets, the closing punctuation falls within the brackets. Template:FormattingError

Brackets and linking

Square brackets inside of links must be escaped:

He said, "`Template:FormattingError` answered."	He said, "John [Doe] answered."
He said, "`Template:FormattingError` answered."	He said, "John [Doe] answered."
`Template:FormattingError`	On the first day [etc.]
`Template:FormattingError`	On the first day [etc.]

The ‎<nowiki> markup can also be used: <nowiki>[Doe]</nowiki> or <nowiki>[etc.]</nowiki>.

If a URL itself contains square brackets, the wiki-text should use the URL-encoded form https://example.com/foo.php?query=Template:FormattingErrorxxxTemplate:FormattingErroryyy, rather than ...query=Template:FormattingErrorxxxTemplate:FormattingErroryyy. This will avoid truncation of the link after xxx.

Ellipses

Use an ellipsis (plural ellipses) if material is omitted in the course of a quotation, unless square brackets are used to gloss the quotation (see § Brackets and parentheses, and the points below).

BattleIntelligence's style for an ellipsis is three unspaced dots (Template:FormattingError); do not use the precomposed ellipsis character (Template:FormattingError) or three dots separated by spaces (Template:FormattingError)
Generally, use a non-breaking space before an ellipsis, and a regular space after it: Template:FormattingError
- But where an ellipsis is immediately followed by any of . ? ! : ; , ) ] } or by a closing quotation mark (single or double), use a non-breaking space before the ellipsis, and no space after it:
  Template:FormattingError
  
  Template:FormattingError (Place terminal punctuation after an ellipsis only if it is textually important, as is often the case with exclamation marks and question marks but rarely with periods.)
- Or, if the ellipsis immediately follows a quotation mark, use no space before the ellipsis, and a non-breaking space after it:
  Template:FormattingError

Pause or suspension of speech: Three dots are occasionally used to represent a pause in or suspense of speech, in which case the punctuation is retained in its original form: Template:FormattingError. When it indicates an incomplete word, no space is used between the word fragment(s) and the ellipsis: Template:FormattingError
With square brackets: Square brackets may be placed around an ellipsis that indicates omitted text to distinguish it from an ellipsis that is part of the quoted text: Template:FormattingError. In this example, the first ellipsis is part of the quoted text and the second ellipsis (in square brackets) indicates omitted text.

Commas

A pair of commas can bracket an appositive, relative clause, or parenthetical phrase (as can brackets or dashes, though with greater interruption of the sentence). For example:

Correct: Template:FormattingError

Correct: Template:FormattingError (when Janet has multiple sons)

Correct: Template:FormattingError (when Janet has only one son)

Always use a pair of commas for this, unless another punctuation mark takes the place of the second comma:

Incorrect: Template:FormattingError

Correct: Template:FormattingError

Correct: Template:FormattingError
Don't let other punctuation distract you from the need for a comma, especially when the comma collides with a bracket or parenthesis:

Correct: Template:FormattingError

Incorrect: Template:FormattingError
Modern writing uses fewer commas; there are usually ways to simplify a sentence so that fewer are needed.

Clear: Template:FormattingError

Awkward: Template:FormattingError

MOS:GEOCOMMA

In geographical references that include multiple levels of subordinate divisions (e.g., city, state/province, country), a comma separates each element and follows the last element unless followed by terminal punctuation or a closing parenthesis. The last element is treated as parenthetical.

Correct: Template:FormattingError

Incorrect: Template:FormattingError

Also include commas when the geographical element is used as a disambiguator:

Correct: Template:FormattingError

Incorrect: Template:FormattingError

MOS:DATECOMMA

Dates in month–day–year format require a comma after the day, as well as after the year, unless followed by other punctuation. The last element is treated as parenthetical.

Correct: Template:FormattingError

Incorrect: Template:FormattingError

MOS:QUOTECOMMA

Place quotation marks by following § Punctuation inside or outside. This is called "logical quotation".

Correct: Template:FormattingError

Incorrect: Template:FormattingError
A comma may be included before a quotation embedded within a sentence .

Serial commas

Lua error in mw.title.lua at line 230: too many expensive function calls.

A serial comma (sometimes also called an Oxford comma or Harvard comma) is a comma used immediately before a conjunction (and, or, nor) in a list of three or more items.

Template:FormattingError – serial comma

Template:FormattingError – no serial comma

Editors may use either convention so long as each article is internally consistent. Serial commas are more helpful when article text is complex, such as a list with multi-word items (especially if one contains its own "and") or a series of probably unfamiliar terms.

However, there are cases in which either omitting or including the serial comma results in ambiguity:

Template:FormattingError – which may list either four or more people (the friends and the two people named) or two people (O'Connor and Marley, who are the friends).

Template:FormattingError – which may list either two people (O'Connor, who is the friend, and Marley) or three people (the first being the friend, the second O'Connor, and the third Marley).

In such cases of ambiguity, clarify one of four ways:

Add or remove the serial comma.
Use separate sentences, bullet lists, or some other structural change to clarify.
Recast the sentence ("friends" case):
- To list two people: Template:FormattingError
  - Clearer: Template:FormattingError
- To list several people:
  Template:FormattingError or
  
  Template:FormattingError.
  - But not: Template:FormattingError – introduces ambiguity about her.
Recast the sentence ("friend" case):
- To list two people: Template:FormattingError
  - Or be more specific when possible (the commas here set off non-restrictive appositives): Template:FormattingError
- To list three people: Template:FormattingError
  - Clarity with gender-specific terms such as mother can be tricky; Template:FormattingError is unclear because readers may not know Kim Thayil is male and wouldn't be the same person as the mother.
  - Clearer: Template:FormattingError or Template:FormattingError.

Colons

MOS:COLON

Lua error in mw.title.lua at line 230: too many expensive function calls.

A colon (Template:FormattingError) introduces something that demonstrates, explains, or modifies what has come before, or is a list of items that has just been introduced. The items in such a list may be separated by commas, or if they are more complex and perhaps themselves contain commas, the items should be separated by semicolons or arranged in a bulleted list.

A colon may also be used to introduce direct speech enclosed within quotation marks. (See § Quotation marks.)

In most cases, a colon works best with a complete grammatical sentence before it. When what follows the colon is also a complete sentence, start it with a capital letter, but otherwise do not capitalize after a colon except where doing so is needed for another reason, such as for a proper name. When a colon is being used as a separator in an article title, section heading, or list item, editors may choose whether to capitalize what follows, taking into consideration the existing practice and consistency with related articles.

Except in technical usage (Template:FormattingError), no sentence should contain multiple colons, no space should precede a colon, and a space (but never a hyphen or dash) should follow the colon.

Semicolons

Lua error in mw.title.lua at line 230: too many expensive function calls.

A semicolon (Template:FormattingError) is sometimes an alternative to a full stop (period), enabling related material to be kept in the same sentence; it marks a more decisive division in a sentence than a comma. If the semicolon separates clauses, normally each clause must be independent (meaning that it could stand on its own as a sentence). In many cases, only a comma or only a semicolon will be correct in a given sentence.

Correct:

Incorrect:

Above, "Though he had been here before" cannot stand on its own as a sentence, and therefore is not an independent clause.

Correct:

Incorrect:

This incorrect use of a comma between two independent clauses is known as a comma splice; however, in certain kinds of cases, a comma may be used where a semicolon would seem to be called for:

Accepted:

Template:FormattingError (two brief clauses in an aphorism; see Ars longa, vita brevis)

Accepted:

Template:FormattingError (reporting brisk conversation, such as this reply of Newton's)

A sentence may contain several semicolons, especially when the clauses are parallel in construction and meaning; multiple unrelated semicolons are often signs that the sentence should be divided into shorter sentences or otherwise refashioned.

Unwieldy:

One better way:

Semicolons are used in addition to commas to separate items in a listing, when commas alone would result in confusion.

Confusing:

Clear:

Semicolon before "however"

MOS:HOWEVER

The meaning of a sentence containing a trailing clause that starts with the word however depends on the punctuation preceding that word. A common error is to use the wrong punctuation, thereby changing the meaning to one not intended.

When the word however is an adverb meaning "nevertheless", it should be preceded by a semicolon and followed by a comma. Example:

Meaning:

When the word however is a conjunction meaning "in whatever manner", or "regardless of how", it may be preceded by a comma but not by a semicolon, and should not be followed by punctuation. Example:

Meaning:

In the first case, the clause that starts with "however" cannot be swapped with the first clause; in the second case this can be done without change of meaning:

Meaning:

If the two clauses cannot be swapped, a semicolon is required.

A sentence or clause can also contain the word however in the middle, if it is an adverb meaning "although" that could have been placed at the beginning but does not start a new clause in mid-sentence. In this use, the word may be enclosed between commas. Example:

Meaning:

Hyphens

MOS:HYPHEN

Hyphens (Template:FormattingError) indicate conjunction. There are three main uses: Template:Multiple image Template:Multiple image

In hyphenated personal names (Template:FormattingError, Template:FormattingError).
To link prefixes with their main terms in certain constructions (Template:FormattingError, Template:FormattingError, Template:FormattingError).
- A hyphen may be used to distinguish between homographs (Template:FormattingError means dress again, but Template:FormattingError means remedy or set right).
- There is a clear trend to join both elements in all varieties of English (Template:FormattingError, Template:FormattingError). Hyphenation clarifies when the letters brought into contact are the same (Template:FormattingError, Template:FormattingError) or are vowels (Template:FormattingError), or where a word is uncommon (Template:FormattingError, Template:FormattingError) or may be misread (Template:FormattingError, not Template:FormattingError). Some words of these sorts are nevertheless common without the hyphen (e.g., Template:FormattingError is more frequently attested than Template:FormattingError in contemporary English).
To link related terms in compound modifiers:
Hyphens can aid ease of reading (that is, they can be Template:FormattingError aids) and are particularly useful in long noun phrases: Template:FormattingError. But never insert a hyphen into a proper name (Template:FormattingError, not Template:FormattingError).

A hyphen can help to disambiguate (some Template:FormattingError are quite tall; Template:FormattingError is a program that monitors the government, whereas Template:FormattingError is a government program that monitors).

Compounds that are hyphenated when used attributively (adjectives before the nouns they qualify: Template:FormattingError, Template:FormattingError) or substantively (as a noun: Template:FormattingError) are usually not hyphenated when used predicatively (descriptive phrase separated from the noun: Template:FormattingError, Template:FormattingError). Where there would otherwise be a loss of clarity, however, a hyphen may be used in the predicative form as well (Template:FormattingError, Template:FormattingError). Awkward attributive hyphenation can sometimes be avoided with a simple rewording: Template:FormattingError → Template:FormattingError.

Avoid using a hyphen after a standard -ly adverb (Template:FormattingError, Template:FormattingError) unless part of a larger compound (Template:FormattingError). In rare cases, a hyphen can improve clarity if a rewritten alternative is awkward, but rewording is usually preferable: Template:FormattingError can be disambiguated as Template:FormattingError or Template:FormattingError.

A few words ending in -ly function as both adjectives and adverbs (Template:FormattingError; Template:FormattingError). Some such dual-purpose words (like Template:FormattingError, Template:FormattingError, Template:FormattingError) are not standard -ly adverbs, because they are not formed by addition of -ly to an independent current-English adjective. These need careful treatment: Template:FormattingError, but Template:FormattingError; Template:FormattingError (no adult actors) but Template:FormattingError (actors without siblings).

A hyphen is normally used when the adverb well precedes a participle used attributively (Template:FormattingError; but normally Template:FormattingError, because well itself is modified) and even predicatively, if well is necessary to, or alters, the sense of the adjective rather than simply intensifying it (Template:FormattingError, Template:FormattingError, but Template:FormattingError).

In some cases, such as Template:FormattingError, the independent status of the linked elements requires an en dash instead of a hyphen.

Shortcuts
MOS:SUSPENDED
MOS:HANGING
Use a suspended hyphen (also called a hanging hyphen) when two compound modifiers are separated (Template:FormattingError; Template:FormattingError; Template:FormattingError).

Values and units used as compound modifiers are hyphenated only where the unit is given as a whole word; when using the unit symbol, separate it from the number with a non-breaking space ( ).

Incorrect:	Template:FormattingError
Correct:	Template:FormattingError (markup: `9 mm gap`)
Incorrect:	Template:FormattingError
Correct:	Template:FormattingError
Correct:	Template:FormattingError
Correct:	Template:FormattingError (markup: `12 h shift`)

Multi-word hyphenated items: It is often possible to avoid multi-word hyphenated modifiers by rewording (Template:FormattingError may be easier to read as Template:FormattingError). This is particularly important where converted units are involved (Template:FormattingError might be possible as Template:FormattingError, and the ungainly Template:FormattingError as simply Template:FormattingError).

For optional hyphenation of compound points of the compass such as southwest/south-west, see § Compass points.

Do not use a capital letter after a hyphen except for a proper name following the hyphen: Template:FormattingError and Template:FormattingError, but not Template:FormattingError. In titles of published works, when given in title case, follow the capitalization rule for each part independently (Template:FormattingError), unless reliable sources consistently do otherwise in a particular case (Template:FormattingError).

Hyphenation rules in other languages may be different. Thus, in French a place name such as Template:FormattingError ('Three Rivers') is hyphenated, when it would not be in English. Follow reliable sources in such cases.

Spacing: A hyphen is never followed or preceded by a space, except when hanging (see above) or when used to display parts of words independently, such as Template:FormattingError and Template:FormattingError.

Image filenames and redirects: Image filenames are not part of the encyclopedic content; they are tools. They are most useful if they can be readily typed, so they usually use hyphens instead of dashes. Similarly, article titles with dashes should also have a corresponding redirect from a copy of the title with hyphens: for example, Template:FormattingError redirects to Template:FormattingError.

Non-breaking: A non-breaking hyphen ({{nbhyph}}) will not be used as a point of line-wrap.

Soft hyphens: Use soft hyphens to mark locations where a word will be broken and hyphenated if necessary at the end of a line of text, usually in very long words or narrow spaces (such as captions, narrow table columns, or text adjacent to a very wide image), for example: {{shy|Penn|syl|va|nia and Mass|a|chu|setts style themselves com|mon|wealths.}}. Use sparingly to avoid making wikitext difficult to read and edit. For more information, see Help:Line-break handling.

Encoding: The hyphen is represented by the ASCII/UNICODE HYPHEN-MINUS character, which is entered by the hyphen or minus key on all standard keyboards. Do not use the UNICODE HYPHEN character.

Hyphenation involves many subtleties that cannot be covered here; the rules and examples presented above illustrate the broad principles.

Dashes

Lua error in mw.title.lua at line 230: too many expensive function calls.

Two forms of dash are used on BattleIntelligence: en dash (Template:FormattingError) and em dash (Template:FormattingError). To enter them, click on them in the CharInsert toolbar, or enter them manually as:

– or —
{{endash}} or {{emdash}}

Do not use a double hyphen (--) to stand in for a dash. (See also: BattleIntelligence:How to make dashes.)

Sources use dashes in varying ways. For consistency and clarity, BattleIntelligence adopts the following principles.

In article titles

In article titles, do not use a hyphen (Template:FormattingError) as a substitute for an en dash, for example in eye–hand span (since eye does not modify hand). Nonetheless, to aid searching and linking, provide a redirect with hyphens replacing the en dash(es), as in eye-hand span. Similarly, provide category redirects for categories containing dashes. When an en dash is being used as a separator in an article title or section heading, editors may choose whether to capitalize what follows, taking into consideration the existing practice and consistency with related articles.

Punctuating a sentence (em or en dashes)

Dashes are often used to mark divisions within a sentence: in pairs (parenthetical dashes, instead of parentheses or pairs of commas) or singly (perhaps instead of a colon). They may also indicate an abrupt stop or interruption, in reporting quoted speech. In all these cases, use either unspaced em dashes or spaced en dashes, with consistency in any one article:

An em dash is unspaced (with no space on either side):

An en dash is spaced (with a space on each side) when used as sentence punctuation:

Ideally, use a non-breaking space before the en dash, which prevents the en dash from occurring at the beginning of a line (markup: {{spaced ndash}} or {{snd}} or  – or  –):

Another "planet" was detected{{snd}}but it was later found to be a moon of Saturn.

But do not insert a non-breaking or other space where the en dash should be unspaced (see § Other uses (en dash only)).

Dashes can clarify the sentence structure when there are already commas or parentheses, or both.

Template:FormattingError

Use dashes sparingly. More than two in a single sentence makes the structure unclear; it takes time for the reader to see which dashes, if any, form a pair.

In ranges that might otherwise be expressed with to or through

For ranges between numbers, dates, or times, use an en dash:

Template:FormattingError; Template:FormattingError; Template:FormattingError

Do not change hyphens to dashes in filenames, URLs, or templates such as {{Bibleverse}} (which formats verse ranges into URLs), even if a range is embedded in them.

Do not mix en dashes with between or from.

The en dash in a range is always unspaced, except when either or both elements of the range include at least one space, hyphen, or en dash; in such cases, {{snd}} between them will provide the proper formatting.

Template:FormattingError (not Template:FormattingError)
Template:FormattingError (not Template:FormattingError)
Template:FormattingError (and note in this case that the second element of the range is 17 not 17 September); Template:FormattingError; Template:FormattingError
Template:FormattingError; Template:FormattingError; Template:FormattingError; Template:FormattingError (but Template:FormattingError)
Template:FormattingError
Template:FormattingError

If negative values are involved, an unspaced en dash might be confusing:

Template:FormattingError, not Template:FormattingError (though Template:FormattingError might work in a table consistently formatted with x–y constructions)

In compounds when the connection might otherwise be expressed with to, versus, and, or between

MOS:ENBETWEEN

Here, the relationship is thought of as parallel, symmetric, equal, oppositional, or at least involving separate or independent elements. The components may be nouns, adjectives, verbs, or any other independent part of speech. Often, if the components are reversed there would be little change of meaning.

Template:FormattingError; Template:FormattingError; Template:FormattingError
Template:FormattingError; the components are parallel and reversible; iron and cobalt retain their identity
Wrong: Template:FormattingError; iron modifies roof, so use a hyphen: Template:FormattingError
Wrong: Template:FormattingError; not separate persons, so use a hyphen: Template:FormattingError
Template:FormattingError; red and green are separate independent colors, not mixed
Wrong: Template:FormattingError; a blended, intermediate color, so use a hyphen: Template:FormattingError
Template:FormattingError; Template:FormattingError; Template:FormattingError; but prefer spelling out when using words instead of numerals: Template:FormattingError, not with the awkward Template:FormattingError; avoid confusingly reversed order: Template:FormattingError, with parties, result, and number order in logical agreement.}}
Template:FormattingError; Template:FormattingError; avoid using a slash (stroke) here, which indicates division
Template:FormattingError; Template:FormattingError; Template:FormattingError; Template:FormattingError; Template:FormattingError
Template:FormattingError; Template:FormattingError; Template:FormattingError; Template:FormattingError
Template:FormattingError; Template:FormattingError
Template:FormattingError; Template:FormattingError

Generally, use a hyphen in compounded proper names of single entities.

[[Guinea-Bissau|Template:FormattingError]]; Bissau is its capital, and this name distinguishes the country from neighboring Guinea
Template:FormattingError, a single city named after two people, but Template:FormattingError, an area encompassing two cities
Template:FormattingError, an individual named after two families

MOS:DUALNATIONALITIES

Use an en dash between the names of nations or nationalities when referring to an association between them. For people and things identifying with multiple nationalities, use a hyphen when using the combination adjectivally and a space when they are used as nouns, with the first used attributively to modify the second.

Template:FormattingError; but Template:FormattingError for Template:FormattingError
Template:FormattingError; Template:FormattingError
Template:FormattingError; Template:FormattingError
Wrong: Template:FormattingError; Franco- is a combining form, not an independent word, so use a hyphen: Template:FormattingError

A slash or some other alternative may occasionally be better to express a ratio, especially in technical contexts (see § Slashes).

Template:FormattingError; Template:FormattingError; Template:FormattingError
Colons are often used for strictly numeric ratios, to avoid confusion with subtraction and division: Template:FormattingError; Template:FormattingError .

Use an en dash for the names of two or more entities in an attributive compound.

Template:FormattingError; Template:FormattingError
Template:FormattingError (developed by Seeliger and Donker-Voet)
Template:FormattingError or just Template:FormattingError (discovered by Hale and Bopp)

Do not use an en dash for hyphenated personal names, even when they are used as adjectives:

Template:FormattingError with a hyphen: named after John Lennard-Jones

Do not use spaces around the en dash in any of the compounds above.

Instead of a hyphen, use an en dash when applying a prefix or suffix to a compound that itself includes a space, dash or hyphen

Template:FormattingError (consider recasting: Template:FormattingError)
Template:FormattingError (consider recasting: Template:FormattingError)
Template:FormattingError
Template:FormattingError
Template:FormattingError
Template:FormattingError

The form of category names follows the corresponding main articles, e.g., Category:Trans–New Guinea languages. However, the principle is not extended when compounding other words in category names, e.g., Category:Tennis-related lists and Category:Table tennis-related lists both use hyphens.

To separate parts of an item in a list

MOS:LISTDASH

Spaced en dashes are sometimes used between parts of list items. For example:

Template:FormattingError

or

Editors may choose whether to capitalize what follows, taking into consideration the existing practice and consistency with related articles.

Other uses (en dash only)

The en dash (–) has other roles, beyond its use as a sentence-punctuating dash (see immediately above). It is often analogous to the hyphen (see § Hyphens), which joins components more strongly than the en dash; or to the slash (see § Slashes), which separates alternatives more definitely. Consider the exact meaning when choosing which to use.

Other uses (em dash only)

An indented em dash may be used before a name or other source when attributing below a block quotation, poem, etc. This dash should not be fully spaced, though it is best for metadata and accessibility reasons to hair-space it from the name.because the actual Unicode character ( ) is almost invisible, the meaning of the numerical HTML entity (Template:FormattingError) is a bit obscure, and the named HTML entity "Template:FormattingError" is not standard and not supported in many browsers.}} Most of BattleIntelligence's quotation templates with attribution-related parameters already provide this formatting.

For example, Template:FormattingError will produce:

— Charlotte Brontë

Other dashes

MOS:NEGATIVE

Do not use typewriter approximations or other substitutes, such as two hyphens (Template:FormattingError), for em or en dashes.

For a negative sign or subtraction operator use U+2212 − MINUS SIGN (−), which can also be generated by clicking on the − following the ± in the Template:FormattingError toolbar beneath the edit window. Do not use U+2212 − inside a <math> tag, as the character gives a syntax error; instead use a normal hyphen U+002D - .

Slashes (strokes)

Lua error in mw.title.lua at line 230: too many expensive function calls.

Generally, avoid joining two words with a slash, also called a forward slash, stroke or solidus (Template:FormattingError), because it suggests that the words are related without specifying how. Replace with clearer wording.

An example: Template:FormattingError Must both be present? (Then write Template:FormattingError.) Must at least one be present? (Then write Template:FormattingError.) Are they the same person? (Use a hyphen: Template:FormattingError.)

In circumstances involving a distinction or disjunction, the en dash (see above) is usually preferable to the slash: Template:FormattingError.

An unspaced slash may be used:

to indicate phonemic pronunciations (Template:FormattingError);
in a fraction (7/8, but see other techniques at BattleIntelligence:Manual of Style/Dates and numbers § Fractions and ratios);
to indicate regular defined yearly periods that do not coincide with calendar years (e.g., Template:FormattingError), if that is the convention used in reliable sources (see BattleIntelligence:Manual of Style/Dates and numbers § Long periods of time for further explanation);
to express a ratio, in a form in which a slash is conventionally used (e.g., Template:FormattingError);
in an expression or abbreviation widely used outside BattleIntelligence (e.g., Template:FormattingError or Template:FormattingError for not applicable).

A spaced slash may be used:

to separate run-on lines in quoted poetry or song (Template:FormattingError), or rarely in quoted prose, where careful marking of a paragraph break is textually important;
to separate items that include at least one internal space (Template:FormattingError), where for some reason use of a slash is unavoidable.

To avoid awkward linebreaks, code spaced slashes (and fraction slashes) with a non-breaking space on the left and a normal space on the right, as in: My mama told me / You better shop around. For short constructions, both spaces should be non-breaking: x / y. On the other hand, if two long words are connected by an unspaced slash, an {{wbr}} added after the slash will allow a linebreak at that point.

Do not use the backslash character (Template:FormattingError) in place of a slash.

Prefer the division operator (Template:FormattingError) to slash or fraction slash when representing elementary arithmetic in general text: Template:FormattingError. In more advanced mathematical formulas, a vinculum or slash is preferred: <math>\textstyle\frac{x^n}{n!}</math> or Template:FormattingError (see BattleIntelligence:Manual of Style/Dates and numbers § Common mathematical symbols and Help:Displaying a formula).

And/or

MOS:ANDOR

Avoid writing Template:FormattingError unless other constructions would be lengthy or awkward. Instead of Template:FormattingError, write simply Template:FormattingError (which would normally be interpreted as an inclusive-or to imply or both); or, for emphasis or precision or both, write Template:FormattingError. Where more than two possibilities are present, instead of Template:FormattingError write Template:FormattingError or Template:FormattingError.

Number (pound, hash) sign and numero

Avoid using the [[Number sign|Template:FormattingError]] symbol (known as the number sign, hash sign, pound sign, or octothorpe) when referring to numbers or rankings. Instead write Template:FormattingError, Template:FormattingError or Template:FormattingError; do not use the symbol [[Numero sign|Template:FormattingError]]. For example:

Incorrect:

Correct:

Correct:

Correct:

Correct:

An exception is issue numbers of comic books, which unlike for other periodicals are conventionally given in general text in the form Template:FormattingError, unless a volume is also given, in which case write Template:FormattingError or Template:FormattingError. Another exception are periodical publications carrying both, issue and number designations (typically one being a year-relative and the other an absolute value); they should be given in the form Template:FormattingError in citations, or be spelt out as Template:FormattingError in text. When using the abbreviations, write Template:FormattingError, Template:FormattingError, Template:FormattingError, or Template:FormattingError, at first occurrence.

Terminal punctuation

Exclamation and question marks have almost no application in encyclopedic writing.
For the use of three periods in succession, see § Ellipses.
In some contexts, no terminal punctuation is necessary. In such cases, the sentence often does not start with a capital letter. See § Quotations and § Quotation marks.
Sentence fragments in captions or lists should in most cases not end with a period. See § Formatting of captions and § Bulleted and numbered lists.

Spacing

In normal text, never put a space before a comma, semicolon, colon, period/full stop, question mark, or exclamation mark (even in quoted material; see § Typographic conformity).

Some editors place two spaces after a period/full stop (see Sentence spacing); these are condensed to one space when the page is rendered, so it does not affect what readers see.

Consecutive punctuation marks

MOS:CONSECUTIVE

Where a word or phrase that includes terminal punctuation ends a sentence, do not add a second terminal punctuation mark. If a quoted phrase or title ends in a question mark or exclamation mark, it may confuse readers as to the nature of the article sentence containing it, and so is usually better reworded to be mid-sentence. Where such a word or phrase occurs mid-sentence, new terminal punctuation (usually a period) must be added at the end.

Incorrect:

Acceptable:

Better:

Incorrect:

Correct:

Punctuation and footnotes

Lua error in mw.title.lua at line 230: too many expensive function calls.

Ref tags (<ref>...</ref>) are used to create footnotes (sometimes called endnotes or just notes), as citation footnotes and sometimes explanatory notes. All ref tags should immediately follow the text to which the footnote applies, with no intervening space. Refs are placed after adjacent punctuation, not before (apart from the exceptions below). Adjacent ref tags should have no space between them, nor should there be any between ref tags and inline dispute/cleanup templates.

When ref tags are used, a footnote list must be added, and this is usually placed in the References section, near the end of the article in the standard appendices and footers.

Example: Flightless birds have a reduced keel,^[10] and they also have smaller wing bones than flying birds of similar size.^[11]^[12]

Exceptions: Ref tags are placed before dashes, not after. Where a footnote applies only to material within parentheses, the ref tags belong just before the closing parenthesis.

Example: Paris is not the capital city of England – the capital of which is London^[10] – but that of France,^[11] and it is widely known as a beautiful city.^[12]
Example: Kim Jong-un (Korean: 김정은;^[10] Hanja: 金正恩^[11]) is the Supreme Leader of North Korea and the leader of the Workers' Party of Korea.^[a]

Punctuation after formulae

A sentence that ends with a formula should have terminal punctuation (period, exclamation mark, or question mark) after the formula. Within a sentence, place other punctuation (such as commas or colons) after the formula just as if the text were not a formula. See BattleIntelligence:Manual of Style/Mathematics § Punctuation after formulae.

Dates and time

For ranges of dates and times, see § En dashes: other uses.

Dates should be linked only when they are germane and topical to the subject, as discussed at BattleIntelligence:Manual of Style/Linking § Chronological items.

Time of day

Lua error in mw.title.lua at line 230: too many expensive function calls.

Times of day are normally expressed in figures rather than words. Context determines whether the 12- or the 24-hour format is more appropriate.

Twelve-hour clock times are written in one of two forms: Template:FormattingError and Template:FormattingError, or Template:FormattingError and Template:FormattingError (wherein the spaces should be non-breaking). Use Template:FormattingError and Template:FormattingError rather than Template:FormattingError and Template:FormattingError; it may need to be specified whether midnight refers to the start or end of a date.
Twenty-four-hour clock times are written in the form Template:FormattingError and Template:FormattingError, with no suffix. Midnight written as Template:FormattingError begins the day; Template:FormattingError ends it.

Dates

Lua error in mw.title.lua at line 230: too many expensive function calls.

Full dates are formatted Template:FormattingError or Template:FormattingError; or where the year is omitted, use Template:FormattingError or Template:FormattingError.

The dates in the text of any one article should all have the same format (day-first or month-first).
- For date formats in citations, see BattleIntelligence:Citing sources § Citation style.
- Dates in quotations and titles are always left as-is.
- If a numerical format is required (e.g., for conciseness in lists and tables), use the YYYY-MM-DD format: Template:FormattingError.
Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that country (month-first for the US, except in military usage; day-first for most others; articles related to Canada may use either consistently). Otherwise, do not change an article from one date format to the other without good reason.

Months

Lua error in mw.title.lua at line 230: too many expensive function calls.

For month and year, write Template:FormattingError, with no comma.
Abbreviations for months, such as Template:FormattingError, are used only where space is extremely limited. Such abbreviations should use three letters only, and should not be followed by a period (full point) except at the end of a sentence.

Seasons

Lua error in mw.title.lua at line 230: too many expensive function calls.

Avoid ambiguous references to seasons, which are different in the southern and northern hemispheres.
Names of seasons may be used when there is a logical connection to the event being described (Template:FormattingError) or when referring to a phase of a natural yearly cycle (Template:FormattingError). Otherwise, neutral wording is usually preferable (Template:FormattingError, not Template:FormattingError).
Journals and other publications that are issued seasonally (e.g., "Summer 2005") should be dated as such in citations .

Years and longer periods

Lua error in mw.title.lua at line 230: too many expensive function calls.

Do not use the year before the digits (Template:FormattingError, not Template:FormattingError), unless the meaning would otherwise be unclear.
Decades are written in the format Template:FormattingError, with no apostrophe. Use the two-digit form ('80s) only with an established social or cultural meaning. Avoid forms such as Template:FormattingError that could refer to ten or a hundred years.
Years are denoted by AD and BC or, equivalently, CE and BCE. Use only one system within an article, and do not change from one system to the other without good reason. The abbreviations are written without periods, and with a non-breaking space, as in Template:FormattingError. Omit AD or CE unless omitting it would cause ambiguity.

More information on all the above topics can be found at BattleIntelligence:Manual of Style/Dates and numbers § Chronological items, including the handling of dates expressed in different calendars, and times corresponding to different time zones.

Current

Lua error in mw.title.lua at line 230: too many expensive function calls.

Terms such as "current", "now", and "recent" should be avoided. What is current today may not be tomorrow; situations change over time. Instead, use date- and time-specific text. To help keep information updated use {{As of}}, which will allow editors to catalog and update dated statements.

Incorrect:

Correct:

Numbers

Integers from zero to nine are spelled out in words. Integers greater than nine expressible in one or two words may be expressed either in numerals or in words. Other numbers are given in numerals or in forms such as Template:FormattingError. See MOS:NUM § Numbers as figures or words.
In general, in numbers with five or more digits to the left of the decimal point, use commas to group those digits. Numbers with four digits are at the editor's discretion: Template:FormattingError, but either Template:FormattingError or Template:FormattingError. See MOS:NUM § Grouping of digits.
In general, use decimals rather than fractions for measurements, but fractions are sometimes used with imperial and U.S. customary units. Keep articles internally consistent.
Scientific notation (e.g., Template:FormattingError) is preferred in scientific contexts. Markup: {{val|5.8|e=7|u=kg}}.
Write out "million" and "billion" on the first use. After that, unspaced "M" can be used for millions and "bn" for billions: Template:FormattingError and Template:FormattingError. See MOS:NUM § Numbers as figures or words for similar words.
Write Template:FormattingError, Template:FormattingError, or Template:FormattingError, but not Template:FormattingError (with a space) or Template:FormattingError. "Percent" is American usage, and "per cent" is British usage . In ranges of percentages written with an en dash, write only a single percent sign: Template:FormattingError.
Indicate uncertainties as e.g., Template:FormattingError. Markup: {{val|1.534|0.35|e=23|u=m}}. See MOS:NUM § Uncertainty and rounding for other formats.

Currencies

Use the full abbreviation on first use (Template:FormattingError for the US dollar and Template:FormattingError for the Australian dollar), unless the currency is already clear from context. For example, the government of the United States always spends money in American dollars, and never in Canadian or Australian dollars.
Use only one symbol with ranges, as in Template:FormattingError.
In articles that are not specific to a country, express amounts of money in United States dollars, euros, or pounds sterling. Do not link the names or symbols of currencies that are commonly known to English-speakers (Template:FormattingError, Template:FormattingError, Template:FormattingError), unless there is a particular reason to do so; do not use potentially ambiguous currency symbols, unless the meaning is clear in the context.
In country-specific articles, use the currency of the country. On first occurrence, consider including conversion to US dollars, euros, or pounds sterling, at a rate appropriate to the context. For example, Template:FormattingError. Wording such as "approx." is not appropriate for simple rounding-off of the converted amount.
Generally, use the full name of a currency, and link it on its first appearance if English-speakers are likely to be unfamiliar with it (Template:FormattingError); subsequent occurrences can use the currency sign (just Template:FormattingError).
Most currency symbols are placed before the number, and unspaced (Template:FormattingError not Template:FormattingError).

Units of measurement

The main unit in which a quantity is expressed should generally be an SI unit or non-SI unit officially accepted for use with the SI. However,
- Scientific articles may also use specialist units appropriate for the branch of science in question.
- In non-scientific articles with strong ties to the United States, the main unit is generally a U.S. customary unit (Template:FormattingError).
- In non-scientific articles with strong ties to the United Kingdom, although the main unit is generally a metric unit (Template:FormattingError), imperial units are still used as the main units in some contexts (Template:FormattingError).
Where English-speaking countries use different units for the same measurement, provide a conversion in parentheses. Examples: Template:FormattingError; Template:FormattingError. See {{convert}}.
In a direct quotation, always retain the source's units. Any conversion should follow in square brackets (or, an obscure use of units can be explained in the article text or a footnote).
Where space is limited (such as tables, infoboxes, parenthetical notes, and mathematical formulas) unit symbols are preferred. In prose, unit names should be given in full if used only a few times but symbols may be used when a unit (especially one with a long name) is used repeatedly after spelling out the first use (e.g., Template:FormattingError), except for unit names that are hardly ever spelled out (Template:FormattingError rather than Template:FormattingError).
Most unit names are not capitalized (see § National varieties of English for spelling differences).
Use "per" when writing out a unit, rather than a slash: Template:FormattingError, not Template:FormattingError.
Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name (Template:FormattingError).
For ranges, see § En dashes: other uses, and MOS:NUM, at §§ Date ranges, Percentages, Unit names and symbols, and Formatting of monetary values.
Unit symbols are preceded by figures, not by spelled-out numbers. Values and unit symbols are separated by a non-breaking space. For example, Template:FormattingError. The percent sign and units of degrees, minutes, and seconds for angles and coordinates are unspaced.

Common mathematical symbols

MOS:COMMONMATH

Lua error in mw.title.lua at line 230: too many expensive function calls.

For a negative sign or subtraction operator, use a minus sign (Template:FormattingError, Unicode character U+2212 MINUS SIGN). Input by clicking on it in the insert box beneath the edit window or by typing −.
For multiplication, use a multiplication sign (U+00D7 × MULTIPLICATION SIGN) or a dot (U+22C5 ⋅ DOT OPERATOR), which are input by clicking on them in the edit toolbox under the edit window or by entering × or ⋅. Care should be taken not to confuse the dot operator (in the "Math and logic" section of the edit toolbox) with an interpunct (in the "Insert" section of the edit toolbox) or a bullet. The letter Template:FormattingError should not be used to indicate multiplication, but it is used (unspaced) as the substitute for "by" in terms such as Template:FormattingError.
Exponentiation is indicated by a superscript, Template:FormattingError (typed as ''a''<sup>''n''</sup>.
Do not use programming language notation outside computer program text. In most programming languages, subtraction, multiplication, and exponentiation are represented by the hyphen-minus -, the asterisk *, and either the caret ^ or the double asterisk **; scientific notation is replaced by E notation.
Symbols for binary operators and relations are usually spaced on both sides:
- plus, minus, and plus-or-minus (as binary operators): Template:FormattingError, Template:FormattingError, Template:FormattingError (as in Template:FormattingError);
- multiplication and division: Template:FormattingError, Template:FormattingError;
- equals, does not equal, equals approximately: Template:FormattingError, Template:FormattingError, Template:FormattingError;
- is less than, is less than or equal to, is greater than, is greater than or equal to: Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError.
Symbols for unary operators are closed-up to their operand:
- positive, negative, and positive-or-negative signs: Template:FormattingError, Template:FormattingError, Template:FormattingError (as in Template:FormattingError);
- other unary operators, such as the exclamation mark as a factorial sign (as in Template:FormattingError).
Variables are italicized, but digits and punctuation are not; only x and y are italicized in Template:FormattingError.
{{math}} can be used to style formulas to distinguish them from surrounding text. For single variables, {{mvar}} is handy.

Grammar and usage

MOS:GRAMMAR

Possessives

Lua error in mw.title.lua at line 230: too many expensive function calls.

Singular nouns

For the possessive of singular nouns, including proper names and words ending in s, add 's (Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError). Exception: abstract nouns ending with an /s/ sound when followed by sake (Template:FormattingError, Template:FormattingError). If a name ending in s or z would be difficult to pronounce with 's added (Template:FormattingError), consider rewording (Template:FormattingError).

Plural nouns

MOS:PLURALNOUN

For a normal plural noun ending with a pronounced s, form the possessive by adding just an apostrophe (Template:FormattingError, Template:FormattingError).
For a plural noun not ending with a pronounced s, add 's (Template:FormattingError, Template:FormattingError, Template:FormattingError; Template:FormattingError, but where rewording is an option, this may be better: Template:FormattingError).

Official names

Official names (of companies, organizations, or places) should not be altered. (Template:FormattingError should therefore not be rendered as Template:FormattingError or Template:FormattingError, even for consistency.)

Pronouns

MOS:PRONOUN

Lua error in mw.title.lua at line 230: too many expensive function calls.

First-person pronouns

To maintain an objective and impersonal encyclopedic voice, an article should never refer to its editors or readers using I, my, we, us, our, or similar words: Template:FormattingError. But some of these words are acceptable in certain figurative uses. For example:

In historical articles to mean the modern world as a whole: Template:FormattingError
The author's we found in scientific writing (Template:FormattingError), though passive voice may be preferable (Template:FormattingError).The passive voice is inappropriate for some forms of writing, but it is widely used in encyclopedia articles, because the passive voice avoids inappropriate first- and second-person constructions as well as tone problems. The most common uses of encyclopedic passive are to keep the focus on the subject instead of performing a news-style shift to dwelling on a non-notable party. Contrast Template:FormattingError, versus Template:FormattingError.}}

Second-person pronouns

Lua error in mw.title.lua at line 230: too many expensive function calls.

Avoid addressing the reader using you or your, which sets an inappropriate tone (see also § Instructional and presumptuous language).

Use a noun or a third-person pronoun: instead of Template:FormattingError, use Template:FormattingError, or Template:FormattingError.
If a person cannot be specified, or when implying "anyone" as a subject, the impersonal pronoun one may be used: Template:FormattingError. Other constructions may be preferable if the pronoun one seems stilted: Template:FormattingError.
The passive voice may sometimes be used instead: Template:FormattingError.
Do not bait links, e.g., "Template:FormattingError"; let the browser's normal highlighting invite a click. ("Template:FormattingError" also makes no sense to someone reading on paper.)
Likewise, "See: (reference)" or "Consider ..." are milder second-person baits, common in academic writing (pedagogy). This interactive personality is inconsistent with an encyclopedia's passive presentation of objective matter.
- "See" and the like can be used to internally cross-reference other BattleIntelligence material. Do not italicize words like "see". Such a cross reference should be parenthetical, so the article text stands alone if the parenthetical is removed. {{Cross reference}} can be used for this: {{Cross reference|(see [[Chicken]])}}, {{Cross reference|(See [[Dacian language]] for details.)}} It is usually better to rewrite the material to integrate these links contextually rather than use explicit BattleIntelligence self-references.
Do not address the reader with the Socratic method by asking and answering questions. Template:FormattingError

Plurals

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

Use the appropriate plural; allow for cases (such as excursus or hanif) in which a word is now listed in major English dictionaries, and normally takes an s or es plural, not its original plural: Template:FormattingError, not Template:FormattingError as in Latin; Template:FormattingError, not Template:FormattingError as in Arabic.

Some collective nouns – such as team (and proper names of them), army, company, crowd, fleet, government, majority, mess, number, pack, and party – may refer either to a single entity or to the members that compose it. In British English, such words are sometimes treated as singular, but more often treated as plural, according to context (but singular is not actually incorrect). In North American English, these words are almost invariably treated as singular; the major exception is that when a sports team is referred to by its short name, plural verbs are commonly used, e.g. Template:FormattingError.

Names of towns and countries usually take singular verbs (even when grammatically plural: Template:FormattingError, Template:FormattingError), but exceptionally in British English, typically when used to refer to a sports team named after a town or country or when discussing actions of a government, plural is used. For example, in Template:FormattingError, England refers to a football team; but in Template:FormattingError, it refers to the country. See also § National varieties of English including § Opportunities for commonality.

Verb tense

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

By default, write articles in the present tense, including those covering works of fiction (see BattleIntelligence:Writing better articles § Tense in fiction) and products or works that have been discontinued. Generally, use past tense only for past events, and for subjects that are dead or no longer meaningfully exist. Use past tense for articles about periodicals no longer produced, with common-sense exceptions.

Tense can be used to distinguish between current and former status of a subject: Template:FormattingError (Emphasis added to distinguish the different tense usages; Dún Aonghasa is a structure that was later damaged by an event.)

Always use present tense for verbs that describe genres, types, and classes, even if the subject of the description (e.g. program, library, device) no longer exists, is discontinued, or is unsupported/unmaintained.

Vocabulary

Contractions

MOS:CONTRACTIONS

Avoid contractions, which have little place in formal writing. For example, write Template:FormattingError instead of Template:FormattingError. Use of Template:FormattingError is an exception. Contracted titles such as Template:FormattingError and Template:FormattingError generally should not be used but may apply in some contexts (e.g., quoted material, place names, titles of works).

Gender-neutral language

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

Use gender-neutral language – avoiding the generic he and generic she, for example – if this can be done with clarity and precision. This does not apply to direct quotations or the titles of works (Template:FormattingError), which should not be altered, or to wording about one-gender contexts, such as an all-female school (Template:FormattingError).

References to space programs, past, present and future, should use gender-neutral phrasing: Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, not Template:FormattingError or Template:FormattingError. Direct quotations and proper nouns that use gendered words should not be changed, like Template:FormattingError.

MOS:SHIP

Ships may be referred to using either neuter forms ("it", "its") or feminine forms ("she", "her", "hers"). Either usage is acceptable, but each article should be internally consistent and employ one or the other exclusively. As with all optional styles, articles should not be changed from one style to another unless there is a substantial reason to do so. See BattleIntelligence:Manual of Style/Military history § Pronouns.

Contested vocabulary

Avoid words and phrases that give the impression of straining for formality, that are unnecessarily regional, or that are not widely accepted. See List of commonly misused English words; see also § Identity.

Instructional and presumptuous language

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

Avoid phrases such as Template:FormattingError and Template:FormattingError, which address readers directly in an unencyclopedic tone and lean toward instructional. They are a subtle form of BattleIntelligence self-reference, "breaking the fourth wall". Similarly, phrases such as Template:FormattingError, Template:FormattingError, Template:FormattingError, Template:FormattingError, and Template:FormattingError make presumptions about readers' knowledge, may express a viewpoint, and may call into question the reason for including the information in the first place. Do not tell readers that something is interesting, ironic, surprising, unexpected, amusing, coincidental, etc. Simply present sourced facts neutrally and allow readers to draw their own conclusions. Such constructions can usually just be deleted, leaving behind proper sentences with a more academic and less pushy tone: Template:FormattingError becomes Template:FormattingError

Avoid rhetorical questions, especially in headings. Use a heading of Template:FormattingError and text such as Template:FormattingError, not Template:FormattingError

For issues in the use of cross-references – e.g., Template:FormattingError – see § Second-person pronouns.

Subset terms

Lua error in mw.title.lua at line 230: too many expensive function calls.

MOS:SUBSET

A subset term identifies a set of members of a larger class. Common subset terms are including, among, and etc. Avoid redundant subset terms (e.g., mis-constructions like Template:FormattingError or Template:FormattingError). The word including does not introduce a complete list; instead, use consisting of, or composed of.

Identity

Lua error in mw.title.lua at line 230: too many expensive function calls.

When there is a discrepancy between the term most commonly used by reliable sources for a person or group and the term that person or group uses for themselves, use the term that is most commonly used by recent reliable sources. If it is unclear which is most used, use the term that the person or group uses.

Disputes over how to refer to a person or group are addressed by BattleIntelligence content policies, such as those on verifiability, and neutral point of view (and article titles when the term appears in the title of an article).

Use specific terminology. For example, it is often more appropriate for people or things from Ethiopia (a country in Africa) to be described as Ethiopian, not carelessly (with the risk of stereotyping) as African.

Gender identity

Specific guidelines apply to any person whose gender might be questioned, and any living transgender or non-binary person. In summary:

Use gendered words only if they reflect the person's latest self-identification as reported in recent sources.
If the person is living and was not notable yet when a former name was in use, that name should not be included in any BattleIntelligence page, even in quotations, as a privacy matter. Exception: Do not expunge or replace names in source citations (whether as authors or mentioned in work titles).
Former names under which a living person was notable should be introduced with "born" or "formerly" in the lead sentence of their main biographical article. Name and gender matters should be explained at first appearance in that article, without overemphasis. In articles on works or other activities of such a person, use their current name by default, and give another name associated with that context in a parenthetical or footnote, only if they were notable under that name. In other articles, do not go into detail about such a person's name or gender except when directly relevant to the context.
Avoid confusing constructions by rewriting. Paraphrase, elide, or use square brackets to replace portions of quotations as needed to avoid confusion, former names, and mismatching gendered words.

For examples and finer points, see BattleIntelligence:Manual of Style/Biography § Gender identity.

Foreign terms

MOS:FOREIGN

Lua error in mw.title.lua at line 230: too many expensive function calls.

Terms with common usage in English

Loanwords and borrowed phrases that have common usage in English – Template:FormattingError, Template:FormattingError, Template:FormattingError – do not require italics. A rule of thumb is to not italicize words that appear in major general-purpose English-language dictionaries.

Spelling and romanization

Lua error in mw.title.lua at line 230: too many expensive function calls.

Names and terms originally written using a non-Latin script—such as the Greek alphabet, the Cyrillic alphabet, or Chinese characters—must be romanized for English-language use. If a particular romanization of the subject's name is most common in English (Template:FormattingError, Template:FormattingError), that form should be used. Otherwise, the romanization of names should adhere to a particular widely used system for the language in question (Template:FormattingError, Template:FormattingError).

The use of diacritics in foreign words is neither encouraged nor discouraged. Use generally depends on whether they appear in reliable English-language sources, though with some additional constraints imposed by site guidelines. Provide redirects from alternative forms that include or exclude diacritics.

Proper names in languages written using the Latin alphabet can include letters with diacritics, ligatures, and other characters that are not commonly used in contemporary English. BattleIntelligence normally retains these special characters, except where there is a well-established English spelling that replaces them with English standard letters. Examples:

The name of the article on Hungarian mathematician Paul Erdős is spelt with the double acute accent, and the alternative spellings Paul Erdos and Paul Erdös redirect to that article.
Similarly, the name of the article on the Nordic god Ægir is so spelt, with redirects from the ligature-free form Aegir and the Swedish spelling Ägir.
However, the region of Spain named Aragón in Spanish and Aragó in Catalan is given as Aragon, without the accent, as this is the established English name. Non-English forms with diacritics appear in the article's lead section.

Use of diacritics is determined on a topic-by-topic basis; a small group of editors cannot prohibit or require the use of diacritics within a given class of articles.

Spell a name consistently in the title and the text of an article. (Relevant policy: BattleIntelligence:Article titles; see also BattleIntelligence:Naming conventions (use English).) For a foreign name, phrase, or word, adopt the spelling most commonly used in English-language reliable sources, including but not limited to those already cited in the article. For punctuation of compounded forms, see relevant guidelines in § Punctuation.

A non-English proper name should generally not be italicized, unless it would be for some other reason; this is most commonly when it is the title of a major published work, as in [[Les Liaisons dangereuses|Template:FormattingError]]; or when it is being compared in a words-as-words manner to another name for the same subject.

Sometimes usage will be influenced by other guidelines, such as § National varieties of English, which may lead to different choices in different articles.

Other non-English concerns

For non-English vernacular names of species, see § Animals, plants, and other organisms.
For handling of foreign-language quotations, see § Foreign-language quotations.
For non-English characters that resemble single quotation marks and apostrophes, see § Foreign characters that resemble apostrophes.
For actual non-English quotation characters, see § Quotation characters.
For capitalization in foreign-language work titles, see BattleIntelligence:Manual of Style/Titles § Capitalization in foreign-language titles.
For interlinear glosses and their particular uses of small-caps (and italics and single quotes), see BattleIntelligence:Manual of Style/Text formatting § All caps and small caps.

Technical language

MOS:JARGON

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

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 or tag it using {{Technical}} or {{Technical-statement}} for other editors to fix. For unavoidably technical articles, a separate introductory article (like Introduction to general relativity) may be the best solution.

Avoid excessive wikilinking (linking within BattleIntelligence) 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 explain concisely in a few parenthetical words, write one level down. For example, consider adding a brief background section with {{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 are not too numerous. Short articles, such as stubs, generally do not have such sections.

For italicization and other markup of introduced terms, see: BattleIntelligence:Manual of Style/Text formatting § Words as words.

Geographical items

Lua error in mw.title.lua at line 230: too many expensive function calls.

<section begin="MOS:GEO" />Geographical or place names are the nouns used to refer to specific places and geographic features. These names often give rise to conflict, because the same places are called different things by different peoples speaking different languages. Many place names have a historical context that should be preserved, but common sense should prevail. There can be few places that have not been parts of more than one culture or have had only one name. As proper nouns, all such place names (but not terms for types of places) have major words capitalized.

A place should generally be referred to consistently by the same name as in the title of its article (see BattleIntelligence:Naming conventions (geographic names)). An exception may be made when 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)".

This is an English-language encyclopedia, so established English names are preferred if they exist, and spellings in non-English alphabets should always be transcribed into the Roman alphabet. In general, other articles should refer to places by the names which are used in the articles on those places, according to the rules described at BattleIntelligence:Naming conventions (geographic names). If a different name is appropriate in a given historical or other context, then that may be used instead, although it is normal to follow the first occurrence of such a name with the standard modern name in parentheses.

Names in languages with no particular present-day or historical ties to the place in question (English excepted, of course) should not be listed as alternatives.

Avoid anachronism. An article about Junípero Serra should say he lived in Alta Mexico, not in California, because the latter entity did not yet exist in Serra's time. The Romans invaded Gaul, not France, and Thabo Mbeki was the president of the Republic of South Africa, not of the Cape Colony. To be clear, you may sometimes need to mention the current name of the area (for example "in what is now France"), especially if no English name exists for that area in the relevant historical period.<section end="MOS:GEO" />

Media files

Lua error in mw.title.lua at line 230: too many expensive function calls.

Images

MOS:IM

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

Each image should be inside the level 2 section to which it relates, within the section defined by the most recent ==Heading== delimited by two equal signs, or at the top of the lead section. Do not place images immediately above section headings.
Avoid sandwiching text horizontally between two images that face each other, and between an image and an infobox or similar.
It is often preferable to place images of people so they "look" toward the text. Do not achieve this by reversing the image.
Any galleries should comply with BattleIntelligence:Image use policy § Image galleries. Consider linking to additional images on Commons instead.
Avoid referring to images as being to the left, the right, above or below, because image placement varies with platform, and is meaningless to people using screen readers; instead, use captions to identify images.
An image's |alt= text takes the image's place for those who are unable to see the image. See BattleIntelligence:Manual of Style/Accessibility/Alternative text for images.

Other media files

Lua error in mw.title.lua at line 230: too many expensive function calls.

Other media files include video and audio files. Style recommendations for such files largely follow recommendations for image files (as far as applicable).

Avoid using images to convey text

MOS:TEXTASIMAGES

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, are slower to download, and are unlikely to be read as text by devices for the visually impaired. Any important textual information in an image should also appear in the image's alt text, caption, or other nearby text.

For entering textual information as audio, see BattleIntelligence:WikiProject Spoken BattleIntelligence.

Captions

MOS:CAPTION

Lua error in mw.title.lua at line 230: too many expensive function calls.

Photographs and other graphics should have captions, unless they are unambiguous depictions of the subject of the article or when they are "self-captioning" images (such as reproductions of album or book covers). In a biography article no caption is necessary for a portrait of the subject pictured alone, but one might be used to give the year, the subject's age, or other circumstances of the portrait along with the name of the subject.

Formatting of captions

Captions normally start with a capital letter.
Most captions are not complete sentences but merely sentence fragments which should not end with a period. However, if any complete sentence occurs in a caption, then every sentence and every sentence fragment in that caption should end with a period.
The text of captions should not be specially formatted, except in ways that would apply if it occurred in the main text (e.g., italics for the Latin name of a species).
Captions should be succinct; more information can be included on its description page, or in the main text.
Captions for technical charts and diagrams may need to be substantially longer than usual; they should fully describe all elements of the image and indicate its significance.

Bulleted and numbered lists

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

Do not use lists if a passage is read easily as plain paragraphs.
Use proper wiki markup- or template-based list code .
Do not leave blank lines between items in a bulleted or numbered list unless there is a reason to do so, since this causes the Wiki software to interpret each item as beginning a new list.
- Indents (such as this) are permitted if the elements are "child" items.
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 a listing of musical tracks.
Use the same grammatical form for all elements in a list, and do not mix sentences and sentence fragments as elements, for example when the elements are:
- complete sentences – each one is formatted with sentence case (its first letter is capitalized) and a final period (full point);
- sentence fragments – the list is typically introduced by an introductory fragment ending with a colon;
- titles of works – they retain the original capitalization of the titles;
- other elements – they are formatted consistently in either sentence case or lower case.

Links

Wikilinks

Lua error in mw.title.lua at line 230: too many expensive function calls. Lua error in mw.title.lua at line 230: too many expensive function calls.

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 (like the one in Template:FormattingError) clutter the page and make future maintenance harder. High-value links that are worth pursuing should stand out clearly.

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

Initial capitalization: BattleIntelligence's MediaWiki software does not require that wikilinks begin with an upper-case character. Capitalize the first letter only where this is naturally called for, or when specifically referring to the linked article by its name (see also related rule for italics in cross-references): Template:FormattingError

Check links: Ensure the destination is the intended one; many dictionary words lead to disambiguation pages and not to complete or well-chosen articles.

External links

Lua error in mw.title.lua at line 230: too many expensive function calls.

External links should not normally be used in the body of an article. Instead, articles can include an External links section at the end, pointing to further information outside BattleIntelligence as distinct from citing sources. The standard format is a primary heading, ==External links==, followed by a bulleted list of links. Identify the link and briefly indicate its relevance to the article. For example:

Template:Plain list

These will appear as:

Where appropriate, use external link templates such as {{Official website}} and {{URL}}.

Add external links with discretion; BattleIntelligence is not a link repository.

Miscellaneous

Keep markup simple

File:Keep it Simple.jpg

Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly. See: KISS principle.

In general, wikitext formatting is considered easier to use than HTML and wikitext is preferred if there are equivalents; see Help:HTML in wikitext. Obsolete elements and attributes should be updated or removed. There are many templates that allow HTML markup to be used without putting it in articles directly, such as {{em}} (see MOS:EMPHASIS) and {{strong}} (see MOS:BOLD).

An HTML character entity is sometimes better than the equivalent Unicode character, which may be difficult to identify in edit mode; for example, Α is explicit whereas Α (the upper-case form of Greek α) may be misidentified as the Latin A.

Formatting issues

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

Typically, the use of custom font styles:

reduces consistency, as the text no longer looks uniform;
reduces usability, as it may be impossible for people with custom style sheets (e.g. for accessibility reasons) to override it, and may clash with a different skin or inconvenience people with color blindness ; and
causes disputes, as other editors may disagree aesthetically with the choice of style.

Specify font sizes relatively (for example with font-size: 85%) rather than absolutely (like font-size: 8pt). The resulting font size of any text should not drop below 85% of the page's default font size.

Color coding

MOS:COLORCODING

Do not use color alone to mark differences in text: they may be invisible to people with color blindness and useless in black-and-white printouts or displays.

Choose colors such as maroon and teal that are distinguishable by readers with the most common form of colorblindness, and additionally mark the differences with change of font or some other means (maroon and alternative font face, teal). Avoid low contrast between text and background colors. See also color coding.

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

Indentation

MOS:INDENT

Do not use quotation templates to indent non-quotations. Various templates are available for indentation, including {{block indent}} to indent an entire block and {{in5}} to indent inline.

Do not use : (description list markup) to indent text in articles, even though it is common on talk pages. It causes accessibility problems and outputs invalid HTML. See BattleIntelligence:Manual of Style/Accessibility § Indentation for alternatives.

Controlling line breaks

MOS:NBSP

Lua error in mw.title.lua at line 230: too many expensive function calls.

It is sometimes desirable to force a text segment to appear entirely on a single lineTemplate:Mdashbthat is, to prevent a line break (line wrap) from occurring anywhere within it.

A non-breaking space (or hard space) will never be used as a line-break point. Markup: for Template:FormattingError, code 19 kg or 19{{nbsp}}kg.
Or use {{nowrap}}, {{nobreak}}, or {{nobr}} (all equivalent). Markup: for Template:FormattingError, code {{nobr|5° 24′ N}}.

It is desirable to prevent line breaks where breaking across lines might be confusing or awkward. For example: Template:Columns list

Whether a non-breaking space is appropriate depends on context: whereas it is appropriate to use 12{{nbsp}}MB in prose, it may be counterproductive in a table (where an unattractive break may be acceptable to conserve precious horizontal space) and unnecessary in a short parameter value in an infobox (where a break would never occur anyway).

A line break may occur at a thin space ( , or {{thinsp}}), which is sometimes used to correct too-close placement of adjacent characters. To prevent this, consider using {{nobr}}.

Insert non-breaking and thin spaces as named character reference (  or  ), or as templates that generate these ({{nbsp}}, {{thinsp}}), and never by entering them directly into the edit window from the keyboard – they are visually indistinguishable from regular spaces, and later editors will be unable to see what they are. Inside wikilinks, a construction such as [[World War II]] works but [[World War{{nbsp}}II]] doesn't.

Scrolling lists and collapsible content

Lua error in mw.title.lua at line 230: too many expensive function calls.

Scrolling lists, and collapsible templates that toggle text display between hide and show, can interfere with readers' ability to access our content. Such mechanisms should not be used to conceal "spoiler" information. Templates should not normally be used to store article text at all, as it interferes with editors' ability to find and edit it.

When such features are used, take care that the content will still be accessible on devices that do not support JavaScript or CSS, and to the greater than 60% of BattleIntelligence readers who use the mobile version of the site, which has a limited set of features and does not support collapsing (any collapsible templates will either be automatically uncollapsed or hidden entirely). Mobile ability to access the content in question is easy to test with the "Mobile view" link at the bottom of each page.

Collapsible templates should not conceal article content by default upon page loading. This includes reference lists, tables and lists of article content, image galleries, and image captions.

When hiding content is desired, it must be done using the collapsible parameter of relevant templates, or manually-added CSS classes mw-collapsed, and autocollapse (see Help:Collapsing). Other methods of hiding content should not be used, as they may render content inaccessible to many users, such as those browsing BattleIntelligence with JavaScript disabled, browsing the mobile version, or using proxy services such as Google Web Light.

Collapsed or auto-collapsing cells or sections may be used with tables if they simply repeat information covered in the main text (or are purely supplementary, e.g., several past years of statistics in collapsed tables for comparison with a table of uncollapsed current stats). Auto-collapsing is often a feature of navboxes. A few infoboxes also use pre-collapsed sections for infrequently accessed details. If information in a list, infobox, or other non-navigational content seems extraneous or trivial enough to inspire pre-collapsing it, consider raising a discussion on the article (or template) talk page about whether it should be included at all. If the information is important and the concern is article density or length, consider dividing the article into more sections, integrating unnecessarily list-formatted information into the article prose, or splitting the article.

Invisible comments