LyricWiki talk:Community Portal/Archive/2009 2

From LyricWiki

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
<< January 2009	February 2009	March 2009 >>

Contents 1 Bands with different names in different languages 2 Arja Koriseva's songs (or what to do about unfixable encoding problems?) 3 Arashi 4 Policy about lyrics 5 OOoooge Files 6 Parental Advisory templates 7 Official Lyrics 8 Proposing changes to the Billboard Hit template 9 Artist Subpages 9.1 Navigation Templates 9.2 Uniformity of Artist Subpages 9.2.1 Vote on separator 9.2.2 Naming after separator 9.3 Nutshell 10 wikEd 11 Edits by: "autogen. song page (WLv0.13.3)" 12 {{Albumcover}} 13 {{Cover}} 14 UK Singles Chart badge Top 20 badge 15 {{Artist}} template 16 OOOoooge artist pages, transclusion, (bots) & the API 17 S2E2 overly zealous...

[edit] Bands with different names in different languages

I just signed up and was reading the policy and noticed the policy about page names of "Non-Latin Character Sets". I am wondering how this policy applies to artists with two names, one in English and one in a non-Latin character set.

Specifically I'm working the lyrics of one of F.I.R.'s songs. The band has two names, one in English (F.I.R.) and one in Chinese (飛兒樂團) and often the two are used together. According to the page naming policy, should the band's name be "飛兒樂團 (F.I.R.)", or should it be something else? (It is currently named simply "F.I.R.")

Thanks for any clarifications.—Gniw 05:55, 1 February 2009 (UTC)

"飛兒樂團 (F.I.R.)" ∃cho⚡ierr∀ (☏) 06:21, 1 February 2009 (UTC)

Thanks for the clarification. But the F.I.R. page already exists and has already been edited by several people. Can the new page be deleted and the old page be renamed instead? Or should I move the old contents from the old page to the new page and make the old page a redirect? Sorry for the trouble.—Gniw 06:50, 1 February 2009 (UTC)

I'll merge them to the new name right away ∃cho⚡ierr∀ (☏) 07:14, 1 February 2009 (UTC)

done ∃cho⚡ierr∀ (☏) 07:24, 1 February 2009 (UTC)

As an explanation: Whatever the official name of the Artist is, that's what should be used. In the case of Non-English Artists, then a parenthetical add-on with the English translation should be added.    Kiefer    talk    contribs    admin   13:08, 1 February 2009 (UTC)

Hmm. I'm now confused. Perhaps I was not too clear. In this case, both names are simultaneously "official" and one of them happens to be in English (and in this case the English name probably came first, the Chinese name was probably derived from the English one). Sometimes one name is used, sometimes the other, and sometimes both, so it's hard to say what what "the" official name of the band is because any combination is official.

So can we say if a band has two names, each in a different language (and each of them simultaneously "official" and not necessarily the translation of the other name), then the "official non-English name (official English name)" format should always be used regardless of how the names are related? Or should this be decided on a case-by-case basis?

Sorry for these questions.—gniw 16:10, 1 February 2009 (UTC)

Ok, I think I get it now. It is the way it is because when you translate the official non-English name you just put in the English official name.—gniw 16:40, 1 February 2009 (UTC)

The questions are good, because I don't think we've come across such a situation. In this case, this artist might require some further investigation. We try to have every Artist/Album/Song as close to "official" as is possible, barring certain MediaWiki limitations, and with the addition of the English add-on for Artist names in Japanese and Chinese. In this case, when I translate the artist's website using Yahoo's Babelfish, it appears as if they use merely "F.I.R." as the band's name. Which means that the page possibly should be at F.I.R., with redirects to that page placed on 飛兒樂團 and 飛兒樂團 (F.I.R.). (As a bit of a digression, Babelfish says that 飛兒樂團 translates as "Flies the orchestra". Weird.)    Kiefer    talk    contribs    admin   04:31, 2 February 2009 (UTC)

The F.I.R. name comes from the initials of the band's members. For the Chinese name, 飛兒 is basically the transliteration of F.I.R. into Mandarin (which also explains Babelfish’s weirdness; transliterations are usually nonsense if taken literally), and 樂團 (which usually does mean “orchestra”) is just a fancy word for “band” here.

You are quite right that the official page seems to almost exclusively just use "F.I.R." right now (except the page title itself, which uses both forms). But I have a feeling that this has not always been the case. Evidence of this is the name of their first album, which is often (including in this wiki) listed as "飛兒樂團 同名專輯"(meaning "飛兒樂團, an album with the same name [as the artist]"), implying that at least at the start the Chinese name was also quite a bit more official. (It might be interesting to note that this first album also has a parallel official English title that is not even mentioned here.)

I guess I’m also at a loss as to what the official name should be, though I don’t have an objections if it’s decided that the band should be at “F.I.R.”.

BTW, there’s a similar situation with another band currently listed at 飛輪海.—gniw 04:56, 2 February 2009 (UTC)

[edit] Arja Koriseva's songs (or what to do about unfixable encoding problems?)

I was browsing SNLI and decided to pick some songs that looked like Finnish. Then I discovered that all of Arja Koriseva's songs have encoding problems that can't be fixed by the browser's Encoding menu. What should be done about these pages?—gniw 10:46, 1 February 2009 (UTC)

Best thing to do is fill in the language param in the SongFooter. hth ∃cho⚡ierr∀ (☏) 11:06, 1 February 2009 (UTC)

I can't believe there're so many songs with unreadable lyrics in SNLI… =S —gniw 22:05, 1 February 2009 (UTC)

[edit] Arashi

I wonder if anyone would know how the band "Arashi" should be named in this wiki. I noticed it being filed under two names, 嵐_Arashi and 嵐 Arashi, when I was browsing the SNLI. Thanks. (I’m not a fan myself and I’m not sure what its official name(s) is/are.)—gniw 05:46, 4 February 2009 (UTC)

Official name (according to MusicBrainz and Japanese Wikipedia) seems to be 嵐, so the artist page should probably be 嵐 (Arashi).

To complicate matters, there is/was also a US band called Arashi… but the songs on 嵐 Arashi all seem to be by the Japanese group. — 6x9 (Talk) 13:10, 4 February 2009 (UTC)

[edit] Policy about lyrics

I hope this will be the beginning of the end of my newbie questions =)

Anyway, the page naming policy, as I understand it, says that songs should be given names that correspond to the official title, without notations in parentheses (like "(guitar mix)", "(live version)", etc.) unless the lyrics are different, in which case a notation in parenthesis is allowed.

However, the lyrics policy, as I understand it, says that notations like "repeat", "verses", "chorus" should generally be avoided. I understand this to mean the lyrics should basically look like a transcript of the recording, so that the reader can basically just follow the transcript and sing along without having to figure out what to repeat, etc.

What if, in an album, there are three songs whose titles differ only in the "(xxx version)" notation, and the lyrics differ only in how certain verses are repeated? Under the current policy, should we merge all three and use some notation to indicate how the song is repeated in each version, ignore the differences and just pick one version to transcribe, or should we create separate pages for all three? (I think it boils down to whether a difference in how verses are repeated count as sufficient difference in the lyrics to justify separate pages.)—gniw 03:08, 5 February 2009 (UTC)

If the song versions are sufficiently different so that adding some kind of notation about the differences below the lyrics would be too cumbersome or difficult to explain, then creating a separate page for those lyrics is perfectly acceptable. If all that is changed is that at the end of the song the chorus is repeated an extra time or some such thing, then a note about that on the original page is a simple thing. In a nutshell: If the lyrics are mixed around enough to warrant a unique page, then do so.    Kiefer    talk    contribs    admin   03:51, 5 February 2009 (UTC)

[edit] OOoooge Files

When you've got a moment can you please cast your eyes over this list. This one is oooge! Thanks  Ñô†īṃέ2çяȳ^Talk 11:20, 8 February 2009 (UTC)

I just typed you out a reply but I'm experiencing problems (again) with the summary box. If I type in it my browser immediately crashes..grrrr. Basically I was saying that I've dealt with this now and thank you. I know Will will appreciate your observances (he takes an interest in sorting image files).  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 12:01, 8 February 2009 (UTC)

Thanks for sorting that, I was also concerned by the lack of the Fair Use Statement too & noticed the help pages state 'preferably less than 600x600'. I could've sworn it once said 500x500 & also wondered if help should state 'must be less than..in accordance with fair use laws' Ñô†īṃέ2çяȳ^Talk 12:14, 8 February 2009 (UTC)

Help:Contents/Uploading Content/Album Covers#Image Format  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 12:46, 8 February 2009 (UTC)

WillMak050389 won't be happy... [1] That page pretty much shows all the files that are "to big" (The last one is getting down to "legal" size) and he's got 12 hits :P ♫ LYRIC-Humbug ^words♪_deeds 12:59, 8 February 2009 (UTC)

Poster size? ...sorry  Ñô†īṃέ2çяȳ^Talk 13:31, 8 February 2009 (UTC)

Odd occurrence (no it's not a joke). ♫ LYRIC-Humbug ^words♪_deeds 14:21, 8 February 2009 (UTC)

Notime, if you want to help in this: copy the file, resize to 500x500 and then re-upload by following the link "upload a new version of this file" on image page. Then I'll delete the originals.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 14:39, 8 February 2009 (UTC)

Couldn't we simply include the fair-use statement in the {{Albumcover/Upload}} template? Or would that be legally questionable? — 6x9 (Talk) 19:29, 8 February 2009 (UTC)

Mmmm...not sure. People would still have to fill the link in at the top with artist name/album name, so I would imagine that is an acknowledgment that they did notice it... ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 21:17, 8 February 2009 (UTC)

Good idea, assuming people actually use the {{Albumcover/Upload}} template,example.Perhaps a gentle reminder at the top of the upload page would suffice?.  Ñô†īṃέ2çяȳ^Talk 21:34, 8 February 2009 (UTC)

I just stumbled on to this discussion. And I'll be honest, I disregard fair use, which probably isn't good, but I can't help myself when I find good resolution album cover. I hate finding blurry, jpg artifacted, obscure album covers when I want to be able to recognise what is happening on the album cover. Would you rather look at a piece of art at this resolution or this resolution? (You can now see the guys in the eye) And, to be honest, I'm surprised I don't have more hits on that huge image size list. As for the Hawthorne Heights cover, I believe someone else uploaded it at a different filename, and I just moved it, though I would've uploaded it if I found it on my own. So, scold me and give me a spankin', but I don't know that I would stop unless I see it negatively affecting the site. Who's gunna report us for copyright infringement on the album covers before we get into a bind over the whole lyrics thing?

As a side note, I would really love if we could get everyone to use {{Albumcover/Upload}} when they upload images; I might keel over in excitement. It gets inconvenient having to type in each artist name when looking up unlinked image files. Is that something we could have appear when people upload new files, just like our artist/album/song mock templates when a page is being created? --WillMak050389 04:54, 9 February 2009 (UTC)

As an afterthought, because I felt arrogant by what I wrote above, I definitely don't want the harm LyricWiki (what would I do with myself if I didn't have it?) But in this situation, I feel the benefits outweigh the risks. --WillMak050389 05:19, 9 February 2009 (UTC)

