Template talk:Imbox/Archive 3

From Wikipedia, the free encyclopedia

This 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 talk page.

1 Deploying on non-free licence tags
2 Colour code deprecated
3 Mbox differences
4 Metadata class

Deploying on non-free licence tags

So far, I haven't seen a full discussion on deploying this on non-free licence tags. The problem is that there is a large amount of legalese on these tags, so when I try to put this on one of the long ones like Template:Non-free promotional, it is going to look like this (keeping the font size at 85%):

This is a copyrighted image that has been released by a company or organization to promote their work or product in the media, such as advertising material or a promotional photo in a press kit.

The copyright for it is most likely owned by the company who created the promotional item or the artist who produced the item in question; you must provide evidence of such ownership. Lack of such evidence is grounds for deletion.

It is believed that the use of some images of promotional material to illustrate:

the person(s), product, event, or subject in question
where the image is unrepeatable, i.e. a free image could not be created to replace it
on the English-language Wikipedia, hosted on servers in the United States by the non-profit Wikimedia Foundation,

qualifies as fair use under United States copyright law. Any other usage of this image, on Wikipedia or elsewhere, might be copyright infringement. See Wikipedia:Non-free content and Wikipedia:Publicity photos.

Additionally, the copyright holder may have granted permission for use in works such as Wikipedia. However, if they have, this permission likely does not fall under a free license.

To the uploader: This tag should only be used for images of a person, product, or event that is known to have come from a press kit or similar source, for the purpose of reuse by the media. Please add a detailed fair use rationale as described on Wikipedia:Non-free use rationale guideline, as well as the source of the image and copyright information. Additionally, if the copyright holder has granted permission, please provide further details as to the terms.

I would prefer that the Image:red copyright.svg image remain vertically justified at the top instead in the middle. Any other thoughts? Zzyzx11 (Talk) 16:09, 11 May 2008 (UTC)

I very much disagree: having images top vertically-aligned is something that has always irritated me wherever I find them. It's just a personal preference, but I much prefer the appearance of the box with the image centrally aligned - it makes the template look more balanced (and more professional: for some reason whenever I see a top-aligned image I instinctively assume it wasn't coded properly :D). Just my £0.02. Happy‑melon 17:04, 11 May 2008 (UTC)

I agree with Happy-melon that the central alignment looks much better. —David Levy 17:09, 11 May 2008 (UTC)

I agree that in general the central alignment is better, but in templates where there is a lot of boilerplate text, it probably would look better to change the layout somewhat. My inner designer says that perhaps we can find some tricks to allow the images to be center-aligned with respect to the first paragraph or so; such a solution would probably look better, in my humble opinion, while providing many of the advantages inherent in the standard layout. This might be achieved by adding an extra parameter to the template, say "{{{boilerplate}}}", that would add an extra table cell to the template, below the others, for the massive amounts of boilerplate text our image templates ~~sometimes~~ all too often use. Nihiltres^{t.l} 19:02, 11 May 2008 (UTC)

feature creep, in my opinion. KISS principle also applies. Since it essentially comes down to a personal preference, I can't see the point in bulking up the codebase of every page using these templates to fix such a trivial detail (assuming, of course, that one considers it currently 'broken' :D). Once we've loaded the styles into Common.css, of course, editors can override it with their own .css to top-align the images if they so wish. Happy‑melon 19:19, 11 May 2008 (UTC)

I agree with Happy-melon and David Levy, central alignment looks better. But from a technical point of view: I would really dislike to add more table cells and other such complex solutions. Instead we already have the "style" and "textstyle" parameters to handle other similar requests. So the simple way would be to add "imagestyle" and "imagerightstyle" parameters. And then you could set "imagestyle = vertical-align: top;". But I think even that would be function bloat. Instead, as I said before, if you need special functionality you should build those boxes with a table yourself and hard code the styles. When the CSS classes are available it will be pretty simple to build such boxes. By the way, I just tried, it doesn't work to set "style = vertical-align: top;".

--David Göthberg (talk) 20:43, 11 May 2008 (UTC)

I also feel that it is better in the centre; if it were at the top there would be too much white space below it. Waltham, The Duke of 03:32, 12 May 2008 (UTC)

David, you'd need to use !important to override the current inline styling, and it would only apply if that parameter affected the image cell (which currently has no css class or style parameter). Either that or you'd need some fancy CSS using table.imbox tr:first-child or something which doesn't apply right now. Waltham, the white space below the image can be solved using my alternate method with a separate table cell. For example, see my quick and dirty example, below, of the above template with my suggestion added. (if it's horribly broken, sorry, didn't bother checking code carefully, just hacked at it to make it look OK in Safari) Nihiltres^{t.l} 01:38, 13 May 2008 (UTC)

