Template talk:Infobox Musical artist/Archive 2

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents

Name field problem

Did someone update the part of the infobox with the name? It looks fine for most artists, but for some (say, with Japanese names, like Ayumi Hamasaki for example) it's cutting the field off. Would someone mind looking into it? --Shiori 18:26, 9 November 2006 (UTC)

Can you be more specific? I don't see any cutting off. The contents of the name field seem to render exactly the same for me whether it's inside or outside the name field. That is to say, I see "Ayumi Hamasaki (浜崎 あゆみ?)" displayed just fine, and it looks the same here as it does in the infobox. I don't know if that's how it's supposed to be rendered, since my Japanese is very limited, but if there's a problem, it doesn't seem to be related to the infobox. (And in answer to your first question, no, the name field has not been updated or changed in, well, ever.) -- Xtifr tälk 23:46, 9 November 2006 (UTC)
Sounds like a system-specific problem. You could take a screenshot, upload the image to one of the free hosts (such as imageshack.us) and then link it here. Prolog 23:52, 9 November 2006 (UTC)
The problem seems to only be happening in IE. Screenshot (Cropped to make it easier to see). It's fine in Firefox. -- Shiori 22:39, 9 November 2006 (UTC)
I tried with IE (6.0) now and the same thing happened, so it's definitely an IE-related bug and not just on your system. Prolog 16:02, 10 November 2006 (UTC)
I think I've tracked down the cause. IE doesn't seem to like Template:Nihongo, which adds the small question mark and wikilink to Help:Japanese after the Japanese spelling (as shown on Xtifr's post above). Prolog 16:26, 10 November 2006 (UTC)
Ah, that makes sense. Thanks for solving the puzzle, Prolog. I didn't think this infobox could possibly be doing anything complicated enough to confuse even IE—and sure enough, it's not. Has someone reported the problem on at Template talk:Nihongo? Xtifr tälk 05:20, 11 November 2006 (UTC)
I don't know how to fix it, so I left a note at Template talk:Nihongo. Prolog 18:09, 12 November 2006 (UTC)

Reply to question from Template talk:Nihongo

It is caused by the fact that an HTML sup tag is used to create a superscript ?-mark. It is a peculiarity of the default IE stylesheet that this causes the line-height to be slightly larger. Since the designer of the infobox didn't account for that and tightened the line-spacing, text is cut off.

I would like to take this opportunity to ask you not to try to solve this problem, but to instead refrain from using the kanji spelling in the infobox. You see, the name in roman letters + the name in kanji is, for most artists, too long to fit in the caption. That, and I don't think that such information is needed more than once in an article. We would already have the kanji, and possibly Hepburn, in the lead, so why duplicate in the infobox title? Shinobu 05:59, 16 November 2006 (UTC)

I think that is a good point about not using Template:Nihongo in the infobox, especially when the template is already in use in the first sentence of the introduction. – Heaven's Wrath   Talk  00:21, 17 November 2006 (UTC)
Fully agree. I'll see if I can think of some appropriate brief comment to add to the docs to cover not just this, but other potentially problematic templates in the name field as well. Xtifr tälk 00:53, 17 November 2006 (UTC)
I must agree as well. There's already an overuse of kanji (along with excessive capitalization of English) in quite a few Japanese music-related articles, despite the last paragraph in WP:MOS-JP. Using the nihongo template within the infobox would just encourage this sort of overkill. Cyrus XIII 00:15, 1 December 2006 (UTC)

Field Names

It's too bad the fields in the solo and Band templates are not consistent with the field names here. Makes more work for a switch.

Is there a tool that would automate switching solo and Band templates to this one? *Spark* 03:35, 16 November 2006 (UTC)

You might want to talk to Kingbotk about that. He developed some plugins for AWB, available here. I have been replacing them by hand, so I would be interested if he could make one. – Heaven's Wrath   Talk  00:14, 17 November 2006 (UTC)
I have an idea for making it easier, but don't have the time to try it juuuuust yet. When I do I'll report back here on it. *Spark* 01:25, 17 November 2006 (UTC)

Well, I ran a test and am awaiting some answers regarding template substitution. If you look at User:Sparkhead/TemplateTest and User:Sparkhead/BandTest (which was a copy of the infobox code on the Marillion page) when I edited it, I replaced {{Infobox_band with {{subst:User:Sparkhead/TemplateTest and nothing else, saved. It ran the subst, and it almost worked. There are some other issues. I'm no expert with template syntax, nor with AWB plugins. If someone else a little more knowledgeable about template subst wants to mess with it, feel free to do it right in my user space. *Spark* 14:23, 17 November 2006 (UTC)

  • I wrote a little utility that will convert templates. I'm using the "View Source With" plugin for Firefox to launch it. Which means I have to go to the page, hit edit, hotkey the "view source with" for my util, hit "show changes" to make certain all works correct, then hit save. Anyone know of a faster way to edit the wiki on a large number of pages? If I could go to the "what links here" page for the band template, and simply launch tabs for 20 links at a time, I could convert them all in a short time. I'm not familiar with AWB but will check it out to see if it can launch my utility. *Spark* 20:51, 17 November 2006 (UTC)

Documentation transclusion

Browsed Wikipedia:Template doc page pattern and it seems like an excellent idea, so I've implemented it on this template. I don't see any ill effects and it should reduce impact of doc changes. Apologized if I've missed anything, but looks like pages using it are still evaluating it properly. *Spark* 23:10, 16 November 2006 (UTC)

Sounds fine. Would help if we need to protect the template in the future. – Heaven's Wrath   Talk  00:17, 17 November 2006 (UTC)
Indeed, I've seen this done on other templates, and had been thinking it might be a good idea, but hadn't gotten around to doing anything about it. We might even want to go a little further, and split it up a bit so that important pieces can be transcluded elsewhere (e.g. the docs on the background field, which a lot of people find tricky), but this is an excellent start. Kudos! Xtifr tälk 00:47, 17 November 2006 (UTC)
Thanks. Glad it worked smoothly. This is not a template I make a major edit to without more than a bit of hesitation. *Spark* 01:29, 17 November 2006 (UTC)

I redirected the talk page back here, as I think it makes more sense to have all the discussions in one place. I did add it to my watchlist, but I don't think that everyone who wants to keep track of discussions should have to do so. Xtifr tälk 01:45, 17 November 2006 (UTC)

Individual band members?

What is the appropriate type for an individual band member? It appears that group_or_band would be for articles on the band, not its members. Joltman 13:56, 17 November 2006 (UTC)

It depends on what they do within the band. If they sing and play an instrument, use solo_singer and if they only play an instrument, but do not sing, use non_vocal_instrumentalist. – Heaven's Wrath   Talk  01:50, 18 November 2006 (UTC)
Doesn't that kind of contradictory to list a band member as a solo singer? Perhaps we should either change the wording or create a type just for members of a band? I think that a type just for band members would be best, because why should a singer get their own color but every other band member be the same? Joltman 12:44, 20 November 2006 (UTC)
I think you're correct. There should be a "band_member" category with the same color as the band color. Maybe add the wording "Member of /band/" up top, like singles have "from /album/" on them. *Spark* 13:01, 20 November 2006 (UTC)
What ended up being called "Solo_singer" was meant for use by all articles pertaining to a singular singer, whether they perform with a group or without one. Instrumentalists (meaning people who never or very rarely sing) should be tagged with the instrumentalist color. --FuriousFreddy 22:59, 21 January 2007 (UTC)

Centering Subsection Headers

If you check any usage of this template, the name of the artist is centered at the top of the template, but the subsection headings (Background info, Members, former members, etc.) are left justified. I believe they should all be centered (just looks better IMO). Comments? *Spark* 23:01, 17 November 2006 (UTC)

They are all centred in my browser.--NeilEvans 23:06, 17 November 2006 (UTC)
I don't see any explicit centering code in the template. Check Rush (band) for an example. The subsection headers are left justified in my browser (Firefox). *Spark* 23:12, 17 November 2006 (UTC)
There lies the problem. I am using Internet Explorer. If I knew how to change the code I would.--NeilEvans 23:21, 17 November 2006 (UTC)
Well, I'm using Firefox, like Spark, and it's centered for me. Furthermore, the explicit centering code is the part where it says 'style="text-align: center;"', which it says before each of the headings. Spark, I don't know why it's not centered for you, but I strongly suspect that the problem is on your end, somehow. Does anyone else see the headings left-justified? Xtifr tälk 23:50, 17 November 2006 (UTC)
Very very strange - I logged out and viewed the page. Everything is centered correctly. Logged back in, left justification. I have a few css/javascript changes, looks like something is mucking with the pages. *Spark* 00:22, 18 November 2006 (UTC)
Found it. My Preferences->Misc->Justify Paragaph was checked, and overriding the centering code. Don't know if there's a way to fix that, but that was the cause. *Spark* 00:46, 18 November 2006 (UTC)

Colors

Can someone pretty please change the pink color that gets assigned to instrumentalists? Of all the proposals above, I don't see that anyone is actually in favor of that color. It's killing me. --Aguerriero (talk) 18:15, 20 November 2006 (UTC)

Sorry, I have lately been involved in the Esperanza MfD, so discussion has died out. Hopefully we can get a vote going soon. – Heaven's Wrath   Talk  21:46, 20 November 2006 (UTC)


Colour selection

While I agree with the idea of colour-coded boxes, and particularly like the khaki scheme used for the 'solo artist' box, I'm not sure cyan is the best candidate for 'band' infoboxes. To my eyes it doesn't travel well, in that while it looks ok and appropriate for pop bands etc, it generally looks too 'soft' for most alternative and rock bands. Also cyan is a colour that clashes easily, IMHO.

I'd like to know what others would think of using more a neutral and muted colour, such as "darkseagreen" or "#cccc99". Sorry If im coming late to this discussion and you've already been through the issue, but its an important one. Thanks - Coil00 22:54, 30 October 2006 (UTC)

I agree that the current colors bear further discussion. Note that they're a legacy from the first, defunct, Musicians WikiProject. I strongly disagree with any suggestion that genre or style should be a consideration (I know you didn't say that, but I want to make it clear up front). I definitely think some of the current colors are oversaturated, and would be less obtrusive if they were more subdued. Members of the Guitarists WikiProject have expressed their dislike for the pinkish-red used for non_vocal_instrumentalists, and I tend to agree with them. Gross changes (i.e. switching from cyan/blue completely) will affect huge numbers of articles, and should only be done after consultation with many other WikiProjects that will be affected, but more subtle changes, such as reducing the saturation or making minor adjustments to the tint, should be fairly non-controversial. The darkseagreen, IMO, is much too dark, much too saturated, and, well, green.  :) I actually made a psuedo-template over the weekend that can be used to help this discussion (based on something I saw at the albums wikiproject), but it's not quite ready to go. But I definitely think it's about timme to start this discussion. Xtifr tälk 23:41, 30 October 2006 (UTC)
I acknowledge that you didn't contradict me, but to be clear, my wish is that the colour selected is: 1. neutral, 2. does not 'imply' upon the article it is used for, and 3. is unlikely to clash with the band image used in that article. (We're really saying the same thing here.) I'm not sure a desaturated blue will deliver this, but am open to suggestion.
What we are effectively talking about is a 'picture frame', meaning the colour should be as unobtrusive as possible. My own preference would be for a light brown, grey or green (hey, I like green!), but if you're making up mocks, great. Maybe we can put together a few templates (I'd need help on this), and try for a consensus. Anyway, thanks for the quick reply! - Coil00 00:00, 31 October 2006 (UTC)
I also agree that we should try for agreement from all projects, and, given the number of pages affected, should lobby wide, getting as many views as possible before a decision is made. - Coil00 00:44, 31 October 2006 (UTC)
I agree that the current cyan colour is not very good in terms of aesthetics, although my real gripe is having it as a background colour for the title bar. Precious few infoboxes have this, and it when rendered it results in many infoboxes (in particular those that use band logos as names) looking stupid. Toning down the colour would be a good start, but I would like to see a simultaneous removal of background colour for the "name" field - it the broader scheme of things it does not serve any purpose. DJR (T) 02:37, 31 October 2006 (UTC)
I took this comparison template for WikiProject Albums. Just copy the code an you can add your new suggestions. This will allow us to better see the differences between colors. (also, see this dicussion for color ideas) – Heaven's Wrath   Talk  02:56, 31 October 2006 (UTC)
Proposal #0
solo_singer khaki ===> solo_singer new
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist new
non_performing_personnel lightgreen ===> non_performing_personnel new
group_or_band lightskyblue ===> group_or_band new
cover_band plum ===> cover_band new
classical_ensemble paleturquoise ===> classical_ensemble new
temporary darkgray ===> temporary new

As the user who created the original color scheme, I should point out that the colors were not selected for decoration, but for cataloguing purposes. I had three requirements in mind when selecting the colors: (1) make them obviously different from one another, and (2) make them natrually bright, but not overly saturated. Upon re-evaluation, new colors wouldn't be a bad idea, and the template colors is easily adaptable (never realized just how...wrong a choice that red really was, especially for the "guitarist jock" set. I just needed somethign that wasn't one of the other hues and...that's what I ended up with). So long as functionality and purpose are not compromised. Also, not to be a drag, but geez...aren't there more important things to worry about on Wikipedia than what color your favorite band's article's infobox is going to appear? (And to the person who said that infobox colors serve no purpose -- they indeed do, as they allow quick and easy identification of various musical act types before one jumps into the article. It is an organizational mechanism). --FuriousFreddy 05:46, 3 November 2006 (UTC)

To reply to the dismissive comment above: it's not just my 'favorite band's infobox' that's effected, but all band's infoboxes on Wikipedia. Surely, the visual presentation of hundreds of articles is worth tiring people with. Coil00 23:31, 3 November 2006 (UTC)
Yes, visual presentation is important, but in no way are any of the color options truly garish or inconvenient (or, at least, certainly not as garish or inconvenient as the original album infobox colors, or the colors that were originally to accompany this infobox). While changing the colors is certainly not a wholly objectionable activity, I just think it might be more important to press for putting this much energy into improving the overall quality of music articles on Wikipedia, and also to make sure the infoboxes are being used properly in the first place, verses color selection. But that's just my opinion, and I'm neither pushing for or against any changes. --FuriousFreddy 02:37, 5 November 2006 (UTC)
There has been a fair amount of negative feedback about the current colors, and many instances of people resisting the use of this infobox because of the colors. For that reason, I think it's worthwhile exploring some alternatives. This is not what I'm spending all, or even most, of my time on, but it's something I'm keeping an eye on, and I hope to get it resolved before long so I don't have to spend any more time on it! :) Xtifr tälk 02:59, 5 November 2006 (UTC)

Proposed colour selections

Proposal 1

Yeah, Heaven's Wrath has obviously been looking in some of the same places I have.  :) I made it into a psuedo-template, though, which is even easier than copying HW's whole table. Just fill in the colors (or colours if you prefer) in order. (A good place to start to find possible colors is at Web Colors). Here's a quick suggestion:

Proposal #1

solo_singer khaki ===> solo_singer khaki
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist SandyBrown
non_performing_personnel lightgreen ===> non_performing_personnel lightgreen
group_or_band lightskyblue ===> group_or_band LightSteelBlue
cover_band plum ===> cover_band Thistle
classical_ensemble paleturquoise ===> classical_ensemble paleturquoise
temporary darkgray ===> temporary LightGrey

I really like the LightSteelBlue. It's much closer to a neutral grey, but still contains enough blue to be obviously colored. I'm not as sure about the SandyBrown, but I do think it's an improvement over the lightcoral (almost anything would be). Xtifr tälk 09:58, 31 October 2006 (UTC)

Comments

  • I like this selection of colors because it keeps a variety of colors and mutes them at the same time. I also think the lightsteelblue is a very general color and would look good for all bands. Thistle is close to lightsteelblue, so maybe we should find a new color for cover bands (or keep the old). – Heaven's Wrath   Talk  23:29, 31 October 2006 (UTC)
  • This is a good proposal, as it retains something of the hues of the original scheme while making them less saturated. --FuriousFreddy 05:46, 3 November 2006 (UTC)
  • This is an improvement and even keeps much of the colour info for nearly-blind and colour blind persons, but I still think that lightgreen and sandybrown are too strong. I also seem to be the only one to have a problem with paleturquoise? I'd much prefer AntiqueWhite or some other more neutral colour. Prolog 19:50, 4 November 2006 (UTC)
I share your paleturquoise concern ;) Would be happy with AntiqueWhite as suggested, or, not wanting to push my luck, #cccc99 as in option 2 below. - Coil00 20:00, 4 November 2006 (UTC)
Nice to know I'm not the only one, although colours do show differently to each eye and monitor. I agree with #cccc99 as a colour for classical ensembles. Prolog 20:06, 4 November 2006 (UTC)
Just a tought, but I'd be in favour of broadening the scope of classical ensemble to also include composers and conductors. I'll give it some tought and maybe raise it as a seperate thread. - Coil00 20:13, 4 November 2006 (UTC)
Antique white is extremely similar to khaki, to the point where some users will not notice a dicernable difference --FuriousFreddy 23:41, 4 November 2006 (UTC)
Possibly, but some of the light-brownish colours listed on web colors should make a contrast high enough, so it wouldn't be mixed up with khaki. Prolog 13:30, 6 November 2006 (UTC)

