Download the Liquipedia app here!Download the Liquipedia app to follow Brood War!Want personalized updates on Brood War esports? Download the Liquipedia app on iOS or Android to never miss your favorite tournaments and matches!
Liquipedia app match pages updated! Liquipedia app match pages are overhauled! Download on Android or iOS! Liquipedia app's match pages got completely revamped with game data, standings, VODs and more! Download the the latest version on iOS or Android and read our update blog here.

Help:Manual of Style

From Liquipedia StarCraft Brood War Wiki
This article is under construction and is subject to major revisions.


This page explains the inclusion criteria for the new player achievement boxes that are in the process of being introduced to this wiki. The introduction of the new player achievement box comes with the introduction of comprehensive player results pages, where all results achieved by a player who has a page on this wiki are to be placed.

While these achievement boxes may carry the same aesthetic look and feel as their counterparts do on another Liquipedia wiki, they do not have the same inclusion criteria, as the different wikis deal with two very separate games and scenes.

There are three distinct sets of inclusion criteria for the use of these achievement boxes on this wiki, one for each of the following:

  • old Korean professional scene players
  • Korean amateur scene players
  • and Foreign players.

There are also a set of general inclusion criteria that govern the use of the achievement box across all three categories of pages.

Inclusion Criteria[edit]


In general, we only record placements at tournaments, not participation at tournaments. This means that only first, second, and third place results are recorded, with fourth place also being recorded if there is no determination between third and fourth and that semifinalist position is prized. All other results should go into a player's Results page, and, if possible, into the textual playing narrative in the respective player page.


Korean professionals[edit]

These player pages are where the only instance of the word Premier is acceptable. Premier tournaments for these players are the obvious set: OSL, MSL, and WCG. Everything else is major except special events tournaments.

Korean amateurs[edit]

As many of the players in the amateur leagues also fall into the above professional category, follow those criteria as applicable. The Sonic Starleagues are to be included in major tournaments.

Foreign players[edit]

Major events for this category of player pages include the following: TLS, TSL, ISL, and Defiler Tours. All other "for fun" and non-standard ruleset tournaments, such as the Gem League or no-ramp tournaments, as well as all showmatch series and special events, are minor.


  • Dates should be rendered in ISO format: YYYY-MM-DD
  • Use local time (the time zone applicable to where the tournament was held) for dates.
  • Render the games won versus games against section in logical format: subject player's wins to the left and listed opponent's wins to the right.
  • No player flags, only races, due to size constraints.
  • For matchfixers only, wins and placements stripped from them by KeSPA must be indicated as such through the use of {{Template:Placement}}.
  • Render winnings in the currency awarded to players, if applicable. Do not convert currencies.


The following are blank templates of the player achievement box that can be copy-pasted onto pages and filled out as necessary.

See also[edit]

The Manual of Style is a style guide for all Liquipedia articles.

The purpose of this manual is to provide a resource for Liquipedia editors, helping them produce articles with consistent, clear, and precise language, layout, and formatting. Consistency in language, style, and formatting promotes clarity and cohesion, something especially important in an educational and reference resource such as Liquipedia.

Standardized Liquipedia Conventions[edit]

National varieties of English[edit]

Although Liquipedia favors no national variety of English over any other, within a given article the conventions of one particular variety should be followed consistently. The exceptions to this rule are:

  • Quotations — do not alter a quotation to match the variety used in the main text of the article
  • Proper names — use the original spelling

Disputes over which English variety to use in an article are strongly discouraged. Such debates waste time and engender controversy, mostly without accomplishing anything positive. An article should not be edited or renamed simply to switch from one valid use of English to another.

