2,054,106 Pages

Replacement filing cabinet This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current LyricWiki talk page.
LyricWiki talk archive for Community Portal
<< November - December 2007 January 2008 1st February - 16th April 2008 >>

AOTW nominations

Is it possible to nominate compilation albums? I've read the nomination guidelines, and while there's nothing in there that says you can, there's also nothing that says you can't. Thanks. - Cubs Fan2007 04:02, 5 January 2008 (EST)

Please do so! Unless it is specifically forbidden, or required, we are very liberal about what can be done here.
- teknomunk (talk,E,) 04:19, 5 January 2008 (EST)
Great, thanks. It's just I did, but them someone removed it, which kind of irked me. - Cubs Fan2007 12:02, 5 January 2008 (EST)

Should Non-English Translations be kept?

Hi. The hard-working ÜberBot has collected some non-English translations of Rammstein songs. See e.g. the Norwegian, Portuguese, Spanish, or the Swedish version of Rammstein:Sonne. I’m tempted to just delete them because

  1. I can’t check them for correctness or even fix their accents
  2. I don’t think it makes sense to keep translations in one language (like Swedish) for only very few songs
  3. it would be hopeless to try to collect translations in many languages generally
  4. they were not created by our users

On the other hand, you could say that we should keep the stuff that we already have. So what do you think? Dump them, keep them, or should those editing on the Rammstein pages discuss under themselves? --Hfs·· 10:16, 5 January 2008 (EST)

