Template talk:Infobox album/Archive 12

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Including the venue parameter for studio albums when substituting

Would there be any way to alter instances of substituting the template/updating that already used on articles to not include the parameter "venue" if the infobox is already set to "studio" or "album"? The template's documentation states, in bold, that the "venue" parameter is explicitly for live albums, and realistically there are few exceptions for studio albums being recorded in venues or live settings. Most of the time this parameter is not filled in anyway and left blank, or removed in cleanup sessions by other editors. I've noticed that it's automatically placed when users substitute the template when in most cases it's not needed. Ss112 05:58, 20 October 2018 (UTC)

Looking at Module:Unsubst-infobox I don't really see any way to do this. Having the blank parameter on the page has no negative effect. I don't see anything wrong with it... One thing we could easily do is add a tracking category. So any page that had a venue set AND was not a live album would be placed in the category. That would certainly make sense. But I don't see any reason to rebuild a Module to work around this one use case, unless someone can see a way I can't. --Zackmann (Talk to me/What I been doing) 06:05, 20 October 2018 (UTC)
The best option would be to see if @Zackmann08: could address this with the updates the editor is making. Walter Görlitz (talk) 06:37, 20 October 2018 (UTC)
@Walter Görlitz: all I am doing is substituting the template... {{subst:Infobox album..... That doesn't have the ability to conditionally replace that parameter. --Zackmann (Talk to me/What I been doing) 07:00, 20 October 2018 (UTC)
If it is valuable to remove the |venue= parameter, one could submit a bot request. There are plenty of template transclusions with empty parameters that do no harm, however, and this seems like one to me. – Jonesey95 (talk) 09:51, 20 October 2018 (UTC)

Listing producers on separate lines when there are lots of them

Does it seem wise to anybody else that we're advocating that users list each producer on a new line in the infobox when, especially for modern pop and hip hop albums, there are usually at least a dozen separate producers? This can turn out to be a long list and a mile to scroll through before the actual prose starts and it seems excessive. Horizontally listing them with the actual defined hlist template (not just utilising the default hlist capabilities of the infobox) inside visually takes up less space in the source editing. I wouldn't think using an hlist in cases where there are a tonne of producers to list would be a hindrance to screen readers for accessibility concerns either, otherwise, why does hlist exist as a template if it's an accessibility obstacle? (No need to ping me, I'll be watching the talk page.) Ss112 05:50, 31 October 2018 (UTC)

For recorded (which used to include studio and venue), studio, genre, label and producer we have a note (For multiple entries, see Notes[2] for details). That note used to state that we could use either flatlist or hlist, but that seems to have been changed. The template parameters table has not kept pace and should be updated. Do you have any suggested improvement to the documentation? Walter Görlitz (talk) 06:15, 31 October 2018 (UTC)
I'd suggest we could re-add the part about using hlist if there's a lot of names or items to list in the infobox. Ss112 15:14, 31 October 2018 (UTC)
Since both list templates work in the parameter, it might make sense. However, space isn't really an issue and vertical is often more clear than horizontal when a large number of items is present. I wouldn't be opposed to restoring the copy to the note though. Walter Görlitz (talk) 15:32, 31 October 2018 (UTC)

Deprecations

@X201: what happened? The category was empty for albums. What did I miss? --Zackmann (Talk to me/What I been doing) 18:58, 13 November 2018 (UTC)

@X201: HAHA!!! I just noticed that you reverted your revert. :-p I was worried because I checked and rechecked my work before making that change... Please do look over the change I made though? Always great to have a 2nd set of eyes. :-) --Zackmann (Talk to me/What I been doing) 19:12, 13 November 2018 (UTC)
@Zackmann08:, Yes, sorry about that. I'd got multiple diffs open on an article with a module string error and lost my marbles for a second. Sorry. I'm currently clearing Category:Music infoboxes with Module:String errors, will also clear the User and Draft articles that are cluttering it up. - X201 (talk) 08:54, 14 November 2018 (UTC)
@X201: no problem at all! Just wanted to make sure I wasn't missing something. Keep up the great work. --Zackmann (Talk to me/What I been doing) 17:15, 14 November 2018 (UTC)

Addition of link to discography page or section

I'm frequently frustrated by the lack of link to the artist's complete discography (page ifexist or artist page section ifexist) (issue: multiple artists) and briefly searched the talk archives to find I'm not alone in a desire to add one (or as many as are needed with regard to issue). Let's talk :) Fred Gandt · talk · contribs 07:55, 1 December 2018 (UTC)

You are suggesting that the infobox would include a link to an artist's discography? ―Justin (koavf)TCM 08:00, 1 December 2018 (UTC)
Yes I am. Fred Gandt · talk · contribs 14:55, 1 December 2018 (UTC)
@Fred Gandt: And do you have any notion of how it would be displayed? ―Justin (koavf)TCM 21:47, 1 December 2018 (UTC)
Not in particular Justin; since it would be a trivial addition with a non trivial effect (change == scary), I figured a discussion about the possibility before getting entrenched in aesthetic preferences seemed prudent. But to kick things off; I suppose a relatively plain link just above the "chronology" section, or at least around there somewhere. What do you think? Fred Gandt · talk · contribs 22:23, 1 December 2018 (UTC)

@Tango303 and Walter Görlitz: As you've previously expressed support... Fred Gandt · talk · contribs 22:27, 1 December 2018 (UTC)

I don't recall being in favour of a link to a discography article in the infobox, but I'm not opposed. How would it benefit (or distract) a reader? Walter Görlitz (talk) 01:11, 2 December 2018 (UTC)
A couple of years ago in this archived discussion (linked above) Walter :) Fred Gandt · talk · contribs 02:40, 2 December 2018 (UTC)
  1. "How would it benefit...?" By providing the missing link when offered to easily peruse the chronology while stingily requiring one to find one's own method of finding the discography; convenience.
  2. "How would it distract...?" I personally can't envisage it distracting anyone. Fred Gandt · talk · contribs 02:49, 2 December 2018 (UTC)

"Single Album"

Please see this rather lengthy discussion: Wikipedia talk:WikiProject Albums#"Single Album", in which a bunch of knowledgeable editors in the Albums Project reached a consensus on the need for a new TYPE called "Single Album" in the Album Infobox. (The term is unique to the Asian music industry and is becoming very common.) Please advise on the next steps. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 15:11, 5 February 2019 (UTC)

Safest bet is if the new type is called single_album or singlealbum. There's already a single option in the color and link templates and using single with a space could open up a can of worms. - X201 (talk) 16:22, 5 February 2019 (UTC)
That looks good to me. I do not have authorization to edit a template so we simply need an appropriate person to go forth. I forgot to mention above that this new type can be parallel to the existing "EP" type in terms of the color, as decided in the discussion. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 16:35, 5 February 2019 (UTC)
Anyone can edit the template's sandbox (copy the main template code over to the sandbox first) and the testcases page to show how this new feature would work. Ping me or put an edit request template here if you need help, or if you need someone to look at the changes and implement them. – Jonesey95 (talk) 17:40, 5 February 2019 (UTC)
Pinging Galobtter, who has some unpromoted changes in the sandbox. Do you want to move those over to the main template before this new experiment? – Jonesey95 (talk) 17:42, 5 February 2019 (UTC)
Jonesey95, The unpromoted changes can easily be reintegrated back, so feel free to reset the sandbox or whatever else needs to be done. Galobtter (pingó mió) 17:55, 5 February 2019 (UTC)
Jonesey95 - The procedures at the sandbox and test cases page are beyond my area of expertise and I don't want to mess things up. Please consider taking the initial steps yourself if you have time (adding a new TYPE called "Single Album" with the proper coding and the same color as the existing "EP"). I will keep an eye on things and provide comments. Thank you for your assistance. ---DOOMSDAYER520 (Talk|Contribs) 17:59, 5 February 2019 (UTC)
Well played, doomsdayer520. This little template has a LOT of moving parts. I think I found, updated, and documented all of them. Please try it out and let me know if I missed anything. – Jonesey95 (talk) 18:41, 5 February 2019 (UTC)
Jonesey95 - Well played because I have no idea what you did or where you did it. Thanks for taking the time to implement the change. Per your comment over at the original Project discussion, you are correct about the link to Single (music) which is not quite an accurate place to send the term "Single Album". We decided to write a new article on the term "Single Album" as used in Korea, or at least a new section in an existing article somewhere else. When that happens I will take the lead back here on adjusting the link. Thanks again! ---DOOMSDAYER520 (Talk|Contribs) 20:20, 5 February 2019 (UTC)
We shouldn't need to adjust any links in any templates. Just drop your elegantly written, reliably sourced, mind-blowing new article content, complete with categories and arrows on the back of each one, into single album, replacing the redirect that is there now. – Jonesey95 (talk) 05:36, 6 February 2019 (UTC)

Just wanted to point out that I have started converting articles on these Korean releases that were previously mis-characterized as EPs and whatnot. The new "Single Album" type in the infobox appears to be working properly. Thanks all! ---DOOMSDAYER520 (Talk|Contribs) 16:14, 7 February 2019 (UTC)

Adding short description

Continuing from Template talk:Infobox album/Archive 11#Short description (ping Fram), I'm proposing adding an automatically generated short description to this infobox, having fixed the issue of secondary infoboxes by creating and using a module, Module:Is infobox in lead, to check if the infobox album is the lead infobox. (this is to avoid, say, having the short description "Soundtrack album by Clint Mansell" added to Pi (film)). The code is in the sandbox.

The short description is exactly the same as header1 of the infobox, i.e, "Greatest hits album by Nirvana" for Nirvana (Nirvana album), "Studio album by Simon & Garfunkel" for Wednesday Morning, 3 A.M., and so on; these descriptions are generally as good or better than the currently displayed wikidata descriptions (which are often just "album"). If that would improve the description, I can add the release date, too, for say "1964 studio album by Simon & Garfunkel". Galobtter (pingó mió) 08:03, 20 January 2019 (UTC)

  • I like it and support it. I'd also support the year addition. I'd personally would like it if a module did the work as usually there are a few more if checks to make sure that the description doesn't seem strange with missing parameters (and having all that in the template just clutters it up for no reason and is harder to debug). If you need help with testing, let me know. --Gonnym (talk) 08:34, 20 January 2019 (UTC)
    Gonnym, I've added the year, I'll see about a module: another thing, would you think that "studio album" should be shortened to "album" in the short description? I don't know nothing about music which is why I'm wondering if you think that is reasonable. Galobtter (pingó mió) 08:51, 20 January 2019 (UTC)
    Not my expertise as well so cannot help there, sorry. --Gonnym (talk) 08:53, 20 January 2019 (UTC)