Liquipedia tries to find words that are common to all varieties of English. Insisting on a single term or a single usage as the only correct option does not serve the purposes of an international encyclopedia.

  • Universally used terms are often preferable to less widely distributed terms, especially in article titles. For example, fixed-wing aircraft is preferred to the national varieties aeroplane (British English) and airplane (American English).
  • If one variant spelling appears in an article title, make a redirect page to accommodate the other variants, so that all variants can be used in searches and in linking.
  • Terms that are uncommon in some varieties of English, or that have divergent meanings, may be glossed to prevent confusion, for example, the trunk (boot in the U.K.) of the car was ...
  • Use a commonly understood word or phrase in preference to one that has a different meaning because of national differences (rather than alternate, use alternative or alternating depending on which sense is intended).

Tone and point of view[edit]


Liquipedia articles, and other encyclopedic content, should be written in a formal tone. Formal tone means that the article should not be written using unintelligible argot, slang, colloquialisms, doublespeak, legalese, or jargon; it means that the English language should be used in a businesslike manner.

Point of view[edit]

Articles should generally not be written from a first or second person perspective. In prose writing, the first person ("I" and "we") point of view and second person ("you" and "your") point of view typically evoke a strong narrator. While this is acceptable in works of fiction, it is generally unsuitable in an encyclopedia, where the writer should be invisible to the reader. Moreover, the first person often inappropriately implies a point of view inconsistent with neutrality.. First and second person pronouns should ordinarily be used only in attributed direct quotations relevant to the subject of the article.

Gender neutrality[edit]

Gender-neutral pronouns should be used where the gender is not specific.


When writing about things that have taken place in the past, stick to using the simple past tense.

Game-specific conventions[edit]


  • Names of buildings are to be upper cased, see:
Supply Depot, not Supply depot
Cybernetics Core, not Cybernetics core.
  • Unit names are to be upper cased, see:
Zealot, not zealot
Zergling, not zergling.
  • Compound expressions, such as Natural Expansion, Main Base, and Psi Storm, are to be upper cased when used as a proper noun. However, when used more casually and as a single word, they are to be in lower case, see: natural, main, and storm}.
  • Tech n. is to be upper-cased.
  • Races should always be in singular form and in upper case. For example: Protoss, Zerg, and Terran, not Zergs or terrans.
  • When giving the remaining Hit Points of a unit, use Hit Points, HP, or (sparingly) health. Do not use hp or hit points.
  • Two-word units can be compressed when unambiguous:
Siege Tank → Tank
but not: High Templar → Templar
  • Common names for upgraded units may be used, but sparingly: speed upgraded Zealots → Speedzeals, speed upgraded Zerglings → Speedlings, and so on. Do this, however, only in contexts where that upgrade bears importance.
  • For the sake of simplicity, we call groups of Marines, Marauders, and Medivacs MMM not mmm or m&m&m or 3M.
  • The upgrade status on units can be expressed in the format #A/#B unit, where #A is the level of armor upgrades and #B is the level of attack upgrades. For example: 3/3 Mauraders, or 1/3 Ultralisks.

Titling and Naming Conventions[edit]


  • Use the root name for maps when referring to them. Please remove all version related tags unless they are absolutely vital to the context in which you are using it.
    • Python 1.3 has four starting locations.
    • The cliffs on Lost Temple are an ideal place for the Terran to drop Siege Tanks.
    • Lost Temple 2.4 has been significantly altered to enhance game balance.


  • When referencing professional gamers, use their most common nickname. The most common nickname is that which is used the most by news posts on Team Liquid and other prominent sources, as well as that which is used most frequently and consistently by the organizers and casters of events.
  • Team tags should not be included due to the issues that arise if a player moves teams or changes their tag. An example, with WeRRa disbanding, all IDs with WeRRa in the name are out of date. With the arrival of name changes soon, clan IDs will change greatly while player IDs are more static. So for in line text remove all tags.


  • When referencing professional teams you may use abbreviations. If referring to the team multiple times in the same piece, try and alternate the names so that it does not become monotonous.
    • SKT, SKTT1 for SK Telecom T1.
  • In info boxes and titles, please use the complete name of the team.
    • Hwaseung Oz or SK Telecom T1


  • Do not upload images with generic titles, such as:
    • Raw image titles, with IMG_, IMGP_, SAM_, etc.
    • Image titles that are a random assortment of letters, numbers, or a combination of the two.
  • Do upload images with useful, descriptive, titles that nevertheless remain brief to allow their quick use on the wiki.

