Template talk:Infobox record label

From Wikipedia, the free encyclopedia

Template:Infobox record label is within the scope of WikiProject Music, an attempt to build a comprehensive and detailed guide to music. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.

Contents 1 Make "founded" optional? 2 Code for "defunct"? 3 Add CEO field? 4 need help 5 G-Unit Records WikiProject 6 Divergences on recent changes

Add issues below as you see fit, sign with ~~~~

[edit] Make "founded" optional?

Could we make "founded" (the year of founding) optional? It's causing problems at Credential Recordings. --Metropolitan90 06:41, 4 August 2006 (UTC)

[edit] Code for "defunct"?

Can their be an additional piece of code for "defunct" or "disestablished" for labels that no longer exist? Naufana : talk 21:27, 20 October 2006 (UTC)

I was thinking the same thing. I can do it, the only problem is what would the proper wording be? Disestablished, Discontinued...? I like Discontinued better, but I'm not sure if there's a better word. Joltman 15:37, 13 November 2006 (UTC)

The defunct feature doesn't seem to work. I put in the year 1994 for Twin/Tone Records, but it doesn't appear. Eco84 | Talk 23:21, 7 February 2007 (UTC)

Defunct should now work. Proto ► 19:11, 2 March 2007 (UTC)

[edit] Add CEO field?

i think CEO or owner should be in the infobox. --Peterm1991 21:12, 2 April 2007 (UTC)

Disagree: the information can change too often, and isn't meaningful to most readers. To know that a label currently belongs to Sony-BMG is a relatively stable information, and understood by most readers; to know that a label is currently held by Joe Schmoe is meaningful only to a handful of insiders, and smells more like vanity/self-publicity from CEOs. IMO. — Komusou ^talk @ 19:52, 5 September 2007 (UTC)

[edit] need help

hi, i'm trying to use this template for Napalm Records but its not working. can anyboody help? see my sandbox for what i'm using. thanks. ...Patrick (talk, contributions) 21:48, 7 April 2007 (UTC)

i messed around with it and got it to work. still don't know what i was doing wrong, but its fixed ...Patrick (talk, contributions) 23:08, 7 April 2007 (UTC)

[edit] G-Unit Records WikiProject

I'd like to invite you to join the WikiProject G-Unit Records. We are currently on demand for new members and we believe that the project could benefit from your contributions. Make me sure that you'll think about this and remember cooperative works can do amazing things. Regards

--The-G-Unit-Boss 20:46, 14 August 2007 (UTC)

[edit] Divergences on recent changes

Some disagreements started in edit summaries and continued on my talk page, which I copy-pasted here before answering. — Komusou ^talk @ 17:13, 24 September 2007 (UTC)