Proposal 2

Ok good, this is a handy template for comparing diff options. I've gone for #cccc99 for bands; as I was saying color should be muted, unobtrusive and mix well with other colours appearing in the band photos.

Proposal #2

solo_singer khaki ===> solo_singer khaki
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist SandyBrown
non_performing_personnel lightgreen ===> non_performing_personnel lightgreen
group_or_band lightskyblue ===> group_or_band #cccc99
cover_band plum ===> cover_band NavajoWhite
classical_ensemble paleturquoise ===> classical_ensemble paleturquoise
temporary darkgray ===> temporary LightGrey
- Coil00 22:02, 31 October 2006 (UTC)

Comments

  • The problem I have with this color selection is the similarities between the colors. I do not think I could tell the difference between the colors if they were alone in an article. (Does that make sense?) The goal is to have a set of colors that are easily distinguishable from each other. – Heaven's Wrath   Talk  23:34, 31 October 2006 (UTC)
  • That does make sense, I've changed "PaleGoldenrod" back to "lightgreen" accordingly. - Coil00 23:47, 31 October 2006 (UTC)
  • The #cccc99 is a little too close to, um, babypoo brown for my tastes. :) --Xtifr tälk 08:32, 1 November 2006 (UTC)
Mmm, 'too green' (quote), 'too brown' (paraphrasing)..! Thanks for you honesty anyway Xtifr ;). I can see it's going to be difficult to agree a move away from blue, but that's ok too; it's a matter of taste, and taste is always going to be subjective. I'm not particularly married to either of the colours I've suggested - what I'm looking for is one having a framing effect, similar to the khaki of the solo singer box. To use these words again - muted. neutral. unobtrusive. compatible. And those blues are just not such colours. But your own suggestions are welcome.
On a side note, perhalps the height of the coloured bars could be reduced, might help negate the imposing effect they currently have.- Coil00 00:09, 3 November 2006 (UTC)
The colored bars should not be reduced in height. The main title needs to be its larger size for obvious reasons (when this template becomes populated, it can appear long and monotonous -- offsetting the title prevents the entire thing from being a homogenous mess), and the other bar is to re-emphasize the color and to match the album and singles infoboxes. --FuriousFreddy 05:46, 3 November 2006 (UTC)
  • I'm with Xtifr, I guess. The band colour should be something easier, more neutral and suit better to Wikipedia's current layout, since "group_or_band" is and will stay the most popular one. Prolog 20:00, 4 November 2006 (UTC)
  • That's ok, I've since supported Xtifr's suggestion for the band color below. The brown is probably more suited to classical composers or ensembles, as I've mentioned above.
  • My concern re the bar height stands. Maybe not so much with the title bar, but both the 'Background information' and 'Former members' bars have a lot of space between the edge and text. Also, do we really need a separate bar for former members? - Coil00 20:10, 4 November 2006 (UTC)
    • About the "Former members" section, it's good that you brought it up. Former members isn't so crucial information that it would need to be in the infobox. On Iron Maiden, there's 18 (!) of them, and the box has sort of lost its purpose and become a long list instead. Prolog 20:28, 4 November 2006 (UTC)
      • This has already been debated above, but I know what you mean - had a similar problem with Mayhem a few months back. I'd say in cases like these former members are best kept to a seperate section at the end of the article. However, for most bands former members is a valid infobox subsection. My point is that it's not one that warrants a third colour bar. - Coil00 21:00, 4 November 2006 (UTC)
        • The Fall is the supreme example of an out of control former members section. And it grows week by week! - Coil00 21:05, 4 November 2006 (UTC)
        • I wan't joking! [1] - Coil00 00:10, 7 November 2006 (UTC)
          • "Former members" was something that was debated long ago, for articles about acts that continue to perform, but without hteir best-recognized lineup. For example, it looks rather odd to have an article on The Miracles without listing Smokey Robinson. Iron Maiden's "former members" list is no worse than The Temptations', but The Fall's list is poor looking because it is not properly formatted. I will fix that. And how and why does "Former Members" not require a separate "color bar" section? What would the alternative be?--FuriousFreddy 23:48, 4 November 2006 (UTC)
            • Why a bar for former members in paticular, is a blank space not enough? Former members seems arbitrary, and on that logic why not a large colour bar for each element? The footprint of the infobox should be as small as possible IMHO. Freddy, your judgement on these issues seems to be sound so far, I'm just voicing my openion, am open to your views and willing to stand corrected. I just want to get these issues out and off my chest. On a side note, it's a badge of honour with the Fall about all the ex-members, as a long term, damn it, fanatic, i think the list is great. my to-do list is turning the reds to blues. - Coil00 01:03, 5 November 2006 (UTC)
              • Yes, the footprint should be as small as possible, which is why we want to avoid listing anything but names. However, former members is an important field for many groups, and, yes, maybe not so for others. We have to find some sort of balance, however, so that we can accommodate each type of article. Perhaps we could make it policy for, with groups that have more than 10 former members, to list any particularly notable former members up to ten, and then place a note "for more, see [[#Personnel|Personnel]]". As for the bar thing, I was just asking for an alternate solution. I, personally, don't care one way or the other, so long as any changes are done without breaking any of the pages. Many articles on musical acts have all "former members" and no "current members" (The Supremes, for example), so the seperating bar needs to be there if it is to be there for the "(current) members" section as well. --FuriousFreddy 02:30, 5 November 2006 (UTC)
                • My openion is that neither the current nor former members bar is needed. Can I get some views on this. - Coil00 00:10, 7 November 2006 (UTC)