Style and formatting[edit]

Text formatting[edit]


The most common use of boldface is to highlight the article title, and often synonyms, in the lead section (the first paragraph in an article).

Use boldface in the remainder of the articles only in a few special cases:

  • Table headers and captions
  • Description (definition, association) lists
  • Mathematical objects traditionally written in boldface such as vectors and the rational numbers Q
  • Volume numbers of journal articles, in some bibliographic formats

In the first two cases, the appropriate markup automatically adds the boldface formatting; do not use the explicit triple-apostrophe markup. Similarly, in the last case, the formatting should generally be added implicitly by use of a template.


When to use[edit]
  • Court case names (Case citation or law report information is presented in normal font.)
  • Works of art and artifice
    • Books
    • Comic strips and webcomics
    • Computer and video games (but not other software)
    • Films (including short films) and documentaries
    • Paintings, sculptures and other works of visual art
    • Periodicals (newspapers, journals, and magazines)
    • Television and radio series and serials. Individual episodes of these should appear in quotes.
When not to use[edit]

Italics are generally used only for titles of longer works. Titles of shorter works should be enclosed in double quotation marks ("text like this"). This particularly applies to works that exist as a smaller part of a larger work. Examples of titles which are quoted:

  • Articles, essays or papers
  • Chapters of a longer work
  • Entries in a longer work (dictionary, encyclopedia, etc.)
  • Single episodes of a television series
  • Chinese characters

Dates and Time[edit]

Basic Guidelines[edit]

  • In templates and Infoboxes, we generally prefer the ISO dating scheme (YYYY-MM-DD).
See: 2012-03-05
  • In citations, DD Month YYYY is preferred.
See: 24 September 2011
  • Avoid the use of -th, -rd, -st modifiers to the date when the year is given.
use August 21, 2012
not August 21st, 2012.
  • Do not use year-final numerical date formats (DD/MM/YYYY or MM/DD/YYYY), as they are ambiguous: "03/04/2005" could refer to 3 April or to March 4. For consistency, do not use such formats even if the day number is greater than 12.
  • Yearless dates (5 March, March 5) are inappropriate unless the year is obvious from the context.
  • If a date range is abbreviated, use the formats 5–7 January 1979 or January 5–7, 1979 with an unspaced en dash. An unspaced en dash is also used for month or year ranges, such as June–August 1940 or the 1939–45 war. However, between two months and days, use a spaced en dash, such as June 3 – August 18 or June 3, 1888 – August 18, 1940. The space before an en dash should preferably be a non-breaking space.
  • 12-hour clock times end with dotted or undotted lower-case a.m. or p.m., or am or pm, preceded by a space (e.g. 2:30 p.m. or 2:30 pm, not 2:30p.m. or 2:30pm). Hours denoted by a single digit should not have a leading zero (e.g. 2:30 p.m., not 02:30 p.m.). A hard space (see above) is advisable (2:30 pm or 2:30 p.m.).
  • 24-hour clock times have no a.m., p.m., noon or midnight suffix. Hours under 10 should have a leading zero (e.g. 08:15). 00:00 refers to midnight at the start of a date, 12:00 to noon, and 24:00 to midnight at the end of a date, but should not be used for the first hour of the next day (e.g. use 00:10 for ten minutes after midnight, not 24:10).

