Template talk:Infobox single

Proposal for color extension to include Promotional singles

I would like to make a proposal to extend Infobox single to have a color scheme similar to that of Template: Infobox album/color and Template: Infobox song/color. I would like infobox single to take care of Promotional singles, since they are technically singles, not just ordinary album songs. I will admit to the mistake of creating Template: Infobox promotional single without consulting this talk page first. I would just like to ask for edits of this kind to allow Promotional Singles to contain single infoboxes instead of song infoboxes, with a coded background color that does not match the infobox single color, but something similar or exactly #FFFFC9.

The extensions I propose are-

• the creation of Template:Infobox single/color and a documentation, similar or exactly this:

<includeonly>{{#switch: {{lc:{{{1|}}}}}
  |single|[[single]]|singles|[[singles]]=khaki
  |promotional single|[[promotional single]]|promotional singles|[[promotional singles]]=<nowiki>#FFFFC9</nowiki>
  |{{#if:{{{2|}}}|{{{2}}}|peachpuff}}
}}</includeonly><noinclude>
{{template doc}}</noinclude>

• An edit in line 4 (abovestyle),

from

''abovestyle = background-color:#F0E68C''

to

''abovestyle = background-color: {{Infobox single/color}}''

• An edit in line 8 (headerstyle),

from

''headerstyle = background-color:#F0E68C''

to

''headerstyle = background-color:{{Infobox single/color}}''

• An edit in line 11 (header 1),

from

''header1 = [[Single (music)|Single]] by {{{Artist}}}''

to

''header1 ={{#if: {{{Type|}}} | {{{Type}}} | [[Single (music)|Single]]}} by {{{Artist}}}''

• After changes, correct any mistakes I may have made and update the documentation of Infobox:Template Single.

If these proposals are accepted, promotional singles can finally be recognised on wikipedia. So I ask the moderators of this page, please make an infobox shade for Promotional singles on Infobox single! — Preceding unsigned comment added by RazorEyeEdits (talk • contribs) 07:59, 25 December 2012 (UTC)‎

 Not done: Sorry, but you need to show that there is a consensus to implement the above change before I can update the template. To show you that there is a consensus, I recommend you follow the following procedure:

1. Add your proposed change to the template sandbox
2. Set up some test cases on the test cases page eper WP:TESTCASES.
3. Notify people at WT:SONGS and WT:ALBUMS of this discussion and point them to the test cases you have made.
4. Wait for a while. (Usually seven days is enough, but I suggest ten days as it is Christmas now.)
5. If the rough consensus from the discussion is to implement the change, reactivate the {{edit protected}} template.

If the admin who patrols your edit request agrees that a consensus has been reached, they will perform the edit. Let me know if you have any questions about any of this. Best regards — Mr. Stradivarius ^{(have a chat)} 10:18, 25 December 2012 (UTC)

Even if the above things are trialled first there is an on-going discussion about the deletion of {{Infobox promotional single}} at Wikipedia:Templates_for_discussion/Log/2012_December_16#Template:Infobox_promotional_single which needs to be addressed first. There's already some opposition to the idea of a new color for promotional singles. — Lil_℧niquℇ №1 ^[talk] 14:00, 25 December 2012 (UTC)

Oppose - "promotional single" is most definitely not the same thing as a single in the normal sense. In fact, the term is essentially meaningless, especially these days. A "promo" just means a song is played on the radio, and can be downloaded. There's nothing special about that. We can't just go putting an infobox up whenever Amazon lists a price for an MP3. — Preceding unsigned comment added by 86.191.160.108 (talk) 23:24, 10 May 2013 (UTC)

Published and Language parameters

Please add Published, Composer, and Language parameters to Infobox single similar to the parameters in template:Infobox song. Thanks. Uzma Gamal (talk) 14:57, 2 February 2013 (UTC)

 Not done: For heavily used templates such as this you need to establish consensus even for small changes before asking for an edit. I would support adding Composer, and Language, but the purpose of the Published parameter is still unclear at "Infobox song", so I don't think this should be introduced here. De728631 (talk) 00:15, 9 February 2013 (UTC)

I'd support a |lang= for songs whose lyrics are not in English. We should also, separately, have a {{title_lang}} for songs whose titles are not in English (even if their lyrics are), so that we can mark them up with the relevant ISO code (c/f |native_name_lang= in {{Infobox settlement}}); and a |title_translation=, for the English equivalent of such titles. This applies to both of these sibling infoboxes (which should be merged). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:38, 15 April 2013 (UTC)

Addition of "lyrics" and "music" fields

"Infobox single"
Song

I could have sworn I brought this up before... but I looked around and I guess I haven't. Often times, the writers of a song are listed just as "written by", or "writers", however, in some cases, they are separated into "lyrics by" and "music by" (the "writer(s)" of a song generally include both those who wrote the lyrics and those who wrote the music). I purpose that we add a field for this. It can get quite messy otherwise; for example, on "Feelin' So Good" it reads: "Writer(s): Cory Rooney, Jennifer Lopez (lyrics); Sean "Puffy" Combs, Steven Standard, George Logios (music)", when it could just read "Lyrics: Cory Rooney, Jennifer Lopez" and "Music: Sean "Puffy" Combs, Steven Standard, George Logios". I don't see what harm such addition could do.  — Statυs (talk, contribs) 23:30, 23 March 2013 (UTC)

In addition, this would too be added to Infobox song.  — Statυs (talk, contribs) 23:32, 23 March 2013 (UTC)

I've marked this edit request as answered. Feel free to reactivate it when you have worked out exactly how this parameter should work, and have a consensus to change it. Also, it would be best if you could add your proposed change to the template sandbox and set up some test cases to test its functionality at the test cases page. If you want more info, there's some at WP:TESTCASES, or feel free to ask on my talk page. Best — Mr. Stradivarius ^{♪ talk ♪} 08:39, 25 March 2013 (UTC)

Thank you; I have attached a sample of the proposed change to the side.  — Statυs (talk, contribs) 21:56, 25 March 2013 (UTC)

Since "Music", I don't think, necessarily works perfectly in the context, "Composer" could be used instead; meaning the same thing.  — Statυs (talk, contribs) 21:57, 25 March 2013 (UTC)

For backwards compatibility, we should retain the |writer= parameter. We should then code the template so that if that parameter is present, the |lyrics= and |music= (or whatever we call it) do not display. That would also serve cases where both are by one person. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:32, 15 April 2013 (UTC)

Anybody else got anything to say about this?  — Statυs (talk, contribs) 21:09, 6 July 2013 (UTC)

List formatting

My recent addition of a note about the use of {{Plainlist}} and {{Flatlist}} was reverted due to a claim of "no consensus". Without a discussion here, that cannot be determined, and WP:DNRNC applies. The use of those templates accords with WP:LIST and WP:HLIST, and both offers accessibility improvements and makes sure that we confirm to international web standards. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:21, 15 April 2013 (UTC)

You might as well have been trying to edit the contents of the template yourself. It's the same thing. None of the pages you have linked to discuss anything about use in infoboxes the way writers, producers, etc. are. Are you linking to the right page, or will something about that show up there too soon?  — Statυs (talk, contribs) 21:25, 15 April 2013 (UTC)

As I've just told you in response to your message on my talk page: You should read WP:UBLIST, which is a subsection of WP:LIST, and part of WP:MOS. It says "For lists of... items, without bullets (for example in infobox fields, or to replace lists separated with <br />), {{Plainlist}} or {{Unbulleted list}} should be used. This emits the correct HTML markup...". That's not a recent change, so you can drop you insinuations. Now, would you like to say why the you think the two list templates, and their accessibility and web standards improvements, are good enough for almost all of our infoboxes, but not this one? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:37, 15 April 2013 (UTC)

This is involving (as an example) the writers of a song, which are separated by commas and have been for many years. Changing such to a mid dot without a discussion is not the way to be. I would be interested in you providing a similar type of situation with another type of infobox. And please, keep all discussions in one place. What is the point of discussing the same thing on two talk pages, one for a specific song, and one in general? General is the issue, not the song. And stop acting as if I were involved in such original dispute on April 4; I had no knowledge of the message on the talk page.  — Statυs (talk, contribs) 21:57, 15 April 2013 (UTC)

"A similar type of situation with another type of infobox"? See, for example, the documentation of {{Infobox film}}, {{Infobox play}}, every navnbox, and over a thousand more. Infoboxes which do not yet use these two templates are the exception, not the norm. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:10, 15 April 2013 (UTC)

Not exactly the same. Those use line breaks, while this and similar infoboxes, such as Infobox album uses commas.  — Statυs (talk, contribs) 22:15, 15 April 2013 (UTC)

The documentation change under discussion uses both. The "over a thousand more" link refers to {{Flatlist}}, and my comment refers also to both. The principles of improving accessibility end meeting web standards applies equally. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:13, 15 April 2013 (UTC)

There are a couple of good reasons for preferring to use {{flatlist}} and {{plainlist}} for lists of items in infoboxes and neither of them are related to the visual appearance. It is important to realise that whether list items are separated by commas or mid-dots is purely and simply a piece of personal preference and should carry no weight, unless we think we can decide on what the entire readership of Wikipedia would prefer to see.

The first reason for preferring a structured list in an infobox is on the grounds of accessibility. If we mark up a list with commas, as in running prose, then a screen-reader will simply read the items (along with punctuation if enabled). This isn't bad, because screen-reader users are accustomed to it, but we can do better. A real list, using on of the templates, can give the screen-reader user expanded information like "List of 3 items: first item, 7-inch single; second item, CD single; third item, digital download; end of list" if they want to get full information.

It's worse with vertical lists. Using <br /> leads a screen-reader reading Golden Brown to announce something like "... Producer, The Stranglers; new line; Steve Churchyard; new line; The Stranglers singles chronology ..." instead of something like "... Producer: List of two items: first item, The Stranglers; second item, Steve Churchyard; end of list; new line; The Stranglers singles chronology ...". We should not be using <br /> to separate list items ever. Wikipedia:Manual of Style/Accessibility#Lists is utterly unambiguous about that: "Do not separate list items with line breaks (<br />). Use one of the following methods." - the "following methods" are {{flatlist}} and {{plainlist}}.

The important point here is that marking up a list as a list gives visually-impaired readers more choice and flexibility. We should not be denying them that opportunity just because we like commas and don't like mid-dots.

The second reason for preferring a structured list in an infobox is that third-party re-users of our content (like Google) use automated tools to scrape information from our content, and structured content works best for them. Those tools can recognise an infobox and can recognise a list within it. This makes it much more likely that they can recognise the producers of Golden Brown as two distinct entities: 'The Stranglers' and 'Steve Churchyard', rather than a single entity 'The Stranglers Steve Churchyard'. It's not crucial to try to make it more likely that Google gets it right when reading our content, but it's helpful.

So there are good reasons why we should prefer {{flatlist}} and {{plainlist}}, and the consensus documented at Wikipedia:Manual of Style/Accessibility#Lists is not to be ignored lightly - certainly not with a reason like "I don't like mid-dots", which doesn't even apply to {{plainlist}}! Unless there are good reasons why we shouldn't be asking users of this template to comply with WP:ACCESS, I'll restore the documentation to a more accessibility-friendly state. Please feel free to explain any objections, but I'd be grateful if such objections were based on policy, rather than personal preference. Cheers --RexxS (talk) 18:20, 1 May 2013 (UTC)

I am quite happy to adopt the use of them (as good practise) and as an example in all my GA articles. — Lil_℧niquℇ №1 ^[talk] 19:30, 1 May 2013 (UTC)

Thank you Lil', it's good to bump into you again, and I know that your endorsement will help spread the good practice faster than anything I could do. I'll leave it a few more days in the hope that some others will come up with important points that I might have missed. Regards, --RexxS (talk) 00:52, 3 May 2013 (UTC)

Hi RexxS, I've adopted the {{flatlist}} at Glassheart and particularly found a useful use within the {{track listing}} template as seen at Glassheart track listing which prevents the scenario as seen at #willpower. — Lil_℧niquℇ №1 ^[talk] 20:56, 4 May 2013 (UTC)

Alright RexxS, you've convinced me (you should run in politics!). I'm with Unique above.  — Statυs (talk, contribs) 20:35, 7 May 2013 (UTC)

This is very nice looking, actually. I've applied it to Love?.  — Statυs (talk, contribs) 20:55, 7 May 2013 (UTC)

Thank you - the folks using screen readers will appreciate it. I've tentatively updated the documentation as it looks like we have reached a consensus here, but I won't object if I've misjudged that. Cheers, --RexxS (talk) 07:39, 8 May 2013 (UTC)

Changing visual appearance

Can we change the guidance for the 'Label' and 'Producer' fields to read {{flatlist}} instead of {{plainlist}}? In which case the infobox example needs to be updated too as it presently uses a comma to separate the labels. — Lil_℧niquℇ №1 ^[talk] 20:46, 2 June 2013 (UTC)

People have generally separated such items with <br />, in which case the appropriate replacement is {{Plainlist}}; whereas {{Flatlist}} is the replacement for comma-separated lists. Such a significant change to visual presentation should be agreed through wider discussion, rather than being brought about by a change to template documentation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:16, 2 June 2013 (UTC)

If you take a look at the majority of song articles, the two labels are listed alongside each other e.g. in the infobox example it even says Food, EMI, suggesting that the standard format is to list them alongside each other. so per the guidance above that should change to Food  · EMI. Additionally, if we're listing writers using {{flatlist}} surely producers should be listed using this too? In fact its standard practise, if you look at good article nominations for songs, virtually all list all elements of the infobox in a traditional list format i.e. SUBJECT 1, SUBJECT 2, SUBJECT 3 etc. So actually when it is standard practise I don't see why it is a "significant change to visual presentation", particularly when the very example we give is a horizontal format anyway and doesn't match the written guidance we provide. That's all I am trying to correct. — Lil_℧niquℇ №1 ^[talk] 21:37, 2 June 2013 (UTC)

[ec]That's not been my observation, but if so, go ahead. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 2 June 2013 (UTC)

I've disabled the {{edit protected}} template; any changes need to be made in the template documentation, which is not protected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:54, 2 June 2013 (UTC)

Asking editors to use {{plainlist}} for producers and labels would be considered a radical change in itself because if you view the template the examples we've always given and guidance prior to the recent update was a horizontal list, separated by commas. — Lil_℧niquℇ №1 ^[talk] 21:46, 2 June 2013 (UTC)

I'd happily recommend using {{plainlist}} instead of <br /> everywhere that we list items one-per-line - and in infoboxes that tends to be where each item is long enough to justify that. It is always a gain in accessibility to do so. If the items are short enough for multiple values to fit on one line of an infobox, then it makes sense to use a horizontal list (and I see that {{Flatlist}} is preferred to {{hlist}} here). I wouldn't complain about using commas if there are only ever going to be a couple of items in a list, but otherwise upgrading to {{Flatlist}} will improve accessibility. --RexxS (talk) 16:17, 3 June 2013 (UTC)

The advantage of lists over comma-separated items even for short lists is machine readability; it's far easier for a parser (or, for that matter, a human) to understand that, say:

<li>Pye</li>
<li>London</li>

are two items and not one, than for "Pye, London" where the latter might be the location of the former. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:42, 3 June 2013 (UTC)

Which screen readers are better at presenting lists than comma separated lists and for which does it not matter? Please be specific and cite your sources. It seems we've accepted opinion here and an editor is pushing said opinion on another template's discussion (Template talk:Infobox album. We won't stand for lack of references is articles and shouldn't stand for it in template documentation either. Walter Görlitz (talk) 04:53, 5 July 2013 (UTC)

Similarly, CSV management is standard in every modern programming language (Perl, Ruby, Python similarly with C#, C++, etc.) so I don't believe that creating list items makes it any easier to parse for machine-readability. Has Google complained that we use commas? Have they suggested that we move to lists? Predictability is more important here so we should parse whatever list we have into the same output. If you look at the way it was done for the band members at Template:Infobox musical artist, comma separated lists and manually created lists are presented the same way. That should be done here as well. Walter Görlitz (talk) 13:41, 5 July 2013 (UTC)

Catalogue number

Why is catalogue number not a named parameter? (applies equally to Infobox album. Thanks. Martinevans123 (talk) 13:03, 11 May 2013 (UTC)

Because different versions of an album have different catalogue numbers and the catalogue numbers are also different for each territory. Additionally digitial editions of an album don't usually have a catalogue number so their relevance is fading quickly. What would be gained by having a catalogue number in the infobox? — Lil_℧niquℇ №1 ^[talk] 13:12, 11 May 2013 (UTC)

It would save having to put the number in the text. Singles and albums which got to number one, went platinum, got banned by radio stations, etc., etc. used to be physical entities, made of vinyl, with a label, and with a catalogue number. Just because you suggest they are "no longer relevant" does not mean they are not still very relevant to collectors who might be searching for them. A catalogue number is also useful for distinguishing between re-issues of the same record and between records with the same title. I've had this discussion a number of times before, so I am not going to labour the point. But there seen to be enough unused parameters in the single and album infoboxes, that adding one that might be used just seemed sensible to me. Martinevans123 (talk) 13:50, 11 May 2013 (UTC)

Where there is scope for significant differences i.e. catalogue numbers vary by region, release, format etc the release history is the best place for them because it just gets too complicated. In some cases Catalogue numbers can be cleverly woven into the article itself e.g. Glassheart#Track listing, but generally I would think it is more suited to a release history section e.g. Memoirs of an Imperfect Angel#Release history. In fact the latter is an excellent example as to why they shouldn't appear in the infobox. — Lil_℧niquℇ №1 ^[talk] 21:37, 2 June 2013 (UTC)

So, you seem to be strongly suggesting that it's ok to include a Catalogue number in the infoxox when there is only one release, or at the most two. Would this be best placed after the label, or in a separate field? If there are more than two releases, you seem to be strongly suggesting that a table is best, which included country of release, date, label and format. Is that correct? Thanks. Martinevans123 (talk) 17:52, 3 June 2013 (UTC)

I have mixed feelings about this. On the one hand, the catalogue numbers for every edition of, say, 'Dark Side of the Moon' would fill a book. On the other, they do serve a useful purpose, and we seem to manage with ISBNs for books, which are analogous; we usually only give one in an infobox, and it tends to be for the first release in the home country. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:05, 3 June 2013 (UTC)

I think one in the infobox, after the label, or as a separate parameter, would be an improvement on none. Martinevans123 (talk) 18:10, 3 June 2013 (UTC)

If we do include a catalogue number, it should definitely be a separate parameter, no matter how it is displayed, to preserve data granularity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 3 June 2013 (UTC)

The only "spare" parameter currently seems to be Misc, which makes no mention of Catalogue Number. Should a new paramater be added? Thanks. Martinevans123 (talk) 18:46, 3 June 2013 (UTC)

Next and previous singles and data granularity

Mentioning data granularity, above, reminds me that this template has

• |Last single=
• |This single=
• |Next single=

parameters, with values like:

• |Last single="[[To the End (Blur song)|To the End]]"<br />(1994)
• |This single=""Country House""<br />(1995)
• |Next single="[[The Universal (song)|The Universal]]"<br />(1995)

We should convert those to:

• |Last single title=
• |Last single date=
• |This single date=
• |Next single title=
• |Next single date=

with values like:

• |Last single title=[[To the End (Blur song)|To the End]])
• |Last single date=1994
• |This single date=1995
• |Next single title=[[The Universal (song)|The Universal]]
• |Next single date=1995

That way things like the parentheses and quote marks can be applied automatically, and the data will become easier to enter and to parse.

We don't need |This single title=, as we have that in |Name=.

A bot could handle conversion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:49, 3 June 2013 (UTC)

Video director

Hyacinth (talk · contribs) added a "v. director" field to the template with no discussion here on as to whether or not it should be added. Looking at the archives, it was brought up twice previously: in September 2006 and May 2012 (two people involved in each discussion, both ending in no consensus).  — Statυs (talk, contribs) 21:07, 6 July 2013 (UTC)

Hear, hear. Can this please be reverted and consensus reached before it is implemented? Thanks. Adabow (talk) 22:25, 6 July 2013 (UTC)