Template talk:Term

This template was considered for deletion on 2014 October 22. The result of the discussion was "keep".

Have you seen what a page like Glossary of cue sports terms looks like without that tweak? It's a readability issue, and the change is pretty minor. Everything we do with CSS here is something that the bare HTML tag doesn't do itself, right? Are you finding that it looks bad in your browser? I tested it in 7 browsers on 2 platforms, and it seemed okay in all of them, though not 100% consistent, due to difference in default fonts between Windows and Mac. — SMcCandlish Talk⇒〈°⌊°〉 Contribs. 02:35, 20 February 2012 (UTC)[reply]

The sandbox currently has the normal size version, so you can see the effect on the testcases. The subtle but eye-pleasing difference is even more apparent in a whole pagefull. Anyway, part of the rationale was also just to get people used to it. Most large glossaries have been done with ===h3=== headings (or otherwise huge text, e.g. at HTML entity), and I'm trying to get people to not "revolt" against template-structured definition list glossaries. But if there's some general view that using CSS to tweak things a bit like this is Bad News, I guess I could live without it. Do note, though that it's not site-wide CSS, it just the {{term}} template for use with {{glossary}}; it won't affect any other use of definition lists. — SMcCandlish Talk⇒〈°⌊°〉 Contribs. 06:12, 20 February 2012 (UTC)[reply]

With the increased font size, they look like H4 headers to me (which are also bold by default), so they may be mistaken for headers. Nothing wrong with tweaking per se, but elements should at least look consistent between raw and templated use. — Edokter (talk) — 10:45, 20 February 2012 (UTC)[reply]

The difference was mean to be clear and intentional, and to look a bit like headings on purpose (since our earlier glossary style was based on headings), though a tad smaller. People use (especially ";" and ":" Wikimarkup-based) definition/description lists for a very large number of purposes on WP (including some bad ones), and their default display isn't entirely optimal for stand-alone glossary articles. If you really think it's detrimental, I won't belabor the point further. — SMcCandlish Talk⇒〈°⌊°〉 Contribs. 00:49, 23 February 2012 (UTC)[reply]

Unique id

The HTML5 specification (and every other html spec for that matter) insists that the "id" attribute must be unique on any page: https://www.w3.org/TR/html-markup/global-attributes.html#common.attrs.id but this template adds id to the <dt /> and the <span />. It needs to be applied to one or the other, but not both. Every page using {{term}} fails html validation. Unless there's any objection, I'll remove it from one of those elements. --RexxS (talk) 23:54, 22 August 2016 (UTC)[reply]

Good catch; it should have been only on the highest-level (surrounding) element, so removing the span was the right course. — SMcCandlish ☏ ¢ 😼 22:37, 30 December 2018 (UTC)[reply]

I simplified the {{{id}}} logic since it was not necessary to use a parser function for that. That said, using |term= (or |1=) is currently useless when |id= and |content= (or |2=) are used. 50.53.1.33 (talk) 22:24, 16 August 2017 (UTC)[reply]

They serve different functions. The |term= can serve as the default id if |id= is not specified. If the latter is specified, it overrides the value of |term= on purpose, or there would be no point in it being specifiable. — SMcCandlish ☏ ¢ 😼 22:37, 30 December 2018 (UTC)[reply]

As a side note, I also notice there is currently no way to have a definition (<dfn>...</dfn>) with other parts of the term used for other things. For example, when I provide |content= (or |2=) with reference markup (which should not be in |id=, |term= or |1=), should the reference markup really be part of/inside the <dfn>...</dfn>? When one wants a definition, would it not make more sense to use {{dfn}} (or provide a |dfn= that calls that at the beginning of the description term key)? It currently seems like it would be hard to use {{dfn}} and/or {{abbr}} with {{term}}. 50.53.1.33 (talk) 22:24, 16 August 2017 (UTC)[reply]