Yeah, I don't think it's that big of a problem because people aren't saying "Oh, you want high res covers to print? head over to LW". But LW does pay royalties to those who ask for it (for lyrics) so it'd only hurt the site when people start asking for covers to be taken down. I think Auto filling the description box an warning users about the file name policy (and maybe having a checkbox "I agree to what is in the box") on the uplaod page would be awesome. ♫ LYRIC-Humbug ^words♪_deeds 05:32, 9 February 2009 (UTC)

Thanks for all your comments guys. Interesting thoughts and ideas. Firstly, Notime is one of those users who (like me) makes good use of the help pages. And since the page about uploading album art has always given guidance on how to do this properly, image sizes for album covers (due I believe to copyright infringement), etc., he was of course right to bring our attention to this. And now that he has, and since it is clear that we all agree that there is room for improvement, would anyone object to me moving this discussion to Community Portal in the hopes of achieving this?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 14:03, 9 February 2009 (UTC)

I'm all for discussing this with the public. --WillMak050389 17:10, 9 February 2009 (UTC)

Thanks Will. If 6x9 objects I intend to ignore him anyway ;) so here goes... ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 18:59, 9 February 2009 (UTC)

Ok well I do think we should be mindful of copyright. And since we don't actually need large covers, I personally feel that 500x500 (maybe 600x600?) is a good compromise. I think that 500x500 may be the guidance given at Wikipedia. I agree that images smaller than this are often unsatisfactory.

More importantly, I would very much like a Fair Use Statement and the {{Albumcover/Upload}} template included on the upload page when uploading album art. The fact that many album covers are being added without proper use of the upload template causes unnecessary work for people like Will who I am aware have taken some responsibility for sorting these, since images not uploaded correctly are not being categorised. If the upload cover template and the fair use statement could be made to automagically appear by clicking on the "Upload cover" link on album page (as now happens with Page Ranking templates) that would be great. I'm just not quite clever enough myself to do it ;)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:49, 10 February 2009 (UTC)

Before this discussion dies out… Is there any reason (legal or otherwise) NOT to include the fair use statement in the {{Albumcover/Upload}} template, so it's automatically included with all album covers (or at least those that use the template)?

As for file size, I think 500x500 is plenty. Remember that the thumbnails on album and artist pages are only 180px wide anyway, so you only get to see the full size when you click on it. There are other web resources available for bigger cover art. — 6x9 (Talk) 20:48, 10 February 2009 (UTC)

I concur, 500x500 is ample & 'fit for purpose' & takes up less room on the server I imagine. I appreciate excellent quality images but I also appreciate the necessity for following LW guidelines in conjunction with fair use rules (& copyright infringement?).I have excellent quality images stored on my pc, they don't need to be on LW for me to enjoy them & the grainy 'poor quality to start with' ones can sometimes be enhanced prior to uploading. Including the fair use statement in the {{Albumcover/Upload}} template is a very good idea. If images are uploaded via the Upload file link in the toolbox could there be a notice at the top of the upload page to include a fair use statement? Ñô†īṃέ2çяȳ^Talk 21:37, 10 February 2009 (UTC)

Since the issues below this one seem to be pretty much resolved, can we maybe come to an agreement on this here as well? (I asked Sean on his talk page about the auto-template in the summary box thing, but no reply so far…) It seems to boil down to two issues:

1. Image size – no bigger than 500x500 px² and 150 kB. There are sites dedicated to hi-res album art out there, so there's no point in us running even the slightes risk of legal trouble over something other than lyrics.
2. Fair use statement – including this in the {{Albumcover/Upload}} template. (We'll have to find a way to add this template to as many uncategorized files as possible, preferably automated…)

Anyone against either of these? — 6x9 (Talk) 01:00, 19 February 2009 (UTC)

Nope and Notime has already indicated his agreement too. That's exactly what I think too. No point taking the risk...even though we probably are with artist images me thinks  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 01:12, 19 February 2009 (UTC)

Thank-you to all who participated for your considerations on this oooge subject yes@artist images, I add a fair use statement to artist images too.  Ñô†īṃέ2çяȳ^Talk 01:26, 19 February 2009 (UTC)

[edit] Parental Advisory templates

Regarding {{Pa}} & {{Parental Advisory}}: After seeing the edit history on Katy Perry:I Kissed A Girl, regarding the inclusion or removal of the Parental Advisory template, I am moved to suggest that these templates be done away with site-wide. These templates have no criteria for when they should or should not be included, and creating criteria that is clear and comprehensive is going to be impossible. The site has a "no censorship" stance, attempting to present the lyrics "as is", for good or for bad. Such notices are supposedly for protecting those who either might be offended or those whose parents might be offended. Do such notices do any good with regards to these goals? No. When these notices first started appearing on albums in the 80s, I knew kids that purposely sought those albums out for their parental piss-off value. It really had the opposite effect than what was intended. What it does is present a viewpoint that the ones marked with the templates are "bad" while the others (which could very possibly have even more potentially objectionable material) without these templates are "okay". Once we label something as "questionable", we also label everything else as "approved." Whatever the policy regarding f-bomb and sexual language is, it needs to be site-wide, not in a hit-and-miss manner as it is now. (Which is really shown by the fact that we have two templates for the same task.) As ruling on things in a fair, clear, and comprehensive manner is likely impossible and the templates in the end really have no effectiveness, I really think these should be axed.    Kiefer    talk    contribs    admin   00:51, 10 February 2009 (UTC)

Agreed, 100%. These badges probably do more harm than good, if they do anything at all. (Nothing more to add – Kiefer put it all down succinctly. Frank Zappa would approve.) — 6x9 (Talk) 01:27, 10 February 2009 (UTC)

Yep. Agreed, 105.97%. For all the reasons Kiefer has stated.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:03, 10 February 2009 (UTC)

I decided to chime in as well. Most minors hear (and say) a lot worse things than adults realize. They aren't the innocent babes that some folks would hope they were. And besides, what does the parental advisory do? Most parents don't sit right next to their child while they surf. For those parents who are truly concerned, they install content filtering software. I say ditch the PA. -    RainbowDragon    talk    contribs   15:23, 10 February 2009 (UTC)

Totally disagree. I replied to Keifer on the PA discussion page. When I was new here, there was a thread by admins which said those templates don't have to meet some arbitrary criterion set by shifting opinion polls to be defined as "offensive": if someone is offended, it's offensive. Are we going to setup a list of words or topics and maintain them as the Official Policy of Offensiveness? Whose do we go with?

I don't want the templates for minor, I want it for me. --Åqüã†ìкí ƒ_Δ^Σ ¶ 15:26, 10 February 2009 (UTC)

But what use is it then? People can get offended at just about everything. I actually doubt that there are many lyrics which *no-one at all* in the whole wide world would find offensive. (Even Puff The Magic Dragon was once blacklisted by radio stations, allegedly…)

For this template to be of any use, we'd have to (1) decide on a set of rules what is offensive and what not, and (2) find ALL pages that are offensive (according to those rules) and tag them. If we have no definitive rules, how would you know, if you came across a page that has been tagged with PA, that its content would actually offend you? For all you know, it could have been some user who just loathes the song for reasons other than the lyrics. BTW, I find lyrics in ALL-CAPS to be offensive… does that mean I can tag them with PA? — 6x9 (Talk) 16:06, 10 February 2009 (UTC)

Only reason to use the tags is if we are trying to remain faithful to what the Artist/Publisher/Distributor chose to label the track with... ∃cho⚡ierr∀ (☏) 16:16, 10 February 2009 (UTC)

For Aqua: The link that you give does talk a bit about the templates, but isn't an endorsement in the least. How are the templates effective in their assumed goal? You say that you want them for you, but how are they helpful to you?

Once again, the "if someone wants it on a song, it's there" application of these templates is a major problem, and is not policy. Some would find any metal song offensive. Some would find evangelical Contemporary Christian music to be offensive. Some might find a certain artist offensive (Dixie Chicks and Sinead O'Connor come to mind) and want all their songs tagged. The idea that if somebody finds the song offensive or might find the song offensive, then it should be tagged is ridiculous because of the abuse that it can bring. Should The Kingston Trio:Tom Dooley be tagged because it talks about someone being executed? How about Queen:Bohemian Rhapsody? For that matter, how about Queen:Fat Bottomed Girls or Queen:Tie Your Mother Down? Perhaps I find Vanilla Ice:Ice Ice Baby to be offensive because it ripped off the bassline from Queen:Under Pressure. Some are offended by John Lennon:Imagine because of its line about imagining if there was no religion, no heaven or hell. What about protest songs, such as Neil Young:Let's Impeach The President? In the song Katy Perry:I Kissed A Girl, the song was tagged because a girl kissed another girl. There's no crude language, just the girl kissing another girl (and liking it, I guess.) I could literally go on and on and on and on. What is the benchmark for template use going to be? If there isn't any, then anything can be tagged, and the supposed usefulness of the template is removed.    Kiefer    talk    contribs    admin   21:04, 10 February 2009 (UTC)

If I find a song with the template, I might edit the details, but I won't read the lyrics. I'm very surprised how many of us are presumptuous enough to suppose we can dictate what is an is not offensive for everyone else. We don't need to try to find every offensive song: people can label stuff for themselves. The fact that anything can be tagged does not make it useless. It would be more useful if everyone who placed the template had to give parameters (e.g. 'cursing', 'blasphemy', 'racism', 'sexuality', etc.) Those could be defined on the template page, but there can always be more categories added. I can't imagine myself saying to someone that maybe they think such-and-such is offensive, but it isn't really. "Just get over your being offended at racism/sexism/homophobia/whatever." --Åqüã†ìкí ƒ_Δ^Σ ¶ 23:49, 10 February 2009 (UTC)

Aqua, I'm concerned where this could possibly lead. If we label things we find objectionable, the next step could be making rules to ban lyrics from this wiki with certain words or topics. There are songs and groups that I find objectionable. My solution is to not go to those specific artist/album/song pages and let other folks enjoy them. I fear this could snowball into a censorship issue.    RainbowDragon    talk    contribs   00:12, 11 February 2009 (UTC)

(must be edit conflict day today) {{pa}} already allows for parameters; trouble is, no-one uses them. (Notice all the red links on the page?) Maybe we could make them a requirement, i.e. the badge doesn't appear if there's no parameter.

I suppose I should keep out of this discussion, because so far I've never read anything (that wasn't directed at me personally) which positively offended me. I might get annoyed sometimes, but then I usually stop reading. I'm not saying/writing this to brag, just to make clear where I'm coming from. — 6x9 (Talk) 00:19, 11 February 2009 (UTC)

I am against {{Pa}} templates for reasons stated previously. If not all songs that should be flagged are not flagged then it gives a false sense of security. I don't think a reduced risk of reading something that offends you is worth the effort/annoyance. I think LW's "no censorship" policy is against this (imho). To flag a song is to convey an opinion on the song that reflects your (the editors) ideology (man, this sounds like a school essay...) and this is in dange4r of being just as offensive. I don't think this is the way we should be going. (And how do you get to a song on LW? Search for a song/artist in which case you probably know what your getting, follow an external link in which case you know generally what your in for due to the context of the link) The only thing I wouldn't go up in arms about would be an [explicit] badge for explicit language as this can offend at a glance and every song can be tagged by Bots although I'd still be against it. ♫ LYRIC-Humbug ^words♪_deeds 04:39, 11 February 2009 (UTC)

To kind of sum things up, I feel that three things need to be asked with regards to these templates (and actually, templates in general):

1. Does the template have a clear purpose?
2. If so, does it satisfy this purpose?
3. Does the template have viable and clear criteria for inclusion or exclusion?

As far as I can discern, these two fail on all three points. Even if one was to concede #1, that they somehow protect children from reading the lyrics that their parents don't want them to read, the other two points are missing.    Kiefer    talk    contribs    admin   04:27, 11 February 2009 (UTC)

I have read with interest all the comments and my opinion on this hasn't changed. I guess that's because I know that "Sticks and stones can break my bones but words will never hurt me". I also don't feel I have the right to decide what others may or may not find offensive. This is why I have never used those templates. Maybe it's the same for many others too. I also don't think Mary Whitehouse done much good....  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 11:13, 11 February 2009 (UTC)

I can certainly see us getting rid of the template and that would not be all bad to me. As for Keifer's three points, I think the purpose of the template is give people who are offendable a "heads up" regarding songs they made be injured by. Let me call to mind that there are two templates being discussed here, and that that makes a huge difference. The little {{pa}} just puts a sticker in the upper right that everyone who doesn't care is used to looking right past. {{Parental Advisory}} shoves all the lyrics way down in an effort to hide them. Let me propose a compromise

1. Do away with Parental Advisory - it doesn't fulfil the purpose of stopping minors and there is no consensus on when it may or may not be used. It just doesn't work.
2. pa require a parameter - Kiefer's right that there is no point in opening a door to mutually righteous revert wars. People ought not be able to apply it randomly or whimsically.
3. pa can only be used on the song if
   1. it is labeled explicit in iTunes, or
   2. a PARENTAL ADVISORY: EXPLICIT LYRICS label was put on it in the past, or
   3. it is an indie/unreviewed song which a quorum of users feels fits into one of the existant parameter definitions

The purpose is to help those who don't want their eyes going over stuff we find offensive. We are mature enough to have willfully made that decision along clearly definable lines. In line with almost everything we do here, we follow precedents set by others and do not attempt to define our own ex nihilo. How do these strike people? --Åqüã†ìкí ƒ_Δ^Σ ¶ 14:03, 11 February 2009 (UTC)

Better yes. Much. But to be honest I don't think it really matters what we decide, I still can't see people wanting to use it. I think we've got to accept that some templates (like Official lyrics) are just doomed to fail. That having been said, with clear guidelines, some may feel more inclined to use it. If we do decide to go that route though, I certainly don't think that we should try to coerce people into using it, as it seems may have been suggested, by making it a requirement of Page Ranking.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 17:42, 11 February 2009 (UTC)

I am against it being a requirement for anything .--Åqüã†ìкí ƒ_Δ^Σ ¶ 23:25, 11 February 2009 (UTC)

Okay, I'm giving the conversation a little bump, as it seems to have stalled. As far as I can tell, there are five for removal (Kiefer, 6x9, Redxx, RainbowDragon, & Humbug) and one against (Aquatiki). Not exactly an overwhelming consensus, but we've certainly made bigger changes with such a small body of voices. I certainly appreciate the compromise that Aquatiki brought forward, but I still have concerns that the template is really ineffective with regards to its stated purpose and that the compromises, although possibly helping with the third requirement, still do not help with the second requirement. Any thoughts?    Kiefer    talk    contribs    admin   03:38, 15 February 2009 (UTC)

Nope. Think it's all been said. The axeman cometh..  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 10:14, 17 February 2009 (UTC)

[edit] Official Lyrics

I would wish to propose that we dispose of the {{Official Lyrics}} template. The lyrics we hold should be the recorded version, not the official lyrics. As such I believe this template simply causes confusion. It was previously suggested (by Mischko) that maybe we could add an optional parameter to the SongFooter template for this. I am not suggesting that this is what I think we should do, I am simply including this for Mischko's suggestion to be considered.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:19, 10 February 2009 (UTC)

Wow, my other least-loved template. I don't mind a link to "official" lyrics, as with R.E.M.:It's The End Of The World As We Know It (And I Feel Fine) sometimes the heard lyrics are a bit confusing and commonly misheard and so official versions can help to clarify word choice. So, I could go for a link being presented in the SongFooter as Mischko apparently has suggested, but the Official Lyrics template is overkill and gives undue weight to something that is often at odds with the recorded lyrics. I've said remove this template for (literally) years.    Kiefer    talk    contribs    admin   05:22, 10 February 2009 (UTC)

Oooh, ooh, can we get rid of {{Actual Lyrics}} then, too? --WillMak050389 05:13, 12 February 2009 (UTC)

Dunno… it's included on quite a lot of pages… who's gonna clean all 1 of them out? — 6x9 (Talk) 05:25, 12 February 2009 (UTC)

I know, we better get User:S2E2 on it. lol --WillMak050389 05:28, 12 February 2009 (UTC)

So, anybody against this change? If not...?    Kiefer    talk    contribs    admin   03:40, 15 February 2009 (UTC)

5... 4... 3... 2... ...      ♫ LYRIC-Humbug ^words♪_deeds 06:56, 17 February 2009 (UTC)

Go ahead and smite it. You know you want to :-) — 6x9 (Talk) 14:06, 17 February 2009 (UTC)