This is great. Definitely have the year in there. I think "album" over "studio album" works. Also, I noticed an article (I can't remember what one) before I saw this post that had two infoboxes and two short descriptions. There shouldn't be too many articles that have multiple infoboxes but would that happen with this automated feature? StarcheerspeaksnewslostwarsTalk to me 16:59, 25 January 2019 (UTC)
A short description is only generated if an infobox album is in the lead section and is the only infobox in the lead, so I don't think that should be an issue. Galobtter (pingó mió) 13:46, 26 January 2019 (UTC)
That doesn't appear to be the case with Hopes and Fears, where a second infobox further down the page is overwriting the short description from the first one. -- I need a name (talk) 11:25, 3 March 2019 (UTC)
I need a name, thanks,  Fixed, doesn't display description in those cases. Galobtter (pingó mió) 12:01, 3 March 2019 (UTC)
Thanks, although that means it's now defaulting to the Wikidata description. Would it be possible to add a field like |short_desc= to the template for manually adding the description or would it be better to just use {{Short description}} in such cases? -- I need a name (talk) 12:15, 3 March 2019 (UTC)
 Done Galobtter (pingó mió) 10:04, 25 February 2019 (UTC)
@Galobtter: Question. The description is created through the infobox without anyone seeing or knowing that it exists when in edit mode, correct? So if someone trying to be helpful adds {{short description}} to the page, will that override the default automated description? Also, since those adding it are creating unnecessary work for themselves, is there a way to find out which album pages with infoboxes have a short description that was added manually as well? Thanks. StarcheerspeaksnewslostwarsTalk to me 02:36, 7 March 2019 (UTC)
Starcheerspeaksnewslostwars, Well, a manual description should override the automated description, except I messed up and it actually doesn't; I'll see about fixing that, since although many of the manual descriptions are of lower quality than the automated ones, it still should be possible to easily override the automated description.
Do a search for insource:"short description" hastemplate:"Infobox album" insource:/short description[^=]*infobox album/i - about 2000 album pages have a manual short description. Most I see were added using User:Galobtter/Shortdesc helper in which case they will see the automatically generated description though (now that it is there). Galobtter (pingó mió) 05:48, 7 March 2019 (UTC)

Extra chronology

Regarding the extra chronology, the release Live at the Paramount (video) was released first as a DVD/Blu-ray video in 2011 and the audio album on vinyl was not released until 2019. If it had been the other way round it would have been a simple case of denoting the extra chronology as type: video. However, this appears to be a rare case where the video has been released first. As such both chronologies are not differentiated in the output. I have added "video" and "album" to the titles to differentiate for now, but can this issue be addressed ? QuintusPetillius (talk) 20:16, 16 April 2019 (UTC)

I think type should equal live. ―Justin (koavf)TCM 22:00, 16 April 2019 (UTC)

Yes, I have done that already, but the point I am getting at is there is nothing to differentiate between the two chronologies. Neither says "video chronology" or "album chronology".QuintusPetillius (talk) 17:03, 17 April 2019 (UTC)

Format

Shouldn't there be a section to indicate format -- CD, cassette, vinyl, download etc.? Sheila1988 (talk) 11:40, 29 June 2019 (UTC)

I can see that being mildly useful if the subject album was only released on specific formats, but since most are released on multiple formats,[CN] this could get old fast. If excluded or empty, would the output of |format= (working title) be omitted or populated with a coverall? I assume you imagine the data will be linked to the most suitable respective article about the format? I can't see the need for a convenience link to the various formats, especially if not all are listed on each article. It can be argued that the noteworthiness of the format upon which an album (single, movie etc. for that matter) is rarely of any interest beyond the technical, and could be considered trivial. Where the information is notably non-trivial (perhaps only released as a download because the band and label were in dispute or similar), I'm sure it would be better covered in the article body. Fred Gandt · talk · contribs 12:02, 29 June 2019 (UTC)
I see {{Infobox song}} has a |format= parameter. I wonder if this has been discussed before? Fred Gandt · talk · contribs 20:26, 1 July 2019 (UTC)
Yes it has; see Template talk:Infobox album/Archive 9#Proposed addition of a "format" parameter closed as "no consensus" 2014. Fred Gandt · talk · contribs 20:29, 1 July 2019 (UTC)

Producer parameter confusion

According to Template:Infobox album the producer parameter is for the person(s) credited with the record production. This is someone who oversees the recording process. I am confused as to why vocal producers, co-producers and executive producers are being included in this parameter as well?

I also find it bizarre that producers of bonus tracks and Japan bonus tracks not included on the main album track listing are included in this parameter as well. Could someone please clarify this for me? CoolMarc 14:07, 11 August 2019 (UTC)

Wikipedia is full of work done contrary to documentation, guidelines and even policies; while the infobox template doesn't specifically handle other roles, I suppose editors who are unfamiliar with, or just don't care about, the template's documentation, will just stuff things in wherever they seem to fit. Consider landing on a page about something one's interested in, and finding that the philistines who wrote the article failed to mention the janitorial staff! Alarm bells ring; a giant red countdown timer starts; epic music plays! It's now or never; the fate of humankind is at stake! MUST. ADD. INFO. NOW!! Consequently, it gets shoehorned in with little to no regard for standardisation or continuity.
So, three questions need to be asked:
  1. Should the various production-like roles be included in the |producer= slot (which, it should be noted, is built to handle lists)? or
  2. Does this template need special handing for other roles? or
  3. Should the information about other roles (where not exactly per docs) be blanket removed from articles, because the template docs don't specifically mention them?
I hope most people would answer a strong "no" to question 3, in preference of additional handling or a change to the documentation. Fred Gandt · talk · contribs 15:42, 11 August 2019 (UTC)
Vocal producers, executive producers, Co-producers are not the same as the actual record producer, so I would think they do not belong in a parameter used to name record producers. Also I don't think producers of bonus tracks not on the main album track listing belong here either. It is bizarre for example when you see a said producer in this parameter at the start only to find out later they only produced bonus track 21 of the album's Japanese version. This is obviously just my view on things but I think whatever the standard is, it should be clarified on Template:Infobox album. CoolMarc 15:59, 11 August 2019 (UTC)

RfC on naming countries in infoboxes

A RfC which may affect this infobox's |studio= and |venue= parameters has been opened at WT:WikiProject Music#Naming countries in infoboxes. Please add your comments there. —Ojorojo (talk) 17:20, 17 August 2019 (UTC)

"Released" parameter and future dates

I have some questions due to revert warring on a future album (this is not a formal RfC yet so freeform answers are fine):

  1. Can "Released" be used for scheduled or anticipated release dates as the infobox is current worded?
    1. Does this violate WP:CRYSTAL since we don't know if it will actually happen? Specifically Dates are not definite until the event actually takes place.
    2. Does this violate simple grammar and logic since the parameter is phrased in the past tense, "Released"?
  2. Are any of the following solutions appropriate:
    1. Changing the text to "Release date" (still would seem to violate the portion of CRYSTAL I quoted)
    2. Adding a "Scheduled release" or similar parameter
    3. Adding logic to select wording based on whether release date is in future or not (which is problematic due to not knowing time of day or timezone)

Thanks. —DIYeditor (talk) 23:35, 19 August 2019 (UTC)

Unless someone creates some sort of “future release” section, if there’s reliable sources stating the date, it’s appropriate. As someone who has created and maintained a lot of future albums, I can say that it’s generally uncontentiously done this way. Sergecross73 msg me 23:46, 19 August 2019 (UTC)
DIYeditor, There's really no need for any technological solution here: if an album says that it is "released" next January, that is obviously in the future. I really don't see why anyone needs to edit-war over a release date that has a source. If it changes, change the information. ―Justin (koavf)TCM 00:11, 20 August 2019 (UTC)
"Dates are not definite until the event actually takes place." What we are doing here is stating that something will happen in the future on a certain date (actually, by my reading, that the future has already happened, but either way) despite not being able to know that. —DIYeditor (talk) 00:18, 20 August 2019 (UTC)
DIYeditor, Sure but can we have utter certainty about past events? ―Justin (koavf)TCM 01:13, 20 August 2019 (UTC)
Again, it’s okay to make comments on future events with reliable sourcing. As one can plainly see, there is no current ban on future release dates on Wikipedia. Nor should there be, that would serve no purpose to the reader. Application like what you’re proposing would benefit no one. Sergecross73 msg me 01:20, 20 August 2019 (UTC)
If the prose read "scheduled to be released on ..." it is safe for the infobox to read the proposed date. It is a summary of the article. Most people understand that the date could change. It is not a case of CRYSTAL as that only applies to creation of articles. In this case, WP:HAMMERTIME also applies. However, WP:PROMOTION does apply, and this is where my opinion diverges from much of the project. If we can't say much about the album, we shouldn't have an article, let alone an infobox in it. Wait for the album to be reviewed by at least one source. Walter Görlitz (talk) 03:15, 20 August 2019 (UTC)

Please change the guideline for chronology to exclude releases without articles in favor of release with articles

A content dispute at The Taylor Swift Holiday Collection has led me to ask for this change to the current template guideline. As I said there, it's more important to lead readers to the next significant release in an artist's discography than it is to show readers the next release was one so insignificant that no article covered it. Per WP:COMMONSENSE and Wikipedia:Ignore all rules: "When advancing a position or justifying an action, base your argument on existing agreements, community foundation issues, and the interests of the encyclopedia, not your own common sense." Dan56 (talk) 15:28, 24 September 2019 (UTC)

Could we still call it a chronology if it didn't show the next chronological release? I feel like it would need to be renamed "Next/Previous Album that Meets Wikipedia's Notability Guidelines" or something to explain to readers that the listed album technically isn't truly chronologically next, it just has an article and the other one doesn't. The last time I saw this discussed the point was brought up that nowhere on Wikipedia is there a list of chronological albums from an artist. The artist's discography and navbox already provide links to other albums, so do we really need a third thing to provide the same function to readers? Fezmar9 (talk) 16:04, 24 September 2019 (UTC)
Yes, we could still call it a chronology. Because the purpose of an infobox is to summarize at a glance key facts and do so in short form, not to be a complete account of information found in the article or elsewhere. Additionally, "general consistency should be aimed for across articles using the same infobox", and it would be less consistent if there is a break in the navigation across articles. And if we are going to have a pedantic outlook (like to argue the release following isn't "truly chronologically next"), then it holds true that the chronology section doesn't label or specify that the next release showing is immediately next. Dan56 (talk) 16:37, 24 September 2019 (UTC)
(edit conflict) Huh? Adding the next chronological release regardless of notability does not impact the infobox's ability to present key facts in short form. In fact, adding the next album that doesn't have an article is closer to a fact than adding an album released years later just because it has an existing article. You're also using the word "consistency" in two different contexts here. The guideline you're quoting is suggesting whatever is agreed upon should be used consistently across similar Wikipedia pages, but you're suggesting it would introduce a navigational inconsistency, which is not what the guideline is referring to. If all articles are presenting chronologies regardless of notability, that would be very consistent and in agreement with that guideline. And actually the infobox does imply that what's listed immediately follows because that is literally the definition of chronological ("an arrangement in order of occurrence") . Fezmar9 (talk) 17:36, 24 September 2019 (UTC)
[moved my comment since Fezmar9 is addressing Dan56's comment] Agree 100% with Fezmar9 reasons. If chronologies are to remain (I disagree that they are "key facts" about the release), they should be "arranged in the order of their occurrence" (dictionary def). Since only official releases should be included, most insignificant albums are excluded. —Ojorojo (talk) 17:33, 24 September 2019 (UTC)
  • Embarrassing edit war on that Taylor Swift article; an argument by edit summary and no attempt at discussion on the talk page; *shakes head*
  • I agree with Fezmar9 and Ojorojo; chronologies should not be notabilities
  • If navigation being interrupted is the actual problem i.e. reaching a dead end because an article is missing (and unlikely to be created); perhaps a solution is to allow the |next_title= parameter to carry a list which terminates at the next live article? Fred Gandt · talk · contribs 20:06, 24 September 2019 (UTC)
Bullets? Why?
No, a chronology is not a list of notable works, it is a list of similar works of this type by the subject that came before and after this work. This applies to singles and albums. I've even seen separate chronologies for studio albums and live albums. Navigation templates go at the bottom of an article. That is the correct location for a list of all works with articles. Walter Görlitz (talk) 20:18, 24 September 2019 (UTC)
Thanks, Merriam. But what good does it do a reader (which should be our priority), for them to see a (supposed) release title in the infobox, for which no article exists? Just words in italics and a year in parenthesis, without a link to anything for context. Can they at least be pipe-linked to the artist's discography article? Dan56 (talk) 22:06, 24 September 2019 (UTC)
An unlinked album does no more harm to a reader in a chronology than it does in a discography or an artist's biography. The aim of the infobox field is information, not navigation. Fezmar9 (talk) 22:12, 24 September 2019 (UTC)
It actually does, because at a discography article, there is information about the release; there is context. The aim of the infobox is information within the article. Dan56 (talk) 22:14, 24 September 2019 (UTC)
See here, WP:IBX: Keep in mind the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article Dan56 (talk) 22:15, 24 September 2019 (UTC)
It actual does no harm to the reader because the infobox is not a navigation template.
At worst, it would do more harm indicating that the next work is a notable one and omitting all of the non-notable works in the sequence. If albums A, B and E are notable while C and D are not, making the infobox of B show only A and F could lead the reader to assume that the three albums between them do not exist! Again, the infobox is to be a summary of the article and provide the information in a compact format. Its primary function is not for navigation. The navigation function is what the nav box at the bottom is for. The fact that we are able to navigate all of the works for some artists using the infobox is simply because their works are all notable. Not all works created by notable subjects are automatically notable. Walter Görlitz (talk) 22:25, 24 September 2019 (UTC)
My question is about pipe-linking to the release's section in a discography page. And, as it is here, there has been no reported harm to readers so far. Dan56 (talk) 00:04, 4 October 2019 (UTC)

An Italic Title Issue

See Aleluya (En La Tierra). The page title is half in italics and half not. The whole thing should be in italics because that is the full title of the album. It appears that something is going on with the italics function in the Album Infobox. I cannot figure out the problem myself. Also inquired at [1]. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 20:33, 12 November 2019 (UTC)

 Done An editor named PrimeHunter has fixed it. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 20:38, 12 November 2019 (UTC)

RfC on producer entries in infobox album

A discussion has begun at WT:ALBUMS#RfC on producer entries in infobox album regarding the |producer= parameter used in this infobox. Please add your comments there. —Ojorojo (talk) 16:02, 15 January 2020 (UTC)

We need to change this rule

Why is that any singles on any re-releases of an album are NOT included under the singles box? As long as the singles are promoted within the album itself it SHOULD count as a single, that just seems like common sense to me. Aardwolf68 (talk) 06:46, 24 January 2020 (UTC)

What exactly is a single on a re-release? Walter Görlitz (talk) 06:46, 24 January 2020 (UTC)
I think Aardwolf is referring to when an album is re-released with new songs and they are released as singles, they aren't always included in the infobox. → Lil-℧niquԐ1 - (Talk) - 13:30, 24 January 2020 (UTC)
One of the specific rules within the infobox says to NOT include singles on album re-releases. Can somebodybplease explain to me why this is? That makes no sense and doesn not have an argument for the rule. I say it's about time that we change it Aardwolf68 (talk) 14:39, 24 January 2020 (UTC)
I've never seen a re-release have new singles. I've seen deluxe editions released with one single. Where's an example of what you're stating? I'm open to reviewing the documentation if a case can be made. Walter Görlitz (talk) 15:54, 24 January 2020 (UTC)
I'd like to see some reliable sources that indicate the singles were released "during the marketing and promotion of the album". Often, singles are released prior to and after the album's promotion phase. These stand on their own and are marketed independently of the album. In any event, these details are not always key facts as presented in the main body, if they are discussed at all. —Ojorojo (talk) 16:10, 24 January 2020 (UTC)
Doll Domination by Pussycat Dolls is a great example. It was released in 2008 then re-released in 2009 with two brand new singles "Hush Hush; Hush Hush" (a remix of a song from the original album not previously released) and then also "Jai Ho!" a completely new recording. Editors at the page chose to include the singles in the infobox because the re-releases formed part of the same chart listing as they had the same name etc. → Lil-℧niquԐ1 - (Talk) - 16:14, 24 January 2020 (UTC)
Many modern releases, particularly pop or urban releases, get re-releases with deluxe editions being released later. One Love by David Guetta is another example of that → Lil-℧niquԐ1 - (Talk) - 16:15, 24 January 2020 (UTC)
Deluxe editions are not re-releases, they're just a money-making effort to fleece fans: "wow three new songs". It's part of the original release and should be treated as such. Third Day (album) is a re-release. It was released on a small label, the band signed with a larger label, they re-packaged it and released it with additional tracks in a new order. There are instances where a work is re-mastered and released with bonus material, but I have not seen singles appear from those works. Deluxe editions should be treated as part of the original release as should any singles from the release of deluxe editions. Walter Görlitz (talk) 16:51, 24 January 2020 (UTC)
From the guidance wording, more than the fact that a single was released is needed, otherwise it could simply say "list singles here". They must be noteworthy in the context of the album. If a single is released when a classic album gets a "deluxe" or anniversary edition, it may be argued that it promotes that edition, but not the original. The guidance makes clear that only info about the original release be included in the infobox (see cover, release date, length, and label). So it follows that singles are treated similarly. —Ojorojo (talk) 17:49, 24 January 2020 (UTC)

Then I pose this question: How exactly do we classify re-releases and deluxe editions differently, and what difference does it make o include the singles listed in the album's tracklisting? Aardwolf68 (talk) 00:32, 25 January 2020 (UTC)

Do we need to? Releases that are separated by years or labels are clearly re-releases. Releases that add "bonus material" without significant difference in time and on the same label are simply different editions of the same album. Walter Görlitz (talk) 00:52, 25 January 2020 (UTC)

But who's to say that we're in control of deciding that? In any case- my main point of discussion is about singles being listed in the infobox and why it matters to seperate re-releases from deluxe editions when including them Aardwolf68 (talk) 09:50, 27 January 2020 (UTC)

I think Walter has summed it up perfectly. → Lil-℧niquԐ1 - (Talk) - 15:40, 27 January 2020 (UTC)

Singles

In going over some newer album articles, I noticed that many or most album tracks are released as singles. Listing them all can double the length of the infoboxes and push them far down into the following sections. Singles are often discussed (or should be) in the main body, but are they really needed in the infobox? Also, some were released a year or more before the albums, so I wonder if they actually meet the guidance "were released as singles during the marketing and promotion of the album". —Ojorojo (talk) 18:42, 24 April 2020 (UTC)

Ojorojo, If you can give some e.g.s, that would be helpful. ―Justin (koavf)TCM 19:12, 24 April 2020 (UTC)
LP1 (Liam Payne album), We Love You Tecca, Why Me? Why Not., This One's for You (Luke Combs album), Divinely Uninspired to a Hellish Extent, While I'm Livin', Carte Blanche (DJ Snake album), Imperfect Circle, Rewind, Replay, Rebound, When We All Fall Asleep, Where Do We Go?, ADHD (Joyner Lucas album), The Later Years, etc. —Ojorojo (talk) 14:24, 25 April 2020 (UTC)
Ojorojo, If the singles are supported by a source then it's fine, but looking at the articles that you pointed out have no sources. I think removing the unsourced singles is the best idea. TheAmazingPeanuts (talk) 15:57, 25 April 2020 (UTC)
@TheAmazingPeanuts: That would work in the short run, but after sources are added, we're back to overly long infoboxes. Review ratings used to be included in infoboxes; once they were removed, people didn't seem to miss them. The distinction between singles and "tracks" is becoming increasingly blurred and really doesn't have the importance it once did. —Ojorojo (talk) 17:33, 25 April 2020 (UTC)
Copy about the nature of the "singles" and their WP:SECONDARY sources would be placed in the body of the article and so no need for references in the infobox would be necessary. Just being released as a video does not indicate that the song is a single. Walter Görlitz (talk) 18:22, 25 April 2020 (UTC)

odd case: 7eventh Time Down

There's an issue with linking the chronology of the albums for the band 7eventh Time Down. It can be seen Just Say Jesus where it capitalizes the first letter, and there's no article at 7Eventh Time Down. It's easy enough to fix by using a redirect there, but it would also be easy enough to fix by not forcing a cap on the first letter in the word if it's not the first letter in the string. Walter Görlitz (talk) 16:25, 6 May 2020 (UTC)

Walter Görlitz, It comes from the "ucfirst" passage. Not sure what that's there to be honest, except maybe so that (God forbid), we would see "the Beatles chronology" instead of "The Beatles chronology". Let me see if I can fix it. ―Justin (koavf)TCM 16:31, 6 May 2020 (UTC)
Thanks. It's on Infobox Song as well. Walter Görlitz (talk) 16:33, 6 May 2020 (UTC)
See Template talk:Infobox album#Inconsistency of capitalization style. —Ojorojo (talk) 16:46, 6 May 2020 (UTC)
Walter Görlitz, There's no problem at (e.g.) Just Say Jesus (song) (note that I am redirecting that page now, see the history). ―Justin (koavf)TCM 16:54, 6 May 2020 (UTC)
The documentation for this template explains what to do in this edge-case situation: The first letter of the artist name given in artist= is automatically capitalized in the chronology header so that band names starting with "The" appear as recommended in the Manual of Style. If the first letter of the artist's name should appear in lower case, enter the artist's name in chronology= as you wish it to appear, e.g. chronology=letlive... I have asked Koavf to revert the most recent change that removed ucfirst; ucfirst had been implemented as a result of the discussion above. – Jonesey95 (talk) 17:06, 6 May 2020 (UTC)

Should the automatic upper-casing be removed?

In a discussion section above, we decided that in order to better comply with MOS guidance on capitalization of "the" at the front of band names, we would use ucfirst to apply automatic upper-case to the first letter in |artist= when it appeared in the Chronology header. This change has the known side-effect of upper-casing the first letter of an artist or band's name in the very rare case when the preferred style of the artist/band name is to lower-case the first alphabetic character. See the discussion above for a few examples of this very rare case; 7eventh Time Down, mentioned at the top of this section, is another example. The template's documentation explains that |chronology= should be used to fix these very rare cases.

Koavf proposes to undo this upper-casing entirely. This would presumably decrease MOS compliance across a wide array of articles, while preventing the inconvenience of needing to use |chronology= in a small handful of articles. It is quite possible that we can come up with a more elegant way to manage this upper-case/lower-case situation. Maybe, for example, there is a tool similar to ucfirst that limits its action to the first character instead of the first letter. Changes in the template's sandbox and the testcases page are welcome, as is discussion of ideas about how to manage this situation. – Jonesey95 (talk) 21:13, 6 May 2020 (UTC)

"The" in band names is fairly common, but names that begin with a lower case letter or number are rare. Whatever benefits the most occurrences should be used. It's just a matter of one or the other having to use |chronology=. Also, if the proposed change is made, who will go through and correct all the current infoboxes that use the lower case "the"?—Ojorojo (talk) 22:12, 6 May 2020 (UTC)
Ojorojo, "T/the Beatles" is perfectly fine and works but "6band" where "6Band" is a redlink doesn't work. This is a choice between many instances of a small style issue being fixed versus a few instances of the purpose of the field not working at all. ―Justin (koavf)TCM 22:26, 6 May 2020 (UTC)
Could someone come up with a tracking category that shows how many occurrences "don't work at all"? It probably would be easier just to add |chronology= to those rather clean up all the "the"s. —Ojorojo (talk) 22:46, 6 May 2020 (UTC)
Despite Koavf's declaration that there were only two possible choices, I have found what appears to be a third option. I have added a test to the "chronology" header that is intended to check the first character of the artist. If it is a letter, upper-casing proceeds as usual, so album articles like Fake History by letlive. will still need to use |chronology=, but Alive in You by 7eventh Time Down is fixed. Please let me know if you find any bugs. – Jonesey95 (talk) 00:20, 7 May 2020 (UTC)
Jonesey95, The magic word {{ucfirst:}} only capitalizes the first character. Galobtter (pingó mió) 00:14, 7 May 2020 (UTC)
That has not been my experience. To wit:
{{#invoke:String2 | ucfirst |[[7eventh Time Down]]}}7eventh Time Down
My experience is that the first alphabetic character in the string is upper-cased, which is a bit frustrating, but working as currently documented on the page for ucfirst. – Jonesey95 (talk) 00:20, 7 May 2020 (UTC)
I mean the magic word: {{ucfirst:4foo}} gives 4foo. Galobtter (pingó mió) 00:22, 7 May 2020 (UTC)
Oops, totally missed that there was a difference. I am using Module:String2. I wonder why they are different.
{{#invoke:String2 | ucfirst |[[7eventh Time Down]]}}7eventh Time Down
{{ucfirst:[[7eventh Time Down]]}}7eventh Time Down
Unfortunately, it doesn't really help when a wikilink bracket is the first character:
{{ucfirst:[[the Beatles]]}}the Beatles
Strange. I could probably try to delink and then re-link, but ugh. – Jonesey95 (talk) 00:25, 7 May 2020 (UTC)

Inconsistency of capitalization style

At MOS:MUSICCAPS we are instructed to use lower case 'the' in running prose for band names, for instance the Beatles released the album The Beatles. But in the infobox coding, there is no way to have the correct version of the band name show up at the correct spot. We either have an incorrect capital styling in the sentence "Studio album by The Band" or we have an odder styling of lower case 'the' starting a new line as "the Band chronology".

An example can be seen at A Date with Elvis (Cramps album) which says "Studio album by the Cramps" (proper Wikipedia style) but below that it says "the Cramps chronology" in a new header, which shows a lower case 'the' incorrectly.

The opposite example can be seen at Bad Music for Bad People which properly says "The Cramps chronology" but displays the wrong styling of "Compilation album by The Cramps".

Can we tweak this template's background coding to accommodate the two styles? The brute force method would give us two places to enter the band name, one with capital 'The' for band chronology and one with lower case 'the' for running prose. Perhaps there's a more automatic way to solve the problem.

Note that Template:Infobox song has the exact same style problem. Both should be fixed at the same time. Binksternet (talk) 19:54, 8 October 2019 (UTC)

Nothing to add except to say this has always annoyed me too. Popcornduff (talk) 19:55, 8 October 2019 (UTC)
I have modified the template's sandbox to capitalize the first letter (and only the first letter, with the rest of the letters left alone) of |artist= in the Chronology section. You can see an example on the test cases page. I think this will solve the problem, with one big caveat: if a band's name is supposed to be written in all lower case, this change will capitalize the band's name in the Chronology section. Are there bands with that limitation? If so, we need to be more clever. – Jonesey95 (talk) 21:57, 8 October 2019 (UTC)
|chronology= has been used to work around these problems. Template:Infobox album#chronology includes: "This field can be used when the album belongs to an overall series that is not adequately described by the artist's name alone; in these situations, the text entered in this field replaces the artist name that would normally be displayed preceding 'chronology'." Five Live Yardbirds uses |artist=the Yardbirds and |chronology=The Yardbirds), so they appear correctly. The group name stylized as letlive. is an example of Jonesey95's last concern. For The Blackest Beautiful, |chronology=letlive. would need to be added if the first letter of |artist=letlive. is automatically capitalized. The link in |artist= is also automatically repeated in the chronology, so it appears twice (unnecessarily?) in the infobox. —Ojorojo (talk) 14:24, 9 October 2019 (UTC)
(edit conflict) I looked around and did some web searches for band names that are styled in all lower case, and it was a surprisingly difficult search. I found The xx, which is a pretty cool name, written "the xx" in running text; since there is a "the", they won't be affected. There's Letlive, stylized letlive., but in the infobox for their album Fake History, a WP editor has already capitalized the artist's name, so it's quite possible that nobody will notice this change. See also fun. I also stumbled across !!!, which is a bitchin' band name; I tested one of their albums with the sandbox version of the template, and nothing appeared to change.
Thanks to Ojorojo for actually reading the documentation to see how |chronology= works; that looks like a great solution for edge cases like letlive. I'm going to move this change from the sandbox into the live template and document it. – Jonesey95 (talk) 14:37, 9 October 2019 (UTC)
Unless someone sees a problem (maybe link this discussion on Template talk:Infobox song), the same should be added to that infobox as well. —Ojorojo (talk) 14:52, 9 October 2019 (UTC)
 Done after some testing in the sandbox; {{Infobox song}} is more complex than this album template. – Jonesey95 (talk) 15:06, 9 October 2019 (UTC)
Jonesey95, Heads up that I removed this, per below, as it was generating redlinks. If necessary, the solution is to use the chronology field to enter "The Beatles" or "the Beatles" as necessary. Better to have some awkward caps than to have redlinks. ―Justin (koavf)TCM 16:56, 6 May 2020 (UTC)
Please revert. I think you threw out the baby with the bathwater. Band name edge cases are clearly documented in this template's documentation. – Jonesey95 (talk) 17:05, 6 May 2020 (UTC)
Jonesey95, I don't think this is wise but I'll revert for collegiality. Will you revert your changes to the template as well? ―Justin (koavf)TCM 18:39, 6 May 2020 (UTC)
The band "65daysofstatic" oddly gets its name in the chronology changed to "65Daysofstatic" (example). It's fixable with |chronology=, but it certainly seems like something that shouldn't be happening. The documentation for Module:String2 is a bit contradictory. Under "Functions" it says that "ucfirst" renders the first alphabetical character in upper case (which is what actually happens), while under "Usage" it claims to capitalize the first character (which is the way I think it should work). MANdARAX  XAЯAbИAM 01:07, 2 January 2020 (UTC)
This problem has been fixed. See below. – Jonesey95 (talk) 00:32, 7 May 2020 (UTC)

Genre's

It does not specify here what the acceptable amount of genres are for the infobox as it does at Infobox musical artist which is 2 to 4. Would 2 to 4 also apply? Robvanvee 15:13, 8 May 2020 (UTC)

I worry when I read a plural that uses an apostrophe.
We tend to rely on common sense. If source consistently apply one genre, then that's all that is needed. If no sources can agree, then leave it blank. If the sources vary but centre around five genres consistently, then list five. There is no policy for the number of genres other than conveying what the reliable sources state and be sure the reader understands the genres that represent the work. WP:GWAR offers some additional insight. Walter Görlitz (talk) 15:52, 8 May 2020 (UTC)
Quite right, a thoughtless error but don't lose any sleep over it
I've been around for a few years so I'm quite familiar with your link and the logic behind your explanation which I have always attempted to adhere to but is there a reason this template is so vague and Infobox musical artist is very specific? It does make reasoning with an unreasonable editor easier if you are able to refer them to a guideline that is more specific such as 10 reviews per review box for example. Robvanvee 17:21, 8 May 2020 (UTC)
Robvanvee, Reducing bickering by creating very precise rules seems like a good idea and sometimes works but sometimes, it just results in more bickering about the rule. E.g. if it were strictly limited to four, then wouldn't editors just fight over which four out of the 10 that are found in reliable sources belong in the infobox? I think that unless an album has more than 10 or so, it's not really a problem. I would wonder about an album that has 17 sourced genres, unless it were something like a sampler but even then, that seems excessive and "Various" would probably be the best thing to enter into the infobox. ―Justin (koavf)TCM 19:49, 8 May 2020 (UTC)

Chronology header missing?

Just noticed that the chronology header "Artist chronology" and "Artist single chronology" (for infobox song) are missing in several articles. Could this be from Jonesey95's recent edits or ? —Ojorojo (talk) 19:44, 13 May 2020 (UTC)

Caused by edits to Module:Infobox, now fixed. —Ojorojo (talk) 20:28, 13 May 2020 (UTC)

Template:Promotional singles

I assume to complement Template:Singles, someone recently created Template:Promotional singles, yet on the documentation page for this infobox, it says "Do not add specialty- or limited-release singles, such as those supplied to radio stations and music publications, which are often marked as 'Promo copy' or 'Promotional'." In this digital age, I don't know what constitutes a promotional single anymore, but the use of a separate sub-template for the infobox still seems overkill. StarcheerspeaksnewslostwarsTalk to me 21:57, 28 May 2020 (UTC)

Promotional singles have never been included in the infobox and I agree, there isn't a hard and fast rule for what constitutes a promo single. Also it seems silly to have a promo template when sometimes promo singles are then released again as proper singles. Something like a template like this needs a consensus of support. It looks like it has been created for a series of Taylor Swift album pages. I can't see any discussion where this has been agreed or approved. ≫ Lil-Unique1 -{ Talk }- 22:58, 28 May 2020 (UTC)
Promo singles are not well-defined and are subject to changes by the music industry to meet marketing strategies. These types of tentative peripheral details have no place in album infoboxes. On a broader note, over the years, efforts have been made to achieve consensus on the infobox parameters and guidance. This should not be so easily bypassed by one editor creating a subtemplate to be inserted into the main infobox. Template:Promotional singles should deleted. —Ojorojo (talk) 13:53, 29 May 2020 (UTC)
Starcheerspeaksnewslostwars and Ojorojo, I've started a formal deletion nomination at Wikipedia:Templates_for_discussion/Log/2020_May_30#Template:Promotional_singles. I believe SCSNLW had previously nominated it for deletion in 2011. ≫ Lil-Unique1 -{ Talk }- 20:23, 30 May 2020 (UTC)

Studio parameter of the album's infobox (Template:Infobox album#studio)

Is the studio parameter of the album's infobox Wikipedia definition only for recording studios where a record was recorded, and not where it was overdubbed and/or mixed? "If the album was recorded in a recording studio, enter the name and location." (Template:Infobox album#studio). It does not say to include anything other than a studio in which the album was recorded. The Wikipdia page Audio mixing (recorded music) states "Before the introduction of multitrack recording, all sounds and effects that were to be part of a record were mixed at one time during a live performance. If the recorded mix wasn't satisfactory, or if one musician made a mistake, the selection had to be performed over until the desired balance and performance was obtained. With the introduction of multi-track recording, the production of a modern recording changed into one that generally involves three stages: recording, overdubbing, and mixing." Since the 1970's, record albums have been recorded in three stages: recording, overdubbing, and mixing. It was common practice to record an album in one studio, overdub in another studio and mixed in another. I would argue for the listing of every recording studio that was used in the making of the song or album. Please weigh in here.Joanne.nathan (talk) 13:58, 6 July 2020 (UTC)

Please add your comments at WT:ALBUMS#Studio parameter of the album's infobox (Template:Infobox album#studio). —Ojorojo (talk) 14:02, 6 July 2020 (UTC)

Important discussion about singles and when to include in the album infobox

See Talk:Brightest_Blue#RFC_on_Singles_from_the_Album. Thanks ≫ Lil-Unique1 -{ Talk }- 11:13, 17 July 2020 (UTC)

"Class" not working on mobile?

I have seen an editor or two complain that the data/labels that include an "class" for {{hlist}} seems to not be working on mobile devices. I have checked myself, and while it does work for my own mobile device, that [may not] also mean that the issue does not exist. Is there a way to address and potentially fix this? livelikemusic (TALK!) 16:53, 23 July 2020 (UTC)

As always, please link to discussions, or to articles where the reported problem can be observed, or both. – Jonesey95 (talk) 18:08, 23 July 2020 (UTC)
Folklore (Taylor Swift album) and Smile (Katy Perry album). livelikemusic (TALK!) 18:14, 23 July 2020 (UTC)
I am seeing the |producer= parameter in those articles being rendered as an hlist separated by dots in desktop view, and as an unnumbered, unbulleted list in mobile view. Is that what you and the reporting editors see as well? I don't use the mobile view, so I don't know what it is supposed to look like. Do you know if this is a recent change? If so, something may have changed in the underlying code somewhere, which would mean that we should see this problem in other infoboxes. – Jonesey95 (talk) 22:36, 23 July 2020 (UTC)
I am unsure; I do not have the issue on my own mobile device, but, it seems others are, too, and it is only when hlist is automatically called upon. No clue how long this issue has existed, either. livelikemusic (TALK!) 13:02, 24 July 2020 (UTC)
I modified the article so that the genre uses a physical {{hlist}} and it renders as a bulleted list on my iPhone 6S using iOS 13.5. The producer, which renders as a bulleted list on my desktop Firefox, renders as a vertical list in iOS. The hidden "additional recording" locations are expanded and the locations is a vertical list. We should not be using parenthesis around cities (but that's just preference). Also, there is a lot of whitespace above and below rows in the infobox in iOS. Walter Görlitz (talk) 18:30, 27 July 2020 (UTC)

Albums with only one single

I started a discussion in Template talk:Singles#Albums with only one single to propose a change to {{Singles}}. I'd appreciate feedback there, thanks. –Dream out loud (talk) 18:08, 1 October 2020 (UTC)

K-Pop Album Repackages Singles?

There have been some discussions and disagreements on K-Pop album pages whether a K-Pop album's repackage counts as a re-release and therefore its single should be omitted from the Infobox Album. The argument has been presented that the repackaged album has its own, separate promotional period, and that the Track Listing can circumvent potential confusion around the single not belonging to the original album. 41matt14 (talk) 03:02, 14 October 2020 (UTC)

This is a malformed RfC. Where is the discussion here? An RfC should only be entered after discussion grinds to a halt. Walter Görlitz (talk) 03:32, 14 October 2020 (UTC)
The discussions have taken place on many different pages for K-Pop albums. Multiple times the Infobox albums have changed back and forth between including or excluding singles from the album repackages in the Singles section. Much of the conversation itself has taken place on Talk:Neo Zone. 41matt14 (talk) 22:53, 14 October 2020 (UTC)
Only details about the original album should be included in the infobox. This is made clear in Template:Infobox album#Details:
  • released: "Only the earliest known date that the album was released should be specified; later release dates (incl. re-issues) can be mentioned in a Release history section."
  • length: "Usually, only the length of the original album release should be entered. The timing of reissues or other releases, such as with bonus tracks, should be added to a "Releases" or similar section in the main body of the article, if noteworthy."
  • label: "Only the record label that the album was originally released on should be specified. Where significantly different versions have been released (featuring alternative track listings) e.g. in the US vs UK, the later release date or record label should be mentioned in the article, for example in a Release history section."
Additionally, listing singles in an album infobox is limited to those that "were released as singles during the marketing and promotion of the album" (Template:Singles). Singles that were not on the original album, but later added to a re-release of the album, don't meet this requirement, such as "singles that were added as bonus tracks on a re-release of an album".
41matt14 argues that K-Pop are "repackages" rather than "re-releases" and therefore are somehow exempt. Albums are sometimes re-released as "Special edition", "Extended/Expanded edition", "Xth Anniversary", "Remixed", "Remastered", etc., often with additional or "bonus" songs as an added incentive. Just because different designations are used does not change the fact that they are later re-releases and not the original or first release. This type of information should be mentioned, along with any singles, in an appropriate section in the main body of the article, but not in the infobox.
Ojorojo (talk) 14:41, 15 October 2020 (UTC)
If the discussions are on other pages, the RfCs should be on one of those pages, otherwise, it's completely disjointed. I'd like to see what the arguments on both sides are to determine if I have a blind-spot in my opinion. With that said, my opinion aligns quite well with Ojorojo's and we have traditionally treated extended editions and compilations differently. Extended editions do not get their own article while compilations do. Walter Görlitz (talk) 16:40, 16 October 2020 (UTC)
My argument is that K-Pop album repackages are different from re-releases since they have their own promotional period. While they may sometimes have a Bonus Track, more often than not they have many new songs, including one single that is promoted on Korean music shows independently of the original album. One of the best examples of this is Neo Zone, where the original album was released March 6, 2020, with one single, Kick It and 12 B-side tracks. On May 19, 2020, Neo Zone : The Final Round was released with the original 13 tracks – which weren't promoted in this promotion and marketing period – as well as its own single, Punch – which was promomted in this promotion and marketing period – and 3 B-side tracks. Punch was not a Bonus Track, and it had its own promotion and marketing period. This is a very good example of K-Pop album repackages overall, which is why I think their singles should be included in the infobox album. Orojojo has presented the argument that it could be confusing to include the single on the infobox album if it wasn't on the original album, but the Track Listing should quickly disambiguate that. 41matt14 (talk) 18:43, 16 October 2020 (UTC)
You seem to be trying to make a distinction between "repackages" and "re-releases" that doesn't exist in order to justify treating them differently in infoboxes. Many of the various re-released albums also have promotions, including for additional or bonus tracks released as singles which were not on the original album. So in this regard, repackages are not different than re-releases. More importantly, repackages with new singles that have separate promotions further illustrates that they do not meet the requirement of being released as part of the marketing and promotion of the original album. If this were the case, details about many "Extended/Expanded", "Anniversary", etc., re-releases could be added to infoboxes, which the guidance is clearly discouraging with its emphasis on only details about the original album.
My point about the potential for confusion can be seen when the fields for |recorded= and |studio= are used: new singles not included as tracks on the original album may have been recorded at different dates and studios. They might even have a different |producer= or |label=. Therefore, it may be misleading to include them in the same infobox; the fact that the correct information is located elsewhere in the article does not excuse adding it in an infobox where it can be misconstrued. To add all the extra recording and other information could overburden infoboxes with details that would detract from providing a clear and concise summary of the key facts (see WP:INFOBOXPURPOSE).
Ojorojo (talk) 23:22, 16 October 2020 (UTC)

If a release is significantly different it might be possible to create a separate section with second infobox within the main article. However Ojorojo is absolutely correct - repackage and re-release are the same thing. New singles (added to the track listing later) are promoting a different version and extension of the promotional period. ≫ Lil-Unique1 -{ Talk }- 18:37, 17 October 2020 (UTC)

Following Lil-unique1's point, perhaps there should be a new discussion on how to best handle various types of re-released albums in WP articles. Usually, re-releases have been addressed in the articles about the original album, but separate articles have been created for some repackaged albums: for example, Humanoids is a repackage of Catch Me with two additional songs; and Spellbound is a repackage of Tense plus three new songs.
WP:ALBUMSTYLE doesn't provide much guidance, but under "Track listing" it includes "Some albums come with deluxe editions, bonus tracks, or extra discs in re-releases. These bonus tracks can be formatted in a similar way to the example above. The track listing for the R.E.M. album Accelerate gives an example of adding bonus tracks to a track listing." Separate articles for albums with two or three additional tracks don't seem to be warranted; maybe this should be clarified in ALBUMSTYLE.
Ojorojo (talk) 15:02, 18 October 2020 (UTC)

Alt text categorization even when no cover?

The template currently places articles in Category:Album articles lacking alt text for covers even if there's no cover image used by the template. Is that what we want? If so, perhaps the category should be moved to Category:Album articles lacking alt text. Jason Quinn (talk) 03:23, 23 October 2020 (UTC)

Jason Quinn, It should be fixed but I haven't gotten around to it. :/ ―Justin (koavf)TCM 05:27, 23 October 2020 (UTC)

Music Genre

Can we use source's subcategory for genre? Entertainment Weekly does this a lot, they are not directly explained in the article. They usual have a sort of "infobox" with the label, release date and genre(s) of the album. Is it okay for us to use that to classify the genre of an album or does it need to be directly explained in the article? I believe I have seen this policy somewhere but I can't seem to find it. MarioSoulTruthFan (talk) 01:09, 1 November 2020 (UTC)

I know for Allmusic its advised against. ≫ Lil-Unique1 -{ Talk }- 01:49, 1 November 2020 (UTC)

RfC concerning songs on multiple albums

On the article for Post Human: Survival Horror, there is a dispute concerning whether or not Ludens should be listed as a single on the album using Template:Singles, because it was originally released for the Death Stranding soundtrack, and later added to Post Human. My questions are: what defines "a single being used for the marketing and promotion for multiple albums" if the second album it is released on is not a compilation album, and, what defines "a single being used for the marketing and promotion of an album" in general? JJP...MASTER!...MASTER!!! master of puppets, i'm pulling your strings (0-3-5)[talk about or to] JJP... master? master? where's the dreams that i've been after (0-3-6-5) 15:03, 15 November 2020 (UTC)

Rather than restating anything I've already said, I'll link the discussion this RfC is branching from: link here. I think the biggest issue comes from consistency between this template and Template:Infobox song, and from the unclear phrasing presented by @JJPMaster:. Despite our differing reads on this information, I totally agree that clarity in phrasing is important to prevent future misunderstandings like this one, or this discussion I also referenced relating to Katy Perry's newest album. Sock (tock talk) 23:07, 18 November 2020 (UTC)
Template:Infobox_album#Template:Singles clearly says Do not include singles that were added as bonus tracks on a re-release of an album. For songs that appear on more than one album, list the song as a single only for the album(s) where the single was released as part of the marketing and promotion of that album. Therefore there are a couple of things that can be looked at: if the record label that originally released the song is different to the record label releasing the album, its not a single from that album. If the single was released before the album was announced and wasn't subsequently referred to as a single from said album but rather simply tacked on the end then again, not a single from the album. ≫ Lil-Unique1 -{ Talk }- 10:40, 19 November 2020 (UTC)
@JJPMaster: "a single being used for the marketing and promotion of an album" should come from a reliable source, such as in a press release or review. Without it, it's just another single, which the parameter guidance entry is trying to discourage from being added to album infoboxes. @Sock: I don't see a conflict with Template:Infobox song#album, since that parameter doesn't depend on whether the single "was released as part of the marketing and promotion of that album". —Ojorojo (talk) 16:54, 19 November 2020 (UTC)
@Ojorojo: I didn't mean to imply a conflict, just that the wordings differ. I personally agree with @Lil-unique1: that the wording reads that way and that, in our specific instance, "Ludens" was referred to as a single from Timefall but not from Post Human, so it should only be considered a single for the former. The record label difference is also a great point I hadn't considered, which also stands to "Ludens"' status as simply a song on Post Human rather than a single. Sock (tock talk) 00:16, 20 November 2020 (UTC)

Singles from re-releases

I would like to discuss the second rule of the singles: "Do not include singles that were added as bonus tracks on a re-release of an album." I understand why this rule was put in place as many albums at the moment simply add on additional tracks upon their release to increase streams and sales, but I think it should be different for singles that actually promote an album and are released after. For example, Fever (Dua Lipa and Angèle song). Like many singles I was mentioning before, it was originally added as a bonus track on Lipa's Future Nostalgia, but it was released to promote the French edition of the album which was released on both CD and LP physical formats. It also appeared in commercials for the reissue and sources including Billboard have called it a single from the album's era. Finally, Lipa described the song as an introduction to the albums 2021 reissue, but another song (titled "We're Good") was referred to as its lead single. I think this is enough for it to appear as a single in the infobox but I just wanted to check here first. LOVI33 01:47, 20 February 2021 (UTC)

What are you calling a re-release? The example you gave is a bonus track to a release, all of which came out within a year of the original date. I believe the "re-release" term signifies an album that was released in one format and much later was re-released on a different format with additional tracks. For instance, an album that was released in the early 80s on vinyl and then later re-issued on CD with three bonus tracks. You might want to discuss at the albums project. Walter Görlitz (talk) 17:27, 24 February 2021 (UTC)

Duration template

For length=, Was {{duration}} deprecated some years ago, or is its use still encouraged? Mac Dreamstate (talk) 21:15, 25 February 2021 (UTC)

Studio/location

Are we using brackets now? This editor seems to think so. I don't agree with it, but the studio= parameter has no style guide. It's been a free-for-all for as long as I can remember, which annoys me because I'm a stickler for site-wide consistency. I've seen small text (which falls foul of MOS:FONTSIZE), commas (my preference), and now brackets. A consistent format should be in place. Mac Dreamstate (talk) 17:36, 23 April 2021 (UTC)

I don't think brackets are a problem, particularly if there are multiple locations and multiple studios in said locations. As for small text and collapsing, I ALWAYS remove both as gross violations of the MOS. ≫ Lil-Unique1 -{ Talk }- 22:31, 23 April 2021 (UTC)
A consistent format has not been adopted or recommended. Besides not addressing it under |studio=, the album template guidance page does not include it in the example infoboxes (the example in Template:Infobox song uses a comma, "Record Plant, New York City"). A certain amount of standardization cuts down on the need for repeated debates over minor stylistic issues, but often there is little support for it. —Ojorojo (talk) 14:44, 24 April 2021 (UTC)
No, parenthesis should not be used. If there are multiple locations, we should use lists. Walter Görlitz (talk) 06:14, 29 April 2021 (UTC)

I mainly just did it to avoid confusion. Look at the article The Number of the Beast (album) for example. It previously just said "Battery, London" as another editor insisted on removing the "Studios" part per the infobox guideline. Now it just makes it seem like it was recorded in a town called "Battery" within London, instead of the "Battery Studios" in London FMSky (talk) 17:18, 5 May 2021 (UTC)

It wouldn't be a problem if we just kept the Studios/Studio or whatever. FMSky (talk) 17:21, 5 May 2021 (UTC)

A better example: https://en.wikipedia.org/w/index.php?title=Thriller_(album)&oldid=1009513628 --- pretty much everyone reading this would assume the city "Westlake, Los Angeles" is meant FMSky (talk) 17:41, 5 May 2021 (UTC)

There was a discussion about it in the past, but I can't find it now. It was not settled, and many editors prefer the parenthetical approach, but I do not believe that any manual of style would use that. Notice how it is handled in the {{cite book}} template: Søm, Author (1999). Some Book. New York, New York: Some Publisher. {{cite book}}: |first= has generic name (help). Notice that it is not parenthetical. That won't stop editors from using it. They also incorrectly apply MOS:CAPS and many other manuals of style. I suggest following a standard rather than trying to create a new one. Walter Görlitz (talk) 05:21, 6 May 2021 (UTC)
Using parentheses does not make it any less ambiguous: one may assume "Westlake (Los Angeles)" is also a district within the city. The link to Westlake Recording Studios makes it clear, although it would have been better entered as "Westlake Recording". —Ojorojo (talk) 14:56, 6 May 2021 (UTC)
I will say, rigidly omitting "Studios" can result in some clunky-sounding stuff: "Criteria, Miami" reads like ass (if anyone were to try that). That's just one example of many possible. Mac Dreamstate (talk) 21:28, 8 May 2021 (UTC)
I totally agree. Removing "Studios" can be ambiguous, without a more rigid synthax. I think that the studio= and venue= options should be optional, because compiling the recorded= camp is sufficient to convey all the needed info. Lewismaster (talk) 17:27, 14 June 2021 (UTC)
Adding parenthetical brackets is far from standard and I don't think it's necessary (or helpful) in that first example cited here. Where there might be instances of multiple studios in the same city, perhaps that approach could be considered.
Agree that the blanket removal of "Studios" can create problems – it needs to be done with some thought involved, rather than robotically. I've seen instances of Twickenham Film Studios reduced to "Twickenham Film", which is ... well, rather silly. JG66 (talk) 17:38, 14 June 2021 (UTC)

So can we remove this from the documentation? "Remove "Studios" if it appears in the name – use Sound City rather than Sound City Studios". Whats the point anyway, to save space?

I guess to avoid redundancy. You see in bold letters Studio, followed by a list of recording facilities called Studios.Lewismaster (talk) 20:49, 14 June 2021 (UTC)
I think it was done to save space and avoid repeating "Studio", similar to the practice of not including "Records" in |label= ("e.g. use [[Universal Records|Universal]] rather than [[Universal Records]]"). Maybe both issues 1) comma vs parenthesis for the city and 2) whether or not to include "Studio" with the studio name, should be addressed in a RfC. Template talk pages don't get much attention and changes to what has been in place for years should not be decided by a small group. —Ojorojo (talk) 13:41, 15 June 2021 (UTC)
If there less than one studio in the infobox I think leaving the word "Studio" is fine, but if there are multiple studios in the infobox I think it would added too much space. TheAmazingPeanuts (talk) 14:58, 15 June 2021 (UTC)
I am in favour of omitting studio and their location, and leaving those details for the personnel section. Walter Görlitz (talk) 06:15, 16 June 2021 (UTC)

Whenever

I'm here to get some suggestions, there's this claimed single called Whenever from The Beginning and apparently according to this source it claims that the song was released as the fourth single from the album, and it charted at the French Singles chart peaking at no. 14, but despite all of this, the single wasn't released nor charted anywhere else other than France. Is it eligible to be included in the Infobox:Singles of that article? Moh8213 (talk) 14:45, 15 July 2021 (UTC)

If there is a reliable source that shows that it appeared in a legitimate chart (see WP:GOODCHARTS) and it otherwise is not excluded under the Template:Infobox album#Template:Singles guidance, it should be OK to add. Just because it was only released in France (likely a major market) would not necessarily make it a "specialty- or limited-release single". Additional input should be solicited on the album, discography, and/or group talk pages. —Ojorojo (talk) 15:42, 15 July 2021 (UTC)
Alright, I understand, tho I think it's worth mentioning that I also found this source were it noted in French "Promotional Disc prohibited for sale", what do you think? Moh8213 (talk) 19:10, 15 July 2021 (UTC)
Discogs is user-generated, so it is unreliable for WP purposes. However, it does raise the question whether "Whenever" did have a typical wide-spread release (in France at least). The image only shows the CD front cover with "The Black Eyed Peas Whenever" and no other info. If it included images of the back and the CD itself (as many Discogs entries do), it might be possible to verify the user-supplied text regarding the music labels and "Disque Promotionnel interdit à la vente". They did not provide the ID numbers and list it as a CDr, which seem odd if it were an official release. Amazon France only shows an MP3 album version[2] (not a RS, but again it does raise the question). I would say that there is enough uncertainty that "Whenever" should not be identified as a single (limited promo or otherwise) until there are some solid sources for it. —Ojorojo (talk) 13:50, 16 July 2021 (UTC)
if discogs.com contains original images of coverts, tray inserts or liner notes, they may be used in lieu of that. Anything else should be considered user-generated content. Walter Görlitz (talk) 06:23, 20 July 2021 (UTC)

Adding unreleased albums to infobox chronology

Ik it's been discussed before but I cannot find where so I'm asking as a refresher: do we include upcoming releases in the infobox (as done by this editor) that have been announced (so covered by secondary sources), but don't yet have their own WP article? -- Carlobunnie (talk) 18:36, 9 September 2021 (UTC)

It looks like it was sourced on the subject's article on September 6, and added to the article the same day. That is acceptable. What is unacceptable is when the album name is not known. Other longstanding project participants may correct me if I have erred. Walter Görlitz (talk) 20:52, 12 September 2021 (UTC)
@Walter Görlitz: Just one correction to your dates: it was added to the TCCF infobox on the 5th (per my link+yours). There was no mention of it in the artist's article on that date. I sourced it on the discog page on the 6th, following which another editor added the release to the artist's article 16 mins later, and then updated that w my source 1 min afterwards. But the takeaway from what you is that it's fine so I'll leave it for now, unless someone says otherwise. Thank you for responding! -- Carlobunnie (talk) 22:03, 12 September 2021 (UTC)

Way to remove "missing" cover art from article infoboxes?

Sorry to send editors to multiple spaces, but please see this discussion re: this ongoing campaign to reduce the number of entries in Category:Album infoboxes lacking a cover. Editors have noticed there are many film articles with soundtrack infoboxes which are unlikely to ever have cover art (for fair use purposes). The aforementioned category will continue being populated unless editors have an option to suppress whatever mechanism is used to determine when infoboxes do not have cover art. Can editors who might be able to help come join the discussion?

Thanks! ---Another Believer (Talk) 19:09, 22 September 2021 (UTC)

@Goszei, Jonesey95, RexxS, Samsara, Galobtter, Jc86035, X201, Zackmann08, and Jc86035: Pinging template editors in case you may be interested or have suggestions for where to seek help. Thanks! ---Another Believer (Talk) 19:11, 22 September 2021 (UTC)

List formatting

Hello everyone. For listing items in the infobox, the template says the following: "For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists the use of the class=hlist is preferred as it offers a benefit to users of screen readers (see Wikipedia:Accessibility for more information on Web Content Accessibility Guidelines). To use it, format the items as a normal bulleted list; don't use other list templates or br />.

For example: | genre =

  • Item one
  • Item two
  • Item three".

I find this confusing, as it first says hlist should be used, but then goes on to say that "to use it", it should be formatted as a bulleted list, and not to use list templates? Hlist is a list template, whereas formatting items as a bulleted list isn't. Not sure if I'm missing something, but does the wording not lead to a contradiction? If anyone could shed some light or explain, that'd be appreciated. I've seen hlist being used almost exclusively in the infoboxes of album articles, and just need some clarity on what the consistency is/should be. Btw, the same wording is used at Template:Infobox song. AshMusique (talk) 13:14, 6 January 2022 (UTC)

Perhaps the wording could be clearer, but it currently states "the use of the class=hlist is preferred" because the parameters themselves use "class[#]=hlist" (see the source code), not that the template {{hlist}} should be used. Since it's already coded into the parameters, adding the template is unnecessary. Formatting the items as a bulleted list as shown in the example produces the same list as using {{hlist}}. What would you suggest? —Ojorojo (talk) 14:06, 6 January 2022 (UTC)
Ojorojo, ah, I see. Thank you so much for explaining, I misunderstood. As you said, the wording could be clearer, so can't it just say it should be formatted as a bulleted list, and not mention hlist? Or, perhaps what you've just explained above could be included as a note? AshMusique (talk) 14:28, 6 January 2022 (UTC)
"Class=hlist" probably doesn't mean anything to the average user, so maybe the wording could be simplified to just:
For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists, format the items as a normal bulleted list; don't use other list templates or <br/>. For example:
The less complicated it is, the easier it will be to follow. Would that work?
Ojorojo (talk) 15:08, 6 January 2022 (UTC)
Ojorojo, agreed, very much simplified. Can the same wording be adapted to Template:Infobox song then? AshMusique (talk) 15:42, 6 January 2022 (UTC)
OK, based on this discussion, I'll be bold and add this wording to both infobox documentation pages and adapt it for the class=plainlist explanations that precede them. —Ojorojo (talk) 15:54, 6 January 2022 (UTC)
Thank you. AshMusique (talk) 17:19, 6 January 2022 (UTC)
Thanks for bringing it up. I've noticed several edits that changed bulleted lists to {{hlist}}. Maybe this will help. —Ojorojo (talk) 17:29, 6 January 2022 (UTC)
We should also be careful to remind people not to change shorter lists per MOS:STYLERET as well. Not everything needs to be bulleted. Walter Görlitz (talk) 06:14, 11 January 2022 (UTC)

Border

Hello. I propose to apply borders to song and album covers by default just as Template:flag or the likes. It will provide more consistency and harmony to articles. And thus remove the parameter "border". Any thoughts? 7szz (talk) 07:40, 5 February 2022 (UTC)

(I think this is also applied to flags in Template:Infobox country.) 7szz (talk) 15:56, 5 February 2022 (UTC)

I'd like to see this. Not just a single-pixel border (which is barely visible anyway due to its grey colour), but a drop shadow so that the artwork stands out more. Unsure if that would go against WP:ACCESS, though. Mac Dreamstate (talk) 10:25, 5 February 2022 (UTC)
Having either of those would make this infobox different than almost every one I have seen on Wikipedia. It might merit a larger discussion.
Also, one of the differences with the flag templates and the album artwork templates is that the latter is actually linked and uses a border around the image to identify the link. The only way having yet another border would make any sense is if the existing link border was removed. Walter Görlitz (talk) 06:06, 12 February 2022 (UTC)
I take that back. That seems to be a JavaScript extension that I have. I tried it in a browser where I was not logged in and it did not show. Walter Görlitz (talk) 06:14, 12 February 2022 (UTC)

Tone of the hidden notes in the template

The guidelines at WP:HIDDEN recommend using request-like language rather than command-like language when putting in hidden notes. This template has several command-like hidden notes in it (e.g., "Do not use for English albums by English-speaking artists"). It'd be nice to see these changed so that they are less severe in tone (e.g., for the example above, "This parameter is not needed for English albums by English-speaking artists"). Chubbles (talk) 23:05, 20 February 2022 (UTC)

I agree that a language change would be best to bring it in line with what WP:HIDDEN recommends, and I think it is a pretty simple fix to move it from "Do not add unsourced recording dates/years" to something like "Please only add sourced recording dates/years" and "Do not add unsourced genres" to "Please only add sourced genres". Nangears (talk) 04:46, 25 February 2022 (UTC)
Agreed. After becoming aware of WP:HIDDEN a while back, I started changing "Do not..." to "please source..." and asking several users to stop with the commands in hidden notes. Some scream, like "Don't you DARE change this! We had a discussion on the talk page SO GO THERE! You will be INSTANTLY REVERTED if you change this". I understand that users constantly changing elements of pages that have been discussed is annoying, but some are genuinely unaware and need to be pointed in the right direction. If they're made aware and still change it, they can be warned, may be blocked, and/or the page protected. Still no real need for this tone on articles. Ss112 06:20, 22 March 2022 (UTC)
The usage in the documentation isn't really a "hidden note" as it's visible and used as a form of short documentation to the longer documentation. So the note at the recorded parameter is part of Template:Infobox album#recorded. Making it longer or adding unnecessary words that make it longer is unhelpful. In general documentation should tell a user how to use it and what shouldn't be used in it. It shouldn't ask for their permission or even ask nicely. Gonnym (talk) 06:30, 22 March 2022 (UTC)
@Gonnym: I think the general point was more about the language users use in hidden notes on album articles—at least mine was. Obviously not on the documentation here as we can see it, but on the articles this template is being copied to the notes definitely qualify as hidden. Changing the wording to "please source genres" is not making it longer or adding "unnecessary words"—it's shortening it and as an example being copied, would bring it in line with HIDDEN. I don't believe saying "please" is asking for users' "permission" (I don't think that was the right word to use—"please" is not always used in scenarios to ask permission to do something), it's asking users to only add sourced information instead of ordering them not to unsourced information (bringing it in line with a guideline that applies to all of Wikipedia). If "please" is such a point of contention, "genres/recording dates should be sourced" could suffice. Either way, I'm just clarifying—I don't have a vested interest in whether this is changed or not (I don't know about @Chubbles and Nangears: perhaps they care more). Maybe in the end it's outside the scope of template documentation to concern itself with whether users add unsourced genres to it or not? It certainly can't stop them from doing so whatever the note says, and in my experience if users want to add something unsourced, they'll go ahead and get rid of the note and change it anyway, whether it's "do not", "please", or even "should". Ss112 00:38, 8 April 2022 (UTC)

Template-protected edit request on 11 April 2022

Seems like parameter "release" is not needed and is also not used anywhere on wiki: https://bambots.brucemyers.com/TemplateParam.php?wiki=enwiki&template=Infobox+album . So it should probably be removed? Solidest (talk) 17:32, 11 April 2022 (UTC)

@Solidest: there isn't a parameter called release but there is field called released which is a key/critical field. Are you sure that is what you mean or have I misunderstood? ≫ Lil-Unique1 -{ Talk }- 17:56, 11 April 2022 (UTC)
TemplateData suggests to add "release", so it has to be there. I guess it's used as an AKA in module part: {{#if:{{#invoke:string|match|{{{released|{{{release|}}}}}}|%d%d%d%d|ignore_errors = true}}|{{#invoke:string|match|{{{released|{{{release|}}}}}}. Solidest (talk) 18:00, 11 April 2022 (UTC)
 DoneJonesey95 (talk) 18:32, 11 April 2022 (UTC)

More contrasting shades

Following the manual of style for accessibility, I would like to propose a change of colors in this template to meet at least the WCAG AA contrast level with the blue links that the template itself generates. Also, I propose alternative colors that meet the AAA level, which are much lighter. For the lightest shades (types single, soundtrack and video), a change to AAA seems small and is perhaps worth considering.

Type code Current color Proposed color meeting a specific WCAG level on blue links
AA AAA
Greatest, remix box, compilation, mixtape
Link, text
Link, text
Link, text
EP, single album
Link, text
Link, text
Link, text
Live
Link, text
No change needed
Link, text
Studio, demo
Link, text
Link, text
Video
Link, text
Link, text
Soundtrack, film, cast
Link, text
Link, text
Single
Link, text
Link, text
Song
Link, text
No change needed
Other
Link, text
Link, text[1]

--Fernando Trebien (talk) 21:03, 20 January 2022 (UTC)

For AAA cretification, studio, demo is too similar to video. Any suggestions for a change? Walter Görlitz (talk) 07:31, 31 January 2022 (UTC)
What about Lavender Blush, Beige or Mint Cream for the video? I'd rather change video than studio album as I reckon this would cause less issues across the community - there will be many people who may balk at the sudden colour change as they probably won't be aware of the reasonings behind it, and there are probably more studio/demo album articles than video ones. ≫ Lil-Unique1 -{ Talk }- 09:41, 31 January 2022 (UTC)
I'd rather make studio the colour that video has. Take your best shot. Walter Görlitz (talk) 05:56, 5 February 2022 (UTC)

@Walter Görlitz and Lil-unique1: LavenderBlush is very similar to the AAA color proposed for Other, MintCream is almost indistinguishable from white on my screen, but Beige seems to work. So if we use it for Video and use the previously proposed color for Video for Studio, demo, the updated proposal would look like this:

Type code Current color Proposed color (WCAG AAA)
Greatest, remix box, compilation, mixtape
Link, text
Link, text
EP, single album
Link, text
Link, text
Live
Link, text
Link, text
Studio, demo
Link, text
Link, text
Video
Link, text
Link, text
Soundtrack, film, cast
Link, text
Link, text
Single
Link, text
Link, text
Song
Link, text
No change needed
Other
Link, text
Link, text[1]

What do you think? --Fernando Trebien (talk) 23:01, 16 February 2022 (UTC)

I'd support that personally if it's compliant. ≫ Lil-Unique1 -{ Talk }- 23:03, 16 February 2022 (UTC)

References

  1. ^ a b Actually no change needed, but proposed to avoid a shade too close to live.
What if the colour for single were closer to the colour for song. It is currently very close to video. Walter Görlitz (talk) 05:01, 22 February 2022 (UTC)
@Walter Görlitz: I'm here for accessibility, so I'm neutral on this change. Single and Song are very common values, while Video is not so common, so I think it would be best to try that change in a next step to avoid confusion if questions arise about how accessibility is being achieved. --Fernando Trebien (talk) 14:02, 2 March 2022 (UTC)
I take your accessibility advice, as I am no expert. Walter Görlitz (talk) 17:55, 2 March 2022 (UTC)
Sorry, but I'm not a fan of new, in some cases more acidic colors. And even less a fan of a drastic change of colors to new ones, as in the case of "video" and "other" (similar pink color was used 10 years ago for tribute and cover albums that were merged into studio). But I would generally support changing the colors to as similar pastel shades as possible. First of all we should just change the shades of studio and EP colors to more neutral ones, because the current colors don't even pass AA compliance with the links. And thinking about AAA compliance is something long-term (I suppose it's more likely that we'll remove the colors altogether). Solidest (talk) 14:50, 13 April 2022 (UTC)

Template-protected edit request on 11 April 2022 (2)

The parameters last_album, this_album, next_album were marked as deprecated for almost 5 years. Now they are completely removed across the wiki by replacing with prev_title, prev_year, year, next_title, next_year. So they can be removed from the code now with removal of unneeded modules. Solidest (talk) 23:57, 11 April 2022 (UTC)

P.S. Btw, Category:Pages using infobox album with empty type parameter part should be edited to be filled with main namespace articles only. As it currently filled with userpages/sandboxes/etc by 95%. Solidest (talk) 00:04, 12 April 2022 (UTC)

 Done Done, after carefully and surgically removing a bunch of convoluted, nested text in the sandbox and checking the results on the testcases page. – Jonesey95 (talk) 14:24, 14 April 2022 (UTC)

Template:Infobox album/genre/Sol-Angel and the Hadley St. Dreams and the infobox

Template:Infobox album/genre/Sol-Angel and the Hadley St. Dreams is up for deletion at WP:TFD. Looking at the history of this infobox I see that User:Samsara added the functionality in March 2019 but I can't see any disscussion about it in the archives here. Seeing as this is the only template using this style, was this addition with consensus? Gonnym (talk) 08:43, 15 April 2022 (UTC)

Template-protected edit request on 27 April 2022

Could you make it so that if the released field date is set in the future, that it automatically changes the label to "Set release date", "Set to release" or similar? Alternatively, you could make another field for future release date if the conditional formatting is difficult because of different notations being used (which I'd understand fully). The reason for my request is because I sometimes see infoboxes in which the release date is in the future yet the label just says "Released", creating a grammatical incongruence where the label suggests it is released but the release date hasn't come to pass yet. Hope it's clear. Thanks in advance for reading my message and considering its implementation. Cheers. ★Ama TALK CONTRIBS 18:35, 27 April 2022 (UTC)

You should really gain consensus before making requests like this. "Release date" makes sense and that is what it has been changed to. Walter Görlitz (talk) 19:57, 27 April 2022 (UTC)
I was under the impression that you didn't need consensus for uncontroversial requests. I deemed my request uncontroversial seeing as I wouldn't know who'd ever object to such an obvious thing but sure I'll open a post and get people to agree first next time. Also, I'm sorry if I sound salty, it's not because of you. ★Ama TALK CONTRIBS 20:01, 27 April 2022 (UTC)
(edit conflict) x2
 Done: the label has been changed to "Release date", which covers past and future release dates. P.I. Ellsworth - ed. put'r there 20:02, 27 April 2022 (UTC)
Thank you! ★Ama TALK CONTRIBS 20:03, 27 April 2022 (UTC)
my pleasure! Paine  20:14, 27 April 2022 (UTC)

I must admit I'm very lost, and have come here for clarification. Tonight I have come across 'Release date' in articles like Paix and Renaissance, but others remain 'Released'. All that I can say is that I would be strongly against 'Release date' being enforced on articles over 'released' – it creates an extra line of blank space that is totally unnecessary and ugly. Moreover, whilst 'released' can be seen as a past-tense term I don't think that's really an issue for upcoming albums, as it can similarly be read as 'x album [is] released X/Y/2022', in the same way a press release might say an album "is released" rather than "will be released". --TangoTizerWolfstone (talk) 01:47, 28 April 2022 (UTC)

@TangoTizerWolfstone: Hm yes, I admit I did not foresee the repercussions of creating additional lines with my request, and I expect that the template editor didn't either. Perhaps we could reconsider the styling or wording but I do maintain my original point that it looks off for an album or song that's not yet released to say 'Released'. If more people were to disagree with me I'd absolutely be in favor of having a discussion about it however, as I previously said, it was never my intention to bypass consensus haha. Last but not least, the reason some will still say 'Released' instead of 'Release date' might be that on the articles that still have the 'Released' notation, they substituted the template, causing new edits to the template to not appear there. ★Ama TALK CONTRIBS 02:01, 28 April 2022 (UTC)
@Paine Ellsworth: I agree with @TangoTizerWolfstone:. Please revert this. Large-scale changes like this require consensus. Every album is now forced to have "release date", whereas the requesting editor says they wanted it to only say "release date" for future releases. Ss112 02:01, 28 April 2022 (UTC)
Fair, this was indeed not my initial request, but to cut Paine Ellsworth some slack, I didn't expect the change to be controversial (at least not my initial request for only future albums) and as such didn't gather consensus beforehand. That's on me though so not on the template editor. ★Ama TALK CONTRIBS 02:03, 28 April 2022 (UTC)
@Paine Ellsworth: There are other concerns besides the extra line, so adding a non-breaking space and forcing other text in the infobox to be pushed over to compensate for the wider parameter title isn't a fix. Please revert your edits outright until and unless they have consensus. We've now had two editors objecting, and any undiscussed changes that are objected to should be reverted on such a widely used template. Ss112 02:19, 28 April 2022 (UTC)
arrow Reverted pending consensus. P.I. Ellsworth - ed. put'r there 03:14, 28 April 2022 (UTC)
@Paine Ellsworth: I'd like to retract my request on grounds of WP:NOCON, sorry for any inconvenience caused to you or other editors as a result of my speedy request, I sincerely did not foresee the ramifications of such a change I initially deemed minor. ★Ama TALK CONTRIBS 12:05, 28 April 2022 (UTC)
No worries, ★Ama, it's happened to all of us; not always easy to know what is and is not controversial. You'll develop a "feel" for that as you continue to edit this awesome reference work. On the other hand, had I thought this edit to be controversial, I would have denied it and asked that you seek consensus in the first place. So it's on me as well. Thank you for your edits, and stay healthy! P.I. Ellsworth - ed. put'r there 17:19, 28 April 2022 (UTC)