Wikipedia talk:Manual of Style/Glossaries

Manual definition lists / Hierarchical Non–glossary lists / Non–Non–structured lists

Resolved

 – (Apparently.) Mostly moot; one issue is  Won't fix; any others lost in the TL;DR.

Regarding §Non-glossary lists using glossary formatting and §Actual XHTML output of structured glossaries, a few are things are confusing, perhaps until WP:LIST#Definition lists gets updated? I'm not sure if the plan is to keep "Non-glossary lists" in other sections of this article... Because {{term}} & {{defn}} insert class=glossary It would seem that "manual" HTML is currently the only way? (I find it easier any way). The article makes "wikimarkup equivalent, the leading ;" sound scary. Also, because the output is the same, it's unclear why {{term}} should not be used.

The {{term}} template should only be used for actual glossaries. For non-glossary lists that simply use glossary formatting, use a bare <dt>...</dt> structure, or its wikimarkup equivalent, the leading ; character:

  {{gloss}}
  ;term 1
  :Definition of term 1.
  {{glossend}}

Shouldn't it be this?

  {{gloss}}
  {{term|term 1}}
  {{defn|Definition of term 1.}} 
  {{glossend}}

Or this? (per class≠glossary)

  <dl>
  <dt id="term 1">term 1</dt>
  <dd>Definition of term 1.</dd>
  </dl>

Somehow, I got the impression a linkable anchor would be automatically inserted when using <dt>...</dt> so that it's equivalent to {{term}}. It seems I got confused, (it's not automatic). Using span tags are mentioned but they don't seem to work inside a <dt>...</dt>, so maybe it should recommend adding an id attribute? (or the {{anchor}} template, if possible, and more than one link target is required)?

Possibly in §Technical notes it should mention that it's not referring to the "manual" HTML markup in item 4, (unless it's somehow related):

4. Forthcoming: When a known MediaWiki bug is fixed, so that the [X]HTML element <dfn> is properly supported, the {{term}} template will also identify the term as the defining instance of its usage in the page.

In the §lead, second paragraph, should it read?

Glossaries can be formatted in a structured, non-structured or manual html manner, each of which can appear much the same to the human reader. Glossaries can be stand-alone list articles or embedded in-article list sections; either may be structured non-structured or manual html. (Glossaries can constructed as flat list or hierarchically as well). There are thus six (or twelve) basic types of glossary on Wikipedia. Regardless of the type selected, there are guidelines for making them useful, consistent, reader-friendly, and editor-friendly. There are also rationales for selecting which type to use.

I just wanted to touch on one last thing in §Alphabetization, is it necessary to dictate "Alphabetize term entries from A to Z"? Hierarchical lists, for example, might not necessarily be sub–sorted alphabetically at each level, and the hierarchy itself could be informative for the reader—without insisting on strict determinism for each of its parts. WP:LIST#Definition lists seems to be a little more circumspect. One hopes the order in which a flat glossary should be sorted could go without saying... Machine Elf 1735 (talk) 10:06, 2 August 2010 (UTC)

1. Most of this is moot, due to more recent major editing.
2. If someone wants a generic version of the template with no class parameter or a different value because they don't like the style applied by class="glossary" (which is none at all; it's simply reserved), they can copy the code, paste it into Template:Dl-dl, and take out/change the class, and do the same with matching Dl-dt and Dl-dd templates if they want. There's no reason to make the glossary template either more complicated or dumbed down.
3. If there are other out-standing issues, please raise them in new threads, one issue at a time, not in a long post raising multiple issues, or my asplode (not that I personally WP:OWN this stuff, of course, but I wrote 95% of it, and understand it better than anyone else, both as to the tech and as to the purposes, so if there's a problem it'll probably be me fixing it). — SMcCandlish   Talk⇒〈°⌊°〉 Contribs. 00:00, 12 February 2012 (UTC)

Why would “someone want a generic version”? “because they don't like the style ... which is none at all” in other words, you want people to copy a bunch of your templates for no particular reason… I agree, that can neither more complicated nor dumb. Could there be any doubt you “understand it better than anyone else”? No, no problem that I'm aware of requires you to be fixing it. Certainly, henceforth, I shall provide each WTF individually, as you require. How gracious that years later you've called my attention to the fact that until now, you completely ignored it. Indeed, TL;DR is moot, and fair enough, the “asplode” of TL;DR barely covered 5% of the page's preaching, confusion and lousy advice. But my apologies, how presumptuous: you're on the dispensing end of the advice.—Machine Elf ¹⁷³⁵ 12:59, 12 February 2012 (UTC)

