FANDOM

2,054,169 Pages

Replacement filing cabinet This page 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 LyricWiki talk page.
LyricWiki talk archive for Community Portal
<< April 2009 May 2009 June 2009 >>


Artists who can't decide what they want to call themselves

The question has come up what to do with artists who released stuff under various names. There are several options available:

  1. Decide on one artist name and put everything on that page, with the same "Artist:" prefix for all song and album pages. This has several advantages:
    • A user who looks for the lyrics to "Cinnamon Girl" by Neil Young, for example, won't have to guess (supposing he doesn't have the album cover at hand) whether he'll find them on the Neil Young or on the Neil Young & Crazy Horse page.
    • A thing called "Implied Redirects": in short, if there's a redirect from Neil Young & Crazy Horse to Neil Young, a user looking for Neil Young & Crazy Horse:Heart Of Gold will get redirected to Neil Young:Heart Of Gold automatically, even if there's no explicit redirect for that song page.
    • All song and album pages by an artist can be quickly found using the PrefixIndex. Obviously, pages starting with "The Soft Machine:" wouldn't show up in a prefix search for "Soft Machine:".
    • I'd guess this approach also makes certain things simpler for the bots, but I'm no expert on that… Teknomunk?
  2. If, like with Neil Young vs NY&CH, the works can be reasonably split up, put them on different pages (though of course not for minor name variations, like Simon And/& Garfunkel). This removes several of the advantages above, but at least keeps the pages small.
  3. A sort of inbetween approach where everything is on the same artist page, but with different "Artist:" prefixes. This will eventually present a big problem when we are able to get the artist from the pagename and no longer depend on artist parameters in the Song and Album templates for most pages.

Another question would be how the API can deal with the second and third approach, but I'm no expert on that either, so I'd be obliged if someone more knowledgeable could chime in on that… — 6×9 (Talk) 21:07, 3 May 2009 (UTC)

Well presented 6!
Now come on people, what method do you consider should be used? And why? This is your community, and we really want to get your input on this...  Яєdxx Actions Words 21:18, 3 May 2009 (UTC)
My preference is for the implied redirects. That seems relatively painless. To muddy the waters a bit more though, what about Jefferson Airplane/Jefferson Starship/Starship? When one or two members would leave they'd change their name but were essentially the same "band". --    RainbowDragon    talk    contribs   21:41, 3 May 2009 (UTC)
I have a feeling that we may actually need/want to do a mixture of a couple of these, depending on the example. The Artist that caused this discussion was Captain Beefheart And The Magic Band And The Magic Band‎/Captain Beefheart And The Magic Band And His Magic Band‎/Captain Beefheart And The Magic Band. This might be a good example (along with Neil Young/Neil Young & Crazy Horse) of a place where an implied redirect would be good. The extra "...And The Band" parts should possibly be removed and everything placed on just "Captain Beefheart" and "Neil Young." Neil Young more so, because his stuff is generally attributed just to him, whether with Crazy Horse or not. Captain Beefheart is a little weird because only one(?) album is attributed just to him on the album cover. I'm not a Beefheart fan, so if one of the other versions is better, then so be it. Zappa's output might fall under this, as well, with everything under Frank Zappa, as he is the anchoring factor.
Jefferson Airplane/Jefferson Starship/Starship I think would be on separate pages, I think. These name variations fall into time-specific eras, correct? Kind of like Bruce Hornsby And The Range and Bruce Hornsby. So, I'd treat these incarnations as essentially separate Artist entities, listing the other two names in the Related Artist section. Time-specific eras I think should automatically be separate.
Those are my initial reactions, anyhow. Perhaps more examples of such "problem children" can help with figuring this out? Thanks, 6x9 for bringing this here!    Kiefer    talk    contribs    admin   01:13, 4 May 2009 (UTC)

I don't know that I would call them "problem children" (in this instance I think you got to blame the parents ;p) but I think this is what you're after:

 Яєdxx Actions Words 17:54, 4 May 2009
Mmmmm..Artists who can't decide what they want to call themselves...but these aren't, are they?
Neither is Neil Young & Crazy Horse, or Captain Beefheart and The Magic Band (though The Magic Band/His Magic Band are). Crazy Horse is a band. Neil Young has solo recordings. Captain Beefheart is an individual who has collaborated with Zappa. The Magic Band are still performing magic...
Artists who can't decide what they want to call themselves are the likes of Simon And/& Garfunkel, Ron Wood/Ronnie Wood, Jackson 5/The Jackson Five (but not The Jacksons).
See how confusing this can get?
This is why I believe the deciding factor as to who the recording artist is and therefore how an album page should be named and on what artist page a release should be included should continue to be the album cover. That is something everyone can easily understand. To allow for users personal preference in determining this aspect for themselves will only give rise to conflict/reverted edits, as has already happened on a number of occasions.
I hear what you say 6 about advantages, but I certainly don't consider any of the advantages you have mentioned worth having if to use them means that we can no longer name album pages correctly. That to me is a distinct disadvantage.  Яєdxx Actions Words 23:38, 6 May 2009 (UTC)
How about this? We get Sean to change the page title to 6pt grey, so you can pretend it's not even there, and the only reference for an album's artist will be the link produced by the Album template (the display text of which can be changed). Or do you seriously suggest we move Frank Zappa:Lumpy Gravy (1968) to Frank Vincent Zappa & The Abnuceals Emuukha Electric Symphony Orchestra & Chorus:Lumpy Gravy (1968)? 'Cause that's what's on the cover. — 6×9 (Talk) 00:00, 7 May 2009 (UTC)
Additionally, please see Sean's last post in this topic. — 6×9 (Talk) 00:16, 7 May 2009 (UTC)
Re Frank Zappa, And what's so wrong about that? After all that is what it's called ;). There doesn't appear to be a clear cut case and as such each case should be decided individually on merit. The album cover is a good starting place. If I went in to a music store looking for anything by Eric Burden I'd be inclined to check under War in addition to The Animals I'd also check under E for Eric. Similarly with Jools Holland I'd also check under Squeeze and expect to see 'Related Artists..' under both artists. That said, I'm inclined to agree with 6×9's point 2 in his initial presentation. Ñôīέ2çяȳTalk 00:34, 7 May 2009 (UTC)
Then we should get rid of the capitalisation rule as well, because K.d. Lang is just as wrong for any k.d. lang album as Neil Young is for any Neil Young & Crazy Horse album. But of course there are technical reasons for the former, as opposed to mere technical reasons for the latter ;-) — 6×9 (Talk) 01:01, 7 May 2009 (UTC)
Eric Burdon was a redirect to War. I made the artist page and removed the redirect. I was hoping all songs attributed to Eric Burdon can be filed under his own page. is there any reason (technical or otherwise) that removing the redirect and making the artist page was a bad thing? The links in the Artistfooter list his works. If some of his songs were performed by him also in his collaborations, they can show under both artist pages, correct? thanks Night Owl 10:21, 11 May 2009 (UTC)
It is correct for Eric Burdon and War to have individual artist pages. One should not be redirected to the other because both are independent of each other.
It has also occurred to me that maybe we should be focusing more on our definition of "collaboration". Neil Young is one artist. Crazy Horse is another. Neil Young performed both with and without Crazy Horse. Since both artists are independent of each other, recordings Neil made with Crazy Horse could be deemed to be a collaboration.
It would also seem to me that once the definition of collaboration has been clarified/agreed, some of the issues relating to the naming of collaborative albums/songs might also be resolved.  Яєdxx Actions Words 02:52, 23 May 2009 (UTC)
Who wrote 99.99% of the songs on all NY&CH albums? Not to mention the fact that even if an album has "NY&CH" on the cover it doesn't necessarily mean CH are featured on all tracks (Zuma – 7 out of 9, Rust Never Sleeps – only 4 out of 9). So no, not a collaboration, rather CH as backing group for NY. Therefore I'd merge them all onto the NY page.
EB&W on the other hand… I'm not very familiar with them, but from what I've heard collab might be fitting here… — 6×9 (Talk) 03:17, 23 May 2009 (UTC)
Now we might be getting somewhere ;)
Ok nice try, but who wrote the songs and performing on every song doesn't actually have any relevance as to whether or not the union is a collaboration. Nor do I consider that it should continue being left up to the individual editing the page to determine, without any guidance, whether a union is in fact a collaboration. To do so will simply mean that these discrepancies and differences in opinions are going to continue to recur.
As far as I am concerned it is solely a matter of independence. If it can be shown that the two artists have independent releases, or perform independently of each other, the union is a collaboration.  Яєdxx Actions Words 04:09, 23 May 2009 (UTC)
Neil Young has his own page, so why do all the songs under Neil Young & Crazy Horse read Neil Young:Song? Can't be that tough to see!
A Collaboration header vs. Artist header won't resolve the issue, because the song page names don't match the artist page name. As an example, see Richard & Linda Thompson, removing the collab header won't break anything, It's just a better way of describing the artists involved in the collaboration. Similarly, putting a collab header on CSN&Y page may be considered a good thing, it would make for a more visible description of the gang. Whether an artist page is for a band, a duo, trio, collab, supergroup etc. the song pages should match the artist page name, and that is not a matter of choice by any editor. The NY&CH page is a good example of the rule that says, don't start what you can't finish; it's half done, either it has to go all the way, or go back to where it was on NY page, so that NY&CH can redirect to NY. Or it may be worth some editor's while to put a weird looking SongHeader on NY&CH pages as a long term experiment :) Night Owl 05:49, 23 May 2009 (UTC)
The song pages don't have to match the artist page name in instances where the artist that did the recording is different than the artist whose album it is included. It's not a matter of choice. You are the editor trying to push their personal choice, as opposed to following the site rules that were set up years ago by Sean. You keep trying to slip that in there, and I have debunked that thoroughly time and time again. Dead point.    Kiefer    talk    contribs    admin   01:37, 24 May 2009 (UTC)

I have today finished correcting the Neil Young & Crazy Horse album and song pages that had originally been set up incorrectly as being Neil Young. All the song pages relating to the NY & CH albums have now all been moved to NY & CH and the links in the song and footer templates updated too.
In view of the time it has taken me to correct all this, I would ask again that users take a little more care to create pages under correct artist names. The correct artist name for album page is who released it. The correct artist name for song page is who performed the song. This information is shown on the album cover.  Яєdxx Actions Words 05:36, 26 May 2009 (UTC)

@Keifer: see Robert Cray Band albums under Robert Cray, dead point? Night Owl 20:33, 29 May 2009
Not sure what your point (here) is. Do you mean should Robert Cray Band albums be on the Robert Cray page? No, they should be on the Robert Cray Band page. Are there possibly Robert Cray Band recordings on a "Robert Cray" album? Possibly...I don't know. Should they be labeled "Robert Cray Band" if they do exist, even though they are on a Robert Cray album? Yes, they should be labeled "Robert Cray Band" if they are a Robert Cray Band recording, even if they have been included on a Robert Cray collection. Is your point still a dead one? Yeah. Can I come up with more questions to interview myself with? You bet I can. Can I stop? I'm not sure.... What's my signature look like?    Kiefer    talk    contribs    admin   03:09, 30 May 2009 (UTC)
my point: There are contrary examples existing on the site already, done by other editors,... which example is to be followed?! All Robert Cray Band albums are listed on the Robert Cray page (check the covers), is that OK? Can the same be applied to Prince & The Revolution, Bruce Springsteen & the E Street band, John Mayall & The Bluesbreakers, NY & Crazy Horse? As for NY&CH, is it in worse shape now than it was 2 weeks ago? Hope that is clear. Night Owl 06:22, 30 May 2009 (UTC)
Yes, there are contrary examples. Each editor makes a good faith attempt to present their information in a manner that they think is best. This means that different ways to handle the information is used. Everybody seems to want a flowchart type of decision maker on how each little instance should be treated. I think that we've found (well I have, anyway) that there always seem to be exceptions to the rule. I think that may be the biggest source of conflict going. In a perfect world, Captain Beefheart wouldn't freak around with his name. In a perfect world, Neil Young wouldn't go hopping around with different bands. (Band monogamy, dude! If Huey Lewis and Tom Petty (for the most part...a little solo action as well as Wilbury fun aside) can do it, why can't you!) In a perfect world, Chicago wouldn't have released their first album as "The Chicago Transit Authority". For most of those artists that you mention above, I wouldn't have much of a problem merging them onto a single artist page, but I wouldn't want to see them listed as an album without the band recognition. This, of course, is not something that you want to see on an Artist page if avoidable because it messes with the API. It's an avoidable situation, so right now I'd lean towards having most of these as separate pages. But I don't think that it's as cut-and-dry and you and Redxx seem to feel. I stated as much earlier.
In general, those situations should be kept separate unless the usefulness of the two pages is diminished by the exclusion of the albums. (The Chicago situation, for example.) Originally, when I came on the site I included Bruce Hornsby And The Range albums on the Bruce Hornsby page, as they are a continuous work by the Artist. I later rethought my position and moved the "Range" items to a separate page. But I think that the Beefheart situation or the collaboration (whose name escapes me) where the two artists changed billing order on the cover are exceptions. It diminishes the information by separating the "And The" albums from the "And His" albums, and the two collaborations by the same artists, I feel.    Kiefer    talk    contribs    admin   18:42, 30 May 2009 (UTC)
In a (not perfect) but most desirable world, artists, like communities, collaborate, use release titles and group names as they see fit. There are artists who have 4-5 aliases, as can be verified at discogs, where they use a alias param, so that all variations of Captian Beefheart and the dude's real name lead to the same page, similar to lw's Artist Redirects. A perfect world is not a world cast in stone. My point it whichever way an artist's page is split or NOT split, it can equally be labeled as editor's personal preference, as you labeled mine. The pros and cons of splitting were already outlined by another administrators, and the objections to splitting based on aliases and it's technical limitations did not garner any response. Night Owl 07:25, 31 May 2009 (UTC)
I didn't label how you wanted a page split or not split as your personal preference, that was referring to your desire for multiple pages for the same song recording. Here, we are discussing our personal preferences with regards to these Artists Who Can't Decide What To Call Themselves in order to (hopefully) come up with a general strategy or guideline for the help pages. But, I agree with you that in the end it's going to come down in some instances to the editor's personal preference as these situations can't all be ground out in an "if-then" statement. In fact, allow me to outdent...    Kiefer    talk    contribs    admin   19:20, 31 May 2009 (UTC)

