Wikipedia:Templates for discussion/Log/2020 December 19



Template:K. S. Lal

 * The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. Primefac (talk) 01:28, 27 December 2020 (UTC) Redundant template with self links. The template contains links for promo articles about the non notable books. Those articles have already been merged or redirected to the author's article by multiple editors. The template is only used on the author's page and now serves no purpose, as it is simply a list of redirects. Walrus Ji (talk) 20:44, 19 December 2020 (UTC)
 * K. S. Lal
 * Delete: Per nom, no navigational assistance is provided anymore. -- 2pou (talk) 19:52, 23 December 2020 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:English Test match double

 * The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. If someone needs the content to add it to the 1977 template or for other use, please ping me. Primefac (talk) 02:01, 28 December 2020 (UTC) No accompanying article with coverage that 'Test match double' is a significant achievement and is exclusive. The criteria is too inclusive if we expand it to all test-playing nations. No navigational value. Störm  (talk)  19:01, 19 December 2020 (UTC)
 * English Test match double
 * Comment There is an existing navbox for all countries, but it stops in 1977 for some unexplained reason: Test cricket doubles to 1977. There is Double (cricket) which could be expanded to cover this, but it currently deals just with domestic single season efforts rather than international career ones. This could be better dealt with by a category than a navbox. As it is, many of the players listed are bowlers who have played long enough to reach 1000 runs, rather than being all-rounders of note.  Spike &#39;em (talk) 21:07, 19 December 2020 (UTC)
 * Delete Not sufficiently important to need a navbox. Content should be in a Test Record article if it is sufficiently important. Doesn't seem to exist for other test countries. Nigej (talk) 22:13, 23 December 2020 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Dvořák symphonies

 * The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. Plastikspork ―Œ (talk) 13:35, 27 December 2020 (UTC) Template:Dvořák symphonies, Template:Dvořák string quartets, Template:Dvořák concertos are redundant since Template:Antonín Dvořák exists and includes the exact information. Currently, each page is transcluding both templates and the duplicates are not helpful. intforce (talk) 10:39, 19 December 2020 (UTC)
 * Dvořák symphonies
 * Dvořák string quartets
 * Dvořák concertos
 * Delete or if people think it appropriate redirect to the main Antonín Dvořák template, we don't need the duplication. Chiswick Chap (talk) 19:01, 19 December 2020 (UTC)
 * Delete as redundant. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:22, 20 December 2020 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Queensland Rail templates part 2

 * The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. Plastikspork ―Œ (talk) 17:17, 27 December 2020 (UTC)
 * GoldLinQ color
 * GoldLinQ lines
 * GoldLinQ stations
 * S-line/QR right/Airport
 * S-line/QR right/Beenleigh
 * S-line/QR right/Caboolture
 * S-line/QR right/Cleveland
 * S-line/QR right/Diesel Tilt Train
 * S-line/QR right/Doomben
 * S-line/QR right/Electric Tilt Train
 * S-line/QR right/Exhibition
 * S-line/QR right/Ferny Grove
 * S-line/QR right/Gold Coast
 * S-line/QR right/Gympie North
 * S-line/QR right/Ipswich and Rosewood
 * S-line/QR right/Kuranda Scenic Railway
 * S-line/QR right/Nambour
 * S-line/QR right/Pinkenba
 * S-line/QR right/Redcliffe Peninsula
 * S-line/QR right/Shorncliffe
 * S-line/QR right/Spirit of Queensland
 * S-line/QR right/Spirit of the Outback
 * S-line/QR right/Springfield
 * S-line/QR right/Sunshine Coast
 * S-line/QR right/The Inlander
 * S-line/QR right/The Sunlander
 * S-line/QR right/The Westlander
 * S-line/QR right/Tilt Train