Proposal 3

Ok, let's try something else. If we're going to go with green for "group_or_band", then we should pick one thats neither too saturated nor too muddy. And if "group_or_band" is going to be green, then "non_peforming_personnel" can't be. And I think it's more important to have "non_performing" stand out than to have "cover_band" stand out. I mean, honestly, is "cover_band" really worth wasting a whole color on? Anyway, this is what I've come up with. I'm not sure we're there yet, but it's something to contemplate.

Proposal #3

solo_singer khaki ===> solo_singer khaki
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist SandyBrown
non_performing_personnel lightgreen ===> non_performing_personnel plum
group_or_band lightskyblue ===> group_or_band #bfe0bf
cover_band plum ===> cover_band lightsteelblue
classical_ensemble paleturquoise ===> classical_ensemble paleturquoise
temporary darkgray ===> temporary LightGrey

BTW, while I'm here, I want to suggest adding singer_instrumentalist. With a color possibly somewhere between khaki and sandybrown:  singer_instrumentalist  in peach, or something like that. The category certainly seems far more useful than "cover_band"!  :) Xtifr tälk 21:14, 3 November 2006 (UTC)

The band colour is well chosen, Xtifr. BTY what IS a non performing personnel? Bez is the only example I can think of ;) - Coil00 21:31, 3 November 2006 (UTC)
The template page lists it as: "All composers, producers, songwriters, arrangers, engineers, and other non-performing personnel." – Heaven's Wrath   Talk  00:02, 4 November 2006 (UTC)
The definition is incomplete. Should be changed to "All composers, producers, songwriters, arrangers, maracca shakers, engineers, and other non-performing personnel." - Coil00 00:12, 4 November 2006 (UTC)
Maracca shakers would be under "non_vocal_instrumentalist." :-) – Heaven's Wrath   Talk  04:07, 4 November 2006 (UTC)