I think that we've kind of discussed a variety of these situations, enough to try to come up with our general guidelines. I'm not sure if we've come up with any real solutions, though. So let's get less specific and more general, and start putting down some suggestions for guidelines. (Although if a specific example to match your explanation of the general situations are appropriate, then do so with a link, but let's try to limit the talk about the specifics themselves.)
Here's mine:

  1. Whenever possible, use the artist name given on the album in the pagename. This goes for Artist, Album, & Song pages.
  2. If a song appears on an artist's album that was not recorded by that artist (whether a guest artist track, a promotional bonus track, or an instance where a song by a previous musical endeavor by the artist or a member of the artist band, but not recorded under the same name as the album's artist) then the name of the Artist which made the recording should be used.
  3. If an artist's discography is under a wide variety of names, but is essentially the output of a single entity with perhaps minor variations, then it may be advantageous to include the various incarnations on one main artist page, with redirects to this page from the various incarnations' pages. This is likely less true if these incarnations are contained within certain distinct eras and do not intersect with other incarnations' eras. If these incarnations are included on a single Artist page, then the pagenames of the included albums & songs should still include the official artist name, as shown on the album cover.
  4. If the situation seems unique, use your best judgment or ask for input in the Community Portal's talk page.

Please note that these guidelines are specific to these AWCDWTCT situations, and aren't meant to include situations that are being discussed elsewhere here in the Community Portal.    Kiefer    talk    contribs    admin   19:20, 31 May 2009 (UTC)

Thank you Kiefer  Яєdxx Actions Words 00:23, 1 June 2009 (UTC)
Seeing as especially #3 concerns the API, could we get Sean's or Teknomunk's input on this before any further discussion? — 6×9 (Talk) 00:50, 1 June 2009 (UTC)
Additionally, before an artist's page is split, attach a move request, so that it can be visible and discussed on Category:Requests For Moves and the artist talk page, given that these splits can impede access via api/soap. Night Owl 02:09, 1 June 2009 (UTC)
Do you mean an artist split or a merge? Splitting things should help the API, shouldn't it? I was under the impression that this was one of the benefits of keeping these sorts of variations on separate pages. If there is a problem with the splitting, I may need to update my suggested guidelines above.    Kiefer    talk    contribs    admin   03:17, 1 June 2009 (UTC)
A move request is not appropriate Night Owl. As Kiefer has indicated above, and as you are fully aware, that is for merges.
I also have absolutely no desire, and I'm sure neither does Kiefer, to keep going over and over the same old ground with those that made these incorrect edits and who for whatever reason would prefer that things were done not as Kiefer has suggested, but their way. I am also moved to say that discussion should have taken place before the pages of which we are talking were merged. Kiefer has now provided more than adequate guidelines for this. If you really do not understand when it is inappropriate to merge a page look at the album cover.
And no you're not wrong Kiefer. As Night Owl is fully aware, splitting the pages helps with the API by making the variants visible.  Яєdxx Actions Words 07:45, 1 June 2009 (UTC)
Relax, Redxx...relax.... I think it's just a slip in terms, which is why I was asking for clarification. The conversation is actually heading in a forward direction, let's not put up any extraneous bumps in the road, eh?    Kiefer    talk    contribs    admin   12:38, 1 June 2009 (UTC)
Okay sorry. I'll get the roller out...  Яєdxx Actions Words 20:24, 1 June 2009 (UTC)
My mistake when I said putting a merge request, It should have said, a Split Request. Beware that what i say below is not my personal prefs!
  • Case 1:Van Der Graaf was split from Van Der Graaf Generator, then the two were put back under Van Der Graaf Generator again. The split was unnecessary because the two are name variations for the same band, and VDGG is now happily an artist redirect (instead of many song redirects), so a search for a song under either name resolves as it should.
  • Case 2: Bob Marley. It could have been handled two ways, a: everything under BM, with BM&TW as a redirect to BM, or the other way around; everything under BM&TW, with BM being a redirect. The way it IS now: both artist pages exist, with BM pretty much an empty page, and an artist redirect is not possible, so every song under BM&TW needs an individual redirect from BM.
  • Case 3: If the measure is what's the title on the cover, then all Robert Cray Band albums should be taken out of the Robert Cray page and go under their own page, But as it is now, RCB is a redirect and search for any song by either name variation works fine.
  • Case 4: Red's intent of splitting Bruce Springsteen And The E Street Band from Bruce Springsteen. I'm still wondering what is the justification... the discussion is open on the talk page, see my last post there.
  • Case 5:The Jeff Healey Band, Jeff Healey, Jeff Healey & The Jazz Wizards. By the Cover art standard, Jeff's works should be split three ways, with an army of song redirects. Right now two artist redirects take care of his works, Splitting his page would be an unnecessary make work project, Nobody's set their mark on Jeff yet, I guess.
  • Splitting variations of an artist name like Dude /Dude & His Gang means that even from the web page the entire discography can't be searched at once, artist redirects become impossible. This is why Frank Zappa was not split 6 different ways based on Album Cover title. This is why Robert Cray Band is not split from Robert Cray, (but by Red's standard, it should). There are more cases like this Captain Beefheart And The Magic Band!. If the only reasoning for a split is because of the cover art and no gain is to be made after lots of page moves, and artist redirects become impossible and song pages end up under a diff artist name, then what is the point?! Example: (see Alison Krauss & Union Station, it contains whole lotta AK albums/tracks, even though AK page already exists and the msg on both artist pages tell us that everything is fine, but in reality it's a half finished job) AK could have been left alone with AK&US as artist redirect, rather that it being left as it is now until who knows when...nobody can touch it because the intent of the last editor is unclear. This is pretty much what happened after NY page was supposedly split to NY&CH page. With both pages containing tracks and albums of both artists (NY&CH is not a variation of NY, but an artist redirect from NY&CH to NY was handling everything just fine) Everybody doesn't remember if it was NY or NY&CH that recorded Cortez the Killer first.
It is not the artists who can't decide what to call themselves, they can call themselves something different on every release and in every concert or collab, LW's job is to decide how to make all the variations accessible by web/api. I am pretty much agreeing with everything 6 times 9 said when he started this thread, I can see Senvaikis agrees from the decisions he makes when he doesn't religiously follow the album cover commandments.
  • The other technical bit is that Batch Move is no help in such cases (nobody ever mentions this) Batch Move wasn't used to split the two dudes named David Wilcox, or when splitting NY&CH pages from NY. (Batch Move moves everything in the namespace!) This is why such attempts are so tedious by hand, or the Splitting admins need to have a good knowledge of using their bots, otherwise an attempt is started, a second artit page is created, tracklist moved over but then then the actual moving of pages is left on the back burner!
  • So here is my proposal, finally. The person who wants to split an artist page or requests a split based on cover art would be required to do their research, fill all the external references in AF/AH, put a split request somewhere to be checked, and the split be done in a timely manner, and the outcome be equally accessible by web AND api before & after the split, for all the community. I hope this all makes sense to everybody. Let's measure three times and split once. Night Owl 22:41, 1 June 2009 (UTC)
I'm really more interested in ideas for solutions to the general problem of these situations. That's a lot of examples, but we're getting swamped with the examples. We could at this point argue each instance and be her all year. I gave general site guidelines above and asked for others' ideas about guidelines. What are your general site guidelines for dealing with these instances?
As for the "outcome be equally accessible by web AND api" bit, having artist pages merged into one page breaks the API because the API only recognizes items that begin with the artist pagename. Having, for example, Neil Young & Crazy Horse albums on the Neil Young page will make them invisible to the current version of the API. (Or am I misremembering that as well?) My guidelines try to limit these problems. With my guidelines, Zappa and Beefheart and the like are the rare exception to the rule. Springsteen and Springsteen & the ESB would be two separate pages by my guidelines.    Kiefer    talk    contribs    admin   03:09, 2 June 2009 (UTC)

(pssst, over here, on the left) That's only one job of the API – to make a song list for a certain artist accessible. The other (and probably far bigger) job is to access song pages directly, for whatever song is currently playing in whatever software the user is running. The latter works in one of these three cases: (1) both artist and song title are identical on our and the user's side; (2) one of these is different, but there's a redirect for that particular combination; (3) the artist is different while the song name is identical, and the user's artist is a redirect to ours. With AWCDWTWTCTs #3 will probably be the most likely scenario, therefore the best solution (as concerns the API) would be to keep all song pages in the same artist "namespace" (which has the added benefit of making them visible if the artist page is accessed via the API, though this part could probably be fixed so any song page is visible, while the other part can't). This is what I meant at the very top of this topic about those Implied Redirects.
An example just in case I switched to Chinese again without noticing, which must have happened in a certain other discussion, where no-one had any idea what I was going on about: A user has Neil Young:Southern Man tagged as being by NY&CH, because CH actually play on that song. They don't play at all on the first half of Rust Never Sleeps, which is still credited to NY&CH, but that's a different story. His software player tries to retrieve the lyrics… and fails, because there's neither a song page nor a redirect. If, on the other hand, NY&CH were a redirect to the NY page, any query for NY&CH:Song would automatically be redirected to NY:Song even if there is no explicit redirect at NY&CH:Song (like there isn't at Neil Young & Crazy Horse:Southern Man).
If we want to keep them in separate artist "namespaces" anyway, the only way to help out our frustrated API users would be to create a redirect for every song and every artist name variation: NY, NY & CH, NY And CH, NY With CH…
Was that English, or do I have to run it through Google's translator? — 6×9 (Talk) 04:13, 2 June 2009 (UTC)