[edit] Proposing changes to the Billboard Hit template

I had a couple ideas I thought I'd toss out and see what the general feelings are. First, on the Billboard Hit badge it says that songname is a Billboard Hit. I'd like to see it changed to was a Billboard Hit because they don't stay hits forever. Second, I thought it'd be rather cool if the badge also showed the date the song was a Billboard hit. This would be similar to how the Song Of The Day badge is worded. I don't know how difficult it would be to have a date parameter added or even if anyone would be interested in seeing when a particular song was a Billboard hit. Comments? Suggestions? --   RainbowDragon    talk    contribs   20:40, 10 February 2009 (UTC)

I'm with you RD on the This song was a Billboard/Number One Hit although I suppose there's an argument that says once a hit, always a hit. Trouble with date stamps is that a song may have been a multiple hit, I remember having/seeing a similar discussion on here somewhere/sometime. The SOTD badge is useful in avoiding duplicate nominations whereas the 'hit' badges are more information only in my book. Ñô†īṃέ2çяȳ^Talk 23:00, 10 February 2009 (UTC)

Yes Notime, you're right we had a discussion (in your sandbox) back in December about changing the wording on the Billboard Hit template from "is" to "was" , and also adding the date. Here is part of the discussion that resulted, which I'm sure 6x9 will also recall.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 10:37, 11 February 2009 (UTC)

Ahh, knew I'd seen it somewhere local _{and could rely on you to locate it ;)}. Thank you. (ps, any decision on 'oooge files' so I can continue/stop resizing?) Ñô†īṃέ2çяȳ^Talk 17:48, 11 February 2009 (UTC)

I like the idea of the changes. Now that I've had a little bit of time to thing about the Billboard Hit template, how about having the date state the date that the song first reached its highest point on the charts? It could state "This song was a Billboard Hit! It reached #8 on February 14, 1986." Is there a way to research this? There's got to be, I've just never attempted it....    Kiefer    talk    contribs    admin   04:27, 11 February 2009 (UTC)

chartfreaks.com is one site I know of Kiefer, but think you may need to register. I'm already a member.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 10:53, 11 February 2009 (UTC)

You folks have already talked about this? And here I thought I was coming up with an original idea I like the idea of placing when it reached its highest point on the charts. I'm also glad you guys agree with was over is. I'm glad I brought this up (apparently again). Would somebody with template skills mind tinkering around with the badge, please? --    RainbowDragon    talk    contribs   15:01, 11 February 2009 (UTC)

Great minds think alike ;)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 15:20, 11 February 2009 (UTC)

And another reason to discuss such changes in the Comm. Portal! Yay, collaboration!

Okay, keeping in mind the situations mentioned in the linked-to discussion on 6x9's archived talk page: What could be done is to institute a "Charts" section, much like the "Credits" section on pages that have the B-Hits badge. Instead of adding date information to the badge itself, there can be a link (either by text "Info" or by an info icon) to the Charts section below the lyrics. Then the badge doesn't have to be country-specific. Just a thought off the top of my head....    Kiefer    talk    contribs    admin   18:45, 11 February 2009 (UTC)

I would go for a "Charts" or "Awards" section on song pages. There could be one badge saying "This song has made an appearance in music charts" and link to the section (what Kiefer said :P) then the section could have a standard sentence of line or userbox style thing for each chart that it appeared in and each award it has won. This is where other (award/chart related) categories should be put. Such as "Category:AWARD Nominees" if we want such a thing (a list might be better) ♫ LYRIC-Humbug ^words♪_deeds 07:03, 17 February 2009 (UTC)

If we've reached a consensus on this, would somebody with the appropriate permissions reword is to was on these two templates, please? The templates are locked or I'd go ahead and do it. Thank you,    RainbowDragon    talk    contribs   21:20, 20 February 2009 (UTC)

What about the section link to "Awards"? We'd have to make this optional (via an additional parameter) for those song pages that don't have an "Awards" section (yet). Or do we leave it out and trust people to know where the page-down key is? :-) — 6x9 (Talk) 21:30, 20 February 2009 (UTC)

I'd say leave it off. If in the future somebody wants it we can discuss it again.

--    RainbowDragon    talk    contribs   23:22, 20 February 2009 (UTC)

What was is is now was. All else is as it was. — 6x9 (Talk) 23:48, 20 February 2009 (UTC)

[edit] Artist Subpages