Proposal 4

Get rid of the colors. —freak(talk) 01:47, Nov. 4, 2006 (UTC)

Proposal 5

Basically, a milder version of #3. Per Prolog, I toned down the SandyBrown by reducing its saturation to 40, and this is what I got. Thistle is a lot more subdued than Plum. And I think the PowderBlue is at least a little less intrusive than the paleturquoise.

Proposal #5

solo_singer khaki ===> solo_singer khaki
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist #f4bf92
non_performing_personnel lightgreen ===> non_performing_personnel Thistle
group_or_band lightskyblue ===> group_or_band #bfe0bf
cover_band plum ===> cover_band lightsteelblue
classical_ensemble paleturquoise ===> classical_ensemble PowderBlue
temporary darkgray ===> temporary LightGrey

I'm not sure about "composer_or_conductor", if we end up adding that, but perhaps a tan or brown of some sort would work. Xtifr tälk 22:37, 5 November 2006 (UTC)

I like this. All the colours are pretty neutral and unobtrusive, yet they are still clearly different from each other. I'd personally keep the old primary colour set between non_performing_personnel, group_or_band and cover_band though, as I think the blue (lightsteelblue) fits best to the current WP colour scheme, and the band colour is much more popular than cover band one. The green does look very good, though. Prolog 13:15, 6 November 2006 (UTC)
Just in case it wasn't obvious: my thought (with this and #3) was to have similar things use similar-but-distinctive colors, so that even if you see a new color for the first time, you'll get a strong hint that it's similar to things you have seen before. Thus, individual musicians from red/yellow range of the spectrum, groups from blue/green, and non-performers get purple all to themselves. However, given the relative rarity of "cover_band", perhaps "cover_band" and "classical_ensemble" could be switched. (I do like the lightsteelblue.) Xtifr tälk 23:23, 6 November 2006 (UTC)


Proposal 6

Proposal 5 colors, different order - Today's colors muted a bit. Any sort of group (band/cover/ensemble) have a stronger blue channel in the color (cooler colors), soloists have yellow/orange (warmer), green goes to non-performers (which could be expanded later). *Spark* 22:44, 20 November 2006 (UTC)

Proposal #6

solo_singer khaki ===> solo_singer khaki
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist #f4bf92
non_performing_personnel lightgreen ===> non_performing_personnel #bfe0bf
group_or_band lightskyblue ===> group_or_band lightsteelblue
cover_band plum ===> cover_band Thistle
classical_ensemble paleturquoise ===> classical_ensemble PowderBlue
temporary darkgray ===> temporary LightGrey


Note: I mostly went with the color order in #5 due to some strong objections to the use of blue for group_or_band. Xtifr tälk 10:10, 21 November 2006 (UTC)

Proposal 7

This is a variant of 5 above, except haved used lightsteelblue for non-vocal instrumentalist (a fairly widely used template, deservs more than the link /orange. Also, I think #cccc99 would be well suited to classical related infoboxes. - Coil00 22:14, 22 November 2006 (UTC)

Proposal #7

solo_singer khaki ===> solo_singer khaki
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist lightsteelblue
non_performing_personnel lightgreen ===> non_performing_personnel Thistle
group_or_band lightskyblue ===> group_or_band #bfe0bf
cover_band plum ===> cover_band #f4bf92
classical_ensemble paleturquoise ===> classical_ensemble #cccc99
temporary darkgray ===> temporary LightGrey
I still find cccc99 extremely ugly, and I have no idea what "deserves more than the link /orange" means. I think the orange for non_vocal_instrumentalist has the strong advantage of being similar enough to the "khaki" yellow to make people think they're dealing with something similar (which they are) while still being distinctive. Whereas, making it the color used for cover_band makes that category so completely distinctive from group_or_band that it is potentially confusing. Xtifr tälk 02:20, 23 November 2006 (UTC)
Re: "link /orange" - typo there, meant 'pink'. Not sure its a general enough colour for such a widely used category. Everything else looks good. - Coil00 21:54, 24 November 2006 (UTC)

Proposal 8

On the other hand, if we absolutely must have cccc99, it should be used (IMO) on a category that appears rarely. Plus, this eliminates all variants on the baby-blue that several people have objected to. And it leaves open the possibility of using another shade of blue for the proposed new category, composer_or_conductor. Puts individual musicians in the yellow/orange spectrum, bands in the greenish spectrum, classical in the bluish spectrum, and leaves purple for the not-really-musicians-after-all category. Xtifr tälk 02:20, 23 November 2006 (UTC)

Proposal #8

solo_singer khaki ===> solo_singer khaki
non_vocal_instrumentalist lightcoral ===> non_vocal_instrumentalist #f4bf92
non_performing_personnel lightgreen ===> non_performing_personnel Thistle
group_or_band lightskyblue ===> group_or_band #bfe0bf
cover_band plum ===> cover_band #cccc99
classical_ensemble paleturquoise ===> classical_ensemble lightsteelblue
temporary darkgray ===> temporary LightGrey

Voting

Please indicate your support for a color system below.

Proposal 1

  • Oppose, I think the lightgreen is unacceptable, and the sandybrown and paleturquoise are marginal. (And note, this was my proposal.) Xtifr tälk 02:43, 23 November 2006 (UTC)

Proposal 2

  • Oppose, I think the lightgreen is unacceptable, the sandybrown and paleturquoise are marginal, and the cover_band color is potentiall confusing. Xtifr tälk 02:43, 23 November 2006 (UTC)

Proposal 3

  • Oppose, I think the lightgreen is unacceptable, and the sandybrown and paleturquoise are marginal. (And note, this is my proposal.) Xtifr tälk 02:43, 23 November 2006 (UTC)

Proposal 4

  • Neutral, I think the colors are useful for identification, but this does have the advantage of not using any colors that anyone has objected to. :) Xtifr tälk 02:43, 23 November 2006 (UTC)

Proposal 5

  • Support Very subdued and nice color selection. – Heaven's Wrath   Talk  21:54, 20 November 2006 (UTC)
  • Support, I like the green, and hate to waste it on a variation of the infobox that is almost never used. Though #6 is fine too Xtifr tälk 07:16, 21 November 2006 (UTC)

Proposal 6

  • Support Like 5's colors, think the assignments are wrong though. *Spark* 22:45, 20 November 2006 (UTC)
  • Support. As I mentioned above, I like #5 but prefer to have lightsteelblue for group_or_band. Prolog 22:56, 20 November 2006 (UTC)
  • Support For same reasons as #5. I like this more. – Heaven's Wrath   Talk  23:20, 20 November 2006 (UTC)
  • Support These colours are similar to those already in use but will be a lot less intrusive on the article pages.--
  • Support Is similar to the existing scheme, which has advantages. I slightly prefer #5, but this is perfectly adequate. Xtifr tälk 07:16, 21 November 2006 (UTC)
  • Support as for reasons stated above Andrzejbanas 09:28, 21 November 2006 (UTC)