Citations belong in the content parameter, and probably that of the definition ({{Defn}}). And {{Term}} already uses <dfn> markup internally; there is no reason to ever use that markup manually with these templates. If you need to use {{abbr}} for some reason, that would also be done in the displayed content parameter. However, there is probably no point to using it in the {{Term}} template, ever, since the definition provided in {{Defn}} would be where the meaning of the abbreviation is explained. However, many {{Defn}} instances might make use of {{abbr}} for abbreviations used in them. Example: {{Term|RTFM}}{{Defn|"Read the 'friendly' manual"; the term may have been invented at {{abbr|Argonne National Laboratory|ANL}}}} – assuming Argonne National Laboratory (ANL) was already linked recently in the page and we didn't want to link it again. — SMcCandlish ☏ ¢ 😼 22:37, 30 December 2018 (UTC)[reply]

PS: to clarify, the purpose of {{abbr}} and the underlying <abbr>...</abbr> markup is not to declare "this is an abbreviation"; it is only to provide the meaning of the abbreviation, which is what the {{defn}} (the <dd>...</dd>) is doing when this content is formatted as a {{glossary}} (description/definition/association list, a <dl>...</dl>) in which the abbreviation is the {{term}} (<dt>...</dt>) being defined. — SMcCandlish ☏ ¢ 😼 00:29, 13 November 2019 (UTC)[reply]

Anchors away

