Jump to content

Template talk:Infobox album/Archive 10

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

Consistency

I've noticed some inconsistencies both within this template and with other similar templates like Template:Infobox single. Could we please agree that we are happy for the following changes to be made?

Field Suggested change
Released Change the date so that it uses {{startdate}}, i.e. the date format should be {{2014|01|01}}
Recorded Include guidance on how to list recording locations, dates etc. Use {{ubl}} rather than <br/>
Genres Add that either {{ubl}} or {{flat list}} should be used to order lists.
Record label Add that either {{ubl}} or {{flat list}} should be used to order lists.
Producers Add that either {{ubl}} or {{flat list}} should be used to order lists.

Now this has been brought up before and people harp on about {{flat list}} not producing commas etc. Please note that before complaining about that here, WP:ACCESS is already a confirmed and accepted part of the Manual of Style. Its changes are mandatory and frankly its very unorganised of us to half implement these changes for some fields or not for others. If you dislike or disagree with Accessibility changes then this is not the place or discussion to lambaste the {{flat list}} as this has already been accepted into the manual of style which applies to all of wikipedia regardless of the article or project. I would like to see some form of agreement that whilst we already promote their use for the Producer field, it needs to be updated for the other fields too. This is also along with the use of the start date template which is a separate but equally important issue. → Lil-℧niquԐ 1 - { Talk } - 23:03, 29 April 2014 (UTC)

