Template talk:Track listing/Archive 21

Tracklist positions for vinyl releases
Is there any way to add positions like "A1" or "B2" for vinyl releases in tracklist? Eurohunter (talk) 14:47, 27 April 2022 (UTC)
 * Yes – see MOS:SPECIALLIST. But make sure there's a valid reason for doing this – for example, if the vinyl version of an album has exactly the same track listing as the CD version, we wouldn't bother duplicating the track listing for both versions. Richard3120 (talk) 14:53, 27 April 2022 (UTC)
 * I'd just do it as a list personally e.g.


 * Side A
 * Track1
 * Track2


 * Side B
 * Track1
 * Track2


 * But it might be worth asking yourself if its really necessary if the track listing and order are the same as the CD/digital versions. Doing all this to just say A1, B1 etc is pointless. ≫  Lil- Unique1  -{ Talk  }- 15:00, 27 April 2022 (UTC)
 * Yes, I totally agree with Lil-unique1... theoretically it is possible, but there are much easier ways of showing the information than writing A1, A2, etc., as highlighted above. Richard3120 (talk) 17:23, 27 April 2022 (UTC)

Automatic summation of track lengths into total time of album
Is there a way for this template to automatically compute  using the lengths of individual tracks, rather than forcing editors to manually add together individual track lengths? My friend asked me about this, and I didn't have an answer for him, but it seems like it would be rather simple to put such a thing together. If it just needs some code to be written, I wouldn't mind taking a try at it myself. jp×g 05:25, 12 July 2021 (UTC)


 * Should be possible, yes. Gonnym (talk) 09:05, 12 July 2021 (UTC)
 * Shouldn't we be using the actual total time of the album, as published, rather than our own WP:OR? I am sure – anecdote warning! – I have seen (played) recordings that didn't actually add up as advertised on the tin / CD cover / LP sleeve. &mdash; JohnFromPinckney (talk / edits) 23:46, 12 July 2021 (UTC)
 * It seems that this would be withing WP:CALC; simple arithmetic is not original research.
 * As a side note, it looks like the edit would actually be to the Lua code at Module:Track listing. TJRC (talk) 23:50, 12 July 2021 (UTC)
 * I'd note that sometimes albums do give total running time, but it doesn't match the time obtained by adding up the individual track times. This is because each track is rounded up or down to the nearest second. JohnFromPinckney is also correct that in the LP era especially, total lengths of the album or each side of the album were often given on record sleeves or on the label, which were often very wrong. I worry that we may create edit wars if the computed total length doesn't match the stated total length on the album. Richard3120 (talk) 00:51, 13 July 2021 (UTC)
 * This is what I thought when I saw the request a few days ago. I have several CDs where the total run time is longer than the sum of each of the tracks. Walter Görlitz (talk) 07:07, 15 July 2021 (UTC)
 * Me too. This is one of those areas where I think editors can get overly creative and treat Wikipedia like Discogs or something. We don't have to provide this information, and it's often original research to do so. (Another area is totalling the number of singles, studio albums and compilations in artist discographies when no reliable source actually gives those totals. The reliance on formally rated album reviews and cursive descriptions with a score attached is another.) JG66 (talk) 15:05, 15 July 2021 (UTC)
 * How about as a compromise, the 'total length' field overrides the calculated one? This surely falls under a routine calculation: Basic arithmetic, such as adding numbers, converting units, or calculating a person's age is almost always permissible. The templatedata should also mention that it is to override the generated value only if it differs from a source. SWinxy (talk) 19:43, 4 September 2021 (UTC)
 * How can we compromise? Performing this calculation, whether automatically or by hand, constitutes WP:OR, which is prohibited by policy. We can't ever be sure that the individual times we have will add up to the correct total running time, so we can't/mustn't do this calculation at all. &mdash; JohnFromPinckney (talk / edits) 09:51, 6 September 2021 (UTC)
 * How does WP:CALC not apply in this situation? The compromise is not on policy, but to dissuade edit warring by having a RS that gives the totals (on the presumption that CALC does apply). SWinxy (talk) 13:42, 6 September 2021 (UTC)
 * If we have a reliable source for total running time, we should use that (and not do any addition). If we do not have a reliable source for total running time, we should not make any indication of a total (and here, too, we should not do any addition). &mdash; JohnFromPinckney (talk / edits) 19:50, 7 September 2021 (UTC)
 * Well, I've written User:JPxG/TrackSum.js. I would be willing to add a few lines of code that prevent it from running if there's already a  specified, but it does seem like simple arithmetic (and people already do this manually). jp×g 00:18, 4 September 2021 (UTC)
 * It would not most definitely not be appropriate. Walter Görlitz (talk) 02:01, 4 September 2021 (UTC)
 * What would not? jp×g 05:33, 4 September 2021 (UTC)
 * Using or deploying the code you've written. As discussed above, adding up individual track times to produce some "total running time" is original research and so would be entirely inappropriate for use on Wikipedia. &mdash; JohnFromPinckney (talk / edits) 18:55, 4 September 2021 (UTC)
 * Two points of clarification, yes, the code adding up and inserting the total would not be appropriate. There is no consensus to do so and several reasons have been provided.
 * Point two, I am not JohnFromPinckney and JohnFromPinckney is not me. I believe the editor was simply agreeing with my points and elaborating. Walter Görlitz (talk) 18:29, 7 September 2021 (UTC)
 * Yes, sorry if I caused confusion (Point two) by responding to JPxG's question about Walter's statement. I just hoped to clarify what I had thought was already clear, but apparently wasn't. &mdash; JohnFromPinckney (talk / edits) 19:46, 7 September 2021 (UTC)
 * Seems perfectly clear now. Thank you. In short, consensus is that summing the individual track duration could lead to a misrepresentation of total length, and should not be done, whether manually or via a tool, script, or utility that would do the adding for the editor. Walter Görlitz (talk) 15:19, 8 September 2021 (UTC)
 * This does not seem clear at all to me; of seven editors in this section who have expressed an opinion, only two of them have said that use of this tool would be OR, whereas three have said it's covered under WP:CALC, and the other two haven't made a clear judgment (saying that it has the potential to cause trouble is not the same thing as saying it must be forbidden). jp×g 09:03, 8 December 2021 (UTC)
 * If a total length is reported by the listing then fair enough use it but I note that sometimes digital copies versus physical copies differ depending on whether they've been coded to be seamless or not. TBH if a reader really wants to total the length they can do it for themselves. If the code automatically did it, again its not WP:OR, actually WP:CALC applies as we're summing info already there. I suspect editors like to add it because it gets picked up at FA/GA review sometimes and it helps them to feel like the information is as complete as possible. Asking for a reliable source for running time is akin to reliable sources for release dates. Pick a number and see if it fits. ≫  Lil- Unique1  -{ Talk  }- 21:52, 30 May 2022 (UTC)

