Template talk:Track listing/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Excellent!

Awesome template, thank you! ♫ Cricket02 (talk) 16:14, 13 February 2008 (UTC)

Seems good

It looks decent. Easy enough to use. I think it will help make formatting more consistent. Like, I won't have to remember whether to use an endash or an emdash (if I remember at all). Saves having to put quotes around the songs. I would prefer having no pound sign over the number column. It looks a little weird, and there's really no need for it. Could there be a way to shut off the "hide" button? I like having the option, but I don't like having the link showing if I've decided not to use the option. I used the template at Hallowed Ground. -Freekee (talk) 03:56, 14 February 2008 (UTC)

Okay, now I see things I don't like. The main thing is that the writing credits appear in a column on the other side of the time. I think the author should always appear in parentheses directly after the song title. Also, the table is of fixed width. Is there any way to make it wider if more columns are added? Now the problem with having the composer directly after the song title is that if you have "notes", it gets really messy. See User:Freekee/Sandbox. Would it be possible to have the title/author separated from the notes by a line break? Like this :

1	Manic Depression (Jimi Hendrix) Performed by Seal & Jeff Beck, produced by Jeff Beck, Eddie Kramer and Seal	5:09
2	Hey Joe (Billy Roberts) Performed by Body Count, produced by Ernie C	4:28

With our without the bullet. I can see there would be technical difficulties, but I really dislike the composer column. Is there anything you can do?-Freekee (talk) 05:10, 14 February 2008 (UTC)

Oh, now I thought the composer column was the best part, I know of many various-artist compilation albums where that will be useful too. Maybe you can choose to omit that parameter when you use the template. And IMO your example doesn't look messy to me - I think it looks fine. Just one gal's opinion. ♫ Cricket02 (talk) 06:33, 14 February 2008 (UTC)

Hm, I'll just try to address some of the topics you have noted. As for the fixed table width there were several reasons why we decided to use it that way.

- If the table becomes wider it's likely that it would collide with album boxes at the right side, at least at lower resolutions (Which would even include 1024*768, which is still seen as a standard in many places)

- Multi disc albums (like our Beatles example) would probably jump in cell width which would destroy the consistent look of the track list (which was one of our main priorities)

If someone knows a possible solution or workaround for this problem I'd be more than happy to hear about it.

It would be possible to shut off the hide button though I guess an extra option would be appropriate for this case, since "collapsed" is actually taken as a state from the collapsible table

I'm note quite sure about the linebreak for writings and lyrics. It could help clean up some templates while in other cases might just blow up the whole track listing. At the moment it's position was also decided upon consistency. I guess I will try out changing it in my sandbox and get some opinions on this matter. FjtDo (talk) 12:26, 14 February 2008 (UTC)

I have to concur with Cricket02 and FjtDo; providing separate columns for songwriting credits was part of the whole point of having a table, in order to provide a more ordered appearance, rather than cramming all information in a single column all over again and just have the track lengths line up more nicely. Removing the column for overall songwriting would also bear the question what to do with the more differentiated ones for lyrics and music. Putting "(Lyrics: John Doe. Music: Charles Smith.)" behind each track of a list appears to be another step backwards. Also, while introducing a "collapsible" option is probably relatively easy to do, it too would promote inconsistency.

But I do see a point in having credit information appear more closely to the titles, by moving the Length column all the way to the right (like the All Music Guide does it). This would also provide a more rounded look overall. If there are no objections, I'd implement that change right away, it would break none of the current options, just the presets in the documentation should be re-ordered. Another idea I've been toying around with (see my sandbox) are notes in smaller font, but I'm not too sure about that myself and would appreciate more opinions on it. - Cyrus XIII (talk) 16:20, 14 February 2008 (UTC)

I feel like changing font sizes of notes is a good idea, since it accents the actual title and prevents the overall cluttered look which comes with identical sizes. That way the notes are just seen as what they are: small notes which shall help the actual title.FjtDo (talk) 16:46, 14 February 2008 (UTC)

Thanks all, for your comments. Before I read Cyrus's paragraph, I thought of moving the writer credit column inside of the time column, and it's definitely an improvement. The smaller font size for the notes is also good. I'm not generally a fan of making information small, but it makes it more readable (at least for people without vision problems). Just for reference, here's the original article. The track listing looks messy there too, but it's always title, performer, time (author), and producers on the second line. That help its readability. I do see that, for better or worse, composers can be put in the notes area, if one prefers.