Any wise souls: Is what I did to Elvis Presley [2] good? There's a few more like it that I will do the same to if there's no objection. Also, what's the deal with categorising? Should we go with the "ARTIST Subpages" as subcategories (there are quite a few in Special:WantedCategories) or should we go with putting all the subpages in the "Artist Subpages" category (like the Elvis Presley Subpages) (or both?)? There aren't that many of them so the second option wouldn't be to bad... ♫ LYRIC-Humbug ^words♪_deeds 08:48, 16 February 2009 (UTC)

Yes Humbug way to go! (Thanks for doing that.) Or like I've done with Frank Sinatra. The important things to consider are:

1. there needs to be some sort of logical splitting/era division. See Frank Sinatra and this post here.
2. It must be made clear, by linking each subpage like I have done with Frank Sinatra, that these pages are split.

Either way Category:SplitCatalog on main artist page and Category:Artist Subpages on each subpage (with links from/to each page) and {{SplitCatalog}} on the main artist page is what I believe you should do. As I previously stated, I don't see the sense in creating separate categories for each individual artist simply for their subpages. Certainly not by way of artist name. The subpages can easily be located from within Category:Artist Subpages/Category:SplitCatalog anyway and this would certainly seem to me to make a lot more sense. But if anyone thinks otherwise please comment here.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 11:03, 16 February 2009 (UTC)

What do you think now? I very much like the ambiguity of the actual page titles as it makes page titles easy and regular across different artists and also stops them looking like song pages. Not the best for categories but I think it's a fair trade off. I also linked to the next chapter at the bottom in big text just in case someone is reading through the list chronologically and they reach the end. ♫ LYRIC-Humbug ^words♪_deeds 13:02, 16 February 2009 (UTC)

Yes, much better. The only thing I changed was I added links at the top and a back link at the bottom of all the pages so they are easy to navigate and all link up. As I was doing this and negotiating the links "The Sixties", etc. I was thinking about what you said about liking the ambiguity of "Chapter 1" "Chapter 2" etc. However, upon investigation it doesn't seem there is actually much uniformity here.

By which I mean that some sub pages are named:

1. like I did with old Blue Eyes (many blue moons ago) Frank Sinatra: The Fifties (1950-1959),
2. or a slight variation on the theme, Jimmy Buffett: 1970 - 1979.
3. Others are named with a slash, like Jethro Tull/Compilations and Live Albums and Pink Floyd/Singles.
4. Then we have Disney Animated Films (which admittedly is not really an artist page but a list).
5. We also have pages named like Elvis, Elvis Presley Chapter 1, split into "Fifties", "Sixties" etc. but no reference to this included in page name.
6. Similarly, but with colon, we have sub pages like Styx: Chapter One.

So I think we need to discuss how exactly these pages should be named. I believe the correct way to name a sub page is with a slash, i.e. Pink Floyd/Singles. I also think that the page should be descriptive of what it contains. So if it is covering "The Fifties", or "Compilations", this should be incorporated into page name, not just be "Chapter One", "Chapter Two", etc. Maybe the parentheses could present problems with bots thinking it's an album page. I don't know but I would be glad of some feedback on this.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 14:43, 16 February 2009 (UTC)

I realise there are many different naming conventions being used :P which is why the simple method looked the best to me. I think slashes are the best too. But "Singles" and "Compilations" wont split pages small enough (leaving "Studio Albums" over the limit). Should it be something like "ARTIST/Fifties"? Colons are likely o cause a problem with bots recognising them as artist like pages. Also, their should be a template ({{nav}} or similar) to provide the next and previous links so they are uniform. (I think I saw one, maybe on Red's archive footer?)
I also like the idea on "ARTIST/Visual" containing similar to this as all the album art otherwise can't be shown on one page.
So we are talking about 2 things. Naming and categorising. I'm going for "ARTIST/Fifties" (or "ARTIST/Fifties and Sixties" as necessary) for names and Category:Artist Subpages only for categorising. ♫ LYRIC-Humbug ^words♪_deeds 15:12, 16 February 2009 (UTC)

[edit] Navigation Templates

Hey look, {{Nav}} now exists. What a coincidence! It's ugly as atm but that's the sort of thing I am going for. feel free to make any cosmetic changes to it. ♫ LYRIC-Humbug ^words♪_deeds 15:44, 16 February 2009 (UTC)

Looks good! I fixed the column widths so the middle one is always centered. I also noticed you used a few absolute values… don't forget that these pages will be viewed with all sorts of fonts, font-sizes and screen resolutions like I'm telling Red time and time again, but nooooo, she insists on using loads of &nbsp;s and <br>s for layout, so try to use em or % instead of px wherever possible. (Top & bottom padding for the rows might also be better than a fixed height – what if a line needs to wrap?) But it really looks good :-) — 6x9 (Talk) 16:19, 16 February 2009 (UTC)

Darn User:Redxx/Template:SubNav! You nicked my idea Humbug using my ArchNav I am just sooo slooowww!..great minds...

Ok well there aren't too many differences 6 as you can see. I categorised my template so when it's used it will automatically enter the page in Category:Artist Subpages. I kinda felt this was important ;) And you will note that on my version the artist blue is in the top section, same as artist header. I have retained the label parameters as these allow for variations in artist names, etc. I have also named my version SubNav because we are likely to get a few more variations on this now, like ArchNav. I felt it was descriptive too. You will also need to amend both templates 6, certainly my version, to take into account the beginning and the end, so that the text remains centralised where these do not exist (see Frank Sinatra.

Well now me and Humbug have done all the hard work, I'll leave it to you to amalgamate the two, etc. Just never say I don't ever give you nothing ;) Happy editing! (hee hee)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 17:56, 16 February 2009 (UTC)

EDIT: Just a further thought. Since it is more specific, documentation, categorised, etc. I think my "SubNav" should be used for Sub pages and Humbug's "Nav" should stand exactly as it is (but with a colour change), as this can be adapted by anyone..for anything. Good idea yes?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 18:53, 16 February 2009 (UTC)

Alright, I've (1) made ret and cur parameters optional (works correctly only if subpages are separated by slashes, though), (2) added the category and (3) made sure cells don't get displaced if prev or next aren't specified.

There's still the problem that not all artist pages are split chronologically. (Frankly, I prefer to split off compilations and live albums wherever this is sufficient, because they are mostly redundant anyway.) So I suggest the following: add an optional switch "type=list" which produces just that – a vertical list instead of the horizontal prev-cur-next layout. What do you think? — 6x9 (Talk) 20:22, 16 February 2009 (UTC)

Why don't we just adopt the list format for all? This way, you can still put them in order, but you don't have to click through multiple pages to go to the end. I might want to see Sinatra's 90s page after looking at his 50s stuff. But, pretend I'm an extremely lazy editor (this may not be too hard, actually and unfortunately) and I just don't feel like clicking through his 60s, 70s, and 80s pages. I'd be happy being able to get to his 90s page from any and all of his subpages. Anyway, this is just a thought. All these other templates put mine to shame anyway. Oh no! I've started using emoticons... --WillMak050389 22:39, 16 February 2009 (UTC)

I think you aren't listening to me 6 ;)

I proposed that you use {{SubNav}} for navigating artist sub pages since this was created specifically for that purpose (adapt this to your hearts content) and {{Nav}} can be used (without any adaptation) for any type of navigation. To assist in this I've now moved Template:SubNav into main template space. I don't know about anyone else but slashes is how me and Humbug feel these sub pages should be named, so if you adapt {{SubNav}} for that, and that is what is agreed, it shouldn't be a problem.

I'm not fussed about whether the template displays horizontally or vertically - I know you'll do whatever is best. As I was creating it I was thinking however that it would be good if the template was positioned on the page like the Help navigational template, i.e. to the right of TOC. So being verical might assist in that of course.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 23:20, 16 February 2009 (UTC) Rfl@Will. Live Long and prosper.

Good idea, Will. I removed the horizontal layout completely and just left the list. Since it's now vertical anyway I thought it might be a good idea to move it to the top right corner, kind of like the Help navigational template.

 ;-) — 6x9 (Talk) 00:08, 17 February 2009 (UTC)

Haa haa very funny 6. Thank you.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 12:22, 17 February 2009 (UTC)

I propose {{Nav}} to be general horizontal nav template; {{SubNav}} be a Horizontal navigation similar to {{Nav}} but with the text "Return to Artist's artist page" and categorising built into it and; {{ListNav}} be what 6x9 is building in his sandbox and fit for general use. (floating right, clearing right). {{ListNav}} would be used at the top of artist subpages and {{SubNav}} would be used at the bottom. I believe only a link to the next subpage is really required at the bottom like if your looking for a song around 1960 and you start half way down "The Fifties" subpage. I don't think it's too big of an ask to go back to the artist page if you want to jump to an arbitrary subpage, bu the list in the space to the right of the TOC would be good. ♫ LYRIC-Humbug ^words♪_deeds 06:50, 17 February 2009 (UTC)

What would the advantage be of having two nav. templates on a subpage? The current (top right, list-type) SubNav already lets you go to every other subpage, and a horizontal Nav is really only useful if you have many consecutive pages (Frankie does, but few other artists do).

The latter could be useful on song pages though, where you could jump to the previous or next song on an album (as was suggested on LyricWiki talk:Pink Floyd a while ago). — 6x9 (Talk) 17:50, 17 February 2009 (UTC)

I would go for a list up the top and a link, "Forward to The {Next}ies", at the bottom. I think it would be neat for {{SubNav}} to look like {{ArtistHeader}} (with the margin around the blue etc.) but that's just cosmetic. (We should talk about that Template talk:SubNav We should try to wrap this up I guess... ♫ LYRIC-Humbug ^words♪_deeds 13:18, 18 February 2009 (UTC)

I think it would be neat for {{SubNav}} to look like {{ArtistHeader}} (with the margin around the blue etc.) I was actually trying to do that but I could only get margin in top bit before I got..err.."frustrated" enough to forget the idea. So I'm very glad you done this guys! Thanks! Looking good.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 15:48, 18 February 2009 (UTC)

[edit] Uniformity of Artist Subpages

(Continued from above) Forgive me, if it was discussed already somewhere, but one thing is still strange for me: nobody's talking here about the topic of the thread: real Artist Subpage; including those, having a {{UBX:CtS}} on their pages. If that's still unacceptable in LW for some reasons, - ok, let's do it in some 'pseudo-subpages', or 'splitted' pages, manner; but please, do that in some uniform manner. Either way current LW API version is unable to work with any kind of mentioned splitted pages. But we should think at least about those advanced users, or addins-makers, who are forced now to make their search tools, considering all possible variations of our 'ingenuity'. As it was mentioned above, now we have 3 types of such 'subpages': slash-separated (PF...), colon-separated (FS...) and simple space-separated (e.g. - unseparated) (EP...). Don't you think we should firstly choose some one approach for doing that, and make this choice be visible on HP? --Senvaikis ^(talk) 11:55, 17 February 2009 (UTC)