Taking advantage of semicolon-colon Wiki markup

Resolved

 – MediaWiki's parser is badly broke on this; the italics problem has been fixed at MediaWiki:common.css.

Bravo on these efforts to standardize glossaries and make them accessible. I have one suggestion, however: doesn't it make sense to take advantage of the nifty Wiki markup for association lists as much as possible? The semicolon-colon markup does almost everything we want it to do here, as long as the "terms" get wrapped with <dfn>..</dfn> tags. Thus, for example, the following Wiki markup:

;{{term|term 1}}
:Term 1 definition
;{{term|term 2}}
;{{term|alternate term 2}}
:Term 2 definition 1
:Term 2 definition 2

renders, upon parsing by MediaWiki (assuming that the "term" template simply wraps <dfn>..</dfn> tags around the term:

<dl>
<dt><dfn>term 1</dfn></dt>
<dd>Term 1 definition</dd>
<dt><dfn>term 2</dfn></dt>
<dt><dfn>alternate term 2</dfn></dt>
<dd>Term 2 definition 1</dd>
<dd>Term 2 definition 2</dd>

which is a perfectly accessible HTML 4/5 association list. In fact, the <dfn> tag is so unobtrusive, that I don't think it is asking too much of editors to simply do the following, to the same effect:

;<dfn>term 1</dfn>
:Term 1 definition
;<dfn>term 2</dfn>
;<dfn>alternate term 2</dfn>
:Term 2 definition 1
:Term 2 definition 2

which is almost as simple as using the template format. All the matters of style could be handled in MediaWiki:common.css or any of the various skins. If we want to present the glossary in a particular style, it could be wrapped in the "gloss" template, and then styled in the css style sheets. For example, the style sheet could define an html class in which the terms are on the same line as the definitions. That way, the styling is completely separated from the content, and different Wikipedia skins can present the glossaries differently.

By the way, now that the <dfn> tag is recognized by Wikipedia, I have just added some default styling for the tag in common.css. As it now stands, adding a <dfn> tag within the <dt>...</dt> tags of an association list does not change the default styling, which is bold, no italics. In other words, including the <dfn> tag to designate the "names" in an association list as being a "defined term" does not unexpectedly convert the terms to bold italics. COGDEN 19:54, 4 May 2011 (UTC)

I spoke too soon. The formatting I added to common.css is apparently controversial (at least for now), and has been removed. The consequence of this is that <dfn>-tagged terms within glossaries will show up as bold italics in Internet Explorer, Firefox, Opera, and Safari, but will show up as just bold in Chrome. This happens if you use the "term" and "defn" templates as well. If that's not what you want, then please speak up at MediaWiki:common.css. COGDEN 03:01, 10 May 2011 (UTC)

See Wikipedia:Manual of Style/Glossaries/DD bug test cases; the entire point of all this templating is that MediaWiki's parser is badly broken when it comes to ;/: markup. I have no idea what they're doing with making <dfn>...</dfn> do weird stuff; it shouldn't have any style whatsoever, it's pure semantic metadata. I've used {{dfn}} to undo this with local style, and this fix propagates to {{term}}. I've filed an editprotected at MediaWiki:common.css to permanently fix the italics problem. — SMcCandlish   Talk⇒〈°⌊°〉 Contribs. 23:28, 11 February 2012 (UTC) Update: The italics fix is now in common.css. — SMcCandlish   Talk⇒〈°⌊°〉 Contribs. 23:33, 16 February 2012 (UTC)

<Dfn> support

Update (8 May 2011): Now that a known MediaWiki bug has been fixed in Wikipedia's software engine, and the HTML element <dfn>...</dfn> is properly supported, the {{term}} template will now also identify the term as the defining instance of its usage in the page, as en.wikipedia has in fact installed the upgraded version of MediaWiki. (This update was moved here from WP:Manual of Style/Glossaries#Technical notes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:50, 19 October 2014 (UTC))

Revamp begun

I've begun simplifying the instructions, focusing them on the 3 styles of glossary format. I've shortened the styles' names, for easier reading. I've removed the term "structured", so it won't get confused with the phrase "structured list", which refers to outlines.

I've removed a lot of redundancy from the page, but there is still a lot more in there. Sometimes things are explained 2 or 3 times.

For some unknown reason, the Terminology section (an embedded glossary) wasn't following the guideline. It does now.

My eyes have glazed over, so I'll give it a rest for a day or two and will return to continue copy editing for clarity and conciseness.

We need to get some proofreaders to critique it, preferably some who have never built glossaries before. The Transhumanist 04:32, 1 February 2012 (UTC)

I put a few snippets back in because they're important for reasons that may be orthogonal to your concerns, but overall agree with the changes, and it's nice to have someone else paying attention, as well as adding stuff I didn't think about, like material on the Outlines. Not sure how I feel about losing things like "the importance of getting basic information into an article and sourcing it greatly exceeds any formatting considerations", etc., but have left all that out. The stuff I put back was largely technical or in a few places things like "If a glossary consists of few entries, all with lengthy definitions, consider instead formatting the article as a subheaded-style glossary, in regular paragraphs.", because it isn't safe to assume that everyone will read the entire page top-to-bottom, so it needs sectional cross-references. PS: Nice edit summaries, too; helped me grok what you were doing and why. — SMcCandlish   Talk⇒〈°⌊°〉 Contribs. 22:55, 11 February 2012 (UTC)

All glossary templates nominated for deletion

Resolved

 – TfD closed as keep.

Please see WP:Templates for discussion/Log/2014 October 22#Glossary templates (and the related WP:Templates for discussion/Log/2014 October 20#Template:Gbq), as the outcome will strongly affect MOS:GLOSSARIES.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:04, 22 October 2014 (UTC)

Categorization of glossary terms

Some glossaries have an accompanying category (e.g., Glossary of geology and Category:Geology terminology). Other glossaries don't have a matching terminology categorization; conversely, some categories of terms don't have a glossary yet. Can we come up with some guidance on this? Making a good categorization is a good way for preparing the field for a future glossary. Even the naming is not uniform: sometimes it's "terms" other times it's "concepts", etc. Fgnievinski (talk) 07:07, 7 January 2015 (UTC)

@Fgnieinski: Agreed. Did you have some specific wording to suggest?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:15, 10 July 2016 (UTC)

Naming convention change request

A glossary is by definition a list of terms. So, the title "Glossary of education terms" is redundant, because it means a "list of terms of education terms".

At least for some of the glossaries, they started out as "List of subject terms", and when they got renamed to glossaries, the word "terms" was inadvertently left in the title.

Also, a glossary is essentially a dictionary that is part of a book, rather than a stand-alone book. A dictionary is a collection of terms. So, "Dictionary of psychology terms" would be redundant. Therefore, in the publishing field, "Dictionary of Subject" is standard. It should be the same for glossary titles (except that on Wikipedia, the subject isn't capitalized unless it is a proper noun).

Therefore, I request we change the standard naming convention for glossaries from "Glossary of subject terms" to "Glossary of subject", except when that wording would be awkward (such as "Glossary of Asteraceae"). The Transhumanist 13:04, 10 November 2015 (UTC)

IMHO, it is not redundant. Suppose there were two glossaries of photography terms, one with modern terms and one with historically common ones (presumably still needed in articles about old cameras and old photography practices). I would want "Glossary of photography terms" and "Glossary of historical photography terms" (maybe there is a better word than "historical"). The terms are what's historical, not the photography.

More importantly, the terms are what's being glossed. Many books say "Glossary of Terms", not just "glossary". It's true that glossaries on Wikipedia will usually be glossaries of technical terms, but you can also have a "glossary of symbols" (found in math books), or just a glossary of a language (these are found in books used for learning that language; they differ from a dictionary by virtue of providing a gloss only for words occurring in the text, and also, providing a gloss which is specifically relevant to the text. A gloss, here, is not a definition, since it need only work in the one context.) 64.186.47.170 (talk) 08:03, 11 June 2016 (UTC)

I concur with the anon. A "Glossary of historical photography" might be something very different (a glossary of modern terms about historical photography). We also have other complications, such as the fact that there can be glossaries of other things than terms (e.g., equations, symbols, etc.), and glossaries of terminology that are not just lists of terms and definitions, but have more conventional article content on the systematics of a terminological system. Finally, using titles like "Glossary of basketweaving" is simply telegraphic writing, and parses as extremely awkward to some of us, even confusing and questionably grammatical/logical. It's the pursuit of concision to an extreme that defies common sense and the other naming criteria like WP:Precision and WP:Recognizability. Another way of looking at this is that "Glossary of" and "List of" are themselves "redundant" in the same sense: we could move all list articles to bare plural forms (usurping plural redirects and moving non-list articles to singular where necessary), e.g. moving "List of physics journals" to just "Physics journals"; and we could likewise move all glossaries to titles like "Physics terms". But this would not serve either reader interests or editorial, information-architecture interests. As anyone who's even taken a Linguistics 101 class knows, natural language has a great deal of redundancy in it, of many kinds, and this is because humans are not machines; our proper interpretation often requires some degree of redundancy.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:12, 10 July 2016 (UTC)

Should we link from the term or the definition?

Some glossaries link directly from the term (Glossary of architecture, Glossary of biology, Glossary of genetics), while others link from the definition (Glossary of spider terms, Glossary of bird terms, Glossary of sculpting). There doesn't seem to be any consistency and I couldn't find any guidance in the MoS (except the tangentially related WP:BOLDAVOID, which says "Links should not be placed in the boldface reiteration of the title in the opening sentence of a lead."). What are people's opinions on this? Kaldari (talk) 20:36, 27 May 2017 (UTC)

@SMcCandlish, The Transhumanist, and Machine Elf 1735: Any opinions? Kaldari (talk) 23:36, 28 September 2017 (UTC)

• Link from the term - This seems to be the simplest and most intuitive option. Kaldari (talk) 20:36, 27 May 2017 (UTC)
• No real case for a rule, but probably for an explanation. This should be up to (guided) editorial discretion. At the "flagship" Glossary of cue sports terms – used as the testbed for all this stuff, including the templates, and still probably our longest and most complex glossary article – we've been using {{ghat}} (a custom hatnote template for use inside glossary entries) to link to articles where we don't want to have a redundant explanation in the glossary page, or we want a short summary and a "Main article: ...." link per WP:SUMMARY style. A good example of the latter is Glossary of cue sports terms#century. But in other cases we're using in-text contextual links inside the glossary definitions, e.g at Glossary of cue sports terms#eight-ball because multiple articles are implicated. In a much more simple glossary, it would probably make more sense to just link the term, rather than something in the definition, especially if the text is very tight and doing it in the definition would require repeating the term for the sole sake of creating a link. Title linking comes at the cost, in template-structured glossaries anyway, of extra care being needed, to do this in the {{term|content=}} parameter. Some people also philosophically object to an inbound link target (the term) also being an outbound link to somewhere else.

  It would probably make the most sense to just document all of these approaches, as available options and when they work best. That would be especially consonant with WP:CREEP concerns, that MOS and other guidelines should not reduce editorial choice without a demonstrable need to do so, both because it's annoying and because it leads to too many rules.
   — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:27, 29 September 2017 (UTC)

• Follow the MOS on the formatting of headings – while it is more intuitive to link the term, the MOS states "Headings should normally not contain links". This has something to do with accessibility. So, except in cases where the term is a heading, I would link the term. For glossaries with headings, you do have the option of changing the format so that the terms are no longer headings. ;) The Transhumanist 05:50, 29 September 2017 (UTC)

Speaking of length and detail ...

I've been thinking of splitting this into an MoS page and a Help:Glossaries how-to, with most of the technical details moving to the latter. The technical complexity of this page is the only reason it still has a proposal or draft template on it, since it's actually been in daily use for years, but a proposal to put a guideline tag it, at WT:MOS several years ago, came back with a general "not yet, too complicated" response. It's actually less complicated than MOS:ACCESS and its subpages, but whatever. "Go with the flow." An argument can be made to just put {{Guideline}} on it right now, since it's actually in use as one. But as the primary author of it, I don't think I'm in a position to do that.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:37, 29 September 2017 (UTC)

I would be OK with this. · · · Peter Southwood ^(talk): 08:18, 26 July 2022 (UTC)

Naming conventions of glossary names

The following question comes out of a talk page discussion at Talk:Glossary of graph theory terms, where an editor requested a move to a page title that would violate what MOS:NCGLOSSARIES says about page titles, and another editor noted that this would violate MOS:NCGLOSSARIES, raising the following question: Why, exactly, does MOS:NCGLOSSARIES say that glossaries should be named "Glossary of X terms" rather than a less-redundant title like "Glossary of X" or "X terms", names that MOS:NCGLOSSARIES says to avoid? What extra aid to the reader does this redundancy, these repeated words with the same meaning, provide to help readers of these glossaries? Wouldn't it be simpler to simplify the titles of our glossaries by giving them a simpler form, like "Glossary of X" or "X terms"? What justification is there for this redundancy and unnecessary repetition? Anyway, as this has come up at Talk:Glossary of graph theory terms, and would obviously be relevant to the move discussion there, I think an answer to the question raised by that discussion would be helpful. I realize that this discussion repeats one already performed above, but I think a clearer statement of why "glossary of" and terms" are not redundant, and do not repeat themselves, might be helpful, as I did not see any such clear explanation in the discussion above, merely an implausible claim that the ability to modify one or both of "glossary of" and "terms" by adjectives or adverbs or other modifying phrases means that the other term that remains unmodified would then no longer be redundant. But in the basic case, where there is no modification, or when there is a modification but it applies to X rather than to the parts at the start of the title and the end of the title that refer to lists of terms from X, then this explanation would not apply, so I am still lacking an explanation that would apply to this basic case. —David Eppstein (talk) 07:09, 14 February 2021 (UTC)

• I was the one to raise the question at Talk:Glossary of graph theory terms. It seems that the question of whether to include "terms" or not could be better to judge on a case-by-case basis:

On the one hand, "Glossary of nautical terms", seems to be the only sensible title, while on the other hand "Glossary of astronomy" and "Glossary of history" are clearly better than "Glossary of astronomical/historical terms" [sic!], but "Glossary of history terms" is possibly clearer in this particular case. Whether "Glossary of cricket terms" is really better than "Glossary of cricket", I don't know, although I note that there is a Glossary of chess.

But "Glossary of graph theory terms" is slightly awkward, and the only reason it was moved from "Glossary of graph theory" a few years ago seems to be because of this policy, not because it would actually make an improvement. That is not the way! -St.nerol (talk) 10:50, 25 February 2021 (UTC)

• The "X terms" form always sounds awkward to me. The subject of the article should be the subject of the title phrase, not tucked away as an adjective. This should be possible almost all the time, e.g. Glossary of nautical terms could just as easily be Glossary of navigation or Glossary of seafaring. A quick look through Category:Wikipedia glossaries suggests that the "Glossary of X" form is actually more common – a clue that this guideline is trying to prescribe somebody's opinion of the best style rather than describe consensus. – Joe (talk) 11:21, 25 February 2021 (UTC)

I have closed the RM at Talk:Glossary of graph theory#Requested move 13 February 2021 as consensus to move to the shorter title.

I note that the standard proposed in this draft MOS section is not yet an official naming convention. If it is to become one, it needs to conform to our current consensus-based practice IMO. Andrewa (talk) 19:08, 25 February 2021 (UTC)

• In general, I think having "terms" tacked on to the end of a Glossary article title is unnecessary and redundant, as a glossary is a list of terms by definition. But I also agree with the above comment that some titles like "Glossary of nautical terms" is the only logical title. The naming guidelines should be written to give some leeway rather than being an absolute rule. Rreagan007 (talk) 21:10, 26 February 2021 (UTC)

In light of the above consensus, how about this formulation? (Note that it also does not demand creating every single redirect (e.g. "Astronomy slang" would seem a bit silly).):

For an article that consists of a simple lead and a glossary, the form Glossary of subject is preferred (e.g. Glossary of mathematics), while Glossary of subject (as adjective or noun) terms can be suitable alternatives (e.g. Glossary of nautical terms or Glossary of computer hardware terms). Whichever of these are used, consider creating redirects from the alternatives as well as from Subject terms, Subject glossary, Subject terminology, Subject jargon, Subject slang, and List of subject terms. --St.nerol (talk) 18:24, 2 March 2021 (UTC)

Splitting large glossaries and tables of content

The normal tables of content appear to only work within a single page. A split glossary would be enhanced by a ToC that can jump among the sub-glossaries. This can be done with a special purpose template, such as Template:Glossary of underwater diving terminology ToC and at least one other that I based it on, but maybe a generalised template can be coded for this purpose. I do not know how to do that, so making the suggestion here in case someone more skilled at template-fu knows whether or not it is practicable or wants to have a go at it. Glossary internal links also fail between different pages. This can also be handled with a special purpose template, (like Template:Diving term), and again it may be possible to generalise. As time goes by glossaries get longer, and eventually they crash from exceeding the template inclusion limits, so, in the long term, dealing with this problem will become more common. I suggest some guidance on this in the MOS.

Also, I would appreciate someone taking a look at how I managed the split at the glossaries of underwater diving terminology, in case there is a better way. Cheers, · · · Peter Southwood ^(talk): 09:29, 15 July 2022 (UTC)

Much the same approach has also been applied to Glossary of nautical terms, and seems to be working satisfactorily. The change was fairly straightforward and quick, and functionality seems good so far (no-one has complained yet). · · · Peter Southwood ^(talk): 08:14, 26 July 2022 (UTC)

Layout: where to place additional Tocs in long glossaries

Proposal: change "terminate with" to "begin with" in section § Layout:

Each section in a lengthy glossary page should terminate begin with another call to {{Compact ToC}} (or some other form of concise sectional navigation).

When using the compact Tocs to browse or navigate through the glossary, having the compact Toc at the beginning of the section creates a rapid nav ability as every click brings up a new section with a new ToC in the same viewport position, such that your cursor is placed over the same ToC letter as it was before. You can zip through it very quickly, which is very handy for certain tasks, such as when you don't recall the first word of a multi-line term, or simply for browsing. With the Toc placed at the end of a section, it requires scrolling an unknown amount down to the end of that section to find the next ToC, and place cursor over it. Top-of-section ToC has some advantages, and no disadvantages that I can see. (This also applies to non-glossary pages that use multiple Compact ToCs, such as at Phases of Operation Car Wash—to see the quick-nav effect, click the YYYY years in the numeric compact ToC.) Mathglot (talk) 05:20, 25 March 2023 (UTC)

This discussion is merely about where to place an existing template on a page; a discussion about whether this template should exist at all takes precedence, and follows below. Thanks, Mathglot (talk) 06:16, 25 March 2023 (UTC)

Compact ToC hostile to Vector2022 users

(Spun off from previous section.)

Am I the only one to whom the advocacy of all these fake-TOC templates comes off as actively hostile to Vector2022 users? In Vector2022, the real TOC is always visible and always usable, but these fake TOCs scroll off the screen and you have to go find them again before you can use them. —David Eppstein (talk) 05:44, 25 March 2023 (UTC)

Can you elaborate? Are you saying that the scrollable, expandable ToC which normally appears in the left sidebar doesn't appear on the page you are looking at? Can you link to an example? Mathglot (talk) 06:14, 25 March 2023 (UTC)

To pick an arbitrary one from an earlier discussion here, Glossary of nautical terms (A-L). There is no left sidebar ToC. There is only the compact ToC that this MOS says to use instead. So if I am somewhere in the middle of that glossary, I have to navigate back to the top of the page to use the compact ToC to go anywhere else. It's the same for other glossaries I tried, such as Glossary of computer science and Glossary of algebraic topology. You might notice that when {{Compact TOC}} is used, it by default disables the real TOC, unless the |allowtoc= parameter is explicitly used. —David Eppstein (talk) 06:23, 25 March 2023 (UTC)

The page Glossary of nautical terms (A-L) has a __NOTOC__ statement near the top, which I suspect is responsible for what you are seeing. If the Vector2022 skin can be tested for by a builtin or magic word ({{CURRENTSKIN}} would be nice) or by a template or module ( {{ Is Vector2022 }} ), then if there were consensus for it, the __NOTOC__ could be conditionally suppressed (or perhaps even, always suppressed for that skin by default, although that would probably require a higher level of consensus and possibly a software change?). Can you try a no-save edit to Glossary of nautical terms (A-L), dropping the __NOTOC__ and previewing it, to see if the expected ToC comes back in Preview mode? (That's assuming the ToC normally appears in preview before saving, which I'm not certain about, otherwise you might have to try it in a sandbox.) Mathglot (talk) 06:38, 25 March 2023 (UTC)

Removing the NOTOC does not produce a left-sidebar-TOC on preview. I'm not sure whether this is because there is a NOTOC hidden somewhere else or because preview respects the sidebar presence/absence of the existing article. —David Eppstein (talk) 07:12, 25 March 2023 (UTC)

I started this discussion at a Mediawiki page about Vector 2022. Mathglot (talk) 07:03, 25 March 2023 (UTC)

Tracked in Phabricator
Task T317818

I received a response. The underlying issue of configurability options for table of contents is being tracked in phabricator. Mathglot (talk) 06:30, 21 April 2023 (UTC)

Looking again, I think you identified it with the #if statement that tests param |allowtoc= in the template. I can imagine a solution to this, such as flipping the sense of the #if so allowtoc is ON by default, but this would change the behavior of every page that includes a {{Compact ToC}} (6,915 of them), which would be beneficial for you (and perhaps for other Vector 2022 users), but would very likely annoy the users of Vector 2010 (or other skins) for whom the template has been working since before Vector 2010 was first released. A sudden change in its operation now, would look to those users like the converse of your problem, i.e, "Vector 2022 is hostile to Compact ToC", and they would have a certain claim to that view: after all, why should a new skin break something that's been working since 2007? The burden should be on the new piece of software to integrate smoothly with pre-existing software in a desirable way, but in a software development of that scale, various glitches are inevitable, and we just have to figure out the right place to raise the issue, so we can get it looked at. I'm fairly certain that this page, a Manual of Style page, is not the right place for this discussion to get the right people looking at it, and probably neither is Template talk:Compact TOC, because there's not really a whole lot the template can do about it (unless we get a solution for that magic word/built-in issue). A starting point might be the Talk page of Help:TOC, which is Help talk:Section, and even then, that's not quite the place to find folks knowledgeable about skins. I'm thinking we might have to move this to Wikipedia:Village pump (technical), with a linkback from Wikipedia:Village pump (WMF) (because of the possible need for a new built-in or something). Another option, not exclusive of the others, if this looks like an issue around the interaction between Vector 2022 and __NOTOC__, is to raise a bug in Phabricator (click here). Do you have a preference? Mathglot (talk) 08:12, 25 March 2023 (UTC)

I think that a manual of style page for glossaries is exactly the right place to discuss a styling issue that affects basically all glossaries. Also, its not "an interaction between Vector 2022 and ", it's deliberate behavior on the part of glossary styling to disable the real TOC and put in a fake TOC in its place, because of limitations on TOC styling of previous skins. —David Eppstein (talk) 17:40, 25 March 2023 (UTC)

Okay, if you wish, but it's a bigger issue than that as it appears on 5,000 non-glossary pages which have the template (as well as a handful of pages that don't have the template), so even if you succeed in altering glossary styling to your preference, there will still be 15,000 other articles that have the issue. In any case, the Talk page should be used for discussion of how to improve the situation, so what do you propose? Mathglot (talk) 19:00, 25 March 2023 (UTC)