No flatlists. No plainlists. There is consensus that long lists should use them but not for short lists. There is no proof that it is better for ACCESS either, only anecdotal evidence. Take your list suggestions and push them elsewhere, thanks. Walter Görlitz (talk) 23:21, 29 April 2014 (UTC)
Oh for goodness sake Walter Görlitz, I explained in previous discussions that Accessibility is not a pure science like Maths or Science where you can measure results. We rely on the feedback from others to inform our decision. It is proven if you understand the concept of data granularity. To put it in simplest terms, this is how easily one can tell that one piece of information is related to the previous or is part of a subset of information. When using commas, screen readers read as follows "item one COMMA item two COMMA" etc which has a negative impact on granularity. With either UBL or FLAT LIST, the reader will read as follows: "Item one [pause] item two [pause]". Whereby the pause is the equivalent of a breath much like when you or I would read a list. There is already a consensus that they can be used in the producer field, it seems only logical that we uniform the template. You've already objected on the grounds that you don't see any benefit, that's fine. Your point is noted, I would like to hear from others. Would it harm you to speak politely for a change? → Lil-℧niquԐ 1 - { Talk } - 21:52, 30 April 2014 (UTC)
Really unnecessary. If you truly want to be consistent, bring this up in village pump for other infoboxes to cover, not one infobox at a time. Lucia Black (talk) 22:00, 30 April 2014 (UTC)
Lucia Black not unnecessary at all, previous discussion decided that UBL and FLAT LIST should be implemented in the producer field. It looks silly have some fields use these templates and not others. Since the templates bring about valuable changes its logical that all fields should be updated according. I don't need to bring it up at village pump as changes such as these are part of the MOS already and other infoboxes are making in-roads to change these factors. There is already a consensus that these changes improve data granularity. → Lil-℧niquԐ 1 - { Talk } - 22:07, 30 April 2014 (UTC)
It looks unnecessary to use flatlist at all in an infobox. in a navbox sure. Again, improving "data-granularity" is subjective....and no, not other forums are doing this. WP:GRANULARITY is only promoting grnaularity wikiproject per wikiproject. if you brought it up to WP:VILLAGE, it will look less like you're trying to change wikipedia slowly, and trying to improve it "instantly".
There is no need for flatlist in the infobox. i dont know why they made this consensus, and even so, it seems more like a localconsensus. Lucia Black (talk) 22:10, 30 April 2014 (UTC)
Please explain how data granularity is "subjective". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:13, 30 April 2014 (UTC)
[ec] Please provide evidence for your claim that list markup templates should not be used for short lists. As pointed out to you previously, the use of proper list markup is a recommendation in WCAG 2.0, the ISO international standard for web accessibility. Do we need to rerun the recent RfC, in which yours was the only dissenting voice, here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 30 April 2014 (UTC)
Support the proposed changes, which are in keeping with MOS:LIST and improve both accessibility, per WCAG, and data granularity. (I'd prefer {{Plainlist}} over {{ubl}}, but that's a relatively minor point compared to the advantages of using either.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:17, 30 April 2014 (UTC)
Nuetral really unnecessary. If User:Pigsonthewing quote specifically where WCAG supports this, it depends. but i've seen in the past where he and User:Lil-Unique refuse to answer the bigger questions. Lucia Black (talk) 22:22, 30 April 2014 (UTC)
That's an unacceptable personal attack; and hypocritical, as I note that you have not answered the question I put to you, above; but see http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H48.html Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:33, 30 April 2014 (UTC)
Oh for goodness sake Lil-unique1, I explained in previous discussions that pure science is the only real reason to make this switch and is otherwise an imposition of something that may or may not be beneficial to any other editors.
I see the list cabal has found their way here. Glad to see Lucia Black is making perfect sense that this should not be one article at a time but rather should be applied to all of Wikipedia or none of it. Please let me know when and where that discussion starts. As far as I'm concerned, this discussion is over here. Walter Görlitz (talk) 22:39, 30 April 2014 (UTC)
      • Presumably, your "discussion is over here" constitutes a refusal to answer my request that you substantiate your claim, above; and my question about re-running the recent RfC, in which yours was the only dissenting voice. Your claim is clearly bogus; and your "cabal" comment is as unacceptable here as it was the last time you made it. The use of these list markup templates is already in MOS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:56, 30 April 2014 (UTC)
And your tired return to the MoS, that suggests using formatting that has not been proven to be better than what is currently used, is the problem. I'm sorry you don't understand the problem. Perhaps someday we can discuss this face-to-face but until then, I am not the only dissenting voice here. Walter Görlitz (talk) 01:59, 1 May 2014 (UTC)
I'm sorry you don't understand the problem. The formatting to use was established before you started using your own formatting and so the blame is on you, not on me. I'm sorry that you insist on following your own rules. Everyone prior to you was using colons to indent and then you switched to asterisks which produce bullets in an unordered list in mark-up. Don't put that on me. Cheers. Walter Görlitz (talk) 14:56, 1 May 2014 (UTC)
It is entirely on you. Your comment timestamped "22:39, 30 April 2014 (UTC)", indented with two colons, immediately follows one by Adabow, timestamped "22:37, 30 April 2014 (UTC)", and indented with an asterisk. once again, that breaks the HTML list markup and presents an accessibility barrier. Your continued passive-aggressive expressions of sorrow add no weight to your comments, and fail to deflect from the palpable falsehoods in your statements. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:17, 1 May 2014 (UTC)
I see where the problem lies. That was an edit conflict. I should have notated that. It was meant to follow this edit by Lil-unique1. Shall I move it and this entire discussion or shall I leave it where it is? Walter Görlitz (talk) 15:52, 1 May 2014 (UTC)
  • Support, broaden to {{infobox song}} and add |format= to those params requiring {{ubl}}/{{flatlist}}. I'm having a bit of difficulty with one or two editors on matters like this. --Redrose64 (talk) 22:50, 30 April 2014 (UTC)
  • Support lists for consistency, consistently, --Gerda Arendt (talk) 23:07, 30 April 2014 (UTC)
  • Oppose Per the last discussion we had on this a very short time ago and my comments there, we do not need to move to change every field in the infobox to use flatlists. They would be harder for newer editors to use, and leave it more likely for them to break the infobox by messing up a bracket, I have seen it happen many a times. Flatlists are not used throughout the encyclopedia as some claim. You can use them if you like, but that is an editor preference and should not be forced on every album article. I am on the side that sees the lack of evidence in the effectiveness of them. Where was this discussion for it to always be used in the producers field anyways? I do not remember that at all. As for the startdate template, sure why not. STATic message me! 23:14, 30 April 2014 (UTC)
those who oppose the chnages on the grounds of a lack of evidence should research data granularity and what it means. When you have read up on DG then it makes logical sense. Any tenplate which reduces the number of interruptions when a screen reader reads aloud a list improves granularity. Those opposing should also note MOS:LIST where it clearly talks about structured formats. Also, those worried about the impact on new editors need not worry as that is thr whole point of guidnace in the template document. Finally ill end by saying the changes that are being suggested improve things should someone choose to use a screen reader. They in no eay alter the experience, readability or understanding of an article for a fullsighted or able dighted individual. The changes suggested are also in line with the international stabadards for accessible articles. Those who still oppose the changes after all of the above should think about bringing it up at MOS:LIST as frankly there is already a consensus in masses that such changes are a useful and valuable modification to current practises. This is not the forum for questioning MOS → Lil-℧niquԐ 1 - { Talk } - 23:37, 30 April 2014 (UTC)
If this is really the case, you should be mentioning this to village pump to effect "ALL" infoboxes. not just the ones you're interested. with that said i'm not seeing where this has to be taken in order for readability. and thats what matters most for wikipedia. not only that, but how does it make it "less" accessible? I'm particularly not fond of the flat list in infoboxes. non-bulletined list, maybe but not really necessary. Lucia Black (talk) 23:47, 30 April 2014 (UTC)
I dont need a consensus to implement a consensus. I think your opposition to flat list is around the template using dots instead of commas? (Correct me if that assumption is wrong) the idea of asking users to use either Flat list or UBL/Plainlist is that is provides options for short lists and options for longer lists. Also, it may be the current limitations of technology that means that the flat list is the nearest we can get to an audible list. As far as i am aware, the flat list template is the only formatting that allows a screen reader to read aloud a list in the most human way possible i.e. with a pause after each item in the list, that will display the list horizontally. When one uses commas in a list, the screen reader reads aloud the punctuation thus diluting the list entries and lowering data granularity. I have never refused to answer wider questions. That is my answer to why the changes are needed. Not understanding is never a reason to oppose something. The reason for the dicussion is to get the support of editors so that it is encouraged to be rolled out. Simply ram-raiding people with changes to MOS would defeat the object of accessibiluty as people wpuldnt learn why the changes were valuable. The reason I am personally not going to village pump are very easy to understand. I was never involved in the changes at MOS nor was I originally knowledgeable about accessibility. I come from the music editor side of the fence. I went about editing articles and noticed MOS has been updated and so ive tried to ensure that music-related guidelines reflect the MOS. This template nor any other has a mandate to deviate from the MOS. This discussion is to draw attention to the MOs and worj out how best to implement it. If you have an issue with the MOS and the changes it recommends then that talk page is the forum for disucssion about how best to make lists accessible. As far as I'm concerned the MOS says lists need tp be structured and im trying to unify the way we do it in this template and others. Last time I checked, one does not require consensus to implement the MOS. It is a given that every article across wikipedia should adhere to MOS. To criticise every application of accessibility is a waste of time because it was not myself that implemented the original cjange to accessibility. I am merely conveying what the MOS says. → Lil-℧niquԐ 1 - { Talk } - 00:26, 1 May 2014 (UTC)
in the past, both you and Pigsonthewing refused to answer the bigger questions placed when i provided a compromise that offered "more" granularity, it lead you and (pigsonthewing) to prolong a discussion to being unnecessarily long just out of "preference" in the end and it never passed. But now for the more recent issues: the changes here aren't really a matter of "accessible" visually. Audible, Wikipedia has a large ammount of issues that sometimes can't be fixed no matter what.
If you truly believe you're coming from a "music editor" then you would still go to Village pump to ensure that this isn't a local consensus because this really affects more infoboxes style. Keep in mind, infoboxes haven't really been classified as "lists" (yet). On another note, if an e reader verbally says "comma", then thats not an issue within Wikipedia. Lucia Black (talk) 00:48, 1 May 2014 (UTC)
I have already pointed out that your ad hominem is unacceptable; and you are again hypocritical, in that you accuse us of refusing to answer a question, while ignoring mine in this section: "Please explain how data granularity is 'subjective'". Please answer it now. While your rather odd statement that "infoboxes haven't really been classified as "lists" (yet)" is true, the contents of some infobox fields are irrefutably lists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:13, 1 May 2014 (UTC)
I have no ignored a single question. Also, don't tell me what to do. If you ask me to answer it, i will answer, but don't demand it from me. The problem here is that theres too many i also have far more important things to do. ANd even then, its not hypocritical in the least. I've mentioned in the past that you have ignored serious questions. Using this particular situation on how i haven't had the chance to answer (yet), is not in the least.
With that said, Data granularity can be subjective by how one views it. In the end there will always be more and more things to add to "granularity".THerefore, it'll never end, or rather some people will choose to change things for the sake of data granularity, while another person wanting to change it a different way for the same thing. both involve adding more code, but in the end, its never really needed or necessary at times. Lucia Black (talk) 22:08, 1 May 2014 (UTC)
Yes, you did ignore my question; otherwise, why are you only now answering it? I haven't demanded anything from you. Unfortunately the answer you have now given simply repeats your assertion that granularity is subjective, without substantiating it. Your again repeat your claim that I have ignored serious questions; and again you do not substantiate that allegation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:35, 3 May 2014 (UTC)
Should it be encouraged/recommended to use {{ubl}} instead of <br /> in the Chronology section as well, i.e.:
This → Last album = {{ubl|''[[Incesticide]]''|(1992)}}
Instead of this → Last album = ''[[Incesticide]]''<br />(1992)
Thanks. --StarcheerspeaksnewslostwarsTalk to me 00:02, 1 May 2014 (UTC)
I don't think that's a good idea. When it comes to (for example) genres, we might have a three-item list, each item being a single genre - they are all the same type of data, so list markup is logical. But your suggestion concerns an album title and release year - two pieces of information which are not of the same type, yet are closely associated with one another: I consider them to be a single item. A single space instead of the <br /> would maintain the association of title and year; I believe that the use of <br /> here is within Wikipedia:Line-break handling#<br> - it aids clarity for sighted people by reducing the width in a position where there are three items of information arranged as a horizontal row. --Redrose64 (talk) 09:29, 1 May 2014 (UTC)
No, but they should, as proposed elsewhere, be separate parameters. That's a separate issue, though. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:13, 1 May 2014 (UTC)
This wasn't a suggestion but a question, as I've noticed the former's use on some album articles. --StarcheerspeaksnewslostwarsTalk to me 06:50, 10 May 2014 (UTC)
  • Support the purposed changes. — Status (talk · contribs) 01:03, 1 May 2014 (UTC)
  • Weak support: Most of these changes seem fine, on a whole, but I don't see them as being absolutely necessary. If editors don't want to take the time to type in the list code, or they don't want to use it, then the information can still be entered in with a comma and will still show up properly; if another editor comes along later and switches them to one of the horizontal list templates, so much the better. Therefore, I'd rather see wording like "either {{ubl}} or {{flat list}} can be used to order lists", rather than requiring it (WP:HLIST doesn't actually require those templates be used, it just says they are "available" to be used). I support using the Start Date template. "Include guidance on how to list recording locations, dates etc." I'd like to see what exactly is proposed here first before commenting on it. MrMoustacheMM (talk) 17:02, 1 May 2014 (UTC)
I would kinda support your views MrMoustacheMM's suggestions BUT I would like to add that once one of the accessible templates is added it should not be reverted. → Lil-℧niquԐ 1 - { Talk } - 21:57, 1 May 2014 (UTC)
Consistency could also be achieved by removing them from single. They're not used in the artist template for things like label or producer, but I suspect that's where the cabal will go next. Walter Görlitz (talk) 00:42, 3 May 2014 (UTC)
Do you men the cabal for improvement? If you want improvement you have to move in steps, you have to start somewhere and take inconsistency for a while. I do. --Gerda Arendt (talk) 06:41, 3 May 2014 (UTC)
Steps can be taken care of more efficiently. If we bring this issue up in Village pump, not only will you get your way, but consistency will be established that much quickly. but thats if it passes. Lucia Black (talk) 06:54, 3 May 2014 (UTC)
They already claim that there is proof that it is better, but only anecdotes that some user claims it's better for screen readers, but no evidence has ever been provided. The village pump is the correct place to take this.
No, the cabal of editors who want lists used rather than correct punctuation and who offer not proof that lists are better only that LIST says it is. Walter Görlitz (talk) 08:40, 3 May 2014 (UTC)
Once again, Walter, you are using ":" (part of a definition list) to indent under an initial "*" (part of an ordered list). That's breaking the underlying HTML structure and harming accessibility. As to your suggestion of removing these list-structure templates from Infobox Single, I shall remind you again that in the recent RfC which decided to use them, yours was the only dissenting voice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 3 May 2014 (UTC)
The general use for asterisks, which are converted to bullets, is to make a point. They are only useful in indenting unordered lists. If there's a MoS or policy to use them that way then I will. If it's your own preference, lump it.
There was one other dissenting voice, but the point is not the louder the crowd, the more correct they are. I can point to many times in history where the crowd was wrong. The crowd did not provide any proof that it is better only a general feeling that it may be better and anecdotal reports that it does something better, a report I have not seen either. Walter Görlitz (talk) 20:33, 3 May 2014 (UTC)
Your esoteric (and far from general) view that the purpose of using asterisks (which in Wikimarkup form an ordered HTML list) is to make a point does not concur with HTML standards, WCAG guidelines, nor our own MoS and accessibility guidelines. You would, of course, be welcome to cite a Wikipedia: page refuting this, if such a thing existed. It does not. You may refer to MOS:LIST, WP:ACCESS and WP:TALK for guidance on how to use them correctly. You will recall that Wikipedia works by consensus, not your unsubstantiated assertions of authority. As to the previous RfC, there were ten "yes" !votes, and only one "no". That one was yours. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:44, 3 May 2014 (UTC)

We seem to have seven "support", one "neutral" and one "oppose". It's time to implement this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 3 May 2014 (UTC)

For the sakeof not gaining WP:LOCALCONSENSUS, we should put this in village pump fro broader reasoning, if you get your way, it will be implemented in "ALL" infoboxes, not just this one, which will benefit you more. Lucia Black (talk) 21:02, 3 May 2014 (UTC)
I've never heard of anyone going to Village Pump to implement what is already present in the MOS - a consensus to implement a consensus is illogical and absurd. This discussion is NOT about gaining a consensus to implement a change (the change is already supported) it is about how best to implement the required changes. Like I've said numerous times before, the consensus is for some form of structured listing to go in place of all lists where present in articles. The options are predominately {{flat list}}, {{ubl}}, {{plainlist}} or {{hlist}}. As such I would like to add the following wording for each field - "it is strongly encouraged that multiple items are dlisted using either {{flat list}}, {{ubl}}, {{plainlist}} or {{hlist}}. Pigsonthewing, Lucia Black, Walter Görlitz what do you think of the proposed wording? → Lil-℧niquԐ 1 - { Talk } - 01:29, 4 May 2014 (UTC)
Because reaching consensus for one specific infobox or a specific range of infoboxes instead of all of the ones that could hypothetically apply sounds more deceiving then anything else, it looks more like you're trying to warm up to the idea until it eventually goes to all the infoboxes rather than going directly to all the sources.
We still dont even know if infoboxes count as list, and going to village pump will solve this matter MUCH quicker. The MOS isn't 100% clear on infoboxes, and if you're asking in this specific infobox, you should be asking about all of them, all at once. which is why village pump is there, even if you claim it is meant for new ideas, which technically it is. Lucia Black (talk) 01:34, 4 May 2014 (UTC)
The fact that you think an infobox doesn't count as a list is ridiculous. The infobox contains lists of producers, recording locations, recording dates etc where more than one of each item occurs. The suggested changes immediately above would strongly encourage the changes without forcing editors to have to use the templates. However, once implemented the templates should be left. It is because there are different ways of implementing the MOS that individual projects must decide which particular list templates should be used. You can harp on about Village Pump as much as you want but it doesn't change the fact that this discussion has been opened and this discussion should determine the outcome of what happens in the infobox. As far as I am concerned, a change to the MOS was made to implement accessibility, I notified the project with this discussion and others that we should be updating our infoboxes according to the MOS. We can discuss as a project what form of implementation we need. Other projects are doing the same. Please stop digressing with the Village Pump argument. Also, if you really disagree with the templates take it up at the MOS for lists because frankly (particularly aimed at Walter Görlitz) because objecting to implementing what is already consensus is a waste of everyone's time. → Lil-℧niquԐ 1 - { Talk } - 01:45, 4 May 2014 (UTC)
the infobox is a template, not all templates are lists, if you want to do the proper thing, then going to apply this to all infoboxes all at once is appropriate thing to do. just because you care about this particular infobox, doesn't mean you shouldn't do the proper thing. Lucia Black (talk) 02:00, 4 May 2014 (UTC)
The proper thing is to enforce the MOS whereby there is a template here which doesn't not adhere to the MOS. The infobox itself is not a list, but it contains lists. Or are you now going to claim that where there is more than one item listed in the field this is not now a list? You cannot object to a change on the basis that it is not happening in other projects. Whether other infoboxes are or are not implementing the change is rather irrelevant as an argument along that line is a case of WP:OTHERSTUFF. → Lil-℧niquԐ 1 - { Talk } - 02:05, 4 May 2014 (UTC)
This template is an infobox...but you want to apply it to just one. if you want to have any reasoning to work, you would try to get this done to all infoboxes. not one. Lucia Black (talk) 02:12, 4 May 2014 (UTC)
You didn't answer my question. Are you claiming that there are no lists within the template? No one has said this template is not an infobox. I am merely saying that within the template there are lists and hence those lists need to be structured according to MOS:LIST. We have a variety of options which is what this discussion should be about. To be frank, not giving your support because I am not conducting a universal implementation is stupid IMO because at the end of the day what is right is not dependent upon the majority. You're argument sways between saying saying, this template doesn't contain lists and therefore MOS:LIST doesn't apply and between WP:OTHERSTUFF - only the first of these arguments would be valid grounds for objection but you seem reluctant to accept that this template doesn't contain lists. Not surprising because that would be accepting something which is not true. That's all I have to say for now. I am interested to see if there are any other views. → Lil-℧niquԐ 1 - { Talk } - 02:19, 4 May 2014 (UTC)

i'm suggesting that not all of them are lists, for possibly just 2 or 3 links. i'm saying that other people would consider it differently, or see things we might not see in this just one discussion for just one infobox when in reality what you are proposing affects other infoboxes as well. Broader consensus for broader issue. It doesn't make sense at all to apply a broader issue and apply it for only one infobox.

For example: Navboxes use of hlist and that was done universally, not one navbox at a time. Lucia Black (talk) 02:37, 4 May 2014 (UTC)

Right so you accept that the infobox contains lists (even if it is just in one of the fields or if it happens sometimes but not in all occurances), you also accept that MOS:LIST requires all lists to be structured (it recommends, {{plainlist}} or {{hlist}}) so that just shows that your objections are invalid. Yes you have a point for us to consider about whether this needs to be pumped at the village but that doesn't take away from the fact that in your own words you accept that the infobox contains lists and lists are subject to the MOS. Thus this conversation is quite circular if you keep objecting on the basis that infoboxes are not lists. → Lil-℧niquԐ 1 - { Talk } - 14:59, 4 May 2014 (UTC)
WP:FLATLIST. "In situations such as infoboxes, a single-line list may be useful—in this case". And the first example used is a comma separated list, not a flatlist, plainlist or other list. You accept MOSLIST requires all lists to be structured and it recommends comma separated lists so that just shows that your objections are invalid.
So if you want that MOS to be changed, take it to the village pump.
Thus this conversation is quite circular if you keep objecting on the basis that infoboxes must follow MOSLIST when they currently are. Walter Görlitz (talk) 16:17, 4 May 2014 (UTC)
it says maybe useful. Where we have the producer field and a number of entries we advocate the use of template mark-up. My point is that for consistency other fields should be marked up too. It offers comma seperated lists as ONE option but again further down it advocates that templates like {{plainlist}} and {{ubl}} are preferred. Again MOS doesn't need to be changed. A discussion was already had that the producer field would benefit from such changes as the lists can be quite long. I don't see valid opposition for extending this to other fields for visual consistency. → Lil-℧niquԐ 1 - { Talk } - 16:27, 4 May 2014 (UTC)
So it may be useful either way. And the argument has been presented that if you want consistency, seek it at the appropriate level.
The argument I have made is that consistency can be achieved by removing flatlists and plainlists from the smaller list of articles and return to comma separated lists. We would have consistency that way as well. I too agree that a larger audience should be consulted. Walter Görlitz (talk) 16:40, 4 May 2014 (UTC)
And do stop going against the MOS and stating that plainlist or ubl is preferred for infoboxes when we both see that comma separated lists are perfectly acceptable to the MOS. It is intentionally misleading to do so. Walter Görlitz (talk) 16:42, 4 May 2014 (UTC)
You have already been referred to MOS:LIST and WP:ACCESS, more than once; and more than once have I reminded you that " in the recent RfC which decided to use them, yours was the only dissenting voice". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:18, 4 May 2014 (UTC)

Jumping on down past all the arguing: "it is strongly encouraged that multiple items are dlisted using either {{flat list}}, {{ubl}}, {{plainlist}} or {{hlist}}" – This is too strong of wording, and I don't support it. Again, WP:HLIST does not require the use of those templates, WP:FLATLIST explicitly says it's OK to use plain-text comma-delimited lists, and we should not be strongarming editors into using them. I would support wording like this: "Multiple items can be listed using either {{flat list}}, {{ubl}}, {{plainlist}} or {{hlist}}." Or, "It is recommended, but not required, that multiple items be listed using either {{flat list}}, {{ubl}}, {{plainlist}} or {{hlist}}." (I personally prefer the first of those two options.) MrMoustacheMM (talk) 18:55, 4 May 2014 (UTC)

MrMoustacheMM quite the contrary. This is an open discussion and everyone's opinion is appreciated. The thing is that both WP:FLATLIST and [[MOS::LIST]] are both part of the MOS. I think you've found the perfect compromise to the situation.... along the lines of one of your two suggested changes to the the guidance. I personally prefer the encouragement of the template structures as they are better for screen readers (something we've proven with anecdotal evidence.). If the majority agree I would like to change the template guidance to read Multiple items can be listed using either {{flat list}}, {{ubl}}, {{plainlist}} or {{hlist}}.. → Lil-℧niquԐ 1 - { Talk } - 19:30, 4 May 2014 (UTC)
To summarize the whole argument, my point was to try and convince others that if we use one of the template formats because there are multiple items in one particular field, that format should be applied universally across the template. I think MOS clearly shows that in large lists there is clear evidence that list structures improve accessibility. The whole point of the discussion was to try and see if others agreed that if you use {{hlist}} or {{plainlist}} for one field, then in the interest of visual consistency the list structures should apply to all other fields. Although you're suggestions are great and along the right lines they don't address the inconsistency. → Lil-℧niquԐ 1 - { Talk } - 19:33, 4 May 2014 (UTC)
(Sorry about the above comment. I have removed it.) I had an idea: Since the "bullets vs. commas" debate is part of this larger debate, could the various list templates be modified to include comma-delimiting? I'm thinking along the lines of Template:Start date's "df=y" parameter: "commas=yes" (or "commas=y"). It would have to be explicitly enabled, so making this change would not modify any currently-used instances of the templates, but it would allow lists to have the appearance of being comma-delimited, which is supported by WP:FLATLIST. Not owning a screen-reader, I don't know if that would still cause it to say "Item one comma item two comma item three" or not, but if it does work with screen-readers, maybe it's a solution that can get more editors behind these proposed changes? Then, if every list template in every field in the infobox uses "commas=y", they will be visually consistent and work better with screen-readers (again, assuming it reads properly on screen-readers). MrMoustacheMM (talk) 19:46, 4 May 2014 (UTC)
The general issue with screen readers are that many exist and not all handle punctuation the same way. Some will read aloud punctuation others don't. For some reason the delimiter in the {{flatlist}} is the preferred punctuation mark that all screen readers pause at rather than read aloud. I have no doubt that if commas could be universally read aloud as a pause then we probably wouldn't be having a debate. No one in this discussion is advocating that commas are incorrect or that a dot is grammatically correct in terms of delimiting a list, rather we're working within the realms of how we can visually delimit a list in way that doesn't impact granularity when read aloud by screen reading technology. → Lil-℧niquԐ 1 - { Talk } - 20:23, 4 May 2014 (UTC)
We can't appeal to all screen readers just becomes its too redundant to verbally say "comma" just for the sake of a comma. Lucia Black (talk) 22:33, 4 May 2014 (UTC)
Two things, one I could support MrMoustacheMM's first suggested wording. Nothing wrong at all mentioning it could be used. Secondly, if some screen readers read the comma in the infobox, would they not also read commas in the prose? STATic message me! 03:32, 5 May 2014 (UTC)
This isn't just about the pronunciation of commas; it's about as of navigation; and about data granularity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:08, 5 May 2014 (UTC)
Lucia, your comment can't be parsed in English; what are you trying to say? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:08, 5 May 2014 (UTC)
Lucia's comments can be parsed in English: simply remove, the idea is that since screen readers treat punctuation differently, why are we catering to them at all. Perhaps a less ad hominem way of approaching this would have been to write, "I can't understand what you wrote. Can you please rephrase it?", rather than assuming the role of every man or the Übermensch? I didn't think so. Walter Görlitz (talk) 14:54, 5 May 2014 (UTC)
There is no ad himinem, because I described a problem with the comment, not the commenter. What, do you think, does "...just becomes its too redundant..." mean? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:06, 5 May 2014 (UTC)
So, "Lucia, your comment can't be parsed in English" isn't directed at the editor? Walter Görlitz (talk) 19:30, 5 May 2014 (UTC)
Support: Many vertical lists are misrepresented by use of <br /> and there is no doubt that they should be replaced by {{ubl}} or {{plainlist}}. We don't require editors to do that, but we do encourage them and I am certain that such replacement improves an infobox or table. The documentation of many well-developed templates encourages this. If we can cope with list templates in this way for vertical lists, we can do the same for horizontal lists, so I don't find the 'it's too complicated' argument convincing.
We already know from Graham87 (probably our most prolific blind editor) that marking up lists with proper list markup makes the experience of using the commonest screen readers a much nicer experience. Of course, nobody expects us to do that in running prose, where commas are expected by screen readers. But when lists are used in small fragments as in infoboxes, there is not the same context. If we read Producer: John Smith, The Stompers, Bob Brown, Bling, how do we know whether the producers were two individuals: John Smith (who is identified as part of a group called "The Stompers") and Bob Brown (who belongs to the group called "Bling"} - or four credits for the two individuals as well as the two groups? If we mark it up properly as a list in the infobox, we immediately distinguish between two producers:
  • John Smith, The Stompers
  • Bob Brown, Bling
and four:
  • John Smith
  • The Stompers
  • Bob Brown
  • Bling
If you talk to Graham87, who uses a screen reader for all his editing, he'll tell you that visually impaired users become accustomed to poor markup, but appreciate proper semantic markup as it allows them more options in parsing and navigating lists. If we use commas to separate two list items, it's no big deal and using {{flatlist}} offers only a small improvement. But as the list grows, the advantage of using {{flatlist}} or {{hlist}} increases rapidly for the visually impaired.
I can see no reason why we shouldn't encourage editors to mark up flat lists in infoboxes with {{flatlist}} or {{hlist}}. Although I wouldn't want to force editors to use that markup, I would expect that when another editor replaces commas with a list template, that is seen as an improvement, and that reverting such an improvement would be considered as disruptive.
Suggestion: In the interests of finding consensus, perhaps we might consider that the wording in the documentation would probably benefit from reading something like (for example) "If there is more than one producer, the names can be delimited by commas or preferably {{flatlist}}, especially for lists of more than a couple of items."
That would allow editors to create naive lists without problem, but encourage other editors to improve those lists without having to argue this same case on every page. --RexxS (talk) 12:56, 7 May 2014 (UTC)
I would support that wording (although no need for underlining). MrMoustacheMM (talk) 16:59, 7 May 2014 (UTC)
I don't support the wording. Comma separated is fine. If the consensus is to move to letting editors know that they may use an embedded template (flatlist) or the hlist, the wording should be: "the names must be delimited. To delimit the items, use commas or {{flatlist}}." The use of "can be" is wrong. They must be delimited. Also "couple of" is not professional and vague. Walter Görlitz (talk) 17:25, 7 May 2014 (UTC)
@MrMoustacheMM: The underlining is simply my use of the <ins>...</ins> to indicate that I had inserted text into the current wording. It wouldn't appear in the documentation.
@Walter Görlitz: Comma separated is ok for a couple of items, but list markup is better in infoboxes where there is no surrounding context. I believe there is a clear majority of editors commenting who wish to see {{flatlist}}, but I am nevertheless attempting to try to find a wording that could gain a fuller consensus. I am certain that we need to encourage the use of list markup, not merely allow it. I would hope that you could now accept that there is little support for your position and that you would be content to try to find a compromise that we could all live with. I would prefer the vagueness of "a couple of items" and I was only indicating "something like", but if you insist, let me suggest this instead:
  • "If there is more than one producer, delimit the names with commas or preferably {{flatlist}}, especially for lists of more than two or three items."
That should meet your objection to "can be" (the current wording) and to "a couple". --RexxS (talk) 18:11, 7 May 2014 (UTC)
Support RexxS compromise. It is better than the current guidance. To answer Walter about commas being fine, in academia does one settle for a pass when one is capable of so much more? No! One strives for the best possible result, much like this is a achieving beyond the minimum standards and really adding value as well for disabled people as well as adding accessibility and usability for navigation and data granularity! → Lil-℧niquԐ 1 - { Talk } - 22:54, 7 May 2014 (UTC)
Prefer UBl over flatlist in an infobox. it'll look most unnatural, and most inconsistent with the other infoboxes wikipedia has. Lucia Black (talk) 23:00, 7 May 2014 (UTC)
Agree with Lucia Black on this one. Bullets are stupid. To answer Lil-unique1, This isn't academia, it's real life, however in both academia and real life one goes with proper grammar, which is commas. In graphic design, one tries to make things look pretty and make themselves look different for the sake of looking different. We are none of those. In fact, this supposed minimum standard still has not one shred of empirical proof that it is better, only anecdotal evidence that one editor with a screen reader prefers it! Walter Görlitz (talk) 00:43, 8 May 2014 (UTC)
If you don't like bullets, turn them off in your own stylesheet - the ones you see from class "hlist" are not there in the wikitext or the html; they are just how your browser displays the list. Your dislike of something mustn't be allowed to stop improvements to the encyclopedia for everyone who uses a non-visual user agent. There is no "proper grammar" in an infobox; we use phrases, single words and fragments of sentences in there to save space - just as we do in tables and vertical lists within normal text. It is nonsensical to insist on "proper grammar" for one aspect that you don't like, when the entire construct within the template doesn't follow grammatical rules. It matters not a jot that you can't see the benefit of WCAG's H48 - create lists of related items using list elements. Anybody else can read that web-wide standard and understand that there is added value for the visually impaired - as well as solving the issue of the ambiguous commas being used in apposition within a list (that you have failed to address). There is, in fact, not a shred of empirical proof that commas have any advantage at all, other than an irrational dislike by one editor who doesn't even use a screen reader for reading Wikipedia. --RexxS (talk) 08:38, 8 May 2014 (UTC)
If theres an option to not see them, then why makea big deal out of it? PLus, i still strongly suggest we bring this in WP:VILLAGE. if you wont do the right thing, i will. Lucia Black (talk) 08:43, 8 May 2014 (UTC)
Indeed - why make a big deal out of it? In any case, there is sufficient consensus here to implement the original proposals at the top of this section, which I am happy to support if my compromise suggestions don't help you. If you want to change the current consensus guidance on using list markup for lists outside of running prose at Wikipedia:Manual of Style/Accessibility #Vertical lists and Wikipedia:Manual of Style/Accessibility #Horizontal lists, then that talk page would be the right place. I'd be content to debate it at Village pump as well, of course, so feel free to raise the issue. --RexxS (talk) 08:53, 8 May 2014 (UTC)

Ubl over flatlist, because not everyone knows how to change the visual options. and even then, its not necessary to have that option avaliable. Ubl should be more than sufficient. But....since no one wants to do this the correct way, i guess i have to. Its a real shame that it has come to this though.

I didn't ask the proposers to put this in WP:VILLAGE because i'm hoping they go against it, but if this reason is valid, why bring it up for a specific infobox when it applies to "ALL" infoboxes. a greater good could be done if you try to change all of them, not one. WHich i know a specific editor here has the agenda of providing this issue one infobox at a time. Lucia Black (talk) 09:04, 8 May 2014 (UTC)

After all this neither Walter nor Lucia seem to understand the purpose of {{flatlist}}, no one anywhere is trying to suggest that commas need to be replaced with bullets or that bullets are a better punctuation for a list. At the moment, {[tl|hlist}} and {{flatlist}} are the only mark-up we have for horizontal lists that are ALWAYS read correctly by every single screen reader technology. The stylesheet you have in place on Wikipedia determines how that "bullet" is displayed. But, if you actually read the arguments above you would see that the changes made are for the benefit of screen reader technology. It is not about one reader, search the web and you'll see stacks of research about screen readers and their treatment of punctuation. A list where the reader consistently reads out the word "COMMA" between every item in the list dilutes one's understanding of the list. Also, I have no objection to using {{ubl}} where it is appropriate but it makes more sense to use horizontal lists as this prevents ridiculously long info boxes from appearing in articles. As for Walter's comments about this not being academia but real life, academia is real life. I think its a sad state of affairs when people settle for whats okay in any part of their life when there alternatives which are better. Also, I never took this proposal to WP:Village because there was previously a consensus here that multiple items in the producer field can be delimited by {{flatlist}} and this proposal was about extending the existing consensus. If you do take it to Village Lucia, I will be happy to comment and offer my opinion. Anyway, there is a consensus here for extended use and I think it should now be implemented. → Lil-℧niquԐ 1 - { Talk } - 11:28, 8 May 2014 (UTC)
A) We're not opposing just because we think flatlist isn't as good as ubl. After all I've compromised that we don't add flatlist or ubl for just 2 or 3 items in a single parameter. But as the vote for using ubl as aboslute over flatlist is based on the perspective of the common reader or someone who just reads Wikipedia articles at a regular basis who dont know hwo to change the visuals to not see it, and also notice the inconsistency between WP:ALBUM's infobox and the rest. albums and other would definitely conflict with the consistency of the style of the others. why not use ubl over Flatlist? i mean, why make a bigger deal than it needs to if one is preferably more consistent with the current setup? And the point wasn't for me to put in so you can post your opinion (as if we're debating) but to bring it so that you can bring a "better" change, if its truly for the better. Lucia Black (talk) 12:04, 8 May 2014 (UTC)
Isn't Template:ubl meant for vertical lists? As these lists are horizontal, if any template is being used, it should be a horizontal list. Vertical lists will just make the infobox too long (tall?). Or am I missing a horizontal use of UBL? MrMoustacheMM (talk) 18:39, 8 May 2014 (UTC)
Depends, if it gets too long for certain reasons, we can only list the most relevant. Lucia Black (talk) 22:19, 8 May 2014 (UTC)
Disagree, we shouldn't be excluding information from the infobox wherever possible. The Hlist template would have minimal impact on the size of the infobox, forcing people to only use UBL would mean most infoboxes become too long. → Lil-℧niquԐ 1 - { Talk } - 19:10, 20 May 2014 (UTC)
Others do it, such as tv series where there are too many specific directors for specific episodes. Same for producers and artists. depending on who is the overseer and the one who contributed the majority, should be listed in the infobox, while usually tracklist can cover the specifics. Infobox can't cover it all you know, and the general idea is to only list key information. Lucia Black (talk) 19:15, 20 May 2014 (UTC)
We can keep the existing length of the infobox by correctly using HList as they're horizontal lists in the infobox and improve accessibility without causing any major inconvenience or readability issues or we could incorrectly use UBL for all fields, increase the length of infoboxes resulting in key information being removed and improve accessibility. Seems like a no brainer to me. → Lil-℧niquԐ 1 - { Talk } - 19:19, 20 May 2014 (UTC)
i still believe true consistency matters over data consistency. if we want this to work we should do it for all infoboxes, not just the ones you care about. Which i doubt someone will ignore other infoboxes when their arguments are based on all infoboxes in general or at least affect all of them. if you disagree, i ask whats stopping you form making a point for "all" infoboxes in a broader consensus? Lucia Black (talk) 19:22, 20 May 2014 (UTC)
i will only get behind hlist, if all infoboxes accept hlist as the standard alongside ubl. but for now, ubl seems the least intrusive. Lucia Black (talk) 19:26, 20 May 2014 (UTC)
Objecting something because its not widely adopted doesn't mean what you're objecting is wrong or a bad proposal. That's the exist principals that WP:OTHERSTUFFEXISTS talks about avoiding. What you think is not intrusive i think will be the exact opposite, it will require much more consensus and discussion and result in an incorrect template being used to appear a small minority who dislike Flatlist / hlist. Speaking of which, I still haven't seen you bring up objections about the bullet being used to delimit lists on that template's talkpage. I think myself, yourself and Walter have exhausted ourselves in this discussion. There's not really much more to be said really. I accept your right to object the proposal and (Walter's) but there does seem to actually support for the proposal and it looks likely to go ahead. → Lil-℧niquԐ 1 - { Talk } - 19:32, 20 May 2014 (UTC)
WP:OTHERSTUFFEXIST would work in the sense that not every infobox is the same, and although in design maybe, but in structure it is not. so it doesn't apply. Thats the very reason why "hlist" was accepted among navbox at a broader scale and almost instantaneously. I dont see why infoboxes have to go through localconsensus to make the changes one claims will benefit theirs and not others (which you're not claiming, but for the sake of argument, that's what you're defending) What i think is intrusive is what i will continue to believe. ubl serves enough without really damaging the infobox or intrusive. hlist makes things appear more like a navbox. Lucia Black (talk) 19:39, 20 May 2014 (UTC)
Like I said, I accept your right to object. I disagree, infoboxes share general things in common, they're all effectively a giant verticle list, comprising of individual horizontal lists. Do you not accept/ see issues with forcing people to remove content from infoboxes? Its an unnecessary amount of work for a change that is negligible because a small minority of users dislike the delimiter used in horizontal lists. → Lil-℧niquԐ 1 - { Talk } - 19:43, 20 May 2014 (UTC)

Again, the best example i have right now is the navbox/hlist. its something that was done unilaterally and it was forced, but many accepted it, and adding information onto navboxes has become far more efficient. Now....they could have done it with only one navbox and then maybe canvass that all over. but no, the issue was tackled all at once.

Infoboxes can do the same, for the exact same reason. if we're only talking about one infobox and your reasoning isn't based on this specific infobox, just infoboxes in general, than this is nothing but mere localconsensus. And not all infoboxes are horizontal lists, and not all of them have to be. And even then, the issue of providing the key details in an infobox and none of the unnecessary smaller details is a no-brainer as well. Lucia Black (talk) 19:53, 20 May 2014 (UTC)

Unnecessary smaller details is separate issue. Its something not being discussed because at present no one has felt that its an issue elsewhere on the talkpage. Its also the first time you have mentioned the that as a reason for opposing Hlist in this discussion. It could be interpreted as an attempt to divert the discussion but I am going to assume good faith. It is a separate issue to whats being discussed above and if you genuinely feel like this discussion aside, its an issue feel free to start a new discussion and I'll happily engage with yourself over reviewing infobox content but I am certainly not going to let it divert from the main issue here which is approving the use of Hlist for the horizontal lists which appear in the infobox. And so far, your argument of intrusion is limited to yourself though I suspect one or two other people may argue that too and to be fair, its a limited argument and probably won't detract from the consensus that is practically already formed above. → Lil-℧niquԐ 1 - { Talk } - 20:03, 20 May 2014 (UTC)
Although Walter Gorlitz has not voiced his opinion as strongly as i have, he has indeed agreed with me on the hlist issue. so its not really me against the world.
keep in mind, my vote is still to use ubl entirely...if you want me to make a new discussion, it'll have to be before this one reaches consensus. Lucia Black (talk) 21:01, 20 May 2014 (UTC)
My objection is to using lists because there is not proof that there is any benefit to using them over the current method. So in reality, I have been more vocal, in a sense, against it. Walter Görlitz (talk) 22:47, 20 May 2014 (UTC)

Just wanted to weigh in again that I am 100% against using vertical lists for something where some form of horizontal list should be used (ie all the proposed parameters). This will make the infobox far too long, for no benefit to the infobox or the articles that use it. MrMoustacheMM (talk) 18:54, 22 May 2014 (UTC)

I am with User:MrMoustacheMM on this one. I would be 100% against the use of UBL universally. Hlist should be used as they're horizontal parameters and that is the outcome of this consensus discussion. The consensus was already approved for the use of Hlist/Flatlist for the producer field last year I believe and above, its clear that with the exception of Walter and Lucia, other users support a change in wording to include hlist in other fields. I would add that I propose to add that Hlist/flat list or commas can be used but with fields where there are more than a few entries, Hlist/flat list is preferred. That way, people don't have to use them, but wherever they have already been implemented it would be seen as disruptive to remove them. → Lil-℧niquԐ 1 - { Talk } - 20:38, 22 May 2014 (UTC)

Often times, they get too long because most of the info is not "key" info. Rather than mentioning the key production staff and writers, it tries to mention. So like i said, if you want to bring another discussion about that, i would happily bring it up, however it would have to wait before closing this one as it related to this. Either way, Walter Gorlitz has a point, theres no real proof of this being any benefit to the reader over the current method. Lucia Black (talk) 13:56, 25 May 2014 (UTC)

Release Date

I think the format for release date should change. I have experienced this issue on many album pages. The current convention is to show the "first" release date. I think this causes inconsistency with other sources. Instead the OFFICIAL release date should be used. The official release date isn't country specific but rather dependent on the artist and recording studio that released the album. A current example is the album The Hunting Party by the artist Linkin Park. The release date is set to June 13th, 2014 but according to all the official sources of the artist(their official web site, their Facebook page, their YouTube channel, etc) and Warner Bros Records (the recording studio of the album) the release date is June 17th, 2014. It can cause confusion when people see one date everywhere else and come to the Wiki page and see a different date. To reduce confusion the official date should be used regardless of the first release date or release date of any one country. --Jimv1983 (talk) 20:49, 16 June 2014 (UTC)

It should be the earliest referenced date, but if the consensus on the article wants a different date, it's not unreasonable to have it be that date. It should not display both dates though. Walter Görlitz (talk) 20:55, 16 June 2014 (UTC)
Why should it be the earliest date instead of the official date? That makes no sense and just causes confusion. --Jimv1983 (talk) 02:10, 19 June 2014 (UTC)
Why was it released before the "official" date? If there's a reason to release it before the "official" date, then that's the earliest, legal date of release. I think the confusion comes not from claiming that some date is an "official" date rather than listing the earliest release date. I can think of a few instances where the album was officially released before the official date because it was leaked or was otherwise made available and so the "official" date was changed officially. I can also think of multiple instances where an album was released in one market, then another and then another (Australia before the US and then Europe). Each was the official release for that market. So, as long as there's agreement to use one date over another, use it. If you can't come to an agreement, use the earliest date even if it's no the official date. Walter Görlitz (talk) 04:22, 19 June 2014 (UTC)

All dates are "official dates". Release dates are different depending on the country. Linkin Park is an American act, thus those things you mentioned are obviously going to use the American release date, but that doesn't change the fact that it was released earlier in some countries. I don't understand why this is so hard for people to understand. — Status (talk · contribs) 04:26, 19 June 2014 (UTC)

Oppose I do not agree with this. Listing the earliest and first-known release date works just fine with information boxes. It's just fancruft editing where editors want the U.S. date first, but then that is also discrediting countries and territories that received the album first. Why shouldn't they count? livelikemusic my talk page! 12:39, 19 June 2014 (UTC)

Comment This isn't so true in the era of iTunes downloads, but before the digital age the US and Canada were usually the LAST places in the world where an album was released, due to their peculiar habit of releasing records on a Tuesday where almost everyone else releases their records on a Monday. So the 'official' release date announced by Linkin Park here only refers to their domestic market: it would have already been released almost everywhere else in the world before June 17, 2014, so we can't use that date as "the release date". Richard3120 (talk) 12:53, 19 June 2014 (UTC)

Parent genres, subgenres, and issue of redundancy

Since this issue arose at The Beatles (album) recently and seems like it can arise in other articles, I thought it'd be best to bring it up here rather than at individual articles: If the sources cited in an article characterize the album's music as a "parent" genre (eg. rock, jazz) and also a subgenre (eg. folk rock, soul-jazz), is it redundant to include both in the infobox? Dan56 (talk) 04:10, 19 July 2014 (UTC)

IMO, redundancy doesn't apply here, only due weight given to how common a viewpoint such as "rock" or "folk rock" is among the sources cited in the article. In the case of The Beatles (album), a source like Michael A. Katovich ("pop, rock, and folk-rock" being his characterization of The Beatles) is one viewpoint that should be differentiated from David N Howard (who includes "hard rock")--Katovich may have felt that "folk rock" is different enough from "rock" to name it alongside it and "pop". If "Folk rock" signifies only elements of "rock", then "Rock" is a different view of the music altogether. In any case, I don't feel either the parent or sub-genre should be removed simply because it looks redundant on a superficial level. If both a parent genre and a subgenre are equally common viewpoints among the sources available on the album, then both should be included in the infobox's genre parameter. Dan56 (talk) 04:09, 19 July 2014 (UTC)
Seeing to it that genres for songs and singers/groups are generally include just parent genres or subgenres of said parent, I don't see why it would be any different for albums. If users dispute which genres to use for an album, it would be best to leave the field blank. There's never any harm in having it blank. SNUGGUMS (talk · contribs) 04:25, 19 July 2014 (UTC)
I think we should encourage editors to leave the genre parameter blank for complex albums that have a wide variety of songs, with many genres expressed. The album genre parameter should never be a rote collection of all the genres found in the individual songs. Instead, the album genre should be something that can be said (and has been said) of the entire album. Otherwise, tell the reader the genre details in the article body. Binksternet (talk) 04:38, 19 July 2014 (UTC)
I completely agree, Binksternet. SNUGGUMS (talk · contribs) 04:43, 19 July 2014 (UTC)

Box set

Please change this type to "boxed set", which is the correct term, and create a redirect. Radiopathy •talk• 14:50, 26 July 2014 (UTC)

 Not done. Before changing this template you might first want to get consensus to move the main article. From that page it seems that the two terms are equivalent. De728631 (talk) 17:17, 26 July 2014 (UTC)
Correct term for what? A boxed set is a specific type of compilation album. Walter Görlitz (talk) 17:40, 26 July 2014 (UTC)
Radiopathy seems to prefer "boxed set" over "box set" which is being displayed by the template. It's also the main article's title (box set) where his/her move request was recently turned down. De728631 (talk) 17:57, 26 July 2014 (UTC)
Radiopathy, both the OED and Collins dictionary allow "box set" as an acceptable term – if these aren't valid sources, what is? Richard3120 (talk) 19:09, 26 July 2014 (UTC)
The Cambridge dictionary allows for the "box set" variant as well, but acknowledging that a mispronunciation, or at the very least a lazy pronunciation, has slipped into common usage does not mean that the mispronunciation is correct English.
BTW, a "boxed set" is a collection of multiple items, such as CDs or vinyl records, which are boxed and sold as a single unit - or set. I have no clear idea just what a "box set" might be - maybe a set of boxes; gee, you can never have too many boxes. I will never be convinced that WP:COMMONNAME is preferable to actual English. Radiopathy •talk• 00:49, 27 July 2014 (UTC)
But it IS actual English, according to the dictionary: Collins defines the phrase "box set" as "a collection of items of the same type, packaged together for sale in a presentation box". Which is what I meant - if the most reputable English dictionaries confirm it to be proper English and a correct definition, are you saying that all the dictionaries are wrong? Richard3120 (talk) 10:01, 27 July 2014 (UTC)

Example image

Instead of Nevermind as an example image, wouldn't a light coloured album help indicate the fact the the image will automatically have a border added to it? - X201 (talk) 08:38, 9 September 2014 (UTC)

Album licensing

It'd be great if we could list the licensing for albums. e.g. Public domain, Creative commons, artistic work, etc. Any thoughts? Corevette (talk) 20:43, 29 October 2014 (UTC)

It sounds like something that might only appeal to a niche audience, similar to listing pressing details of every single album's release (like this, for example). I'm not sure it has much wide-spread appeal, unless it's a notable example that could be elaborated on like Nine Inch Nails' The Slip. Fezmar9 (talk) 22:30, 29 October 2014 (UTC)
Agree with Fezmar9. I have more than 5000 albums in my collection and not one is anything other than a full copyright. Walter Görlitz (talk) 04:07, 30 October 2014 (UTC)

Re-release singles

I'm just wondering why in the Template:Singles section it says "Do not include singles that were added as bonus tracks on a re-release of an album." I've seen a few articles where this is the case, and I'm not sure what the issue with doing so is. I find the infobox becomes quite lacking of information if the re-release singles are not included. Usfun8991 06:21, 3 November 2014 (UTC)

Shouldn't it be linked to recording studio and music venue same as "Genre", "Label", "Producer", etc.? Also "Producer" to "Producer(s)" as was deemed suitable for the single infobox?--Ilovetopaint (talk) 02:18, 7 November 2014 (UTC)

Also, quite often, an album will be recorded at multiple studios, so maybe that ought to be pluralized as well...--Ilovetopaint (talk) 14:01, 7 November 2014 (UTC)

Italic title

Is the template page supposed to have an italic title? I was going to fix it until I saw that {{Auto italic title}} is being used in the doc page. I didn't know if it was there for a reason or not. RadioKAOS / Talk to me, Billy / Transmissions 10:33, 28 January 2015 (UTC)

Parameter for unfinished/aborted/non-existent/fictional album type?

For a very long time there has been a minor but longstanding edit war from various users on the article Smile (The Beach Boys album) due to the fact that the Smile album doesn't actually exist. Even though it was envisioned as a studio album, and the infobox reflects this, the wording is kind of strange and misleading: "Studio album partially recorded by The Beach Boys". The thing is, there is no studio album called Smile, Smile was just an idea for an album. So it should rather state something to the effect of "Aborted album by The Beach Boys". However, that "breaks" the template, so it can't be done as of this moment.--Ilovetopaint (talk) 00:50, 2 February 2015 (UTC)

Use other. Most albums of this sort never meet WP:GNG so there's no other category for this. Walter Görlitz (talk) 01:23, 2 February 2015 (UTC)

"Executive producers" parameter re-proposal

There is no consensus for a change. See Samwalton9 (talk · contribs)'s comment here at WP:ANRFC:

I don't personally see any clear consensus here. There were only a handful of editors in the discussion and each seems to have a different solution. Sam Walton (talk) 12:45, 13 February 2015 (UTC)

Cunard (talk) 00:42, 14 February 2015 (UTC)

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.

There has been plenty of discussion in the past regarding how to treat the existing "Producers" parameter in situations where there are several (10+) producers credited on a given record. There has been talk of perhaps just listing executive producers in the template for these instances, although some editors expressed concern with issues with older albums where no executive producers were assigned, and instead just featured many general producers. I've been doing some work on The Pinkprint recently, and like I Am Not a Human Being II (which prompted the original discussion if I remember correctly?), there are so many producers listed it makes the infobox almost too large for comfortable navigation. If it is overwhelming on my large laptop screen, imagine how busy this would look on a mobile device. My suggestion is that an "Executive producers" parameter is introduced to substitute the existing "Producers" field when applicable. If there are executive producers specifically listed on any given album, these individuals would be recognized with the new field, and if not, then all of the general producers would be listed in the original parameter. Neither of these templates would be used alongside each other, and would instead be used one over the other. I would find this particularly helpful with present-day pop and hip hop music; artists usually collaborate with multiple unique producers on each song and when this number is multiplied by at least ten songs per record, it would be much more concise to just list the few executive producers that are usually recognized as the most important, or so the back sleeve of a physical album would suggest. Any thoughts? WikiRedactor (talk) 20:54, 22 December 2014 (UTC)

I think adding another parameter for the executive producer(s) of an album, while would be resourceful, may cause unrequited fancruft editing. Also, the way they are listed on I Am Not a Human Being II should not be used. It clutters the infobox, which are meant to provide an over-view of material. If people want specific information, they should look within the article and see that the information is outlined (hopefully). I do, however, agree with Walter Görlitz that only an album's producers should be included, not specific producers for each and every single song produced for an album (if that is what they meant in their statement). Most albums have a surplus of producers and can cause an over-fill of information within an infobox; maybe executive producers are the only ones who should be listed, period? livelikemusic my talk page! 23:14, 26 December 2014 (UTC)
@Livelikemusic: I would support replacing producers with executive producers in the infobox. By the general nature of the position, executive producers pertain more to the record as an entire unit; it would seem as though producers has just become a field in the infobox to list every producer that has dipped their toes in the project. WikiRedactor (talk) 22:29, 30 December 2014 (UTC)
You have confused modern pop production with album production. Most albums are still produced by only a few people. Modern pop albums have production on a song-by-song basis and are an anomaly. I will never agree to removing producers for executive producers. Walter Görlitz (talk) 05:56, 31 December 2014 (UTC)
All the more reason to add an executive producers field for situations where this would be most useful, and leaving the producers parameter for circumstances where it is applicable. They would both have their own unique purposes that would be useful in different scenarios. WikiRedactor (talk) 16:44, 1 January 2015 (UTC)
  • If the number of producers is too large to comfortably list, why not leave a note to see the appropriate section in the article's body? This is sometimes done in film articles. You don't have to compulsively list every last bit of information in the infobox. NinjaRobotPirate (talk) 00:23, 2 January 2015 (UTC)
  • I would support this. Many modern albums, particularly in the pop and hip hop genres, have become a game of "let's fit as many hitmakers on one record as possible". Often times, this results in an excessive laundry list of anyone who had any involvement on any song (see Britney Jean), rather than who has primary oversight over the overall sound of the album. Sometimes, executive producers are even credited as "album producers" where the individual songs saw many different producers (I want to say I've seen this crediting on the back cover of My Love Is Your Love).

    I would suggest, however, only doing this on a case-by-case basis unique to each album. On albums with one producer, or a reasonably small list of individual song producers, go ahead and list everyone out. In instances such as The Pinkprint or Britney Jean, it may be more helpful to just list executive producers, or omit the field entirely. –Chase (talk / contribs) 20:40, 2 January 2015 (UTC)
  • Exactly. As the sentiment made by Chase, a lot of times, artists gather "hitmakers" for their album, which can cause clutter in an infobox, which is meant to house and over-all review of information. I would say either list the executors of the album, or whatever the album sleeve, and / or metadata lists as the album's producers. As in the case of The Pinkprint, there is much an overload of information. Or simply omit the entry. livelikemusic my talk page! 23:04, 2 January 2015 (UTC)
I would italicize it. It could work, but something about it does seem off, and I can't put my finger on what it is. livelikemusic my talk page! 01:37, 3 January 2015 (UTC)
I do see what you're saying; part of me is wondering if it seems off just because it's different from what we've done for so long? I'm not quite sure though. I've rolled it out Bangerz and Pink Friday: Roman Reloaded – The Re-Up just so we can see how it looks on a couple other articles for a sample. WikiRedactor (talk) 01:42, 3 January 2015 (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.


Request for comments

A Request for Comments about the use of album covers is currently on at Talk:Shades of Deep Purple#Cover dispute. It would be greatly appreciated to have more opinions on the matter. Lewismaster (talk) 21:23, 31 May 2015 (UTC)

Genres and flatlists

I have noticed a trend popping up on a handful of album articles (example), namely the use of {{flatlist|}} instead of commas to separate genres. On the guideline, for that infobox field, it still says: "The one or more music genres that the album reflects, delimited by a comma should be listed here." Should I let it slide or inform the user who insists on using flatlists on other articles they edit? They have also used it for track listing credits, but that may not be necessary to discuss here. Mac Dreamstate (talk) 16:36, 31 January 2015 (UTC)

Ehh.. looks like I'm a bit late to the party. Mac Dreamstate (talk) 16:44, 31 January 2015 (UTC)
Yes. To recapitulate, two or three items should be separated by commas. More than three, should use a list. Walter Görlitz (talk) 23:40, 31 January 2015 (UTC)
I think {{flatlist}} is preferable to using commas whenever there is more than one item listen: I think it looks neater and, also, commas, to me, imply that there is an order of importance placed on the items in terms of the order in which they are listed. Lachlan Foley (talk) 00:41, 17 June 2015 (UTC)
Nice to know what you think. It looks like a 1985 Mac OS user gone amok. It's really ugly. That's not an opinion either. Walter Görlitz (talk) 06:00, 17 June 2015 (UTC)

Genre section

I propose that a code such as <!-- In order to add genres to an infobox, they must be cited in-article by reputable sources. --> be built in to this template's 'Genre' section as default text – and also {{Infobox single}}, {{Infobox song}} and any others that may apply. Lachlan Foley (talk) 00:45, 17 June 2015 (UTC)

Support - I think having guiding placeholder text like what you proposed would be a great idea that would (hopefully) limit the edit-warring and excessive lists of questionable genres. I generally add my own warning along those lines on articles I create or work on, but it would certainly be easier to have it pre-coded across all album and song articles. Songsteel (talk) 04:43, 24 June 2015 (UTC)
Retracting my support in light of the good points raised below. Helpful idea in theory, but probably could not be implemented in a way that would take advantage of its potential benefits. Songsteel (talk) 15:56, 24 June 2015 (UTC)
Oppose – For many reasons: (A) hidden comments regarding genre are largely ignored anyways; (B) if someone actually does provide a source, it's either not a reliable source and you have to explain what that means, or the source only supports the claim that one song kind of sounds influenced by the genre they're claiming the entire album is; (C) if you're suggesting it should be added here the same way <!-- {{Start date|||}} -->, it's not going to spread because people don't copy & paste the album template from here, they copy & paste it from other articles where it may or may not be used correctly; (D) if the template is really full, a hidden comment will get lost, so it's not that people are ignoring it, they're straight up not even seeing it. I really don't see this change making any measurable impact. As long as there is a place for anyone to freely tinker with a genre that someone disagrees with, it's going to happen no matter what's in their way. Fezmar9 (talk) 05:10, 24 June 2015 (UTC)

Blank cover fields

Template:Infobox album#Cover specifies that the value "blank" should be used to avoid adding an article to Category:Album infoboxes lacking a cover. Alakzi, I believe your change broke this functionality, and any articles using the "blank" value now point to File:Blank. hinnk (talk) 18:34, 27 June 2015 (UTC)

Fixed. Alakzi (talk) 19:01, 27 June 2015 (UTC)
Thanks! I think the reason you didn't see any articles using the field just now was because it wasn't widely used before, and KylieTastic (and probably other editors) had been fixing the red links. hinnk (talk) 19:20, 27 June 2015 (UTC)

Syntax for chronology parameters

according to the template data on the documentation page, the syntax for the chronology parameters is 

| Last album = ''[[Last album name]]''<br />(YEAR)
| This album = '''''This album'''''<br />(YEAR)
| Next album = ''[[Next album name]]''<br />(2004)

so I was surprised to find that many articles are using {{unbulleted list|Last album name|(YEAR)}} which is completely wrong since these aren't lists. so, I created a tracking category, Category:Pages using infobox chronology parameters with plainlists, and there are currently over 900 pages in the category. it would be great if users like User:Synthwave.94, who are actively changing the syntax to {{unbulleted list}} could comment why list markup is being used instead of a break tag. and yes, I read WP:UBLIST, and saw nothing about replacing all <br /> with {{unbulleted list}}. Any help with cleaning up Category:Pages using infobox chronology parameters with plainlists is also appreciated. Frietjes (talk) 13:25, 27 June 2015 (UTC)

I agree that we should not use {{Unbulleted list}} in those fields. You should make a WP:BOTREQ to have them cleaned up! Thanks! Plastikspork ―Œ(talk) 19:04, 27 June 2015 (UTC)
UBLs should be used and the breaks should not have had the XHTML version. Walter Görlitz (talk) 01:51, 28 June 2015 (UTC)
Lists are used for lists. This is not a list; it's just a linebreak to push the year on to a new line. Alakzi (talk) 01:56, 28 June 2015 (UTC)
Walter Görlitz, the br tag is supported in XHTML, see http://www.w3schools.com/tags/tag_br.asp . You just have to make it self-closing. I agree with Alakzi, that these are clearly not lists. Plastikspork ―Œ(talk) 02:06, 28 June 2015 (UTC)
Which is why I called it the XHTML break tag. I understand. (WP:ASSUMECLUE). The issue is that XHTML is now a disfavoured technology. HTML 5 is the new favoured technology and it does not support the break that way. With that said, if we go with UBL, it doesn't matter. Walter Görlitz (talk) 04:29, 28 June 2015 (UTC)
Walter, <br /> and <br> are both valid in HTML 5. It does matter to use HTML elements appropriately. Alakzi (talk) 11:12, 28 June 2015 (UTC)
Wrong. http://www.w3schools.com/tags/tag_br.asp says only <br> is valid. Browsers will interpret the wrong one, but they prefer the correct one. Walter Görlitz (talk) 01:17, 29 June 2015 (UTC)

From the HTML 5 specification:

6. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.

Hope this helps. Alakzi (talk) 01:51, 29 June 2015 (UTC)

That's not the case here. The standard is a simple break. XHTML is dead. You've lost. Walter Görlitz (talk) 02:11, 29 June 2015 (UTC)
Sometimes I just don't know what to say. Alakzi (talk) 02:17, 29 June 2015 (UTC)

"Singles taken from..." parameter coding issue

Is anyone else noticing that the "Singles taken from..." parameter is off in its coding; the header aligns completely to the left, instead of being centered as it once was. Also, the spacing between singles and their release dates seem to be more condensed and a bit cluttered. Was there a change on the document pertaining to these parameters? livelikemusic my talk page! 15:44, 1 July 2015 (UTC)

I've fixed the header alignment. The spacing hasn't changed, as far as I can tell. Alakzi (talk) 16:00, 1 July 2015 (UTC)
Excellent, that was changed back! And see here (sorry for off-site upload), the singles are squeezed together, when before there was some space between releases and their release dates. livelikemusic my talk page! 16:10, 1 July 2015 (UTC)
Well, that's ridiculous. I've restored the default leading. Alakzi (talk) 16:36, 1 July 2015 (UTC)
Again, excellent! Looks much better! Thank you again! livelikemusic my talk page! 16:55, 1 July 2015 (UTC)

Studio parameter

What should be entered after "Studio = " Just the name of the studio? Studio and city? Studio, city and country?

Also, are there any guidelines for size of text in the infobox? Piriczki (talk) 02:39, 16 July 2015 (UTC)

Piriczki, see WP:FONTSIZE. Frietjes (talk) 14:57, 2 August 2015 (UTC)
If there is an article about the studio, I'd say a mere wikilink to that page should suffice. If there is no article, I suppose name and city are alright, or just name and country if different from the artist's country of origin. This is an infobox so let's it keep it short. De728631 (talk) 00:58, 3 August 2015 (UTC)

Chronology

Is there a verdict on whether the chronology includes all albums, including live and 'best of' albums? There is a mixture out there and a proliferation of best of albums really messes the chronology up in some cases. Dennisthemonkeychild (talk) 09:45, 4 May 2015 (UTC)

A different question: Shouldn't the heading link be to the artist's discography page (if there is one) instead of a repeated link of the artist's page found in the above heading? --Musdan77 (talk) 04:46, 27 June 2015 (UTC)
Dennisthemonkeychild: See [1], where a consensus was established in 2010 that the chronology chain should include all albums. It's not something I agree with, and I'm grappling with a tricky issue at the moment over multiple versions of a compilation album by The Mutton Birds: released in different countries under different names and with different track lists.]] BlackCab (TALK) 23:39, 24 August 2015 (UTC)

Modern criteria for what constitutes a single?

Someone else asked this question on the talk page for Template:Singles, but never received a response. In the modern era, what constitutes a single released for an album? Before the advent of digital music, it was a lot easier to determine this, as single releases produced a physical artifact, usually a vinyl record. However, with most (thought not all) songs from an album being available for download individually, what constitutes a single? Does it need to be sold separately on iTunes and other digital music stores? (Example: the original release of Prince's "Breakfast Can Wait") Does it need to be released separately in a physical format (vinyl, CD, etc.)? (Example: the forthcoming Sam Smith song "Writing's on the Wall") Is it a matter of what the record company promotes to radio and streaming services? If so, how would one determine that? It's easy enough to leave the Singles template out of the infobox, but for the sake of argument, what is the appropriate criteria for inclusion? Thank you. --GentlemanGhost (converse) 23:15, 21 September 2015 (UTC)

You likely won't get a unified response from either Wikipedia or third-party sources because, as you note, the digital age has really mucked up that definition. As such, the following response reflects my personal opinions. I've been writing and editing articles with this rough definition of what a single is in 2015: a single is a type of release that's much like a studio album or EP that can be legally obtained independent of another release (if one exists) that has its own release date, catalog number, cover art, etc. that could be digital or physical or free or paid. For several decades, there's been two senses of the word "single" -- a literal one and a more conversational one. The literal one is much like the one I've outlined above, while the more conversational definition uses "single" to describe popular songs and songs promoted in any, way, shape or form. Think of the relationship between the use of the word stomach to literally refer to the organ that digests your food, and the more conversational usage of the word that kind of generally refers to your abdominal area. In the digital age, the more conversational use of the word "single" is used to describe just about everything by just about everyone, which makes it even more difficult. Personally, since an encyclopedia is a fairly literal medium, I don't think Wikipedia should be defining songs as singles using the more conversational definition. But like I said, you're not going to get a unified answer, so whoever comments after me is probably going to disagree :) Fezmar9 (talk) 03:40, 22 September 2015 (UTC)
A single should be a song released for commercial charting purposes, not simply a promotional song. Walter Görlitz (talk) 04:04, 22 September 2015 (UTC)
Thanks! --GentlemanGhost (converse) 00:45, 16 October 2015 (UTC)
You might like THIS. I would like to emphasize that just having a video, in and by itself, does not create a single. Also the radio dates are not called "release", but rather "serviced to radio", "Radio add date", "sent to radio", etc.—Iknow23 (talk) 05:50, 16 October 2015 (UTC)

I always thought a good place to a link to the discography article for the musical artist in question would be in the little album chronology header. right now, that is just an additional link to the musical artist's article. what do you guys think? link to the discography article? wouldn't that be helpful? Tangy 303 Mamet Sauce (talk) 22:21, 29 January 2016 (UTC)

I could support that. Walter Görlitz (talk) 07:19, 31 January 2016 (UTC)

Last album and next album fields don't work

In the Last album and Next album fields, the entry in the "This album" doesn't appear on the reader's unless you specify blank entries such as "". Please sort it out. You can see my point in this edit. Jodosma (talk) 18:51, 18 May 2016 (UTC)

It's been like that for years—as long as I can remember, or 2008 to be exact. If the field for This album is the only one that applies, with no albums before or after, then I was told (many years ago, and I agreed with the editor) that the discography section becomes unnecessary until further album articles can be entered. Introducing blank entries to force This album to show up isn't the right way to go about it, as WP guidelines widely discourage hidden elements unless absolutely necessary. Mac Dreamstate (talk) 19:36, 18 May 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_album/Archive_10&oldid=1134869279"