Longer Periods[edit]

  • Months are expressed as whole words (February, not 2), except in the YYYY-MM-DD format. Unlike some other languages, the names of months and days of the week are capitalised in English. Abbreviations such as Feb. in the United States or Feb in most other countries are used only where space is extremely limited, such as in tables and infoboxes. Do not insert of between a month and a year (April 2000, not April of 2000).
  • Seasons
    • As the seasons are reversed in the northern and southern hemispheres—and areas near the equator tend to have just wet and dry seasons—neutral wording (in early 1990, in the second quarter of 2003, around September) is usually preferable to a "seasonal" reference (Summer 1918, Spring 1995). Even when the season reference is unambiguous (for instance when a particular location is clearly involved) a date or month may be preferable to a season name, unless there is a logical connection (the autumn harvest). Season names are preferable, however, when they refer to a phase of the natural yearly cycle (migration to higher latitudes typically starts in mid-spring). Seasons are normally spelled with a lower-case initial.
  • Years
    • Years are normally expressed in digits. Avoid inserting the words 'the year' before the digits (1995, not the year 1995), unless the meaning would otherwise be unclear.
    • Year ranges, like all ranges, are normally separated by an en dash, not a hyphen or slash: 2005–06 (unspaced) is a two-year range, whereas 2005/06 is a period of 12 months or less, such as a sports season or a financial year.
    • A closing year is normally written with two digits (2010–12) unless it is in a different century from that of the opening year, in which case the full closing year is given (1998–2012).
    • Ranges expressed using prepositions (from 2001 to 2006 or between 2001 and 2006) should not use en dashes (not from 2001–2006 or between 2001–2006).
    • To indicate around, approximately, or about, the abbreviation c. (without italics) is preferred over circa, ca, ca., approximately, or approx., and should be spaced (c. 1291). Do not use a question mark for this function (1291?), as this implies to a reader an uncertainty on the part of Liquipedia editors.
  • Decades
    • Decades as such contain neither an apostrophe nor the suffix -ies (the 1980s, not the 1980's, not the 1980-ies, and definitely not the 1980s'). The two-digit form is never used in reference to the decade as a time span per se.
A detailed map of global time zones and their UTC offsets

Time Zones[edit]

When writing a date and time, first consider where the event happened and use the local time zone there. For example, the date of the attack on Pearl Harbor should be December 7, 1941 (Hawaii time/date). If it is difficult to judge where, consider what is significant. For example, if a vandal based in Japan attacked a Pentagon computer in the US, use the time zone for the Pentagon, where the attack had its effect.

If known, include the UTC date and time of the event in the article, indicating that it is UTC. For example: 8 p.m. Eastern Standard Time on January 15, 2001 (01:00 UTC, January 16)

Alternatively, just include the UTC offset: 21:00 British Summer Time (UTC+1) on 27 July 2012

While the official time of Team Liquid and Liquipedia is Korean Standard Time (UTC+9), do not assume that all dates and times must be expressed in terms of KST. Similarly, do not assume that all times on the wiki must be expressed in any single, uniform, time zone at the expense of others.