Lots of pages have NOTOC for lots of different reasons. Glossaries have them for a specific reason, that this MOS encourages the replacement of real TOCs by template fake-TOCs. Let's not confuse that with the other reasons NOTOC is used elsewhere.

As for "In any case, the Talk page should be used for discussion of how to improve the situation, so what do you propose?": I think it's important to identify a problem and to discuss different possibilities for what might be done first, before demanding that anyone pointing out an issue already have a fix in hand. One thing that might be done: go back to using real TOCs and let anyone still having difficulty with that under the non-default skins lump it. They chose to use a non-default skin, so any problems with that skin are their fault. Or do you maybe have a better idea? —David Eppstein (talk) 04:18, 26 March 2023 (UTC)

Agree with all three sentences in your first paragraph. Just one aside: remember when using the term "MOS" here as shorthand, that this page is not part of the Wikipedia:Manual of style, and has no particular force. So, for example, if you think it's necessary to have an Rfc to change the terms of this page, it isn't; there's no consensus to overturn.

Regarding the second paragraph, yes indeed, let's identify the problem, and nobody is asking for a solution. Asking for what you propose, is simply a request to try to see how you want it to work, i.e., "what needs to be changed, in order for you to be happy with it?" I think you answered that in your next sentence, where you proposed this:

go back to using real TOCs and let anyone still having difficulty with that under the non-default skins lump it.