I think it's quite senseless to have translations into languages other than english. I think everyone here speaks english so those aren't really needed and it's very hard to translate lyrics so everyone should work on just one translation (english) to improve that one instead of having dozens of translated lyrics which are mostly translations from the english translations and therefore even more incorrect than the english one. --MetalSnake 10:50, 5 January 2008 (EST)
I would have to disagree with MetalSnake on this one in that I think that translations into any language should be accepted. However, HS.4 may be reason enough to delete them.
HS.1 will not be a problem as we get more users here, a wider variety of languages will come, so I don't really see that as a problem. When I first came here, the Japanese songs here were a joke, but not any more.
And about HS.3, we are trying to collect the lyrics for every song ever created, doesn't that seem a little hopeless to you? And yet we are trying anyway.
I think we need a few more opinions before any policy is decided on this one, so those people who are watching this page, what do you think?
- teknomunk (talk,E,) 14:58, 5 January 2008 (EST)
I would have to agree with teknomunk, just because almost all of the users right now are English speaking, we are striving to be a more universal site. These translations are just as helpful as English translations for non-English songs. That being said, I think we need to either find official translations or at least note the ones that are unofficial as such. I think that if we delete non-English translations of songs, we might as well delete non-English songs altogether, its the same concept. That's just my two cents, take it for what it's worth. --WillMak050389 15:09, 5 January 2008 (EST)
In my opinion, lyrics should be kept in the language they are sung in. So German lyrics in German, English lyrics in English, etc. Of course, there may be cases where songs are actually released in multiple languages, then it is certainly justified to have the lyrics in that language as well. The only exception to not having translations would be to have an English translation as secondary translation on the page, just because this site was originally in English, most users speak English and English is one of the most widely used languages on the web -- therefore having an English translation will make the meaning of the lyrics more accessible to people who are unable to read the original ones. But instead of collecting lyrics in all different translations in which the song is not even available, I'd rather focus our attentions on cleaning up the thousands of pages that still need attention, as well as improving the site (layout, copyrights, etc) and keeping the lyric database up to date (so many songs have to be released each day, and a lot of them appear here fairly quickly already). Just my 2 cents... --Mischko Talkicon EsperanzaIcon 10:03, 7 January 2008 (EST)
I'm with Mischko. Lyrics are every bit as significant to a song as the music, and so much gets lost in translation. (Those of us that were lucky enough—no pun intended—to hear "Suerte" first can't stand to hear that horrible "Whenever, Wherever". Those beautiful Spanish lyrics are what make the song shine.)
As Mischko said, an exception should be made when the song is actually released in more than one language, such as the aforementioned "Suerte". However—while I agree that this is an English site, and caters primarily to English-speaking people, I don't necessarily think that translations should be provided for every foreign song, be it for us English people or any other language. As I said, part of the artform of a song is the lyrics, I find translating a song into a second language (when the artist has chosen not to themselves) to be a bit insulting to the artist's work. It would be like repainting the Mona Lisa because you're not familiar with the clothing she's wearing...
About the only "but" I would throw in would be for songs in non-Arabic alphabets. I'm on the fence on that one, since anything in Japanese is going to be a bunch of ??????????? to anyone without the proper kanji or other typefaces installed. Without those typefaces (and some knowledge in reading those characters), no doubt we are missing out on some masterpieces. That might be worthwhile for an accurate translation, but that's about the only good reason I could personally name.
—  jF 23:10, 7 January 2008 (EST)
I full well know that a lot is lost in translation (I am responsible for a few of the translations of Japanese songs here), but I like translations as a tool to understand the original song (and the language) rather than it being an insult to the artist. It was a major factor in me studying Japanese and I would like to be able to help other do the same.
I know we have thousands of pages that need more work, so we should not go out of our way to encourage translations into additional languages beyond English, but we should also not go out of our way to censor (delete) the translations that already exist.
- teknomunk (talk,E,) 02:43, 8 January 2008 (EST)
Everyone out there has great ideas about this, but may I ask why not add a sub-section "Translations" under the "Other Songs" section? Since the bots find songs and automatically put new songs in the "Other Songs" and we've kinda discussed the fact that we shouldn't promote translation production, but be shouldn't delete them, why not put them in a separate sub-section? Then, they would be out of the way of released artist songs and if a user wants to look at them, they could.
I wouldn't think it would be a difficult task to do and would probably solve many problems addressed. HS.1 would have a (accent) template on the page so someone who does know the language would fix it. HS.2 separates the translation from the actual released song (which most users tend to want to do anyway). HS.3 addresses a place where translations would be welcome if needed and lastly, HS.4 if they were not created by our users and are found in the "Other songs", they could either be deleted or moved to the new sub-section.
Also, If we come across a page that has a translation embedded in it, we can split it of into it's own page and add the page into the new section.
What do you all think about this possibility?
Lyricserver 21:26, 10 January 2008 (EST)
I would suggest the other way, that the translations be embedded into the original page, and have one page per song released by an artist. That way you don't have to run around to try and find if a translation exists or not, you can see it in the TOC. And it also keeps the artist page from getting cluttered. Having a section for "translations" and pulling them out of the articles would likely double the length of certain artist pages (for example Ali Project, one of the more popular Japanese artist pages here).
- teknomunk (talk,E,) 00:21, 11 January 2008 (EST)
That might not be so bad, Teknomunk, but how about our notably underused subpage capabilities? I'm envisioning (just for ideas here) a template at the top (like {{translation|German}} or {{translation|French}}) that would create text at the top that says something like "These lyrics also available in German." That could reference a subpage from the article itself to provide the lyrics. It wouldn't be "embedded" in the page as you suggested, but it would seem a logical place to put variations of the same page to me.
For a song called [[Artist:Sample Song]], you would have a page called [[Artist:Sample Song/German]] or [[Artist:Sample Song/French]]. I can see some potential confusion over the page, however—do you use "German" or "Deutsche"? (And my possibly solution for that: if it's called from an English page, use the English name for the other language. If a Chinese translation called from a French page, it would be [[Artist:Sample Song/Chinois]], and so on.)
Here the Wikipedia reference on subpages. Whatcha think—workable idea or not?
—  jF 03:01, 11 January 2008 (EST)
Subpages are already used for songs that were released in several languages by the artist as described on Help:Multiple Languages. See e.g. Rammstein:Du Hast for a song that has both a very literal translation and a more meaningful “official” translation. I like the current line-by-line formatting of the English translations, because it allows you to sing (or read) along to the lyrics and glance at the meaning at the same time. --Hfs·· 17:50, 14 January 2008 (EST)
Now how on earth did I miss that? Looks like someone already had the same good idea.  ;-)
One possible problem with the side-by-side translation, though. Different resolutions are going to freak things out a bit. You might wind up with lines wrapping and throwing off the line-by-line format. And I notice the side-by-side lyric blocks don't always line up vertically depending on resolution.
What would be the solution for situations where the song has been released in more than one language (or more than one translation is available)? How do you decide which appears on the page with the original lyrics? (I can see English getting priority, since LyricWiki caters to a primarily English-speaking audience, but what if English isn't even one of the available translations?)
—  jF 01:46, 15 January 2008 (EST)

Capitalization for displayed titles

I am copying a discussion from my talk page. We need to discuss this.

When doing AotW yesterday, I edited K.d. Lang:Ingénue (1992) and changed the display names for some song titles by making some prepositions and articles (a, an, the) lowercase. Now, the naming convention for article names is to capitalize each word (LyricWiki:Page Names), but there is no precedent for the displayed titles. --WillMak050389 15:16, 7 January 2008 (EST)

On this week's Album Of The Week, I noticed you corrected the displayed titles to put prepositions in lowercase. Is there a Wikipedia rule involved here, or is that done for the sake of appearance only?
The album gives the tracklist in all capitals, so it's useless as a reference. I've never been one to agree with that old English rule of "lowercase any unimportant words" that typically applies to prepositions in titles, and find the initial capitalization policy of LyricWiki quite agreeable for both article names and displayed titles. (Where no clear conflict exists, of course—with k.d. lang, the rules are all but thrown out the window.)  ;-)
I'd personally argue for keeping initial capitalization for everything, at least until that fabled mod can be applied to enable proper case. New users (and even us not-so-new users) have enough trouble keeping up with LyricWiki standards, and it can be confusing to know that the rule for article names might not necessarily apply for displayed titles.
Since LW:PN doesn't specifically mention displayed titles, I'd like to see some discussion on that point. (As it reads now, the rule applies to article names only.) Perhaps a consensus could be made part of the policy. I'd be comfortable either way, but I would like to see it clarified and standardized for the benefit of us anal types who are striving for perfection.  ;-)
What do you think?
—  jF 02:03, 7 January 2008 (EST)
I would think that the display title should be as close to what appears on the album as possible.
And about that plugin, I ran into a problem with resetting the cache of a page. If you or anyone else knows how to do that or would like to work on it, please let me know.
- teknomunk (talk,E,) 02:50, 7 January 2008 (EST)
Personally, the way I have learned that titles for anything, in English, is that prepositions and articles (a, an, the) are to be lowercase unless it is the initial word. I use this rule when displaying the title, but of course, when creating a page it should be all caps for initial characters. I use the lowercase rule, unless of course the band's naming goes against this. (A similar problem occurs between whether to use "and" or "&"). I think this should be discussed, though. So I will post this discussion at the Community Portal. --WillMak050389 15:09, 7 January 2008 (EST)
Actually, I've been doing a little bit of both. When I edited the Moenia pages (TechnoPop group in Spanish), I took to heart LW:PN, however in other Spanish pages I came across, I kept some of the title display properties
(Note: in Spanish, titles are always lowercase except for the first letter of the initial word and any Proper Nouns (ex. La emancipación de Mimi, a translation for Mariah Carey's The Emancipation of Mimi. )
Lyricserver 21:42, 10 January 2008 (EST)

Reserved characters

Since WillMak050389 mentioned this in a comment above, would anyone like to compile a list of reserved characters for LyricWiki? It should also include any characters that aren't necessarily reserved, but might interfere with LW operations. If someone a bit more knowledgeable with MediaWiki can provide that information, I'll be glad to work on turning it into a replacement list in the Help (along the lines of "+ should be replaced with Plus", "& replaced with And", etcetera). We already have some basic rules for that in LyricWiki:Page Names, but a concise list might be a useful reference.

—  jF 22:17, 11 January 2008 (EST)

Stylized Typography?

I noticed in the Page name policy it mentions nothing about artists, albums and songs which might have a stylized name, eg. a name where a symbol takes the place of a letter. For example the artist P!nk has an exclamation mark in place of the "i" however LyricWiki has her at Pink. KoЯn is the same, redirecting to KoRn. At wikipedia they have a policy against it however this being a music wiki I'd assume this wouldn't apply here being the policy seems to simply state that the first letter for each word in a page title must be capitalized and the symbols: + # and < be replaced with words however these are all for technically reasons and with the capitalization for consistency as well, however as far as I can tell the stylized names like P!nk and KoЯn don't seem to have technical problems. Also it seems that MusicBrainz considers P!nk to be the correct name, also it seems that a Japanese band and a video game music composer go by the name Pink so simply having a redirect to P!nk wouldn't be the best so if stylized names should be used here then a note should be left at the top of Pink directing to Pink should be done instead. So does anyone have anything to say on this issue? The Light6 07:37, 15 January 2008 (EST)

I would say to ignore it in favor of a reasonable approximation. While something like the famous reversed B in ABBA (which isn't in the Unicode character set) isn't too hard to handle, you run into the problem of dealing with artists that throw all kinds of ridiculous things into their work. Consider Prince's dalliance with that unpronounceable symbol in the 1990's, and you see what I mean.
As a general rule, I would suggest limiting things to strict alphanumeric characters (in other words, the letters of the standard alphabet for the artist's native language—including the appropriate diacritical marks—and the numbers 0 through 9). Going by the established pronunciation might help as well. I mentioned reserved characters in this post, and alphanumerics are inherently safe for use in URL's and article names. Using any other characters (including those that may not be specifically reserved by operating systems or HTTP) could lead to troubles down the road. (Just ask Sean about API's and SOAP and such—I bet you get a rather exasperated response.)  ;-)
Wikipedia's policy is wise. Our own LW:PN might not specifically mention it, but the rationale behind both policies is the same: to provide accuracy and consistency in naming while avoiding anything that might throw a monkey wrench into the works later. As Wikipedia said, a simple redirect from those bizarre typographical treatments to a more standard spelling is a good idea.
Parting comment on MusicBrainz—I note that the majority of the data they collect is from what people are tagging their MP3's with (via their tagger applications). That doesn't make them the most reliable resource of information, and I'd certainly put more faith in Wikipedia's judgement (and the intense scrutiny from their monstrous user base) than MusicBrainz.
—  jF 01:06, 16 January 2008 (EST)
With ABBA, isn't the reversed B a logo design issue, rather than an official part of the band's name? Same, basically with Korn/KoRn. (Wikipedia uses "Korn", but we use "KoRn", primarily, I believe because their website uses the capitalized forward R.) Logo designs aren't necessarily 100% official and sometimes use artistic license with regards to the artist's name. The same thing goes for Pink's name, which Wikipedia notes as sometimes being "stylized" as P!nk. Some artists purposely have symbolic or typographically unusual names, which, like t.A.T.u., should be followed, but this should be distinguished from creatively altered logos, I think.    Kiefer    talk    contribs    admin   02:57, 16 January 2008 (EST)
@ jF: About "other characters (including those that may not be specifically reserved by operating systems or HTTP) could lead to troubles down the road", I'm not sure about the bit about operating systems however for HTTP yes it could cause trouble with external sites trying to link in (at least with BBCode) and links from here out (eg, with the song footer template, for example I know an ampersand (&) breaks links to however Non-English artists sometimes have to use characters which are not alphanumeric and any time you go to such a page (without typing or copy and pasting the correct name) it will change the symbols to what I believe is Unicode equivalent.
@ Kiefer: So the policy is basically unless proven that a stylised name is the real/correct name the artist goes by the stylised name is basically just a logo and the non-stylised name should be used?
The Light6 07:34, 16 January 2008 (EST)
Yes, the reversed B is nothing more than artistic license. And as with my beloved Prince, you have to find a balance between what the artist's desires and the rules that make life easier for us here. And that could prove tricky. With KoRn, I would think applying our normal capitalization rules would be appropriate. (And side note—they pay an unexpected homage to ABBA by reversing the R in their band logo. Never noticed that...)
Assume you have a band named CoRe, and the artist chose to capitalize the name as such because it is a portmonteau of the names of two members, Coleman and Redding. I would find justification to capitalize it in that manner given that scenario, since it reflects an origin from two proper names (which would be capitalized themselves). Under that premise, I find that full capitalization of ABBA would be correct, since it's an acronym of the four members' names. However, with KoRn, there is no indication (at least not as far as I've found) that it is anything but a made-up name, assumedly from mispelling the word "corn" and reversing the third letter. Knowing the history of the name in question helps, but I think it ultimately falls down to individual circumstances.
A good contrast is k.d. lang, who is famous for lowercasing her name as a tribute to her favorite poet, e.e. cummings. She has universally applied this treatment to her name since the start of her career, and given the uniformity in her extensive catalog, I would choose to honor that. (I should point out that Wikipedia disagrees with me, and has chosen not to honor it.) But what about Pink? While her releases seem to be fairly consistent on using the exclamation point instead of the I, note the biography page on her official site, which uses both forms. Where the artist uses a regular spelling and a stylized spelling, I would go for using a regular spelling every time.
But again, it is probably impossible to set a universal rule for such. As Kiefer said, some artists purposely break those rules (and sometimes with good reason), and figuring out which artists are doing it for a valid reason and which are doing it just for publicity or image can be tough. Each situation has to be looked at on its own individual merit, I would think.
(Another good artist for discussion purposes is Mike & The Mechanics, who apparently have chosen to abandon the "calculator" logo they used on their first albums. We might see P!nk do that someday...)
Concerning those "not necessarily reserved" characters, I should reiterate my comment about the "artist's native language". We can't complain about Japanese kanji being used, nor should we have issues with words like "Français" and "jalapeño". Such characters are letters, after all, and are being addressed by the Unicode standard. What I'm talking about is using characters that aren't alphanumeric, like ♫ or ∑. We should avoid those, as well as mixing code pages (like trying to create something like KoЯn). They may not map to letters or numbers in different code pages, causing chaos for users in other parts of the world.
And while much lesser of an issue, it also could make our wiki data worthless for other uses. (For example, if Sean ever decided to export our wiki to files, he'd have to name countless files by hand or pick his operating system of choice carefully. The quotation mark, question mark, and asterisk are all reserved characters under NTFS, but none of those are reserved under HFS.)
—  jF 02:10, 17 January 2008 (EST)


I was wondering if there was some edit that would show that the song you're looking at is a B-side. Such as, when I click on a song, at the top it says:

{{Song|Album Title (Year)|Band Name.}}

But if the song is a B-side and isn't on a album, I was wondering if you could have something like this:

This song is a B-side and appears on the single "Song Name (Year)" by Band Name.

Just wondering. Thanks.

— The preceding unsigned comment was added by KirbyMaster14 (talkcontribs).

You can always recreate the results of the Song template by hand for the relevant article, much as I've been doing with a lot of k.d. lang stuff. (Take a look at the source code for "Constant Craving" to see what I did.)
B-side is a bit of a misnomer these days. While the B side was once used for songs that weren't expected to become hits (or to provide a place for album outtakes), modern artists instead tend to add mixes of the particular song. Most B-sides actually do appear on a work elsewhere, and with the extinction of vinyl media, a true B side for singles no longer exists. I'd suggest instead putting a comment that specifically addresses their absence on another work. Perhaps:
This song was released as a single by Band Name.
This would also serve songs that were released on CD singles as the only track and don't appear elsewhere.
—  jF 23:10, 30 January 2008 (EST)

(Pagesize = 29,187)

Community content is available under Copyright unless otherwise noted.