Two diff notes for a track
How do I handle a track that needs two notes added to it? One for the featured artist and one to state that it's a remix? Eg. "Banana Bread" (featuring Abcd) (Black and White Remix). -- Carlobunnie (talk) 20:29, 30 May 2022 (UTC)


 * hey try the following:  . This should render like the example below:

≫  Lil- Unique1  -{ Talk  }- 21:46, 30 May 2022 (UTC)


 * Oh, that simple? Thanks! -- Carlobunnie (talk) 22:29, 30 May 2022 (UTC)
 * Just jumping in here to say that I've avoided using adjacent parentheses in track listings after somebody alerted me to MOS:PAREN: "Avoid adjacent sets of brackets. Either put the parenthetical phrases in one set separated by semicolons, or rewrite". So per that, it's probably best to put "featuring artist; ABC remix".  Ss  112   05:28, 31 May 2022 (UTC)
 * Noted, and thanks for bringing it to my attn. Wasn't aware the MOS covered it. -- Carlobunnie (talk) 07:58, 31 May 2022 (UTC)
 * Ooo I wasn't aware of that either . Thanks for pointing out! I'll be sure to correct any instances I see of it, and avoid using next time. ≫  Lil- Unique1  -{ Talk  }- 08:07, 31 May 2022 (UTC)
 * Just a friendly hijack of this topic: I know we routinely use  for live tracks and remixes, but what about when the word "(Remix)" or "([Something] Mix)" forms part of a song title? Surely that goes under   and not  ? I can't think of good examples right now, other than "Symphony of Destruction (The Gristle Mix)". We wouldn't put the latter part under , surely? Mac Dreamstate (talk) 20:02, 31 May 2022 (UTC)
 * Correct. If it's part of the title then that's different. Plenty of songs have appended subtitles/parenthesis. ≫  Lil- Unique1  -{ Talk  }- 20:09, 31 May 2022 (UTC)