I think that you did pretty well with the explanation. I think that I followed everything, but I'll have to sort of digest all of it and its implications though, and fully respond later as I'm just "checking in" right now.
Added question for my digestion later tonight, however: If there is a redirect from Neil Young & Crazy Horse to the Neil Young page, then those songs and albums by Neil Young & Crazy Horse can still be pagenamed "Neil Young & Crazy Horse:Album Title (DATE)" and "Neil Young & Crazy Horse:Song Title" on the "Neil Young" Artist page and it won't muck with the API? Or should they all be in the format "Neil Young:Etc."? Thanks, 6x9. I'm really feeling as though these discussions are progressing now.    Kiefer    talk    contribs    admin   19:36, 2 June 2009 (UTC)
The second one. The way I understand it is, if "Artist 1:Song" doesn't exist the API checks for "Artist 1", and if that is a redirect to "Artist 2" AND "Artist 2:Song" exists, it returns "Artist 2:Song". — 6×9 (Talk) 20:24, 2 June 2009 (UTC)
Still digesting a little, but I think I'm pretty much there. Wherever "there" is. I think that your most recent reply means that the API won't be looking for "Artist 1:Song" on the "Artist 2" page (in the case of there being no redirect from "Artist 2:Song" to the correctly pagenamed "Artist 1:Song"), unless of course the song was pagenamed "Artist 2:Song" to keep it in the same namespace, which is still a broken situation. (It means that any "Neil Young & Crazy Horse" song or album on the "Neil Young" page would have to be titled/pagenamed "Neil Young:Song", which isn't correct and I think will open as many cans of worms as we are trying to close with this situation. If that is the case, then I'd still go with my original guidelines.
It really is too bad that there can't be a kind of "soft" redirect for the API, where if someone searches for that "Neil Young" song and doesn't find it that there can be a sort of "Well, check CSN&Y for that title, and if not, then perhaps check Neil Young & Crazy Horse for that title, etc." Since we have "Related Artists", it'd be a similar thing. (I know I'm dreaming here, and I know it's not possible with the system that we have but a guy can dream, can't he?) In the meantime, we do have the Special:Soapfailures page to help fix these failed requests, so if someone does request Neil Young & Crazy Horse:Southern Man), then it can be fixed/redirected for the next time that it is requested.    Kiefer    talk    contribs    admin   00:02, 3 June 2009 (UTC)
@6: not wishing to interrupt the flow, but on which NY&CH release is "Southern Man"? The reason I ask is because I can only find this as being released by Neil Young see here
@Night Owl: NY&CH officially recorded "Cortez the Killer" first. 1974/75 for Zuma.  Яєdxx Actions Words 01:56, 3 June 2009 (UTC)
@kiefer: Does your guidelines state that when taken on way they break the api? and given that they are only guidelines no matter which way they are taken, they can be questioned as personal preference edits? And what is the primary purpose of the guidelines? Accessibility, or...., else....? Night Owl 02:03, 3 June 2009 (UTC)
@Kiefer: You gotta admit that waiting for them to turn up in Soapfailures is less than ideal, especially when we could prevent that in the first place. @Red: It isn't (like I wrote above), but it features CH (like I wrote above), therefore it made a good example. @Owl: Kiefer already said those guidelines aren't etched in stone (yet), so let's wait a bit longer before we throw rotten tomatoes at them, OK? (Still waiting for Sean's or Teknomunk's input… They probably could explain it way better than me.) — 6×9 (Talk) 02:14, 3 June 2009 (UTC)
@Night Owl: No, they don't state that they break the API. They don't really need to. Any solution that we come up with will break the API in some way. OR will break the pagenaming system that we use. My guidelines were written, however, to try to not break the API except in cases where otherwise we would break the pagenaming system, or in cases like Beefheart & Zappa where the names go all higgledy-piggledy. In the end they aren't personal preference edits, but best judgment edits. The only way around that is to go strictly by whatever is on the cover of the album. The primary purpose of the guidelines is to guide editors as to which way to go so as to both follow the pagenaming policy of the site, but also help the API function as well as it can in its current form. The secondary purpose is to try to keep admins from killing each other over something that for the past three years was dealt with (and worked sans conflict) in a "choose which method you think is best" manner.
@6x9: Yeah, Soapfailures isn't ideal. Especially since it is pretty weighed down at the moment with requests for things like videos (non-music ones) and the like for which we are not likely to ever have pages for. But it is a back-up to see which sorts of misnamed pages are being requested. That's all I meant. Good luck with Sean or teknomunk's input. I've e-mailed Sean about these site API issues, and got no response.    Kiefer    talk    contribs    admin   14:59, 3 June 2009 (UTC)
@Kiefer:Things started coming apart when artist redirects were deliberately broken (Young, Marley) They will break at Healey, Cray, Mayall etc if they are split based on album cover. The needless splits are the problem, not having all of Beefheart's dude under one namespace, and all variations left as artist redirects. Exactly what problem is caused if artists with name variations are left alone? We already break actual names for CJK/Cyrillic etc. All our naming conventions are targeted towards accessibility. Night Owl 15:55, 3 June 2009 (UTC)
Correction. Things started coming apart with wrongful merges of artist pages (Young). They will not break at The Robert Cray Band, etc. if they are split based on album cover, since this is the name being searched.
If I want to find the album Long May You Run at musicbrainz, I would search for the artist who released the album, "The Stills-Young Band", and I would find it. If I want to find the album at discogs, again I would search for it under "The Stills-Young Band" and I would find it. Including LyricWiki in my search, I would consider LyricWiki a very erroneous site to find the album page had been incorrectly named "Neil Young".
Incorrectly named album and song pages are the problem.
The problem caused if artists collaborations are merged onto the one artist page is that they are no longer accessible to the API, that is unless flaws with the current API are heavily compensated for and all the album and song pages are deliberately and incorrectly renamed. This is certainly not an acceptable solution when to leave the pages unmerged presents absolutely no problem, not to those accessing the site directly via the web, nor to those accessing it via the API, etc.  Яєdxx Actions Words 18:13, 3 June 2009 (UTC)
For how the API works, 6x9 gave a good explanation above. The API should not break for a given song if the title and artist combination given by the software matches at least one of the three cases given above. For listing songs by a given artist things get more difficult (and into areas that I don't understand), but to the best of my knowledge, it scrapes song links from the artist page. So as long as a link appears on the artist's page it will show up in the list provided by the API.
- teknomunk (talk,E,,A) 22:46, 3 June 2009 (UTC)
They show up, but the links are broken – see here for an example. The first song link goes to Captain Beefheart And The Magic Band And The Magic Band:Captain Beefheart And His Magic Band:Sure 'Nuff 'N Yes I Do instead of Captain Beefheart And The Magic Band And His Magic Band:Sure 'Nuff 'N Yes I Do. But this is something that can possibly be fixed, so let's not worry about that (unless Sean tells us categorically that it can't). The main problem with Beefheart is that, since Captain Beefheart And The Magic Band is not a redirect to Captain Beefheart And The Magic Band And The Magic Band, Implied Redirect won't work if someone is looking for, say, [[Captain Beefheart:Sure 'Nuff 'N Yes I Do]]; and even if it was a redirect, Implied Redirect still wouldn't work, because that particular song isn't in the same "artist namespace". — 6×9 (Talk) 23:03, 3 June 2009 (UTC)
That particular behavior is caused by a bug, which should be fixed shortly (I've let Sean know).
- teknomunk (talk,E,,A) 02:53, 4 June 2009 (UTC)
teknomunk, I'd love to have a new voice in this discussion, especially since you have been around as long as I have. Since you have a familiarity with the site and the technical side of things, what are your thoughts regarding this issue and the guidelines that I have enumerated above?    Kiefer    talk    contribs    admin   03:19, 4 June 2009 (UTC)

Artist Naming Guidelines

Because the previous discussion was getting very large, I've started a new heading to make things easier to discuss.
For the purposes of discussing the API, the following information:

  • There are two primary functions of the API as of now:
    1. Listing all songs by a particular artist and
    2. Getting the lyrics to a particular song.
  • For #1, the API opens the artist's page (Captain Beefheart And The Magic Band And The Magic Band -> Captain Beefheart And The Magic Band) and then enumerates all the albums and songs on the page. This function will follow page redirects.
  • For #2, the API tries to open the page directly (and possibly doing some modifications), follow redirects. If the page is not found, it tries following redirects on artist pages (This functionality on the web interface is called Implied Redirects).

The guidelines as originally given by Kiefer:

  1. Whenever possible, use the artist name given on the album in the pagename. This goes for Artist, Album, & Song pages.
  2. If a song appears on an artist's album that was not recorded by that artist (whether a guest artist track, a promotional bonus track, or an instance where a song by a previous musical endeavor by the artist or a member of the artist band, but not recorded under the same name as the album's artist) then the name of the Artist which made the recording should be used.
  3. If an artist's discography is under a wide variety of names, but is essentially the output of a single entity with perhaps minor variations, then it may be advantageous to include the various incarnations on one main artist page, with redirects to this page from the various incarnations' pages. This is likely less true if these incarnations are contained within certain distinct eras and do not intersect with other incarnations' eras. If these incarnations are included on a single Artist page, then the pagenames of the included albums & songs should still include the official artist name, as shown on the album cover.
  4. If the situation seems unique, use your best judgment or ask for input in the Community Portal's talk page.

Now, for my thoughts. I've always had the impression that we want as little red tape as possible. So along those lines, I would recommend these suggestions with few changes. In particular, I would suggest that #3 was instead:

  1. If an artist's discography is under a wide variety of names, but is essentially the output of a single entity with perhaps minor variations, then it should have one main artist page, with redirects to this page from the various incarnations' pages.

I would think that an artist with several different names in basically an evolution (I think Jefferson Starship/Starship was a specific example of this) could be handled with sections on a single page with possibly an infobox explaining that a name change occurred and the reasons for it (if there was any).
I would also suggest that if an exception to the guidelines is made for a given artist, that an explanation of why the exception was made is given on the associated talk page. This should help give a baseline for edit wars over personal preference and instead have the discussion regarding the reasons for a particular decision.
I expect there to be many cases where there are questions regarding the course of action to be taken. Questions over specific groups of artist pages should have their own discussion and they should be discussed individually, apart from the overall guidelines.
What still needs to be discussed, is this: When does a particular artist name deserve its own artist page rather than be combined with another, existing page? Best as I can tell, this is the core of the issues being discussed. Everything else is implementation details. (How do we get the API to work as expected when we do X? How do we prevent edit wars? How will people find song X through the web interface?) Personally, I think that the two artists/groups should be distinct groups that operated separately at the same time. This I think is a fairly simple and rigerous test that can be done.
I also think that some software upgrades may be required to make things easier (somebody mentioned "soft" artist redirects, which I think is an excellent idea, and that Batch Move was useless for splitting artists apart) The discussion of that should be kept separate from this discussion.
The software (API,MediaWiki) should not be used as an excuse to limit the use of something. If it is requred, the software can be modified to suit things, provided that there are reasonably simple and consistant rules that apply.
- teknomunk (talk,E,,A) 23:15, 5 June 2009 (UTC)

Thanks for your thoughts and input, teknomunk. As far as I can tell, you basically stated what was essentially the status quo you and I have been using for the past 3 years!  :-] We just never really had the need to write it all down. I don't like the extra red tape, either, if the truth be known. In the past, people edited those artists with which they were familiar and used their fan-based expertise to determine how these instances should be dealt with. Now there's a big move for complete uniformity across the site which often (as with this) drifts into realms that I'm uncomfortable with forcing site uniformity. I'm more uncomfortable with the conflict and inability to back off of a situation, though, so here we are with these "new" guidelines.
I, for one, am okay with what you've presented. (I think there's going to be a bit of disagreement over what the "single entity with perhaps minor variations" bit means, though. There's a bit of legalism and hair-splitting that's been going on.) So, I'd say that, at least for now since we both agree, those are the "official" guidelines.
Since I think that there may be still some disagreement, allow me the opportunity to state a preemptive piece of advice to editors: I would be very cautious when merging/separating those Artist pages belonging to artists that one is not well-acquainted with if they possibly fall into those maybe/maybe not situations. Let that Artist's fans take the lead. There's lots of other stuff to be done. And when conflicts of opinion arise, talk. Or just leave it alone.    Kiefer    talk    contribs    admin   22:49, 6 June 2009 (UTC)
I, for one, am perfectly happy with those guidelines. There's still the question of album and song pagenames, though… If various artistnames are united on one artist page, do all album and song pages also get the same artist prefix, or do they get whatever's on that particular album cover?
I'm for the first option, because (1) it's the simplest solution, (2) Implied Redirects won't work otherwise and (3) there's still the alias parameters to display the "actual" artistname. — 6×9 (Talk) 23:26, 6 June 2009 (UTC)
It's got to match. A) Because that's just the truth. If it's a song or album by Jefferson Airplane, the link should be to a Jefferson Airplane page, if it's by Starship, it should be to a Starship page. B) Because if merges are later decided to be undone, it's easier this way.    Kiefer    talk    contribs    admin   23:58, 6 June 2009 (UTC)
But all Starship/Airplane pages will be in One namespace, true? Otherwise artist redirects won't work. And we don't want links to redirects on pages, so the Alias param can be used for display purposes. Artist name variations can be shown in the Artist Info box, so users will be informed. Night Owl 00:27, 7 June 2009 (UTC)
No, all Starship/Airplane album & song pages will not be in one namespace. They possibly could be on the same Artist page, but Starship songs will be in the Starship namespace and Jefferson Airplane will be in the Jefferson Airplane namespace.    Kiefer    talk    contribs    admin   01:03, 7 June 2009 (UTC)
There's also the matter of minor name variations (& ↔ And, Artist ↔ The Artist, …The Magic Band ↔ …His Magic Band). Do we want different song/album pagenames for those as well? If not, where do we draw the line between minor and major name variations? — 6×9 (Talk) 01:05, 7 June 2009 (UTC)
For album and song pages, I would revert back to guideline #1 which states that "Whenever possible, use the artist name given on the album in the pagename." True, using one artist name for all songs and albums is the simplest, but also the least accurate and is not an techical limitation of our software. And I agree that keeping it this way will make un-merging artists easier.
As for implied redirects not working, You are assuming the current state of implied redirects will remain. This does not need to be the case. Extensions to the implied redirects can be made to handle these types of situations. The only thing that must first happen is finding a way to express what prefixes should be searched in addition to a given artist.
Also, to prevent the need for links to redirects, {{Song}} supports the parameter |alias=
{{Song||Test|alias=This Artist Name}}
Similar parameters may be required for other templates, but adding them should be fairly simple.
- teknomunk (talk,E,,A) 01:16, 7 June 2009 (UTC)
As long as "song/album pages with namespace not matching the artist page" are handled intelligently by the software, all would be well (VDG/VDGG on same page) Night Owl 01:43, 7 June 2009 (UTC)
Closed
Thank you tek and Kiefer for your help in resolving this issue. Can we please close this thread now?

 Яєdxx Actions Words 10:38, 7 June 2009 (UTC)

