Talk:Community Portal

Back to page

1,816,913pages on
this wiki

…to the Community Forum's talk page! This is the place to talk about the site with other editors, make plans for future changes, discuss problems and discover solutions.

Have fun, keep a cool head in discussions, and remember to always sign your posts!

  • Topics are in relative chronological order, top to bottom, so please add your post at the bottom of the page.
  • For questions about editing, see the Help Pages. If you still can't find what you're looking for, post your question at the Help Desk.
  • Current projects with links to discussions: [edit]
Project Link Page/s
Policy change for root pages LyricWiki:Proposal For Root Pages Policy

Non-Latin artistsEdit

After discussing the matter with the other admins, we decided to get rid of the "Native (Romanized)" pagenaming rule for non-Latin artist names. This should make things simpler, less ambiguous and less ugly. Of course it will take a while until all affected pages are moved and cleaned up.

Please note that, for artists and albums, the |roman parameter should still be used to indicate romanized name/title, to improve searchability. — 6×9 (Talk) 11:51, October 18, 2015 (UTC)

Sounds good! I never understood that anomaly in the first place and I think most beginners neither Smile Greetings, --Fassbrause (talk) 19:09, October 18, 2015 (UTC)
So for example, 倉木麻衣 (Mai Kuraki) would be renamed to 倉木麻衣 only?? — Steffy13 (Talk) 10:52, October 22, 2015 (UTC)
That's how I understood the change Smile. See the corresponding updated help page. Greetings, --Fassbrause (talk) 12:03, October 22, 2015 (UTC)

> Hey there! Start getting comfy 'cause this is looong and a bit confusing (at least for me). Even though I tried it to make it brief, I couldn't Cry. So...

I was discussing with Lichtweber and EchoSierra about how the pagenaming for non-Latin artists should be. It was said before that the naming should go according to how the artist's name was on their albums, but then appeared some doubts about it. In some cases, the albums had the romanized name on them, but on other media (such as iTunes, Youtube, official charts...) appears their non-Romanized name. So we started discussing which name should be prioritized: the one the artist put on their albums' covers or the one put on their sales pages and other media.

Aside from that, supposing we follow the cover-name rule, there are some complications about it too:

These are the main problems with the covername-rule. Using one or another would solve partially the problem, but it won't be as accurate. On one side, non-Latin names may be more easy to find (and easier to edit too, truth be told :P), but I'm still a bit doubtful if it's the best way to do it because aside from the cover, most of pages list their native names.

So, I'm asking what do you think about this? Should we use the cover name? Their non-Latin name? The Latin name? One of them even if it varies from album to album? A different one depending on the album? Both? None XD? Abuse of redirects? I'm very confused, really Unsure I would prefer if we could avoid having a bunch of exceptions and special cases, it's much easier a one rule XD.

Thank you for your time and patience Grin