Thanks for your proposal. I want to make sure I understand what you are saying. I interpret the above, to mean this:

Remove the __NOTOC__ from Template:Compact ToC, and those pages that previously used the template in glossaries should either stop using it, or else continue to use it and suffer the consequences. For Vector 2022, this will be an improvement, bringing glossary page ToCs in line with the way they are done on the other 6.6 million pages; and for those users choosing to use a legacy, non-default skin like Vector 2010 on pages having the Compact ToC template, they will see a standard, Vector 2010, vertical Table of Contents under the lead, as well as the template-generated horizontal ToC in-line in the article body. The fact that the vertical ToC would be visible in Vector 2010 at the top of the page on glossary pages is just tough luck for those who choose to use a non-default skin, when they could have just gone with the default, which is now Vector 2022.

Is that a fair restatement of your position?

There's one other thing, and it's about the tone of this discussion. It feels like you may have become annoyed, frustrated, or angry at the current situation with Compact ToC and glossary pages, and it's leaking out a bit in the way you phrase your comments. I just wanted to say that I had no part in creating template {{Compact TOC}}, no part in designing the Vector 2022 product (or, for that matter, Vector 2010 or any other skin), and I had no part in designing MOS:GLOSS or writing any of it. The only reason I'm even on this page talking to you, is due to a very minor issue, detailed in the previous section, and I saw your comment and wanted to help you air your concerns, with a hope of getting you to some outcome you are happy with; but I am not responsible for how things got the way they are. If this is mostly about venting, then I get it: you're not happy with the status quo; you couldn't be clearer on that point. That said, if you do want to see an improvement in the situation more to your liking, then as you said, the first step is identifying the problematic behavior, and then, as I've indicated previously, it's to bring the issue to the proper venue. Nobody who has the understanding or tools to change the current situation will see this discussion here, and as a first cut, I'd recommend you start a new discussion at one of the venues mentioned previously, starting right off at the top with your proposal, and explaining a bit of the reasons why. You can link back here using {{Dicussion moved from|WT:Manual of Style/Glossaries#Compact ToC hostile to Vector2022 users}} for anyone who's interested in the backstory. If I wanted to move the template in your direction, that's what I would do, but you may have a better alternative. Mathglot (talk) 05:55, 26 March 2023 (UTC)