What happens when the table collides with the infobox? Will it just be bumped downwards, or do bad things happen? I don't think bumping is an awful thing. FjtDo, I don't know what you mean by "Multi disc albums (like our Beatles example) would probably jump in cell width..."

Did anyone else have thoughts about removing the # above the number column? I probably should even suggest it be removed, since the track listing guidelines at WP:ALBUM specifically say to use it. But we can change that if it looks good. And speaking of that WikiProject, since album articles and their track listings fall under their auspices, please bring this up there at some point. When you're ready to go live, at the very least, since they're the ones who will implement it broadly. :-) -Freekee (talk) 03:20, 15 February 2008 (UTC)

One other thing. If a song title happens to begin or end with quotation marks, there should be a space between them and the quotes that go around the whole song. There's probably not a way to support that, but I thought I'd mention it. -Freekee (talk) 03:43, 15 February 2008 (UTC)

Peculiar typographic choices like that may be negligible, given our general approach towards stylized text formatting per WP:MOS/WP:MUSTARD. A related example would be the article move of "it's a small world" to It's a Small World. I believe the jumping issue FjtDo is referring to is the fluctuation in width of consecutive tables, that would occur if they were not fixed - another break in consistency. A "bad thing" that may occur on low resolutions is overlapping with the infobox, which is certainly less desirable than the list just being bumped down. I have put in for help with this at Wikipedia:Requested templates, with any luck, it will be resolved soon and then an announcement at WP:ALBUMS will probably make more sense (let's discuss the "#" then, since the project's guidelines mention it). In the meantime, the Length column has been moved and the notes now appear in a smaller font. No parameter names were changed, hence no template breakage. - Cyrus XIII (talk) 06:10, 15 February 2008 (UTC)

Cool. One more thing. I came across the template in an article last night, and the row height seemed a little cramped. It's probably a pixel or two smaller than regular text. And maybe it seems smaller, given the alternating background colors. Would you consider bumping it up a little? Maybe make it a couple of pixels larger than regular text lines? Thanks. -Freekee (talk) 01:30, 17 February 2008 (UTC)

Saw Cyrus's request for help with this template:

1. The issue with overlapping is the same issue that was plaguing {{Ambox}}. This is a problem (with tables on almost ALL browsers btw.) that stems from setting the width to a fixed 65%. I have taken the liberty of changing this to use the ambox fix, but I suggest you might want to tweak the exact values a bit perhaps.

   Alternatively i can make it simply clear and retain 65%, but then it will ALWAYS bump below the infobox. There is no way to do clear only when there is not enough room. (Conclusion, tables do not follow CSS specifications, but what else is new :D )

2. As far as i'm aware you cannot change the default hide/show behaviour of tables in order to not conflict with navbox'es. It is enabled for ALL collapsable tables. --TheDJ (talk • contribs) 14:24, 23 February 2008 (UTC)

Thanks for your assistance. :) I've played around a with your revision and noticed a few issues: While the table now seems to be resizable to lower widths, before overlapping with an infobox occurs, at a certain point it still happens (at least with Firefox 2). Also, width is quite unevenly distributed between the various columns. See my sandbox for an example. Since there is fairly little gained from the changes, while sacrificing cleaner formatting, I've reverted the changes for now, but please give the fixed width/bumps always approach a try, it could very well be the best compromise between practicality and aesthetics. – Cyrus XIII ^(talk) 22:06, 23 February 2008 (UTC)

1. Correct, overlapping with tables is almost unavoidable. You can try by setting all other column values to a fixed width and one of those columns to 100%. But when there is text, at some point it will overlap floats simply to show text. Solution, do not use tables, or spam firefox, safari and IE developers to make tables CSS valid :D
2. I will show you why using clear always is bad. Now look at these pages: Withering to Death. Bara no Seidou Vision Creation Newsun Subarashikikana, Kono Sekai

So unfortunately, there might just not be a solution for your problem. --TheDJ (talk • contribs) 23:48, 23 February 2008 (UTC)

Not pretty huh ? :D It is the big downside of using clear, even more so in wikipedia. with its fully dynamic layout'ing. :( --TheDJ (talk • contribs) 00:12, 24 February 2008 (UTC)

New option: total_length