Correct format for sub-tracks?
As far as I can tell, this template doesn't handle sub tracks well, which is a problem for something so common. Historically, tags and asterisks have been used, but this generates lint errors; using smalldiv fixes the lint issues but leaves a dangling quotation mark (also note the manually added " after the title, as it is otherwise lost). Consider the following example:

Is there a format that works properly without generating bad HTML5? If not, can the template be improved to handle this type of work natively? pauli133 (talk) 13:38, 30 October 2021 (UTC)
 * I am guessing that this will need an update to the module. Currently it surrounds the title with double quotes, including the case when the title is multiple lines and includes a div, which is where the dangling double quote is coming from. Having said that, I am curious as to what the formatting with tags and asterisks looked like. I understand that we can't use it because of the linting errors, but perhaps it might provide some inspiration for a new format. Are you aware of anywhere where it was used? — Mr. Stradivarius  ♪ talk ♪ 14:25, 30 October 2021 (UTC)
 * Examples: sub tracks without extra markup, sub tracks with encompassing small tags; generates lint errors, small tags on each individual item pauli133 (talk) 14:35, 30 October 2021 (UTC)
 * Another 2 examples at https://en.wikipedia.org/w/index.php?title=American_Idiot&oldid=1057019225. -- I need a name (talk) 16:41, 29 November 2021 (UTC)

Picking up on this again, since nothing seems to have changed (see the earlier example). Look at this case adapted from 01011001, where there's more than one set of subtracks; I've got tags on each line instead of the smalldiv above, and we get different strange behavior:

This uses different bullets for sub tracks if there is more than one set, which cannot possibly be intended. pauli133 (talk) 14:07, 21 March 2022 (UTC)


 * I'm not sure what the knock on impact for "Accessibility would be". I suspect it might be better to instead display each track as: "Beneath the Waves": "Beneath the Waves" / "Face the Facts" / "But a Memory..." / "World Without Walls" / "Reality Bleeds" which is how we display medleys. Otherwise maybe a list forward would be better without using the template tbh. ≫  Lil- Unique1  -{ Talk  }- 21:55, 30 May 2022 (UTC)
 * Ok, so I've created an account solely for this: A workaround seems to be using : instead of * for the subtracks. This doesn't fix the "-line one gets when using, but it does at least yield a presentable and consistent layout if we remove smalldiv. I've taken the liberty of editing 01011001 to showcase this. Recipriversexclusion (talk) 22:03, 24 August 2022 (UTC)
 * Interestingly, my workaround does not fix these slight inconsistencies for the mobile version. Similar to the shift in pauli133's example above with the bullet points it keeps a reduced shift (tab space?) after the second item with subtracks. Recipriversexclusion (talk) 22:17, 24 August 2022 (UTC)
 * Another reason why I have never liked this template... Richard3120 (talk) 22:33, 24 August 2022 (UTC)

Removing auto-quotes from track titles
Hey, this is a bit of a niche situation but still one that comes up enough that I feel it's worth mentioning.

There's certain situations in which bands make a multi-part song with different writers for each section, and when putting the individual writers next to each section, it would be nice to be able to remove the automatic quotation mark that inevitably appears to the right of the last writing credit. Examples of what I mean are the "Refrain" section of the title track from Terrapin Station and the "As Sure as Eggs is Eggs" section from "Supper's Ready" on Foxtrot. Usually this could be fixed by using the numbered list but with multiple vocalists and whatnot these track lists actually do benefit from the template. So it would be nice if it didn't have to say - (Banks, Gabriel)" - and instead say (Banks, Gabriel) without the quote. Thanks - Elephantranges (talk) 18:47, 18 October 2022 (UTC)


 * I'd argue per WP:TRACKLIST, it is a relatively simple track listing that could and should be presented in a different format rather than editing the template for quite a niche scenario. Templates provide standard formatting styles. Any deviation like that present at Terrapin Station risk being not WP:ACCESSIBLE. >> Lil-unique1  (  talk  ) — 19:20, 18 October 2022 (UTC)

Footnotes param
So I'm looking at ReWiggled and see in its track list a footnote on two tracks mentioning that they don't appear on the vinyl version of the album. But those footnotes are placed against the track titles, thus landing inside the quotation marks around the song names. Maybe it's just me, but I think that's an innapropriate placement. The one solution that had ever crossed my mind was to just drop it in the note# parameter (e.g. Diamond Star Halos), but ever since I've just thought that looked silly. I think a more elegant solution would be good to have, and what I'm thinking is a special parameter just for footnotes that would place it immediately after the quote marks around the song titles with no space between, just how any other reference should be placed in prose. Is that doable, and is it wanted by anyone other than just me? QuietHere (talk) 05:22, 17 January 2023 (UTC)


 * Isn't that what the note field is for e.g. (doesn't appear on the vinyl edition) or just add it as a note below? Doesn't need efn or note. >> Lil-unique1  (  talk  ) — 09:30, 17 January 2023 (UTC)
 * Oh yeah, I guess that makes sense. It does take up a bit more space than I'd like but I guess that's forgivable. Thanks! QuietHere (talk) 23:38, 17 January 2023 (UTC)