Done. The main topic of the conversation has been accomplished. After a few days it can be archived.    Kiefer    talk    contribs    admin   01:16, 8 June 2009 (UTC)

Songs Featured In Other Media

User:Hornean is going through a lot of songs and adding information about songs that have been featured in television shows and movies and such. I don't mind, and I think that the info can be good to have, but too many of these notices (as with Journey:Don't Stop Believin') and the top becomes a bit ugly. Anybody have ideas about what to do with this?    Kiefer    talk    contribs    admin   01:16, 4 May 2009 (UTC)

Suggestions: (1) Move the whole bulk below the lyrics to a ==Featured== (or some such) section; (2) make one catch-all, collapsible {{Featured}} template similar to {{Covered}} and {{AddAlb}}; or (3) both. — 6×9 (Talk) 01:52, 4 May 2009 (UTC)
(2) to include video games, etc. and with option to link to page on wikipedia.  Яєdxx Actions Words 14:41, 4 May 2009 (UTC)
The {{wp}} template would take care of that last bit anyway. — 6×9 (Talk) 16:05, 4 May 2009 (UTC)
Inside of the new template?  Яєdxx Actions Words 16:12, 4 May 2009 (UTC)
Inside any template parameter that outputs pure text. — 6×9 (Talk) 16:30, 4 May 2009 (UTC)
K thanks  Яєdxx Actions Words 16:55, 4 May 2009 (UTC)
I was just now asking Hornean about his references, and I think that a way to give a reference website to these items would definitely be good. Otherwise, who's to say what info is good and what isn't. Hornean does his work, but others...not so much. Kiefer 18:59, 4 May 2009 (UTC)

Action Required

To progress this post, we now need to decide whether we want to:

  • (1) Move the whole bulk below the lyrics to a ==Featured== (or some such) section
  • (2) make one catch-all, collapsible {{Featured}} template similar to {{Covered}} and {{AddAlb}}; or
  • (3) both.
  • (4) make one catch-all, non-collapsible {{Featured}} template with optional paramaters for the various types, e.g. television show, video game, movie, etc., that incorporates both internal and external links. (added by Redxx)
(4) is the same as (2). With "catch-all" I meant "catch-all". — 6×9 (Talk) 15:18, 3 July 2009 (UTC)
Aah but no, because (4) is "non" collapsible, so if it's only got the one entry (which is the usual scenario) it will simply display on the page ;) Yeah yeah, I know, I just wanted to make it clear (lol)  Яєdxx Actions Words 16:15, 3 July 2009 (UTC)
Do you really think I'd have made a collapsible table for one item? The idea (which is so obvious I didn't expect I'd have to write it down) was to only display the table in case of more than two or three items and otherwise use just text. Honestly, after all this time you could have a little more faith in me. *goes off to sulk* — 6×9 (Talk) 16:36, 3 July 2009 (UTC)
Haa haa haa you are so easy to wind up 6 ;) I have every faith in you which is of course what I meant by Yeah yeah, I know, I just wanted to make it :::::clear... :P But to assume is to make an ass of u and me as they say. I also figured that a bit of clarification at this point might save that question being asked by someone else. See, there is a method in my madness (lol) Sometimes anyways ;)  Яєdxx Actions Words 16:45, 3 July 2009 (UTC)
More like there's madness in your methods… — 6×9 (Talk) 17:02, 3 July 2009 (UTC)
If someone can provide me with a list of all the various Featured templates I can get to work… — 6×9 (Talk) 22:42, 5 July 2009 (UTC)
 Яєdxx Actions Words 01:12, 9 July 2009 (UTC)
That's less than I thought… {{RockBandDLC}} is just a special case of {{GameFeatureDLC}} and not really necessary, {{Feature}} is something else entirely, so it's just five templates. We could keep them separate and only beef each one up to allow several parameters (so only one of each is needed on a page). — 6×9 (Talk) 03:34, 10 July 2009 (UTC)
I know you have your reasons 6 but I really don't get it, why keep 5 separate templates that are all basically the same when one {{Featured In}} will do? The job Q?  Яєdxx Actions Words 10:23, 10 July 2009 (UTC)
I think that the various templates were created over time without any collaboration other than looking at what the others did. The only reason I see for the various templates is the categories and/or auxiliary pages that hold links to these things.
- teknomunk (talk,E,,A) 22:35, 10 July 2009 (UTC)
The category thing could be sorted by way of an #if thingy code though couldn't it tek? It's Ok I'll show 6 how to do it ;)  Яєdxx Actions Words 02:17, 11 July 2009 (UTC)
The category thing is not the problem. The different wording of {{GameFeatureDLC}} and an additional category "Request Anime Page" in {{AnimeFeature}} means we can't just re-use the same code for the various types though. We could do that if we just merged the other three templates… but that's not really a satisfying solution. The simplest thing all around, it seems, would be to keep them separate (except for the redundant {{RockBandDLC}}) and just add more optional parameters to each, so they won't have to be used more than once on the same page. I'm still for moving them below the lyrics though, at least if there's more than one. — 6×9 (Talk) 02:30, 11 July 2009 (UTC)
You know best. Only thing I don't agree with is putting them below the lyrics. The reason being that all this kind of info is at the top of the page and these little templates are likely to feel that they are being picked on if they are singled out and moved to the bottom. It just wouldn't be right. I'm sure you can make multiple templates fit neatly at the top of the page, (if that's your concern [some templates don't fit neatly I agree]), by giving due consideration to break lines when adapting the templates. Yes?  Яєdxx Actions Words 11:24, 15 July 2009 (UTC)

LyricWiki article page on Wikipedia

[1]  Яєdxx Actions Words 01:24, 5 May 2009 (UTC)

Are you following me around again?!? :-]    Kiefer    talk    contribs    admin   01:57, 5 May 2009 (UTC)
ShaunTheSheep Baaaaa...  Яєdxx Actions Words 15:10, 5 May 2009 (UTC)

Category:Instrumental

I just peeked at 6x9's new intro (nice update, BTW), and saw that there are listed a bunch of *NSync songs as well as A*Teens songs. Perhaps I'm wrong, but when I see *NSYNC:Oh Holy Night (A Cappella), I'm not thinking "instrumental." Actually, when I think *NSync, I'm not thinking "a band that does instrumentals." Anyone have a handle on these?    Kiefer    talk    contribs    admin   01:57, 5 May 2009 (UTC)

Not my intro – I just copied over an edited version of the one on Cat:L/I before deleting the page. — 6×9 (Talk) 15:25, 5 May 2009 (UTC)
Thank you 6. [2] I nicked it from wikipedia (lol) and they nicked it from...and they nicked it from...  Яєdxx Actions Words 16:17, 5 May 2009 (UTC)
No you ain't wrong. This is the point I was endeavouring to make (despite everything and against all the odds - lol), when I said important information was being lost by processing merge requests by bot without comparing pages. See here....
That having been said *NSync:Oh Holy Night (A Cappella) wasn't a merge request. It was set up wrongly it seems by Uberbot.
I've taken care of the wrongly attributed *NSYNC song pages, but I'm sure there is still plenty more song pages in the Instrumental category for 6 to correct Consider it a penance 6 (haa haa). Because if I see any more sickly-sweet love lyrics today by teeny pop manufactured bands I think I'm very likely to puke!  Яєdxx Actions Words 14:46, 5 May 2009 (UTC)
If you're gonna hurl...hurl into this.... *hands Redxx an old plastic New Kids on the Block wastebasket and runs away*    Kiefer    talk    contribs    admin   17:19, 5 May 2009 (UTC)

Firefox Extensions Page

I think it's about time that LyricWiki:Firefox Extensions gets moved to a non-Userspace location. (File under the category of "Long Overdue".) I'm thinking LyricWiki:Firefox Extensions?    Kiefer    talk    contribs    admin   17:37, 5 May 2009 (UTC)

I guess it was a good thing, so I've moved it. I'll put a link on the main Comm. Portal page and do a little editing.    Kiefer    talk    contribs    admin   02:27, 8 May 2009 (UTC)
Yes good move Kiefer..long overdue  Яєdxx Actions Words 22:16, 8 May 2009 (UTC)

Propuesta: en todos los idiomas. Propose: Wiki in all languejes

Me gustaría que la wiki entera estuviera disponible en todos los idiomas, así como la traducción (e incluso interpretaciones) de las letras de artistas que contiene. I like that all wikilirycs was available in much other languajes, and we would have the translation to our own languaje. 80.39.244.175 14:19, 9 May 2009 (UTC)

Nosotros queremos que las letras de canciones estuvieran disponible también. ¿Puede ayudarnos con esto? Los más de colaboradors solamente hablan en Inglés. --    RainbowDragon    talk    contribs   15:35, 9 May 2009 (UTC)
Pregunta: ¿Quieren decir Uds. que las letras de canciones en otras lenguajes deben estar disponibles, o que las letras ingleses deben eatar disponibles en otras lenguajes?
I ask because I have seen songs that were originally (only?) released in English with the {{translation}} template so that the English lyrics are side-by-side with a Spanish/German/whatever translation (though I can't find a specific example at the moment). Clearly this is impractical, but I feel guilty removing someone's hard work. Should the {{Multiple Languages}} template be used in situations like this even if the song hasn't been released in that language? Or are translations-not-into-English more trouble than they're worth? ~ Backgammon 02:48, 10 May 2009 (UTC)
As an example, {{Multiple Languages}} has been used on Duffy:Mercy which has preserved the translation that someone took time and effort to complete. Also, see T.A.T.u.:All The Things She Said where {{Multiple Languages}} was used & didn't affect the page layout with the badges. Ñôīέ2çяȳTalk 10:20, 10 May 2009 (UTC)
There is another discussion going on about this elsewhere. I just can't remember where atm...
Things are changing here all the time, and whilst I'm pleased to say that at least so far as I am concerned these changes are usually for the better, it is nevertheless very difficult trying to keep up with the pace of these. But the current policy as I know it is that we only seek to provide translations into English. These are placed side by side on the original song page.  Яєdxx Actions Words 10:26, 26 May 2009 (UTC)
This one ?  Ñôīέ2çяȳTalk 10:39, 26 May 2009 (UTC)
Thank you Notime and also further down this page too :-)  Яєdxx Actions Words 16:59, 26 May 2009 (UTC)

Google search violates accessibility

I'm sorry but your Google search box, located on every page, violates accessibility guidelines: I can't get any results here in my text (emacs-w3m) browser (no javascript, thank goodness.)

OK, I'll just have to use e.g., http://www.google.com/search?q=site:lyricwiki.org+Eno externally. Jidanni 05:54, 14 May 2009 (UTC)

You can access LW's native search by using Special:Search. — 6×9 (Talk) 12:57, 14 May 2009 (UTC)

Songs in multiple languages