I believe this has been suggested somewhere else already and after running into a few rather special use cases related to the Tori Amos live discography, I guess this is a useful option for certain cases after all. I went for the most simple possible formatting for now. Thoughts? – Cyrus XIII ^(talk) 23:45, 7 March 2008 (UTC)

Looks pretty good to me. It should be put in a few of the examples on the main page though. = ∫_t^c 5th Eye 01:25, 1 April 2008 (UTC)

Good idea. The current examples should now cover about all of the functionality. – Cyrus XIII ^(talk) 02:52, 1 April 2008 (UTC)

I wonder though; how easy (or difficult) would it be for the template to parse the times and add them automatically? = ∫_t^c 5th Eye 03:04, 1 April 2008 (UTC)

The math itself is probably doable, though I'm not sure in how far MediaWiki markup can parse the times to separate minutes from seconds or if these would have to be provided separately right away. As far as I know, CD audio track lengths can be more precise than just seconds, so we would be adding up rounded values anyway and the result of such a calculation could differ from the actual disc length. – Cyrus XIII ^(talk) 08:27, 1 April 2008 (UTC)

Good points. It's probably best to leave it the way it is anyway since the total time is in the infobox as well. 13:04, 1 April 2008 (UTC)

Collapsed appearance

When collapsed, the entire thing disappears except for a [show] button. This makes it difficult to discern that a track listing actually exists on the page. Could this be changed so that, for example, it at least has a text box saying "Track list" or similar? Ham Pastrami (talk) 10:15, 2 April 2008 (UTC)

I see that it can be done using headlines. However, even with headlines, if the size of the table is wide enough, the [show] button seems to be disassociated with the headline. Can this be changed so that the background isn't white? That is, have the headlines and the [show] button visually connected by a gray (or other) colored box by default. Ham Pastrami (talk) 10:22, 2 April 2008 (UTC)

I'm not sure that this wouldn't detrimental of the overall appearance of a few articles, for example the one about the Legs and Boots series. When it comes to lone, collapsed track listings, more emphasis can be provided though extra spacing and a <big> tagged headline, in order to make readers more aware of the context (see The Orange Box#Soundtrack). – Cyrus XIII ^(talk) 00:37, 9 April 2008 (UTC)

Option suggestion: Producer

I happened to browse to Love. Angel. Music. Baby. (for god knows what reason) and, upon seeing the ugly table used to display the tracklist, thought that it would be nice to replace it with {{tracklist}}—however, one of the columns is Producer, not supported with the template. How appropriate would it be to add this extra category? = ∫_t^c 5th Eye 16:45, 7 April 2008 (UTC)

You could put the producer info in the "note" fields. -Freekee (talk) 05:12, 8 April 2008 (UTC)

Good point. I'll see how that looks. = ∫_t^c 5th Eye 05:21, 8 April 2008 (UTC)

What about the "extra_column"? danBLOO (talk) 21:37, 15 August 2008 (UTC)

Use in templates

Hello! I've recently been trying to incorporate this template within a wikitable. Basically for use with EPs etc that aren't notable enough for their own articles or compilations but would like to put their track listing hidden if anyone would like to see it. As is it behaves rather strangely.. there's a blank section in the middle. I can't see to figure out where it's coming from. Perhaps this is a bug? Would anyone be able to recommend a solution ot alternative to this? Thank you! [table commented out]Rehevkor (talk) 01:25, 4 May 2008 (UTC)

Yes, the CSS properties of the wikitable are screwing up those of the template. But for a list of works you might want to opt for a simpler approach anyway. Take a look at Legs and Boots#Shows and Rentrer en Soi#Singles, where the headline text is wrapped in the {{nobold}} template, to have it appear in the regular font-weight, making it easy to work multiple track listings into a regular bulleted list. – Cyrus XIII ^(talk) 22:43, 4 May 2008 (UTC)

That worked really well! Thank you. :) Rehevkor (talk) 00:07, 5 May 2008 (UTC)

[hide]

First of all, this is an awesome template and I'm surprised no one thought of it sooner. It's very well-done. I'm wondering, would it be possible for it not to show the [hide] button unless the template is collapsed to start with? I'd say it's very unlikely that anyone would need to collapse a tracklist in 99% of cases; it's just visual pollution. —Werson (talk) 16:54, 5 May 2008 (UTC)

Seems quite reasonable and as well as an option which should not be too hard to include since all that would be needed is a simple flag which determines if to show the hide button (using the collapseable class) or not. We will have a look into it and try to implement the functionality. This could also be bound to the collapsed flag which already exists. Unless it's set to yes the hide button would be invisible FjtDo (talk) 00:35, 6 May 2008 (UTC)