Deprecated params...
So with being empty, it would follow that support for those parameters can be removed, yes? I would suggest removing those parameters from Module:Track listing/configuration (lines 31-35) and then removing Module:Track listing lines 224 and 230-236. Just want to make sure I'm not missing anything. -- Zack mann  (Talk to me/What I been doing) 00:09, 24 January 2023 (UTC)


 * Makes sense to me. >> Lil-unique1  (  talk  ) — 16:18, 22 February 2023 (UTC)

Note parameter for covers
I've always thought using  for covers is a great idea. This edit removed one such instance and retained only the  parameter to indicate a song not written by the album's artists. I fail to see how this is an improvement. If a song is a cover, and there isn't an article for the original, why not state as such? Mac Dreamstate (talk) 15:40, 22 February 2023 (UTC)


 * There's no set guidance, but yes the note parameter can be used for that purpose. >> Lil-unique1  (  talk  ) — 16:19, 22 February 2023 (UTC)

Module for checking for unknown parameters
It would be useful to have Module:Check for unknown parameters here, as there are quite a lot of errors filled in per this. All the parameters are probably listed in TemplateData section (hoping nothing is missing there). Solidest (talk) 09:43, 17 June 2022 (UTC)
 * ✅ Adding this check for templates that use modules is a little tricky. I messed up the first time because I failed to RTFM about using regular expressions in the check, so there are a couple thousand false positives in the category now that will clear out soon. If you find additional supported parameters that should be added to the check, please let me know by posting here. – Jonesey95 (talk) 16:33, 17 June 2022 (UTC)
 * It looks like this tracking category has settled at just over 3,000 articles, or about 3% of all articles that use the template. This does not include about 30,000 templates using collapsed (see below). – Jonesey95 (talk) 17:31, 19 June 2022 (UTC)

Is "number" a supported parameter?
Pinging re this set of changes that appear to include support for number or numbern. It is used in Mes premières vraies vacances and other articles. Is this a supported parameter? If so, can you please document it? It will also need to be added to the list of known parameters in the template (not module) code, either as "number" or a regexp. Thanks. – Jonesey95 (talk) 17:13, 17 June 2022 (UTC)


 * I'm not sure where I've added numbern. Also if I recall the code correctly, self.number is an internal variable and not a template parameter. In that I mean, the module knows itself what the number of the track is without needing user input. Gonnym (talk) 18:11, 17 June 2022 (UTC)
 * Why does the parameter exist if it still renders as a standard list? ≫  Lil- Unique1  -{ Talk  }- 18:11, 17 June 2022 (UTC)
 * It could just be coincidence that some instances of this template use numbern, which does not appear to do anything. There are a lot of strange parameter usages out there, since the template has never had parameter tracking until today. – Jonesey95 (talk) 20:11, 17 June 2022 (UTC)
 * It wouldn't surprise me if pre-Lua those parameters were there. Gonnym (talk) 20:39, 17 June 2022 (UTC)