Proposal 7

  • Support Per Xtifrs reasoning above with a few swap arounds. - Coil00 22:14, 22 November 2006 (UTC)
  • Mildly Oppose, I think the blue for instrumentalists and orange for cover bands is simply too confusing. Xtifr tälk 02:43, 23 November 2006 (UTC)

Proposal 8

  • Support while I still have mild reservations about the puke-green, it could grow on me, and this does have the advantage (IMO) of making similar things similar-but-distinctive. Xtifr tälk 02:43, 23 November 2006 (UTC)

Proposal 6 Implemented

Since proposal 6 seemed the clear preferred choice, I've implemented the changes. *Spark* 15:39, 2 December 2006 (UTC)

Sounds good. Thanks for being bold. – Heaven's Wrath   Talk  16:03, 2 December 2006 (UTC)
I agree, it was definitely time. (Would have done it myself if I hadn't been sick the last couple of days.) However, since the color names aren't part of the W3C standards, I've replaced them with color codes. I also took out the aliases that Spark had silently added because A) I'm not sure they're a good idea--simpler is better, and B) if they're going to be done, they should be proper aliases, not just additional cases. We can discuss it at length later, but for now, I think the status quo is more sensible. Xtifr tälk 17:10, 2 December 2006 (UTC)
Good move. Looks great. - Coil00 19:15, 2 December 2006 (UTC)
Problem: The selected color for bands is almost exactly the same as the color used in template:album infobox for studio albums, this might cause confusion in the future. —The preceding unsigned comment was added by Nightmare X (talk • contribs) 13:50, 3 December 2006 (UTC).
  • Suggestion: I have found that some Singer-instrumentalists do lead vocals and others only backing vocals. I therefore propose an addition to the Color selector of an appropriate new shade for backing singers, instrumentalists and otherwise, including session backup singers. A shade that dovetails into the existing new Color selector code should allow the viewer to differentialte between lead singers, backing singers and non-vocal instrumentalists. - B.C.Schmerker 15:15, 23 May 2007 (UTC)

Request:The Template's code (for Arabic Wikipedia)

Hi. Listen, I'm currently expanding the article for Linkin Park in Arabic [2] and I'd like to know the code for the Arabic musical template asap. And if there is, can you add the Arabic interwiki? Thanks.

P.S. Here's one interwiki that needs to be added for this musical template: "fa:الگو:جعبه اطلاعات هنرمند موسیقی"

-- Qasamaan 6:52, 23 November 2006 (UTC)

I added the interwiki, but what do you mean by the code? It is all there on the template page. Just hit edit and you can look at it and copy it. – Heaven's Wrath   Talk  00:01, 27 November 2006 (UTC)

Color - Hex vs. Name

Xtifr updated my name changes with the comment "use more portable color encodings, rather than color names". Can someone explain the rationale behind this?

I was going to comment on Xtifr's talk page but thought it might be useful as a MOS on templates. To me, using names is more portable, as if a mirror wants to implement different values for those colors, they can. Same for printing, a named color can be changed, a hex RGB triplet not so much. In fact, I believe a user could override these colors if they wanted using css (though haven't investigated). Thanks. *Spark* 17:08, 2 December 2006 (UTC)

Those color names aren't part of the W3C standards. And no, I don't know of any way that color names can be overridden, although we might be able to re-implement the template using styles, which would allow the colors to be overridden. Seems like it might be a lot of work for not much gain, though. So really, the only difference between color names and hex triplets is that hex triplets are a real web standard, while the color names (at least, these ones) are merely a convention. Xtifr tälk 17:16, 2 December 2006 (UTC)
Color names are listed in the CSS3 working spec [3] and are standard on popular browsers [4]. Using a name is more flexible than hardcoding RGB. Keep in mind certain color combinations don't work well for the colorblind, which could have their software configured to handle css color names differently. Is there a MOS statement on named vs rgb colors? *Spark* 18:24, 2 December 2006 (UTC)
RGB triplets are just as easy/difficult to override if someone really wants to. There's no more flexibility in the one than the other. And the triplets give greater backward compatibility with older software. Also, there's a consistency issue: we're using some colors that don't have names. I think it's better to have all names or all triplets, and since all names isn't an option any more, I think all triplets is the btter choice. I don't feel strongly about this, and if you can find some MoS or something to support using color names, then I'm fine with it, but it just doesn't seem right to me. Xtifr tälk 19:49, 2 December 2006 (UTC)
Named colors are easier to tailor to your preferences. It's much easier to have a stylesheet change than having a program parse and recalc RGB. The named colors go back quite a few revisions, even though they haven't been official until CSS3. Much more flexible than hardcoded values. Hardcoded RGB just doesn't seem right to me. Interesting, isn't it? I'll investigate more, but am leaning toward putting back the names where they can be put back unless there's something stating that is definitely not proper. *Spark* 00:47, 3 December 2006 (UTC)
Hex triplets can be matched just as easily as arbitrary names. You don't need to "parse and recalc" anything! In any case, there's no named styles here to override (just "infobox", which is too generic to help in this case). We could possibly rewrite the infobox to use different named styles for each type of background. But then you wouldn't care what the default colors were, you could just plug in your own preferred values. Which is maybe something to consider in the future (I might even try to build a prototype). But as it is, hex triplets are compatible with old browsers, cell phones, and all sorts of things, whereas named colors (beyond the sixteen that are standard) are not necessarily. And overriding seems just as easy either way (unless you can show me a counterexample). Xtifr tälk 01:40, 3 December 2006 (UTC)

(<-left shift) On matching - named values are evaluated through a lookup table/map. RGB values aren't. Customizing a lookup table for 147 named colors would require a change in that map. Doing it for 16 million colors would be a bit more complex and require a change beyond an updated map. Named colors give you a known working set of possibilities. Named colors (most if not all of the X11 colors), have been in Netscape since 1.1 and IE since at least 3. I don't think I can name a browser on any platform that doesn't support that named color set. If you can point one out, please do. Keep in mind when talking about mobile platforms or older systems, going with named colors is generally better, as the software for those systems can easily map those colors to something decent on that platform. I'm saying not only should we use named colors, we should be restricted to them (or styles) in templates. I had thought about starting a push to use styles for infoboxes. Maybe it's time to head in that direction. This discussion goes beyond the musical artist template. *Spark* 11:51, 3 December 2006 (UTC)

Ah, I assumed you were talking about using some combination of javascript and styles to remap the colors, which would work just as well for these seven specific colors no matter what their format. If you're talking about hacking your system colormaps, well, I think that's a bit much to expect of most people. Anyway, we already have two colors that lack names, so at best, you'd be able to remap five of the seven. Furthermore, those two nameless colors happen to be our red and green, and red-green color-blindness is the most common type, so we wouldn't be able to help most color-blind people even if we did enable this dubious hackery. If we want to allow people to control the colors, I think the right way is with styles (or javascript), not color-map hackery. But the real bottom line for me is that the template was using hex triplets, and I don't know why, but I don't want to find out the hard way that there was a very good reason. I don't think this is the right template to use for casual experimentation. A meta-discussion at a higher level sounds great; experimenting with this template, not-so-great. Xtifr tälk 18:18, 3 December 2006 (UTC)
I'm not certain if, for example, the firefox base allows for changing named colors via some sort of properties file. Looked around a bit, didn't find anything. I wouldn't expect an end user to modify maps, but I could see a usability group putting together a special build or a patch or plugin that could be applied to the generic browser to address the issue, if one hasn't already. As to why I did it, I did not consider it experimentation, I considered it consistency. Most every other template I've worked with uses named colors. That's why I was looking for a MOS statement. If you find the right forum for discussing the potential for a style based approach, fire me a message. Don't know that I have much time to dig into it at the moment but that might change in a few weeks. *Spark* 18:27, 3 December 2006 (UTC)

Archive

Can someone with the know-how archive closed discussions please (page is now 115kb) - Coil00 21:41, 2 December 2006 (UTC)

Done. See floating archive box for the link. *Spark* 00:42, 3 December 2006 (UTC)
Thanks, I was about to do this myself. The page was getting rather large. – Heaven's Wrath   Talk  02:52, 3 December 2006 (UTC)