Is the anchor part of this template functioning properly? Notice that this link does not follow to the term (and it's not the link formatting, as this one goes to the proper alphabetic section). czar 04:53, 30 December 2018 (UTC)[reply]

@Czar: Glossary of anarchism#Lifestylism appears to work fine. However, "{{term|Lifestylism}}{{anchor|Lifestyle anarchism}}" is invalid markup; you can't have non-description-list elements, like the <span>...</span> generated by {{anchor}}, inserted between the {{term}} (<dt>...</dt> and the {{defn}} (<dd>...</dd>). Please read the template documentation. If you need multiple anchor points do this: {{term|lifestylism|content=lifestylism{{anchor|Lifestylism|lifestyle anarchism|Lifestyle anarchism}}}}. The original term (here, lifestylism) will already be an anchor, but you need to use the content parameter to override it, with a displayed copy of itself plus additional anchors (which are case-sensitive). There's not really a simple way around this issue; each element can only have one ID, which must be unique, and the term itself cannot contain markup, since it will be the default HTML ID, not just displayed content. Thus, the content parameter lets you keep the bare ID of the term, then also add additional anchors (each a span with its own ID) or other markup. It's also probably not a good idea to capitalize glossary entries unless they are proper names, or readers can't tell whether the capitalization is meant to be there "mandatorily". — SMcCandlish ☏ ¢ 😼 22:54, 30 December 2018 (UTC)[reply]

I think you see it working fine because I added {{anchor|Lifestylism}} next to it. (Why doesn't it work in this previous revision?) I imagine this use case is relatively common, no? Might be useful to bake secondary anchor terms into the template rather than requiring this additional markup. czar 23:09, 30 December 2018 (UTC)[reply]

See thread immediately below; #Lifestylism failed because of changes to case-handling. — SMcCandlish ☏ ¢ 😼 00:21, 13 November 2019 (UTC)[reply]

Upper-case anchors are not created for upper-case terms

The documentation says "{{term}} automatically creates anchors from the original term (|term= or |1=) or |id= value, as entered, and an all-lower-case version." But it looks to me like if the original term starts with an upper-case letter, the anchor for the original, upper-case term is not created. Only the all-lower-case version of the link works.

Here is an example, the term "Hollywood" from Glossary of professional wrestling terms:

Glossary of professional wrestling terms#Hollywood links to the top of the page.
Glossary of professional wrestling terms#hollywood works as a section link.

Side note: when the term itself is lower-case you can also only use the lower-case version of the term as a section link, but I believe this is as intended:

Glossary of professional wrestling terms#Broadway links to the top of the page.
Glossary of professional wrestling terms#broadway works as a section link.

Spike (talk) 20:33, 9 September 2019 (UTC)[reply]

Pinging SMcCandlish after his return. Spike (talk) 16:15, 5 November 2019 (UTC)[reply]

Testing:

Test123: Just a test

Yep. Something is screwy there. This may've gone unnoticed because the {{glossary link}} template lower-cases, I think. This and the above thread suggest some code tweaks are needed. Have to be careful, though. If these templates have too many parser-function calls in them, then long glossaries will start to fail and have to be split into multiple pages, due to a hard limit on the number of function calls per page. I misremember what that is (and would hope that it's been raised since the last time I checked, a few years ago). — SMcCandlish ☏ ¢ 😼 20:32, 5 November 2019 (UTC)[reply]

Looking at the history, this feature was removed by RexxS in Special:Diff/737088251. * Pppery * _{it has begun...} 01:45, 11 November 2019 (UTC)[reply]

Yes, of course I removed it. The code I cut out gives both the <dt> element and the <span> element the same id if it begins with a lower case letter. That's invalid HTML because all ids must be unique on a page. --RexxS (talk) 01:01, 12 November 2019 (UTC)[reply]

And I don't see a way to fix this without a custom module. My first thought was to use <a name="{{#invoke:String|replace|source={{{id|{{{term|{{{1}}}}}}}}}"></a>, because an id and a name can coincide (indeed, they must when used on the same element – or that was the case in HTML 4.01 and early versions of HTML 5 ...). Today, though, <a name="..." ...>...</a> is no longer valid in HTML 5; this use of name has been deprecated. So, we're stuck with a situation where the template is going to produce lower-case IDs (and needs to, because the habit of starting all list items, including glossary ones, with a capital letter is ingrained, no matter what MOS:GLOSSARY says), and there's not a way in the template code to check for whether the term began with a capital letter, set a variable if so, and generate both a lower- and upper-case id anchor point (in different elements) if that variable is true. If someone who knows the highly particular Scribunto implementation of Lua better than I do wants to take a stab at Module:-izing this template, have at it. In the interim, I'm going to update the template documentation to describe actual behavior and how to work around it if you really need to. — SMcCandlish ☏ ¢ 😼 23:44, 12 November 2019 (UTC)[reply]

Docs updated. — SMcCandlish ☏ ¢ 😼 00:13, 13 November 2019 (UTC)[reply]

@SMcCandlish: I can write Lua code to do the job you want, but I'm loathe to convert templates to modules when the template maintainers are not Lua programmers. Can I suggest that you consider the following algorithm?

Go back to your earlier version that has ids on both the dt and the span.
For the first one, just use the term/id supplied without changing its case.
For the second one, use a lower-case version in the span if the term/id starts with a capital, but use nothing if the term/id starts with lower-case.

You'd have to work from the current version, which has modifications from your earlier one, but it just needs the extra span. The test for something beginning with an upper-case letter would be something like this:

{{#ifeq:{{{id|{{{term|{{{1}}} }}} }}} | {{ucfirst:{{{id|{{{term|{{{1}}} }}} }}} }} | this when first starts with upper-case | this when first doesn't }}

If that causes issues in large glossaries, then by all means look at the fragment I've created at Module:Sandbox/RexxS/GenerateIDs along with a few tests at Module talk:Sandbox/RexxS/GenerateIDs which could be used as a basis for dealing with the second id, while retaining most of the template. --RexxS (talk) 02:37, 13 November 2019 (UTC)[reply]

Orca-dorca. I'll have to have a nap (been up for about 30 hours now), then coffee up, and put on the tempate-coding hat. The test-bed article is Glossary of cue sports terms, which I still think is the largest one we have (and one that already had to have some stuff done to it, like conversion of simple {{defn}} cases into raw <dd>...</dd> markup to keep from hitting the limits. But that was years ago, so it bears some re-testing anyway. — SMcCandlish ☏ ¢ 😼 22:51, 14 November 2019 (UTC)[reply]

Linking of terms

This template's instructions on wiki-styling and linking discourage links to other pages in glossary terms. However, if the consensus at an article is to link certain terms, what would be the appropriate format: {{Term|term=[[Foo]]}} or {{Term|term=Foo|content=[[Foo]]}}? -- Black Falcon ^(talk) 19:17, 17 November 2019 (UTC)[reply]

Section transclusion on a per-term basis

It would be v useful to be able to selectively transclude specific terms form a long glossary like Glossary_of_genetics into smaller glossary templates (example) or those used directly in pages (example) using mw:Extension:Labeled_Section_Transclusion. Currently {{#section-h:Glossary_of_genetics|B}} works but {{#section-h:Glossary_of_genetics|base pair}} doesn't. I think functionality could be achieved by adding a <section begin={{{1|}}}/>...<section end={{{1|}}}/> around the {{defn}} template. What do people think? T.Shafee(Evo&Evo)^talk 02:33, 30 November 2019 (UTC)[reply]

Simpler term-defn template

I was trying to create a simpler {{term-defn}} to be used as follows:

{{term-defn|term 1|definition 1}}

Unfortunately, it didn't work. Let me know if you see what's wrong. fgnievinski (talk) 00:02, 27 January 2022 (UTC)[reply]

It's not documented, so please explain, what do you intend for {{term-defn}} to do? What does it do that the existing {{term}} / {{defn}} templates don't? — sbb (talk) 03:23, 28 January 2022 (UTC)[reply]

@Sbb: it's intended to be used as in the example given above; the single-template usage proposed, {{term-defn|my term|my definition}}, is meant to be more concise than the current dual-template usage, {{term|1=my term}}{{defn|1=my definition}}. fgnievinski (talk) 07:32, 28 January 2022 (UTC)[reply]

Hmm. I don't think saving 3 characters is the type of concision that's needed. Compare:

{{term-defn|my term|my definition}}
{{term|my term}}{{defn|my definition}}

— sbb (talk) 04:05, 31 January 2022 (UTC)[reply]

Intend to obsolete `|multi=y` with TemplateStyles in {{Glossary}}

(Cross ref this discussion with Template talk:Glossary#Convert to TemplateStyles: save 6% on PEIS!)

TL;DR: Using 2 simple CSS rules in Template:Glossary/styles.css (currently not promoted, they're in the sandbox/styles.css file), the need for {{Term}}'s |multi=y parameter goes away. We should do this and obsolete the parameter entirely.

IMO, the "default" behavior of multiple successive {{Term}}s being spaced apart is a misfeature, simply a limitation of what can be done with MediaWiki's templating and processing engine. It just wasn't possible to emit multiple <dt>...</dt> tags from {{Term}} tags (on a one-for-one basis) and also automatically emit different CSS styling to the 2nd through n <dt> tags. Hence it required the |multi=y option to deliberately switch behavior for the successive terms that all share the following <dd> definition. At least, it's not possible without also modifying the bloated common.css (or Main.css, I forget which).

That is, until TemplateStyles came along. With these 2 simple CSS rules in {{Glossary}}'s styles.css file,

.glossary dt { margin-top: 4em; }
.glossary dt + dt {margin-top: -0.2em; }

The "closing up" of successive {{Term}}s is automatic. It also reduces PEIS by ~6% (in my limited testing of a couple large existing glossaries).

I'm going to sit on this for a couple weeks. If there aren't strong objections, or really good reasons why this shouldn't be done, I'm moving ahead with it then. — sbb (talk) 16:45, 26 May 2024 (UTC)[reply]

Moved to Template talk:Glossary

– This is more of a top-template-level design/use change, so that discussion there is probably better.

— sbb (talk) 02:22, 10 June 2024 (UTC)[reply]

Font size