Is "collapsed" really deprecated?
I read through all of the discussions, and I haven't been able to figure out whether there is consensus to deprecate and remove collapsed. It appears to be used in 30,000 articles, but it does not do anything (and has not since March 2020, apparently, when an editor with a long block record for edit warring removed the functionality). The tracking category,, that is supposed to track it does not work; I can make it work again if people are interested, but I think it is more important to sort out whether this functionality is wanted or not. If it is not wanted, I can ask for a bot to remove all 30,000 usages of the parameter (limiting the bot's operation to blank, "y", "n", "yes", or "no", case-insensitive, so that humans can sort out the edge cases). – Jonesey95 (talk) 17:13, 17 June 2022 (UTC)


 * It was removed because of MOS:COLLAPSE, where it says Collapsible templates should not conceal article content by default upon page loading. I pointed this out and it was removed soon after on the basis that was not negotiable per MOS:ACCESS. Surely a BOT could remove the depreciated parameter? ≫  Lil- Unique1  -{ Talk  }- 18:10, 17 June 2022 (UTC)
 * I agree with Lil. This clearly fails MOS:COLLAPSE. Gonnym (talk) 18:12, 17 June 2022 (UTC)
 * I also agree that collapsing should not be allowed in this template per MOS, but the history of this parameter is contentious. If you read the 2014 discussion linked from the documentation, you will see (AFAICT) that the parameter was deprecated, then immediately disabled without removing it from the articles that used it, then re-enabled. At some point, a tracking category was added. There were a few subsequent discussions, and then in 2020, the functionality was removed, and the categorization broken, by a many-times-blocked editor. The history is contentious enough that I think we need to establish a new consensus before requesting that this parameter be removed from 30,000 articles. Someone should dig through the archives and ping participants in the three or four or five(?) previous discussions. – Jonesey95 (talk) 20:33, 17 June 2022 (UTC)
 * I disagree - the MOS:COLLAPSE is very clear collapsing isn't to be used. I think that's reason enough to have it removed. its inclusion is superfluous because functionality is, at present, disabled and will remain that way. Having a consensus to remove the inclusion of the code is pointless. If the consensus conceded keeping it on the off chance the functionality is re-enabled then that opens the doorway for this template to deviate from others in a way that goes against MOS and in a way which other templates don't. ≫  Lil- Unique1  -{ Talk  }- 20:39, 17 June 2022 (UTC)
 * I, again, agree with Lil. The consensus lies with the guideline, not with any template or local consensus. Also worth reminding that collapsed content has issues of not working on mobile. Gonnym (talk) 20:41, 17 June 2022 (UTC)
 * Exactly. We shouldn't be creating forks in process where locally a small group of editors can opt to deviate from the MOS just because "they don't like it". ≫  Lil- Unique1  -{ Talk  }- 20:43, 17 June 2022 (UTC)
 * I have enabled the tracking category in article space. It should populate with about 30,000 articles. Once it is populated, we can submit a bot request to delete this parameter from the affected articles. – Jonesey95 (talk) 04:42, 25 August 2022 (UTC)
 * YAY! >> Lil-unique1  (  talk  ) — 12:31, 25 August 2022 (UTC)

"collapsed" parameter while edit preview
Following a request at WP:BOTREQ, I have filed a bot request for the task of removing "collapsed" parameter, after checking that it was deprecated through consensus. My only doubt is, while I was testing my code, and previewed my edits with some articles having "collapsed" in the template. Generally, in edit previews with unknown/deprecated infoboxes there is a warning about these parameters. Would it be worth to add similar warning/notice in preview if "collapsed" is being used? I am not sure if people are still inserting the parameter, or if all the current instances were added a while back. There are currently 13k entries in Category:Track listings that use the collapsed parameter. Maybe we can think about that notice if the category gets a lot of pages again after clearing it. —usernamekiran (talk) 10:34, 19 April 2023 (UTC)
 * I have removed collapsed from the list of supported parameters in the parameter check. An error message shows in preview now. This will temporarily increase the size of (in the "Co" section of the TOC) until the AWB run is complete. – Jonesey95 (talk) 13:18, 19 April 2023 (UTC)

Remove "collapsed" from presets
All the presets still have the collapsed parameter despite it having been deprecated nearly a decade ago. Is there a reason why that hasn't been removed from all of those yet? And if not, shouldn't it be? Just seems like a waste of space. QuietHere (talk &#124; contributions) 00:06, 22 April 2023 (UTC)
 * What do you mean by "presets"? What page are you looking at? If the page is not protected, you can remove it. – Jonesey95 (talk) 02:33, 22 April 2023 (UTC)
 * @Jonesey95 was referring to Template:Track_listing. Turns out those are all unprotected so I will remove the parameter now. QuietHere (talk &#124; contributions) 07:56, 29 April 2023 (UTC)

Extraneous full stop with all_writing
Killing Is My Business... and Business Is Good! being just one of many examples. Can we please get rid of the one after the ref? Mac Dreamstate (talk) 19:34, 7 August 2023 (UTC)
 * Done and documented. Module editors should feel free to implement this change in a more sophisticated way if desired. This will probably cause many articles to be missing their terminal punctuation, so this change might be controversial, but as the module was written, there was no good way to include a reference at the end of the sentence. – Jonesey95 (talk) 15:46, 8 August 2023 (UTC)

Pseudo-splitting total length
I've never seen this done with. Not really feeling it. Mac Dreamstate (talk) 19:49, 22 January 2024 (UTC)