Template talk:Track listing/Archive 20

Archive 15

←

Archive 18

Archive 19

Archive 20

Archive 21

References and citations

This template needs a parameter to handle references and citations to support track information. Binksternet (talk) 03:02, 30 July 2020 (UTC)

@Binksternet: Where in the template output would you put the references and citations? — Mr. Stradivarius ^{♪ talk ♪} 06:17, 5 September 2020 (UTC)

Certainly there should be a spot at the top for one reference supporting all the track information. It would follow the headline.

If we are getting more detailed, then we could have a place for the overall reference at the headline, and another optional place at each track listing, just in case there are specific references for specific tracks. Binksternet (talk) 06:23, 5 September 2020 (UTC)

It would be good to have an optional column on the far right titled Ref. or something similar. Tboa talk. 10:54, 5 September 2020 (UTC)

Song titles and Interlanguage links

I was wondering if there's a proper way to make use of Template:Interlanguage link within the |title= fields. Using {{ill}}, one can have Finishing The Hat – 2 Pianos or, ideally what would be displayed in the article, "Finishing The Hat – 2 Pianos", but as the Track listing automatically puts quotation marks around whatever is listed in the |title= field, there's no way to have the bracketed link to another language's Wikipedia outside the quotation marks. At least that's how I understand it, am I correct?

No.	Title	Length
1.	"Finishing The Hat – 2 Pianos"
2.	""Finishing The Hat – 2 Pianos""