It is NOT a proposal, in the sense that I am not convinced that it is the best course of action and am not trying to drum up support for that specific course of action. Again, please stop demanding that I must have a solution in hand when I report a problem. It is merely throwing out an idea, something that could possibly be done instead of the status quo. I would prefer if other people more familiar with the general topic of glossary contents could suggest some way forward, rather than having to make up a solution myself in an area with which I am less familiar, or face your dismissive tone about how this is all just a bug in Vector2022 and I should go report it on Phab and if we only didn't have it as our default skin for the majority of readers to use we wouldn't have any problems. —David Eppstein (talk) 07:39, 26 March 2023 (UTC)

Just adding a statistic: to the 6,900 uses of the template, we also have the 22,000 direct uses of __NOTOC__ on article pages. Mathglot (talk) 08:31, 25 March 2023 (UTC)

How is "lots of other pages are doing this for different reasons" relevant to this specific MOS and the specific reason it has for encouraging NOTOC? To me it just looks like a deflection rather than an honest effort to examine the issue. —David Eppstein (talk) 04:20, 26 March 2023 (UTC)

It isn't, and this isn't a Wikipedia:Manual of style page. Given the amount of time and effort I have spent engaging with you on something I had no part in creating purely in a desire to help you, your last sentence is rather disappointing to me; see my comment on "tone" above. It's becoming clear that my efforts haven't been as helpful as I would have wished. Perhaps it's time to allow others to chime in, who can offer better feedback on this than I have been able to. Sorry I haven't been more helpful. Cheers, Mathglot (talk) 06:00, 26 March 2023 (UTC)