P.D.: Most of examples are Japanese because I'm more familiarized with Japanese artists and music, but this also affects other non-Latin artists, such as Taiwanese, Russian, Greek, Arabic, etc etc.....
~Steffy13~ > talk > contribs 18:24, October 23, 2015 (UTC)

  • This issue is not exclusively a matter of confusion by non roman artists, plenty English speaking artists use different names on different releases, please see Laveerre; and for now please do not emulate what you see on that page (different namespaces for each alias of the artist), that practice is in the twilight zone.
  • The reason (imho) for using name per (majority of past) covers by the artist is that it's a historical milestone that unlike fb/homepage/youtube titles etc. cannot be retroactively changed.
  • We have artist redirects for name variations, aliases etc.
  • A matter that has not yet been policified (afaik) but we have been following as a best practice is the One artist, one page practice, so creating multiple pages for the same artist is out of the question (and there are still pages that remain to be merged (see Index AI)'s aliases in ArtistInfo section.
  • For artists that have used other titles but now are using yet another title 上木彩矢 (Aya Kamiki), we use the most recent title, again, not a matter exclusive to CJK artists.
  • Majority of CJK pages will be moved to their native page name.
  • For the pages that you are working on, and the artist has used a mix of native and romanized artist title over the years, I'd suggest making a list of such artists until a clear resolution and policy has been defined.
  • For the case of artists that use both native and romanized like كیوسك I kept the roman artist title for songs/albums artist pages, and used DISPLAYTITLE in persian. No way anybody will have a hard time finding the band!
  • lw being a reflection of the real world, no matter what us admins try to streamline by policifying, there will be exceptions and contentious cases like this one... or artist collab/album collab! and certainly this discussion needs more input. --ES (talk) 20:07, October 30, 2015 (UTC)

Appeal to adepts of African languagesEdit

Please, help me to clean finally the Category:Songs Needing Language Identification, containing atm 4 songs by Deep Forest, - all from their album Deep Africa (2013).
Baie dankie by voorbaat! --Senvaikis (talk) 08:35, November 13, 2015 (UTC)

Should song lyrics contain marks where guitar solos start?Edit

I wonder if lyrics should contain marks like "Solo (name of guitar player)"?
If this info is really needed, maybe there should be some kind of template?
--OlenJ (talk) 12:42, December 25, 2015 (UTC)
See Help:Contents/Editing/Formatting/Songs#Lyrics: Please do not include notation like "Chorus", "Bridge" or "Guitar solo", chords or time codes in the lyrics.6×9 (Talk) 23:20, December 25, 2015 (UTC)


I've been overhauling our old {{Song}} template to make use of the dpl extension. The result should be (mostly) easier to use, but also comes with a few radical changes (some of them visual):

  • song, romanizedSong (now roman) and language parameters are moved from Footer to Header
  • song title is displayed in a title bar (like Album- and ArtistHeader; always seemed like a waste to have it only show in the external links)
  • album parameters now take the full pagename (no more need for albumartist parameters, no more different behaviour for type=compilation/soundtrack)
  • allows for multiple artists, so it will replace {{SongCollaboration}} as well

All changes are described in the new template's documentation. Any criticism, feature request, warning of potential problems or layout improvement is welcome. I will soon (sometime next month, I hope) start converting all SongCollaboration instances; if no major problems appear, I'll then move on to the "normal" song template. — 6×9 (Talk) 09:30, January 30, 2016 (UTC)

Oh yes, nice work as always! My only minor issue for now would be to increase the regular featured artist count to say maybe 5, as certain genres like Hip Hop tend to favor more fa's. And well, how about showing the actual flag icon of a language (where possible) instead of the generic flag icon? That should be more intuitive for normal users. Greetings, --Fassbrause (talk) 13:51, January 30, 2016 (UTC)
  • fa: I'd like to unclutter the header, hence the |featured parameter in CreditBox for > 3 artists. But if the majority is for 5 fas, I'm willing to be overruled.
    • Another (separate) issue is whether to keep autolinking fas – the majority probably has no solo releases and therefore will stay red, and many probably link to the wrong artist page.
  • Flags: That was my first idea too, but flags signify nations, not languages. Do we use the UK or the US flag for English? Either way, the Irish (Republic, not Northern) might feel left out. Spanish is spoken in many countries other than Spain, same for Portuguese (though at least we have a separate cat for br-pt). — 6×9 (Talk) 14:25, January 30, 2016 (UTC)
  • I don't think it would add to much clutter as long as line breaks are kept in the header (maybe it would be the perfect time to make it a rule and write it down in the docs? After all, it would comply with artist page headers and song page footers). Though I don't now if that is compatible with the bots.
    I could very much live without autolinking of fas (for your reasons mentioned) - as long as it is easy to do it manually.
  • Yes, you are right flags don't cut it either. How about simply writing out the lang name or using the short ISO codes? Or maybe we can come up with a better generic symbol, maybe the language icon?. It's just... as a simple user I wouldn't expect a language category behind the icon. That's all I wanna convey here Smile. --Fassbrause (talk) 15:03, January 30, 2016 (UTC)
  • I meant clutter on the saved page, not in the source. Imagine a song with 3 albums and 5 fas – that's a lot of commas.
  • Having text next to the star icon would look weird. The generic language icon hasn't really caught on, though it's been around since 2011 (not that its predecessor fared any better), so I'm not sure it'll be any more recognizable. The multiflag icon OTOH is used by our {{NoLang}} and {{TranslatedSong}} templates (where the generic icon would look too bland/boring). — 6×9 (Talk) 20:35, February 1, 2016 (UTC)
  • Flags: i took the liberty creating a multilingual icon: Icon - Multilingual. What do you think of it? Can we use this instead of the old flags?  · Lichtweber talk service  18:59, February 3, 2016 (UTC)
For SH I'd prefer something simpler, like this: LangIcon – remember it has to look good at 15-20px. — 6×9 (Talk) 21:26, February 3, 2016 (UTC)

For now I'll proceed with 3 unlinked fas and the blue speechbubble icon. There's still more than enough time to change things later on… — 6×9 (Talk) 11:37, February 14, 2016 (UTC)

Looks good so far and I like the blue icon Smile. One more minor issue: There is now a pretty big whitespace between the Edit/Talk toolbar and the song header box, compare before and now. (Optimal) solution could be to move the lang & star icon in line with the edit/talk bar (not sure if that is possible) or else move them in line with the song title bar? Greetings, --Fassbrause (talk) 20:45, February 16, 2016 (UTC)
Already tried that – not possible in wikia skin, because moving anything outside the article container makes it disappear, which no amount of z-index will change. We tried to come up with other solutions, but none of them were convincing. — 6×9 (Talk) 21:47, February 16, 2016 (UTC)
Maybe it could be moved inside the song title bar to keep the boxes the same width? I don't remember if you played through the possibility as well and would accept it as a solution. Greetings, --Fassbrause (talk) 22:07, February 16, 2016 (UTC)
Most of this discussion already happened pretty much the same way on the admin portal, so if I'm shooting down most of your suggestions it's not because I don't like you :-) The Bronze and Gold stars would be near invisible on the title bar unless you put them in a box; and some of the other colours would clash horribly. Plus, there's the matter of consistency with artists and albums, where the star is also at the top above the box (though at least albums make better use of that space). The cert and lang icons are actually the result of attempting to make better use of that space. — 6×9 (Talk) 18:30, February 17, 2016 (UTC)
Good points, I can understand them. A box could work though.
It's just... one third of the vertical space on a song page is sacrificed for the navigation (always visible Wikia bar...) and display of the page title before one can read the first line of lyrics :| Maybe the song header can one day be moved to the right side like the album box, coupled with {{Youtube embed}}, {{WP-Song}}, a Spotify player (Make it happen, please) and a track by track navigation/tracklist of the album tracks. I could see some benefits. Greetings, --Fassbrause (talk) 18:56, February 17, 2016 (UTC)
Would it be better to left-align the little icons? That would slightly reduce the impression of white space, since English-readers read from the left. --RWDCollinson (talk) 15:39, February 21, 2016 (UTC)

I just want to point out that there are a lot of featured artists who *aren't* red. I've been working on a lot of country songs recently, and those people seem to be constantly featuring each other in their songs (just one or two doing backing vocals, or perhaps singing one stanza). Will it be easy to restore the link manually, and will there be a way of finding out which song pages this affects? --RWDCollinson (talk) 13:35, February 18, 2016 (UTC)

Manually linking will work the same as elsewhere – you can do |fa1=[[Artist Name]] or |fa1=[[Artist Name|Link Text]] or even |fa1={{wpi|Artist Name}} if the artist has no LW but a WP page.
I wasn't sure whether to make the bot check for blue artists and keep them linked, because there are probably many fas linking to a different artist (maybe not in country music, but certainly in the hip hop world). But the correct links probably outweigh those. — 6×9 (Talk) 19:02, February 18, 2016 (UTC)
Thanks --RWDCollinson (talk) 15:39, February 21, 2016 (UTC)

Update: Replacing {{SongCollaboration}} is done, I'm slowly starting on {{Song}} now. I'll also update the documentation and get someone to change the new page autotemplates. — 6×9 (Talk) 17:39, February 19, 2016 (UTC)

So there's a new header, will it be permanent? 'Cause it looks amazing! and it's much more easier to use. Great work, guys! (SirDogg (talk) 15:02, February 21, 2016 (UTC))
So, here's a suggestion: could we have an Oxford comma before the 'and' in the 'appears on the album and on the' list in the header? It would divide up the list and make it easier to read.
This is definitely much better than the previous template. Thanks for all the work, again. --RWDCollinson (talk) 19:24, February 25, 2016 (UTC)

Not sure if it is intentional (as the bot removed |artist parameter from the songfooter), but for songs with multiple artists the links - which are generated in the song footer - contain "various artists" as artist. The nature of it makes it hard to get good results on external sites like amazon etc. If it doesn't interfere with anything else I would like to see it changed to the pattern artist1 & artist2 (or take the first part of the page title?) to make it easier for users to find and insert external sources. Greetings, --Fassbrause (talk) 18:05, March 3, 2016 (UTC)

@RWDC: Wouldn't it be clearer to instead put commas before the list of albums? "is by A, and appears on the album X and on the album Y"
I'm also starting to think it might be better to switch to a bulleted list at three albums (currently four), as that sentence can get pretty long. Opinions?
@FB: That's a problem of SF, not SH (and inherited from SongCollaboration) – I've removed the v.a. text from most search links, but haven't got around to all of them yet. Part before first colon wouldn't really be useful if the first artist had a name like {{D:Ream}}… Using a1 & a2 (or just a1) would be doable, but seems unfair to a3 etc. — 6×9 (Talk) 08:03, March 5, 2016 (UTC)
Thanks! Sorry for my blame of SH Smile. And sorry if I wasn't clear in my writing; I meant to include every artist of SH then for the links in SF if possible. I've only listed artist1 & 2 to shorten the example.
Regarding the album listing: I'm all for a shorter notation, go for it. Greetings, --Fassbrause (talk) 18:22, March 5, 2016 (UTC)
There are two thing's currently bugging me about the album bullet list in SH, most visible on this page:
  1. There's a lot of whitespace on the right of the template; more than 50% of it is currently whitespace, and only really long album names take up this space.
  2. Seeing as the bullet list isn't collapsible at 3-4 albums, the lyrics (the part of the page users are here for) is pushed down lower
Is there something that could be done for this, maybe make the list collapsible as soon as it becomes bulleted? - Patzilla777 (talk - contributions) 12:17, March 27, 2016 (UTC)


With the spotify player now being introduced into wikia, should the player be introduced into this wiki? This is something that I have thought of many times when visiting the wiki. If this was something that would be considered, I would assist in adding these where possible. ShufflerChat 14 / 02 / 2016

Width can be reduced to 250px, so it would fit in nicely with our song badges and with {{youtube embed}}. The biggest drawback is that not every user has a spotify account; therefore it might be a good idea, if possible (and if we decide to do this), to add an option to user preferences to hide the spotify player. — 6×9 (Talk) 11:45, February 14, 2016 (UTC)
If it's possible, both technically and legally, then I think that's a wonderful idea. If bots could handle adding Spotify player to the pages, LW would become even better than it is now (and it's pretty damn good already in my opinion). So if it's some kind of community poll, count me in. Smile --Ozpl (talk) 13:53, February 14, 2016 (UTC)
The player itself can be made quite small (250px by 80px) so it would not take up too much space on the page. Being so small it would not force anyone to use the player at all, so there should not need to be reason to hide it, unless of course the community feels like it would be intrusive. I already have a bot on the Yogscast Wiki that adds Spotify players to pages automatically, so I can always run that for the majority of the pages on here if the community agrees to implement this feature.
ShufflerChat 15 / 02 / 2016
Isn't it possible to listen to those embedded spotifies, even if you don't have an account?  · Lichtweber talk service  05:52, February 15, 2016 (UTC)
No, it seems that you must have an account, though the large majority of people have accounts now. ShufflerChat 15 / 02 / 2016
@LW: the account issue (as previously noted elsewhere[s]) baffles me; with or without an account, the service (spotify, yt etc.) collects the user IP address etc. anyway, as is the case with any http activity. An account can be had by providing minimal unidentifiable identity: so why not make an account? I musta be missing something as usual... -- (ES) 06:04, February 17, 2016 (UTC)
@ES: It's just that I simply don't want to.  · Lichtweber talk service  18:58, February 18, 2016 (UTC)

For anyone that maybe wondering how it would look on pages, I have included an example here. It can easily be changed into a template to be used on multiple pages. ShufflerChat 18 / 02 / 2016

For those who are eager to take advantage of embedded spot-player without waiting for a "better times", I may remind about alternative solution, based on js-driven "on-fly" spot player embedding (and suggested almost 2 years ago):
Quote by Senvaikis @Spotify vs Goear?: "Btw, for those who don't mind spotify-"registering" or adding a few lines into user.js, I'd like to show, how spotified LW page may look like and how does it work on my box."
All you need for that - just copy one line into your common.js page:
importArticles({type: 'script', article: 'u:lyrics:User:Senvaikis/spotplayer-js'});
You may want also to add some "customization" (swithing the player on/off):
var loadSpot=true; //set loadSpot=false to "switch off" the player 
if (loadSpot) importArticles({type: 'script', article: 'u:lyrics:User:Senvaikis/spotplayer-js'});
hth, --Senvaikis (talk) 11:25, February 18, 2016 (UTC)
Senv, I tried it but it didn't work for me sadly. Can someone confirm that the snippet works? Either way, I'm looking forward to have a Spotify player included. Greetings, --Fassbrause (talk) 17:10, February 18, 2016 (UTC)
Embedded spotifies work for me though I don't have an account :) No objection.  · Lichtweber talk service  18:58, February 18, 2016 (UTC)
@FB: Sad (and strange) indeed... Have you checked if the checkbox "Enable personal JavaScript" on your Preferences/Under the Hood page is selected? Btw, what a browser are you using? --Senvaikis (talk) 19:21, February 18, 2016 (UTC)
I forgot about the checkbox, indeed. I'm using either Chromium or Firefox and thought an extension blocked it, but no. Thanks for working it out! Greetings, --Fassbrause (talk) 20:05, February 18, 2016 (UTC)
@LW: I wonder if your spot streams will get reported as c/o LyWi or c/o AdminLW!? Cool duckin 'n' runnin --ES (talk) 19:31, February 18, 2016 (UTC)
Using the Spotify embed without an account gives me only a 30 second preview. Maybe that's what Lichtweber had too? - OneTwoThreeFall (talk) 12:30, March 11, 2016 (UTC)
Right, but, for me, that's usually enough to verify.  · Lichtweber talk service  21:05, March 11, 2016 (UTC)

iTunes links Edit

Some iTunes links end with "?i=[numbers]", but removing this string seems to lead to the same page. Does this parameter ever make a difference, and if not, should it be removed from all iTunes parameters? ~Bobogoobo (talk) 10:48, March 2, 2016 (UTC)

iTunes links with "?i=" are links for specific songs, as opposed to links for albums. There's a slight difference - on the iTunes page, if you look at the row for the song that the link was for, it'll have a shaded background. Also, I believe these links have different behaviour if you have the iTunes program installed (though I've not tested this myself). - OneTwoThreeFall (talk) 12:43, March 2, 2016 (UTC)

Infected spoof lyric siteEdit

Someone has made a spoof copy of songmeaningsDOTcom at songmeaningsDOTxyz; It appears that clicking anywhere on any page in xyz (if you have js enabled) will cause all manner of strange activity in your browser. Some of the js code on xyz point to a Russian site, but xyz in registered in US, hmmmm. Browsers beware. --ES (talk) 10:40, March 13, 2016 (UTC)

WrongTitle template - is it redundant now? Edit

Hey guys, I was wondering, due to latest change of {{Song}} template, is {{WrongTitle}} even necessary? SongHeader's title display looks really nice and I'm not sure that we need that anymore. Same goes for AlbumHeader and ArtistHeader, they all cooperate really well with displaying titles that are not permitted by LW:PN. There's always {{DISPLAYTITLE}}, though I'm not sure that it's allowed (I saw that on few pages but I don't know that case is resolved by policy). What do you think? --Ozpl (talk) 13:26, March 15, 2016 (UTC)

Formatting of RTL albums Edit

What is the correct way to format album titles in a right-to-left script? For example, the titles in Category:Albums Hebrew don't look quite right, but that seems to be how text editors try to group the conflicting directions. Should we force it into "tsitra:mubla (year)"? ~Bobogoobo (talk) 10:25, March 20, 2016 (UTC)

HebCat in TextEdit --ES (talk) 13:26, March 20, 2016 (UTC)
@ES: Your picture is very nice and helps a lot ;) --Senvaikis (talk) 16:46, March 20, 2016 (UTC)
I skipped the video, my bad ;-). Copying the properly formatted and displayed text from OSX TextEdit to this edit box transforms it into:
	▪	הבילויים:הבילויים (2003)
	▪	רונה קינן:לנשום בספירה לאחור (2004)
	▪	רונה קינן:עיניים זרות (2007)
	▪	מוניקה סקס:פצעים ונשיקות (1995)
	▪	הבילויים:שכול וכישלון (2007)