The subject of uniformity was just delayed Senv, due to the mass influx of navigational templates that resulted after I highlighted this non-uniformity (hee hee). Now that it seems this has been resolved, I believe we can get back on track.

So, which one would you prefer? Can you see any way that these could be made to work with current api? If not (and I accept this is probably a loaded question), what would need to be done to make them visible to api?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 12:22, 17 February 2009 (UTC)

Seems to me I must clarify the main questions of my post:

• 1'st Q(main): Is still real subpaging (enabling subpaging in the main namespace), making all our nav's needless, unacceptable in LW?
• 2'nd Q(uniformity): this question raises in case of negative answer to the first one; Looking ahead, I'd vote for slashes...
• 3'd Q(API-compatibility): This question is relevant in either way, and seems to me that only One Person is able to give us solid answer to it...

--Senvaikis ^(talk) 13:07, 17 February 2009 (UTC)

Noted Senv, but I thought that a slash did make for a "real" subpage?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 15:14, 17 February 2009 (UTC)P.S. Just in case anyone else was wobdering about this >>> LyricWiki:Colons to Slashes

As for Colons to Slashes, I think that the main point against such a thing is that it limits the use of Slashes to signalling subpages only. Under such a plan, AC/DC would essentially mean "the DC subpage of the artist AC", wouldn't it? I have a feeling that this is why the subpaging was originally turned off. (We had enough symbols that didn't work well in pagenames already, although a couple of those are now possible after the MediaWiki upgrade.)

As far as how we have this set up currently, slashes, colons and spaces all essentially work the same when creating subpages, it's just however the editor feels the page would best be set up. I use colons, although looking at The Beach Boys & The Rolling Stones I used a space before the colon in one instance, and without in another. I also bolded album lists on one and not on another (I think it looks better without, so I'm going to fix that on the Beach Boys page.) I like the idea of uniformity, though, so I'm going to go with how I did it on The Rolling Stones, with a colon and then a space after the artist name. I think that this method helps the page stand out pagename wise just a smidge from a regular album page, and allows for subpage naming versatility.    Kiefer    talk    contribs    admin   16:56, 17 February 2009 (UTC)

I'd prefer slashes for subpages, to clearly set them apart from songs and albums. (Plus it means that {{SubNav}} can detect the main page automatically.) Agree on your point against :-/ (CtS) – there's way too many song titles with slashes in them, as well. It's bad enough that we constantly run into colonial trouble with the magic words. — 6x9 (Talk) 17:19, 17 February 2009 (UTC)

Question, since an idea popped into my head.... Could {{SubNav}} be set to use/detect a double colon instead of a slash? So, having something along the lines of [[The Beach Boys::The Classic Years (1962-1966)]] for these pages? I can't think of an instance where we use two colons one after the other, and we could have that signal the fact that the page is a subpage. As I said, just a thought that popped into my head.    Kiefer    talk    contribs    admin   18:11, 17 February 2009 (UTC)

If it is possible, I don't know how. Currently it uses the #titleparts: parser function, and that only works with slashes. It's not really a problem anyway; if autodetection doesn't work you can still enter the title of the mainpage manually. — 6x9 (Talk) 18:20, 17 February 2009 (UTC)

I would also prefer slashes as it identifies "folders" on my desktop so I find it easy to see it as a subpage :P. But the main reason is it would be quite easy for the API to detect {{SplitCatalog}} and then treat all links from that page that begin with "{{PAGENAME}}/" as subpages to be searched. I'm assuming the API uses artist pages to list things... ♫ LYRIC-Humbug ^words♪_deeds 08:56, 18 February 2009 (UTC)

I would also prefer slashes since whilst this option may be turned off in mainspace, slashes do actually = subpage. Even to the uninitiated ;)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 11:18, 18 February 2009 (UTC)

Well I guess we better wrap this up or we'll be here 'til the come home. I say we put this to a vote (because we can). We also have to consider the bit after the seperators. I'm against "Types" as it will still leave a large "Studio Albums" subpage, and I like words better, hence my vote. ♫ LYRIC-Humbug ^words♪_deeds 13:18, 18 February 2009 (UTC)