The help page states: "Songs released in multiple languages should have the postfix /<language code> for each additional language the song was released in." Trouble is, these songs usually have different titles, but {{Multiple Languages}} only works with identical pagenames (except for the postfix). On the other hand, it's perfect for translations. I suggest the following:

  • Renaming the ML template to tl:Translations, to be used only for user translations. (SongFooter template shouldn't be necessary on translation subpages… Actually, if we include an artist link in the new template tl:Song could be omitted as well.)
  • Creating a new template for releases in different languages, which doesn't require identical pagenames.

Also, maybe we should put English translations on subpages as well, not just those into other languages… (Sean suggested the same recently, but I can't remember where.) — 6×9 (Talk) 16:47, 14 May 2009 (UTC)

I'm all for cleaning this stuff up. teknomunk, I believe, worked on the side-by-side translation bit, primarily because of his love of Japanese music. It gets a bit weird with the badges, though. If there isn't something between the badge and the lyrics, then the badge goes in the leftmost column, which isn't right, and if it went in the right, then the translations wouldn't be side-by-side. I like the English translation beside the original, though! It's just convenient/useful/etc. that way.
I'm not sure how everything is right now. I think it is a bit higgledy-piggledy. So, here's what I think would be nice: (workable? i don't know. i'm just throwin' this out there.) It would be nice if we could have the translation of a page in English on another page and include the lyrics template-like in a second column as teknomunk has it. (Somehow fixing the badge problem, as well.) This page should use the /en addition. Other, unofficial translations should also use the /lang endings. Those songs that have been actually recorded in other languages should be treated just like we do with regular songs. If it has a different title, then it goes under that title. If it has the same title, then we use an add-on - Artist:Song Title (Language). If it just has a minor change, such as having the chorus different (as with Avril Lavigne:Girlfriend), then I don't see a problem with listing those on the same page. No need to create a new page, just as if the Live version of a song had a small bit different, just a notation on the original page is good.
As for the Multiple Languages/Translation template, I think that it would be nice to basically merge the two ideas into one template. "Multiple Languages" is a good a name as any. Have the template give a "This song has been translated into Spanish, Swedish, and German." or "This song was released in the following languages: Spanish, Swedish, and German." or "This song was released in the following language: Spanish and has been translated into Swedish and German."
At least that's what I have off the top of my head.    Kiefer    talk    contribs    admin   01:36, 15 May 2009 (UTC)
The side-by-side thing would still be possible if we swapped English translations to subpages – by adding the original there as well. Since badges (and any metadata) would only be on the main page, that problem would be solved as well. (Unless you'd want original and romanization side-by-side…)
The reasons why I'd prefer two separate templates are: (a) categorisation – a song that's been released in English and Spanish versions should show up in both language categories, as well as twice in fLetter categories (since they're basically two separate songs), which SongFooter already handles, while user translations (which are subpages for the same song and which don't really need a SongFooter) could be put in a Translation/Language category; (b) the one for user translations could take over the duties of {{Song}} as well (basically just adding a link to the artist page) – this saves us any worries what to do about page ranking. — 6×9 (Talk) 03:00, 15 May 2009 (UTC)
Is it also possible to further distinguish between Translations and Romanization? Or are they treated pretty much the same? Some songs have been romanized but no translation. Also would be useful to be able to view the romanization beside the original script (either by using one page or two pages plus magic). thanks Night Owl 06:36, 15 May 2009 (UTC)
Swapping translations to subpages means we can have rom.s and originals side-by-side. The current rule is to have rom. and trans. side-by-side below the original. — 6×9 (Talk) 14:33, 15 May 2009 (UTC)
Okay, those are good reasons to have both templates. Just so that I'm clear that we're talking about the same thing, though. A song recorded and released in two languages will get separate pages if it has a different title as I said above so that there are two Language categories and fLetter categories, yes?    Kiefer    talk    contribs    admin   20:11, 15 May 2009 (UTC)
Exactly. And one recorded and released in two languages but with the same title will still get two pages, one with "(Language)" tagged on (like Peter Hammill:Gaia and Peter Hammill:Gaia (German)). — 6×9 (Talk) 20:23, 15 May 2009 (UTC)
Okay, I think I will jump in here with a few thoughts...It should be possible to have all the pages (original, romanizatoin, translations, etc.) on separate pages with the option of having original/romanization and romanization/translation views with the use of some template and/or extension magic. On a related note, one problem I have with the side-by-side translation is that the lines do not always line up correctly (it varies with the page layout and the size of the window). If we do make changes via extension we should also consider fixing this problem.
All things considered, I am rather liking the direction this is heading :)
- teknomunk (talk,E,,A) 18:56, 22 May 2009 (UTC)
So I take it we are agreed that we want to separate templates for songs released in different languages (let's call it {{OtherLanguages}} for now) and for user translations (I'd suggest remodelling and using {{Translation}} for the translation pages, and create {{Translated}} for original song, similar to {{Covered}})? — 6×9 (Talk) 20:02, 26 May 2009 (UTC)
Hi there, 6×9 invited me to contribute and as I am mainly here because I have the opportunity to translate songs I now do. In my opinion LW is the site with the best features to translate songs, so I decided to contribute my works to LW instead of other lyric-projects. Translations of songs are very important, because they give the listeners the chance to actually understand what they are listening to. And this is why I'd say: the creating of a new translation has to be easier then now, and a better structure.
If we take a look at translations in general, there are 2 basic kinds of translations: the ones who have been sung and published by the artist, and the ones that have been translated "for fun" to make the content understandable for more people. At first, LW puts them together, and especially in the help the topics oftex mix up as it seems. And LW is making a big mistake there: they only focus on making songs understandable for English people. "Non-English Songs" - the category shows: translations from en to any do not seem to be welcome. In fact they are as {{Multiple Languages}} shows (at least I hope so). It's very hard to find out, this is the only paragraph where I found information, and even there it focuses on non english-songs. Why not provide the other directions as well, there's nothing to loose but many viewers to win ;).
Let me focus on songs translated "for fun" at first. The translated song is listed in the Category:Translated songs as now. The translations use the /lang endings as it is at the moment (and might appear in a new Category:Translations).
The "new" {{TranslatedSong}} template is build like {{Multiple Languages}}:
{{TranslatedSong
|Artist = The Examples
|Song   = Lied
|OriginalLang = de
|Translation1 = en
|Translation2 = es
}}
It creates a tiny Div looking like that:

Translated song

This song has been translated into several languages: English, Spanish, the original song's language is German.
This looks a lot tidier then it looks now, besides you see it has been translated, and doesn't it say "The song exists in multiple languages" although it actually doesn't. The new place to insert is between the </lyrics>-Tag and the SongFooter, it's displayed below the lyrics. To put it in a nutshell: TranslatedSong is like Multiple Languages, just renamed and other parameter-names (because I think they are more understandable then).
Alright, now I'll focus on the songs released in more than one language. If we'd say the song "Lied" would actually exist in 3 languages. It's obvious the problem is: often the song title is changed, too, so they have to be submitted as well. The template I thought of for that problem is more of the type like the {{SongFooter}}: there are some possible parameters with any possible value. The possible parameters are the language-abbrevations, the values are the names. So this is what an template should look like (in use):
{{Multiple Language
|Artist = The Examples
|de = Lied
|en = Song
|ru = Песня
}}

Multiple Language

This song has been released in several languages: Lied (German), Song (English), Песня (Russian).
Which song is displayed at the moment (fat) can be found out by the language-value in the song-footer as well as by extracting the songname from the URL comparing it with the parameters.
OK, so this would be my solution. :) - Chris 01:06, 28 May 2009 (UTC)
Thanks for the efforts you put into this Chris.  Яєdxx Actions Words 18:43, 29 May 2009 (UTC)
I like the look of these template mockups.
- teknomunk (talk,E,,A) 19:43, 29 May 2009 (UTC)
This will be very nice since I like translating greek songs! I'll ask something though, which I'm not sure if it fits here. I don't know programming.. but the programs that take the lyrics from LW may be confused if two "lyrics" tags are in one page. I'm referring to the romanisation here. So is there needed a template that can "tell" the system to take just the original? Or the romanisation for the non-greek speaking users? I have no idea if that can happen. Just suggesting. :) Titaki 15:09, 30 May 2009 (UTC)

So, to summarize:

  • Songs released in multiple languages include the {{Multiple Languages}} template to link to other songs, listing the other song title (instead of the current /lang title addon)
    • If the song has the same title in multiple languages, a parenthetical disambiguation should be used Artist:Title (Language)
  • Translations of songs (including romanizations) are located at /lang (/roman or similar for romanizations) and use {{TranslatedSong}} to make links.

I went ahead and created the two templates suggested above. {{TranslatedSong}} and {{Multiple Languages/Test}}. The second one will need need to eventually override {{Multiple Languages}} or be renamed. Example usages of these templates:

{{TranslatedSong
|Artist=Kotoko
|Song=Radiance
|Translation1=en
|Translation2=es
|Translation3=ro
}}
{{Multiple Languages/Test
|Artist=Kotoko
|Lang1=ja|Title1=Radiance
|Title2=Radiance (English)
|Title3=Radiance (Spanish)
}}


- teknomunk (talk,E,,A) 00:15, 6 June 2009 (UTC)

I tested the "Multiple Language" on the pages Enrique Iglesias:Hero and Enrique Iglesias:Heroe - works, BUT:
  • No spaces after "," in both templates (tried to insert them but it didn't work, sry...)
  • How is submitted what language the songs are if the song-titles are different with "Multiple Language" (like in my example)?
  • Maybe "TranslatedSong" should be written as "Translated Song", too... Sorry, my fault.
  • Could you add some space above the template (margin-top), please? It looks quite sticky as it is now *g*
- Chris 13:53, 9 June 2009 (UTC)
In order:
  • I've added the spaces as best I can, (you have to use non-breaking spaces or MediaWiki will remove them).
  • You can use Lang#= to specify a language if there is not already a (Language) on the title. From a API/program perspective, we may need to have a parameter that is not actually used in the template just to declare the language, like this:
{{Multiple Languages/Test
|Artist=Kotoko
|Lang1=ja|Title1=Radiance|apiLang1=ja
|Title2=Radiance (English)|apiLang2=en
|Title3=Radiance (Spanish)|apiLang3=es
}}
  • That should be a simple move.
  • That should be fairly simple to do (I just copy/pasted your examples from above when making the templates)
-teknomunk (talk,E,,A) 16:32, 11 June 2009 (UTC)
Got some more questions. :) Can you add /roman code to be (Romanization) as en is (English)? The template {{TranslatedSong}} should be at the top (main page of the song) above the {{Song}} though, below it or under the lyric tags? At the sub pages no SF or {{Song}} is needed but the template TranslatedSong doesn't create a template to the original. Any thoughts? Titaki 08:09, 12 June 2009 (UTC)
Okay, answers:
  • Sure, we can add a /roman code. It just needed to be added to {{Language}}.
  • Personally, I would prefer that this is just above the lyrics tag, with the Multiple languages above the TranslatedSong.
  • Added backlink for translated song pages.
{{TranslatedSong
|Artist=Kotoko
|Song=Radiance
|Translation1=en
|Translation2=es
|Translation3=ro
|Translation4=roman
}}
- teknomunk (talk,E,,A) 16:55, 13 June 2009 (UTC)

There has been no recent activity on this thread. Unless somebody has an objection, I'm going to go ahead and update the help pages sometime Friday (June 26).
- teknomunk (talk,E,,A) 22:57, 25 June 2009 (UTC)

Looks good. Am I right that although there was talk at the beginning to merge the two items, we're going with two templates for the two separate types (Translated & Multiple Languages)? I'm okay with that, I just wanted to make sure that everything was 100% clear.    Kiefer    talk    contribs    admin   02:38, 26 June 2009 (UTC)
IIRC the talk was about separating them, because until now they were treated as the same thing (even though that wasn't appropriate). — 6×9 (Talk) 02:46, 26 June 2009 (UTC)
Okay. All good now.    Kiefer    talk    contribs    admin   03:00, 26 June 2009 (UTC)
I am going to get started now. I will try to do it so that things are not broken.
- teknomunk (talk,E,,A) 22:27, 26 June 2009 (UTC)

Dare to give REST a little more visibility

No fair. REST pages have hundreds of links to regular pages, but regular pages have not one link to REST pages. LyricWiki talk:REST#Dare to put a REST link on every page, pleaseJidanni 00:54, 17 May 2009 (UTC)

Here is an example: NY & CH, so how about a link in SF? Night Owl 15:55, 17 May 2009 (UTC)
Nice. The only link that works here is for a song that shouldn't be on that page in the first place. — 6×9 (Talk) 16:24, 17 May 2009 (UTC)
Here is one that was done right:DS & RF all links work. Night Owl 16:37, 17 May 2009 (UTC)
In my thinking, the linking makes sense the way it is now. Since the website is made for viewing on the web and the API is designed for programmatic access so that other apps can access the data (and chose whether or not they wish to link to the corresponding webpage as appropriate). Liking to the REST page from the site doesn't make sense to me since the person must have a browser to see those links (and therefore should be using the site).
The only benefit I can see to an end-user viewing a page via the REST API in a browser as opposed to the using the site itself would be that there are no ads on the REST pages. If you would like to browse without ads, my recommendation would be to choose the "Banners, No Ringtone Links" setting in the "Ads" tab of your user preferences, then install something like AdBlock Plus to remove the banners.
-Sean Colombo (talk|contribs) 18:02, 18 May 2009 (UTC)
PS: As a side-note: the original post implied that we were hiding the API, but I think we've done a pretty successful job of popularizing it for its intended purpose (as an API, not an anemic alternative web interface). The list of plugins (kind of a misnomer now since it's used for many purposes, but I digress) shows a pretty vibrant pool of apps that use the API - and it's not even close to being a complete list. Also, the last time I checked it (this was several months ago), the API was resulting in 250 times as many requests per day as the site itself.
One notable advantage of a REST link on an artist pages is to inform editors how misfiling can break the api:NY & CH, and make pages inaccessible to the other 250 :\ Night Owl 04:58, 19 May 2009 (UTC)
Editors do not need to be informed about misfiling, because it isn't misfiling. Those pages are filed correctly. To file a Buffalo Springfield recording as a Neil Young recording merely because it shows up on the Neil Young page because it is on a Neil Young retrospective album is clearly not correct. The API needs to be updated so that it doesn't have a problem with these fairly rare situations. We shouldn't have two pages for the same recording. Sean, how can this be corrected?    Kiefer    talk    contribs    admin   01:37, 20 May 2009 (UTC)
Yes I totally agree. It certainly does not seem correct or indeed a solution to this ongoing and extremely frustrating problem that we should be expecting or ask editors to create wrongly named song and album pages to compensate for flaws in the API.
Whilst I am aware of the incompatibilities, I must confess that I also find it very strange that in my time of being here only 2 users have complained of these issues, i.e. Senv and ES. However whilst not ideal, Senv has found a way to work with existing system. If the problem affected more users I'm sure something would've been done by now.
That aside, the answer is not to start undoing the good work that has been done by our editors in correcting page names, and by ourselves in educating them towards making good edits, etc. The answer lies with updating the API/widgets, etc. to work compatibly with the system that we have all discussed and have helped to create.  Яєdxx Actions Words 13:21, 20 May 2009 (UTC)
for a clear example see: David Wilcox (US) and David Wilcox (CA), one of the two is misfiled as far as the api is concerned. As far as web access is concerned, they are both fine. If this issue is not worthy, then all the moves of song/album pages for artists needing romanization was wasted effort, as well as all the moves done in order to have the artist name and artist portion of song name matching. fwiw Night Owl 18:17, 20 May 2009 (UTC)
Invisibility to the api is the reason these templates Track List, Track are not in general use, unless the policy on their use has changed. Night Owl 00:50, 21 May 2009 (UTC)
We try not to break the API on purpose, so those 2 templates aren't used. That does not mean, however, that we break site organizational rules for the API's benefit. Two different and unequal situations.    Kiefer    talk    contribs    admin   02:26, 21 May 2009 (UTC)
in David Wilcox (US) page, did you observe any problems? It breaks the api exactly the same way as NY&CH. For a properly done split, see Richard & Linda Thompson, songs split from Richard Thompson. Pages were moved to the correct name space matching the artist name, If that was a damaging edit, it hasn't been called such, yet. Not so with NY & CH. Another example: Laïs, anything noticeable? There are other examples...Night Owl 14:09, 21 May 2009 (UTC)