New field: distinguishing genres and styles

As part of a proposal to try and end "genre edit wars", one of the things I requested was that a Style(s) field be added to this template.

To view this proposal, see Wikipedia talk:WikiProject Musicians#Genre wars and the distinguishing of genres and styles.

I would appreciate feedback on this proposal. I am going to push hard for this proposal to be put into action, and I appreciate any supporters in helping me do so. Thank you. -- Reaper X 00:53, 11 December 2006 (UTC)

This has already been discussed and rejected (see the archived discussion). Xtifr tälk 04:29, 11 December 2006 (UTC)

Use of Template:flagicon vs. Direct image call

As infoboxes are one of my big focuses at work on another wiki I spend my time on, I am in high favor of not using the long code version of calling the flag of origin to an artist, but using the Template:flagicon. Quite simply, its less code, cleaner, and a good standard. In the upgrades to using this infobox (which I much love and support), I state my opinions for the following:

Do not support

[[Image:Flag of country.svg|25px|Country flag]] [[City]], [[State/Province]], [[Country]]

Support

{{flagicon|country}} [[City]], [[State/Province]], [[Country]]

It calls the country's alias and the country flag alias. All which have been well established within Wikipedia. I think the example should reflect this. -- immunity 21:36, 17 December 2006 (UTC)

Excellent suggestion! I see that's a widely used template already. It does mean more work for the servers with all the extra transclusion (I'm really amazed by this page), but that seems like a small price to pay for the improved standardization and ease-of-use. I'd say go for it. Xtifr tälk 23:56, 17 December 2006 (UTC)
The direct image call was originally put in there, because it created an image slightly larger than the {{flagicon}} template. The flag icon also seemd to cramp the image a little. I did see it, but I did not really like the way it looked.
  • Image:Flag of USA.svg —
  • {{flagicon}} — Flag of the United States
I do not really care either way. It might be able to make it a little easier to use for the average user. We can certainly use the template. – Heaven's Wrath   Talk  00:58, 18 December 2006 (UTC)
Maybe we can discuss or update the actual template of Wikipedia:WikiProject_Flag_Template, there so far doesn't seem to be any reason why we cannot bump it up a few pixels? -- immunity 02:12, 18 December 2006 (UTC)
This was apparently discussed before. This is where we can get our answers. Wikipedia_talk:WikiProject_Flag_Template#Using_Diff.27t_Image_at_Diff.27t_Resolutions --immunity 03:40, 18 December 2006 (UTC)
Note the template does accept sizing:
  • {{flagicon|USA|size=25px}} — Flag of the United States
  • {{flagicon|USA|size=100px}} — Flag of the United States
    --*Spark* 23:07, 20 December 2006 (UTC)