Wikia's bad. You don't recall your editions of a Hebrew artist page that looked crazy either way...?--ES (talk) 21:01, March 20, 2016 (UTC)

P.S. This is why Kiosk albs are en-titled, even though per alb cvrs, fa was an option. --ES (talk) 21:47, March 20, 2016 (UTC)

I think this problems needs two solution:

  1. A template that displays the binary file (Album Art/YT) aligned left, and the text aligned right, so the test wrap around the binary f.e.:here (and on artist & alb pages) will get fixed. 6?
  2. (the tough one) The page names with bidirectional text (Album pages, or any song pages containing #s), Bob's example on cat pages.
Might be our luck and 6 can apply some wizardry, otherwise this 2nd one has to come down from Wikia. Best I know, non of the RTL wiki(a)s have our page naming convention and if they do, they can use arabic/hebrew script numbers to avoid Bidirectional text in page names. Or our templates (did I say 6/۶?!) might have to be modified so they can deal with Arabic/Hebrew #s;
(هایده:شانه هایت (۲۰۰۸ instead of (2008) هایده:شانه هایت (<-If you create this page, in preview you will notice the mess). But to get it to work, it has to be هایده:شانه_هایت_(2008), and the associated categories are a mess. Happy Easter! --ES (talk) 18:58, March 25, 2016 (UTC)

Collaborations v. 'Featured' on Artist PagesEdit

Following up on a long conversation I've been having with ES on my talk page, wouldn't it be better to have separate section for 'Collaborations' (ie, songs where multiple artists have a roughly even contribution) and 'Songs Featuring [This Artist]?' Apparently there's a previous discussion on this, but I can't find it.

These things just seem very different. A featured artist is sometimes just providing backing vocals or a couple of lines; it's totally different to a full-scale duet. This seems like information which is useful to viewers, and especially appropriate to LW, on which users actually listen to the songs and can make a judgement about whether the song is a collaboration or a single-artist song with a featured artist.

The case in point here is the artist page for Ricky Skaggs, which (in line for the 'featured' format) currently lists 'Friendship by Ray Charles'. But this song is a full scale duet; although it appears on a Ray Charles album (an album of duets), there's no sense in which this is 'by' Ray Charles any more than it is 'by' Ricky Skaggs.

That this distinction is industry-recognised can be seen in the example, from the same album, of Ray Charles & George Jones:We Didn't See A Thing, which is a duet but Charles and Jones, but also features Chet Atkins. This is actually written on the disc.

--RWDCollinson (talk) 08:53, March 30, 2016 (UTC)

In this case, I'd say you're correct in terms of whether the songs are "dual-credit" collaborations or songs with features.
However, "users actually listen to the songs and can make a judgement about whether the song is a collaboration or a single-artist song with a featured artist" rubs me the wrong way, because some artists credited as featured have a substantial part in the song too (see any song by a producer featuring a vocalist), so I'd prefer if we stick to what's written on the album/in sources, as opposed to the opinion of the editor.
In regards to collab vs. feature on the artist page, I think only one "Collaborations" header would suffice, as technically a featured artist is still collaborating with the lead artist, they way it's written can change though, depending on whether it's a joint credit or featured credit (e.g. "with" and "by" respectively). - Patzilla777 (talk - contributions) 14:35, March 30, 2016 (UTC)
Thank you for your response. My current query is about the titles that should appear on album pages, rather than the categorisation of songs. The docs currently don't list 'Collaborations' as a valid subsection title, although that title is used on a substantial number of artist pages.
But on the point you raise (which I am discussing with ES at the bottom of my talkpage), couldn't we just set out one rule for clear-cut cases (50/50 division of vocals for collabs, backing vocals only for featured), and leave the rest to external sources? Even that seems a little dependent to me; if LW is supposed to go on 'the lyrics as sung', it seems very strange to be relying on potentially fallible external sources for this. Relying on external sources seems more suited to a site that transcribes 'official' lyrics where possible.
--RWDCollinson (talk) 15:01, March 30, 2016 (UTC)
I'd prefer the idea that we go with "featured artist unless otherwise specified" (either by majority of sources saying it's a joint-credit collab, or the album/back cover shows "and" or "with" instead of "featured"), as this avoids relying too much on opinions, like I mentioned earlier.
E.g. some songs have a featured artist who does arguably more than the lead artist (e.g. rappers featured on a song by a singer: rapper has far more words in most cases). - Patzilla777 (talk - contributions) 15:15, March 30, 2016 (UTC)
Hmmm. Rap makes everything complicated! I think from the casual viewer point of view what they really want to know is a person's actual contribution to the song, but in most cases it doesn't seem to make a huge difference. While I'm here, do you have an opinion on Tanya Tucker:I Won't Take Less Than Your Love? The (compilation) album back cover says 'With Paul Overstreet and Paul Davis', and the song is evenly divided (three verses, three choruses, one each per singer), but none of the external sources acknowledge this except for Indeed, most of them don't even mention the other two artists! This is part of my difficulty here; a lot of our external sources are sadly of dubious accuracy.
--RWDCollinson (talk) 09:27, April 1, 2016 (UTC)
Does anybody have an opinion/enlightenment on the original issue? Since posting, I have noticed that the George Strait page that ES held up as an exemplar seems to distinguish between songs recorded 'with' and songs 'by', so it is possible to make a subtle distinction between collaborations and songs in which the artist is only featured in the 'Songs Featuring X' section. But I still think it would be helpful to have a separate section for collaborations.
PS: I've realised that this was actually what Pat was referring to at the end of his first response. Fair point!
--RWDCollinson (talk) 09:27, April 1, 2016 (UTC)
For deciding credits "and" and "featuring" are pretty clear, but "with" seems to mean either. In the case of that Tanya Tucker song, IMO Tucker is clearly seen as the lead artist, otherwise it would be credited as "Tanya Tucker, Paul Overstreet & Paul Davis". Not to mention the back cover doesn't even seem to list them (at least not clearly - the image quality isn't excellent). - Patzilla777 (talk - contributions) 11:59, April 1, 2016 (UTC)

Missing language help text refers to SongFooter Edit

The help text that tells you that the song is missing a language directs you to adding it to the SongFooter instead of the SongHeader. Johtso (talk) 11:50, April 8, 2016 (UTC)

Thanks for the hint, fixed it done  · Lichtweber talk service  12:30, April 8, 2016 (UTC)

SongHeader and empty spaceEdit

Having the star etc. icons above the SongHeader leads to a lot of wasted space:

Sh before

With a bit of javascript* they can be moved into the empty space above: *) css is preferable but doesn't work in wikia skin because of "overflow:hidden" on the container element