28 deprecated templates in this category replaced by Module:Adjacent stations/Queensland Rail. This completes the Queensland conversion. Fleet Lists (talk) 01:31, 19 December 2020 (UTC)
 * Delete, per nom. Techie3 (talk) 04:17, 20 December 2020 (UTC)
 * Removed the category (Category:Queensland Rail succession templates) from the nomination, as that category is not populated by these templates, but is instead a category(repository) of templates. I will nominate it for C1 soon. Techie3 (talk) 06:41, 22 December 2020 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Hover title and Template:Tooltip

 * The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was merge to Template:Tooltip. Note that once this is complete, there is no prejudice against revisiting the question of whether to even have this as a single template; there were multiple opinions here that indicated it should simply be deleted outright. Primefac (talk) 12:31, 10 January 2021 (UTC)

Propose merging Template:Hover title with Template:Tooltip.
 * Hover title
 * Tooltip

Some time ago, Template:Tooltip was "merged" and redirected to Template:Abbr. This was an outright mistake in several ways (and undertaken over a decade ago when we cared much less about HTML specs). First, it was not actually merged: the correct use of, for non-abbreviation uses, was lost; imposes  in every case. This is an HTML standards compliance failure on a pretty massive scale. That element is only for abbreviations (including acronyms and initialisms). Despite the redirect from being deprecated, for that very reason, a few years ago, the deprecation was simply ignored by the community in actual practice. There are tens of thousands of calls to (directly, not to ), and a large proportion of them are not abbreviation cases. Then we also ended up with, which did the exact same thing did, just with backwards parameters (plus some extra options). I have merged the additional features of into a new (non-redirect). It appears that the vast majority of instances of calls to and to  (a name that doesn't mean much of anything to anyone) are due to their use in infoboxes and other templates. If 1) instances of the former in such templates are tracked down and sorted properly into uses of for input that is explicitly abbreviation/acronym/initialism, with the rest remaining as  calls (which is fine for input that is sometimes abbreviations and sometimes not –  is an entirely optional semantic markup element); and 2) instances of  are changed in templates to reverse the 1 and 2 parameters and to use  instead; then 3) this should leave only a comparatively small number of manual insertions of  to clean up as  instances (probably an easy bot task).  Then some /doc updates, of course. (PS: I have not TfD-tagged the templates in a way that's visible when transcluded, since these are so frequently used in mainspace that it might be too visually disruptive to even use the small, inline version of the TfM tag. And our readers don't care about template mergers anyway.) — SMcCandlish ☏ ¢ 😼  23:46, 3 December 2020 (UTC) However, could this not be fixed to make it W3C compliant? &#8211; MJL &thinsp;‐Talk‐☖ 06:03, 6 December 2020 (UTC)  Relisted to generate a more thorough discussion and clearer consensus.
 * Note: WP:Village pump (technical) has been notified of this discussion. Also notified participants in the two old discussions, and talk pages of project pages (e.g. WT:HTML5, WT:LINT) where people congregate who probably care and also have ideas for how to do this cleanup expeditiously.  — SMcCandlish ☏ ¢ 😼  23:56, 3 December 2020 (UTC); updated: 00:31, 4 December 2020 (UTC)
 * Sounds reasonable to me. I haven't read the documentation thoroughly, but at a glance, it seems like Hover title and Tooltip are trying to do the same thing. &#123;{u&#124; Sdkb  }&#125;  talk 00:03, 4 December 2020 (UTC)
 * And it's confusing to have backasswards parameters at templates that are otherwise essentially identical.  — SMcCandlish ☏ ¢ 😼  00:12, 4 December 2020 (UTC)
 * Merge. It looks like it should be pretty easy to make one of them into a wrapper for the other until a bot comes along to fix the existing usage. – Jonesey95 (talk) 00:37, 4 December 2020 (UTC)
 * Yeah, that's what I was going to do, but the past history is weird, so it seemed best to chat it out.  — SMcCandlish ☏ ¢ 😼  00:39, 4 December 2020 (UTC)
 * Merge: Obvious improvement. --Guy Macon (talk) 02:01, 4 December 2020 (UTC)
 * Delete both. I'm not a fan of this out-of-process restoration of the template. We have a guideline at MOS:NOTOOLTIPS which states not to use tooltips at all. We have a community consensus at Redirects_for_discussion/Log/2018_May_9 which state that appropriate uses should be converted to use Abbr; Any non-abbreviations should be removed or replaced with footnotes.. The real issue was that someone at some point removed Tooltip from the /holding cell for whatever reason. --Gonnym (talk) 11:40, 5 December 2020 (UTC)
 * Delete both. The templates clearly violate the accessibility MOS and the outcome of the previous RfD. Nardog (talk) 15:33, 5 December 2020 (UTC)
 * Comment. I resent the idea that I need to follow the WP:MOS while in project or talk namespace. These templates need to simply just be handled like talk quote inline is and throw an error when in mainspace. &#8211; MJL &thinsp;‐Talk‐☖ 17:22, 5 December 2020 (UTC)
 * Calling our guideline on WP:Accessibility not something worth following outside of mainspace is ableism. I'm sure you (specifically) can appreciate what that means. --Izno (talk) 05:29, 6 December 2020 (UTC)
 * Okay, so I seemed to have misunderstood something pretty critical which is that our tooltips are currently not accessible to keyboard-only nor mobile users. I looked into the relevant guidelines there, and it seems that we are improperly relying on the title attribute.
 * The point of this template is to produce the hover/tooltip effect with &lt;span>, so I'm not sure what can be done.... (&lt;abbr>'s  has slightly different semantics;   is required in that context and it is the expansion of the particular abbreviation. abbr covers this case already, of course.) There might be a way combined with Template:sronly to get the content into view of the screenreader. We would still have issues with devices that are neither screenreaders nor desktop (namely, almost all mobile) with a media query for mobile. It is likely that most people on those devices would not want the content (as it is often parenthetical in nature, or not necessary for full understanding if you already have the context), but I don't think I would want to have such a radical deviation for three different kinds of devices from the casual editor's authoring perspective, which is almost always desktop only, and unlikely to consider the impacts., any thoughts? --Izno (talk) 18:04, 6 December 2020 (UTC)
 * Yeah I don't really know what to do here either. Graham 87 02:07, 7 December 2020 (UTC)
 * All that said to MJL about possible ways to make the content of a title attribute accessible, I definitely tend toward agreement with both Gonnym and Nardog. Probably all uses of these templates (and abbr) need scrubbing/work/verification. --Izno (talk) 18:04, 6 December 2020 (UTC)