I think how we split should be optional. In the case of Jethro Tull, for example, splitting live albums and compilations to a subpage was sufficient to get the main page below 32k, and if we can keep the studio albums all in one place, we should do that (as they're the most important part of a discography). — 6x9 (Talk) 14:52, 18 February 2009 (UTC)

I think we also need to consider eras in parenthesis and if these will cause problems to bots thinking they are album pages.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 15:54, 18 February 2009 (UTC)

I don't understand the second part of vote Humbug and why we have to decide on this. I feel (like the new section I added and you removed indicated that this should be decided at the time, according to the particular needs of the page. Also think about the example that Kiefer gave above: [[The Beach Boys:The Classic Years (1962-1966)]]. If this was "words", he would have to name it The Classic Years Nineteensixtytwo to Nineteensixtysix. I think that might not quite all fit in on SubNav template ;)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 16:18, 18 February 2009 (UTC)

Good point. I guess I don't really like "The Fifties (1950-1959)" because "The Fifties" pretty much sums it up. ♫ LYRIC-Humbug ^words♪_deeds 16:29, 18 February 2009 (UTC)

A couple of points: Having an era in parentheses shouldn't mess up anything because more than 4 characters are within the (). So, yes, (Live) is thought of as an album, even if it's a song, but (2002-) and (1962-1966) shouldn't cause any problems. So, worry not, true believers!

Also, I'm really a strong believer in that EPs, Live albums, and major "Greatest Hits"-type compilations should be in the main list chronologically, and not separated into sub-pages. (Minor, small press compilations for artists such as America, Jefferson Airplane, etc. that come out after an artist/group is no longer recording can be dealt with with less "respect", though.)

Lastly, from what I can tell, having edited the site using a number of the latest browsers, none have a problem with page size. It's the older, out-of-date browsers that some are sticking to that are a possible problem. (Not a techie, so a grain of salt with that, I suppose.) So, if the page is a little bit over the limit, I wouldn't personally go all Conan on it. Some pages, such as with Frank Sinatra, The Beach Boys, etc., are just massively huge and should get chopped into more manageable pieces, however. This is good for those old-timey browsers (IE 3.0 or some-such) and for information manageability. (Who wants to go to a page, where the first album isn't even visible because the TOC is 1200 pixels deep?!?)    Kiefer    talk    contribs    admin   03:47, 19 February 2009 (UTC)

Ok, couple of points I'd like to clarify with you if I may Kiefer:

1. Slashes won't work with api at present. I think I'm right in saying that subpages will not work at all with api. (See also Senv's comment on this above).
2. I don't have any problem with large page sizes (I use Firefox), but I believe those who use IE6 (like 6x9) may be affected.
3. If we keep all regular albums, EPs, live albums, and major "Greatest Hits"-type compilations on the main artist page there will actually be nothing to move to subpage! This will therefore not resolve the oversize problem. If the albums were all listed on main page (like I have done with Frank Sinatra), would you still feel the same? A sub page is just another page after all surely?
4. With the above in mind, are you suggesting that in fact we should abolish the making of subpages forthwith, unless extremely over, such as for artists such as Sinatra?
5. Sean made the {{SplitCatalog}} at 00.45 am on the 24th of November. Quite what prompted him to do this on that day I do not know. Nor exactly how strictly he intended for this to be applied for pages over 32kb.

If subpages are invisible to the api then this would seem to me to be a more serious issue than page loading times. So whilst I like the idea of sub pages because of information manageability, on balance, and until this issue is resolved, my vote would likely go with not splitting pages, unless extreme like Frank Sinatra.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 02:23, 21 February 2009 (UTC)

1. Okay. Then it doesn't matter what we use, colons or slashes, I guess. I may need to change my vote below. Hrrmmm.
2. I have IE7 now, but before I had it (and before I used Firefox) I used IE6 with the site and didn't have any size-related problems. True, not to say that there can't be, but it doesn't seem to hold 6x9 back.  :-]
3. I view subpages as those for The Beach Boys and The Rolling Stones, where the entire chronological discography is split into manageable sections, not as pages that list all the albums of a certain type. (EP, Live, Compilation, etc.)
4. I would suggest that just because a page opens with a warning that the page size is over the suggested limit doesn't mean that it should be a requirement that it be split up. Those major artists such as Ol' Blue Eyes whose discography is truly over-the-limit should be split. Nothing more complicated than that.
5. Sean basically made a template for what I already had placed on the Beach Boys page here. It's for any page that required splitting.
6. Has anyone figured out what is causing split subpages to be invisible to the API? It's a page like any other, it just doesn't have the Artist as the pagename. Is it essentially that the API can't find a Rolling Stone song page if it isn't listed on the The Rolling Stones Artist page? If this is the problem, then the API should be updated so that if it encounters an Artist page with a marker of some kind that tells the API that the page is split then it will further look at the subpages. I'm thinking using the aforementioned {{SplitCatalog}} in some fashion might be possible. But then, I don't work with the API, so this is all guesswork. If there isn't any way to do this, then perhaps we do need to ban the subpages, and users with older browsers just suffer the consequences. Either that, or we do a collapsible "Every Song" list at the end of the page. This would, again, boost the page size to 32kb+ proportions, but perhaps with the Live albums and compilations, etc. where songs are listed over and over, the size would still be smaller than if all the albums were on the Artist page.    Kiefer    talk    contribs    admin   03:53, 21 February 2009 (UTC)

Just a quick note Kiefer, I believe pages over or approaching 32kb can't be edited by bots. I believe that's the biggest reason to keep them (I mean, if these artist pages won't need bot edits, then we could just have enormous artists pages when necessary, but we may want bots to edit them every once in a while when templates get updated and such and all artist pages are affected). Anyway, just a quick note as I said, I don't know if this changes your opinion on anything. --WillMak050389 06:40, 21 February 2009 (UTC)

Gah! What a nightmare. Long pages can be seen by the API, but can't be edited by bot. Short pages can be edited by the bots, but cause subpage info to be unaccessible to the API! I find it interesting that bots have problems with 32kb+ pages. Why that limit, the same limit that some browsers have? Seems awfully coincidental, or is it some sort of "Drive Kiefer Crazy" conspiracy. Hrmph. I don't know. I think my opinion now is to burn the mess to the ground. It'll look pretty at night and warm us, too.  :-]    Kiefer    talk    contribs    admin   21:22, 21 February 2009 (UTC)

[edit] Vote on separator

1. Humbug
2. 6x9
3. Redxx
4. Senvaikis
5. Kiefer (If this is most likely "usable" for the API, then that is a darn good reason.)
6. RainbowDragon

[edit] Naming after separator

Any objections to having two ways of splitting - "types" and "era" ("timespan") - depending on the artists discography size? The vote is for "era" naming:

1. Redxx (Keep regular albums [and EP's] on main page wherever possible and if spills over to sub page do not mix with compilation albums, etc. Keep separate. Avoid parentheses and numbers where possible)
2. Humbug (Avoid numbers+parentheses if possible)
3. 6x9 (keep regular albums on main page wherever possible)
4. Kiefer

1. Humbug

[edit] Nutshell

Sound good? ♫ LYRIC-Humbug ^words♪_deeds 00:52, 23 February 2009 (UTC)

Sounds good. (I only made one small addition.) — 6x9 (Talk) 01:16, 23 February 2009 (UTC)

Feel free to make changes too! ♫ LYRIC-Humbug ^words♪_deeds 01:51, 23 February 2009 (UTC)

Have you read Kiefer's post above? That basically says to me that this needs further discussion. I feel we also need input from both Senv and Echo before any changes take place. Please..let's not rush this.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 02:12, 23 February 2009 (UTC)

Yes, thank you. I still have a problem with the removal of all Compilation and Live albums in order to reduce page size. Those Live & Compilation albums that were major releases (those that sold well Eagles:Their Greatest Hits (1976) and Eagles:Eagles Live (1980), for example) should stay. Singles should only be a list of links to the album page, not a track listing anyway, so splitting those off likely wouldn't save many bytes.

Now, I was kind of being tongue in cheek with the frustration of API vs. bots, but we need to see if we can discover a way to make the situation the most workable. This will likely help determine the best solution to go with.

If we ignore for the time being the API vs. bot Catch-22, I would say that in my perfect wiki world that when a page needed to be split into subpages, that it be done by era, with the Artist page having sections for each era, and for Singles, minor Compilations, and Live Albums when needed. Each section should be a listing of links to the individual albums and the headers for the era sections should be a link to the appropriate sub-page. And of course, the Other Songs list should be below all the sections.    Kiefer    talk    contribs    admin   03:30, 23 February 2009 (UTC)

I agree Kiefer, split by era. Because asides from anything else, I believe this is also likely to create best results. For example if we just split compilations and live albums from regular studio albums, this would likely not resolve the problem with a major artist like Sinatra. This being so the regular albums would still need to be split. I also think the way I have done Frank's page is fine. Well obviously ;) But then again I did copy the idea from an expert in the field ;) I think this is also how you are suggesting you'd like it done.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:44, 23 February 2009 (UTC)

Sorry for jumping the gun guys. Didn't realise you had brought up that stuff. Relating to the API, even if we only split a few artist those artists will still be a problem for the API so a solution still needs to be found. I actually posed the question to Sean on IRC, and it won't be too hard to use {{SplitCatalog}} as a marker denoting subpages are used and treating any link starting with "ARTIST/" as a subpage that should be searched for album and song links. I'll just chill for a while. ♫ LYRIC-Humbug ^words♪_deeds 00:04, 24 February 2009 (UTC)

Is Ok Humbug I'm a little older than you and I just can't run as fast ;)

Since it would be best for those using api if we didn't split these pages at all, I think we should try and establish the actual extent of this problem before deciding how best to handle these pages from now on. By which I mean does anyone in the room actually suffer frustratingly long load times on pages bigger than 32kb? Enough to consider it a problem..that needs fixing? I don't.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 00:57, 24 February 2009 (UTC)

[edit] wikEd

This morning wikEd started throwing errors again in IE, so I un-included it. I think part of problem is that we include live-code directly from the site where it sits. One thing that's always annoyed me about it though is that it seems to turn itself on without consent sometimes. I don't think we should completely remove it though, because some ppl use it. What are ppl's thoughts on how to use it in the future (I'd like to get it turned back on as soon as possible so that ppl who are used to it aren't disoriented):

1. If only a couple of ppl use it, maybe we make it a User Preference to turn it on?
2. Just grab a copy of the script from it's source and once we've found a nice stable version that doesn't turn itself on too often or throw warnings, just host that on our own servers so it won't change (no instant upgrades, but also no worry that it will break the site for everyone).
3. Maybe just ditch it on a site-wide basis (only if it turns out that almost nobody uses it).

So please let me know what you think and also whether or not you use it.
Thanks,
-Sean Colombo (talk|contribs) 16:22, 19 February 2009 (UTC)

I'm rarely using WikiEd, but anyway I'd vote for the second (local stable version) solution.--Senvaikis ^(talk) 16:35, 19 February 2009 (UTC) ...If error is there. But are you sure?

I never use it (don't even get to see it most of the time, since I usually have scripting turned off). Both 1 and 2 sound like good options though. — 6x9 (Talk) 16:39, 19 February 2009 (UTC)

I think we should go with both options 1 & 2 -    RainbowDragon    talk    contribs   16:43, 19 February 2009 (UTC)

I'd also prefer it as a User Preference to make it turn off & onable as well as a local stable version.  Ñô†īṃέ2çяȳ^Talk 23:38, 19 February 2009 (UTC)

I have been using WikEd for ages now, both here and on Wikipedia. I know KingNee uses it too. I started using it here via Greasemonkey script. I also think it should be a User preference and I'd go with option 2 too.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 02:32, 21 February 2009 (UTC)

Seems to be a pretty solid consensus. Makes my job easy ;). I'll start writing the extension for the User Pref and I'll try to find a stable copy of WikiEd to store on our servers.

-Sean Colombo (talk|contribs) 21:41, 21 February 2009 (UTC)

Alrighty... it's back. To turn it on, go to your Special:Preferences page and it is the last option under the "Misc" tab. And the file is now hosted on our servers, so it shouldn't randomly break when they change things.

-Sean Colombo (talk|contribs) 22:46, 21 February 2009 (UTC)

Thanks Sean  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 00:36, 24 February 2009 (UTC)

[edit] Edits by: "autogen. song page (WLv0.13.3)"

Would it be possible to ban edits by "autogen. song page (WLv0.13.3)"? It deletes the whole existing song page and overwrites it with its incomplete and most of the time more wrong lyrics than what we had already, for example check this: http://lyricwiki.org/index.php?title=Welle:Erdball:Deine_Augen&diff=3937959&oldid=3772546 and this is not the first time I had to bring back old versions... --MetalSnake 19:21, 19 February 2009 (UTC)

Could we get some opinions on this, please? MetalSnake has a point – edits done by that script are hardly ever purely beneficial. Sometimes the lyrics are corrected, but info is removed from the SongFooter. Sometimes just info is removed. Would it be possible to allow page creations, but not edits? Or at least to restrict edits to the content between the lyric tags? — 6x9 (Talk) 16:18, 6 March 2009 (UTC)

I have put the obligatory tl|AutoGenNote on countless user pages, Those folks will mess things up even if they did it by hand. We're still getting pages that are unranked and have cat:Review Me! The author of the script had a dialogue about upgrading the widget with Aqua awhile back, but it hasn't been updated. fwiw ∃cho⚡ierr∀ ( ☏ • ⎋ • ⌫) 16:53, 6 March 2009 (UTC)

At the very least, it should be possible to block outdated versions of the script… Cat:Review Me might be a good thing, though, since at least it gives us an option to find those autodegen. pages quickly. — 6x9 (Talk) 17:48, 6 March 2009 (UTC)

RM is already covered by unranked, so catRM has no real use except for those UTF mangled pages...The only creator of RM pages is autogen (& autogen only), unranked is another story ∃cho⚡ierr∀ ( ☏ • ⎋ • ⌫) 17:55, 6 March 2009 (UTC)

User:Attendant is the author of the script and I think it may be possible to block some outdated versions 6 (see here). I would also support your idea of allowing this script to create pages but not edit. If the page doesn't exist then the script is obviously a positive. It only becomes a negative when some of the people using these scripts edit existing pages.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 19:17, 6 March 2009 (UTC)

If I recall correctly, the script isn't supposed to automatically overwrite pages that don't include the "Review Me" tag, and I think that the user has "okay" the changes if it doesn't. So, if pages are being damaged, I think it still has a human element to it and it's not totally automatic. So, yeah, it's still like any other user, if they're doing damage, {{WarnUser}} them, give them the {{AutoGenNote}}, and then if they do it again, give them a time-out. I'm thinking that there really isn't any way for us to ban those that are using the script, because that would involve somehow detecting that the user is using the script. Perhaps something could be done if the "autogen. song page (WLv0.13.3)" summary could be detected, and then the change denied, but that really seems like it would be a programming hassle for Sean, when Recent Changes patrolling (as many of us do) is an easy enough solution, and more "friendly" in the long run. Remember, these aren't people who are trying to damage the site, they just don't realize what the consequences of their actions truly are. (It is weird, however, that use of the script tends to go in waves. There won't be any use for weeks, and then suddenly 3 or 4 will use the script in a few weeks' time.)    Kiefer    talk    contribs    admin   05:25, 7 March 2009 (UTC)

[edit] {{Albumcover}}

As per the (previously above, now archived) discussion I have included a fair use statement in the Albumcover template, so it's no longer necessary to add it to the summary field manually. (Not that many people did anyway…) There's also now an optional |source parameter. And yes, it's "Albumcover" now, no longer "Albumcover/Upload" (though the latter redirects to the former and therefore still works). — 6x9 (Talk) 01:01, 20 February 2009 (UTC)

Thanks  Ñô†īṃέ2çяȳ^Talk 01:08, 20 February 2009 (UTC)

Yes thank you 6x9.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:32, 23 February 2009 (UTC)

6 times 9, I uploaded some album art yesterday and I did not get the fair use statement pre-loaded for me. Perhaps there is a bug? --    RainbowDragon    talk    contribs   16:42, 7 March 2009 (UTC)

If you're talking about this image, then it's because you didn't include the Albumcover template. I asked Sean a while ago whether a blank template could be inserted into the summary field automatically, but no reply yet… Maybe it isn't possible. — 6x9 (Talk) 16:46, 7 March 2009 (UTC)

Okay, I see where I misunderstood your post. My (mis)understanding had been that if I clicked on an "upload album art" link that both the album cover template and the fair use statement would be auto-filled. My bad... I know better now. --    RainbowDragon    talk    contribs   17:02, 7 March 2009 (UTC)

[edit] {{Cover}}

• copied from User talk:6 times 9 (relevant bits only)

Something's gone a bit awry on this template. The ending of the sentence is not italicised. Looks weird. (Any way we could format correctly, i.e. " song name" ) ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 00:20, 11 February 2009 (UTC)

You sure you don't mean {{Cover2}}? Like here? Because {{Cover}} italicises everything except for the closing period. Do we need to italicise at all? Because {{Covered}} doesn't. Maybe it's time to give the three of them some uniformity. I suggest:

• leaving Covered as it is
• changing Cover to

This song is a cover of "Song Title" by Artist.

• changing Cover2 to

This song has been covered by Artist under the title "Song Title".

That alright with you? — 6x9 (Talk) 00:36, 11 February 2009 (UTC)

Yes sorry I meant {{Cover2}}. And yes I think that'd be fine, but I wouldn't bold the cover artist as it distracts attention way from the song. Now is this an ask? Or is it a do?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 00:58, 11 February 2009 (UTC)

Sounds good to me.    Kiefer    talk    contribs    admin   19:39, 20 February 2009 (UTC)

Sounds good to me too.    RainbowDragon    talk    contribs   19:43, 20 February 2009 (UTC)

Do you both mean Red's version, with de-bolded artist? Does that mean we should de-bold the artist in {{Covered}} as well? — 6x9 (Talk) 20:09, 20 February 2009 (UTC)

Sorry. I would go with the "not bold" all around, I think. We tend to not bold the Artist name in such side notes, don't we?    Kiefer    talk    contribs    admin   20:24, 20 February 2009 (UTC)

No to bold and no to italics --    RainbowDragon    talk    contribs   20:28, 20 February 2009 (UTC)

So we want it to look like this…

• {{Cover}}:

This song is a cover of "Song Title" by Artist.

• {{Cover2}}:

This song has been covered by Artist under the title "Song Title".

…and {{Covered}} like Cover2 except for the collapsed table thing. Anyone who would prefer a different format? — 6x9 (Talk) 20:53, 20 February 2009 (UTC)

Too late now for objections – they're all updated already. :-) — 6x9 (Talk) 03:26, 21 February 2009 (UTC)

Just when you thought....{{Parody}}  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 15:46, 4 March 2009 (UTC)

Done. — 6x9 (Talk) 20:41, 4 March 2009 (UTC)

Thank you :-)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 11:06, 6 March 2009 (UTC)

[edit] UK Singles Chart badge Top 20 badge

I had an idea and wanted to run it by our community for feedback. As this is an international community and since we do have crossover hits between the US and the UK I wondered if it would be desirable to create a UK Singles Chart badge much like the Billboard Hit badge. It would say something like, "Song" was a UK Singles Chart Hit and perhaps include this logo in the badge (shrunk down, of course) Thank you,    RainbowDragon    talk    contribs   18:19, 21 February 2009 (UTC)

I'm not very good at visualizing (sorry) RD, but I have a feeling you may have opened up a can of worms here my friend, because I'm wondering about charts not only in the Uk and Us but also in other countries...

A similar badge type issue came up recently which related to . During that discussion I expressed my concern that if we allowed a badge for the award, it would open the door for a flood of badges relating to each countries awards, charts, etc. until we couldn't see the lyrics anymore...Ok well I might not have said exactly that, but something not too dissimilar. You get my drift though. It's not that I'm against badges, in fact the more info we can provide the better, it adds interest, but priority must always be given to the lyrics. I also believe that since we have an international community we should be mindful of this in all our decisions.

Obviously being from the UK I would like a badge appertaining to the UK charts, but I imagine most hits are hits in the too, for which the Billboard badge of course applies (so far as I'm concerned Sean trumps it, cos he's in the US and it is his site ). To be honest I stopped following the singles charts when I was 16 and discovered in other words many moons ago so I'm not really in a position to comment. One thing I do know though is that the subject of badges needs further discussion so we can all be clear on this....  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 20:05, 21 February 2009 (UTC)

I must say I agree with Red. Oh no… What is the world coming to??? Well, except for her blatant (mis-)use of images. (Show-off!) Just imagine a major hit, plastered all down the right side with dozens of badges… I'd prefer putting info like that into an "Awards" section below the lyrics. We could still have icons for each award, even though the rest would be plain-text.

Hand me that can-opener for a moment… Maybe we should do away with the B-Hits badge, out of fairness? — 6x9 (Talk) 20:26, 21 February 2009 (UTC)

Okay, I can see where you both are coming from. Then what about changing the B-Hits badge to a generic "Top Twenty" type badge? "This song made the Top Twenty on music charts!" We've already got the No.1 Hit badge that will work for any country. I'm already adding a Chart Info section to pages where I know the chart information.... (RainbowDragon starts shoving worms back into their can) --    RainbowDragon    talk    contribs   20:37, 21 February 2009 (UTC)

Thanks for considering the UK RD but Яєdxx talks sense as usual. I'm not a big fan of the B-Hits badge although I do like the fact it categorizes the song. Perhaps it would be possible to categorize without a badge using the existing song template by adding 'UK', 'US' or 'AU' etc.. to it when editing. This would put the song in to the appropriate 'UK number 1 hits' or 'Australian number 1 hits' for example. Ñô†īṃέ2çяȳ^Talk 20:52, 21 February 2009 (UTC)

@ Notime2cry - The No.1 Hit badge already has a parameter to classify what country it was a number one hit in. Changing the Billboard Hit badge to a Top Twenty badge with a parameter for country would be a really nice thing though. --    RainbowDragon    talk    contribs   21:05, 21 February 2009 (UTC)

Badges can be accommodated without clutter if they can be added via template in a hide able manner like the additional albums data. click show and you see a row of badges that can be clicked or moused over to show extra info or take user to the approp list of XYZ hits. I don't like clutter but the meta data is useful to keep handy. AdAlb is a good example. ∃cho⚡ierr∀ (☏) 21:19, 21 February 2009 (UTC)

Thanks guys..some good ideas coming through as usual from all of you. I'm not saying I know what the answer is, but I like the idea of a (generic?) billboard type badge, with different parameter for country. Echo's idea is also worth serious consideration too.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 21:43, 21 February 2009 (UTC)

I like the idea of an "Awards" (or "achievements" or something similar) section that documents chart peak position and awards in any country. These could be categorized per country (or per award/chart and then country) and use standard templates that would also add the song to the relevant categories. Maybe two columns... {{Award|J Award|...}} or {{Award/J Award|...}} for example. These templates could be plain text with a small image as a "bullet" like the external links section or even badge style (but without floating on the right) but I wouldn't prefer this. There could then be a badge on the song page linking to the section. Such as ("No 1 Hit" OR "Top 20 Hit") and "Award winner" if applicable. ♫ LYRIC-Humbug ^words♪_deeds 02:47, 22 February 2009 (UTC)

Giving this topic a bump - What do you folks feel about a top 20 badge to replace the Billboard Hit badge so that we can have any country's top 20 song represented? (subliminal message: HEY KIEFER!) --    RainbowDragon    talk    contribs   23:11, 27 February 2009 (UTC)

I'm in favour. We need an icon though – somehow I don't think a "20" inside the laurel wreath of No.1 would quite cut it… — 6x9 (Talk) 23:16, 27 February 2009 (UTC)

Mixed feelings about "replace". The US billboard charts are universally recognised. Think about Wikipedia and how often this info is included on music pages.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 11:19, 3 March 2009 (UTC)

How about keeping the Billboard badge but amending the Number One Hit badge so that when you add a country, {{No.1|the United States|the United Kingdom|Germany|etc..etc..}}, it displays a flag within the badge (but perhaps with better flags)for example:

 Ñô†īṃέ2çяȳ^Talk 22:32, 3 March 2009 (UTC)

That would be nice… except for those songs which have been No.1 hits in a dozen (or more) countries. (Just a few weeks ago I increased the number of allowed parameters to 20, because I'd come across a song where the previous 9 weren't enough…) Since those songs are also the most likely to be viewed by a lot of users, we want them to look as good as possible. But flag icons would be nice to have in the Awards section below the lyrics. (If such a thing ever materialises…) — 6x9 (Talk) 22:45, 4 March 2009 (UTC)

Sorry notime..the flags..too many colours...confuses my brain ;)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:00, 6 March 2009 (UTC)

In that case you'd better not look at your own userpage. (Unless the damage is already done anyway…) — 6x9 (Talk) 03:09, 6 March 2009 (UTC)

There are ways to get the balance just right 6. Like on my user page :p  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:14, 6 March 2009 (UTC)

Ah, it's about balance. You're balancing utter chaos with even more utter chaos, so the eye eventually gets kinda sorta used to it because there's no contrast (i.e. a less chaotic section). — 6x9 (Talk) 03:34, 6 March 2009 (UTC)

I'll get round to responding to your post Wednesday week...if you haven't archived it by then of course ;)  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 11:10, 6 March 2009 (UTC)

'Too many colours' lol. Hmm, ok..Hows about country codes or perhaps the entire badge in black & white or Taupe or..or...if it aint broke don't fix it?  Ñô†īṃέ2çяȳ^Talk 00:44, 7 March 2009 (UTC)

(outdent) Here's what I've come up with. Please let me know what everyone thinks.    RainbowDragon    talk    contribs   16:01, 11 March 2009 (UTC)

Mmmm...imagine that with this. Ensure you look at page in edit mode, particularly you 6x9.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:07, 12 March 2009 (UTC)

No need for edit mode, I can see all the categories at the bottom :-/ That page was also the reason why I raised the max. number of parameters from 9 to 20. (And that's just the #1 hits… How many additional countries are there where it only reached #2 … #20?) A plain-text list might be our best option. (You can add the flags to the category pages themselves, though.) — 6x9 (Talk) 03:15, 12 March 2009 (UTC)

(Hoping we can finally wrap this discussion up…) So: the No.1 and B-Hits badges stay the way they are; country/date info is added (in text-only list form, because any fancy formatting would take up way to much space on some pages) in a section below the lyrics (like here). Did I get this right? I hope so, because it means less work for me! — 6x9 (Talk) 04:54, 13 March 2009 (UTC)

Yes, we've pretty well reached a consensus. Topic is now closed. Archive this bad boy! --    RainbowDragon    talk    contribs   19:34, 13 March 2009 (UTC)

[edit] {{Artist}} template

After the recent updates to Song- and AlbumFooter, it's time this one got an overhaul as well. I propose:

1. getting rid of wikipedia, officialsite and myspace parameters – they are obsolete since we got {{ArtistHeader}};
2. getting rid of genre and genre2 as well – {{Genres}} allows more genres and is more visible;
3. add icons for the links (like SF and AF); and
4. add discogs and allmusic parameters.

I also suggest renaming it to ArtistFooter for consistency. What do you think? — 6x9 (Talk) 18:20, 23 February 2009 (UTC)

I like. Although I think we may need to keep wikipedia option in footer too for disambig type cases. I think it's because all the other external links are at bottom, including wikipedia, and if wikipedia isn't in footer with disambig addition, it leads to wrong page. This came up a while back.

Also instead of removing genres from footer, can we not just move them outside of footer and make them visible? And add {{Labels}} too? Ok I know I haven't explained that very well but you probably get my drift. I hope you do anyway (lol) ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 00:35, 24 February 2009 (UTC)

I think it sounds very good. Have you finished yet? (Just kidding) I say go for it!

@ Redxx - I don't believe he wanted to eliminate genres from the footer completely. He's wanting to replace genre and genre2 with a better genre template that allows for even more genres. --    RainbowDragon    talk    contribs   00:44, 24 February 2009 (UTC)

Yes is what I meant (he's very good usually at understanding my double dutch). Yes so to put it better can you not add {{Genres}} outside of the footer, together with {{Labels}} on all new artist templates? Either as seperate enteties or as part of footer but external from it?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 01:02, 24 February 2009 (UTC)

Actually yes, I have finished. :-)

@ Red: With removing Wikipedia I meant completely – i.e. not only the parameter, but also the default search link. As for genres, yes, moving outside of Footer is exactly what I had in mind – {{Genres}} does that already, so there's no use leaving these parameters in the Footer. I think I might know what you mean, but you know I love being difficult, so I'm going to make you spell it out in proper English :-) — 6x9 (Talk) 01:04, 24 February 2009 (UTC)

(post-edit-conflict) Erm… If that's putting it better then I don't want to know how you'd put it worse… So, just to be clear: even though we do have two simple and working templates for genres and labels, you want me to incorporate that stuff into ArtistFooter anyway, making it huge and complex, so that people will have to type even more stuff onto the artist pages? — 6x9 (Talk) 01:07, 24 February 2009 (UTC)

Rfl..well now that you put it like that..

I just meant can we not add Genres and Labels to default new artist pages? Although with regards to labels they are sometimes not listed on wikipedia.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 01:14, 24 February 2009 (UTC)

There. That wasn't so hard now, was it? Problem is, these two templates produce garbage if left blank. And anyway, it's only ten characters each – surely your fingers won't fall off if you have to type that little extra bit? — 6x9 (Talk) 01:35, 24 February 2009 (UTC)

I don't. Type I mean. I use a Firefox thingy so I just paste ;) But yes you're right.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 01:45, 24 February 2009 (UTC)

(Outdent) I think that perhaps keeping the Wikipedia parameter in the footer is beneficial because it allows those pages that don't have a WP link in the ArtistHeader (due to there perhaps not having been one at the time it was placed, or for whatever other reason) to still have a way to do a quick search of Wikipedia. True, it does double up the link on a majority of pages, but the doubling up of such a major external link that is quite helpful in the editing of pages really isn't such a bad thing, is it?    Kiefer    talk    contribs    admin   03:36, 24 February 2009 (UTC)

In this case I'd suggest |wp=off to turn off the search on pages with WP link in the Header. Until Semantic anyway. — 6x9 (Talk) 03:44, 24 February 2009 (UTC)

Why is the link bad to have in the external links section, though?    Kiefer    talk    contribs    admin   03:58, 24 February 2009 (UTC)

It's not bad to have, it's just annoying to need to enter the same parameter into two templates on the same page. What if we added a default WP search to ArtistHeader instead (i.e. normal link with wikipedia parameter as it is currently, but rather than no wp link at all, display a "Search Wikipedia" link)? — 6x9 (Talk) 04:12, 24 February 2009 (UTC)

I'd agree to 6x9, moreover - I think he's idea of |wp=off is nice and may be applied in other templates too. Take for example mb parameter in AF: it's allright when we have one-album release - when MbId is known, we have a direct link to album page on MB, otherwise - link to MB-search. But if release contains >1 discs, each of them may have it's own link to Mb, using {{MusicBrainzRelease}}. But then default MB search link, generated by empty mb parameter, looks redundant, if not silly.--Senvaikis ^(talk) 11:16, 24 February 2009 (UTC)

Same goes with multiple instances of wiki links stored on song pages... example ∃cho⚡ierr∀ (☏) 11:50, 24 February 2009 (UTC)

I'm not really comfortable with a "Search Wikipedia" link in the ArtistHeader. First, because I feel that that info box, being so visible and at the top of the page should be for containing "for sure"-type information, not "we don't know if the info exists, but you can try"-type of info. Second, I'd be worried that editors would be slightly less interested in making sure the link was direct to the correct WP artist page. I guess I could live without a link to WP at the bottom of the page if there was a "for sure" link in the ArtistHeader, but I don't think I could live without a search link at the bottom if there wasn't a link in the ArtistHeader. And to me, filling in a parameter with "off" is as much a problem as just entering the correct link to the WP page.    Kiefer    talk    contribs    admin   04:36, 25 February 2009 (UTC)

I agree with Kiefer. If there is a "for sure" wikipedia link in artist header without disambiguation I remove the wikipedia parameter in footer. If there is disambig addition to artist name I leave it. The reason being that this subject came up before as a problem..though I can't recall who mentioned it.  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 11:24, 3 March 2009 (UTC)

With the new Variables extension that's not an issue any longer: it's now possible to disable the search link in the footer automatically when a direct link in the header is provided. Same for myspace. — 6x9 (Talk) 15:46, 3 March 2009 (UTC)

New Variables extension?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 03:16, 6 March 2009 (UTC)

…that Sean installed a week ago. Looks like you're seriously behind with your watchlist. Hint: it's far easier when you only watch obscure songs that no-one's gonna edit anyway since they never even heard of them. — 6x9 (Talk) 03:27, 6 March 2009 (UTC)

[edit] OOOoooge artist pages, transclusion, (bots) & the API

• This is a continuation of the subpages discussion here.

Transcluding song lists from album pages onto artist pages would make the latter nicely small, but unfortunately the API wouldn't find the songs anymore. But how about transcluding just the song lists from compilation & live albums where each song is already listed elsewhere on the artist page (under a regular album)? This would: (1) reduce the page size (and, in some cases like Jethro Tull, make the page botable again); (2) NOT make the songs invisible to the API; and (3) keep Kiefer happy – he's obviously a fan of REDundancy :-) So, would this be a viable alternative, or am I missing something? — 6x9 (Talk) 21:55, 27 February 2009 (UTC)

make an example page and let's see if it holds up ∃cho⚡ierr∀ (☏) 22:28, 27 February 2009 (UTC)

Alright. See Marillion – I've transcluded the tracklist for "Real to Reel (1984)". Displays as before. All tracks are already listed elsewhere on the page. Any problems? — 6x9 (Talk) 22:46, 27 February 2009 (UTC)

Real to Reel is invisible to API 6  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 22:50, 27 February 2009 (UTC)

WHAT is invisible? The album page itself? But that link is unchanged. Or the tracklist? But the tracks themselves are visible elsewhere on the page. I KNOW that transclusion of a certain tracklist makes that tracklist invisible to API, like I wrote above, which is why I only proposed to do this for redundant compilations and live albums (such as R2R). — 6x9 (Talk) 23:06, 27 February 2009 (UTC)

Your blood pressure has just risen. Do some chanting..Om...Om.. ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 23:21, 27 February 2009 (UTC)[3]

(Ohm? Resistance is futile!) Alright, so album links get ignored if there's no #s below them. (And cheating doesn't work here, unlike {{OL}}). So how terrible is it if an album can't be accessed, when the songs themselves are still accessible? — 6x9 (Talk) 23:31, 27 February 2009 (UTC)