A third option is to not make use of the template altogether and just pipe-link to the other Wikipedia, but this isn't ideal as it's a bit of a WP:SURPRISE (see Help:Interlanguage links#Inline links (links in the text of the article)) and also, unlike the {{ill}}, won't automatically switch over if an English article should be created:

No.	Title	Length
1.	"Finishing The Hat – 2 Pianos"

Curious if other editors have figured out what to do in this situation, thanks! Umimmak (talk) 21:21, 18 July 2020 (UTC)

The capitalization is wrong, should be "Finishing the Hat", but I prefer to use {{ill}}, or even creating articles if the subjects meet English notability criteria. Walter Görlitz (talk) 21:33, 18 July 2020 (UTC)

The capitalization isn't the important part of my example. And yes I would prefer to use {{ill}} as well, but as I have mentioned it doesn't work in this template putting the quotation marks in the wrong place. I don't think it meets English notability criteria to be honest, but since it already exists in French Wikipedia I thought it would still benefit the reader to link it. Umimmak (talk) 22:33, 18 July 2020 (UTC)

I see, the old template inside a template issue. I like your idea of linking in prose. Walter Görlitz (talk) 22:35, 18 July 2020 (UTC)

Have you considered just using the available note parameter, so that it'd appear:

No.	Title	Length
1.	"Finishing The Hat – 2 Pianos" (fr)

Seems like the best option. Homeostasis07 (talk/contributions) 22:23, 5 September 2020 (UTC)

S&M2

Could someone take a look at the s&m2 track listing. The way it is right now, the album reviews template is affecting the size of the disk 1 listing, but not the disk 2 listing. Does anyone know how to make the sizes consistent?  Bait30  ^{Talk 2 me pls?} 20:09, 5 September 2020 (UTC)

Add more text to the Critical reception section is the easy answer, or expand the article with a Commercial performance section. The reason it's doing that is because there isn't enough text to wrap around the box, so the box protrudes into the next section. I don't know if there's anything anyone can do here to fix that. This issue should resolve itself as the article progresses (was only created 2 days ago). Homeostasis07 (talk/contributions) 22:30, 5 September 2020 (UTC)

I have fixed it, I just put template:clear at the end of the previous section. Tboa talk. 22:44, 5 September 2020 (UTC)

Original album

I would like to propose adding an extra optional column for the original album, which would be useful for live or compilation albums. This would be far better than having them in brackets, which can become messy very quickly. Tboa talk. 18:09, 4 September 2020 (UTC)

You can already do that with this template... just use the parameter extra_column = Originally on or something similar. See Cross Road (album)#Track listing, for example. Richard3120 (talk) 19:29, 4 September 2020 (UTC)

You can't if the extra column is already in use for something else, and I had been thinking the original album column could appear immediately between the title and writer(s) column. Alternatively, perhaps it would be useful to allow two extra columns. This could be done with extra_column_B = . Tboa talk. 10:51, 5 September 2020 (UTC)

Ah okay... this has also been brought up before at Template talk:Track listing/Archive 19#Adding columns?. My concern then was that on a mobile/cellphone four columns plus track timings would make for very squashed columns, but there didn't seem to be any strong opposition to the proposal. Richard3120 (talk) 14:14, 5 September 2020 (UTC)

Ah, thank you. I'm inclined to agree with what Popcornfud said there, that adding another column can sometimes be a lesser evil than cramming separate pieces of information into one column. Tboa talk. 22:35, 5 September 2020 (UTC)

Yeah, I still feel that how tables will look on mobile shouldn't be our first priority. Tables rarely look good on mobile anyway. Popcornfud (talk) 22:40, 5 September 2020 (UTC)

There doesn't seem to be any opposition to this proposal, so I'm going to go ahead and make an edit request for this.

Add a second extra column, with a changeable title, called extra_column_B, to appear immediately to the right of the current extra_column. Tboa talk. 22:08, 8 September 2020 (UTC)

Just my 2¢, and feel free to ignore it in the interest of getting something done sooner rather than later... Generally, additional parameters like this have numeric suffices, not alphabetic ones, with the #1 aliasing to an unsuffixed parameter.

Put more clearly, I suggest that the new parameter be named extra_column2 and that optionally extra_column1 be added as an alias for extra_column. TJRC (talk) 22:13, 8 September 2020 (UTC)

What values are commonly used for these blank columns? If a usage is common, it should be implemented properly. ProcrastinatingReader (talk) 23:02, 8 September 2020 (UTC)

The issue with putting extra_column2 is that each row has a number, for example:

| title1        = 
| writer1       = 
| extra1        = 
| title2        = 
| writer2       = 
| extra2        = 

B would make it easier to distinguish as you would have:

| title1        = 
| writer1       = 
| extra1        = 
| extraB1       = 
| title2        = 
| writer2       = 
| extra2        = 
| extraB2       = 

I like the idea of having an alias, though I feel that might over-complicate things for editors who are not familiar with the template. As for the commonly used values, I was originally proposing having a column for Original album, which would be used for live and compilation albums (see the discussion above), though Template talk:Track listing/Archive 19#Adding columns? shows there could be other uses for an extra column. Tboa talk. 12:17, 9 September 2020 (UTC)

I have disabled the request because it seems that discussion is ongoing. When you've agreed the details we will need the proposed code on Module:Track listing/sandbox and then reactivate the request. Thanks — Martin (MSGJ · talk) 12:36, 11 September 2020 (UTC)

Thanks. There was opposition, the requester just didn't hear it as such. I assumed that "use the extra column" would be enough, but the requester decided that mobile layout doesn't matter and is apparently using the template on articles with too much information. We want to keep the template simple and adding unnecessary columns is not going to help with that. So just in case it was missed, I Oppose the proposed change as unnecessary. Walter Görlitz (talk) 05:43, 12 September 2020 (UTC)

Addition of song anchor links and row headers

I've modified Module:Track listing/sandbox with the following changes:

1. Added an ID attribute, which allows WP:ANCHOR links from song redirects to their correct position in the article. The current style is "#track<>" (#track3) but that can change to something else if there is a better name.
2. Changed the "number" and "total length" cells from td to th and added the row scope attribute (see Wikipedia:Manual of Style/Accessibility/Data tables tutorial for more info on scopes), as they are the table headers of the rows.

Please ping me if there are any questions or comments. --Gonnym (talk) 06:00, 11 November 2020 (UTC)

@Gonnym: Your edit to Module:Track listing has had the effect of turning the numbers in the "No." column (e.g. 1. 2. 3.) bold. This makes it look like the focus of a track listing is on the numbers. Also, this is a significant visual change that a lot of users may not agree with and you should have sought consensus first instead of just proposing what changes you were going to make a week beforehand. The track numbers shouldn't be bold. Lk95 (talk) 13:53, 18 November 2020 (UTC)

Waiting for a week for comments is exactly what seeking consensus is. Also, don't make a mountain of a molehill. Making the number de-bold is just a adding one CSS property. The behind-the-scene code of actually calling a table header a table header, does not need to seek consensus as it's already established as part of the accessibility guidelines (and the even wider HTML 5 specifications). --Gonnym (talk) 14:29, 18 November 2020 (UTC)

the bold number thing is stylistic. Editors previously expressed a desire for non-bold first column headings but the overall changes are positive so thank you Gonnym. Am I right in thinking that the "heading" function is now a necessity per MOS:TABLE, because the template track listing effectively renders a table? ≫ Lil-Unique1 -{ Talk }- 14:53, 18 November 2020 (UTC)

The module creates an html table at line 458. The columns were already correctly setup as 'th' (table headers), but the rows weren't. How to visually show a header is more open to preference (though that too needs to pass accessibility if colors are used, and other MoS guidelines), which is why not having it bold is ok, but setting it up as a header is important. --Gonnym (talk) 15:01, 18 November 2020 (UTC)

Width customization

If you have a 15-inch monitor or wider, it can be uncomfortable to read the tracklisting template because it would stretch out the information across the screen. Especially when certain templates only reflect the track number, title, and length. It would be better to give the options to reduce the overall width of the template. The best width (in my humble opinion) should be the remaining percentage a standard infobox isn't using. This would be beneficial for articles where there are multiple track listings that affect the size because of the infobox. For example, Music of Minecraft, Music of Final Fantasy X, and Music of Kingdom Hearts show the track listing template in varying sizes because the infobox is interfering with it. I personally would also like to see templates have an option to be reduced at 50% too for more basic track listings, but I hope this idea gets off the ground.Blue Pumpkin Pie (talk) 18:09, 5 February 2021 (UTC)

The issue is not with the size of screen but with the lack of detail. There are other track listings that incude multiple songwriters and producers in the list, or others with compilations that list the original album, etc. Unless there's a reason to force 100% width, we should consider removing that "feature". Walter Görlitz (talk) 18:24, 5 February 2021 (UTC)

@Walter Görlitz: What if we add parameters for "Small", "Medium" and "full"? Small takes 50%, medium takes 75%, and "Full"or default uses 100%?Blue Pumpkin Pie (talk) 18:35, 5 February 2021 (UTC)

This is why I have never liked the use of the template when all songs have essentially the same writer(s) and producers and there is no other information – I much prefer something closer to the simple numbered list style in these cases, rather than have a huge gap between the song titles on the left of the screen and the track lengths on the other side, which looks absurd to me. Richard3120 (talk) 18:55, 5 February 2021 (UTC)

It is already possible to alter the width of the columns in the template (there are fields for that) but I agree with others above - it has become too widespread in its use when it doesn't need to be. ≫ Lil-Unique1 -{ Talk }- 20:46, 5 February 2021 (UTC)

@Lil-unique1: Adjusting the columns isn't available for title. I'm sorry but i thought everyone here so far was saying there's no need to have the template be at 100% width and were agreeing with the criticisms for it. What do you mean the template has become too widespread?Blue Pumpkin Pie (talk) 20:56, 5 February 2021 (UTC)

Column width is not the only issue, it's that the whole table is forced to be 100% width that causes problems visual problems, even with the zebra striping (alternating rows of white and grey background). The example of the Beatles' track listing is a great example. On a reasonable size monitor, the amount of whitespace between the text of the title and the time is greater than the horizontal space used for any specific song title. Walter Görlitz (talk) 00:22, 6 February 2021 (UTC)

@Blue Pumpkin Pie: apologies if I misunderstood your original point. What I was saying about widespread use was that it seems to have become the defaut/go to for track listings even when it is problematic. ≫ Lil-Unique1 -{ Talk }- 00:24, 6 February 2021 (UTC)

This template (module) is another example of people force-feeding a table with constraining parameters to make it "look good" (for some sighted people using some constellation of display/browser/resolution/whatever), when the appearance for others / in other situations is much less than optimal. HTML tables are (nowadays) quite able to suitably adapt to the constraints imposed by data quantity, user agent width, font size, etc.

The 100% width setting should be done away with, IMO, as it adds unnecessary space in many circumstances. Moreover, the code seems to expect (1) that the editor wants a 100% wide table and (2) that any adjustments to column width are going to be in % values.

@Blue Pumpkin Pie: you said above that Adjusting the columns isn't available for title, but in fact, the parameter title_width= lets you do exactly that. And (good news!), you can get useful results with something like title_width=25em, which appears to include the disarming of the 100% table width. Of course, doing this presumes you know what the viewer is going to see, which you don't.

The only good result of having 100% set as the table width, is that it can make multiple tables on one page have a consistent appearance. But as you may or may not be able to see at Music of Minecraft, there's no guarantee (thanks, infobox!). So I would kill that (100% fixed width), leave the column widths settable (as they are now), and amend the documentation to suggest using em units rather than (or as an alternative to) percentages. Your suggestion to Walter about "small, medium, full" would lead, I'm convinced, to complications in use and greater unpredictability of display. — JohnFromPinckney (talk) 07:05, 6 February 2021 (UTC)

If this is done, perhaps examples that use variable width should be added to the documentation. Since "unpredictability of display" is such a concern, a couple visual examples might help ease the burden of that issue. Actually, those should be added anyway, at least for the existing column width options. QuietHere (talk) 20:15, 7 February 2021 (UTC)

@Lil-unique1: Why is it problematic to use a template designed for track listing being used from the get-go? It looks pretty professional and appealing. What other templates would make the track listing information look presentable? It's a catch-22 in my opinion to keep making this template be reserved for some track listings and not all. But reading from what everyone else have said so far, from my understanding, it's not beneficial overall to keep it at 100% width.

@JohnFromPinckney: I see the title_width, and i do see it resolves the issue to a degree if you choose the proper size. 50% doesn't keep it consistent across the board but 75% does. If coded properly, i don't see the problem on having templates be adjustable to small medium or full. But the reason why i didn't choose the option to customize each individual column was because it may seem to cumbersome to keep adjusting each column. But if thats what everyone else prefers, then i have no problem with that and i would support it. My only goal is that the template can be adjustable to size.

But just so i'm understanding everyone here who has voiced there thoughts on the topic, is 100% default width really beneficial overall? is adjusting the default width should be into consideration?Blue Pumpkin Pie (talk) 04:51, 8 February 2021 (UTC)

The template is (well, would be) "adjustable to size" naturally based on content and available width. It should not be forced to 100%, and I don't consider that a useful default. — JohnFromPinckney (talk) 10:03, 14 February 2021 (UTC)

Mobile app appearance

Tracked in Phabricator
Task T285114
Resolved

The appearance on the Wikipedia mobile app and probably the mobile website makes the track listing template unreadable. You can only see the songs with links on them. Forgive me if this is the wrong place for this feedback. Will provide screenshot if needed. --Jennica✿ / ^talk 17:28, 11 May 2021 (UTC)

Hi, Jennica. Sorry, I can't reproduce the problem. I don't have the app, but I looked at the template page with my super-duper iPhone 5, and everything looked fine (after having turned to landscape to avoid trimming of times at right).

Are you seeing this at the template page or on some particular article(s)? — JohnFromPinckney (talk) 23:04, 11 May 2021 (UTC)

On a separate note, I do not believe that there is an official mobile app for any platform. Others may have created wrappers for a browser. What OS and what is the name of the app? Walter Görlitz (talk) 20:19, 12 May 2021 (UTC)

I usually view and edit pages with Firefox in Windows, MacOS or Ubuntu and these landscape orientations on larger monitors present well. Looking at Blood on the Tracks#Track listing and The Best of Talking Heads#Track listing on my iPhone 6 in portrait orientation are quite cramped as there are three columns of data. Taylor Swift (album)#Track listing and Starboy (album)#Track listing are almost illegible because of all of the bulleted lists and volumes of data. I'm sure some albums with more data than this would overload a small screen that is in portrait orientation. Walter Görlitz (talk) 20:30, 12 May 2021 (UTC)

@JohnFromPinckney:: It is on the Android app with dark mode enabled. --Jennica✿ / ^talk 04:02, 15 May 2021 (UTC)

Are you seeing this at the template page or on some particular article(s)? — JohnFromPinckney (talk) 12:25, 15 May 2021 (UTC)

@JohnFromPinckney: I provided some pages where obvious problems are present. Walter Görlitz (talk) 21:20, 21 June 2021 (UTC)

To clarify, there's two different sets of problems here. Not seeing some content in the dark theme of the official Wikipedia Android/iOS apps: someone else has also reported this, and it's being tracked as phab:T285114. And more general issues with the table layout on the mobile website/apps. the wub "?!" 09:53, 22 June 2021 (UTC)

The issue with the dark themes has now been resolved. the wub "?!" 20:23, 4 July 2021 (UTC)

headline and all_writing ordering

Are headline and all_writing rendered in the correct order? On the Sound System (album) article the writing credits do not appear in their correct sections. Is this right or has the template been badly used in this case? OutOnParole (talk) 15:20, 23 August 2021 (UTC)

Instead of using note1 etc., the parameter writer1 should have been used instead. Regarding your specific query, I think it's because headline and all_writing are assumed to be used for just one CD... it wasn't thought how it would look for box sets. Richard3120 (talk) 15:29, 23 August 2021 (UTC)

Template-protected edit request on 13 November 2021

The strings in this portion of the template do not need "are" or "is" in them:

function TrackListing:makeIntro()
	if self.all_writing then
		return string.format(
			'All tracks are written by %s.',
			self.all_writing
		)
	elseif self.all_lyrics and self.all_music then
		return string.format(
			'All lyrics are written by %s; all music is composed by %s.',
			self.all_lyrics,
			self.all_music
		)
	elseif self.all_lyrics then
		return string.format(
			'All lyrics are written by %s.',
			self.all_lyrics
		)
	elseif self.all_music then
		return string.format(
			'All music is composed by %s.',
			self.all_music
		)
	else
		return ''
	end
end

—Hugh (talk) 07:40, 13 November 2021 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. – Jonesey95 (talk) 16:25, 13 November 2021 (UTC)

Just to point out that the template used to say "all songs written by..." without the auxiliary verb until a couple of years ago, just as HughLilly suggests above... the editor AlanM1 raised the issue of adding "is/are" at Template talk:Track listing/Archive 19#all writing and related parameters in September 2019, but I don't know who made the change or when it happened (I'm not a coder, so I wouldn't have a clue where to look for the change in the edit history), and I don't recall any discussion to get consensus to make the change to its current wording. Richard3120 (talk) 18:23, 13 November 2021 (UTC)

That edit was made here by AlanM1. It's clearly a good-faith edit based on his citation of the discussion he started at all_writing and related parameters that received no objections; but now that I see it i would favor going back and dropping is/are. TJRC (talk) 19:35, 13 November 2021 (UTC)

Thanks TJRC – I would probably favour the removal of "is/are" as well, as this is the standard way of writing credits. This should probably be raised at Wikipedia talk:WikiProject Albums as well, as obviously the change will affect album articles, and there are usually more editors watching that page to give their input. Richard3120 (talk) 19:44, 13 November 2021 (UTC)

Removing the "is" or "are" from those notes is fine with me, but the trailing periods should be removed as well since they are no longer sentences. —[AlanM1 (talk)]— 21:48, 13 November 2021 (UTC)

I agree with your point about the periods. TJRC (talk) 22:05, 13 November 2021 (UTC)

Good idea; that's closer to typical use in actual recordings. But: how would we feel about: All lyrics by %s and All music by %s? I just checked my music collection and, among the first six albums I found with some flavor of "all X by Y", Wish You Were Here and Escape leave out the verb altogether, as does The Rhythm of the Saints ("all words and music by Paul Simon except..."), All That You Can't Leave Behind uses "all titles written by U2...", and Californication and Right Down the Line: The Best of Gerry Rafferty have "all songs written by ...". So my random, non-scientific survey comes up with about 50% verbed, 50% non-verbed. Thoughts? — JohnFromPinckney (talk / edits) 23:32, 14 November 2021 (UTC)

All of these are available options, @JohnFromPinckney: Instead of using the "all_writing=" parameter which is being discussed here, one can instead use the "all_lyrics=" and "all_music=" parameters, depending on which works best for a particular album. Hope this helps. Homeostasis07 (talk/contributions) 00:16, 15 November 2021 (UTC)

Sorry, that does not seem to be correct. From the code extract at the top of this section (and my perusal of the actual code), the |all_lyrics= and |all_writing= parameters use both the auxilliary and main verbs (cf. e.g., line 348 'All lyrics are written by %s; all music is composed by %s.'). And in fact, I understood that we were discussing those params, too. — JohnFromPinckney (talk / edits) 01:06, 15 November 2021 (UTC)

Note: as Richard3120 suggests, I've notified WikiProject Albums. TJRC (talk) 22:12, 13 November 2021 (UTC)