I've gone ahead and implemented it. Like FjtDo suggested, the "collapsed" parameter still does all the talking; if it's not used, the template isn't collapsible at all. – Cyrus XIII ^(talk) 01:20, 6 May 2008 (UTC)

Writer(s)

Another idea: Instead of having writing_credits, you could have the page coder choose between writer_credits and writers_credits, for whichever is applicable. That way if there's only one writer for each song (as in the Queen example) it could just say "Writer" at the top instead of "Writer(s)". —Werson (talk) 17:03, 5 May 2008 (UTC)

I'm afraid that besides replacing one existing option with two new ones, for a relatively minor change and with major breakage in already deployed templates, there are semantic issues with this approach. Once it either says "Writer" or "Writers", the respective term might apply to some but maybe not all tracks on the given record. Suppose we have another Queen album, some tracks written by Mercury, others by May and then there are one or two, co-written by, say, Deacon and Taylor. The intentionally ambiguous "Writer(s)" would still apply to each individual song. – Cyrus XIII ^(talk) 00:57, 6 May 2008 (UTC)

Fair enough! —Werson (talk) 02:28, 6 May 2008 (UTC)

Translation and/or Custom column

I'll start by saying that I think it was about time this was done, and I think it's great. Any chance we could add a "Translation" column for foreign albums. For Foreign albums (especially from non-roman written languages), this template looks like crap (no offense). Take a look at Music of Final Fantasy VII, compared to before (http://wiki.riteme.site/w/index.php?title=Music_of_Final_Fantasy_VII&oldid=203900610). Don't even get me started on FFX's
I realize, that if we add a "Translation" Column, then we might have to add god knows how many other columns...
So, would it be possible to add a "Custom" column? (i know it's actually template-possible, I'm speaking more of if you think it's a good idea). I was thinking something along the lines of:

| CustomHeader  = Translation

| CustomValue1  = プレリュード (Pureryūdo)
| CustomValue2  = オープニング~爆破ミッション (Ōpuningu ~ Bakuha Misshon)
...
| CustomValue23 = 想いを胸に (Omoi o Mune Ni)

This looks perfectly possible. We can even implement multiple custom columns by doing something like

| Custom1Header  = Translation(Kana)
| Custom2Header  = Translation(Hepburn)

| Custom1Value1  = プレリュード
| Custom2Value1  = Pureryūdo
| Custom1Value2  = オープニング~爆破ミッション
| Custom2Value2  = Ōpuningu ~ Bakuha Misshon
...
| Custom1Value23 = 想いを胸に
| Custom2Value23 = Omoi o Mune Ni

Then, even add things like "Custom1Position", should we want to position it in a special order. I realize this might not be easy to implement, but I personally believe the template would GREATLY benefit a from this kind of versatility. Thoughts? happypal (Talk | contribs) 17:09, 10 May 2008 (UTC)

After pondering your suggestions for some time, including discussing it with FjtDo (who is more competent on the technical side than yours truly), I've come across several issues that would arise from such a changes and ultimately break its design paradigm. {{Tracklist}} already supports up to six columns (three of them optional), with the still-more-common-than-we'd-want-it-to-be resolution of 1024x768 in mind, at which the template still plays nicely with the {{Infobox Album}}. Adding more columns (you are suggesting at least two) to a table that might already be packed would make it look a lot more crammed than some variants that make heavy use of the notes parameter (that issue having already been somewhat addressed by using the <small> font for that text). Of course, one could always remove the width restriction of the entire template, but then again, having each instance of {{tracklist}} share the same width is essential to presenting a clean, consistent look, particularly when several of them are used in a row.

Custom columns would also inflate the code template code ... a lot, making it harder to maintain in general. Custom column positions on the other hand would not only blow up the code linearly but exponentially. This strange HTML/CSS/Wiki-markup voodoo with which we have to make do is just that limited in its capabilities/versatility. Again considering consistency, being able to switch around column positions between template instances also does seem to be a desirable feature to begin with.

On a side note: Given that I have worked on several soundtrack related articles myself (including some on which the two of us collaborated) this template was designed with them in mind as well; and while I can relate to your desire to make the template more accommodating to the current status quo on these pages, I've come to consider a few common practices found on them rather questionable, e.g. still giving preference to original, Japanese titles, when official English translations are available (at odds with WP:UE), inflationary use of unofficial translations (WP:RS/WP:OR) and pointing out discrepancies between official and supposedly literal translations (WP:MOSJP and probably WP:CRUFT). Considering our guidelines, I'd be rather inclined to simply give preference to English titles where available, rely on romanized titles elsewhere and reserve specific in-depth information for the relevant prose. This is, after all, a general purpose encyclopedia. – Cyrus XIII ^(talk) 20:01, 14 May 2008 (UTC)

I also do not completely agree with giving 2 different translations, but I think at least both Jap(or other language) and English should both be there. And on a side note, the iTunes sources for the above articles are only called "Official" because they are the highest level influence, and when you realize that there are typos in their tracknames, one can only wonder if they weren't just copy pasted after the first Google search by some under-payed employee... But I digress.

Other than that, your post made me realize two things:

• I never said anything about wanting 6+ columns, good god, that would be horrible!
• Creating a CustomValue field is indeed a bad design concept BUT:

Would it be possible to just change the name of the "Note" Field at the top of the template? This would be extremely easy and bring no bloat to code or server load. This would only require a field called "NoteColumnName" or something?

This could be useful for when all the notes relate to the same specific thing (in our case translation or whatnot, but also possible would be location played for VideoGame soundtracks or tons of other things!). I think that would be the perfect level of versatility, without making the code impossible, or breaking the whole of point the template (Consistency). Thanks for taking the time to consider these things.happypal (Talk | contribs) 05:58, 15 May 2008 (UTC)

Disregard the above, I just realized "Notes" Isn't actually a column.happypal (Talk | contribs) 05:41, 18 May 2008 (UTC)

Protection

This page requires at least semi-protection, and full protection once all it's quirks are worked out. It'll soon be too dangerous what with vandals and all. I realized this when I accidentally deleted all it's content, copy-pasting in the wrong window...sorry. Also, I would hate to see a floating penis on all the album pages of wikipedia, as was the case for all japan related articles a few years ago...happypal (Talk | contribs) 17:04, 14 May 2008 (UTC)

Hide Header

Sorry to keep asking for new features, but what could we add a way to NOT display the standard header, like be adding "DisplayHeader=False" (the header being displayed by default). This would allow for easy and continuous subsections, like for albums with multiple bonus tracks or something. Currently, we can do this, but the second header is kind of disruptive...

Beatles Album with super secret bonus songs

No.	Title	Length
1.	"Back in the U.S.S.R."	2:43
2.	"Dear Prudence"	3:56
3.	"Glass Onion"	2:17
4.	"Ob-La-Di, Ob-La-Da"	3:08
5.	"Wild Honey Pie"	0:52
6.	"The Continuing Story of Bungalow Bill"	3:13
7.	"While My Guitar Gently Weeps" (George Harrison)	4:45
8.	"Happiness Is a Warm Gun"	2:43

Bonus Tracks

No.	Title	Length
9.	"Martha My Dear"	2:28
10.	"I'm So Tired"	2:03
11.	"Blackbird"	2:18

In this example, I would want the second table's "#, Title, Legth" Row to not show.
This would be extremely easy to implement, but I don't want to do anything without discussing.
happypal (Talk | contribs) 06:23, 15 May 2008 (UTC)

That would certainly cut some extra fat from a few track lists. I demoed the change by manipulating a screenshot and then went to work in my sandbox. Turns out that along with the table header, this would also eliminate the width distribution among the columns, resulting in ill-positioned songwriting credits across the multiple instances of the template. I'm not sure if the limited number of use cases for a header hiding option would justify adding the width distribution code (and the conditional statements attached to it) to every individual row. – Cyrus XIII ^(talk) 12:39, 19 May 2008 (UTC)

I've thought about it some, and I guess it can't be helped.happypal (Talk | contribs) 14:34, 20 May 2008 (UTC)

I've had an idea of how to this could work without adding widths to all rows: Instead of hiding the row, and gaining all the losses of width data that comes with it, simply hiding the individual text headers in the row. It maintains the width attributes and effectively hides the row since then has nothing keeping it with a height. Thoughts? — Balthazar ^(T|C) 15:44, 7 August 2008 (UTC)

I've kinda got it working in Cyrus XIII's sandbox'd version. — Balthazar ^(T|C) 00:57, 8 August 2008 (UTC)