It is believed that the use of some images of promotional material to illustrate:

the person(s), product, event, or subject in question
where the image is unrepeatable, i.e. a free image could not be created to replace it
on the English-language Wikipedia, hosted on servers in the United States by the non-profit Wikimedia Foundation,

Additionally, the copyright holder may have granted permission for use in works such as Wikipedia. However, if they have, this permission likely does not fall under a free license.

Please note that our policy usually considers fair use images of living people that merely show what they look like to be replaceable by free-licensed images and unsuitable for the project. If this is not the case for this image, a rationale should be provided proving that the image provides information beyond simple identification or showing that this image is difficult to replace by a free-licensed equivalent. Commercial third-party reusers of this image should consider whether their use is in violation of the subject's publicity rights.
To the uploader: This tag should only be used for images of a person, product, or event that is known to have come from a press kit or similar source, for the purpose of reuse by the media. Please add a detailed fair use rationale as described on Wikipedia:Non-free use rationale guideline, as well as the source of the image and copyright information. Additionally, if the copyright holder has granted permission, please provide further details as to the terms.

Sorry, Nihiltres, but that looks awfull in IE7 :D.

—Preceding unsigned comment added by Happy-melon (talk • contribs) 17:32, 13 May 2008

But it looks great in Firefox!...... Dendodge .. Talk^Help 22:01, 13 May 2008 (UTC)

That looks overwhelmingly verbose. Why not simplify some of that language? -- Denelson 83 08:07, 26 May 2008 (UTC)

Colour code deprecated

As this code is not using the full colour wheel, I am not allowing it to show up on my screen. Add a use for green and I will reverse this. -- Denelson 83 23:26, 13 May 2008 (UTC)

Yeah, we know. You refuse to accept the color code unless we invent a use for green purely for the sake of using green. Why should we care? —David Levy 23:33, 13 May 2008 (UTC)

Just add

table.imbox-featured {
border:3px solid #228b22;
}

to your monobook.css (or whichever skin you use) and the featured boxes will be green, completing the colour cycle. Nihiltres^{t.l} 14:26, 14 May 2008 (UTC)

Unfortunately, the way this template is coded now is circumventing my ban. Change the CSS to allow me to turn all the imboxes on my screen to green. -- Denelson 83 23:43, 25 May 2008 (UTC)