Regarding this, having comments inline with the templates example means the user has to select all of the comments one by one and delete them when they are going to use the template on an article. This inconvenience is why none of the other music templates (see for example Template:Infobox Album#Code, Template:Infobox Single#Code, Template:Infobox Song#Code and Template:Infobox musical artist#Code) use such comments. Other than that, it's redundant and confusing to have two sets of instructions, especially when they are subtly different. I also made some other whitespace changes (other than fixing the BR trick, which I assumed was an oversight) to bring this template more in line with the other templates. --PEJL 14:28, 24 September 2007 (UTC)

(Inbetween, I proposed in edit summary the compromise of having both the empty template skeleton for those who prefer to work with ALT+TAB, and the pre-filled template skeleton embedding self-documentation for those who prefer to work this way.) — Komusou ^talk @ 17:13, 24 September 2007 (UTC)

Well we still have the problem of having two sets of subtly different instructions. I also don't think "qualified" and "concise" are appropriate terms to describe the two examples. Both URLs are qualified. --PEJL 16:02, 24 September 2007 (UTC)

(End of copy-paste, new content posted here) A more formal hello than in edit summaries. Still various disagreements, yes, fortunately rather minor and cosmetic I think, matters of taste and/or of explaining the underlying rationales. Let's see what we can tackle already:

• I don't see the two sets of instructions as a real problem: the HTML helper comments are a portable cheat sheet that can't grow on its own (it's already maximized); whereas the Fields section you initiated can evolve and detail at more length how to fill or not to fill the fields, the special cases we'll encounter one by one, the useful solutions that will be found for various problems and that we can accumulate, etc. It's common to have a full manual and a cheat sheet. Also, users have the choice of ignoring one and use the other; the "Fields" heading in the TOC tells them in advance that they have the manual in addition to the cheat sheet.
• About "qualified" and "concise", the two URLs are probably "qualified" in a specialized IT context, as in "a fully qualified URL", but for a largely non-specialist public that seemed to me to be an adequate wording for this case. But that's cosmetic too, what was important in my eyes was to give those two examples, because they both provide different enlightening information to the new user:
  • Way too many infoboxes are filled with full URLs displayed as "http://www.atlanticrecords.com/" when all we need is to display the concise "AtlanticRecords.com" or better "Atlantic Records.com", which is what's usually printed noawadays, or pronounced in an ad. (When you tell a friend about a great new site, you just say "Hiroshige dot org dot uk", nobody says "aitch tee tee pee colon slash slash dubya dubya dubya dot Hiroshige dot org dot uk" any more.)
  • As for the "qualified URL", this was to show what to do in the case of a non-English record label (Turkish here, could have been German or French or whatever) that has an English-speaking sub-site, that's a common problem that many editors will encounter, so we want to proactively propose them a good solution in advance: to link to the homepage of the English sub-site, of course, but we don't want to display the fully qualified "http://www.kalan.com/english/scripts/" so instead we'll pipe it to a "Kalan.com (English)". The display is not fully qualified, but it's qualified enough to tell the reader what's the content of the underlying full URL.
• Anyway, as I said, the important in my eyes was to pkeep those two examples, both common problems and how to solve them. As for which words to describe the two solutions, "concise" and "qualified" seemed OK to me, but then I'm an ESL, so you could just propose something else possibly more genuine, I'm not fighting to keep every last word I wrote.
• I hope we're at least in agreement that we're not at war and just want the doc to be the most useful and informative for the most people, not just one type of editor but several types, such as those preferring the empty skeleton vs. those preferrint the embedded cheat sheet. The rest is about learning why each of us prefer something, see the pros and cons, and to merge or add them, or even get convinced by the other.
• For instance, in the cosmetic department, I completely disagree with your lowercasing all non-prose, HTML stuff. In the times of HTML coding, a lot of webmasters used to write HTML tags in ALL-CAPS precisely because it allowed to visually sort out at a glance what's <I>human prose</I> that'll make it to the screen from what's <CODE>computer stuff</CODE>, so that's the good reason I had for writing the doc page use <PRE> and <BR /> and <CODE> throughout. Of course, I realize that another brand of webmasters preferred their tags lowercase and took everything ALL-CAPS as shouting (too much IRC, my friend, too much IRC), and that's another type of editors that exists today, too. I guess that is *your* reason for lowercasing all tags, but please be aware that there are as much people with an equivally valid reason to prefer uppercase tags. (Plus a lot of lazy people who just prefer to type everything lowercase, even their own I, but I disgress.) Cosmetic but problematic since there's hardly a compromise possible on it, but let's let it slip. Chocolate and vanilla.

— Komusou ^talk @ 17:13, 24 September 2007 (UTC)

I'm sure both of us are trying to make the documentation as good as possible.

• I don't know what alt-tab does on your operating system, would you mind clarifying?
• I'm not sure I accept your claim that a cheat sheet is needed. If there was an overwhelming need for such a format, I would think requests to add such a format to the much more commonly used album/single/song/artist infoboxes would be common. I've never seen such a request. Wouldn't copying from an actual example work almost as well for this type of editor?
• Piping away relevant parts of a URL is problematic. Note that http://example.org/ and http://www.example.org/ are different URLs. Such different variants often go to the same place, but not always. For that reason, I'd prefer this template do what Template:Infobox musical artist does, which is to recommend formatting URLs like [http://www.example.com/ www.example.com]. That makes the URL shorter, while still correct. For URLs which are too long to print like this (for example "http://www.kalan.com/english/scripts/"), I'd recommend shortening it using ellipses, like [http://www.kalan.com/english/scripts/ www.kalan.com/english/...] or similar.
• My reason for lowercasing the HTML tags is not personal preference, it's because lowercased HTML tags are the de-facto standard on Wikipedia and for HTML in general. Only HTML written to very old standards (over ten years old) still use uppercased HTML tags. See also the Wiki markup links below in the insertion box on edit pages.
• Sorry, I don't understand why the indentation is needed, even after looking at the sandbox. I was trying to make this template consistent with the other music infoboxes (album/single/song/artist).

--PEJL 18:05, 24 September 2007 (UTC)

Very quickly for now:

• ALT+TAB switches display/focus between the two windows last used or last selected, allowing you to work on one document, then ALT+TAB to switch display to some manual page and check something, then ALT+TAB back to the work document, and so on.
• There is now wiki guideline/policy mandating to lowercase (or uppercase) tags, it's a matter of personal preference (or lack thereof). Another point is that HTML tags are case-insensitive and there is thus no benefit to Wikipedia to spend time changing their case if one doesn't have a personal preference. Please note that you may be confusing HTML with XHTML, the later mandating lowercase tags; Wikipedia try to accomodate the large parts common to HTML and XHTML, but both Wikipedia and web browsers use HTML. Wiki prescribe very little and especially not things invisible to the reader; you can check the MoS or ask the WP:Help Desk.

I'll comment in earnest tomorrow; today my edits belong to Wodehouse ;-) Cheers. — Komusou ^talk @ 11:17, 25 September 2007 (UTC)

• Oooh, I remember browsing using multiple windows, back in the nineties, back when people were still using uppercased HTML tags and writing web pages using presentational markup... ;-)
• I'm not confusing HTML and XHTML, I'm just using "HTML" in a broad sense to mean the (X)HTML. As you noted XHTML tag names are case-sensitive, and all recent (X)HTML standards are XHTML standards. How web browsers treat (X)HTML is irrelevant, as the output is pre-processed by the Mediawiki software. Mediawiki outputs XHTML, which is also irrelevant for that reason. The benefit from changing from uppercase to lowercase that you seem to overlook is standardization, as lowercased tag names are the de-facto standard on Wikipedia and elsewhere. --PEJL 15:49, 25 September 2007 (UTC)

Back in the saddle:

• Re: ALT+TAB, the same feature is commonly used in tabbed browsing as well, except it becomes CTRL+TAB or similar. And except that if you need to switch between a separate PDF/Word/etc. documentation and a browser page then you'll still have to use ALT+TAB. "ALT+TAB" remains a common name for referring to this way of working, whatever the actual key combination of your software is.
• Anyway for the cheat sheet, it's extremely common in IT to have skeleton config files lousy with self-doc comments about what to put in each section to enable/disable something, so that one doesn't have to refer to another doc/manual for each point. And GUI config interfaces emulate this with plenty of tooltips and/or the magic "?" icon to locally query what each widget is for, without opening any separate help file.
• Also, "copying from an actual example" is a just not worth it, I know it, I used to do it. Just creates errors because you always forget to update or change one field, and some irrelevant info stays there for ages. I've seen it dozens of times on album pages, people have been just copy-pasting the infobox from another album to make their own, often with major errors that just keep spreading and accumulating like a virus, via copy-paste. The pre-filled skeleton is actually used by many people, but we usually keep our cheat sheets to ourselves, in a document file, and not bother to share. There is also often that "I've paid my dues to understand how this infobox worked, I don't share my results, the others can pay their dues too..." mentality, which is why so many template don't have any decent documentation: each editor come, have to figure out for himself how it works in special cases, and then don't bother to write the doc that he missed once it won't be useful any more to him. Did you notice that this template doc didn't have any doc at all (except for four "fields") before I worked on it some days ago? I won't believe that until a few days ago nobody knew how to use all fields of this infobox, but nobody bothered to share once they had had to figure it out. Lots of wasted time, if the first editor that came and found no doc shared his experience to write the doc, the dozens of editors that followed wouldn't have had to do it again from scratch (and not share either thereafter). Anyway, if you could write so quickly the "Fields" section, that's because you found the cheat sheet I had just added to the page, so this means the cheat sheet isn't so useless or unreadable after all, it is actually useful to so as to remind quickly what each field is for and the form each argument takes. And it also allows to benefit from it in situ, after copy-pasting it with the skeleton to the record label article you want to infobox.
• So, you mean you used "HTML" in a broad sense, like I used "ALT+TAB" in a broad sense? Heh. — Anyway, there is no "de facto standard" for tag case, Wikipedia does not prescribe that sort of things (that's both divisive and useless for the encyclopedia) and actually refuses to do so, just like for endash/emdash, US/UK English, and so on. Please go ask to the Help Desk if it's needed or useful or good database-wise that you go and change all tags to lowercase, for no actual benefit whatsoever to the reader, and against the wish of a local editor, especially when you state you don't even have a personal problem with it. And sorry, but you confuse useful standardization and useless uniformization. Standardization is having light bulbs have the same screw base, and that's useful. Uniformization is demanding that all light bulbs all have the same pear-shaped bulb and eradicate mushroom-shaped or square-shaped bulbs, that's unnecessary and divisive. There is no benefit to Wikipedia to uniformize the source code of a doc page to lowercase tags, and it actually works against Wikipedia and its rules to do so: you say don't have a preference for source with lowercase tags, and I say that I work better with uppercase tags source because it makes it easier to parse the source and see what's output prose and what's invisible markup. Not to mention that we're deeply into WP:LAME territory, and that no reader will ever see any benefit from this.
• As for the URLs, there is no guidelines or standard on it. Actually, a lot of infoboxes have opted to hide the URL entirely by forcing the link's label to be "Official website" or "[infobox title]" (see for instance Lyceum Theatre, London). At least we're in the same team for wanting the domain name to be displayed, somehow. As for the details, I have to disagree again. For one thing, we don't have to show the full URL, people don't care, they just want (at best) to know to which domain name they'll be sent to. For another, most of our links or external links never display the URL or the domain at all, it's only a caption or icon or a sentence instead, so that seems hardly a problem, we're actually giving more with displaying some part of the domain than most other links.
  • Specifically, for the "www." part: I known how "Example.org" could theoretically be different from "www.Example.org" in the DNS, but that's totally theoretical for our purpose. In practice, DNS admins make damn sure that the address of the raw domain and the www. host are the same or both send to the website, precisely because it's very common for people to just type Example.org – besides, advertizing, both in print and audio, encourages it by skipping the dubya-dubya-dubya part entirely. So that's no a real world issue, and if you want "de facto standards", that's a clear one – but this one makes a difference, because it allows people to connect to the website they wanted, whether they type the www bit or not. Most people will just CLICK the link, anyway, and if there is someone who actually want to type the domain name we gave him (such as, reading from a printout, or from memory) then it's 99.99% guaranteed that it'll work without the www bit. (If not, the netadmin should be fired.)
  • And for the link with qualifier: an ellipsis idn't a solution, some sites have pretty long and meaningless URLs when you want to link directly to the English-speaking part; it's just a lucky case that "www.kalan.com/english/..." has the word "English" at all and as the first folder, most site would be more like "www.example.com/cgi-bin/subsites/display?file=index&lang=3" and you couldn't ellipse anything meaningful from it. And readers don't care about such underlying details, for an infobox summary, all the info that's needed is the domain name, and possibly a qualifier when we actually send to a subsite. "Kalan.com (English)" is all the info a normal reader would want to have, and the minority who'd want more, they also know how to hover the mouse on the link and read the full URL in the status line, so I see it as a non-issue to caption the URL as "Kalan.com (English)". Each category of user can have his info in a nice manner.

— Komusou ^talk @ 06:45, 27 September 2007 (UTC)

• Alt-tab: Well there are different ways of interacting with windows and tabs. I honestly had no idea what "for those who prefer to work with ALT+TAB" was supposed to mean.
• Of course a de facto standard isn't prescribed, if it was, it wouldn't be a de facto standard.
• I have personal experience with numerous examples of domains which point www.example.org and example.org to different places, or just point one of them. So it's not just a theoretical problem, it's a real one.
• The ellipsis could go anywhere, for example "www.kalan.com/..." if the width was further constrained. The idea being to show the leftmost part of a URL (minus the "http://" part). Note that this is what would happen if we used the a CSS text-overflow: ellipsis; rule (which we can't rely on because of limited browser support). Your cgi-bin example could be shown as "www.example.com/..." I fail to see how a mangled URL like Foo Records.com is better than www.foorecords.com, if the latter is the actual host name.
• I inserted a bunch of <code>...</code> (using the convenient links below the edit field, which as I've noted before output lowercase tag names). That resulted in inconsistent formatting (some lowercase, some uppercase). To make this consistent we either had to change the existing uppercase tags to lowercase or vice versa. In such a situation I would argue that (lacking any other criteria) we should change the formatting to lowercase, as that is the de facto standard (as evidenced for example by the insertion links). Are you arguing that we should have changed it to uppercase because that's what you prefer? Or are you arguing that we should have left it inconsistent?
• Oh, you mean that the "(English)" part is the qualifier. I finally see what you mean by that. Hmm, if such qualifiers are to be included maybe we should be using {{En icon}} (which outputs "(English)"), possibly after the link rather than inside it. Are these qualifiers only meant to be used for languages or for other info as well? --PEJL 10:42, 27 September 2007 (UTC)
• Also, and you still haven't explained why indentation before the first pipe character on each line is useful. Like I've said before, I'd like to make this documentation consistent with all the other music infoboxes, which don't use such indentation. As it stands, the documentation is also internally inconsistent, which is inappropriate. --PEJL 10:47, 27 September 2007 (UTC)

Hi again. It's an answer to your previous post, but I'm outdenting to relieve a bit the marginal pressure.

• For removing "www" on the label and bad DNS zones: IMO, a few freak cases, such as a few currently badly configured domains, shouldn't prevent us from offering a concise "Example.org" as the rule of thumb. (Just like the fact that a few people are in wheelchair shouldn't prevent us from having stairs in buildings.) Furthermore, the underlying URLs remain complete and with www, so the possibility of a reader that would (1) not click but type, (2) sheepily type "Example.org" without the leading www. (3) perform this just on the maybe 0.001% websites with a bad DNS setup – what are the odds of all three things happening simultaneously, 0.000001% of readers? IMO that doesn't justify depriving ourselves of the concise domain name, that's becoming prevalent now.
• For <CODE> vs. <code>: but there is absolutely no requirement of "consistency" for source code, such as writing all tags the same way. Wikipedia requires only consistency for what's visible to the reader, such as "either you use only endashes as prose separator, or only emdashes, but not both randomly". For the rest, it's a live and let live thing, especially if you don't have any vested interest into the lowercase tags.
• Writing "FooRecords.com" or "Foo Records.com" is a matter of taste, but the later makes it easier to understand and remember (if needed) the domain name, or to realize if that's a website you already know or not – and it follows the way you say it to a friend or the way you hear it in an ad.
• Yes, that's the qualifier, just like "John Smith (UK actor)" is a qualified link. The {{En icon}} is a good idea. Per se, we're supposed never to use it on the English Wikipedia, so just to be on the safe side we'd better ask them if this is a good case for bypassing the general rule, or if its usage is deprecated even in our instance. (I mean, lest our articles would eventually get visited by some bot automatically removing it from everywhere, if they're not aware of a justified usage here.) My only concern is that it's called "icon" and we don't know if they're going to add an actual icon to it in some future. (I mean, a link to a Turkish website that would get a U.S. or UK flag icon would be silly, and prolly offensive to some readers). So it'd be best to ask them about that too.
• About the indentation thing, if the source code I pointed you at didn't visually explain it all, then it'll take some time explaining properly here, that I don't have just right now. Another time.
• Instead, some more points about the self-documented template samples:
  • I forgot to mention another dramatically useful case, not limited to record label articles: when you find an article that's missing the relevant infobox (usually because the authors don't even know there's a dedicated infobox for it), one of the simplest things you can do is to just copy-paste the self-documented template, quickly fill in a few fields that you can easily do just glancing at the article, and then you just let the rest in place for the authors to complete. I just did it as on this diff: I filled what was obvious, and I let those who know the topic much better than me complete the rest, with the vestigial self-comments telling them what to do to finish it, and how. Much better IMO than just leaving them a blank template and assume they'll come to the template doc here to find out the exact/best syntax for the rest.
  • Actually, do you realize how many layman editors have no idea how to easily reach the page for a template if you don't give them a link to click at? I bet you and I just craft the URL because we know how it works, but for most people it isn't so easy, that's why so many boxes have the tiny "v-d-e" links. So I mean that only a fraction of editors will even reach the template's full documentation, and that leaving a self-doc in place really is useful.
  • So I think this makes a good second argument in favor of making self-documented samples available. Another thing, maybe, is to point out that personally *I* don't need the self-doc be given out on the doc page. I mean, I could just selfishly keep it in my big Wikipedia.txt bag of tricks, like I used to do, so I have nothing to gain personally whether it's available to others or not on the doc page, it's not a feature of the template itself or a point in an article. But I really believe it's useful for everybody or many other editors if that's made available to all. — Komusou ^talk @ 19:36, 2 October 2007 (UTC)

• Stairs analogy: The analogy is severely flawed. A better analogy might be that we should not include a railing in the staircase because it's not needed in most cases.
• Uppercase tags: So what you are saying is that we should have left the article with half uppercase tags and half lowercase tags? Or are you arguing that I should not have been allowed to use the inserting links on this article because there previously existed uppercase tags in the article? Or that I should have had to manually convert the tags inserted by the insertion links to uppercase?
• URL formatting: Consider alternate modes of interacting with articles, for example printing, and that munging the URL makes it look less like a URL and more like a possibly incorrect trademark. What exactly does munging the URL buy us?
• Indentation: As I've mentioned before, the other music infoboxes seem to do just fine without indentation. As you continually fail to explain why indentation is needed in this case, I'm going to remove it, to at least make the documentation internally consistent.

--PEJL 20:04, 2 October 2007 (UTC)