(...the data shall be Redundificated) How terrible is this: JLH Test? ∃cho⚡ierr∀ (☏) 23:46, 27 February 2009 (UTC)

Echo, at what point does a page become unbotable? What size?  ♫_♫Яєd_{xx ♪}♫♪_♫♪ ^Actions _Words 00:10, 28 February 2009 (UTC)

As long as large pages can be detected by some means (like a Category:.* flag), that'll do. The page size limitation is on the server side of the bot interface, not the driver side. My point is that large pages are not in conflict with api, or the web interface. We don't need to reinvent section editing, it's already here. ∃cho⚡ierr∀ (☏) 02:19, 28 February 2009 (UTC)

Botability was one idea behind it… the other was reducing redundancy: if tracklists are transcluded from album pages, only the latter need to be updated. But if it doesn't work, it doesn't (and this partial solution wasn't very satisfying anyway). It would be nice if the API could fetch the tracklist from the album page instead, but I know next to nothing about programming and have no idea whether that's at all possible or just fiendishly complex. — 6x9 (Talk) 03:19, 28 February 2009 (UTC)

Hi all; glad to hear my "old broken record" playing ;). Some of you know I used to swear not to rise this problem anymore, but just could not resist from adding my 2 p$ here :). First (and the main) thing I've understood long time ago: this discussion is vain till it goes without Sean, the only person here, able to redesign API (or make it's code public). That's because API should be redesigned in any way. The second thing is how it should be done. I may be wrong, because I have absolutelly no idea how it's made and how does it works, but seems to me that now API is based on plain artist page parsing. That's why after adding songs to the album page we must to repeat the same on the artist one. That's why it's so "format-sensitive". And that leads not only to doubling of editing job and artist pages oversizing. There is one more, not mentioned here problem - data integrity. Have you ever checked if album tracking on artist page corresponds to one on the album page? Then you know they may be different. Then what info I should believe? API's providing only info from artist page. So, the problem you are discussing here is hardly related not only to API redesigning - it may lead you to general rethinking of LW data organising, - more based on structural, object-oriented, typed relational data handling. I do believe Semantics may be very useful here... Sorry for erratic post - have no time to fall short of it, must leave. Good luck, --Senvaikis ^(talk) 10:33, 28 February 2009 (UTC)