Re "this isn't a Wikipedia:Manual of style page": this is Wikipedia talk:Manual of Style/Glossaries. In what sense do you think it is not a discussion page about the manual of style? —David Eppstein (talk) 07:40, 26 March 2023 (UTC)

Just as a note: although that would be a bit of added HTML code, there is nothing that prevents replacing __NOTOC__ logic in this template with <div style="display: none;">__TOC</div>-style code. It would make a hidden ToC in most skins and, I assume, a regular one (though not with all of the same headings that pseudo-TOC has) in new Vector. stjn 22:49, 2 April 2023 (UTC)

Very interesting suggestion, but in my tests the TOC was still visible in all styles with this code (or at least in almost all styles; I have old leftover css for monobook that prevented it being visible there but I think the default would be visible. —David Eppstein (talk) 00:19, 3 April 2023 (UTC)

I misspelled it the first time. It needs to be <div style="display: none;">__TOC__</div>, with two more underscores. It seems to work! Brilliant! If this were used, the compact TOCs would still also be there in vector2022, but they're compact, so not very problematic (and maybe a good idea to keep as well for people used to using them to navigate). —David Eppstein (talk) 06:45, 3 April 2023 (UTC)

Yeah, sorry about (my) misspelling above. stjn 18:26, 3 April 2023 (UTC)