Sh after

If you want to try this out for yourself, put the following code by OneTwoThreeFall in your personal js (and check "Enable personal JavaScript" under "Advanced display options" in your preferences):

$(function() {
        .css({"float": "right", "margin-top": "4px"});

If no one finds any bugs or has a problem with it, I'd like to eventually move this into the site's wikia.js. — 6×9 (Talk) 10:33, April 16, 2016 (UTC)

Sounds good to me. ~Bobogoobo (talk) 01:18, April 17, 2016 (UTC)
PS. I forgot to mention that this will also apply to the star icons on album and artist pages. — 6×9 (Talk) 06:27, April 17, 2016 (UTC)
@6: Well Done!. Let us know when it become redundant in our personal.js. --Senvaikis (talk) 07:41, April 17, 2016 (UTC)
Looking a bit deeper at this - why does .WikiaArticle need position:relative? It only has a z-index of 1 anyway. If you change that back to static and give #header-icons position:absolute;right:0;top:6em; then it looks fine. Unless there's some obscure (or not) thing that actually relies on that positioning? ~Bobogoobo (talk) 07:45, April 17, 2016 (UTC)
You'll have to ask Wikia staff about that… Might be that some future global change would break things if we override this. Or maybe, in their view, it falls under "It should not be used to change the layout of the frame around the content" [1] (even if the layout is not visibly changed). — 6×9 (Talk) 10:04, April 17, 2016 (UTC)

UPDATE: I moved the code to LW's wikia.js, and it has been approved. Those of you who added it to their personal js can remove it. — 6×9 (Talk) 10:52, May 3, 2016 (UTC)

It looks a bit weird on diff pages. Maybe it would be better not to move it in that case?
$(function() {
    if (!mw.util.getParamValue('diff') {
        $('#header-icons').appendTo('#WikiaPageHeader').css({'float':'right', 'margin-top':'4px'});
~Bobogoobo (talk) 22:15, May 3, 2016 (UTC)
I've noticed this too (and it also occurs in the Monobook skin), but didn't mention it since it seemed fairly minor. You're right though; it is a little weird, so I'll add that check. - OneTwoThreeFall (talk) 08:52, May 4, 2016 (UTC)
Thanks for catching that! I modified monobook.css so diff pages should be excepted there as well. — 6×9 (Talk) 15:16, May 4, 2016 (UTC)

ESC category templateEdit

I created a proposal to replace the templates for subcategories of Category:Eurovision Song Contest. Currently, it uses {{EurovisionSongContest}} and {{ESC-Country}}. The replacement is located at User:Bobogoobo/sandbox/Template:ESC-Cat. It combines both purposes into one template, bypasses redirects in the year categories, and categorizes by the subpage name so that they're not all clumped under E. Thoughts? ~Bobogoobo (talk) 04:32, April 19, 2016 (UTC)

Looks good to me! I'd suggest using 150px for both cases (the 100px one is a bit blurry, not sure why I did that), then you could pull most of the code outside the #iferror instead of duplicating it. — 6×9 (Talk) 16:09, April 19, 2016 (UTC)
Sounds good, edited it. ~Bobogoobo (talk) 01:59, April 20, 2016 (UTC)

This is done. ~Bobogoobo (talk) 22:15, May 3, 2016 (UTC)

ft templateEdit

Since featured artists in {{SongHeader}} are no longer automatically linked, it makes sense to do the same for {{ft}}. To not break existing links, it will be replaced by a new template {{feat}}. I'm currently writing a bot script to handle this task. — 6×9 (Talk) 16:25, May 7, 2016 (UTC)

UDPATE: A parameter (t=) has been added to {{feat}} to change the text from "featured" to anything else. This makes additional templates like {{with}} obsolete. — 6×9 (Talk) 11:11, May 8, 2016 (UTC)

Around Wikia's network

Random Wiki