(outdent) Thank you vety much Senv for pointing out yet another long standing redundancy issue at lw, Album tracklist vs. Artist page tracklist of same album. It looks like the main problem (assuming Sean is going to rewrite the code) is if there is to be one tracklist only for each album, where should it reside? Album page or Artist page? and then there is the matter of bureaucratic inertia & doubleX redundancy.... oh well ∃cho⚡ierr∀ ( ☏ • ⎋ • ⌫) 20:00, 28 February 2009 (UTC)

The question of "where" is simple: since you can easily transclude the tracklist from an album page onto the artist page, but not part of an artist page onto an album page and then another part of the artist page onto another album page, the logical place for the tracklist to go is the album page. — 6x9 (Talk) 20:13, 28 February 2009 (UTC)

[edit] S2E2 overly zealous...

It seems to ignore the fact that some pages have mergefrom or mergeto in it, and gleefully tag them for deletion and/or remove the merge tags. This is not right. If the pages have been tagged for merging, then it should leave it so that a human can merge them, not act as if the merge tags were meaningless.—gniw 18:29, 28 February 2009 (UTC)

Can you provide a link? ∃cho⚡ierr∀ ( ☏ • ⎋ • ⌫) 19:26, 28 February 2009 (UTC)

Look here [4] and here [5]. hth ∃cho⚡ierr∀ ( ☏ • ⎋ • ⌫) 19:38, 28 February 2009 (UTC)

Thanks for the links. The pages I tagged for merging are 飛兒樂團 (F.I.R.):我們的愛 and 飛兒樂團 (F.I.R.):我们的爱.

I probably will merge them today… =P—gniw 20:31, 28 February 2009 (UTC)

(Pagesize = 113,697)