I saw that when I was checking the template out. It does not seem that much different if we use the template and have to use the size parameter. But in the interest of making this template easier, we can use it. (Even if we do not make it 25px. – Heaven's Wrath   Talk  00:50, 21 December 2006 (UTC)
Template:flagicon appears properly calibrated for text height in the current Infobox. Recommend Template:flagicon for all future projects requiring a template from Category:Infoboxes. - B.C.Schmerker 04:43, 24 May 2007 (UTC)

Coloring snag

I've hit a problem with coloring. What do you do with people who perform both solo and in a group on a regular basis? Please leave a note on my talk page if you answer here. - Mgm|(talk) 18:40, 18 December 2006 (UTC)

NeilEvans responded here. Solo exploits take precedent over group ones, so "solo_singer" would be used. – Heaven's Wrath   Talk  20:54, 18 December 2006 (UTC)
Ok, maybe I've been misinterpreting this. I've been assuming that band membership has nothing to do with anything, and that individual musicians should all be classified as either "solo_singer" (if they sing lead) or "non_vocal_instrumentalist" (if they play an instrument and don't sing or only sing backup). That, of course, leaves us without a category for someone who is only a backup singer, but then I think few such would be notable enough for an article. But basically, I didn't think it mattered whether they were a member of a band or not. If I'm wrong about this, let me know, because I have a bunch of articles to correct. And if I'm right, maybe we should elaborate a bit in the documentation, as this isn't the first time this (or similar) question has been raised. (In fact, we should probably elaborate in the documentation a bit either way.) Xtifr tälk 22:03, 18 December 2006 (UTC)
You are correct being part of a band makes no difference, if they sing or play an instrument then that is what should be entered in that field in the infobox.--NeilEvans 22:07, 18 December 2006 (UTC)
Ok, I added "lead singers" to the "includes" part of the description for solo_singer. That should help make it a little more clear, I think. Xtifr tälk 03:10, 19 December 2006 (UTC)
I concur with solo_singer as the best choice for lead singler in a band or group. I see a potential need for a backing_singer class, referred to above in #Proposal 6 implemented; the other classes are good for now. - B.C.Schmerker 04:49, 24 May 2007 (UTC)

editprotect request

{{mprotected2}} has been updated to allow the name of the article with which the template is associated to be added as a parameter (i.e. {{mprotected2|Selena}}) will add this template to Category:Protected pages associated with Main Page articles . Sandy (Talk) 22:43, 20 December 2006 (UTC)

Unfortunately, it looks like Selena is no longer on the main page (backlogs are bad for business). If I understand correctly, that sort've renders this request moot. If I continue patrolling these things, I'll be happy to do this for you in the future. You may wish to contact the protecting admin to inquire about dropping the protection, as they didn't specify whether their protection was due to high-use or being frontpaged (or if they did, I missed wherever they specified it). Cheers! Luna Santin 02:58, 22 December 2006 (UTC)

Occupation field

Regarding the occupation field, should only musical occupations be listed? What if the artist has dabbled in a field, say, he was in a couple of movies but didn't really act a lot. Would it be fair to include "Actor"? Sam 01:02, 28 December 2006 (UTC)

It's a judgement call. And no, it's not just for musical occupations. If the person is notable for another occupation (e.g. Ice Cube or Harry Connick Jr.), then absolutely that occupation should be listed. If it's more of a case of dabbling in another occupation, then I'd say it probably shouldn't be listed. But Willie Nelson (who I'd consider a borderline case) has "actor" listed. So obviously some flexibility is allowed. Just don't get carried away trying to make someone look more impressive than they really are. Remember that we're trying to write encyclopedia articles, not puff pieces. Use common sense, and you should be ok. Xtifr tälk 11:43, 28 December 2006 (UTC)
Thanks for clearing that up. Could you edit the text in the fields table to clarify that? I would do it myself but the page is locked for me. Sam 16:52, 28 December 2006 (UTC)
I added a little bit of information, but just so you know, although the template page is locked, the page with the information is not. It is transcluded from Template:Infobox musical artist/doc. If you would like to edit it further, please feel free. – Heaven's Wrath   Talk  17:10, 28 December 2006 (UTC)
Ah, thank you. Sam 17:16, 28 December 2006 (UTC)
I somehow missed the release of 2.0. I am off to download. – Heaven's Wrath   Talk  00:08, 29 December 2006 (UTC)
No problem, and thanks for fixing that typo, I thought I checked my spelling before I saved that. Oh, well. – Heaven's Wrath   Talk  20:12, 28 December 2006 (UTC)
Firefox 2.0's spellchecker to the rescue ;) Sam 20:50, 28 December 2006 (UTC)

Nationality field

Would it be possible to add a nationality field? Often the birth place and origin of an artist do not share their nationality. For example, Regina Spektor is an American but if you only looked at the infobox on her page you would think she was Russian. Katie Melua has joint British and Georgian citizenship but her infobox only states her birthplace in Georgia. There are many more examples of this where a nationality field would clear up any confusion. Philip Stevens 10:55, 3 January 2007 (UTC)

I'm dubious, but not totally opposed. Nationality has been the subject of numerous contentious edit wars in the past {see WP:LAME#Ethnic feuds for some of the more extreme examples). Also, I'd prefer not to encourage people to just look at the infobox. If nationality is worth mentioning, it's worth mentioning in the lead, and I think mentioning it in the lead should be good enough to solve the presented problem. And if history shows us anything, it's that people will try to fill in every field of an infobox they possibly can, even when it's not particular appropriate or called for. This field seems like it would be redundant in many (probably most) cases. Or, if it's not redundant, then we'd want to go through and re-edit several thousand articles to add it in. So...I cringe a little at the suggestion, but won't stand in the way if others also feel it's a good idea. But I'm glad you asked (protection aside), because I don't think it should go in without at least a little further discussion. Xtifr tälk 13:20, 5 January 2007 (UTC)
Add {{editprotected}} again after further discussion has taken place. If you have any questions, please contact me at my talk page. Ian Manka 02:15, 6 January 2007 (UTC)
I think there are too many possible combinations and permutations of what could go in there - ancestry, place of birth, residence, etc. It would make the infobox too confusing. I'd put explanations of stuff like that in the article itself. -- Alucard (Dr.) | Talk 04:02, 8 March 2007 (UTC)

Michael Nyman Band

Should I really put all the past members in the infobox? That would be a really long list. I tried to include those who had had major stints with the band, and left out the others, which are listed in the "lineup" section. --Scottandrewhutchins 16:49, 6 January 2007 (UTC)

adding notable roles to the ibox

Hiya, I'm not very familiar with infoboxes and the procedure for adding things to them, so sorry if this seems like a silly question. I was wondering if it was possible to get a 'notable roles' section added to this ibox template. It's just that many singers are also actors so I thought it would be handy to have their roles in the box as well as their music stats. I had a look through the available iboxes and can only find one for actor and musical artist and not a mixture of both. I thought I would be able to just add '|notable_role = ' to the specific artist's ibox (on their page), but it doesn't seem to show up when I save, so obviously it cant be done like this (unless i'm doing it wrong). Gungadin 22:38, 7 January 2007 (UTC)

Sorry, I meant to respond to this before. In order to add a new parameter, you actually have to add extra code to the template's page. Even so, I cannot think of any musicians that would really require a "notable roles" parameter. Most of the time, the musician is only notable because of his or her musical exploits, not any acting roles. I think that it might be more useful as prose in the biography section of the article. Also, the unclear definition of "notable" roles might lead to edit wars or inconsistencies in the content when compared to other articles. The infobox is supposed to display very non-controversial facts (although genre disputes have been known to cause problems), and I think a "notable roles" section might be too subjective. – Heaven's Wrath   Talk  03:33, 9 January 2007 (UTC)

Image size

Apparently, putting any value in the Img_size parameter breaks the infobox (does not recognize size, and puts the image in full size). Is this intended or not? -- ReyBrujo 03:27, 12 January 2007 (UTC)

What do you mean, it breaks the infobox. The parameter for image size does work.--NeilEvans 16:51, 12 January 2007 (UTC)
It seems to be breaking again. Adding Img_size makes it look as though the image link does not exist (red link). Just64helpin 22:21, 26 April 2007 (UTC)
actually, it's not the image size value, it's the appended “px”. if only the value is added, it appears to work. example gut: img_size=200, example nicht so gut: img_size=200px --emerson7 | Talk 03:53, 27 April 2007 (UTC)

Origins and flags

Two issues regarding the origin field:

  1. Sometimes people read it as "where the band members were born" rather than "where the band formed". Is there a way to phrase it better?
  2. Do we actually need flagicons in the field? There are some fierce debates on whether flag icons are overproliferated. My personal thoughts:
    • Flag icons are most often used to save space where it would be too cluttered to write out country names in full, or at all. The origin field must write out the geographical location in full, and therefore the flag icons cannot ever reduce or replace the text.
    • Therefore, the only possible use for flag icons here is to provide a visual cue that is redundant to text already 100% clear in meaning.

What's the opinion on these things? –Unint 01:15, 14 January 2007 (UTC)

My opinion on the flag's in infoboxes is that they really don't have to be there. They are mostly used so infoboxs don't have to squeeze in large country names (like for movie or album release dates in specific countries). I really don't think they need to be in the country infobox, it just clutters them. Andrzejbanas 01:54, 14 January 2007 (UTC)
I agree with you both on this; not only does it seem to me that the flags are a source of clutter, they are also a source of needless edit-warring and controversy; should Simple Minds, for example, be adorned with the Scottish or the British flag? My view is that we should remove this option from the template. See also Wikipedia talk:WikiProject Music#Flags. --Guinnog 12:11, 14 January 2007 (UTC)
The discussion has now been moved to Wikipedia talk:Manual of Style#Flag icons - manual of style entry?. --Guinnog 14:08, 15 January 2007 (UTC)
Per discussion there, and as no objection has been raised here, I'm going to remove the reference to the flag icon in this infobox. --Guinnog 17:35, 15 January 2007 (UTC)
As for the other issue, how about displaying "Career origin" instead of "Origin" as a clarification? –Unint 15:53, 15 January 2007 (UTC)


Layout for Band Pages

One Page Per Artist

I think any pages for a musical group should be merged together so that a band history, list of members, and complete discography are included on ONE PAGE. I'm somewhat new to wiki, but I think that seems more logical than having separate pages like AC/DC discography, Past members of AC/DC, etc. Anyone agree?Thomaslikespigs 19:17, 16 January 2007 (UTC)

Hi. First off, I moved your new topic to the bottom of the talk page so people can find it. I'll explain why on your talk page. Now, as for your question, there are arguments on both sides, and there's no easy answers. The biggest problem with your proposal is that there are technical limits on article size. Very large articles cause problems with many browsers, especially when you try to edit. Also, many people consider large articles unwieldy to browse (especially, I think, those with tabbed browsers). There's no one answer that will satisfy everyone, so we just muddle along as best we can. I do think that the main article about a band should include at least a summary of the the membership, discography, etc., but beyond that, we absolutely have to split some things up. There are other issues—your question does not have simple answers—but that should do for a start. Cheers, Xtifr tälk 20:52, 16 January 2007 (UTC)
Note: this is also off-topic for this infobox. Further discussion (if any) should probably be moved to Wikipedia talk:WikiProject Musicians. Xtifr tälk 21:22, 16 January 2007 (UTC)

footnotes field

Would it be possible for an administrator to add a footnotes field on a par with the one on Infobox Officeholder? There are several pages on which I think it is needed to explain the information displayed in the infobox. Thank you. Hera1187 20:59, 22 January 2007 (UTC)

What is stopping you from using a footnote in the infobox? The note will still appear in the references section in the bottom. Why does it need the parameter? (An example of it in use would be helpful.) – Heaven's Wrath   Talk  03:10, 23 January 2007 (UTC)
  • Katie Melua plays the violin, but this is not widely know and I would like to put an explanation and cite to prevent it being deleted by well meaning editors who don't know this. An unintrusive footnotes field would do this. For an example of such a field in use, see Ehud Olmert. Hera1187 08:29, 23 January 2007 (UTC)
That can go as a regular footnote. There's no reason to have a special field for a standard feature. I've removed the editprotected request, as we seem to be far from having a concensus on adding this. Xtifr tälk 21:47, 28 January 2007 (UTC)

Voice Type

Hi, new here, but with a question: Couldn't there be a category not just for "Instrument," but for "Voice Type"? My issue is opera singers. On Jussi Bjorling, I just tried to change "Instrument: Vocals" to "Voice type: Tenor," but I see the template itself would need a change.

The only problem I see is that people would start trying to categorize every pop singer as an alto, tenor, baritone, etc., which isn't useful information for a pop singer, and would simply add clutter. For an opera singer, though, it's often one of the first things you need to know, like what instrument they play. Thanks, Mackan79 14:27, 25 January 2007 (UTC)

This sounds like it might be worth further discussion, but for now, I recommend something like "Vocals (tenor)". I agree that people trying to classify pop musicians would be a problem (and would frequently constitute original research, even if correct). There might be a way around that, but I don't see it at present, so I think my workaround is probably the best bet until someone comes up with a better suggestion. Xtifr tälk 21:52, 28 January 2007 (UTC)
I think that the only way to do that would be to have a different set of options used only for classical musicians (in other words, make it optional) -- Alucard (Dr.) | Talk 03:58, 8 March 2007 (UTC)

theres's no question that this template is biased toward contemporary music forms, but technically, the voice is an instrument, and it's perfectly appropriate to indicate the voice range in that field. i've been using, [[Human voice|voice]]: [[soprano]] (voice: soprano) --emerson7 | Talk 19:44, 15 March 2007 (UTC)

Spouse field suggestion

Would a spouse field be a good or a bad idea? It seems odd to me that we have them in the actors template and not the musical artist one. --GracieLizzie 16:10, 28 January 2007 (UTC)

Well, ask yourself that question: do you think it's really relevant to this topic? –Unint 18:27, 28 January 2007 (UTC)
I think it's as relevant here as it is to actors. So if you think it's irrelevant here, then perhaps it should go from actors too? --GracieLizzie 20:28, 28 January 2007 (UTC)
The way I see it:
  1. Articles on actors are more focused on personal life across the board, due to celebrity culture and all. However, only a small subset of musicians are bona fide celebrities. In fact, some are intensely private and it is often the case that the names of their partners are unknown, and thus we do not always focus on those details as much.
  2. I've checked out the edit war over the spouse field at Infobox actor, and I'd rather we not bring it over here. Likewise, they have a "notable roles" field; we do not, on the grounds of it being far too contentious.
But don't let that be the last word on the matter. Anybody else? –Unint 21:10, 28 January 2007 (UTC)
I'm strongly opposed. It's not relevant to a musical career. It's not present in the scientists infobox. I don't believe it belongs in the actors infobox, although I suppose there's a stronger case for it there. In those rare cases where a musician's marital status is mentionworthy (if you'll pardon the coinage), it can be mentioned in the body of the article. In general, our policy is not to mention spouses (spice?) or offspring unless they're notable; adding this to the infobox will encourage the opposite. Anyway, in many (most?) cases that I can think of, it's the ex-spouses that are notable, i.e. Sonny Bono and Cher, Gregg Allman and Cher, Richard and Linda Thompson, Madonna and Sean Penn, Kurt Cobain and Courtney Love, etc. And I really don't think we want to add a Former Spouses field as well! Xtifr tälk 21:43, 28 January 2007 (UTC)

Classical Conductors

I have been working on creating a new entry for a Classical Conductor and was going to base it on what has been done elsewhere. Looking at a few sample conductors I don't see this Infobox used, and I think it probably should be. So the question is what "background" value should I use for a classical conductor? Are they considered an instrumentalist? If so, it might be nice to add that to the description as an example. Thanks. -- Alucard (Dr.) | Talk 16:12, 7 February 2007 (UTC)

actually it is being used...ref: Michael Tilson Thomas, Leonard Bernstein, Yehudi Menuhin and Pierre Boulez just to name a few. ....works well with orchestras too! ref: San Francisco Symphony and London Symphony Orchestra. although this infobox is arguably waaaay contemporary-music centric, it works relatively well, but i'd be interested in what additionally you'd like to see. --emerson7 | Talk 20:52, 8 February 2007 (UTC)
I see the value "classical_ensemble" being used in most of the examples you cited, but one is left blank. Surely the background "classical ensemble" isn't really accurate when it's just one person, is it? I don't mind classifying a conductor as an instrumentalist, but we should be using some sort of individual classification, rather than implying that the person is an ensemble. -- Alucard (Dr.) | Talk 03:55, 8 March 2007 (UTC)
the ensemble is the orchestra. what good is a conductor.... --emerson7 | Talk 01:27, 13 March 2007 (UTC)

I have also come across a conductor being listed as "non_performing_personnell", ref: Zubin Mehta, which I disagree with. There really does not seem to be an appropriate background in which conductors fall. I agree that putting a conductor under instrumentalist would be better, but then could that be added to the description. Ideally, I think a separate category should be there for conductors. Xunvala 15:25, 20 March 2007 (UTC)

Cause Of Death

i am proposing adding cause of death to the infobox, other sites like IMDB, answers.com list cause of death. it is useful information for most people and i feeel it should be listed above the fold. Randywilliams1975 18:52, 12 February 2007 (UTC)

I don't think that's something that needs to be in the infobox, I think just put it in the article. -Joltman 19:28, 12 February 2007 (UTC)
i concur with Joltman...everything needn't be infoboxed, and i'd like to see a lot of other things before cause of death. --emerson7 | Talk 21:02, 12 February 2007 (UTC)
Hello. I am not a member of the Project, but I do a lot of work on biographies. I wish you folks would revisit the idea of adding "cause of death" to the info box. It would mean adding just one more line (after the date of death) and would be a quick and easy source of this information. Thanks. Michael David 14:02, 8 May 2007 (UTC)

Spouse

I propose to add spouse to this template. Astor Lam (13 February, 2007 18:15 GMT+8)

Discussed fairly recently (scroll up a little). I'm still opposed to the suggestion. Xtifr tälk 09:48, 16 February 2007 (UTC)

G.D. signature

What about adding an "if" string for signature, I'm sure it won't be very useful but I need to use on the Carl Reinecke article. Thanks. -- Walter Humala Godsave him! (wanna Talk?) 03:46, 18 February 2007 (UTC)

Where exactly do you want to add the signature?--NeilEvans 20:35, 10 March 2007 (UTC)

Image size

Someone should provide the possibility for image to be set at its size, as, when enlarged, it gives bad results as in Carlo Bergonzi. --Attilios 11:20, 20 February 2007 (UTC)

"Years active"?

How are we to define this? Someoneinmyheadbutit'snotme 20:08, 10 March 2007 (UTC)

Surely that's just common sense.--NeilEvans 20:31, 10 March 2007 (UTC)
not really...particularly for classical artists. when does it actually 'count' for career start? ...first recital? ...first paid performance? ...first acclaimed performance? it really isn't all that clear.--emerson7 | Talk 03:49, 11 March 2007 (UTC)
I'd go with first recital, to compare that with modern artists, an artisat could be active for many years within a small niche of music and known to only a small number of people. They may then have a breakout hit in the pop charts some years later. But you wouldn't count the start of their career from the breakout hit would you?--NeilEvans 15:43, 11 March 2007 (UTC)
Hence the dilemma. I'd say the musician is technically "active" from the moment they start to play an instrument or define themselves as a musician, whenever that is. Someoneinmyheadbutit'snotme 22:28, 11 March 2007 (UTC)
I think years active is meant to be a definitive date, as you would not be able to find an exact date of any musician, if you looked for the first time they played an instrument. Something like first recital, I would think that someone could easily research that in regard to classical musicians.--NeilEvans 23:10, 11 March 2007 (UTC)
So, the first available date in reference to doing something musical or definitely the first performance? Someoneinmyheadbutit'snotme 03:44, 12 March 2007 (UTC)
I would say first performance, but I guess you should just use your own judgement for classical artists.--NeilEvans 23:40, 12 March 2007 (UTC)

Height

I think we should at least have a couple of artists of height , like 5 or 6.Happy Editing!(Trampton 01:13, 15 March 2007 (UTC)).

I'm not quite sure what you're trying to say, but if you're asking for a height field to be added, then I disagree. Height is pretty much completely irrelevant to a musician's career. If there are any exceptions, then the height issues can be discussed in the body of the article. Adding a field to the infobox would result in people trying to add the information to many musicians' infoboxes, which would be extremely pointless. Hair color is probably relevant to more musicians' careers than height is—but still irrelevant to the vast majority, so I'd strongly oppose adding a hair-color field as well. Xtifr tälk 22:45, 15 March 2007 (UTC)

Requested edit

This template is protected, and should be tagged with {{protected template}}, or another suitable protection template. Thanks – Qxz 19:24, 15 March 2007 (UTC)

Y Done. – Luna Santin (talk) 02:28, 16 March 2007 (UTC)