Please add new comments below this notice. Thanks, Primefac (talk) 01:29, 11 December 2020 (UTC) — SMcCandlish ☏ ¢ 😼  09:46, 14 December 2020 (UTC)
 * Updated, more accessible implementation tests: As for, that looks like it could easily be used to make the tooltip content available accessibly anyway, perhaps as a square-bracketed note. Just feed it the same or whatever, as feeds the tooltip itself. , and it seems to be working with everything I throw at it.  , I hope the test cases are clear enough. I've tested various linking scenarios, and each example presents the code to test, then example output of the sandbox version of the template, and finally sample output of the current "live" version of the template (useless right now for this, since it lacks any sronly code).  — SMcCandlish ☏ ¢ 😼  09:46, 14 December 2020 (UTC)
 * Reality-check comments: Aside from the fix being tested above, I have to point out that we know several relevant things by now from direct experience:
 * Telling people not to abuse the element and its  template wrapper is simply going to be ignored if there is no alternative that does not abuse that element for non-abbreviations.
 * There are limits to what can be done to make WP or any other website accessible in every imaginable way; the technology simply doesn't exist to do much. And even when it does, makers of screen readers, mobile browsers, etc., often simply refuse to implement such features, and even when they are implemented, users of those things often refuse to turn those features on.
 * WP has made various decisions to permit features that are not 100% accessible to everyone (collapsing navboxes, etc.), because they provide useful features for a majority of users, and they do not harm the actual content of the encyclopedia for users who depend on less capable software (be they screen readers for the visually impaired, or just mobile web browsers for limited-capability devices).
 * This is the same kind of trade-off; if the template (and MoS material about it) is documented properly, to not use it to effectively "hide" key content, but only add navigational and other features that are secondary, there is not an actual problem for us to solve from an encyclopedia-production perspective (cf. WP:GREATWRONGS – it is not our job to find solutions for every web-accessibility problem ever recognized).
 * We already use, for many years now,  tooltips for all kinds of things, including rendering reason values of numerous inline cleanup/dispute templates, e.g.:
 * With the accessibility fix being tested above, that should take care of much of this. I don't think we can care that the mobile-but-sighted version may lack some features. That's a usability not accessibility matter, and the mobile version lacks all sorts of features that the desktop site has. It has to, because it's a stripped-down version for small, handheld devices.
 * Finally, an old RfC and an apparent consensus to make a blanket statement in one page doesn't mean much if it had little input and if the community itself doesn't want to comply. The guidelines exist to document practice not to try to force a change in it. Nor is such a limited consensus unchangeable.  When is the last time this was even examined from a MOS:ACCESS point of view, and can anyone actually identify a real problem (e.g., an instance of use that harms the encyclopedic experience for a subset of users, rather than simply provides a side feature not all of them can use)?
 * Another example of harmless use is Template:Glossary link (a meta-template), and its progeny. They use the HTML   feature to let people know they are going to a glossary entry if they click on the link. It in no way breaks the links, nor interferes with identification of the link URL (usually done in the browser-window footer, though this varies by user agent), nor hiding the actual content that is marked up by the template, nor anything else bad.

 Relisted to generate a more thorough discussion and clearer consensus.
 * Thanks for this. Yes, it does work well with screen readers, though I would put an initial space before the left bracket in the screen reader output. This would be nice to have if the tooltip/etc. templates were used ideally almost 100% of the time, but as you said that's not always the case. Also, the technical village pump does get occasional complaints about weird glitches when this method is used, most notably in sfrac, the latest being this one about Google results. On a scale of importance from 1 to 10, I'd rate the importance of having these always read out for screen reader users as about a 3 or a 4 ... but then again I may or may not know what I'm missing. Graham 87 11:58, 14 December 2020 (UTC)
 * Strange; I actually put a space there (encoded as   to force it). If that somehow didn't work, I can try some other replacement like  . I put that version in the sandbox just now, so the test cases should have nbsp in them.  If we're sure it's going to mostly work, it shouldn't be hard to propagate this sort of sronly tweak to other templates that use tooltips (especially since most of the inline cleanup/dispute ones use a meta-template). The real cleanup operation over the long haul would be undoing misuse of  for non-abbreviations (which brings us full circle to why this TfM is open.  Does the   attribute of the  element work properly in screen readers already? I think you were indicating it's handled differently because it's mandatory in that element, a special case.  If not, I suppose this  tweak can be done to the  template as well.  On the Google glitch: I would hope that wouldn't matter much for this particular sort of use case, since the material in these tooltips is basically trivial, parenthetical annotation. I can see the math-markup substitution being a more important and problematic case, since it's actual encyclopedia content, not metadata. PS: There is actually a very technical  HTML 5 compliance nitpick with the sronly template (at all, not just in this particular kind use of it); something it is doing needs an extra attribute on an element; I forget the details, just something I saw when I ran its output through W3C's validator. I'll try to remember to bring that up at Template talk:Sronly.  — SMcCandlish ☏ ¢ 😼  13:09, 14 December 2020 (UTC)
 * The non-breaking space works fine. Re the title attribute in abbr, it does work, but screen reader users generally have to specify that they want to hear it because the abbreviation expansion isn't spoken by default. Graham 87 14:27, 14 December 2020 (UTC)
 * Is this something people know about and choose? Using this trick to force reading-out of the   content is a bit different from   text, in being add-on material rather than a replacement. And if someone has the -reading feature on, then they would get the material twice. I've asked at Template talk:Sronly about a "nosr" approach.  — SMcCandlish ☏ ¢ 😼  04:15, 15 December 2020 (UTC)

Please add new comments below this notice. Thanks, Primefac (talk) 01:11, 19 December 2020 (UTC) Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:33, 25 December 2020 (UTC)
 * MERGE provided that
 * The merged documentation describes no
 * The merged template handles Hebrew labels correctly, as tooltip currently does and hover title currently does not (see Template talk:Hover title).
 * Sure, that should be doable. Does do what is expected in this regard? You can add a Hebrew test case to Template:Tooltip/testcases.  — SMcCandlish ☏ ¢ 😼  21:01, 31 December 2020 (UTC)
 * Question: I notice that, tooltip, unlike abbr, does not change the cursor to a pointer with a quetion mark when one hovers over it (at least on my browser). I like the changed cursor; is that something we could retained at Tooltip? &#123;{u&#124; Sdkb  }&#125;  talk 00:00, 26 December 2020 (UTC)
 * Not that I know of; that appears to be a function that your browser does with the element specifically.  There might be a way to do something like it with JavaScript, but it's a bit out-of-scope for this, at this time. Better discussed post-RfM at Template talk:Tooltip.  — SMcCandlish ☏ ¢ 😼  21:01, 31 December 2020 (UTC)
 * Pinging, : Please see the thread since you originally commented. The accessibility issues appear soluble, finally. A lot has changed since the old RfD.  — SMcCandlish ☏ ¢ 😼  21:03, 31 December 2020 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Db-t3

 * The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. Primefac (talk) 04:11, 31 December 2020 (UTC)
 * Db-t3
 * Db-t3-notice
 * Db-t3-deleted
 * Hangon preload T3
 * Candidates for speedy deletion as redundant templates
 * Candidates for speedy deletion as redundant templates


 * Templates for speedy deletion with incorrect formatting
 * Templates for speedy deletion with incorrect formatting

Procedural nomination: WP:T3 was recently deprecated and similar to previous discussions regarding T criteria should be deleted to avoid potential confusion. Primefac (talk) 01:08, 19 December 2020 (UTC)


 * Support: per nom  Merry Christmas! Asartea   Talk   Contribs!  08:29, 19 December 2020 (UTC)
 * Presumably this includes/implies db-t3-notice, db-t3-deleted, and hangon preload T3 as well. And, I suppose, Category:Candidates for speedy deletion as redundant templates. ~ Amory  (u • t • c) 22:02, 19 December 2020 (UTC)
 * Yes, thanks. The cat will go as C1 once the templates are gone. Primefac (talk) 22:38, 19 December 2020 (UTC)
 * That is one of those once-in-a-blue-moon instances where another recently deprecated deletion criterion – WP:T2 – would have applied. – Uanfala (talk) 23:02, 19 December 2020 (UTC)
 * It wouldn't have, because deprecation is not "misrepresentation of policy". Doesn't really matter though. Primefac (talk) 12:33, 21 December 2020 (UTC)
 * Template:Db-u4 was deleted as T2 in 2009 and again in 2010. * Pppery * <sub style="color:#800000">it has begun... 17:08, 25 December 2020 (UTC)
 * Added two categories to this nomination, as these two categories are solely populated by the templates that are going to be deleted. Techie3 (talk) 06:44, 21 December 2020 (UTC)
 * Probably better to mark historical / replace with error rather than delete. ProcrastinatingReader (talk) 11:24, 22 December 2020 (UTC)
 * Delete per Templates for discussion/Log/2020 July 14 * Pppery * <sub style="color:#800000">it has begun... 17:08, 25 December 2020 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).