Template talk:Track listing/Archive 19
This is an archive of past discussions about Template:Track listing. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 15 | ← | Archive 17 | Archive 18 | Archive 19 | Archive 20 | Archive 21 |
Adding columns?
Is there some way to add new columns to this? I'd like to be able to add an extra column on the tracklist on I Might Be Wrong so I can put the recording date and venue in separate columns. Someone did kindly make a new version of the tracklist to do this, using another table format, but it wasn't as pretty as the tracklist template. Popcornduff (talk) 06:00, 23 July 2019 (UTC)
- Do you mean like this? --Redrose64 🌹 (talk) 18:00, 23 July 2019 (UTC)
- Not sure what I'm looking at there. That's basically the same tracklist that's currently in the article. It has an "extra" column for the venue, but I'd like to have two extra columns so we can write the venue and date separately. Popcornduff (talk) 18:03, 23 July 2019 (UTC)
- @Popcornduff: don't you think having four columns of text plus track timings might become unreadable on a mobile phone/cellphone? Richard3120 (talk) 18:16, 23 July 2019 (UTC)
- The current table on I Might Be Wrong is already annoying on mobile, so I don't think we'd make it much worse. I think adding a column would be a lesser evil than the current state, which crams separate pieces of information into one column. We already have lots of tables with multiple columns on Wikipedia - sometimes they're just the best solution, mobile be damned. Popcornduff (talk) 18:30, 23 July 2019 (UTC)
- I suspect a bit of small text could help there. Notes are already small and do not violate MOS:ACCESS so making the contents of the extra column small shouldn't either. Walter Görlitz (talk) 19:52, 24 July 2019 (UTC)
- Thanks. I've implemented that suggestion and it's a lot more readable. I would still prefer another column, because each column should only have one sort of information in it, really. Popcornduff (talk) 05:29, 25 July 2019 (UTC)
- I suspect a bit of small text could help there. Notes are already small and do not violate MOS:ACCESS so making the contents of the extra column small shouldn't either. Walter Görlitz (talk) 19:52, 24 July 2019 (UTC)
- The current table on I Might Be Wrong is already annoying on mobile, so I don't think we'd make it much worse. I think adding a column would be a lesser evil than the current state, which crams separate pieces of information into one column. We already have lots of tables with multiple columns on Wikipedia - sometimes they're just the best solution, mobile be damned. Popcornduff (talk) 18:30, 23 July 2019 (UTC)
- @Popcornduff: don't you think having four columns of text plus track timings might become unreadable on a mobile phone/cellphone? Richard3120 (talk) 18:16, 23 July 2019 (UTC)
- Not sure what I'm looking at there. That's basically the same tracklist that's currently in the article. It has an "extra" column for the venue, but I'd like to have two extra columns so we can write the venue and date separately. Popcornduff (talk) 18:03, 23 July 2019 (UTC)
I agree to this proposal. I have another use-case where I need 2 extra columns. Most (if not all) Malayalam cinema soundtrack listings include the artists / singers who performed the song (why is that not included the template anyway?). In some articles, there are information about the Raga used for creating the song ( like Sargam (1992 film)#Soundtrack, for example ). I'd like to include both these columns while using the template. shine | talk 12:29, 1 September 2019 (UTC)
all_writing and related parameters
At Module:Track listing, TrackListing:makeIntro()
creates the notes like "All tracks written by value." at the top of the listings for |all_writing=
, |all_lyrics=
, and |all_music=
. It's been pointed out at Wikipedia:Teahouse#Album style question that these are not sentences and therefore should not end with a period. They look odd as non-sentences at the top of a track listing section (e.g. Alice's Restaurant (album)#Track listing). I think they should be written as complete sentences (e.g. "All tracks below are written by value."). Alternatively, they should be notes for |headline=
, rendered in a note section below the listing, though I can see problems implementing this. —[AlanM1(talk)]— 19:41, 28 September 2019 (UTC)
Proper Way to Specify "Subtracks" Like "1a), 1b) ..."
I don't see a way in the current template or discussion in the template article or here on how to handle subtracks such as for several tracks on CD reissues of Vanilla Fudge's self-titled album (ATCO 33-224-2) where the tracks are listed as:
- 5a) STRA (Illusions Of My Childhood-Part One)
- 5b) You Keep Me Hanging On
- 5c) WBER (Illusions Of My Childhood-Part Two)
- 6a) Take Me For A Little While
- 6b) RYFI (Illusions Of My Childhood-Part Three)
- 7a) Eleanor Rigby
- 7b) ELDS
where there are significant differences with the original LP track listing that are reflected in the a), b), ... subtracks.
If I'm reading the template docs correctly, the track numbers are integers "N" in parameters "titleN", "writerN", etc. As such, the above tracks must be specified with parameters "title5" to "title11", etc., resulting in track numbers 5, 6, 7, 8, 9, 10 and 11, which does not accurately reflect the track numbers on the release.
Of course, the desired effect can be done by using simple lists or tables instead of the Track listing template, as is done in some articles (example), but a way to do it with this template might be warranted.
I would be interested in any discussion on this. I might suggest a parameter like "tracknumberN", "trackdisplaynumberN" or "trackrepresentationN" which would typically be unused and default to the "N" in "<parameter>N". But, in the above example, it could be used like:
- | title5 = STRA (Illusions Of My Childhood-Part One)
- | trackdisplaynumber5 = 5a
- | title6 = You Keep Me Hanging On
- | trackdisplaynumber6 = 5b
- | title7 = WBER (Illusions Of My Childhood-Part Two)
- | trackdisplaynumber7 = 5c
- | title8 = Take Me For A Little While
- | trackdisplaynumber8 = 6a
- etc.
Wantnot (talk) 08:41, 18 December 2019 (UTC)
Headlines
Did I miss something about bolding being removed from headlines? → Lil-℧niquԐ1 - (Talk) - 12:42, 6 April 2020 (UTC)
- I must've missed it too. It looks like shit—change it back, guys. Mac Dreamstate (talk) 20:19, 10 April 2020 (UTC)
- Concur. Just adding my vote. --Jennica✿ / talk 23:02, 12 April 2020 (UTC)
Collapsed parameters don't work anymore either. ili (talk) 08:24, 13 April 2020 (UTC)
- That was definitely removed. Walter Görlitz (talk) 05:30, 14 April 2020 (UTC)
Collapsing was removed per consensus. @Lil-unique1, Mac Dreamstate, and Jennica: Happy to change the formatting per your request. Pardon me that I didn't see it: you can always get my attention with {{ping}}. ―Justin (koavf)❤T☮C☺M☯ 08:57, 15 April 2020 (UTC)
- @Koavf: I agree that when the headline parameter is used, it's better in bold. But why is it necessary to add it to every use of the track listing template, as you are doing? For me, I would only use it when perhaps each side of an album has a subheading. I honestly don't see the point of having a section heading for a particular album that says "Track listing" and then immediately under that heading a headline that says "Track listing for the album xxxx"... it seems a duplication of stating the obvious and completely redundant. Richard3120 (talk) 15:39, 17 April 2020 (UTC)
- Richard3120, Per MOS:TABLECAPTION. ―Justin (koavf)❤T☮C☺M☯ 17:16, 17 April 2020 (UTC)
- @Koavf: thanks for pointing me to that... still seems absolutely bizarre and unnecessary to me, though. The MOS says "You would usually need some kind of heading or description introducing a new table anyway"... I would have thought the section heading "Track listing" would have done that job adequately enough, but there you go. Richard3120 (talk) 17:40, 17 April 2020 (UTC)
- Richard3120, Per MOS:TABLECAPTION. ―Justin (koavf)❤T☮C☺M☯ 17:16, 17 April 2020 (UTC)
Suggested changed to bring in line with MOS:ACCESS
I'd like to suggest a few changes for discussion to the template to modernise and bring in line with MOS:ACCESS.
- Firstly, the template arbitrarily displays the song name section as a certain width? Can this be removed or downgraded/made dynamic like standard tables to prevent text bunching which occurs on longer releases and more modern releases where there tends to be a large number of contributors. For example see Phoenix_(Rita_Ora_album)#Track listing where on track 9 the writes and producers begin to blur into each other.
- Can {{hlist}} be built into the {{Track listing}} coding/syntax the same way it has been with Template:Infobox album?
- Can we stop the use of {{small}} by default with notes? Per MOS:SMALLTEXT, it really should really be used sparingly
- Colours used for alternate rows should be checked against Wikipedia:Manual of Style/Accessibility/Colors to ensure compliance
→ Lil-℧niquԐ1 - (Talk) - 14:59, 6 April 2020 (UTC)
- I agree about your first point. It's as if some extra padding is needed between the columns.
- WP:ALBUMSTYLE#Track listing currently only gives examples with commas separating multiple songwriters (I assume you mean in songwriters, and producers). I don't know where the fashion for hlist in track listing came from, but it's never found its way into the nearest thing we have to a style guide, as the examples there show. Right now, the examples for this template are consistent with that section at the style advice page. So I guess the issue should be discussed there first.
{{hlist}} is the prefered class for screen reading technology as it helps the software better distinguish between one item in a list to the next. Many users are now using hlist in the template anyway. If it could be built in then it would reduce the amount of code/syntax in articles whilst also giving users the choice to use commas or the hlist. → Lil-℧niquԐ1 - (Talk) - 09:13, 7 April 2020 (UTC)
- But the issue is not about screen readers, but visual distinction. I would argue vertical zebra-striping—like what the rows do to distinguish new rows—might be worthwhile. Walter Görlitz (talk) 04:42, 9 April 2020 (UTC)
- I'd be all for avoiding small text in the note parameter. It's often the name of the songwriter appearing there, and it makes no sense to reduce their presence, particularly when writers of the majority of the album's songs appear in regular text above the list of tracks.
- I had no idea editors were colour-coding rows in track listings. Even if it's not purely for decorative effect, I agree we should be ultra-discerning about it – or are you saying there's no problem using them, they just have to comply with the hues listed on that page? (But still, why on earth would anyone use colours for rows in a track listing? Wow ...) JG66 (talk) 16:17, 6 April 2020 (UTC)
- @JG66: I think Lil Unique is talking about the alternating white and pale grey colours currently used to distinguish between separate tracks in a track listing, not anything editors have added themselves.
- 1. Agreed. The song title is rarely substantially longer than the total length of the songwriter or producer names.
- 3. Not sure the small text is usually used for songwriters – there's a "writer" parameter for that. It tends to be used either for (a) "featuring" a guest artist, (b) a remix or alternate version of a track, or (c) in the case of bonus tracks, where the track originally came from... B-side, live version, out-take, etc. I don't have any strong preference one way or the other, but in none of these cases it seems crucial that the additional information is in small text, so I wouldn't object to it being converted to standard text size. Richard3120 (talk) 17:11, 6 April 2020 (UTC)
- Ah, thanks for that, Richard3120, understood.
- The situation I meant re note is at, say, Rubber Soul#Track listing. JG66 (talk) 17:19, 6 April 2020 (UTC)
- What I have noticed recently is that when there's something in the parameter "headline=" of the track listing template anymore, it doesn't appear as bold as before. It looks like table captions will become a requirement soon (which are already bold for any other table) so it would make sense to make headlines bold as well. Not sure why the headline parameter would be exempt. -- Lk95 9:17, 9 April 2020 (UTC)
- Lk95, This has since been changed. Thank you for pointing out this inconsistency. Let me know if you need anything else from me re: this module/template. ―Justin (koavf)❤T☮C☺M☯ 09:12, 15 April 2020 (UTC)
- @Koavf: would you be able to make the suggested changes to the template as above? (remove the small formatting for notes), reduce the size of the "title" field, increase the gap between each of the fields so text doesn't bleed into the next column and check that the zebra stripe colours adhere to Wikipedia:Manual of Style/Accessibility/Colors → Lil-℧niquԐ1 - (Talk) - 09:25, 15 April 2020 (UTC)
- Lil-unique1, I'd love to but 1.) that's a lot of work and 2.) I'm up at 5:27. :/ Let me push it back to you: if you can ping me again at some reasonable hour, I'll give it a shot. Even trying now would just be a recipe for disaster. ―Justin (koavf)❤T☮C☺M☯ 09:36, 15 April 2020 (UTC)
- @Koavf: would you be able to make the suggested changes to the template as above? (remove the small formatting for notes), reduce the size of the "title" field, increase the gap between each of the fields so text doesn't bleed into the next column and check that the zebra stripe colours adhere to Wikipedia:Manual of Style/Accessibility/Colors → Lil-℧niquԐ1 - (Talk) - 09:25, 15 April 2020 (UTC)
- Lk95, This has since been changed. Thank you for pointing out this inconsistency. Let me know if you need anything else from me re: this module/template. ―Justin (koavf)❤T☮C☺M☯ 09:12, 15 April 2020 (UTC)
I had no idea what time of the day it was for you (it's 10.56am in the UK). Eek! No worries, if you wouldn't mind putting it on your radar and can look at doing it in the near future. → Lil-℧niquԐ1 - (Talk) - 10:01, 15 April 2020 (UTC)
- So, what, this is with complete disregard for my point above about the need to first raise the issue at WP:ALBUMSTYLE#Track listing, and all the examples given there? JG66 (talk) 09:46, 15 April 2020 (UTC)
- Apologies @JG66: I hadn't seen your note. I can't see any overarching need to consult with WP:ALBUMSTYLE#Track listing as the changes to the template will bring us in line with MOS:ACCESS as well as improve readability. The Album Style project simply outlines how different formats can be used for the track listing. These wholesale changes to the templates don't impact on the other formats. The changes to the coding will automatically update the example. The main change will be the column spacings and also the removal of small formatting which is a long time coming. I'll ping a note on the talkpage but the album style page is about much more than the specific template. → Lil-℧niquԐ1 - (Talk) - 10:01, 15 April 2020 (UTC)
- No worries, and thanks. I don't necessarily agree that there's no need to consult with WP:ALBUMSTYLE, but never mind.
- Personally, I'm dead against using hlist bullets as separators in columns such as songwriters and producers, because they're such significant separators in a way that commas are not – they completely estrange the names from one another, when in fact the relationship between the individuals is most often one of collaboration. I look at a listing for an old-school album like Pet Sounds#Track listing and think, why such a fussy treatment to separate names for bandmates and/or longstanding writing partners? It just looks pretentious and over-designed ...
- Personal opinion, of course, and I'm just being transparent. I appreciate many other editors don't seem to feel the same way, but I wonder if they work on albums where songwriting and producer credits are so straightforward: I'm calling it "old school", by which I mean there are no additional featured artists, no complicated songwriter credits to acknowledge sampled riffs, etc.
- I guess what seals it – and unless I misunderstood, it's what Walter mentioned above – is whether MOS:ACCESS does apply in Track listing, and: is it necessary? If the answer's yes to both, then fine, I can't argue and will have to swallow my aversion to hlist. JG66 (talk) 13:35, 15 April 2020 (UTC)
- Well the point with {{hlist}} is built into {{Infobox album}} so editors can use it or still input commas and commas will display. It won't retrospectively change track listings that don't already use hlist but then it would make it easier to add templates going forward. → Lil-℧niquԐ1 - (Talk) - 14:12, 15 April 2020 (UTC)
- I think the issue is that for longer lists, it should be mandatory for long lists the way it's explained in the docs at {{Infobox album}}. Walter Görlitz (talk) 16:29, 16 April 2020 (UTC)
- JG66, To be clear, MOS:ACCESS applies everywhere. Accessibility concerns are equally valid across the entire web. That doesn't necessarily mean that {{hlist}} is necessary for accessibility but we can't just call a "time-out" on accessibility for just one element of 250,000+ articles. Just clarifying what you mean by your question: Yes, it applies, no, I am not convinced that the solution is necessarily required or the right one, etc. ―Justin (koavf)❤T☮C☺M☯ 22:15, 16 April 2020 (UTC)
- Well the point with {{hlist}} is built into {{Infobox album}} so editors can use it or still input commas and commas will display. It won't retrospectively change track listings that don't already use hlist but then it would make it easier to add templates going forward. → Lil-℧niquԐ1 - (Talk) - 14:12, 15 April 2020 (UTC)
Checklist of requests
Per the above:
- Firstly, the template arbitrarily displays the song name section as a certain width? Can this be removed or downgraded/made dynamic like standard tables to prevent text bunching which occurs on longer releases and more modern releases where there tends to be a large number of contributors. For example see Phoenix_(Rita_Ora_album)#Track listing where on track 9 the writes and producers begin to blur into each other.
- Partly done Column width can be defined by a user by adding it manually. Can you be more explicit about exactly you want Lil-unique1? ―Justin (koavf)❤T☮C☺M☯ 22:08, 16 April 2020 (UTC)
- Can {{hlist}} be built into the {{Track listing}} coding/syntax the same way it has been with Template:Infobox album?
- Not done Decent amount of work and it seems discussion is ongoing. Again, ping me if you need me. ―Justin (koavf)❤T☮C☺M☯ 22:15, 16 April 2020 (UTC)
- Can we stop the use of {{small}} by default with notes? Per MOS:SMALLTEXT, it really should really be used sparingly
- Colours used for alternate rows should be checked against Wikipedia:Manual of Style/Accessibility/Colors to ensure compliance
- Done The lowest contrast with the #F7F7F7 background is about 8:1, which passes A level compliance. ―Justin (koavf)❤T☮C☺M☯ 21:32, 16 April 2020 (UTC)
- Thanks for those Koavf. I wasn't aware that you could manually edit the width of the columns. My suggestion was for a default smaller title column. → Lil-℧niquԐ1 - (Talk) - 19:39, 17 April 2020 (UTC)
- But setting fixed widths may result in issues for mobile users. Walter Görlitz (talk) 20:39, 19 April 2020 (UTC)
Hiding bonus tracks
Is this a good idea? More here.— Vchimpanzee • talk • contributions • 18:21, 6 August 2019 (UTC)
- Yes, it is a great idea. In the case of the Jepsen song, it probably shouldn't be since it involves a redirect. Walter Görlitz (talk) 18:30, 6 August 2019 (UTC)
- I thought hiding in articles wasn't good practice. So what should be done here?— Vchimpanzee • talk • contributions • 18:40, 6 August 2019 (UTC)
- Quite so, MOS:COLLAPSE. --Redrose64 🌹 (talk) 19:20, 6 August 2019 (UTC)
- Again, my question hasn't been answered. Is this case an exception to the rule?— Vchimpanzee • talk • contributions • 14:51, 8 August 2019 (UTC)
- Your question has been discussed and answered before. Please search the archives for "collapse". There was a consensus to remove the "feature", but it was never acted on. Walter Görlitz (talk) 15:12, 8 August 2019 (UTC)
- Also violates WP:SPOILER. ―cobaltcigs 15:34, 8 August 2019 (UTC)
- So what action should be taken, specifically, on the Carly Rae Jepsen album?— Vchimpanzee • talk • contributions • 17:54, 8 August 2019 (UTC)
- If it's vital information just turn the parameter off. You'd have to be willing to prove it's not extraneous or trivial. If it is, maybe it shouldn't be in the article. Walter Görlitz (talk) 18:23, 8 August 2019 (UTC)
- So what action should be taken, specifically, on the Carly Rae Jepsen album?— Vchimpanzee • talk • contributions • 17:54, 8 August 2019 (UTC)
- Also violates WP:SPOILER. ―cobaltcigs 15:34, 8 August 2019 (UTC)
- Your question has been discussed and answered before. Please search the archives for "collapse". There was a consensus to remove the "feature", but it was never acted on. Walter Görlitz (talk) 15:12, 8 August 2019 (UTC)
- Again, my question hasn't been answered. Is this case an exception to the rule?— Vchimpanzee • talk • contributions • 14:51, 8 August 2019 (UTC)
- Quite so, MOS:COLLAPSE. --Redrose64 🌹 (talk) 19:20, 6 August 2019 (UTC)
- I thought hiding in articles wasn't good practice. So what should be done here?— Vchimpanzee • talk • contributions • 18:40, 6 August 2019 (UTC)
"Melt with You" is a redirect to the album but you can't see it without clicking on "show". Otherwise, I have no idea what's considered "vital".— Vchimpanzee • talk • contributions • 19:57, 8 August 2019 (UTC)
- "Melt with You" seems to redirect to I Melt with You. If it redirected to the album, maybe it shouldn't be a redirect as it's clearly not WP:CHEAP in this case, or another target could be found. Unless it was a single, it probably doesn't need to have a redirect to the album either.
- With that said, just change the state so it's visible if it needs to be visible. Walter Görlitz (talk) 20:47, 8 August 2019 (UTC)
- I forgot. It's this redirect I was discussing.— Vchimpanzee • talk • contributions • 21:08, 8 August 2019 (UTC)
- So many other problems with the article. For instance, they collapse the studios in the infobox. The credits and personnel section is backward (person and what they did, not the other way around).
- With the plethora of releases, I feel collapsing them is appropriate. Similarly, I don't think that it needs to be a redirect and nothing links to the song. Walter Görlitz (talk) 21:23, 8 August 2019 (UTC)
- I have no interest in the song. I see you did what I was going to suggest.
ItThe other song came up when I typed "Melt with You" right after the Modern English song was played on the "radio".— Vchimpanzee • talk • contributions • 22:04, 8 August 2019 (UTC)
- I have no interest in the song. I see you did what I was going to suggest.
- I forgot. It's this redirect I was discussing.— Vchimpanzee • talk • contributions • 21:08, 8 August 2019 (UTC)
Removed deprecated parameter
As I did 2.5 years ago, I have removed this functionality and updated the documentation. This consensus is long-standing and in line with the rest of Wikipedia. Track listings should not be hidden, as they are fundamental information in the main namespace about albums, singles, etc. ―Justin (koavf)❤T☮C☺M☯ 23:02, 23 March 2020 (UTC)
- I like this change, but I will note that it makes albums with extensive track listings a bit cumbersome to scroll through, such as Every Open Eye. Mac Dreamstate (talk) 16:54, 24 March 2020 (UTC)
- I don't think these changes were a good idea. I don't understand why all formatting has been removed – why the notes are now the same size as the main title text – and this has all resulted in some massively cumbersome track listing sections (as noted by Mac Dreamstate above, but I could provide several dozen other examples). All of Vchimpanzee's complaints above could've been easily rectified by switching the collapsed='yes' parameter to 'no' on that one particular edition of the Carly Rae Jepsen album. But instead we have a whole mess of corrections that need doing on several hundred other articles. If it ain't broke... Homeostasis07 (talk/contributions) 23:30, 24 April 2020 (UTC)
Track listings that use the collapsed parameter
Category:Track listings that use the collapsed parameter is now empty, presumably as a result of the recent changes, despite the fact there are still many track listings using the parameter. The parameter no longer does anything, meaning it no longer causes any issues, so the category is probably no longer needed. Should we delete the category or fix the tracking? M.Clay1 (talk) 06:38, 19 July 2020 (UTC)
- @M.Clay1 and Koavf: The tracking category was disabled in this edit on 23 March 2020. If there are still track listings that use it, we should probably enable the tracking category again so that they can be cleaned up. — Mr. Stradivarius ♪ talk ♪ 06:15, 5 September 2020 (UTC)
- Mr. Stradivarius, I don't think it really matters. A single line of junk code that in no way impacts the functioning or the appearance of the template is really irrelevant. I suggest adding it as a line in many semi-automated tools like AWB or if it really matters that much, make a bot to remove them but it's just busywork. ―Justin (koavf)❤T☮C☺M☯ 06:17, 5 September 2020 (UTC)