Basic Guidelines[edit]

  • For numbers taken directly from Starcraft gameplay, use numerals.
    • When you have 300 minerals, build a Hatchery.
    • The Zealot does 8 damage each attack and it attacks twice in rapid succession.
  • For all other numbering up to ten, use their corresponding English words.
    • By this time the Zerg should have three Queens
  • For numbers above ten, use numerals once again.
    • Don't try to be a hero against a group of 24 Marines.
  • In tables and infoboxes, quantitative data should be expressed as numerals.
  • Numbers that begin a sentence are spelled out, since using figures risks the period being read as a decimal point or abbreviation mark.
  • The numerical elements of dates and times are not normally spelled out (that is, do not use the seventh of January or twelve forty-five p.m. or Two thousand eight was the year that ... ).
  • Sums of money should, generally, be expressed in numerals.
  • Common fractions for which the numerator and denominator can be expressed in one word are usually spelled out, e.g. a two-thirds majority; use figures if they occur with an abbreviated unit, e.g. 1⁄4 yd compared with a quarter of a yd.
  • Mixed fractions are usually expressed in figures, e.g. 2 1⁄4; however, the fractional part should always be consistent with the integral part, e.g. Nine and a half, and not Nine and 1⁄2
  • Percentages are usually written with figures, e.g. 10 percent or 10%.
  • Numbers in mathematical formulae are never spelled out (3 < π < 22/7, not three < π < 22 sevenths).
  • Do not use spelled-out numbers before symbols for units of measurement: write five minutes, 5 minutes, or 5 min, but not five min.
  • When both a figure and spelled-out named number are used in a quantity, it is useful to use a non-breaking space, as in 128 million to prevent a line break from occurring between them.


  • Spelled-out two-word numerals from 21 to 99 are hyphenated (e.g. fifty-six), as are fractions (e.g. seven-eighths). Do not hyphenate other multi-word numbers (five hundred, not five-hundred).
  • Where a whole number in a percentage is spelled out, the percent sign is not used (three percent, not three %).
  • The ordinal suffix (nd, rd, or th) is not superscripted (123rd and 496th, not 123rd and 496th).
  • The dot (.) or ordinal mark (º) should not be used as an ordinal suffix, except in direct quotations.


  • Numbers with five or more digits to the left of the decimal point (i.e. 10,000 or greater) should be delimited into groups so they can be easily parsed by using a comma (,) every three digits (e.g. 12,200, 255,200, 8,274,527). A full stop (.) should not be used to separate thousands (e.g. 12.200, 255.200) to avoid confusion with the decimal point.
  • Numbers with four digits to the left of the decimal point may or may not be delimited (e.g. 1250 or 1,250).
  • Numbers are not delimited when they are part of mailing and shipping addresses, page numbers, or years with four or fewer digits; years with five or more digits should be delimited (e.g. 10,400 BC).


Tournament Format Sections
  • Enumerate all numbers in these sections, rather than writing them out, in order to make the format of a tournament absolutely clear to a reader at first glance.

Units of measurement[edit]

  • 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.
  • In a direct quotation, always keep the source units. If a conversion is required, it should appear within square brackets in the quote, or else an obscure use of units can be explained in a footnote.
  • In places where space is limited, such as tables, infoboxes, and parenthetical notes, and in mathematical formulas, use unit symbols. In main text it is usually better to spell out unit names, but symbols may also be used when a unit (especially one with a long name) is used repeatedly. However, spell out the first instance of each unit in an article (for example, the typical batch is 250 kilograms ... and then 15 kg of emulsifier is added), except for unit names that are hardly ever spelled out (e.g. the degree Celsius). Most unit names are not capitalized. Use "per" when writing out a unit, rather than a slash: meter per second, not meter/second.
  • Potentially unfamiliar unit symbols should be introduced parenthetically at their first occurrence in the article, with the full name given first: for example, His initial betatron reached energies of 2.3 megaelectronvolts (MeV), while subsequent betatrons achieved 300 MeV.
  • When dimensions are given, each number should be followed by a unit name or symbol (e.g. write 1 m × 3 m × 6 m, not 1 × 3 × 6 m).
  • When they form a compound adjective, values and unit names should be separated by a hyphen: for example, a five-day holiday.
  • Unit symbols are preceded by figures, not by spelled-out numbers. Values and unit symbols are separated by a non-breaking space. For example, 5 min. The percent sign, and units of degrees, minutes, and seconds for angles and coordinates, are unspaced.
  • Standard unit symbols are undotted; non-standard abbreviations should be dotted. No s is appended, e.g. km, in, lb, not kms, ins, lbs.
  • Write powers of unit symbols with HTML, e.g. 5 km<sup>2</sup> not Unicode superscripts and subscripts.
  • For quantities of bytes and bits, specify whether the binary or decimal meanings of K, M, G, etc. are intended. The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are not familiar to most readers, and should not generally be used.


