GeezerVison

There is a special set of templates used for formatting glossary content. The templates are:

• {{glossary}} – this template is used at the beginning of a block of glossary entries
• {{term}} – this template sets the size and font style (bold) for each term
• {{defn}} – this template provides the formatting for the term's definition prose.
• {{glossary end}} – this template ends the block of glossary entries

Nearly all stand-alone, and most embedded, glossaries are good candidates for the template-structured format. Here's what the format looks like:

==A–M==
Optional introductory text.

{{glossary}}
{{term |1=term A}}
{{defn |1=Definition of term A}}
{{term |1=term B}}
{{defn |no=1 |1=First definition of term B.}}
{{defn |no=2 |1=Second definition of term B.}}
{{glossary end}}

This formatting style produces cleaner and richer XHTML output from Wikipedia's MediaWiki software engine, and uses standard HTML elements specifically intended for glossary markup. It provides many benefits, and the syntax does not take long to learn. Glossaries using this style:

• Are more accessible to those using screen readers, which is important for Wikipedia
• Have directly linkable entries and other editorial benefits (with a simplicity tradeoff), such as code consistency
• Enhance Wikipedia's application richness and usability, and make glossaries easier to parse and re-use in various ways by third-party applications
• Use semantic HTML, improving reusability of Wikipedia content by both software and people
• Will validate as both correct XHTML and HTML, ensuring the broadest browser compatibility (see #Technical notes for why this is important)
• Are technically well-formed XML, another compatibility factor
• Can be extended consistently, e.g. to include metadata, or to specially style terms and definitions
• Will be easier to reconfigure if Wikipedia decides to change site-wide formatting, as it often does.

To produce a template-structured glossary, follow these simple steps:

1. The glossary as a whole (or each part, if broken into sections, e.g. "A–M") is surrounded by a {{glossary}} template and a corresponding {{glossary end}} tag.
2. A term is given on its own line using the {{term}} template, and is automatically boldfaced.
3. A definition is next given on its own line using the {{defn}} template, and follows either the term or a previous definition.

Do not make individual terms in a template-structured glossary into headings. Doing so will produce garbled output. The terms will be linkable without being headings.

Use the templates as a set, and do not mix-and-match glossary templates with wikimarkup description list code (; and : style) or other markup.

If a glossary consists of only a few entries, with lengthy definitions, consider instead formatting the article as a subheading-style glossary, in regular paragraphs.

==A–M==
Optional introductory text.

{{glossary}}
{{term |1=term A}}
{{defn |no=1 |1=
Beginning of the definition of term A.
<p>More of the definition of term A.</p>
}}
{{term |1=term B}}
{{defn |no=1 |1=First definition of term B.}}
{{defn |no=2 |1=Second definition of term B.}}
{{term |1=term C}}
{{defn |1=Simple definition of term C.}}
{{term |1=term D}}
{{defn |1=Definition of term D, with a...
{{quote|Block-quoted passage.}}
More definition of term D.
}}
{{glossary end}}

{{glossary}}
{{Main|Hatnotes and other templates can't go here, inside the glossary list but before terms and definitions}}
{{term|1=term A}}
[[File:misplaced_image.png|thumb|right|300px|This image cannot be between the term and definition like this.]]
{{defn|1=Definition of term A.}}
{{term|1=term B}}
{{defn|no=1|1=First definition of term B.}}
<blockquote>Between definitions is no place for a quotation or anything else.</blockquote>
{{defn|no=2|1=Second definition of term B.}}
<p>A paragraph (or whatever) can't be between entire entries, without {{glossary end}} to close the glossary before the content and a new {{glossary}} to open glossary formatting again after that content being interpolated.</p>
{{term|1=term C}}
{{defn|1=Definition of term C.}}
{{glossary end}}

This is the simplest style used for glossaries. It is an application of a bulleted list. Example, with definitions next to terms:

==Glossary==

Optional introductory text.

* '''term A''' – definition.
* '''term B''' – 1. First definition.  2. Second definition.

This easy style is often used in embedded glossaries. Numbered lists (beginning with # instead of *) should not be used, as they imply a specific (e.g. hierarchical or chronological) order.

Complex glossaries are best done using template-structured format.

Blocks of text, properly marked up, can be used for longer definitions. Multi-paragraph definitions require the HTML <p>...</p> paragraph markup, without any wikimarkup whitespace between either of the passages and the break, due to MediaWiki limitations (see Wikipedia:Manual of Style/Glossaries/DD bug test cases for technical details). The <p>...</p> markup is required both before and after the break or the line spacing will be noticeably inconsistent. Example, with definitions below terms:

==Glossary==

Optional introductory text.

* '''term A''' {{pb}} Definition.
* '''term B''' {{pb}} 1. First definition. {{pb}} 2. Second definition.
* '''term C''' {{pb}} Beginning of long definition. {{pb}} Continuation of long definition. {{pb}} Conclusion of long definition.

Explicit <p>...</p> elements can also be used instead of the {{pb}} template, e.g.:

* '''term A''' <p>Definition.</p>
* '''term B''' <p>1. First definition.</p><p>2. Second definition.</p>
* '''term C''' <p>Beginning of long definition.</p><p>Continuation of long definition.</p><p>Conclusion of long definition.</p>

Remember to use the closing </p>.

Don't mix-and-match this unordered list markup with that for ordered or definition lists, as the output will be invalid markup, and the visual formatting will not be consistent (ordered and unordered lists indent further). Compare:

* '''term A'''
: Definition
* '''term X'''
: 1. First definition.
: 2. Second definition.
* '''term Y'''
# First definition.
# Second definition.
* '''term Z'''
** First definition.
** Second definition.

The HTML output of this is a trainwreck, especially for visually impaired users of screen-reader software, who are told, in series, that: an unordered list of one item has started; that list has ended; a description list with no term but one unassigned definition has started; that list ended; another unordered list of one item started, and ended; another description list with no term but two definitions unrelated to a term started, then ended; a third unordered list of one item started, and ended; a numbered list of two items, unassociated with the above material, started and ended; a fourth unordered list of one item started, then an embedded unordered list of two items started, then both ended. There is generally no clear relationship between any of the terms and definitions, or even a sense that this is one list of things that relate to each other in any way.

Stand-alone glossaries with a limited number of mostly long and detailed definitions sometimes can be formatted best with entries as subheadings. One example of such a glossary is Glossary of ancient Roman religion. This style should not be used for embedded glossaries, as it will overwhelm the article's table of contents with glossary entries. It will also produce an overly-long ToC in a stand-alone glossary with a large number of entries. When this style is used, definitions are presented as normal prose paragraphs:

==A–M==

Optional introductory text.

===term A===

Definition.

===term B===

1. First definition.

2. Second definition.

For cases in which most or all of the definitions are long, multi-paragraph explanations, this format is actually preferable to a template-structured glossary.

Multiple definitions are numbered manually, as shown; do not use ordered lists. This glossary type especially sometimes uses non-numeric identifiers with multiple definitions. Multi-paragraph definitions are just like any other Wikipedia prose paragraphs.

==A–M==

Optional introductory text.

===term A===

Definition.

===term B===

''[[Chemistry]]'': First definition.

More of first definition.

''[[Economics]]'': Second definition.

''[[Underwater basketweaving]]'': Third definition.

The underlying <dl>, <dt>, and <dd> HTML elements (as generated in a template-structured glossary), are also what are output by wikicode lists formatted with initial ; and : characters. (See Wikipedia:Manual of Style/Lists § Description (definition, association) lists for details.)

This markup style is very "brittle" and not recommended for glossaries, except of the shortest and simplest sort, as they are likely to have their semantic structure broken. Even something as simple as a blank line will break such a list. (See § Avoid semicolon-and-colon wikimarkup for glossaries, below.)

==Glossary==

Optional introductory text.

; term 1
: Definition
; term 2
: 1. First definition.
: 2. Section definition.

In a glossary, alphabetize all the terms from A to Z. Entries must not be added randomly or in an arbitrary order. A Latin-based character with diacritics is alphabetized after the plain character it is based on. Non-Latin-based characters are alphabetized in order of their appearance in Unicode.

If numeral entries are present, they precede verbal ones, and any symbolic entries precede both (i.e.: "!" before "1" before "A"). Numeric entries that sometimes appear in the article subject's context as either numerals or spelled out verbally should be given in the form "three (3)" in short glossaries. In longer ones, it is more appropriate to create separate entries, put the definition in one, and crossreference the other entry to that one; put the definition in the verbal not numeral entry in most cases. If there is a definable difference in usage between the numeral and verbal terms in the context, use separate entries and distinguish between them with crossreferences.

If there are no symbolic and only one or a few numeral entries, it is permissible to alphabetize the numeral entries as if they were spelled out verbally, in the form "3 (three)", to avoid creation of a very short numeral entries section.

Make a separate section (or subsection) in a long stand-alone glossary article for each letter, but group them into ranges when appropriate, e.g. "X–Z". For shorter stand-alone glossaries, you may divide the entire article into ranges, e.g. "0–9", "A–M" and "N–Z", or use no divisions at all for very short cases (which may be candidates for merging into main articles on the subject). Do not section an embedded list, as this impedes editing and may greatly lengthen the overall article's table of contents; if an embedded list is long enough that it would benefit from sectioning, it is a good candidate splitting into a separate stand-alone glossary article. Do not create empty sections.

In most glossaries, begin each glossary term with a lower-case letter, unless it is a proper name or an acronym/initialism. While capitalizing the first letter of each term would produce a more uniform, outline-like result (which is why this is the standard for ordered and unordered lists on Wikipedia), natural capitalization produces fewer ambiguities in a glossary.

The use of leading capitals on all entries is recommended only if all of the following apply simultaneously:

• No term in the glossary is a lower-case form of something that in other contexts is usually capitalized
• There is no difference between the capitalized and uncapitalized form of any term in the glossary
• The terms do not contain a mixture of proper names and common nouns
• Capitalizing all entries is otherwise unlikely to produce any form of ambiguity or confusion.
• The glossary is unlikely to ever expand in a way that will break one of the above cases (i.e., it is either already exhaustive, is strictly limited by narrow inclusion criteria, or exclusively contains proper names).

Begin each definition with a capital letter, even if it is a sentence fragment.

The above does not apply to the use of description lists (with or without glossary templates) for material that does not form a glossary, such as list of characters, or an index of different models in a series of products.

Wikipedia is not a dictionary; correspondingly, explain glossary terms descriptively (just like a regular encyclopedia article would do it, but more concisely). Only rarely and sparingly add dictionary definitions to a glossary on Wikipedia (usually solely for the sake of completeness). Lists of dictionary definitions belong on Wiktionary; you can still link to them from Wikipedia articles.

Do not add everyday words. Include only specialized terms specific to or having a special meaning within the subject of the glossary.

All entries must be verifiable with reliable sources, just like regular article content.

The Wiktionary glossaries appendix project is likely to transwiki a copy of any glossary created on Wikipedia, and could considerably re-develop it in a more dictionarian direction. It is not necessary (and may be detrimental) to synchronize edits between the two versions, though it will be rare for an entry to be appropriate to exist at all in some form in only one version but not the other. The existence of a Wiktionary glossary on a topic that has a well-developed main article may be a good indication that an encyclopedic glossary on the subject may be developed, either using the dictionarian glossary as a base, or starting from scratch. If both versions do exist they should link to each other in their respective "See also" sections with a sister-project template, e.g. {{Wiktionary|name of page at Wiktionary}} (see Wikipedia:Wikimedia sister projects for recommendations about the best choice of template for various situations).

One definition can actually have two or more terms above it as variations or alternatives with the same definition. The most common use case for this is presenting the term in two language variants. This is done with {{lang}} and the appropriate ISO language codes as described at that template. In template-structured glossaries, the bare term, without markup, must be the first parameter of {{term}}, and the language-markup version is parameter 2. If display of the language/dialect name is desired, {{langx|language-code}} can be used instead of {{lang}}. Example:

{{term|1=tire |content={{langx|en-US|tire}}}}
{{term|1=tyre |content={{langx|en-GB|tyre}}}}
{{defn|1=A resilient wheel covering usually made of vulcanized rubber.}}

Result:

American English: tire

British English: tyre

A resilient wheel covering usually made of vulcanized rubber.

The wikimarkup version is leaner, but has very limited functionality and cannot handle complex input:

;{{langx|en-US|tire}}
;{{langx|en-GB|tyre}}
:A resilient wheel covering usually made of vulcanized rubber.

In a Wikipedia article, use consistent identifiers for two or more definitions of a term. In most cases, multiple definitions should be numbered. Other conventions exist, such as identification of the sub-field to which each definition pertains, but these are rarely mutually exclusive with numbering, and numerical identification is a convenient mnemonic for readers and referent for editors. Because articles may use numbers to distinguish among multiple definitions, avoid changing the order of definitions without good reason, and correct numerical references to definitions when you do change their order.

Avoid using description list wikimarkup (with ; and :) for glossaries, as it is severely limited and buggy. While such lists are okay for very casual indented list creation, the MediaWiki software does not handle complex definitions gracefully in this format, or permit blank lines between items without ruining the semantic markup. Existing examples should be converted to template-structured glossaries, since most of the work is already done.

Use a glossary style defined above, not your own made-up formatting, such as a pseudo-list created with manual styling, or misuse of a numbered (ordered) list. We have list-formatting standards for several reasons, and failure to follow them may confuse readers and editors, hamper reusability of Wikipedia content, make automated processing more difficult, and introduce usability and accessibility problems.

In some cases, tables are better-suited to associating content than description lists, especially when there are multiple values for each item.

Glossary articles are expected to satisfy the same conditions as other articles; this will include a well-developed lead section, and references.

The default Wikipedia table of contents will not be very useful with most glossaries. One solution is:

__NOTOC__{{Compact ToC|center=yes|symnum=yes|refs=yes}}

or, if there are only alphabetical entries from A to Z, simply:

__NOTOC__{{Compact ToC|center=yes|refs=yes}}

There are a number of variants; see the documentation for Template:Compact ToC.

Please note that the section headings must be created manually, as usual, and must exactly match the selected {{Compact ToC}} parameters.

Each section in a lengthy glossary page should terminate with another call to {{Compact ToC}} (or some other form of concise sectional navigation). Compact ToC can be used with various other parameters enabled to keep the display thin and linear and with a link to the top of the page, e.g.:

{{Compact ToC|side=yes|center=yes|top=yes|symnum=yes|refs=yes|nobreak=yes}}

Depending upon the {{Compact ToC}} parameters set, there may be a section for entries beginning with numerals, with symbols, or both. If present, this section should precede "A" or whatever the first alphabetic section is ("A–M", etc.) Entries that are commonly but not always found in numeric form should be given in this section and cross-referenced to it from its spelled-out name, or vice versa, not given duplicate definitions. Cross references are italicized. Example:

{{term|1=20 Tanks}}
{{defn|''See [[#Twenty Tanks|Twenty Tanks]].''}}
...
{{term|1=Twenty Tanks}}
{{defn|''Also '''20 Tanks'''.'' Twenty Tanks was an award-winning micro-brewery in San Francisco, California, and a sister enterprise to the Triple Rock brewery in Berkeley.}}

For a glossary list article that consists of a simple lead and a glossary, the form Glossary of subject terms is preferred, with redirects to it from Glossary of subject, Subject terms, Subject glossary, Subject terminology, Subject jargon, Subject slang, and List of subject terms (the last one to comply with the more general naming convention of lists pattern of "List of subjects").

For an article that mostly consists of a glossary list but has well-developed prose material on the history and use of the terminology, or other such information (several paragraphs worth), the form Subject terms is preferred, with redirects to it from Glossary of subject terms, Subject glossary and the other names (remember that reader cannot guess whether or not the article has been developed in this way). The links from the "glossary"-named redirects may go directly to the glossary section, if the historical and other material is lengthy. For an article that is mostly on the history, development, spread, etc. of the terminology as a body of a certain subject area's jargon (like legal, dance, etc., terminology generally), and may include an embedded glossary of key terms, prefer Subject terminology, again with all the redirects. It is reasonably likely that such an article will eventually split into a prose article and a stand-alone, more developed, glossary article over time.

For a glossary of terms and characters used in a work or series of works of fiction (i.e. a fictional universe), the form Glossary of work/series/franchise name terminology is preferred (again with redirects) since the terms form a terminological system that does not exist as terms in use outside that fictional context. Example: Glossary of His Dark Materials terminology.

The general advice at WP:Stand-alone lists#Naming conventions (e.g. handling of nationalities, fictional subjects, etc.) includes glossaries as well, to the extent applicable.

The sub-articles of multi-page split glossaries should follow the guidelines at WP:Naming conventions (long lists) to the extent applicable. In short, they should be named as the original (main) glossary page, with the letter or range of covered letters of the alphabet (or numbers, etc.) following a colon after this title, e.g. Glossary of underwater basketweaving terms: A–M or Curling terms: N–Z. Per WP:Manual of Style#Dashes, the en-dash (–) is used to divide the range, not a hyphen (-), em-dash (—), minus (−) or other similar character; however, the hyphenated form of the article name (e.g. Curling terms: N-Z) must also exist as a redirect to the real article page (AnomieBOT will do this automatically). Type the en-dash in as – or click on it to the right of the "Insert" tab under the edit window; or see How to make dashes.

Specialized glossaries may require a different sort of name (including for multi-part glossaries' sub-articles), e.g. Glossary of computing terms: Unix and Linux, Glossary of computing terms: Microsoft Windows, etc.

See the "Embedded glossaries" and "Using glossary formatting in non-glossary lists" sections, below, for related naming issues.

A glossary that becomes too long (more than about 400 KB)^[a] should be split into multiple articles. This is a higher suggested limit than for normal articles, because we generally do not expect readers to work their way through a glossary from head to tail, so their length need not be limited by attention span, and a glossary's primary purpose is linking to specific entries and, crucially, in-page searching, which is broken by splitting. On the other hand, very large articles take a longer time to load, especially for editing or previewing.

When necessary, glossaries should usually be split into roughly equal chunks, rather than attempting to convert to summary style, or thinning out by narrowing the subject of the glossary. For example, the first split of Glossary of underwater basketweaving terms could be into Glossary of underwater basketweaving terms: A–M and Glossary of underwater basketweaving terms: N–Z, but very long glossaries may need even more parts, and some glossaries will have some one letters' sections much longer than others. If there are terms beginning with numbers or symbols, they should go before A, in sections of their own, unless there are enough of them to warrant their own subarticle.

There are two good solutions for the original Glossary of underwater basketweaving terms title:

• Have it redirect to the first chunk, and include the original lead there.
• Have it as a disambiguation page, with a full lead, and links to all the chunks.

In either case, the other chunks should have summaries of the full lead, so that multiple different leads do not evolve. The first method is simpler; the second is preferable for glossaries so long that they need more than three or four chunks, or list articles in glossary format but not in basic alphabetical order (bicycles by manufacturer, wars by year, etc.).

Care is needed in dividing glossaries into subarticles. Each subarticle must link with the ones before and after, and to the disambiguation page if there is one; {{Compact ToC}} can help with this. Each sub-article must have its own references section, and these should be checked to be sure they still work. In particular, the first instance of a named <ref> tag in each subarticle will need its own text and cannot simply be a <ref name="ref-name" /> secondary ref call. The name= name for the same ref should not change from subarticle to subarticle.

For the technically minded, the following is an explanation of the actual HTML markup that will be rendered from the templates by the reader's browser (not counting various classes and other details that are supplied automatically by the MediaWiki web application, and with spacing cleaned up a little for human readability). The code validates, is structurally well-formed, and is semantically correct.

1. {{Glossary}} and {{Glossary end}} together invoke the <dl>...</dl> description list HTML structure (called a definition list in HTML 4, and sometimes also called an association list); the "dl" shortcut is not available at this time, unfortunately
2. {{Term}} a.k.a. {{dt}} invokes the <dt>...</dt> description list term HTML element, with an embedded <dfn>...</dfn> defining instance of term element
3. {{Defn}} a.k.a. {{dd}} invokes the <dd>...</dd> description list definition element

Example wikicode:

{{glossary}}
{{term |term A}}
{{defn |Definition 1.}}
{{term |term B}}
{{defn |no=1 |First definition start.
<p>First definition conclusion.</p>
}}
{{defn |no=2 |Second definition.}}
{{glossary end}}

HTML represented (minus the CSS):

<dl>
<dt id="term_a"><dfn>term A</dfn></dt>
<dd>Definition 1.</dd>
<dt id="term_b"><dfn>term B</dfn></dt>
<dd>1.&#160;&#160;First definition start.
<p>First definition conclusion.</p>
</dd>
<dd>2.&#160;&#160;Second definition.</dd>
</dl>

<dl class="glossary">
<dt id="term_a"><dfn>term A</dfn></dt>
<dd>Definition 1.</dd>
<dt id="term_b"><dfn>term B</dfn></dt>
<dd class="glossary">1.&#160;&#160;First definition start.
<p>First definition conclusion.</p>
</dd>
<dd>2.&#160;&#160;Second definition.</dd>
</dl>

Rendered output:

term A

Definition 1.

term B

1.  First definition start.

First definition conclusion.

2.  Second definition.

The result is the same if you put the entire {{defn}} of term B on one line, as long as <p>...</p> markup is used to introduce the paragraph break in the definition:

{{defn|1. First definition start.<p>First definition conclusion.</p>}}

That is to say, the following mixture of HTML markup and MediaWiki markup, trying to use simple whitespace to create a paragraph break, no longer works inside <dd>...</dd> (and thus {{defn|...}}), as of 2023 (and since around 2014):

{{defn|
1. First definition start.

First definition conclusion.
}}

The result will be run together in the output:

1. First definition start. First definition conclusion.

This behavior is consistent with MediWiki failing to auto-paragraph inside other inline-block elements, including <blockquote> and <li>. (Inline-block elements are those block elements that in WHATWG's recommendations, i.e. in pretty much every modern browser, default to a CSS value of display: inline-block;.)