Laïs has been fixed now, at least. This might be a good place to address this issue: If you find an incorrectly named artist page, don't simply move it and leave the songs. All song pages need to be moved as well. If there are more than a couple and you don't want to do them by hand, let an admin know – we have access to a tool that will move any number of pages with only a few mouseclicks. — 6×9 (Talk) 14:29, 21 May 2009 (UTC)

Collaborative Songs

Do we have an artist name policy on charity singles where ∞ artists have contributed? I'm speaking specifically about Come Together Now (2005), but hopefully it can shed some light on other pages. Twenty-seven singers contributed to the song, so I wasn't sure what to name the song page. On the current edit of the page, the links go to "Various Artists:Come Together Now" but I don't like saying "various artists" is the artist. It would be murderous to put "[{{canonicalurl:Céline Dion, The Game, JoJo, Jesse McCartney, Nick Carter, A.J. McLean, John Legend, Joss Stone, Mýa, Gavin DeGraw, Chingy, Wyclef Jean, Ruben Studdard, Stacie Orrico, Kimberley Locke, Anthony Hamilton, Patti LaBelle, Natalie Cole, Aaron Carter, Brian McKnight, Kelly Price, Angie Stone, Garou, Tren'l, Glenn Lewis, Lee Ryan, R.L. Huggard:Come Together Now}} Céline Dion, The Game, JoJo, Jesse McCartney, Nick Carter, A.J. McLean, John Legend, Joss Stone, Mýa, Gavin DeGraw, Chingy, Wyclef Jean, Ruben Studdard, Stacie Orrico, Kimberley Locke, Anthony Hamilton, Patti LaBelle, Natalie Cole, Aaron Carter, Brian McKnight, Kelly Price, Angie Stone, Garou, Tren'l, Glenn Lewis, Lee Ryan, R.L. Huggard:Come Together Now]" (I can't even link to it, it's so long). iTunes calls the artist "Come Together Now Collaborative", but I think we need to look into creating a protocol for things like this (unless we already have one and I've missed it). --WillMak050389 22:05, 19 May 2009 (UTC)

If the artist is named like itunes, so the lyrics can be downloaded without gymnastics, then Come Together Collaborative:Come Together Now would work. Trying an artist page would create a page from out of this world! All the artists can be detailed in the Song Credits section, and on the album page credits as you have done. There was a similar case with Beyoncé et. al that I think was fixed by listing B as the Artist, and the others using fa (much smaller cast, though), and on itunes they have all the artists listed, comma separated, not a pretty sight. fwiw Night Owl 22:41, 19 May 2009 (UTC)
My question is less about this specific collaboration, but moreso I want to see us have a more official policy for things like this. Let's, for the moment, assume iTunes listed the artist as "Various Artists": How shall we name the song page? I know we try to shy away from Various Artists, and we already don't allocate an artist name to VA compilation releases, so should we just have the song page listed at Come Together Now? Or is there another way we could do this? --WillMak050389 22:44, 21 May 2009 (UTC)
I'll throw in an example: "Mongolia - Living Music Of The Steppes", iTunes & amazon list VA as artist for all tracks. Night Owl 23:04, 21 May 2009 (UTC)
I can think of at a few ways to handle VA songs (singles or albums).
  1. Use a page for VA artists and list all such albums/singles on that page. (least desirable)
  2. Use either the single/album title or abbreviated form of the title as the artist name.
  3. Use a unique numeric/alphanumeric code VA-Year-Mongolia. Night Owl 00:01, 23 May 2009 (UTC)
As far as I'm concerned it can only really be the names of the artists or a variation of various artists. One idea might be to list artists as "Multiple Artists" and list artists individually under credits section of song page. I saw this done once and it seemed like a good idea to me  Яєdxx Actions Words 05:27, 23 May 2009 (UTC)
@Will: Creating song pages without colons like Come Together Now; like an artist page, breaks LyricWiki:Page Names.
@red If a non unique name is desirable, see overcrowded Unknown Artist. Night Owl 08:36, 23 May 2009 (UTC)
I admit I haven't thought this properly through Night Owl, but I was thinking more of a unique artist name to be solely for such songs as Will has described, i.e. where there are simply too many contributing artists to name in the artist parameter of the song page.
Whilst these situations do not occur that often (the last time I recall this subject being raised was with The South Park album), it is something that, like Will, I would also like to see resolved.  Яєdxx Actions Words 12:41, 23 May 2009 (UTC)
As long as we link to the song on the release page, it shouldn't matter that we use a non-unique artist name in the artist portion of the song page name (I'm not sure if people are confused with me, but I do NOT want artist pages for these collaborative one-off projects). So, I think we could use "Multiple Artists" or "Collaboration".
@Night Owl: As for breaking LyricWiki:Page Names by making a song page at Come Together Now, it would be a exception to the rules, just like leaving out the artist name for any VA compilation album/release. The problem we might run into though, but only by extreme coincidence, is if two collaborative songs have the same exact title. --WillMak050389 00:46, 24 May 2009 (UTC)
@Will: No artist page, true. Collaboration as artist value, so Collaboration:Come Together (2005) which takes of care of identically named collabs, as long as not in same year, or Collaboration:Come Together (2005-06) for month (in case of two in same year). Having the Artist value Collaboration satisfies the Song Header & Footer as well. The Individual artists listed in the credits takes care of the links to individual artist pages. Night Owl 01:20, 24 May 2009 (UTC)
Yes I don't like non artist artist pages either. I also don't want to start appending artist names to various artist albums. The current system works well and that is not the issue here. I am merely suggesting we substitute "Multiple Artists" for the artist portion of the song page name where there are too many artists to list.  Яєdxx Actions Words 01:30, 24 May 2009 (UTC)
I have a feeling that these really need to be worked on on a case-by-case basis, so a specific protocol might be a bit difficult to come by. It's all a matter of what is the best fit/description of the group of artists. "Come Together Now Singers:Come Together Now" or "Come Together Now Collaborative:Come Together Now" both seem like good solutions. It's like the "what to do with albums of musicals, such as High School Musical?" question. Do you have a single "artist", or do you list each song by its singers? Do you use the composer? (Andrew Lloyd Webber, anyone?) USA for Africa had it's own group name, so that made things a bit simpler, didn't it?    Kiefer    talk    contribs    admin   01:37, 24 May 2009 (UTC)
@Night Owl: Wow, I'm an idiot. I didn't realize that "Multiple Artists" would have the same run-in problem as no artist. This problem would also come up with "<<Song Name>> Collaborative:<<Song Name>>".
Another option (similar to bibliographies) would be to take the first listed artist and append "et al." This should avoid any ambiguous pages (two songs with the same name). So, with particular song, the page would be Céline Dion, et al.:Come Together Now. Is that any better? Or worse? --WillMak050389 02:08, 24 May 2009 (UTC)
Aren't "No Artist" orphaned type songs? If so the problem should not occur with artist name being "Multiple Artists" and detailed on an album page. No?  Яєdxx Actions Words 00:24, 26 May 2009 (UTC)
The problem I was referring to was one that could come up if two collaborations made two different songs with the same name. If we had the song page at "Multiple Artists:Come Together Now" and another group came along and performed a different song named "Come Together Now" we wouldn't have a place to put it, unless we disambigged the two pages. Again, this would be a very rare occurrence, but something we should at least think about.
My solution of using "et al." should narrow the possibility even more. But "et al." would break capitalization rules" and we'd need to use "Et Al." which kinda looks dumb. (Unless we make an exception for it) --WillMak050389 00:44, 26 May 2009 (UTC)
For Singles: the idea of using the Primary Artist as the artist, put as many as fits in fa, then the rest of the artists in the credits section may be worth a second look.
For Albums:Kiefer brings up a good example (high school musical), I came across one recently: Notre Dame De Paris, a musical that turns out to have Composer and Lyricist as artist (thus my move request on the page, even though lw seems to require the performing artist). In the case of High School musical, it seems the artist page is redundant, as there is no such artist! It's just a series of compilations. The High School Musical Cast can be a disambig page for the compilations, or it can be a list, but a real artist page seems illogical. The songs that were performed by the cast have "CHSM" as artist value, which will not have any conflicts, the rest are by named artists, as any compilation. thoughts? Night Owl 02:12, 26 May 2009 (UTC)
And then, in the case of musicals, sometimes the perfoming artists are listed by their character name e.g. "Sharpey" instead of by their actual name. And yes indeed the male composer who is the female vocalist and full orchestra....Honestly, why does life have to be so damn complicated? Rfl.
Ok well I think we should continue deciding most of these on an individual basis as to what is appropriate. I also think we should simply go with the artist name = multiple artist for any songs that include 3 primary artists or more (by which i do not mean "featuring", as these artists should simply be listed in song template). As for the unlikely possibility that two such songs have the exact same name, this can be dealt with at the time.  Яєdxx Actions Words 04:55, 26 May 2009 (UTC)
@Red: Can you give an example song page that matches what you defined? And if you take a look at High School Musical Soundtrack (2006) and examine the linked mb page for the album, then it seems most of the songs have the wrong artist in the Song Template (but on the album page the correct artist is indicated). How about Category:Pages Needing Artist Identification? There are plenty more like that in cat:Hometown Unknown. Night Owl 04:40, 27 May 2009 (UTC)

(Outdent) Wikipedia informs re High School Musical album: Drew Seeley sang in several of the songs, his voice being mixed with Zac Efron's. He originally was not given credit for singing. That explains the differences between us and musicbrainz, (though I'm not too sure we have correctly listed the last 2 tracks).
Category:Pages Needing Artist Identification seems a good idea so thank you for creating that. I have actually been working through the Disney pages over recent months trying to establish the actual artist for those songs. (I also restored Category:007-Redxx)
As for an example, I'm not too sure what you mean but I'll propose Chef Aid: The South Park Album (1998).  Яєdxx Actions Words 16:57, 28 May 2009 (UTC)

All the songs in Chef Aid: The South Park Album (1998) are single performer songs, and the track list artists matches exactly what is on itoons. A correctly formatted compilation.
The issue about the term Various Artists is that it's bogus. Here at lw, it has been correctly chosen that Various Artists (or variations thereof) are never used. When we don't have a single artist for an album, it's a VA album, but we never use Various Artists as the artist portion of the album or song page name, we just drop it. You can browse mb for how they use it. For those who don't have itunes; I'll explain further: When a CD is inserted, iTunes retrieves track data (from gracenote) and inserts them into the itunes library, so one never needs to manually enter artist, song, composer etc. In cases of VA albums, sometimes the information submitted by individuals to gracenote was done sloppily, the artist for all tracks was submitted as "Various Artists", "Cast of Camp Rock" or "Cats". That is how we end up with misnamed compilation tracks and that is how almost every other lyric site currently names them. There are two fixes to this: One is submit the correct track /album meta data via itunes and at the same time correct the track data in one's own toon library (and for future users), the second is to correct these track/album names here at lw. If one has itunes to begin with... To the best of my knowledge, there are extremely rare cases where the artist of a track is truly "Various Artist" (as printed on the cover or in itoons). For cases of collab Singles as was Will's question, we have fa param in SongHeader (up to six artists), and 7th to 99th artist can safely fit in the credits section, which links them to all the artists involved. Night Owl 21:04, 28 May 2009 (UTC)
Ozzy Osbourne, DMX, Ol' Dirty Bastard And The Crystal Method:Nowhere To Run a 'single performer song'?  Яєdxx Actions Words 11:14, 29 May 2009 (UTC)
And that's where fa would be used, just like the 27 artist example. Night Owl 18:56, 29 May 2009 (UTC)
No that would be incorrect since there is no primary artist.  Яєdxx Actions Words 19:02, 29 May 2009 (UTC)
Actually, I believe in this case, yes. They should be treated as a single entity. Four names is certainly not too unwieldy, and that is how they are credited on the album, not as Ozzy Osbourne with the others as featured artists. It's not causing any problems the way it is, is it?    Kiefer    talk    contribs    admin   18:54, 29 May 2009 (UTC)
Or you may want to check Crossroads: Eric Clapton Guitar Festival 2004 (2004) or Crossroads: Eric Clapton Guitar Festival 2007 (2007), watching the DVD helps too. Each song has a stellar array of axemen, represented in fa, whether song is Instrumental or has lyrics. As a CD or DVD, it's still a compilation.
Those songs with (4 official artists, Ozzy etc.) will be submitted by other contributors with artists entered in different order, and janitor will create new Artist pages for them, (because they are not linked on any pages). How about the maintenance, and avoiding edits on one song getting scattered over many pages? See the multiple redirects pointing to A. R. Rahman:Jai Ho. And what is the limit on how many artists in page name of a song page? Night Owl 19:19, 29 May 2009 (UTC)
Crossroads..lots of wrongly named song pages where someone has decided for themselves to select one artist as the primary artist and add the others as featured and where the song pages linked to do not relate to the album.  Яєdxx Actions Words 20:23, 29 May 2009 (UTC)