For your reference, see also: List of active currencies and their abbreviations
  • Use either the symbol of a particular currency, or its shortening (in capitals), not both.
    • $100, or 100 USD, not $100 USD or usd $100
    • €100, or 100 EUR, not €100 eur or EUR €100
  • Currency abbreviations that come before the number are left unspaced if they consist of or end in a symbol (£123, €123), and spaced if alphabetic (R 75).
  • Do place a space between the currency symbol and its shortening
    • 75 USD not 75USD
  • Unless the rules for the currency symbol allow for it, do not place the currency symbol after the value.
    • $20 not 20 $ or 20$
    • £20 not 20 £ or 20£
  • Format ranges with one, rather than two, currency signifiers ($250–300, not $250–$300).
  • For obsolete currencies, provide if possible an equivalent, formatted as a conversion, in the modern replacement currency (e.g. decimal pounds for historical pre-decimal pounds-and-shillings figures), or at least a US-dollar equivalent as a default in cases where there is no modern equivalent.
  • The names of currencies, currency subdivisions, coins and banknotes should not be capitalized except where normal capitalization rules require this (for example, at the start of a sentence).
  • When called on to use a plural with the euro, use the standard English plurals and not the "legislative" plurals (ten euros and fifty cents, not ten euro and fifty cent). In adjectival use, no plural form is generally used, but rather a hyphenated form: (a two-euro pen, a ten-dollar meal, a ten-cent coin).

Grammar Review[edit]

See Help:Manual of Style/Grammar

Image Use Policy[edit]

See also: A Liquipedia Guide to Copyright

Basic Points[edit]

Licensing and Permissions
  • Any image or file uploaded to this wiki must be accompanied with the permission or license of the copyright holder.
    • This permission or license must be sought before uploading, not after.
  • Sufficient file information must be appended to the file description to reflect the fact that permission has been granted or that the file was found to be available for use under a compatible licensing arrangement. This file information must also display suitable attribution to the creator and rights holder of the work in question.
  • In the very limited and narrow case of the fair use of non-free works, the formulation of a legitimate fair use rationale for the file's upload and use on the wiki is mandatory.
  • Files failing to meet these standards will be deleted.
Editorial Concerns
  • Images uploaded to this wiki must have a clear encyclopedic value
  • Use captions to clarify the relevance of any used image in an article
  • Images should be inside the major section to which it relates, not immediately above the section heading.
  • Avoid sandwiching text between two images that face each other, and between an image and an infobox or similar.
  • Multiple images in the same article can be staggered in position between right and left.
  • Textual information should almost always be entered as text rather than as an image.

Citation and Reference Guide[edit]

Main article for this topic: Citation and Reference Guide

Citations are an important part of any Liquipedia article, serving to identify the reliable sources on which the article is based. By citing sources for Liquipedia content, you enable users to verify that the information given is supported by reliable sources, thus improving the credibility of Liquipedia. You also help users find additional information on the subject; and you avoid plagiarizing the source of your words or ideas by giving attribution.

In most cases, citations for specific pieces of information contained in an article are given in the form of footnotes, though they can also appear within the body of an article. Citations indicated by a superscript number or other means in a line of text are called inline citations. Liquipedia requires inline citations for any material challenged or likely to be challenged, and for all quotations, found anywhere in article space. Editors are advised to provide citations for all material added to Liquipedia; any detail risks being unexpectedly challenged or even eventually removed. Citations are especially desirable for statements about living persons, particularly when the statements are contentious or potentially defamatory


  • All statements and claims made on the wiki should be cited.
    • In particular, it is imperative that these things be cited on Liquipedia:
      • Controversial claims that are subject to challenge
      • Statements made about people and organizations
      • Quotations and attributions
  • In their most basic form, a citation should include:
    • The name of the author or party responsible for the content
    • The date on which the source was published
    • Information facilitating retrieval and review of the source material
  • Citations should:
    • Originate from reliable sources
    • Be readily accessible to others
    • Be regularly audited for accuracy and currency

External Links and Bibliography[edit]

Wiki Resources[edit]

Style Guides[edit]