Yes yes, and we of course do it on purpose! Actually, to accommodate the other 100 million or so users of Wikipedia (who don't know how to manually set or reload their CSS) we currently use hard coded styles while we wait the 30 days it takes for the CSS code in MediaWiki:Common.css to be reloaded into their web browsers.

Accommodating you, or the other 100 million users, now that is a tough choice...

But in about 30 days you will be able to skin the imboxes to your hearts content. Something you could not do at all with the old non-standardised image message boxes. So be happy, things are getting better.

--David Göthberg (talk) 00:17, 26 May 2008 (UTC)

That will not be necessary. -- Denelson 83 00:32, 26 May 2008 (UTC)

What do you mean?

--David Göthberg (talk) 01:20, 26 May 2008 (UTC)

Isn't it obvious? He is planning a coup. Bye bye, Mr Göthberg... Waltham, The Duke of 03:02, 27 May 2008 (UTC)

Mbox differences

I believe that the only differences between ambox, imbox, and cmbox is: background colour; border; and border colour. (The "scheme" for each.)

(This is my understanding following several discussions with DG.)

Is this correct? - jc37 03:16, 24 May 2008 (UTC)

Not quite - each has some unique fixes that haven't (yet) been ported over to the other templates, although in an ideal world they would contain the same display tweaks. {{imbox}} has the "featured" type, which is not supported by the other templates. Each meta-template has its own set of default images. The current drive seems to be for a means of allowing {{imbox}} to take variable-sized images for the left image, which is not supported by the other two. {{imbox}} may also eventually include a "bottom text" parameter, which is not currently supported by the other two (although it may be in future). Happy‑melon 15:56, 24 May 2008 (UTC)

Happy-Melon's explanation is correct. But I certainly would not want a "below" parameter in ambox, that would be terrible. If article message boxes ever become large enough to need the below parameter then something is seriously wrong.

--David Göthberg (talk) 03:36, 25 May 2008 (UTC)

It sounds like all of those "extra" examples all (except "below") are things which should/could be merged to the other mbox templates.

(I think I've asked the next question previously of dg, but not sure.) So how evil is the notion of merging all the mboxes into a single "mbox" template, which has a "style" option for setting the "default" border/background colour scheme as a single entry in the template?

scheme = ab

(the ambox scheme - coloured border along the left side)

scheme = cb

(the cmbox scheme of coloured backgrounds, useful for any "bluespace" namespace.)

scheme = ib

(the imbox multicoloured border scheme)

I would presume that (once coded) this would thus be rather user friendly?

Or is such a thing not possible? - jc37 05:29, 25 May 2008 (UTC)

The different mboxes have slightly different needs and thus slightly different code. For instance since ambox doesn't need and shouldn't have large images it instead have a div in it that makes the text line up nicely when we stack such boxes. But all those differences could of course be handled in the same template using such a parameter as you suggest. (That would mean a single template with a LOT of code inside.) Now we use them like this:

{{ambox|...}}

Say we call your version "mbox", then it would be used like this:

{{mbox|scheme=ab|...}}

Which is simpler to type? Which causes the least template code to process for the servers? Which causes the simplest code in the box? Which is the easiest to maintain? Which does not cause that ALL message boxes on Wikipedia breaks if someone does a mistake with the code? Which does not cause 1.1 million pages to re-render each time we update it?

There is nothing to gain and a lot to loose from putting them all together to one template. So what would be the point in doing that?

--David Göthberg (talk) 07:46, 25 May 2008 (UTC)

Well, actually, the "scheme" could even be predetermined based on namespace through a parser call.

You latter point about "update" is interesting, which makes me wonder if even ambox/cmbox/imbox is each more complex than it needs to be. I would guess that a fair chunk of coding of all these templates could be put into a "core" mbox if we felt that such concerns were concerning. And if so, perhaps that's the better answer. But it's interesting to me that essentially these all are:

"boxes"
with an option for at least one image
with text
with a background
with a border

Honestly, they aren't much different than userboxes, save for size and page placement.

So in looking at the above, what do you feel will have the most "tweaking" which would require such changes? Let's then put the "most stable" parts of this into mbox. If "change" and complexity of code is the actual concern. - jc37 22:30, 25 May 2008 (UTC)

There is some merit in your argument, and I really wish we'd never got into the groove of thinking that these templates attack the server with a baseball bat every time they're updated: I edited {{portal}} not that long ago, which is the silver-medalist with over 1,000,000 transclusions: no effect whatsoever. If it simplifies code and makes it easier to maintain the boxes and propagate updates across them, then we should do it; but we shouldn't do it just because we can - only if it has those advantages. It seems to me that {{imbox}} is deviating from the other standards (with flexible left-image sizes and |bottomtext=) enough to make combining it with the other boxes into a super-meta template difficult - everything that's not the same in all the boxes is something we can't move to the meta-template. Having a super-meta-template without the imbox functionality would be worse than useless; and I just can't see how we could easily merge together enough of the template code to provide significant advantages. Happy‑melon 22:38, 25 May 2008 (UTC)

Jc37: It seems we will have only 6 message box meta-templates: ambox, imbox, cmbox, tmbox, ombox/dmbox, and the namespace-detecting "style-chameleon" mbox. There are good reasons to not let the first five be "style-chameleons" but sometimes we need that functionality and then we have the mbox. And note that mbox just calls the others as needed, so it doesn't have much code in it. And for instance the tmbox is likely to get a lot of special features that the other boxes don't have. So putting together all those special features into one template would cause much more trouble than maintaining six different templates. When we come up with a piece of code that fits in several of those boxes the work to copy and paste the code to them is nothing compared to the work of creating that new code and testing it properly in one of them. If we had one single meta-template instead the work to code and test it properly would be WAY harder.

--David Göthberg (talk) 23:41, 25 May 2008 (UTC)

The "complexity" arguement would be nice, if it weren't for the fact that a "Template-mbox" "special coding" situations (for example) could easily be resolved by using a template which would call "mbox", while adding it's "special features", I presume?

I guess one of the things I keep noticing is that as these discussions progress, new (and good) ideas keep popping up for things which would be useful on all mboxes. So it would seem to make a heckuva lot more sense to have a "core" mbox to make the single change, than going around to all the mboxes to make the change. Else it seems like we're defeating the purpose of standardisation.

Also, in regards to "other": Let's just unite all the "bluespace" mboxes. I would presume that the "style" for category-space would work just fine for Wikipedia space. And the only difference I can see between ambox and cmbox is the "style" (colour/background/border), so it could be easily merged, with a parser of "namespace", as could "talk" space versions.

To give another example of why this could be useful: It could cut down on the number of actual templates necessary.

Imagine if someone only had to merely place an {{xfd}} template, regardless of the namespace, and the template would "do the work for them". We should be attempting to make precesses easier not more difficult.

Same goes for the various cleanup templates. I can imagine several which may be useful in more than one namespace. (Indeed, this was brought up a few times in the various mbox discussions, but was considered by some as potentially "too complex" - there's that arguement again - and so was "left by the wayside".)

I can understand the imbox is more complex. (Especially since there was a decision to merge all the licensing mboxes to it.) But that could be done (I presume) by a "call" to mbox (thus allowing the "core" to be changed with all the other mboxes), with "imbox" having the "additional" needed style, or whatever.

It just sounds like smarter, more intuitive, more adaptable, coding. And looking more to the long term than the short term.

However, if I'm missing something, please let me know. - jc37 21:32, 26 May 2008 (UTC)

Well, as we already have explained several times above: We are about to handle the examples you mention about templates that needs to be used in several namespaces. That is we are going to make tmbox and ombox/dmbox so we cover all namespaces and then make the {{mbox}} that calls the right box for the right namespace. Then the small number of message boxes that need namespace detection can use mbox. So we are going to supply the functionality you want, we just code it "backwards" to the way you are thinking of, since that is better.

Since you don't seem to understand the advantages of our approach even though we explained it in detail several times for you, then there is really only one more thing you can do to increase your understanding: I suggest you try to code up the "message box über-meta-template" you are thinking of. Since when you work with the code then you have to consider all the details and then things probably will become clear to you. Don't forget to handle all the special cases for all the different namespaces. Like that the boxes should only have the ".metadata" class when on articles. (See the Metadata class discussion below.) I suggest you try it out in your own user space, for instance at User:Jc37/mbox. There is of course a chance that what you build becomes better than the current approach and thus you prove me wrong, since you might be seeing something I am missing. Then we of course should use the better solution.

--David Göthberg (talk) 03:09, 27 May 2008 (UTC)

Ouch. Please pardon me for attempting to discuss, and attempt to offer some ideas concerning design, organisation, and implementation. I guess I just didn't see the problem with "talking through" the concepts together. If they turned out to be "undoable", fine. Or even if they were unwanted by consensus, fine. My teachers in programming languages always suggested to have top-down design, and build callable/loopable processes from the inside out. This would seem to be no different (to me at least). Build your "core", and build outwards. The stronger the foundation of your "core", the better use the implementation. And in the modern era of "portability" and "transclusion", I would presume that such lessons in programming would be even more important, preventing spaghetti code and logic. But, again, I won't come even close to claiming to be an expert in this type of coding, and was attempting to learn more. My apologies if my pedantic attempts at discussion hath wasted your invalued time. Personally, I think, and have thought you (plural) to be great. My opinion hasn't changed (mostly), just a bit of shock at being slapped, I suppose. I think it's best if I just bow out of this discussion and leave you to your regularly scheduled davidgothberg. I wish you (plural) well. - jc37 05:43, 27 May 2008 (UTC)

Oh, sorry, I wasn't meaning to slap you. And sorry if I tend to use too hard language. I can't even use the excuse that I am Swedish, since I tend to argue hard in Swedish too. I just don't understand the benefits of your approach. It might be that I miss something and I would be more than happy to be proven wrong. (Well, I might sulk for an hour but I usually get over it quick.) I like improvements, no matter who invents them. But I don't understand how I could implement your approach in an efficient manner. Thus I think you have to do it, since perhaps you know how to do it? If you code it up I can see two likely outcomes: Either you show me/us how to do things better (I'd love that!) or you discover that the current approach is simpler (which would be a boring outcome...). So what I mean is that more words doesn't seem to take our understanding further, but I think code can. (Kind of sounds geeky, but I think you have to speak to us through code in this case. :))

And regarding your teachers: Well, splitting up programs in modules is a very important thing too, which unfortunately often is skipped over since programming courses tend to focus too much on object orientation. Object orientation is meant to be used together with the older modular programming concept, not instead of. Modular programming = "divide and conquer", as opposed to "monolithic programming".

--David Göthberg (talk) 06:30, 27 May 2008 (UTC)

Metadata class

I was the one who added the metadata class to Template:Ambox, which has subsequently been added here. This is causing templates using Imbox to not be displayed when printing, due to .metadata being noprinted in MediaWiki:Monobook.css. This class should be removed the next time this template is updated, as we definitely want licensing tags to be printed. --- RockMFR 21:14, 26 May 2008 (UTC)

Oh, right you are. Thanks for pointing that out. (With many eyeballs all bugs are shallow. :)) I fixed it in {{cmbox}} immediately since that template is "only" used on 14,000 pages. I am copying this discussion to MediaWiki talk:Common.css#Metadata class in mboxes and will continue there since I have some questions about this.

--David Göthberg (talk) 02:11, 27 May 2008 (UTC)