Green albums...

Since album pages aren't created by bots (though artist pages I believe can sometimes be for Other Songs...) can we set the default on template for all/new albums to Bronze?  Яєdxx Actions Words 12:55, 20 May 2009 (UTC)

[3]6×9 (Talk) 17:42, 20 May 2009 (UTC)
Not only there are lots of bot created albums from years gone by, there are plenty false artist pages (created by bots) that should be converted to albums as well. Night Owl 17:48, 20 May 2009 (UTC)
Ok thanks guys.  Яєdxx Actions Words 22:55, 22 May 2009 (UTC)

TOC

I would like to see the Related artists (with capital letter perhaps??), Genre and Labels in TOC. Would anyone else prefer this too?  Яєdxx Actions Words 12:57, 20 May 2009 (UTC)

Capital letter? You mean, like in "External links"? Either way, I'm quite happy not to have them cluttering up the TOC. — 6×9 (Talk) 18:32, 20 May 2009 (UTC)
I bet you put your remote control away in a drawer so it doesn't clutter up the place instead of having it on the arm of your chair ;)  Яєdxx Actions Words 04:50, 23 May 2009 (UTC)
To a new visitor it may not always be immediately obvious upon opening an artist page that 'Related Artists' are listed somewhere near the bottom. Perhaps it would be far clearer that there may be albums by the same artist under a different name if 'Related Artists' appeared in TOC. Could TOC be collapsible to give that minimalist look? Is TOC any more cluttered than the bottom of the page with the seemingly ever increasing number of categories? — The preceding unsigned comment was added by Notime2cry (talkcontribs).
Isn't the TOC collapsible anyway? (I usually have scripting disabled and don't want to turn it on just to check…) And I'm already trying to reduce the category clutter by making at least the hometown ones hidden. Same could be done for labels and genres, since they also have visible links elsewhere on the pages. Anyway, I could see the value of restoring R.A., but Genres and Labels as well would be overkill. — 6×9 (Talk) 00:11, 25 May 2009 (UTC)
I disagree. I think these links would be useful if they appeared (like they used to) in TOC.  Яєdxx Actions Words 02:20, 25 May 2009 (UTC)
Apologies, TOC is collapsible but is shown upon viewing the page with the option to hide.  Ñôīέ2çяȳTalk 11:22, 25 May 2009 (UTC)
I agree with Red, I'd like to be able to jump to these sections from the TOC. Also, if we only include a section link to Related Artists, we won't be able to jump down to Genres or Labels if a specific artists has no Related Artists section, so I think we should include section links to all three. Also, wouldn't mind seeing a section link to External links either. It's kind of a style rule to have all of the sections listed in the TOC. Any new user, or a passerby on our website, might think that there is nothing useful down at the bottom of the page. --WillMak050389 14:14, 25 May 2009 (UTC)
I think it is possible to get the best of both worlds. Put a Goodies link on top of page (or at end of TOC) that takes the user to bottom of page, where they can see whatever is down there (genres, labels, RA, Appears On, External Links, etc.) Night Owl 14:24, 25 May 2009 (UTC) just recycling an old idea
Thanks for that proposal Night Owl but not enough of an annoying factor for 6 ;). Seriously though I think it would be more useful, particularly thinking of new users, to state these links in TOC.  Яєdxx Actions Words 00:18, 26 May 2009 (UTC)
I don't know...I must have missed the discussion where these items were removed from the TOC. That is why the TOC is there, after all, as a shortcut to places on the page - especially places down at the bottom of the page, I would think. I know that we all kind of think of the TOC as a listing of the artist's albums, but like WillMak stated, it is meant to be more than that, even if it is primarily that on this site. I vote for a restoration, as well.    Kiefer    talk    contribs    admin   01:35, 26 May 2009 (UTC)
There was no discussion and there was no objection. The old format Labels, Genres & RA were all inadequate. AF params whether filled or not , don't show in TOC either, even though they are useful, good for researching the artist, and bring in some revenue. Categorizing meta data may be more important than TOCifying.Night Owl 16:31, 29 May 2009 (UTC)
LOL - No discussion would certainly mean no objection. The old formats weren't inadequate, except that when things move to Semantics then the Page Rank system can be more automated if they are templatized. The changes should still have been discussed before they took place. Because they weren't, we're having a rather heated discussion now and having to consider undoing the work that had been done. Shortsightedness with the RA and destruction of information and function malleability has caused discussion there, and removal of these items from the TOC has caused discussion here. Discuss...Get Consensus or Compromise...then Act.    Kiefer    talk    contribs    admin   18:54, 29 May 2009 (UTC)
If you follow the discussion further up about RA, I provided examples that was neither deemed inadequate, nor overburdened. How does one interpret the silence of the participants?!Night Owl 19:11, 29 May 2009 (UTC)
(Colonies are out of fashion) There was discussion about Labels and Genres template, though only on the admin portal. IIRC, Red was all in favour then. Took you long enough to notice they don't show in TOC… Can't be all that important then, right? Yes, I could have announced the removal from TOC, but I assumed people would actually test them before approving… Also, no matter how thoroughly impending changes were discussed here in the past, more suggestions would invariably come in after the change (sometimes right on the heel).
On the topic of automatic page ranking, we don't need Semantic for that, but we will need to templatise everything that is relevant to PR. Even if turning it into a template means more work, rather than less.
With that in mind, how about creating an infobox to hold that sort of information? We'd get one entry in the TOC that way (instead of four or five for Genres, Labels, RA, Members, Pets…), we could save a bit of space (by putting G & L in a second column), it'd look neat, AND I'd get to make a table :-) It wouldn't complicate things really; in edit mode it could look like this:
{{ArtistInfo|info=
{{H1Fake|Band Members}}
*blah blah
*blah blah some more
{{RelatedArtists|first one|second one}}
*{{wpi|third one}} who has a wp article
|{{Genres|...|...}}
|{{Labels|...|...}}
}}
…meaning we could just wrap it around any currently existing informational sections without changing anything (other than converting wiki headers). — 6×9 (Talk) 21:21, 29 May 2009 (UTC)
Even earlier than Genres & Labels, the old Hometown template didn't showed up in TOC (Kiefer was likely one admin who approved that), nor is there an example of a template that shows up in TOC anywhere here on lw. Night Owl 21:38, 29 May 2009 (UTC)
I'll skip the irrelevant stuff about Hometown templates etc and say I still think {{Labels}} and {{Genres}} are great. And I would also consider it a good compromise 6 if there was only one appropriately named entry in TOC linking to Labels, Genres, Related Artists and Group Members at bottom of page. But we've still got to sort the problem of the Related Artist info. Any ideas for resolving that?  Яєdxx Actions Words 23:38, 29 May 2009 (UTC)
I think we've got enough real problems, we don't need to create artificial ones. The current RA template is fine for just creating links, if you want links + text you put them below or leave RA off entirely (since it's optional anyway). Once we decide to automate page ranking we'll have to think of some compromise between homogenisation and individuality we'll probably need an extra server for the discussions but currently we're just turning in ever-increasing circles over an issue that doesn't even exist.
In the meantime, there are already several other topics on this very page which want resolving, and there's also the matter of MusicBrainz following suit after Discogs and introducing "release-group" pages which don't work with our AlbumFooter parameter… — 6×9 (Talk) 00:02, 30 May 2009 (UTC)
Issue that doesn't even exist? 4 people are saying they would prefer RA etc in TOC, Me, Will, Kiefer and Notime. You have proposed a solution. That is an issue that does exist and which you are, through your proposal, seeking to resolve. I hope the others in this discussion will accept your proposal.
But unless I've missed something, the problem of not having an addtext parameter to the side of the artist link in the Related Artist template, etc. does exist and has yet to be resolved. However, until it is I will do as you suggest. I only hope that other editors will heed the note Kiefer has put at the top of the page and not seek to revert any edits I make, old stylee, in favour of adding text underneath.  Яєdxx Actions Words 00:35, 30 May 2009 (UTC)
I wasn't talking about the TOC bit (because you weren't either when you asked me for ideas). I already explained several times why making the RA template accept non-linked text in any way, shape or form would defeat its purpose, and why it's unnecessary. I've yet to receive an answer to my question why users can't simply put anything that isn't a plain wikilink below the template. — 6×9 (Talk) 00:46, 30 May 2009 (UTC)
Like the example on the Joe Satriani page? Because it makes more sense for the info to be beside the link and so far as I am personally concerned because I think it looks pretty bad in operation as two separate sections. (I did actually post that somewhere today too.) Anyway I think Kiefer has proposed something above that might help to resolve this.  Яєdxx Actions Words 03:42, 30 May 2009 (UTC)
"I already explained several times why making the RA template accept non-linked text in any way, shape or form would defeat its purpose." In the sea of words, I think I've missed this and can't find it, unfortunately. Could you reiterate?
Also, that the removal of these items from the TOC wasn't mentioned when it was done, assuming that people would somehow notice was obviously not a good thing.  :-] There is just too much going on to notice such a thing. I look at what is being added/removed information-wise, how the finished product looks and is integrated on the page, but I'm certainly not looking for a change in such non-obvious things. I just don't have the time. I have usually 2 or so hours to spend on the site each day. I'm not looking for hidden stuff like that, and we really shouldn't be expected to.
In the end, if there can be a compromise where there is a link to "Artist Information" in the TOC that includes Group Members, Related Artists, Genres, and Labels (am I forgetting anything?) I'm for it.    Kiefer    talk    contribs    admin   04:05, 30 May 2009 (UTC)
Did I miss something? Is this really how RA has got to look from now on and is it preferable to RA in TOC ? Are 'Genres' and 'Labels' to got at the top of the page too?  Ñôīέ2çяȳTalk 17:48, 4 June 2009 (UTC)
Nope. The result of the recently archived discussion was that tl:RA is no longer to be used. The question now is: should we go back to leaving it untemplated, should we create a host of templates for RA, members past and present, collaborations… (each with their own TOC entry) or should we create a nice infobox template instead that will hold all of the above plus Genres & Labels, with one TOC entry? (Replies to the left, please.) — 6×9 (Talk) 19:24, 4 June 2009 (UTC)
???? Corrected the template placement.  ????    Kiefer    talk    contribs    admin   23:19, 4 June 2009 (UTC)
the fault of tl|RA is the same as the fault of Genres & labels (if that is a fault) that it doesn't show in TOC. Many pages (from as far back as 2 years ago) were using the non template RA which I updated to use the template so they can be accessible from the links to tl|RA page [4]. Does the community consider that a step back?! Can we start a discussion on how we go forward from here? Is removing tl|RA a positive outcome? Night Owl 07:09, 5 June 2009 (UTC)
The fault of the Related Artists template is not the same as the fault of the Genres & Labels templates in that it doesn't show in TOC. The fault of the Related Artists template is greater than this. This is why Genres & Labels are still being used and the Related Artists template is not.
The primary fault of the Related Artists template is the loss of functionality, i.e. to add optional explanatory text next to each artist's link to explain their inclusion in the list.
As 6 has indicated above, to progress this, what needs now to be decided is should we leave it untemplated, should we create a host of templates for RA, each with their own TOC entry, or should we create an infobox template that will hold all this information plus Genres & Labels, with one TOC entry? For which a new discussion is I believe soon to commencee.  Яєdxx Actions Words 08:32, 5 June 2009 (UTC)
Nobody knows how many artist pages have RA info without a template (disadvantage), they need to be updated with whatever will replace it. The ones using tl|RA don't have additional info indicated, but they can be found and updated. So let's start the discussion instead of going backwards... Night Owl 08:39, 5 June 2009 (UTC)
Excuse me? If you avoided making misleading remarks, I wouldn't feel that as an administrator I needed to explain these for the benefit of the community.  Яєdxx Actions Words 09:33, 5 June 2009 (UTC)
When the original discussion came up on 6times 9's talk page about expanding/adding to the tl|RA, two administrators were against such addition/expansion. Do you recall who those two admins were? I ask again: Can we go forward? Night Owl 09:53, 5 June 2009 (UTC)
I say again will you please cease with the misleading remarks. The original discussion on 6times 9's talk page (to which I believe you must be referring) was not about expanding/adding to the tl|RA. It was about the creation of a Band Members template.  Яєdxx Actions Words 11:55, 5 June 2009 (UTC)
Closed
If you wish to advance this discussion, please commence this under a new heading below.

