Jump to content

Template talk:Infobox album/Archive 11

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 9Archive 10Archive 11Archive 12Archive 13

Harmonization with other music templates

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  • Closing discussion The consensus is Support for harmonizing the templates. The guideline already used in Template:Infobox musical artist will be added to the relevant music templates:

[Entries in field] should be separated by using commas, {{flatlist}} or {{hlist}}.[1] [1] For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists the use of {{flatlist}} or {{hlist}} is preferred as they offer a benefit to users of screen readers. Vertical lists should always be implemented by {{plainlist}} or {{ubl}} and never by <br /> tags for reasons of accessibility.

Whether commas should be eliminated altogether or class = be added is not part of this proposal and needs to be discussed separately. —Ojorojo (talk) 14:34, 8 August 2016 (UTC)

Proposal

Several music infobox templates have the same parameters, but different explanations/guidelines. For example, "Genre":

These should be harmonized, along with other common parameters including "Label", "Producer", "Format", and "Writer". (Infoboxes single and song specify {{Plainlist}} for "Recorded", probably because they don't have separate date and "Venue" and "Studio" parameters; these can be changed when added). The standard parameter guideline with explanatory footnote used in Infobox musical artist should cover all:

[Entries in field] should be separated by using commas, {{flatlist}} or {{hlist}}.[1] [1] For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists the use of {{flatlist}} or {{hlist}} is preferred as they offer a benefit to users of screen readers. Vertical lists should always be implemented by {{plainlist}} or {{ubl}} and never by <br /> tags for reasons of accessibility.

Are there any objections to adding this? —Ojorojo (talk) 15:57, 26 July 2016 (UTC)

  • Oppose Have those other templates harmonize with this one as this is correct. Walter Görlitz (talk) 06:33, 27 July 2016 (UTC)
    • You do realize that Producer = allows for the optional use of {{flatlist}}, right? This was added over three years ago [1] and is consistent with MOS:HLIST. This option is used in many album GAs, including for Genre = and Label =; adding it here and harmonizing with other infobox guidelines just adopts accepted practice. One's personal preference does not make it "correct". —Ojorojo (talk) 14:16, 28 July 2016 (UTC)
    • No, it is not correct, you know full well that consensus on this has gone against you in other discussions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:11, 2 August 2016 (UTC)
      • Sorry Andy. The consensus is simply wrong. No proof that all screen readers make use of this has ever been provided. So I don't care what lies have been told in other discussions and what errors in logic have been made, the consensus here is clear. Walter Görlitz (talk) 05:23, 3 August 2016 (UTC)
      • And for the record, I comply with the misguided consensus, I can explain it as is evidenced below, but recognize that it has no empirical support and I will continue to disagree with its implementation at every turn until either I am provided with empirical evidence, until I'm dead in my grave, or all those who support it are. Walter Görlitz (talk) 05:28, 3 August 2016 (UTC)
        • It's impossible to supply empirical evidence to someone who doesn't believe the evidence presented. Nevertheless, This 2015 WebAIM survey shows the screen readers commonly used. Both Graham87 and I have told you how JAWS normally behaves when reading a list and you can read for yourself about its ability to navigate through a list item-by-item. NVDA is free and you can check for yourself or read how to navigate through a list. VoiceOver doesn't work so simply as you have to put it into 'word' mode during list navigation. Windows-Eyes uses 'S' and 'Shift-S' to go back and forth between items in a list. I'm sorry I can't provide proof that all screen readers make use of lists, but I can say with certainty that the bulk of screen readers in common use enjoy some benefit from list markup. --RexxS (talk) 14:18, 3 August 2016 (UTC)
          • Thanks. It's not impossible. I am simply asking for a survey of screen readers that shows whether or not the formatting makes a different. So you can show me all the lists of most popular tools, but all I have ever seen is a single, anecdotal report that it works better for one user who happens to use JAWS. Walter Görlitz (talk) 12:32, 4 August 2016 (UTC)
            • Thank you, Walter, that's clearer to me now. I agree I haven't found a survey of screen reader users that discusses the exact question of whether having lists marked up in list format makes a difference to the listener. What I can show you is merely that the list formatting allows all the major screen readers to navigate directly to a list (if they wish to revisit the information), and that it allows all the major screen readers to move forwards and backwards through a list (perhaps to rehearse earlier items in a longer list). What Graham87 has done is to relate that one user of a screen reader finds it improves the experience for him, not in a dramatic way, but as one of many small improvements that semantic markup makes to his everyday use of screen readers. I've no reason to suspect that Graham's experience is atypical, so I draw the conclusion that having extra abilities to find and navigate though lists is an improvement for most screen reader users. Conversely, what I've yet to see is the smallest hint of evidence that semantic markup worsens that experience for the visually impaired or even that it has no effect at all. --RexxS (talk) 17:02, 4 August 2016 (UTC)
  • Support {{flatlist}} in studio, genre and producer fields. Mac Dreamstate (talk) 14:30, 28 July 2016 (UTC)
  • Support, but also convert appropriate parameters to hlist and plainlist classes — then we won't have to bother with any templates. This has already been done (with hlist) at {{Infobox music genre}} and {{Infobox song}}. Commas can still be a valid option.--Ilovetopaint (talk) 09:48, 30 July 2016 (UTC)
  • Oppose Not a fan of "flatlists"/"bulleted lists"/whatever, believe they look grammatically foreign to most readers (as opposed to a comma), and their benefits have yet to be explained to me. Dan56 (talk) 16:14, 30 July 2016 (UTC)
    • The benefits are that they insert invisible formatting that can be used to programmatically parse the information into chunks. This makes it easier to digest for "partners" of Wikipedia to format data grabs into correct chunks. This also makes it easier for blind users who utilize screen readers—and I'm still waiting for that list of screen readers and their market penetration to confirm this—so that the items can be separated correctly. I'm not a fan of them either, but I understand how they may benefit some constituents. Walter Görlitz (talk) 19:43, 30 July 2016 (UTC)
      • That's too technical/unclear to me; "invisible formatting", "programmatically parse", "data grabs ... chunks"... I'm not even sure what screen readers are lol. Dan56 (talk) 04:51, 31 July 2016 (UTC)
        • Support A screen reader is a type of software that reads the written content of your computer screen aloud or forwards it to a braille device, so if you're blind you don't have to read it yourself but can still. Apart from the technical benefits we should have a standardised/harmonised output among related types of infoxes. De728631 (talk) 19:56, 31 July 2016 (UTC)
          • Please clarify - So if commas are used instead, the screen reader will misread the listed items? Dan56 (talk) 02:35, 2 August 2016 (UTC)
            • So programmatically parse means that a software tool can more easily interpret the information. If you were to perform an Internet search for A Night at the Opera, The Joshua Tree or The Woman in Me, you would see a summary on the right-hand side of the search. A Google employee did not spend time reading the article, a Google employee wrote a program to "read" the article and extract salient information out of the article. That information is placed into a database for quick retrieval.
            • Using the formatting provided by these lists makes it easier to correctly parse chunks of information by any program or even by a human. If the value had a comma in it, and the list were comma separated, it could be confusion. If a big, ugly bullet was placed so you could see it, the confusion would be eliminated. The programs don't see the bullets. They see special computer code. It's still not clear that all screen readers use the special HTML formatting though, but one frequent editor who uses a screen reader assures us that his does. Walter Görlitz (talk) 05:02, 2 August 2016 (UTC)
              • Interesting, @Walter Görlitz:, but then tell me, why aren't bulleted lists used elsewhere, such as in the rest of the article, in the body, the prose, etc.? Why are editors only using them in infoboxes, track listings and other templated tables? Shouldn't an article be consistent in style and use one way of separating listed items wherever items are listed ? Dan56 (talk) 22:58, 2 August 2016 (UTC)
                • I'm not Walter, but perhaps I can cast some light on the issue. Vertical bulleted lists are used commonly in article text (using * and # wikimarkup), which is suitable for longer items; but when each list item is short, the convention for prose is to display them inline with commas to separate them, as we all are used to. That's not too bad for a screen reader, but not as good as it could be. Because we are not writing a paper encyclopedia, we can now take advantage of the technology to introduce hidden markup that enhances the text. A horizontal list is an obvious example and hlist was originally conceived to improve the way that the navigational templates at the bottom of many articles were presented. They used a mid-dot (·) as a separator, but it was soon realised that screen readers read it as a single piece of text and vocalised the dots: "item one, dot, item two, dot, etc." and so we found a way of turning the horizontal list into a real list, analogous to the vertical list. In that sense it's more consistent than text with commas in it. It's understandable that some sighted readers don't like the look of the dots used in hlist (although screen readers don't see them, just as they don't see the bullets in a vertical list), so I'd suggest that you might want to lobby Mediawiki talk:Common.css to introduce a new class for horizontal lists that used a comma instead of the dot. There's an example of a class called "cslist" that does just that in my User:RexxS/common.css. --RexxS (talk) 23:55, 2 August 2016 (UTC)
        • Comment [Diary of a fence-sitter]. I've been umming and ahing about this for ages. I'm certainly pro the idea of a harmonised approach to Song, Single and Album infoboxes (not just on the issue of list formatting, but also re inclusion of the certification field and anything else we've been discussing in the thread above.) But I don't like the look of the bullets at all, either, and I think there's a tendency for editors to assume that because someone's come up with a template, it simply has to be used. If we can be sure that {{flatlist}} and {{hlist}} offer a genuine benefit to visually impaired/blind readers, though, I'll swallow my natural aversion and support this. JG66 (talk) 06:42, 2 August 2016 (UTC)
  • Comment Wikipedia:Manual of Style/Accessibility is a guideline "primarily intended to assist those with disabilities". As part of its stated attempt to comply with access standards, it includes under "Horizontal lists": "For lists running across the page, and in single rows in infoboxes and other tables, the templates {{flatlist}} and {{hlist}} ("h[orizontal]list") are available to improve accessibility" (emphasis added). Some editors here question whether this provides the intended benefit (at the expense of a normal appearance). It would be helpful to hear from those more familiar with accessibility issues, so a note has been added on the MOS:ACCESS and WP:WPACCESS talk pages about this discussion. —Ojorojo (talk) 13:15, 2 August 2016 (UTC)
  • Comment – It's definitely possible to make an accessible list and use comma as separator instead of the bullets (personally I don't have a problem with them, but not everyone likes them). See here for a demonstration. nyuszika7h (talk) 13:53, 2 August 2016 (UTC)
  • Support the use of list templates. We've had past clarification from users of assistive software that this is beneficial to them; and it confirms with ISO standards for web accessibility (not to mention the HTML standard). We don't need to trouble the same people to confirm this for every template affected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:11, 2 August 2016 (UTC)
  • Support the use of list markup, for accessibility reasons. Whether that list is formatted using {{flatlist}} {{plainlist}} {{hlist}} etc. is largely presentational, the important thing is that lists should be semantically marked up as such. --Redrose64 (talk) 14:56, 2 August 2016 (UTC)
  • Support: Where a horizontal list has only two or three items, I don't believe a screen reader user will be too bothered that the whole list gets read out in one go. For a large list, the ability to pause after each item and even go back to the previous item with a single keystroke starts to become a useful convenience for those using the common screen readers. There is also the benefit of disambiguating between two possible readings of Producer: John Smith, Boyband, which may actually be two items, John Smith and Boyband, or which may be a single item, John Smith (i.e. the John Smith who is a member of Boyband). Semanitic markup such as hlist would indicate whether there were two items or just one. --RexxS (talk) 20:30, 2 August 2016 (UTC)
  • Possible compromise Since some editors prefer commas to dots and the benefit of list templates for two or three items is small, maybe the parameter guidance could be standardized as follows:

For two or three [field entries], use commas for separation. For four or more, use {{flatlist}} or {{hlist}}.[1] [1] For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists the use of {{flatlist}} or {{hlist}} is preferred as they offer a benefit to users of screen readers. Vertical lists should always be implemented by {{plainlist}} or {{ubl}} and never by <br /> tags for reasons of accessibility.

The majority of infobox fields would use commas (most have 3 or less items), but accessibility would still be provided for longer lists. This appears to work with "class = hlist" already used in Infobox song. Thoughts? —Ojorojo (talk) 15:10, 3 August 2016 (UTC)
I'd prefer to give editors the option - as suggested by the original poster - of either using commas or {{hlist}}, etc. in short lists. Some editors may prefer to use the same format for short lists as for longer lists and see it as a consistency issue; otherwise an infobox might end up with different formats in different fields. Does it really improve an article to have a list of three labels using commas right next to a list of four producers using {{hlist}}? --RexxS (talk) 16:30, 3 August 2016 (UTC)
I've seen it mixed, but yes, it may look odd to some. —Ojorojo (talk) 18:24, 3 August 2016 (UTC)
It needs to be clarified whether commas will work with class =, since some want the option. —Ojorojo (talk) 18:41, 5 August 2016 (UTC)
  • Agree with middots We need to use ISO standardized punctuation for list items like this. Mid-sentence, a comma is appropriate but in list-readable formats like this, use a middot (with or without a template to generate it). —Justin (koavf)❤T☮C☺M☯ 18:20, 5 August 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Consistency with recording dates?

Should middots also be used in place of commas that are in Americanized recording dates ([month] [day] [comma] [year])? Think of cases where punctuation and prepositions would benefit the layout in infobox parameters like "Recorded" and "Studio". September 1, 2, and 5, 1971; October 5, 1973, for example. Dan56 (talk) 20:16, 7 August 2016 (UTC)

Studio parameter, take #2

I would like clarification on the format of this field, and for it to be included in the MOS for this template. Since 2008, albeit before the separate Recorded field was introduced, I have used this format:

1 January – 8 April 2014 at [Studio name] in New York City

However, recently I've been seeing something like this in the Studio field:

[Studio name], Toronto, Ontario

... or even <small> text being used for the studio. What's the deal there, and all the commas? To me it looks very awkward if the [Studio], [City], [State] format is used, rather than [Studio] in [City], [State]. Mac Dreamstate (talk) 00:55, 12 February 2016 (UTC)

Date is to go in recorded parameter. Studio should go in the studio parameter.
I have seen small setting off the city, state/province.
I have been removing if only the city, state/province is listed without a studio name. Walter Görlitz (talk) 06:19, 12 February 2016 (UTC)
Doesn't appear this question was resolved. So should it be

Abbey Road Studios, London

or

Abbey Road Studios in London?

I'm accustomed to seeing it with a comma on most album covers. As for text size, <small> should not be used where the text is already small, such as in infoboxes. Piriczki (talk) 18:31, 15 July 2016 (UTC)
Comment: Piriczki and other interested parties, there has been a discussion at Wikipedia talk:WikiProject Songs#Widespread usage of inaccessible text regarding the use of small text in infoboxes (there seems to be general agreement with you that it should not be used), and a proposal to create a bot to remove it from all affected articles. it has developed into a further discussion about what should be included in infoboxes anyway. Richard3120 (talk) 19:04, 15 July 2016 (UTC)
I've always used [Studio name], [city], [(add state or country if city not well-known)], [date]. Template:Infobox single and Template:Infobox song only have a "Recorded =" field, so it all goes on the same line. The three should be harmonized. —Ojorojo (talk) 23:22, 15 July 2016 (UTC)

You do realize that Studio = is its own parameter now, right? For live recordings, it's Venue =. The only thing that should be in the Recorded = parameter, is the recording dates. Also for the record, there's no guidance around adding the provenance of the studio or venue, so it's fair to add it. Linking should be within the WP:OVERLINK guideline. In other words, if the city is well-known, such as Los Angeles, New York, London, Paris, Berlin, etc., don't even link the city name. Linking the province or state is probably not required per that guideline. If the country is listed, don't link it at all. If three or more entries are to be used, use a list template. Based on the example, I would use

Abbey Road Studios, London

(backlinks broken for example here) and not "in London".

And for the record, if the editors at infobox song want to get with the programme, they could add the parameters, and harmonize their list requirements with this template all at the same time. Walter Görlitz (talk) 03:30, 18 July 2016 (UTC)

The Studio = and Venue = parameters were added a year and a half ago without any notice or discussion.[2] Many recent album GAs don't use them and the change wasn't picked up for the single and song infoboxes. Anyway, this type of information is better discussed in the body of the article and, like the miscellaneous parameters, inclusion in the infobox is probably unnecessary. —Ojorojo (talk) 14:16, 18 July 2016 (UTC)
Relying on feature articles to determine if something is done right is not appropriate. There is no criteria to determine if all infoboxes are used correctly according to the current documentation. This isn't miscellaneous information, the venue of a live recording is usually central to the album. Similarly, the studios can make a difference, particularly prior to the 1990s. I agree that it should be discussed in the article, summarizing it the infobox is not inappropriate. Walter Görlitz (talk) 14:24, 18 July 2016 (UTC)
Hmm, I'd wondered where that Studio parameter suddenly appeared from, a year or two back. I agree (Ojorojo) that it's been introduced incorrectly, without due discussion let alone consensus, but then that same reluctance to involve other editors has governed other changes to album- and song-related templates to various degrees, I've found. I agree with Walter on this issue, though. The studio or live venue is important enough to warrant a separate field in the infobox. In the same way, we wouldn't/don't lump a record label in with the release date – i.e. "Released = 9 June 1978, Rolling Stones Records". JG66 (talk) 02:47, 25 July 2016 (UTC)
  • Support commas — You wouldn't write that a movie was filmed at "Hollywood in California". Also, the studio/venue parameter is essential.--Ilovetopaint (talk) 16:28, 20 July 2016 (UTC)
  • Support commas, but absolutely no {{small|}} text for any infobox parameters. Mac Dreamstate (talk) 17:16, 20 July 2016 (UTC)
  • Support prepositions (i.e. "in", "and"), not just commas - @Ilovetopaint:, of course you wouldn't say "Hollywood in California", but you would say "The Record Plant in Hollywood, California". There shouldn't be a final word on this. Some articles would benefit from listing out several studios located in the same city and using both commas and prepositions such as "in" or "and". How can you not see where that approach might be more conducive? If we used only a comma, readers could mistake the city of a studio as a separate recording location (eg. "Quad Recording Studios, Platinum Sound Studios, New York", the latter possibly suggesting "someplace in New York"). Dan56 (talk) 14:49, 24 July 2016 (UTC)
The studio parameter calls for the name of the studio, not the city in which it was recorded. If an album was recorded at some unknown place in New York, we wouldn't use "Studio = New York City". The city named following the studio is obviously the location of the studio. I don't see anywhere else where prose is necessary or used in an infobox summary. Piriczki (talk) 18:39, 24 July 2016 (UTC)
Perhaps it's obvious if the city is New York. But what if it's "Caribbean Sound Basin" (which is a studio, but you could see how it could be mistaken for another kind of location, right??) Also, the name of a studio constitutes "prose", so what you're really proposing is banning the use of prepositions, which I don't see the harm of using in an infobox. If commas are being used to separate studios in a list, it's confusing when the last item will be the name of a city; you're putting the burden on the reader to make the connection, that it's not another item in the list but the location for all listed studios. I really don't see the harm in allowing what minimal use of prepositions like "in" or "and" would be warranted by this parameter. Studio names, city names, two-letter prepositions... these are all words. Is there some benefit of reader accessibility regarding commas I'm overlooking? Dan56 (talk) 23:20, 24 July 2016 (UTC)
There is no article for "Caribbean Sound Basin" and only five articles mention it. Are we to add "in" to every album infobox based on that? And wouldn't "Studio = Caribbean Sound Basin, Trinidad" suffice in those articles? Piriczki (talk) 23:54, 24 July 2016 (UTC)
You're being awfully reductive. That was just an example. And no one's forcing you or anyone else to add anything you don't want, but if I want to at an article I'm contributing to, I will exercise this preference, whose harm or disadvantage you have yet to explain. Dan56 (talk) 00:49, 25 July 2016 (UTC)
  • Support prepositions. Scratch my earlier vote—I've been swayed back to my original preference of "[Studio] in [City]", or "[Studio] and [Studio] in [Same city]; [Studio] in [Different city]". No need for country or state, and I have some weird aversion (or even revulsion) towards consecutive commas. Mac Dreamstate (talk) 00:57, 25 July 2016 (UTC)
  • Support commas (and other forms of punctuation if necessary). I agree that one-size-fits-all won't work, and anyway it's about presenting details on a specific album (or song) clearly and correctly. I think all infobox text should be concise, abrupt, just like items presented in a table. For albums recorded in several locations, I'd go for something like: Island Studio, London; Musicland Studios, Munich; Sound Recording Studios, Los Angeles – introducing semicolons to clarify the location of each studio, as one would in prose in main text to differentiate between items in a list. If there are a number of studios in the same city, then: Studio Olympic Sound Studios, Island Studio, Morgan Studios (all London); Musicland Studios, Munich; Sound Recording Studios, Los Angeles. I appreciate that the dots in the list templates would probably remove the need for semicolons in those examples, although I'm really not familiar with the templates. JG66 (talk) 03:27, 25 July 2016 (UTC)
Bulleted flatlist for multiple studios/locations sounds good to me. It's already in place for genres. Mac Dreamstate (talk) 13:51, 25 July 2016 (UTC)
JG66 sums it up well and using {{flatlist}} lessens the need for extra punctuation. However, listing all studios where there are several overwhelms other infobox fields. In some cases, "various locations" may present a more balanced appearance. —Ojorojo (talk) 14:55, 25 July 2016 (UTC)
Wow, that's quite a list at Led Zeppelin II (10 studios for 9 songs!). I struggle with the idea of "various locations", though; I've seen it used in one or two articles, but it's (by definition) so noncommittal – I mean, it's non-information. If the length is an issue, I'd be looking to remove the word "Studio" and lessen the load that way. So, taking the examples I gave above, "Studio = Olympic, Island and Morgan studios, London; …" might be the way to go. JG66 (talk) 02:04, 26 July 2016 (UTC)
I'm confused. Template:Infobox album#Genre still says to delineate genres using commas, which I personally would prefer to bullets, since you don't usually see bullets used to separate items in a list. Dan56 (talk) 00:23, 26 July 2016 (UTC)
I think I saw a guideline somewhere else (maybe one of the general MOS'es) which essentially read like it was designed to "override" the usage of that parameter. There's a fair amount of seemingly outdated stuff in there, though; e.g., the part about linking producers doesn't adhere to WP:OVERLINK. Mac Dreamstate (talk) 00:38, 26 July 2016 (UTC)

Back to the original question, is it "Abbey Road Studios, London" or "Abbey Road Studios in London"? I count five editors in favor of commas (Walter Gorlitz, Piriczki, Ilovetopaint, JG66, Ojorojo) and two opposed (MacDreamstate, Dan56). Is there consensus or not? Piriczki (talk) 19:10, 26 July 2016 (UTC)

Why don't you just open an RfC at the article you really want some so-called "consensus" to put our edit war to rest? ([3], [4], [5], [6]) Dan56 (talk) 10:13, 27 July 2016 (UTC)
Piriczki: well yes, the numbers certainly tell that story, but it might be an idea to invite more editors here than the few of us who have weighed in so far. My suggestion would be to open an RfC on this page and post a notification at WP Albums. (I mean, the issue's hardly related to one album article – which is why the discussion started here, surely.) JG66 (talk) 07:13, 2 August 2016 (UTC)
@JG66:, my point was there shouldn't be an overarching rule on this but something that can be decided case-by-case; I don't believe "[studio], [city]" would benefit every single article (or that outlawing the use of prepositions such as "in" or "and" makes sense), and the use of commas conflicts with what's being discussed below. Dan56 (talk) 00:51, 5 August 2016 (UTC)
Jeez, Dan. You're sounding reasonable enough there, but in practice, letting things "be decided case-by-case" just means you'll get your way every time. Simply because you refuse to budge an inch on any issue or let other editors' judgement hold sway! (I'm not trying to have a go at you – it's a very unfortunate situation for everyone, I find.) If consensus was with your view on this, you'd be pushing to have it set in stone in the guidelines/documentation, and policing it rigorously across the encyclopaedia no doubt. Instead, you're wanting things left nice and loose.
On the point of "in": most people here disagree, and it's not unreasonable to think that the purpose of these discussions is to gain consensus on, at least, a general, consistent approach. As the only other respondent as that Parallel Lines RfC, Martin de la Iglesia, implies, doesn't this discussion provide the answer to the RfC there … Even given what you say about "[studio], [city]" not being used for every single article, I struggle with your rationale in that first link above, to Piriczki, that a reader might mistake "Record Plant, New York City" for "Record Plant and somewhere in New York". Because: a) if the latter were the intended meaning, then surely the text would read "Record Plant, undisclosed New York studio" (or something similar); and b) if anyone misreads "Record Plant, New York City" as you say they might, well, they probably won't have a prayer with anything in the article, in which case they'd best quit altogether. You made a similar change in a Who album article I watch: do you really think "in" is needed there when (quite rightly, imo) you've used semicolons to separate the three city locations? I mean, without the "in"s, no one's going to parse that information as "IBC Studios, Pye Studios, De Lane Lea Studios, CBS Studios, Kingsway Studios, somewhere [else] in London; Talentmasters Studios, somewhere [else] in New York; Gold Star Studios, somewhere [else] in Los Angeles". JG66 (talk) 05:08, 5 August 2016 (UTC)

@JG66:, if you cant see how there would be cases where prepositions would be more useful than strictly punctuation, then you clearly lack imagination. Dan56 (talk) 20:15, 7 August 2016 (UTC)

Consistency with recording dates?

@Nyuszika7h:, @Piriczki:, @Walter Görlitz:, @Ojorojo:, should prepositions also be avoided when listing several recording dates? Think of cases where punctuation and prepositions would benefit the layout in infobox parameters like "Recorded": September 1, 2, and 5, 1971 at Electric Lady Studios in New York; October 5, 1973, and January 1, 1974, at the Record Plant in Los Angeles (for example). This isn't uncommon, and it's ridiculous to limit editors to punctuation. Consider Big Fun (Miles Davis album): "Columbia Studios B and E, New York" (emphasis added). Should "and" be removed and the line be rewritten as "Columbia Studio B, Columbia Studio E, New York"? Furthermore, New York isn't a studio, yet it's being listed like one. This effort to ban prepositions strikes me as misguided minimalism; they can only help. Dan56 (talk) 20:23, 7 August 2016 (UTC)

Doesn't anyone think seeing three or four studios listed consecutively, and then the name of a major city, would throw readers off a bit? The preposition "in" would only make it less jarring. Dan56 (talk) 21:53, 7 August 2016 (UTC)
Prepositions should not be used at all in relation to a recording studio. The studio should be listed, with the city next to each recording studio.
-- Walter Görlitz (talk) 22:26, 7 August 2016 (UTC)
You completely sidestepped what I had written. Dan56 (talk) 02:27, 8 August 2016 (UTC)
No I didn't. I said that my opinion is that they should not be used at all. Ever. Nothing you can say will change my mind that a preposition will make summarizing studios in an infobox necessary. If something is needed to make it less jarring in the way of additional prose, it should be in the prose section not the infobox. Walter Görlitz (talk) 14:15, 11 August 2016 (UTC)
When you don't engage someone's argument and just spout declamatory statements about what should be, then you sidestep what I wrote. Furthermore, I don't see anything at MOS:IBOX about infoboxes needing to be devoid of prepositions. Dan56 (talk) 02:39, 27 August 2016 (UTC)

Why is <small> formatting allowed

It adds nothing to the presentation and many times full size is best. I had thought that <small> was deprecated – especially in infoboxes. Jodosma (talk) 18:58, 16 September 2016 (UTC)

@Jodosma: Agreed--it is bad for accessibility. —Justin (koavf)❤T☮C☺M☯ 20:19, 16 September 2016 (UTC)
(edit conflict) I can't seem to find any parameter in this infobox that comes in very small script by default so I suppose you are referring to this edit? In this case I would say it does not add to the presentation and normal font size can be used. But there may be cases with long parameter entries where the font size would cause additional line breaks and make the list look cluttered, so I think there is a reason why <small><small/> is not completely ruled out. And I didn't know that it was deprecated either. De728631 (talk) 20:32, 16 September 2016 (UTC)
It's against MOS:FONTSIZE as infoboxes already have smaller font than body text by default, and using <small> will make it fall below 85%. nyuszika7h (talk) 22:38, 16 September 2016 (UTC)
<small><small/> is completely ruled out, in all circumstances: it will put the page in Category:Pages using invalid self-closed HTML tags; the correct form is <small>...</small>. As for deprecation, the HTML5 spec for the small element says thet it "represents side comments such as small print" and "Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements." The implication is that the element has a particular semantic meaning, and should not be used merely for reducing font size. --Redrose64 (talk) 08:00, 17 September 2016 (UTC)

I think that the code under "Advanced Usage" is defective

I think that the code shown under Template:Infobox_album#Advanced_usage is defective, as evidenced by previous revisions of Honor Is Dead. --Jax 0677 (talk) 18:26, 1 October 2016 (UTC)

That's because that part of the documentation is using &nbsp; instead of spaces. When you copy and paste it into an article, the non-breaking spaces become part of the parameter names, which are then not recognised. I'll amend the documentation so that you can copy-pasta it in future. It won't be so pretty, but at least it will be usable. --RexxS (talk) 20:44, 1 October 2016 (UTC)

Album Cover Maintenance Category

Every album has album cover artwork. Because of this, I'm proposing that someone implement the code to create a maintenance category of Category:Albums with missing cover, similar to Category:Books with missing cover. This would make it much easier to process articles that have a missing album cover in the infobox. Thanks, TheKaphox T 19:19, 10 November 2016 (UTC)

@TheKaphox: Category:Album infoboxes lacking a cover. —Justin (koavf)❤T☮C☺M☯ 02:41, 11 November 2016 (UTC)
@Koavf: Didn't see this! Thank you! TheKaphox T 07:48, 11 November 2016 (UTC)

Why no field for Mastering?

I wanted to put on Chicago 17 the credit for mastering for George Marino.[7] I don't see a way to do this using the template as it stands-any ideas? DadaNeem (talk) 19:48, 12 November 2016 (UTC)

@DadaNeem: This is probably because mastering is generally obscure. Infoboxes are usually reserved for the most common and simple facts and in the case of albums, it is a lot more likely for someone to talk about when an album was released or what genre it is than who mastered it. If you want to propose adding a field for mastering, you are free to but I think that it will probably not get much support. Personally, I'm indifferent. —Justin (koavf)❤T☮C☺M☯ 20:54, 12 November 2016 (UTC)
Not sure I've seen awards for mastering an album before either. Grammy awards have only rarely noticed mastering, but usually for mastering houses, and they amount to achievement awards, not annual awards. Walter Görlitz (talk) 04:34, 13 November 2016 (UTC)
Mastering is not a key fact that is discussed in WP album articles that I've read, therefore it doesn't belong in an infobox (see WP:INFOBOXPURPOSE). Of course, this info (along with engineers, mixers, etc.) may be mentioned in the body of the article if there is a WP:RELIABLESOURCE. Reading this info off of an image of the album itself at Discogs is OK, but the accompanying text is user-generated and not considered reliable. —Ojorojo (talk) 17:12, 13 November 2016 (UTC)

Durations

For album durations that are over an hour, is it preferred to format the length as 1:10:00 or as 70:00? TheKaphox T 21:58, 17 November 2016 (UTC)

@TheKaphox: 70:00 and with the {{duration}} template. —Justin (koavf)❤T☮C☺M☯ 22:15, 17 November 2016 (UTC)

Novel use with Template:Extra chronology

I want to make a one-off album by a solo artist part of his band's chronology but not display the solo artist's "chronology" (since he doesn't have one apart from the one-off). The specific case is Sly Stone, who did the album High on You under his own name but did all his other work (much of it solo in all but name) as Sly & the Family Stone. Is it OK to do this? Or should I just settle for displaying both the solo chronology (such as it it) and the group one? --Middle 8 (t • c | privacy • COI) 16:17, 30 November 2016 (UTC) (italicize title 20:17, 5 December 2016 (UTC))

@Middle 8: I totally understand what you are going for here but this inevitably leads down a path of many chronologies for individual members of musical groups (I recall one for Eric Clapton leading across several albums by several groups--imagine what they would look like if they all compounded with Jimmy Page, Ginger Baker, etc.) It's probably wise to avoid it. —Justin (koavf)❤T☮C☺M☯ 20:18, 30 November 2016 (UTC)
Thanks Justin/koavf! Agree that it would be nuts to allow ourselves to slip that far down such a slope, but here there's no slope: my calling the album a "one-off" was misleading because it's the same artist in all but name (see the lede of High on You). I re-did my edit a cleaner way, here -- simply by adding the "Chronology" field to the template -- following the example of Liza Jane (David Bowie song), which is credited to Davie Jones with the King Bees but (quite properly imo) displays the chronology as "David Bowie singles chronology". It does bug me when the name of the artist changes across a chronology of albums that are for all intents and purposes by the same artist, but maybe I'm being too nitpicky. Cheers, Middle 8 (t • c | privacy • COI) 20:14, 5 December 2016 (UTC)

Italic title parameters

Can the parameters of {{italic title}} be passed through so we can use those in this template if needed? Specifically {{{all}}} so we can specify the text in parentheses to be italicized as well. Maybe something like {{italic title|all={{ifeq:{{{italic title}}}|all|yes}} }}. {{{String}}} and {{{1}}} (for noerror) should probably be likewise added. This would help with people trying to override the displayed title by other ways and generate errors. Voxii (talk) 19:01, 9 December 2016 (UTC)

The top of the documentation displays {{Auto italic title}}. Users can say |Italic title=no and make their own italics with {{italic title|all=yes}} or whatever they want. There are several infoboxes using {{italic title}} and I don't think a parameter name making no sense in an infobox context should be duplicated. Most users paying enough attention to the documentation to learn about |all=yes would also learn about |Italic title=no. PrimeHunter (talk) 19:26, 9 December 2016 (UTC)
That is entirely confusing. The template takes |Italic title=no for no italics, why not simply |Italic title=all for all italics (including parentheses)? —sroc 💬 11:43, 15 December 2016 (UTC)

DJ mix album type

I remember this came up several times some years ago (and if I recall correctly, buried without establishing consensus), but I'm still very puzzled that there isn't a infobox type for the DJ mix album. I feel simply calling them compilation albums are to the discredit of the DJ, and to the presentation of the content. Remix albums are similarly wrong as they aren't compilations of remixes, or if they are its not the point. The ambiguity of 'mixtape' again feels distant. Surely nowhere on the internet are you gonna find DJ mix albums referred to as mixtapes, or remix albums. Compilations maybe, but DJ mix albums are distinct enough, the work of the DJ as opposed to just a various artists comp. This mess has lead to all different affairs across Wikipedia, with some DJ mix albums saying "compilation album by (DJ)" (which implies these albums are compilation of songs by that artist, which they are not), "compilation album (mixtape)" and "Remix album by (DJ)", when this inconsistent mess could all be clearly wiped up if they just all said "DJ mix album by (DJ)", or if its possible, "DJ mix album mixed by (DJ)", if that's any better. If we have the Category:DJ mix albums, and an article on them, I don't see why they aren't acknowledged as an album type infoboxes.--TangoTizerWolfstone (talk) 19:00, 18 January 2017 (UTC)

RfC at WikiProject Songs

A request for comments has been opened at WT:WikiProject Songs#RfC: Should Infobox single and Infobox song be merged? Please add your comments there. —Ojorojo (talk) 17:32, 7 March 2017 (UTC)

Chronology

Per WP:INFOBOXUSE the chronology field should contain links to existing articles. Occasionally I come upon an album infobox which contains a red or black link because the next chronological album doesn't yet have an article or isn't notable enough for an article (and may possibly never be notable enough), but there are articles on succeeding albums which cannot be reached via the navigation field of the album infobox, meaning I have to either scroll down to the bottom of the article to open up the nav box down there, or go to the artist's discography to find which is the next album we have an article on. I propose a return to the original wording which was amended after this discussion about including all album types. The wording "This group of fields establishes a chain connecting articles about an artist's album" - which makes it clear that the field is for navigation between articles, to "This group of fields establishes a timeline of an artist's releases". I can see how in the general flow of the discussion in which the participants were reaching for inclusivity of album types, that the word "timeline" was used, but the result is that it makes it appear as though all albums should be placed there, regardless of whether we have an article, which is at odds with the purpose of the navigation field per WP:SIDEBAR to navigate readers to related articles. My proposal is that the first paragraph be changed from:

This group of fields establishes a timeline of an artist's releases. In general, all albums and EPs should be placed in a single, chronological chain in order of release date (singles have a separate infobox, and thus a separate chain). Exceptions may be appropriate for artists with very complex discographies which may warrant more than one chain. If the previous or next release has a Wikipedia article, link the title to the corresponding article. Take care to maintain the integrity of chains, so that when release "A" points to "B" as the next release, "B" points back to "A" as the previous release.

to:

This group of fields connects existing Wikipedia articles on an artist's releases in chronological order. In general, albums and EPs should be placed in a single, chronological chain in order of release date (singles have a separate infobox, and thus a separate chain). Exceptions may be appropriate for artists with very complex discographies which may warrant more than one chain. Articles should be linked: if there is no existing article, then per WP:INFOBOXUSE, do not use a red link, but move to the next existing article. Take care to maintain the integrity of chains, so that when release "A" points to "B" as the next release, "B" points back to "A" as the previous release.

Comments? SilkTork ✔Tea time 12:44, 19 February 2017 (UTC)

Chronology has a specific meaning – "the arrangement of events or dates in the order of their occurrence" (OED) – that should not be ignored. To only include albums that have articles is for navigation purposes and not a true chronology. WP:INFOBOXUSE does not mention anything about chronologies, only "Avoid redlinks". The "integrity of chains" may seem like a good idea, but may be misleading about actual chronological sequence. —Ojorojo (talk) 16:01, 19 February 2017 (UTC)
I understand what you are saying, though the infobox is not able to provide a complete chronology, that is served by the discographies of the artist. I agree, though, that having access to the complete chronology or discography is useful, however there have been several requests over the years to add a discography link, and there has not yet been consensus for this, as such a link is generally provided by a nav box at the bottom of the page. Personally I would find it more useful to have a discography link on the infobox, and it would certainly be more useful than having the artist's article page linked twice in the infobox. SilkTork ✔Tea time 17:34, 19 February 2017 (UTC)
"not a true chronology". Chronologies are by their very nature selective. They list things in order of occurrence, but what is actually listed is always going to be a set defined by those creating the chronology. In this case the suggested set is "albums by the artist which have a Wikipedia article". That meets the guidelines for infoboxes and aids the average reader navigate through our articles. The current set up of "any and all albums, regardless of notability" leads to oddities like this: Dogs Under Stress. You can't go backwards, and if you click forwards you are redirected to the main Moe Tucker article because the article on GRL-GRUP was redirected to the main artist article per WP:NALBUMS. SilkTork ✔Tea time 17:51, 19 February 2017 (UTC)
An encyclopedia should not rely on fuzzy interpretations. "Chronology" should reflect real time, not the next WP article. Or change it to something less specific "X albums".—Ojorojo (talk) 18:55, 19 February 2017 (UTC)
  • Strongly oppose Chronology means exactly that. INFOBOXUSE simply says to avoid redlinks, not to avoid listing objects without articles. Producers and studios don't always have articles, are we not to list them based on your interpretation of this guideline? MOS:DATE and WP:OVERLINK state not to link to dates, but the infobox lists recording dates. Based on your interpretation, we should not list that either. No, your interpretation is wrong and consensus is to include recordings immediately before and immediately after in the infobox even when not notable. Walter Görlitz (talk) 22:20, 19 February 2017 (UTC)
  • Deprecate field entirely an infobox is supposed to focus on the article subject itself (in this case, the album/EP), not what was released after or before it. Such details are better for article prose (if anywhere in the article). In certain cases, it can also violate WP:CIRCULAR for solely depending on another article's content to determine placement. Snuggums (talk / edits) 15:47, 28 February 2017 (UTC)
  • Oppose Per the dissenting opinions. Idk if it's been said or not--I skimmed most of this--but there seems to almost always be enough information online about an album or EP to at least create an article with basic information such as personnel, track listing, and release details--at least a stub or start quality article--especially if there was enough information online to know such a release is part of a discography from the start. Allowing red links in the chronology field would also encourage the creation of that article more than excluding them would. Dan56 (talk) 06:36, 11 March 2017 (UTC)
  • Strongly oppose I can see where SilkTork is coming from, but I have to disagree with him on this occasion. As others have noted, the word "chronology" has a specific meaning and, as such, the next album in the chronology should be listed (without a redlink, ideally), irrespective of whether that album has a WP article or not. Kohoutek1138 (talk) 12:22, 12 March 2017 (UTC)

Italic title

@Jc86035: Your last edits removed italic title from a lot of articles, e.g. London Calling Did you test your edits any place - this template is transcluded by 144098 pages. Christian75 (talk) 08:13, 11 May 2017 (UTC)

@Christian75: Sorry about that, should be fixed now. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:46, 11 May 2017 (UTC)
Thanks :-) Christian75 (talk) 10:06, 11 May 2017 (UTC)

Is something broken?

What is with the shift I see in some track listings? Odd (Shinee album) is an example. --Jennica✿ / talk 01:20, 14 May 2017 (UTC)

The subtemplates were in |Next album= instead of |misc=. I've fixed that article. — JJMC89 (T·C) 02:45, 14 May 2017 (UTC)

Chronology/prev_title header

@Jc86035: if there is no |chronology= in the infobox, it produces "Artist chronology" in the header; if it is included but empty (chronology=[is empty]), it produces just "chronology". I think these should both produce "Artist album chronology" (the current {{Infobox single}} follows this, with both producing "Artist singles chronology"). —Ojorojo (talk) 17:52, 12 May 2017 (UTC)

@Ojorojo: My mistake, I forgot how parameters behave when specified but empty. Should be fixed now. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 17:57, 12 May 2017 (UTC)
@Jc86035: Almost, both seem to only produce "Artist chronology", rather than "Artist album chronology". —Ojorojo (talk) 18:03, 12 May 2017 (UTC)
@Ojorojo: The infobox can be used for EPs and other things as well, so adding "album" might not be appropriate here. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 18:10, 12 May 2017 (UTC)
@Jc86035: Yes, good point. I'll add it to the documentation. —Ojorojo (talk) 18:19, 12 May 2017 (UTC)
@Jc86035: |tracks= and/or {{Extra collapsed text}} seems to be causing problems with infobox songs (fields pushed to right) (see song's from Beggars Banquet before I removed the field). —Ojorojo (talk) 00:34, 13 May 2017 (UTC)
If |track_no= is filled in, it seems to display properly. Without it, it's pushed to the right. —Ojorojo (talk) 01:39, 13 May 2017 (UTC)
@Ojorojo: Fixed now, forgot to add a colspan in the TfM notice. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 02:26, 13 May 2017 (UTC)
@Jc86035: There's still a problem with some songs (from Sticky Fingers: "Sway", "I Got the Blues", "Dead Flowers", but other songs from the album are OK). —Ojorojo (talk) 14:35, 13 May 2017 (UTC)
@Ojorojo: Performing a null edit on each page (adding an extra line at the end of the page, then saving) should work. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:37, 13 May 2017 (UTC)
@Jc86035: A null edit will work; but you shouldn't need to add any lines at all - or make any other alteration. Just click any "edit" link and then save changes. --Redrose64 🌹 (talk) 14:32, 14 May 2017 (UTC)

Need a new tracking category

We need a new tracking category to capture all the instances of | Type = being empty. I'm creating some of them in my clean up of the infobox; there's so much incorrect stuff in the Type field that its easier to blank the rubbish entries rather than repair them as I edit. @TheFrog001: is doing a sterling job in populating the blank occurrences with the correct values, but a maintenance category would make life so much easier to track them down and show the outstanding workload. Any objections? - X201 (talk) 15:14, 20 May 2017 (UTC)

If it makes it easier for the clean up, add it. BTW, would something similar be helpful for the infobox song/single merger? —Ojorojo (talk) 15:24, 20 May 2017 (UTC)
I've yet to come across a situation where it didn't help to have a tracking category - X201 (talk) 17:06, 21 May 2017 (UTC)
@X201: No objection; shouldn't need consensus since it shouldn't affect appearance or really anything except maintenance. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:35, 20 May 2017 (UTC)
@X201: Sounds good. Should there also be a cat for when the parameter is incorrectly formatted as well? Walter Görlitz (talk) 20:43, 20 May 2017 (UTC)

bug on pages Step_2/4 and Talk_About_S

In these two pages the entire article gets swallowed up in the infobox. For some reason it doesn't happen on Collection_(2NE1_album) or Fever_(Kylie_Minogue_album) 66.234.193.114 (talk) 00:58, 21 May 2017 (UTC)

Fixed. —Ojorojo (talk) 02:07, 21 May 2017 (UTC)
@Ojorojo: Is the colour of the headers on those pages' infoboxes correct? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:40, 21 May 2017 (UTC)
@Jc86035: Changed to one color. The template explanations note this; infobox single and song use one or a mix of header colors. —Ojorojo (talk) 16:56, 22 May 2017 (UTC)

Another problem

@Jc86035: I've reverted the bot's attempted substitution at Babylon 5, as it left a pile of wikicode visible down in the "Music and scoring" section. When I edited the bot's revision, removed the HTML comment after "Infobox album", and tried "Show changes", the subst went through correctly. So possibly an HTML comment in that position is confusing Module:Unsubst-infobox? -- John of Reading (talk) 10:22, 19 May 2017 (UTC)

@John of Reading: I think the issue is that if the comment is in the template name then MediaWiki won't substitute it. This probably isn't solvable using the module, although maybe AnomieBOT's code could be changed to account for this; @Anomie: would this be possible and is it necessary? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:28, 19 May 2017 (UTC)
@Jc86035: There are over 3000 of these so we'd better delay any large-scale bot run. -- John of Reading (talk) 10:37, 19 May 2017 (UTC)
@John of Reading: of course; I was testing it to see if it would go through every transclusion or keep trying to edit the same article (since it returns itself). There are still a few separate issues to be ironed out with the Infobox song/Infobox single and Audiosample/Extra music sample mergers and Module:Unsubst-infobox, so it'll be a while. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:42, 19 May 2017 (UTC)
It's nothing to do with modules, nor with this infobox. There are a number of things that will defeat an attempt to WP:SUBST - these include: redlinked template; newlines between the subst: and the template name; HTML comment tags at any point between the opening braces and the first pipe. --Redrose64 🌹 (talk) 11:19, 19 May 2017 (UTC)
@Jc86035: Yes, I'll need to update the bot to not screw up like that. If you don't mind, remind me about this on Wednesday or so. Right now I'm at the Hackathon and, thanks to various reports of governmental stupidity, I brought a "clean" laptop and didn't copy AnomieBOT's development environment onto it before I left. Anomie⚔ 16:04, 19 May 2017 (UTC)
@Jc86035: Should be fixed now. Anomie⚔ 18:31, 23 May 2017 (UTC)

Discussion of this template at other venue

FYI
 – Pointer to relevant discussion elsewhere.

For no clear reason, whether to keep or change or remove something in this template is being heavily discussed at the talk page of an entirely different template. Please see Template talk:Infobox song#… and a bugbear: partial track listing.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:31, 26 May 2017 (UTC)

List formatting

On a sidenote - was there a recent change to the infobox to suppress any attempt to use vertical bulleted lists in, say, the studio parameter? Y2Kcrazyjoker4 (talk • contributions) 05:39, 28 May 2017 (UTC)

@Y2kcrazyjoker4: I added the CSS class so that the parameters could be used without {{hlist}}, {{flatlist}} and {{unbulleted list}} (as is done in most articles as far as I'm aware). Is there a need to use a regular bulleted list? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:23, 28 May 2017 (UTC)
Depending on the text, I think a normal vertical bulleted list actually looks better, like when there's a longer list of studios with locations or when that information takes up nearly an entire line each in the list (see Achtung Baby or Songs of Innocence (U2 album)). Y2Kcrazyjoker4 (talk • contributions) 18:09, 28 May 2017 (UTC)

Infoboxes for unreleased albums are broken

See Lei'd in Hawaii, Smile (The Beach Boys album), Andy Paley sessions. --Ilovetopaint (talk) 06:32, 1 June 2017 (UTC)

@Ilovetopaint: Fixed. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:32, 1 June 2017 (UTC)

Forced release date

It appears that the template has been changed so that if Release= is blank but there is a date in Chronology for current album, then the release date is copied from the chronology field. This is not a positive change: it's normal in jazz discographies to list by recording date, not release date, and the latter is often unknown. This change forces potentially erroneous (and unsourced) information into the Release field display, when the Chronology uses recording dates. I was forced into this as a crude avoidance measure. Changing it back, so that Release= must be completed manually, would be advisable. EddieHugh (talk) 22:46, 4 July 2017 (UTC)

Proposal: multiple chronologies

I think there should be two available sets of chronology fields, for example so that an infobox on an article for a studio album of a band with a large, complex discography, there can be one chronology that shows the next and previous studio album, and a second chronology that shows the next and previous official release of any kind. CJK09 (talk · contribs) 17:39, 31 July 2017 (UTC)

We already can do this--are you proposing that it be mandatory? ―Justin (koavf)❤T☮C☺M☯ 18:22, 31 July 2017 (UTC)
I didn't realize this. I was looking at the documentation and didn't see a way. How do I do this? CJK09 (talk · contribs) 18:31, 31 July 2017 (UTC)
As noted earlier: Most artist navboxes include albums, etc. (arranged chronologically in the template examples). Adding a second chronology to the album infobox is unnecessary. If an artist's preceding or next album is really that important to understanding the article album, it should be discussed in the text. Otherwise, it's just information for information's sake. —Ojorojo (talk) 18:50, 31 July 2017 (UTC)
@CJK09: This is explained on the template's documentation. You use this code:
{{Infobox album
...
| misc       = {{Extra chronology 
 | artist     = 
 | type       = 
 | prev_title = 
 | prev_year  = 
 | title      = 
 | year       = 
 | next_title = 
 | next_year  = 
 }}
}}
―Justin (koavf)❤T☮C☺M☯ 19:18, 31 July 2017 (UTC)

Cover art borders

After trying at WP:EIS and WP:VPT, maybe I'm finally in the right place to get this solved. The current border for album art is much too faint. Observe at Darkness in a Different Light (or a screenshot from my end in case it's brower-specific: [8]) It wasn't like that a few years ago, but somehow it's become lighter—to the point where it's barely visible. I request that the grey be made darker, or even black. Mac Dreamstate (talk) 18:10, 13 August 2017 (UTC)

@Mac Dreamstate: The border's color is not defined at this template but much deeper down. I've looked thru the relevant modules and I still don't see it. It may be in a CSS setting on this site. What did VPT tell you? ―Justin (koavf)❤T☮C☺M☯ 21:16, 13 August 2017 (UTC)
They told me.. absolutely nothing. I've been going around in circles. Mac Dreamstate (talk) 21:21, 13 August 2017 (UTC)
@Redrose64: What was this CSS? Was it the standard MediaWiki.css for en.wp? ―Justin (koavf)❤T☮C☺M☯ 22:17, 13 August 2017 (UTC)
The CSS rule that sets the image border is 
img.thumbborder {
    border: 1px solid #eaecf0;
}
but I don't know where that's defined; it's certainly not in MediaWiki:Common.css, it's probably set at a more fundamental level. Users may override that by copying the rule to Special:MyPage/common.css and altering the #eaecf0 - which is   - to another valid colour value. So for a 50% grey like this   you would use the value #808080 --Redrose64 🌹 (talk) 22:30, 13 August 2017 (UTC)

Edit request

Change 

| italic title= {{{italic_title|{{{italic title|{{{Italic title|}}}}}}}}}

with 

| italic title= {{{italic_title|{{{italic title|{{{Italic title|<noinclude>no</noinclude>}}}}}}}}}

so this template page title doesn't italicize. Hddty. (talk) 16:38, 19 September 2017 (UTC)

@Hddty.: Why? Album titles are italicized. ―Justin (koavf)❤T☮C☺M☯ 17:09, 19 September 2017 (UTC)
Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. --Redrose64 🌹 (talk) 19:02, 19 September 2017 (UTC)
@Redrose64: I just tested it at sandbox and it didn't work. Actually my point is that so the template page not italicize itself. For example {{Infobox film}} used that similar code. Hddty. (talk) 22:57, 19 September 2017 (UTC)
Well, for a start, at Template:Infobox album/sandbox you changed this:
| italic title= {{{italic_title|{{{italic title|{{{Italic title|}}}}}}}}}
to this:
| italic title= {{{italic_title|<noinclude>no</noinclude>{{{italic title|<noinclude>no</noinclude>{{{Italic title|<noinclude>no</noinclude>}}}}}}}}}
which is not what you put above. I don't see why you need those two extra <noinclude>no</noinclude>. --Redrose64 🌹 (talk) 08:30, 20 September 2017 (UTC)

Am I missing something here? Why doesn't italic_title = no cover your needs? Which article is it failing to work on? - X201 (talk) 11:53, 20 September 2017 (UTC)

I don't think that any articles are in error. Apparently Hddty. wants the template's home page to display without the italic title. --Redrose64 🌹 (talk) 19:18, 20 September 2017 (UTC)

Music infoboxes with unknown value for type

How does Category:Music infoboxes with unknown value for type get populated? I can't spot any mention of it in the template code. Is there another module that is doing the work? The reason I ask is that it appears to not be recognising "other" as a valid entry for type. - X201 (talk) 13:58, 25 September 2017 (UTC)

Found it, it was the link sub-template. - X201 (talk) 14:15, 25 September 2017 (UTC)

Music infoboxes with deprecated parameters

I've been looking unsuccesfully into why on so many articles using {{Infobox album}} are ending up in the Category:Music infoboxes with deprecated parameters. Originally I was just trying to fix the error on The Room (film) but it looks like this issue is much bigger with over 150,000 articles in the deprecated parameters category. Did something break or am I missing some sort of easy fix? I'm just very confused at this point sadly. Jeanjung212 (talk) 18:38, 31 October 2017 (UTC)

@Jeanjung212: It's due to this edit which changed how the chronology feature works. ―Justin (koavf)❤T☮C☺M☯ 18:57, 31 October 2017 (UTC)
Not only that, it's also about changing the names of all the parameters (they are case-sensitive, so that Artist and artist are different). An easy fix is to do a subst, i.e. subst:Infobox album. You just put this prefix there, then the template code cleans itself up automagically. (Auxiliary templates like {{Extra chronology}} and {{Singles}}, if present, may require the same treatment). Still a tedious work on that many articles, perhaps a bot should do this. — Mike Novikoff 21:50, 31 October 2017 (UTC)
A bot is the plan as I understanding it. The only problem is that for it to be successful all of the major errors that are currently present need cleaning up. I've cleaned the infobox and I'm working my way through the sub-templates, they should be completed soon, then it's just another quick run through and away you go. - X201 (talk) 17:08, 1 November 2017 (UTC)
@X201: I have filed a bot request to substitute all of the infoboxes without errors since I don't think I have time to either substitute the templates or fix the remaining 7,500 errors, but I am not sure whether Nihlus will be carrying it out or if someone else should do it (note to Nihlus: fixing the errors is probably out of scope of that request, sorry if it was confusing). Jc86035 (talk) 06:45, 3 November 2017 (UTC)
Thank you all so much for helping me with this! I just couldn't figure it out on my own at all, I really appreciate it. Jeanjung212 (talk) 16:46, 1 November 2017 (UTC)

Question concerning album type

I am wondering what an album that consists of home/cassette/etc. recordings as opposed to music recorded in a studio would be classed as, as it doesn't currently seem to be clear (and suggests the article on album types needs updating). FamblyCat94 (talk) 01:23, 27 November 2017 (UTC)

I would probably consider that a demo album. ―Justin (koavf)❤T☮C☺M☯ 01:31, 27 November 2017 (UTC)

Problem with page preview mode

I think there is a technical problem with this infobox, which doesn't exist in most other infoboxes. The page preview feature works like a "tool tip": when a reader hovers the mouse pointer over a wikilink, a box pops up with some of the linked article's lead text, and identifying image if there is one. The image is taken from the infobox if there is one, otherwise the top image is selected. This must default to disabled for logged-in users, and to enabled for IP users; that's how I found it by accident.

When I preview wikilinks to album pages, the lead text comes up but the cover photo in the infobox does not.

I wondered if this maybe is due to the pictures being fair-use, but I can prove that's not it: hover on this link to Superman, and you'll see the fair-use picture shows in the preview. So Template:infobox comics character doesn't have the problem.

If you're unfamiliar with this feature, it is enabled from your Preferences under the Appearance tab: set the radio button under Reading preferences: Page views. Notice the little note underneath it says "Certain gadgets and other customizations may affect the performance of this feature. If you experience problems please review your gadgets and user scripts, including global ones." I think that's what's going on here.

I don't know much about the technical details of template writing, or I would look into it myself. Can someone with such knowledge look into this and fix it? (If not, iss there another talk or help page I could post this question to? I haven't been able to find a WP page which explains the page preview option.) JustinTime55 (talk) 19:34, 2 February 2018 (UTC)

Template-protected edit request on 2 February 2018

Please fix problem: does not work properly with page preview feature: when reader hovers mouse pointer over a wikilink to an album page with this infobox, the album cover image does not show up in the preview window. (Example: Don't Crush That Dwarf, Hand Me the Pliers: page preview shows lead text but no cover image.) This works properly for some infoboxes (e.g.: infobox comics character: Superman page preview works properly. JustinTime55 (talk) 20:26, 2 February 2018 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. — JJMC89 (T·C) 20:39, 2 February 2018 (UTC)

No, that burecratic bullshit doesn't cut it. I made the request as clear as I could by demonstrating the problem. I don't know what the technical solution to the problem is, so I can't possibly say "change X to Y". The request is to please solve the problem and kindly fix it.

I am a professional computer programmer; if one of my customers asked me to solve a software problem and I said, "I can't do that; please tell me what code to change", I'd be fired. JustinTime55 (talk) 21:45, 2 February 2018 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Edit requests are to implement requests that have been tested, not to summon someone to do the work for you. Also, I doubt that the template code is the source of the problem, and you haven't presented evidence that it is or proposed a solution. — JJMC89 (T·C) 22:25, 2 February 2018 (UTC)

@JustinTime55: It doesn't seem to be doing that now. In other words, works on my machine. Walter Görlitz (talk) 06:28, 6 February 2018 (UTC)

Spacing in the template?

In the template, the set up is made to include equal spacing, however, certain editors continue to remove the spacing, and make it one space between the "=" and the other media. For example — and I am going to use the Man of the Woods template for example — if we go by what the template calls, the infobox [should] look like this when editing: 

{{Infobox album
| name         = Man of the Woods
| type         = studio
| artist       = [[Justin Timberlake]]
| cover        = Justin Timberlake - Man of the Woods (Official Album Cover).png
| alt          = Cover image features two images of a male, edited to appear as one. Top-half image features male in all-black suit and white undershirt, in a snow-covered wooded area. Bottom-half image features male in ripped blue jeans, flannel button down shirt in a smog-filled wooded area. Text is featured in handwritten print.
| border       = yes
| released     = {{Start date|2018|02|02|mf=yes}}
| recorded     = 2016–2017
| studio       = {{hlist|[[Conway Recording Studios]], [[Los Angeles]]|[[EastWest Studios]], Los Angeles|[[Jungle City Studios]], [[New York City]]|[[Red Bull Music Academy|Red Bull Studios]], [[Sao Paulo]]}}
| genre        = {{hlist|[[Pop music|Pop]]|[[Electronic music|electronic]]|[[Contemporary R&B|R&B]]<ref name="genres"/>}}
| length       = {{duration|m=65|s=54}}
| label        = [[RCA Records|RCA]]
| producer     = {{hlist|Justin Timberlake (also [[Executive producer#Music|exec.]])|[[Danja (producer)|Danja]]|[[1500 or Nothin'|Larrance Dopson]]|[[Jerome "J-Roc" Harmon]]|[[Eric Hudson]]|Elliott Ives|[[Rob Knox (producer)|Rob Knox]]|[[The Neptunes]]|[[Timbaland]]}}
| prev_title   = [[The 20/20 Experience – 2 of 2]]
| prev_year    = 2013
| year         = 2018
| next_title   = 
| next_year    = 
| misc         = {{Singles
 | name        = Man of the Woods
 | type        = studio
 | single1     = [[Filthy (song)|Filthy]]
 | single1date = January 5, 2018
 | single2     = [[Supplies (song)|Supplies]]
 | single2date = January 18, 2018
 | single3     = [[Say Something (Justin Timberlake song)|Say Something]]
 | single3date = January 25, 2018
<!-- Sorry, but an album cover is not a [[Wikipedia:RS|reliable source]] that dictates when singles are coming out. Please find a [[Wikipedia:Verifiability|verifiable]] third-party source to prove that "Man of the Woods" is the fourth single. -->
 }}
}}

However, if users do the one space between, it would look like this — which I believe is a bit messy to look at and edit: 

{{Infobox album
| name = Man of the Woods
| type = studio
| artist = [[Justin Timberlake]]
| cover = Justin Timberlake - Man of the Woods (Official Album Cover).png
| border = yes
| alt = The cover image features two images of a male, edited to appear as one. Top-diagonal-half image features male in all-black suit and white undershirt, in a snow-covered wooded area. Bottom-diagonal-half image features male in ripped blue jeans, flannel button down shirt in a smog-filled wooded area. Below this title: MAN OF THE WOODS, appears in capitalised handwritten print.
| released = {{start date|2018|2|2}}
| recorded = 2016–2017
| studio = {{hlist|[[Conway Recording Studios]], [[Los Angeles]]|[[EastWest Studios]], Los Angeles|[[Jungle City Studios]], [[New York City]]|[[Red Bull Music Academy|Red Bull Studios]], [[Sao Paulo]]}}
| genre = {{hlist|[[Pop music|Pop]]|[[Contemporary R&B|R&B]]|[[Electronic music|electronic]]<ref name="genres"/>}}
| length = {{duration|m=65|s=54}}
| label = [[RCA Records|RCA]]
| producer = {{hlist|Justin Timberlake (also [[Executive producer#Music|exec.]])|[[Danja (producer)|Danja]]|[[1500 or Nothin'|Larrance Dopson]]|[[Jerome "J-Roc" Harmon]]|[[Eric Hudson]]|Elliott Ives|[[Rob Knox (producer)|Rob Knox]]|[[The Neptunes]]|[[Timbaland]]}}
| prev_title   = [[The 20/20 Experience – 2 of 2]]
| prev_year = 2013
| year = 2018
| next_title = 
| next_year = 
| misc = {{Singles
  | name = Man of the Woods
  | type = studio
  | single1 = [[Filthy (song)|Filthy]]
  | single1date = January 5, 2018
  | single2 = [[Supplies (song)|Supplies]]
  | single2date = January 18, 2018
  | single3 = [[Say Something (Justin Timberlake song)|Say Something]]
  | single3date = January 25, 2018
<!-- Sorry, but an album cover is not a [[Wikipedia:RS|reliable source]] that dictates when singles are coming out. Please find a [[Wikipedia:Verifiability|verifiable]] third-party source to prove that "Man of the Woods" is the fourth single. -->
  }}
}}

Which is the proper format to be used to end potential edit-warring once and for all? Also, I started up a discussion about {{Start date}} here, which might also pertain to this page, as well. Hope we can put an edit to this. livelikemusic talk! 15:08, 24 February 2018 (UTC)

  • To be honest, I don't really have a preference. People can use whichever form they like without one being enforced over the other; they make no difference visually outside of editing mode. Snuggums (talk / edits) 18:14, 24 February 2018 (UTC)
  • What am I missing? It seems that the "="s only align vertically when using <pre>{{Infobox album}}</pre>, as in the above example. In an actual article, using the template code from the documentation page (or subst:Infobox album) doesn't produce the same orderly appearance in the edit view (for example [9]). To get that, the template would have to look something like:
{{Infobox album
| name         = 
| type           = 
| artist          = 
| cover         = 
| alt              = 
| released    = <!-- {{Start date|||}} -->
| recorded   = 
| venue        = 
| studio        = 
| genre         = <!-- Do not add unsourced genres -->
| length        = 
| label           = 
| producer   = 
| prev_title    = 
| prev_year    = 
| next_title    = 
| next_year    = 
}}

—Ojorojo (talk) 19:01, 24 February 2018 (UTC)

I'm not quite sure where you're getting the edit view; copy-paste from the main page produces what I block quoted above. livelikemusic talk! 19:11, 24 February 2018 (UTC)
Your Man of the Woods block quote above uses <pre>{{Infobox album}}</pre>. When you click on the link I added (or "edit" for an album article page that uses the documentation page code), do the "="s align vertically? On my setup, they don't. —Ojorojo (talk) 19:30, 24 February 2018 (UTC)
They do align from the edit history you linked me to; however, the spaces within said-edit are not the same as what's requested from the template itself, as I included above in this discussion. livelikemusic talk! 19:39, 24 February 2018 (UTC)
Interesting. What happens if you use the blank template I added above? For me, the "="s appear as in a straight column. —Ojorojo (talk) 19:45, 24 February 2018 (UTC)
This is what I see — I screenshot it, because I just chose a random page to begin editing in, and was unsure if it'd work for anyone else to see on Wikipedia. livelikemusic talk! 19:49, 24 February 2018 (UTC)
When I use this blank template (without the "subst:"), the "="s appear aligned vertically here. It may be that multiple spaces appear differently for different users/systems. If this is the case, there is no real reason to prefer more than one space before the "=". —Ojorojo (talk) 20:23, 24 February 2018 (UTC)
Even with what you just linked me to, it is not aligned for me. The issue is people purposefully removing the spaces, which is naturally against the documentation of the template. livelikemusic talk! 20:30, 24 February 2018 (UTC)
If the template shows differently depending on the system, etc., the code with the spacing may just be for an orderly appearance on the documentation page. Maybe the issue of removing/adding spaces should be taken up at WP:WPINFOBOX or such. —Ojorojo (talk) 20:51, 24 February 2018 (UTC)
I've looked at the coding on this page, the main infobox page and those that you have linked to, on multiple different iOS systems within my availability — of all different screen sizes and producers, etc., and they all mirror correctly to what I do see on my main iOS. So, I don't see how it depends on the system? livelikemusic talk! 21:00, 24 February 2018 (UTC)
I don't have an explanation, but mine definitely shows differently (and has for years). Maybe Jc86035 has an answer. —Ojorojo (talk) 21:09, 24 February 2018 (UTC)
Is your browser zoom set at anything that isn't "100%"? I know that, sometimes, if I do that, then it does change a bit. So, maybe that's what is happening? I honestly do not know. If you copy-paste the code from the main template into your sandbox, what does it show? Or might I do it and you tell me what you see? livelikemusic talk! 21:14, 24 February 2018 (UTC)
Yes, changing the font size makes a difference. I added the template from the documentation page to my sandbox (2nd or "Y" example), but at the default setting, it still appears unaligned (for example, the "=" in |alt= aligns with the "d" in |released=). —Ojorojo (talk) 21:43, 24 February 2018 (UTC)

Ojorojo, are your settings set to use monospaced font in your edit window ("Edit area font style")? If they are and the characters in this sentence don't all have the same width, then you might have a font problem somewhere. If you aren't using monospaced font in the edit window, then the equals signs in the second example won't be aligned. Jc86035 (talk) 07:59, 25 February 2018 (UTC)

@Jc86035: It's set to monospaced font and the sentence characters have the same width. Most all of my settings are default. The difference in spacing/alignment isn't a problem for me – I only bring it up to show that standardized spacing may not work for everyone and therefore, there is no reason to follow the template spacing from the documentation page. The disruptive editing is another issue. —Ojorojo (talk) 14:48, 25 February 2018 (UTC)

I dunno

I just a version of this template to copy and paste. That's all I'm asking for. --80.3.85.48 (talk) 17:50, 17 March 2018 (UTC)

There's one present, just underneath the "code" heading. If that isn't what you're looking for, perhaps you could explain your need in greater detail. Walter Görlitz (talk) 05:49, 19 March 2018 (UTC)
I mean the thing that actually MAKES the template. Use <nowiki></nowiki> to display it for me; put it on my talk page. — Preceding unsigned comment added by 80.3.85.48 (talk) 11:27, 8 April 2018 (UTC)

Changes

This is the first I've noticed a change to infobox album. Which parameters have been deprecated? Why was any of it done? It looked better the old way. Changing something as extensive as the album template strikes me as a solution looking for a problem. A good editor knows when something should be left alone and when something should be changed. All of the people who have worked on infobox templates up until now, particularly IP users, are going to wonder what the standard is. For example, lowercase or uppercase for the field names, prev title instead of prev album.
Vmavanti (talk) 01:51, 16 April 2018 (UTC)

Across Wikipedia the move is to change to lowercase for consistency. Unfortunately at the moment the template is in-between formats, and converting 150,000 templates is a difficult job, as the discussion above shows. - X201 (talk) 08:24, 16 April 2018 (UTC)

Short description

There is a new magic word for short descriptions (used on mobile, apps, search...) which gets populated on enwiki through Template:Short description. More than 800,000 pages already have a short description, either directly or through some logic in an infobox template. This is e.g. implemented in Template:Infobox settlement without much problems (though improvements are always welcome!). The changes there[10] are relatively complicated, the local description we could generate here could be a lot simpler; "'type' album by 'artist'" (adding year would make it somewhat more complicated).

Anyone feels up to actually writing the code for this? Fram (talk) 14:37, 25 May 2018 (UTC)

@Fram: I already have code in the sandbox for infobox album (you can see what I'm looking at and have finished here), and the album template is great in that it already has a suitable description visible in the infobox (e.g for Nirvana_(Nirvana_album) there's "greatest hits album by Nirvana") and thus easy to generate; main problem is that the infobox is often used as a secondary infobox e.g in film articles for film scores; they should be hopefully excluded by excluding film scores and the like from generating short descriptions, but I'm not sure, which is the main barrier to this. Galobtter (pingó mió) 15:55, 25 May 2018 (UTC)

Captions

Hello. In this infobox, I believe that the "caption" parameter should only be used if absolutely necessary; eg. to distinguish a specific version of an album cover that is shown in the infobox. However, I see a lot of album articles (particularly in Wikipedia:WikiProject Electronic Music, and related to the record label Monstercat) that have every cover with the caption "Cover art" (example). I believe this is compeltely pointless, unnecessary, and that these captions that serve no purpose should be removed.

I have also crossposted this at Wikipedia talk:WikiProject Electronic music and Wikipedia talk:WikiProject Music. Thanks, Lazz_R 18:02, 30 March 2018 (UTC)

"Cover art" by itself is indeed a pointless caption, but if the designer has an article, then I can't see any harm in using the caption to link to their article; e.g., Atomic Playboys (older revision). Mac Dreamstate (talk) 18:43, 30 March 2018 (UTC)
I agree, a link to the creator of the artwork may sometimes be necessary (this is done on The Dark Side of the Moon, a featured article). However, yes, "Cover art" alone remains pointless. Lazz_R 22:44, 30 March 2018 (UTC)
Agreed. Captions shouldn't be added for that. This case is given as an example in the MOS. Photographs and other graphics should have captions, unless they are unambiguous depictions of the subject of the article or when they are "self-captioning" images (such as reproductions of album or book covers).MOS:CAPTION — JJMC89 (T·C) 23:40, 30 March 2018 (UTC)
The use of captions to add info about cover authors was already discussed [11][12] and there was an agreement. I would like to keep those decisions as standard. Lewismaster (talk) 20:07, 29 June 2018 (UTC)

RFC on removing genre

There is an RFC on removing genres from infoboxes at WT:Manual of Style/Infoboxes#Request for comment on removing genres from musician, album, and song infoboxes — BillHPike (talk, contribs) 16:22, 27 September 2018 (UTC)

String module error?

Hello, I have run into issues with the substitution trick resulting in errors like this where it states "String Module Error: Match not found" for the next album in a chronology. I am wondering what causes this? I have been running some sandbox tests and it occurs with non-existent pages (my initial hunch), but also with existing articles.

Does anyone have any knowledge as to the cause? Any help is greatly appreciated. (Also, feel free to play around with it in my bot's sandbox if you like) --TheSandDoctor Talk 03:01, 14 April 2018 (UTC)

The missing value in |next_year= causes it. Extra punctucation, letters, etc., in some parameters will also cause an error (see Category:Music infoboxes with Module:String errors). —Ojorojo (talk) 14:17, 14 April 2018 (UTC)
so what is the fix for A Kick in the Head Is Worth Eight in the Pants? Frietjes (talk) 15:14, 14 April 2018 (UTC)
|released=Unreleased is not recognized. It must contain a four number year, which is used in the chronology. It could be worked around using |misc= {{Extra chronology}}, but it doesn't seem that an unreleased album belongs in a chronology of released albums. —Ojorojo (talk) 15:54, 14 April 2018 (UTC)
so we add red error messages to thousands of pages in Category:Music infoboxes with Module:String errors without any idea of how to fix all of them? nice work! Frietjes (talk) 16:11, 14 April 2018 (UTC)
Maybe the persons responsible[13] can provide a better explanation/solution, but it was my understanding that these could all be handled by a bot. —Ojorojo (talk) 17:17, 14 April 2018 (UTC)
do you mean Jc86035 or Jon Kolbert. Frietjes (talk) 14:51, 15 April 2018 (UTC)
The link does show Jc86035 made most of the newer template edits, yes? Some discussions are now in Template talk:Infobox album/Archive 11. —Ojorojo (talk) 16:58, 15 April 2018 (UTC)
true, but the diffs posted below show that Jon Kolbert has been mangling the articles. much easier to fix the template/module than it is to fix all the mangled articles. Frietjes (talk) 17:06, 15 April 2018 (UTC)
Perhaps Jon Kolbert should wait until Jc86035 has had a chance to explain. —17:39, 15 April 2018 (UTC)
I rolled back about 28 of the worst ones, who knows how many other bad edits have been made. Frietjes (talk) 17:57, 15 April 2018 (UTC)
X201 has done a lot of work on album infoboxes. They might be able to address this. —Ojorojo (talk) 18:06, 15 April 2018 (UTC)

I am in the process of clearing out Category:Music infoboxes with deprecated parameters and Category:Music infoboxes with Module:String errors. With backlogs of 149K and 7.1K articles respectively, it's impossible to do it in one go. I've made it down approximately to "Be", as you can see the only remaining pages from 0-Be are those which are in userspace, nominated for deletion or lack information to solve the Module:String error.

Since I started keeping track, the backlogs have been significantly reduced - the first category by around 8.7% (~13K articles), and the second category backlog by around 6.3% (~450 articles). I would gladly appreciate more help in tackling these issues, as the magnitude of articles in these categories is quite daunting. With the current template format it's much easier to avoid silly formatting errors and help ensure consistent usage. I have repaired a bunch more so that the templates are using non-deprecated parameters and the current simplified syntax. Generally any extra comments or weird formatting would trigger a Module:String error, i.e. unclosed italics, using the wrong bracket, having a template where a string is expected. Jon Kolbert (talk) 19:52, 15 April 2018 (UTC)

Jon Kolbert, this is particularly bad. if you can't process the information, don't just erase it. and a blank value for released should not be an error. Frietjes (talk) 16:14, 14 April 2018 (UTC)
I've suffered from this in my own clean up efforts. In short the template is being tripped up by the thing it fixes. The template is eliminating all of the different formats (and errors) that users have introduced over the years. The problem is that in switching, either the subst command or a bot need to be programmed to handle every eventuality that they may encounter and abort if they don't know how to handle it. The problem with this is that there are a mind boggling number of permutations that could trip it up, when I was doing it the only way I found that consistently worked was to do the edits myself. I set up a couple of basic rules in AWB to handle the formats that were consistent and then I manually fixed the ones that tripped it up. In short there needs to be a pre-processing run on fields that can trip the subst command up, then subst can be safely run (perhaps a hidden cat for articles that have been checked and are ready for subst?). There are too many variations to do subst from the start or to program it to handle. - X201 (talk) 08:03, 16 April 2018 (UTC)
The Released field causing an error on blank needs fixing pronto, though - X201 (talk) 08:20, 16 April 2018 (UTC)
don't worry, a bot apparently isn't any worse than a human [14] [15] since humans operate the same as bots. Frietjes (talk) 13:29, 16 April 2018 (UTC)
We definitely need something to move the changeover forward. However, I don't think producing a lot of red string error messages would be accepted. X201's bot suggestion should be explored, but I don't believe Released needs to be changed. As noted above, if necessary {{Extra chronology}} may be used for released values other than year or if blank (see example[16]). The template documentation needs to be updated to advise users on the proper use of certain fields. Another issue has come up a couple times – using subst: always produces |studio= and |venue=. Albums seldom include both studio and live tracks. Maybe subst: could only produce studio, since it is the most common (subst: leaves out several other lesser used parameters, such as longtype, language, director, compiler, etc.) —Ojorojo (talk) 16:05, 16 April 2018 (UTC)
Ojorojo A BRFA is currently underway (albeit slowly, a lot of things to check and little time for the next week to do it in). --TheSandDoctor Talk 01:50, 17 April 2018 (UTC)
I'll try to follow the progress, but I know little about bots, etc. —Ojorojo (talk) 15:44, 17 April 2018 (UTC)

@Frietjes, Jon Kolbert, and TheSandDoctor: Sorry I didn't find this discussion until now. To briefly expand on X201's explanation, I for some reason built all of the replacement code on multiple nested layers of if parser functions and Module:String, and I do not want to touch it any more because it would be a fairly painful experience to wade through that code and figure out how to fix the imperfections. It was basically as good as I could have made it at the time.

The error on the blank Released field is probably intentional because I wanted to require a date for all three chronology fields before the error would go away. This is clearly not the best solution because it requires an editor to manually find all of the dates, but maybe in the next bot run the errors could simply be removed in a second edit, and a tracking category could be added for chronologies without all of the years filled in. Jc86035 (talk) 21:32, 29 June 2018 (UTC)

@Jc86035: Currently the bot reverts itself if it creates an error. Do you suggest the bot add a page to a new category when it reverts itself (wouldn't be that hard to do I imagine) or? Pages are currently recorded locally when reverts occur. If errors already existed and the page was in Category:Music infoboxes with Module:String errors already, the bot won't edit it (in its current configuration). --TheSandDoctor Talk 22:32, 29 June 2018 (UTC)
@TheSandDoctor: I don't think the bot's current behaviour shouldn't be changed. In full (sorry, I should have explained this): I tried in the original UsuallyNonviolentBot AWB configuration to replace the old chronology parameter with the new parameter if there was no date in it (e.g. changing "Last album" to "prev_title" without changing the value), although I don't think this materialized. This would avoid an error materializing during substitution. If this isn't done the bot could just remove the errors from date parameters after substitution. These could be done in a final bot run for any pages left in the error category, after editors have tried to manually add dates and done other similar manual fixes. Jc86035 (talk) 22:39, 29 June 2018 (UTC)

This is just a not-very-useful note to say that this problem still exists. I haven't looked into the causes, but my diff may help develop a solution for what may be one of many pathological cases. – Jonesey95 (talk) 18:53, 7 October 2018 (UTC)

The one you linked was caused by unbalanced apostrophes near the BR ''[[Genius of Modern Music: Volume 1]]''''<br />(1947). They're a pain to code for because there are so many possibilities, I'm doing a clean up of infoboxes at the moment too and have fallen foul of this a couple of times. Also, as a heads up, look out for any Frank Zappa albums, someone has gone through all of those and repurposed the field; adding a chronological discography number to the album name, this also breaks the template updating subst routine because it's unexpected content. I tend to sigh and look forward to the day when we've managed to plough though everything and albums and years are neatly in their own fields. - X201 (talk) 07:31, 8 October 2018 (UTC)
Have just realised, I think it may have been the space in the BR tag <br /> that caused the error. - X201 (talk) 09:34, 8 October 2018 (UTC)
I've said it before, the slash in the break tag is not needed, and here accommodating it may have caused problems. Walter Görlitz (talk) 18:58, 8 October 2018 (UTC)

Unreleased albums

@Frietjes: How should unreleased albums be handled? I've hit a problem with The Black Room (The KLF album). I get a string module error in the chronology because there is no release date for the album, obviously, being unreleased it's never going to have one. How can the template be fixed to handle this situation? Because this isn't a one off Category:Unreleased albums - X201 (talk) 07:34, 17 October 2018 (UTC)

String errors

@X201, Frietjes, and Jc86035: so just an update, I've gotten started on cleaning up the deprecations and I found something that definitely does appear to be broken... Category:Music infoboxes with Module:String errors is populated with tons of pages that don't appear to have any actual errors. Any chance one of you can take a look and see if you can figure out what is going wrong? Thanks in advance. --Zackmann (Talk to me/What I been doing) 18:45, 14 October 2018 (UTC)

The articles don't currently display the errors, but they would if the template were substituted. — JJMC89 (T·C) 22:05, 14 October 2018 (UTC)
It would be helpful if an error message would display, at least in preview mode, so that editors could fix the errors. I also do not see any documentation about this error tracking category in the template's documentation. – Jonesey95 (talk) 19:13, 18 October 2018 (UTC)

Uh... WOAH

@Frietjes: So curious what you think of the way this template is currently laid out... I get the goal here was to be able to quickly subst the template and fix... but WOAH. Any chance you can work your magic? --Zackmann (Talk to me/What I been doing) 07:18, 13 October 2018 (UTC)

Zackmann08, at one point in time I had started to write a LUA version to do all this, but unless it's broken, I don't see any reason to mess with it. Frietjes (talk) 15:07, 13 October 2018 (UTC)
@Frietjes: fair enough. I did find that the substitution method didn't really work. [17], [18], [19], etc. I think I'm just going to write a script to do this. There really isn't a need for a LUA since in the end this is just a standard infobox. Just need to clean up the deprecation. --Zackmann (Talk to me/What I been doing) 16:43, 13 October 2018 (UTC)
I think saying it doesn't work is a bit off, it works for the bulk of articles. All of the examples are caused by unexpected user formatting - ironically the thing that it's fixing. There are so many permutations that it would be wrong to ask Frietjes to code for them. - X201 (talk) 18:14, 13 October 2018 (UTC)
@X201: sorry you misunderstood, or more accurately I didn't really articulate what I meant. You are 100% correct. There are WAY too many permutations to try to code them into the template. IMHO this sort of replacement/cleanup should not be done via template substitution for this exact reason. What I was suggesting was that we clean up the syntax and actually remove that substitution stuff so that the template code is more readable. I'm planning to write my own script to clean up these articles but was having a hard time understanding what needed to be done because the substitution syntax is crazy complicated. Now that being said, you make a good point. It works for the majority of articles. So I withdraw my suggestion. No longer advocating that we change the template code. But we still have the issue of the over 100,000 articles with deprecated syntax. So I'm going to look into creating an AWB script to start getting these fixed. The substitution method works great for one off manual conversions, but when I tried to do it with AWB, of the 30 that I did, at least a third of them broke. That is just a limitation of the template syntax. So I'm going to see if I can get a better solution built. Let me know if you have any thoughts on the matter. :-) --Zackmann (Talk to me/What I been doing) 19:56, 13 October 2018 (UTC)
Maybe you have already figured this out, but you may want to avoid pages that have Module:string errors when you are substing the infobox. That should improve your success rate. I have almost entirely cleared out the "malformed table" error category, so you shouldn't run into any of those. – Jonesey95 (talk) 19:16, 18 October 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_album/Archive_11&oldid=1135365047"