Dutch?

Is there anyone who speaks Dutch around here? I was hoping someone could certify Counting Crows:Wennen Aan September for me, please. - ezekiel000 07:41, 26 May 2009 (UTC)

Nevermind I found someone to check it. - ezekiel000 17:53, 26 May 2009 (UTC)

Previous/Next Song links

Don't know where to put this so I'll just pop it in here: It would be a really really good idea to have link to the previous and next song in an album on a songs page. This would allow the user to quickly and easily go through an album's lyrics without the cumbursome: "Click on Artists name, search for album, locate song in album, click it". Go ask some dark perl wizard to hack together a program to automate most of it. It would also be great if someone got together with Amarok and other open players to create a small .rtf file (so formatting can be preserved) on each page that can be downloaded by the programs. Sorry. I am lazy. — The preceding unsigned comment was added by 68.0.132.72 (talkcontribs).

I've been wondering if it would be a good idea to have something like this for album pages as well so you can flick to the next album by an artist. - ezekiel000 16:52, 26 May 2009 (UTC)
See {{Footer Nav}}.  Яєdxx Actions Words 16:57, 26 May 2009 (UTC)
See also this archived discussion. — 6×9 (Talk) 00:45, 27 May 2009 (UTC)

Roger Whittaker

What is the correct country value for Roger Whittaker? Night Owl 16:22, 29 May 2009 (UTC)

Category:Hometown/Kenya  Яєdxx Actions Words 18:39, 29 May 2009 (UTC)
Surely that is very useful to Americans and Kenyans :) Night Owl 18:50, 29 May 2009 (UTC)
For him...Kenya. Usually if an artist is associated primarily/strongly with a certain location, then that would trump birthplace (such as with Eminem, who was born in Missouri, but is associated as an artist with Detroit), but in this case, he's Kenyan, English, and Irish and who knows what else without reading his autobiography. So, yeah...Kenya is good. Don't freak out over it, though. If a knowledgable Whittaker fan comes around, then perhaps they'll have a more informed view and change it.    Kiefer    talk    contribs    admin   18:54, 29 May 2009 (UTC)
I am his No 1 fan ;)  Яєdxx Actions Words 19:59, 29 May 2009 (UTC)
The Funny bit is Roger Whittaker, and a large number of artists whose wp article declares them "African American". Does hometown mean place of birth or where is home of the artist. For reference, see Michaëlle Jean. Night Owl 21:55, 29 May 2009 (UTC)
The help page states that place of origin (for bands) or birth (for people) is to be used, no mention of exceptions. I'd prefer to keep it that way; it's a simple rule, more detailed information is usually available at one of the links a bit higher in the same box, and we won't have to constantly update parameters for artists who refuse to stay in one place. — 6×9 (Talk) 22:02, 29 May 2009 (UTC)
Yes I would prefer not to make exceptions too Kiefer. Making exceptions is where things can get difficult and conflicts arise. Place of birth please.  Яєdxx Actions Words 22:43, 29 May 2009 (UTC)
It's not an exception, it's the way it's been. Just for the reason where someone is born someplace as a child, but spent much of their life (and artistic lives) elsewhere. For instance, I was born in California, but only lived there as a baby. I do not in any way identify myself as a Californian. That the Hometown should refer to the place of birth was something that you edited onto the page on January 4, 2009. (*busted*  :-]) Wikipedia differentiates between place of birth and such a hometown with the Origin notation in the box, as shown with Eminem.    Kiefer    talk    contribs    admin   03:23, 30 May 2009 (UTC)
I'm saying nowt ;) But this is something on which me and 6 completely agree and for all the right reasons. Place of birth is something that everyone can agree on and which won't lead to reverts due to personal opinions. So with this very much in mind, can we leave it to be place of birth with only .0000001 exceptions? Please? ;)  Яєdxx Actions Words 03:48, 30 May 2009 (UTC)
Yes, 99.99% of the time (give or take a few), it probably isn't an issue. A hard-and-fast rule makes for an easy bureaucracy, but sometimes is inadequate. I'm glad that you and 6x9 have managed to agree on this... :-] ...but while I agree with you also, I am willing to admit that there are going to be some exceptions. Wikipedia recognizes this situation...why can't you?  :-] <-- BIG! Really, really BIG! oh, she's gonna hurt me....    Kiefer    talk    contribs    admin   04:05, 30 May 2009 (UTC)
You are a wicked man Mr Kiefer so you are! Especially as I was acknowledging the need for flexibility by proposing a very generous .0000001 for "exceptions" ;)  Яєdxx Actions Words 06:27, 30 May 2009 (UTC)

Page Ranking Review

Hi. I have been trying to finalize Asa's pages: Aṣa, but didn't dare go higher than Bronze level for now. Is there some kind of review process or should I just go ahead and award myself more stars as I see fit? Since I'm relatively new at this, I'm also wary of having done non-pagerank related errors that wouldn't warrant, say, a gold star. Thx. Monotone 13:01, 30 May 2009 (UTC)

You should check this and this. Em, I think that the english songs from Aṣa are ready to be Gold. The non-english need a translation and the artist page the {{Genres}} and {{Labels}}. You can upload an image for the artist too if you want. Use the |pic = parameter at ArtistFooter for that. Titaki 13:41, 30 May 2009 (UTC)
Cool. I will add genres, labels, and a request for translation since I don't understand Yoruba, nor do I plan to. :) Monotone 14:38, 30 May 2009 (UTC)
P.S. Hey thanks for the hand with that Info banner. Hehe. Small details! 14:53, 30 May 2009 (UTC)
You're welcome. :) Titaki 15:00, 30 May 2009 (UTC)

Category:Pages Needing Artist Identification

This is what I'm talking about with regards to work being done before discussion is complete. Not liking the way something has been done and then slapping a "we need to fix this"-type category on it before a resolution has been achieved (that even defines what actually needs to be fixed) is not the way to go. Discuss - Solve - Edit. Not: Discuss - Edit - Discuss More - Edit More - Discuss Even More - ad infinitum. I'm going to be hardcore about this, guys.    Kiefer    talk    contribs    admin   19:47, 30 May 2009 (UTC)

Please See the talk page for the category, and the Information on the category page. The only edit was to Notre Dame De Paris, as per external references for the artist name. The other 29 artist pages in the category are awaiting research and edit, if any, by others. Step 1 in noticing a problem, is researching who the real artists are, as was done with Notre Dame De Paris. What am I missing? Night Owl 20:00, 30 May 2009 (UTC)
What you are missing is that a category has been created that gives the impression that these items have already been decided by the community as needing fixing. The discussion needs to be finished before such categories are created and therefore community action takes place. Everyone gets too antsy to get to work on these items and then problems mount. The fact that you and 6x9 are discussing this situation in an area that isn't likely to be on anyone's watch list is not a selling point for this category, either.    Kiefer    talk    contribs    admin   20:29, 30 May 2009 (UTC)

Server changes tonight... things to be aware of

We are adding a new server into the mix. Actually, it's in the mix. If you've noticed temporary outages over the past hour, those are related to restarting the main server which is "in front" of the rest of them.
Currently, the only remaining issue to fix is that uploading of files may not work as desired. This will be fixed as soon as possible!
Thanks,
-Sean Colombo (talk|contribs) 07:04, 31 May 2009 (UTC)

Uploading appears to be behaving quite nicely now. There are no immediately apparent bugs. It seems everything is going great. Not only that... the site seems significantly faster to me (as it should be! we doubled the amount of memory for memcache in the system and the number of quad-core apache servers running the site!). :D
That worked out well. Good evening,
-Sean Colombo (talk|contribs) 07:34, 31 May 2009 (UTC)
Seems faster to me too Sean. Good stuff!  Яєdxx Actions Words 00:30, 1 June 2009 (UTC)
Don't know if that has any connection to these changes, but some strange things are going with file upload:
  • trying to upload a new album art by clicking on created link for it works normally in IE but brings me to the login page in FF.
  • Uploaded (via IE) album art looks ok on artist, but not on album page. (If that's going only on my box - here's screenshot 20px).
  • Btw, I even can't see normal look of this screenshot in preview - it's replaced by the same err msg "Error creating thumbnail: convert: unable to open image..."
--Senvaikis (talk) 07:09, 1 June 2009 (UTC)
P.S. Damn, some time ago thumbnail was normally displayed on the page; now it looks exactly as in preview - replaced by errmsg (same on IE & FF)...
P.P.S. lol - after ps saving it's displayed normally again... :) Have you fixed that already, Sean?--Senvaikis (talk) 08:26, 1 June 2009 (UTC)
Talking to yourself is the first sign of madness Senv ;).
Yes you're right about strange things going on with file upload in FF, certainly following link via album page which takes you to a log in page even though logged in.. OK in IE6.  Яєdxx Actions Words 15:07, 1 June 2009 (UTC)
Not only upload – after moving File:22765484v6 240x240 FrontCover.jpg to File:The Klein Four - Musical Fruitcake.jpg the image and its thumbnails appear to have been lost. — 6×9 (Talk) 15:21, 1 June 2009 (UTC)
Also see Special:NewFiles, uploading via IE works but error occures when putting image on artist page. Ñôīέ2çяȳTalk 01:00, 2 June 2009 (UTC)

The reason for all of this weirdness is that I didn't foresee these problems in load-balancing. But they each make sense individually. EXPLANATION:
When you upload an image, it gets put on one of the Apache servers (named "pedlfaster"). When you request an image with "/images/" in the filename, you will be served that image from pedlfaster. However, thumbnail generation appears to be done by the code checking to see if the file exists, then generating it. If for example, you upload the picture to pedlfaster, then on a later page request is filled by the other Apache server (named "leonidas"), then leonidas will look for the image, and see that it's not there yet and give you the error. To confuse you further... every 2 hours, pedlfaster syncs to leonidas, so your error messages will go away in a random amount of time, approximately two hours (and about half of your requests until then will go to pedlfaster anyway and will probably work. I will be adding an extension which will immediately sync the image to the other server(s).

  • Thumbnails aren't being generated because I think the parser looks to see if they exist and then creates them.
  • Moving the file is an interesting trick. Not sure the best way to do that yet.
  • Apparently logins are specific to domains, so when you're sent to upload.lyricwiki.org, your login isn't considered valid anymore (which raises the question of how anyone is staying logged in long enough to upload anything). Fixed logins.
  • Initial thumbnails are now created, but leonidas may attempt to resize them before it has a copy. There is no hook for when a thumbnail is created unfortunately (might be able to write a subclass and put it in $wgMediaHandlers).

Sorry for all of the confusion,
-Sean Colombo (talk|contribs) 01:06, 2 June 2009 (UTC)

Things are still misbehaving.
  1. Rsync doesn't appear to be getting called by uploads anymore.
  2. Moves, resizing, deletion, etc. don't work. Some of this could be caused by the failed rsyncs.
    1. Moves should all be served by pedlfaster. Both the source and destination directories should be synced after a move (with --delete on the source dir).
-Sean Colombo (talk|contribs) 16:05, 11 June 2009 (UTC)
UPDATE: It was really security protection that was "protecting" us from ourselves. However as I thought about it and began to understand more about how MediaWiki handles all of this... it occurred to me that this is basically going to have to be done a completely different way. This is going to be a little tricky from what I understand, but it will be better in the long-run and more like Wikimedia's architecture (which is generally a good thing because we can learn from their mistakes).
In the meantime, I've set the servers to sync up images every 10 minutes (previously this was happening every 2 hours).
I'll update again once I have a better idea of when the new system will be up.
-Sean Colombo (talk|contribs) 20:32, 11 June 2009 (UTC)
I think I've finally gotten it fixed the "right" way (using NFS like Wikimedia does). If you see any image problems such as missing thumbnails, please let me know because they aren't expected any more. Even if it would have worked the other way, this way is better.
-Sean Colombo (talk|contribs) 04:31, 13 June 2009 (UTC)
Ok will do. Thanks Sean. Яєdxx Actions Words 10:06, 13 June 2009 (UTC)
Yes here's a problem one Sean The Little Mermaid (1989) and here's the file Disney - The Little Mermaid.jpg  Яєdxx Actions Words 18:51, 30 June 2009 (UTC)

(Pagesize = 136,107)

Community content is available under Copyright unless otherwise noted.