Template talk:Imbox/Archive 2

Archive 1

Archive 2

Archive 3

License templates - full-page width?

I personally have no preference on this, but, if we are thinking about eventual Commons standardization, we should consider if the license template should be full-page width or the same size as other {{imbox}} templates. For comparison, see {{PD-art}} and Commons:Template:PD-art. Keep in mind that some license templates can contain a lot of text. Kelly ^hi! 16:00, 6 May 2008 (UTC)

Support default Imbox-width templates

• If and/or when we cross-standardize image template appearances with Commons, we can then twiddle or tweak some of, or preferably all of, the templates. Until then, it makes little sense to arbitrarily change one subtype as Wikipedia templates will typically be isolated from Commons templates. Nihiltres^{t.l} 16:57, 6 May 2008 (UTC)
• Standardising with commons is a whole other ballgame. Let's do one thing at a time. Happy‑melon 11:06, 7 May 2008 (UTC)
• The license templates here on the English Wikipedia will be shown together with other image message boxes from here, on local image pages. As far as I understand it they will never be shown on a page together with message boxes from Commons. Thus they should have 80% width just like our other local message boxes. The only message box type I know of that will be shown with boxes from Commons is the "featured" type, but I think that it looks okay with 80% width on that one, see for yourself. --David Göthberg (talk) 00:46, 8 May 2008 (UTC)
• I agree with all the points above. However, I acknowledge the problem with some exceedingly long licence boxes, therefore I should like to tentatively suggest the option of collapsibility for this handful of clutterous (like the word?) templates. Waltham, The Duke of 03:36, 8 May 2008 (UTC)

  I was thinking of "verbose". That being said, if such a feature were added, the table should never be hidden by default. It's probably feature creep too - we can always use CSS tricks on custom tables once the colours are in Common.css. Nihiltres^{t.l} 13:19, 8 May 2008 (UTC)

  Not exactly a synonym; I was thinking of "causing clutter in the page". A licence might be verbose, but if there is not much to say the message box will still be relatively small. Anyway, I was not thinking of hiding the entire box, but of obscuring a part of the text, leaving only an introduction or something similar. I did not suggest making the entire message box collapsible, and I should hate to see one collapsed by default. Dear me, Nihiltres, I shall have nightmares tonight... :-) Waltham, The Duke of 19:12, 8 May 2008 (UTC)

Image parameters

Suggestion to make these changes to the code:

see diff here.

1. Change image parameter to take in an Image name (eg. wiki.png) instead of the full code (eg. [[Image:wiki.png]])
2. Same as above for imageright parameter
3. Include imagerightsize parameter. Useful for images that need to be bigger, e.g. {{ShouldBeJPEG}}, {{ShouldBePNG}}, {{Overcompressed JPEG}}

examples of the codes:

{{User:Oahiyeel/Sandbox/Imbox|imageright=wiki.png|imagerightsize=200|text={{lorem}}}}

{{User:Oahiyeel/Sandbox/Imbox|image=wiki.png|imageright=wiki.png|text={{lorem}}}}

comments? - oahiyeel ^talk 14:45, 7 May 2008 (UTC)

What about templates that want to use two images stacked on top of one another? Or templates that need to use an imagemap to overlay two images? For a metatemplate at this level of abstraction, such specialisation removes potential functionality that might be legitimately needed. Happy‑melon 20:14, 7 May 2008 (UTC)

Happy-melon: Ah, good point.

Oahiyeel: We have several possible solutions:

1: Simply not allow images over 52 pixels width. As is the case for the current code now and for ambox. The reason we made it so for ambox was that we wanted the texts in different boxes to line up nicely above each other even if the different icons had different widths.

2: As I wrote far above in section Flags I could code up a real monster that can take an image width parameter when an image is over 52 pixels in width. Then only in the case where the image is larger than 52 pixels will the texts not line up between boxes. (Later added comment: And that seems to be what oahiyeel has done above.)

3: Drop the demand that texts in different boxes line up and let every box has its own positions of the text. Then I can make a box that instead have a fixed "padding" on each side of the images. (That padding will have to be implemented as extra table cells with DIVs in to force the proper padding, since the text cell is set to 100% width.) And then images can still be fed the old way with the full Wikipedia image syntax.

4: Simpler version of 3: Just drop the text align demand for the right side image. Thus just allowing large images for image right.

--David Göthberg (talk) 01:13, 8 May 2008 (UTC)

I think we're succumbing to feature creep here - why is it necessary to allow the one random image that's 300px? I do think that we should set the image cell width to something a bit larger than 52px (I'd support something around 75px) because the images in ns-image templates tend to be larger in general; but allowing for exceptions to our nice neat layout style seems to be shooting ourselves in the foot. I haven't yet seen any persuasive reasons (actually, any reasons at all) why overly large images in the templates should be allowed. Happy‑melon 08:21, 8 May 2008 (UTC)

I agree with Happy-melon here, adding more functionality would be feature creep. And I just realised we already have a good solution for this, the documentation for {{ambox}} says this:

This meta-template uses the ambox CSS classes in MediaWiki:Common.css. The classes can also be used directly in a wikitable if special functionality is needed. See the how-to guide for that.

And that will be true for imbox and cmbox too when we have added their styles to Common.css and waited a month for the CSS caching to time out.

But still, the more I think about it I think that my 4th option above would be good. Since right side images are not so common then I don't think they need to line up with each other, so we could allow varying sizes for images on the right side. And the 4th option would be pretty simple and clear code. And it doesn't add any new parameters and doesn't change how to use the old parameters, so this template would still be fully parameter compatible with ambox and cmbox.

--David Göthberg (talk) 11:26, 8 May 2008 (UTC)

I think this is best as well. As mentioned above in Flags, the most common right image would be a flag in license templates, of which there is normally only one on a page. So text/image alignment is not so much of a concern in those cases. Kelly ^hi! 12:31, 8 May 2008 (UTC)

I can't think of a situation where it would be necessary to have an image or imageright which displayed larger than about 75px, so preventing that from happening, resulting in a moderate improvement in appearance, seems sensible. Of course if there is a genuine need to have large images in the templates, then naturally we should allow for that. Can anyone give any such examples? Happy‑melon 14:32, 8 May 2008 (UTC)

An example would be {{Cc-by-sa-2.5,2.0,1.0}}, which uses a 90px image for the "CC: Some rights reserved" image. {{FeaturedSound}} has two 57px images side-by-side, and {{FSC}} has two 90px images side-by-side. Assuming that we want to not change elements other than the main layout (border, colour, etc.) then we should accommodate images up to, say, 100-150px most likely. Some templates can have their images reduced in size (e.g. {{OTRS pending}}), but others may have issues, especially ones that have parameters to display other images, e.g. {{db-i1}} which displays a 150px thumb of the duplicate image in question. I don't mind much either way, but these are the facts. Nihiltres^{t.l} 15:05, 8 May 2008 (UTC)

I don't think any of these present insurmountable problems for a max image size of about 75px: templates which have two images side by side could move one of them to the |imageright= position, and the 90px images look a little ungainly anyway. I don't think we'd get howls of complaint if we scaled them down a bit. However I can see that {{db-i1}} has legitimate use for a larger image (although of course it could just be placed within the text cell as it is currently). As I've said above, I don't have a big problem with 'unlocking' the image size; as long as it's genuinely necessary. My main complaint was with the unnecessary specialisation promised (threatened, in my opinion) by |imagerightsize= and |imageright=Foo.jpg, etc. Happy‑melon 15:37, 8 May 2008 (UTC)

I have now tested new code for handling the right side image. Code that allows images with larger size but still gives proper padding. It actually caused simpler code. And as I said above, it doesn't add any new parameters and doesn't change how to use the old parameters, so this template would still be fully parameter compatible with ambox and cmbox.

I have coded up an example with the new code at {{cmbox/test1}}.

I don't know if cmbox needs to handle larger images but since I was testing new margin code for cmbox I tested new image code at the same time. I would like to know how that looks in Safari and in recent versions of Internet Explorer. I have tested it in Firefox 2.0.0.13, Opera 9.02 and Internet Explorer 5.5.

--David Göthberg (talk) 16:56, 8 May 2008 (UTC)

All looks good in IE7. Great work, as always, David! Happy‑melon 20:52, 8 May 2008 (UTC)

I have two issues.

1. Isn't that test box cmbox, not imbox? :p
2. It totally wrecks the layout for {{Cc-by-sa-2.5,2.0,1.0}} and similar templates if the left image cannot be up to 90px. I mean, check out my sandbox (note: linked to main, might eventually change to something else. [permalink]) It would probably be a good idea to allow the margins to be wider if possible. Nihiltres^{t.l} 00:44, 9 May 2008 (UTC)

Nihiltres: Yes, that example above is a cmbox, but that example contains code to allow large right side images so it was relevant to this discussion.

As I explained above, there are no simple way to allow very different sized images in the left image position unless we drop the demand to have the text in different boxes line up for most images. So I suggest that for the rare occasions who "must" have an image over 52 pixels on the left side you use the cmbox CSS classes directly in a HTML table to build the message box. (Those CSS classes will be available in about one month due to CSS caching.)

I have now added code to {{imbox}} so it can handle large images on the right side. Please everyone have a look at Template:Imbox/testcases and see that it looks okay in your browsers. I especially want to know how it looks in Safari and in recent versions of Internet Explorer.

--David Göthberg (talk) 00:47, 9 May 2008 (UTC)

All fine on IE7. Happy‑melon 14:34, 9 May 2008 (UTC)

Speedy image

To help distinguish between Speedy and Normal deletions at a glance, as on some monitors the pink background is unclear, I have created Image:Ambox speedy delete.png, which comes out as: . What do you think?...... Dendodge .. Talk^Help 17:13, 8 May 2008 (UTC)

Nice effort but I don't like it. I'd rather have something that indicates urgency, such as a stopwatch or the numbers "3...2...1..." or something.

—Preceding unsigned comment added by Davidwr (talk • contribs) 17:37, 8 May 2008

Hmm, well I knocked this one up in a couple if minutes (and intend to make a better version) but thought I'd see about the idea. We've already got stopwatches so we could use one of those (there's a couple in Nuvola)...... Dendodge .. Talk^Help 18:01, 8 May 2008 (UTC)

Giving stopwatches another thought: Clocks have traditionally been used for current events rather than deadlines. davidwr/(talk)/(contribs)/(e-mail) 18:13, 8 May 2008 (UTC)

As I said on the parallel discussion at Template talk:Cmbox: that really did give me a smile... but I don't think it's appropriately serious for the least lighthearted class of templates we have. Happy‑melon 18:15, 8 May 2008 (UTC)

We could perhaps use a flashing triangle for speedies... That would be both eye-catching and urgent-looking. I've heard that blinking is evil, but that is not exactly a disadvantage in my book. (evil grin) Waltham, The Duke of 19:42, 8 May 2008 (UTC)

No animated images, please. —Michael Z. 2008-05-08 19:44 z

I was kidding. Animated images are too evil even for me. Too eye-catching, too urgent-looking... Overkill. (And yet still not serious enough.) Waltham, The Duke of 19:52, 8 May 2008 (UTC)

Sorry, I guess I realized. But I haven't much sense of humour about this because I still occasionally have to stop reading articles partway through because some bozo has put animated ads on the page. —Michael Z. 2008-05-08 20:03 z

I almost completely understand ("almost" because it has never happened to me). Waltham, The Duke of 23:34, 8 May 2008 (UTC)

[un-dent] Me likes Dendodge's pic for speedies. A lot. NikoSilver 22:49, 8 May 2008 (UTC)

The image reminds me of a colour print-out once left in a bathroom. :p. I like the concept, but this version seems like it might be somewhat ambiguous. Nihiltres^{t.l} 01:24, 9 May 2008 (UTC)

Template lists

I think I am mostly complete on compiling the major lists of imagespace templates in my userspace (they're linked at the top of this page), though I'm sure there are more out there that I haven't been able to turn up. Should I make copies of them on subpages of this page for people to work with? Eventually WP:TMIN needs to be updated (it's in sad shape) and the license template pages are also incomplete. There are quite a few redundant templates that need to be listed for deletion, also. Kelly ^hi! 23:26, 9 May 2008 (UTC)

Oh dear, that is quite a list. Thanks! Good that we have a resident image specialist like you around!

And nah, don't copy the templates here, it would be confusing. People can update them right on their pages, or make /sandbox versions if they need to.

By the way, could you take a look at the type examples I made in the documentation for {{imbox}} and check so I didn't list the wrong templates as examples for each type?

--David Göthberg (talk) 01:53, 10 May 2008 (UTC)

Standardising other name spaces

Copied from previous section:

Before I forget... You have mentioned project space, Mr Göthberg. Are there any plans in sight regarding the standardisation of the templates within that namespace? Be candid with me, or you shall suffer my extreme displeasure and the terrible consequences thereof. Waltham, The Duke of 03:43, 9 May 2008 (UTC)

Haha, I better write a long and detailed answer then!

Oh, we already have a very old de facto standard for project (Wikipedia:) space and other spaces. The light grey background with a darker grey one-pixel border as specified by the .messagebox CSS class in MediaWiki:Common.css. And that standard is enforced by many editors who changes any message box in project space to that standard if someone tries to add something else. Here's an example of such a box:

(I think I should fix that {{notice}} box up with the new information icon we made for ambox.)

But hang on, the protection templates have their own border style in other space (two pixels blue-grey). And if we look at Wikipedia:Template messages/Wikipedia namespace then we see that the {{humornotaccepted}} has blue background and {{backlog}} has pink background. And the {{intricate template}} has a one pixel red border. But using our ambox / imbox / cmbox colour scale those three templates should probably be yellow or perhaps even orange. (Border or background? Tough choice.) I wasn't planning any new standardisation, but perhaps it is needed...

I have been thinking of perhaps making two ambox / imbox / cmbox compatible meta-templates that renders boxes in the current grey project space colours and the standardised brown talk page colours. Just to make it easier for people to build message boxes that flows well with other boxes. I am thinking of naming them {{ombox}} as in "other spaces message box" (which includes project space) and {{tmbox}} as in "talk space message box".

For those that don't know what "flow" means: Bad flow is when boxes for instance pushes each other out of the screen, or overlap each other and other such nasty things. We have special code in ambox / imbox / cmbox that makes them flow better than the current project space boxes. (That code was added to ambox during my last wikivacation, very encouraging to come back and see that things had been improved!)

--David Göthberg (talk) 14:14, 9 May 2008 (UTC)

Hmmm... Answer deemed satisfactory. :-)

Over-exertion is a bad thing, and we have enough things going on here, so there is, of course, no pressure at all on starting new projects. Once we get images and categories done with, we can move on to the remaining namespaces, of which only Project actually needs work; of the rest, only the Template and User namespaces use message boxes, and very few which could be standardised, as a matter of fact. (Template space mostly uses protection templates and one that says "Intricate template – be careful not to mess it up"; in user space most templates are custom-made and with varying purposes, in addition to an ocean of userboxes, with only few real message boxes.)

Apart from the obvious common element between amboxes, imboxes, and cmboxes (i.e. that readers can see them), they are the most-used ones, so they are of greater importance. Their great variety is also noticeable. Therefore, one can plausibly claim that with these three finished the bulk of the standardisation work will have be completed.

After Project space, if you really are interested in standardisation in general, you could drop by WP:SBS... We could use some helping hands. (Actually, we always can.) Waltham, The Duke of 06:11, 10 May 2008 (UTC)

Right, we should wait some months between standardisation projects since it takes time for things to settle.

I took a look at WP:SBS since I got curios what it was. I am actually not that interested in standardisation, but I am very interested in template programming. But ouch! I think I'll keep away from that one. I first thought my latest "invention" in template programming would be applicable and simplify things, but then I saw the boxes that span two or more rows and then it just got scary. But I'll keep it in mind, I might come up with something.

--David Göthberg (talk) 11:29, 10 May 2008 (UTC)

Protected template

Could an admin please update {{GFDL-with-disclaimers}}? I have placed the new code on the template talk page and created the /doc page as well. Kelly ^hi! 16:38, 10 May 2008 (UTC)

 Done, but... does it really need so much custom (text)styling? It kinda defeats the standardisation, don't you think? — Edokter • Talk • 16:48, 10 May 2008 (UTC)

I agree - I went with what existed already, figuring that would be noncontroversial. Should we all agree to stick with the defaults barring some special circumstances? Also, I noticed that the template has no default for image size if a size for a custom image is not specified. Here is an example -

Should we have a default of 52px if no size is specified? Kelly ^hi! 16:57, 10 May 2008 (UTC)

There's no way to force a maximum image size whist also maintaining the functionality for multiple images, imagemaps, non-image 'images', and all the paraphenalia that people might want to do with the |image= parameter. Happy‑melon 17:13, 10 May 2008 (UTC)

Max size depends on the image being used. Standardised icons are ususally 40px. Here's the template standardised with 52px and no line-breaks. — Edokter • Talk • 17:16, 10 May 2008 (UTC)

I have removed the custom formatting from the template, keeping only the align:center. I think, however, that making the text in license imboxes smaller by default would be a good idea - can this be added to the {{imbox}} code and/or site CSS so that it doesn't have to be set on each individual license template? Happy‑melon 17:17, 10 May 2008 (UTC)

Are you thinking 85%? Also, I like Edokter's left-aligned version without line breaks better than the centered version that currently exists...I think it looks more tidy. Kelly ^hi! 17:22, 10 May 2008 (UTC)

Yeah, I am not a fan of centering text at all. I also think small text should be limited to subtexts (often seen in ambox, although also rarely consistently, some use small, ohters use non-bold), or templates with lots of text. How about this?

Or using regular/small combination:

And if small text is going to be used, please use 88% (but I'm not a fan of this). — Edokter • Talk • 17:45, 10 May 2008 (UTC)

I like the standard text size with only the name of the license bolded (your first example of the four). Kelly ^hi! 17:51, 10 May 2008 (UTC)

I'll second Kelly's opinion. And I'll also second Edokter's opinion that centered text should never be used. --CapitalR (talk) 17:58, 10 May 2008 (UTC)

I second that too. I prefer normal text size, not all of our readers and editors have hawk eyes. And I too prefer left-aligned text.

Since that seems to be the consensus here so far I have updated the template to use left-aligned text.

--David Göthberg (talk) 18:07, 10 May 2008 (UTC)

Default license icon

The default icon for "license" type boxes doesn't matter that much since all license boxes can and should set a more specific icon when they use {{imbox}}. But since the icon has been changed I thought we should discuss it here.

When we first made that box type we used the public domain icon, mostly since we had not come up with a better alternative yet. Looking like this:

But using an icon with a distinct license meaning as default like the public domain icon might be a bad thing since then it might be used by accident on other licenses.

Kelly suggested this one:

David Levy tonight made and changed the default icon to a question mark within a circle:

(David if you have the time and think it is a good idea: Could you make the question mark slightly smaller and fatter? I think it looks a bit skinny inside that circle now.)

I like both Kelly's and David Levy's alternatives. Both works for me. Any one else have any points of view?

--David Göthberg (talk) 19:12, 10 May 2008 (UTC)

I've adjusted the question mark. How does it look? —David Levy 19:44, 10 May 2008 (UTC)

Yes, that looks more proportionate, especially when displayed together with the other images in the doc at {{imbox}}. Thanks!

--David Göthberg (talk) 19:55, 10 May 2008 (UTC)

The question mark isn't bad, but perhaps it would be more appropriate to not have a default license template image at all:

—Remember the dot ^(talk) 01:11, 11 May 2008 (UTC)

Ouch! When I saw your blank image example I first thought you had discovered the undocumented "blank" parameter that I want to remove. (Just haven't brought that up for discussion yet.) But instead you are using an empty image parameter "image=", so you just discovered a bug. I guess that case really should produce the default image. Ah well, at least I can blame it on others. I never liked that version of that switch case, it wasn't coded by me and uses some weird logic that has some other known side effects. But perhaps you can blame me, since I copied it from ambox without fixing it.

Anyway, I prefer a default image for "license" too, otherwise I bet some people will think that type can not have images.

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

Empty "image=" parameter bug fixed. And I dropped the undocumented "image=blank" option at the same time. Instead I added a "image= " to Remember the dot's example above to keep it a blank image.

--David Göthberg (talk) 04:40, 11 May 2008 (UTC)

Edit request

Three other protected license templates ready for update - {{GFDL}}, {{GFDL-1.2}}, and {{GFDL-1.2-en}}. The new code is on the template talk pages and /doc pages have been created. Kelly ^hi! 00:26, 11 May 2008 (UTC)

 Done --CapitalR (talk) 01:12, 11 May 2008 (UTC)

Flags

The imbox has been upgraded since this was written, so the flag in the example below doesn't butt up against or overflow the box border anymore.

If we use imbox for license tags, it's going to be most common for the right image to be a flag. Testing this with the US flag (with a size of 50px for the copyright icon and 70 px for the flag) results in the following:

This image is in the public domain in the United States. In most cases, this means that it was first published prior to January 1, 1923 (see the template documentation for more cases). Other jurisdictions may have other rules, and this image might not be in the public domain outside the United States. See Wikipedia:Public domain and Wikipedia:Copyrights for more details.

The right border of the flag butts up against the margin, which I don't think looks quite right. Also, could someone who is a math wizard figure out the best size for a flag to balance with the copyright icon, given the different size ratios of the different icons? Kelly ^hi! 13:26, 2 May 2008 (UTC)

There are several solutions to this, both organisational and technical. But as I stated above, lets focus on standardising the colours and borders first.

--David Göthberg (talk) 14:38, 2 May 2008 (UTC)

Hmmm, I ended up switching computers...on IE, the flag border was right up against the right margin of the box. On Firefox, part of the flag is actually outside the box. But you're right, this can be tabled until more fundamental issues are solved. By the way, the above example uses the (semi)standard Commons colors for PD/GNU license templates. Kelly ^hi! 16:08, 2 May 2008 (UTC)

Right, "butts up against the margin" means that it touches it. Obviously, I didn't pay enough attention; I have Firefox and I've been seeing the protruding edge of the flag all along. Anyway, if you have any questions about how something looks in Firefox, I'll be here to answer. Now, if you will excuse me... (starts banging head against wall) Waltham, The Duke of 19:48, 2 May 2008 (UTC)

I should perhaps explain: When we made the ambox we had problems with box flow and other boxes overlapping it in several browsers. It looked weird, but in different ways in different browsers. We tried everything and finally found a solution that works in all browsers. However, that solution means that the space available for the left and right images had to be locked to a fixed maximum size. We choose 52 pixels. (One can use up to about 4 pixels bigger images but then they get no padding.) I reused that size for the imbox. So the simple solution to the flag problem above is to set the flag to tops 52 pixels width. Of course, we should perhaps later discuss what maximum image size the box should support. Note that the larger we set that size the more padding there will be around smaller images, making it look very weird for small icons.

We might be able to work around this. For instance with the help of some "{{#expr:||}}" and "{{#if:||}}" functions I can code up a rather complex thing where if you feed an image larger than 52 pixels then have to feed an "image size" and "image size right" parameter too. Thus the box internally can use a "fixed" size appropriate for your image. But I would rather not do that since then the box code will be a monster that not many people could understand and manage.

--David Göthberg (talk) 09:43, 4 May 2008 (UTC)

For the record: problem solved. The template looks just fine now. Waltham, The Duke of 03:36, 12 May 2008 (UTC)

I added the "seetalk" param

Please comment about it here, revert at will. Used to attract attention to the discussion page of an image. CompuHacker (talk) 02:22, 9 May 2008 (UTC)

Why do we need this? Isn't this redundant to the "notice" style? Nihiltres^{t.l} 02:27, 9 May 2008 (UTC)

The "speech bubble" symbol in other cultures represents the god of Periwinkle Doorknobs of Blah. In any case, it separates it from normal notices. CompuHacker (talk) 02:31, 9 May 2008 (UTC)

Appended: It separates it by having a separate symbol, color, and style, and ensures that the person will immediately bow down to the aforementioned god and look at the talk page in it's divine glory. Or something like that. In any case, it's different. CompuHacker (talk) 02:34, 9 May 2008 (UTC)

Well I'd say it's still got the same style as the rest of them, and the image is already configurable through the "image" parameter, and the color is technically configurable through the "style" parameter. I just don't see the need to add another built-in type in addition to the ones we already have. This fits as a "notice" type already. --CapitalR (talk) 02:54, 9 May 2008 (UTC)

Right, this doesn't seem to be a new type to be used for many different templates, instead it seems to be a single template. So it should use an existing imbox type. In this case the notice type fits well. If there is a more specific icon then that one should be used. And the speech balloon suggested by CompuHacker is a very nice choice. Thus making it a template looking like this:

This could be the {{see talk}} template.

That seems to be a very useful template, especially in image space where people are not very aware of the talk pages. I would like to fix it up with the namespace detecting feature so it could change appearance and be used in category and project space too. (But I would not want it used on articles!)

--David Göthberg (talk) 03:20, 9 May 2008 (UTC)

No, definitely not in the mainspace. Still, I agree that it is a most useful template, which would expedite discussion about important matters pertaining to images, facilitating improved communication overall, ultimately ensuring higher standards in articles, etc. etc. I humbly pay my respects to the divine Periwinkle Doorknobs of Blah. (bows)

(rises) Before I forget... You have mentioned project space, Mr Göthberg. Are there any plans in sight regarding the standardisation of the templates within that namespace? Be candid with me, or you shall suffer my extreme displeasure and the terrible consequences thereof. Waltham, The Duke of 03:43, 9 May 2008 (UTC)

David's {{See talk}} code could be useful, but are we in agreement that adding extra code to {{imbox}} is unnecessary? Happy‑melon 08:38, 9 May 2008 (UTC)

As far as I am concerned, we are; it would make the template more complicated without a real reason, and it would make its usage more complex as well. We want our system as simple as possible. A single template conforming to the Imbox info style is all we need, I think. Waltham, The Duke of 09:49, 9 May 2008 (UTC)

Perhaps, and this is just throwing out ideas, we could make an upper-right corner icon, similar to the semi-protection and the former 3d glasses template. Or we can put text. My user page, near the bottom, has several "CHCorner****" templates. That code could be used, seperatly of this template to create corner text, perhaps a large arrow pointing to talk. However, I have heard that absolute-corner icons can cause issues with some computers. Thoughts? CompuHacker (talk) 15:02, 9 May 2008 (UTC)

I say you use the azure notice style with the word balloon image.--HereToHelp ^{(talk to me)} 01:56, 10 May 2008 (UTC)

I would like to restart this discussion. Does anyone have a any ideas on how to include, separate, or improve Template:IMGseetalk? Please put out any ideas you have concerning making a standardized template for this. CompuHacker (talk) 15:25, 12 May 2008 (UTC)

I thought we pretty much had it nailed: it's a Bad Idea to add extra code to {{imbox}}, but code along the lines of:

{{imbox
| type = notice
| image = [[Image:Speech balloon.svg|40x40px]]
| text = {{{text}}}
}}

Would create a 'middleman' template that looks nice and fulfills the requirements perfectly. Happy‑melon 20:21, 12 May 2008 (UTC)

Larger icons break awfully

I tried turning {{ShouldBePNG}} into an imbox and this is what I got:

{{imbox
| type  = style
| image = [[Image:Comparison of JPEG and PNG.png|100px|ℹ]]
| imageright = 
| style = 
| textstyle = 
| text  = This image was [[Wikipedia:Uploading images|uploaded]] in a format such as [[GIF]] or [[JPEG]]. It could be stored, however, in the [[Portable Network Graphics|PNG]] format, which supports lossless compression and transparency. Because the PNG format supports lossless compression, edits made to PNG files do not reduce their quality. If possible, please upload a PNG version of this image. After doing so, please replace all instances of the previous version throughout Wikipedia (noted under the "[[#filelinks|File links]]" header), tag the old version with <code>{{[[Template:PNG version available|PNG version available]]|NewImage.png}}</code>, and remove this tag. For more information, see [[Wikipedia:Preparing images for upload]].
}}

The culprit appears to be a div wrapping the image with style="width: 52px;". When the style parameter is removed it looks fine:

—Remember the dot ^(talk) 01:22, 11 May 2008 (UTC)

What about using "min-width" instead of "width" in the image divs? I just tested it out in Firefox and IE7 and it seems to work...anyone know if IE6 supports that? --CapitalR (talk) 01:32, 11 May 2008 (UTC)

Scratch that, IE6 doesn't support it. --CapitalR (talk) 01:39, 11 May 2008 (UTC)

I see no problem in IE6, but it overlaps in Firefox. So one could still use min-width in addition to width, as IE is not affected. — Edokter • Talk • 11:54, 11 May 2008 (UTC)

Oh no, it is better to not use min-width so it "breaks" in all browsers. Otherwise IE editors will add large images and think that is okay, but users in other browsers will see broken pages. Large images should be put on the right side.

--David Göthberg (talk) 13:36, 11 May 2008 (UTC)

But it would behave the same, at least in IE and Firefox. And I suspect most other browsers support min-width. The way it is now is more likely to cause IE editors to break it for other browsers. — Edokter • Talk • 13:46, 11 May 2008 (UTC)

Ah, I misunderstood. So I looked up "min-width" in my CSS docs and it is already in at least CSS 2.1 so I thought worth a try. I tried a LOT of combinations. (See the history of Template:Imbox/sandbox if you want more details.) I have Firefox 2.0, Opera 9.0 and IE 5.5. Here are my results when trying large images in the left position:

• With only min-width it worked in Firefox, but not with any other combination.
• With only min-width it didn't work in IE, but worked in all other combinations that had "width" in them.
• It didn't work in Opera no matter what I did.

So seems we have to have a fixed width in the left position and not feed any images larger than that. Or drop the width altogether and let the left position of the texts in the boxes vary wildly, which I don't want. So again, either use the right position for the large images, or hard code the occasional box that you think must have a large image to the left (which will be easy when the CSS classes are available).

--David Göthberg (talk) 16:30, 11 May 2008 (UTC)

Use the right side

{{imbox
| type  = style
| image = style
| imageright = [[Image:Comparison of JPEG and PNG.png|100px|ℹ]]
| style = 
| textstyle = 
| text  = This image was [[Wikipedia:Uploading images|uploaded]] in a format such as [[GIF]] or [[JPEG]]. It could be stored, however, in the [[Portable Network Graphics|PNG]] format, which supports lossless compression and transparency. Because the PNG format supports lossless compression, edits made to PNG files do not reduce their quality. If possible, please upload a PNG version of this image. After doing so, please replace all instances of the previous version throughout Wikipedia (noted under the "[[#filelinks|File links]]" header), tag the old version with <code>{{[[Template:PNG version available|PNG version available]]|NewImage.png}}</code>, and remove this tag. For more information, see [[Wikipedia:Preparing images for upload]].
}}

styleThis image was uploaded in a format such as GIF or JPEG. It could be stored, however, in the PNG format, which supports lossless compression and transparency. Because the PNG format supports lossless compression, edits made to PNG files do not reduce their quality. If possible, please upload a PNG version of this image. After doing so, please replace all instances of the previous version throughout Wikipedia (noted under the "File links" header), tag the old version with {{PNG version available|NewImage.png}}, and remove this tag. For more information, see Wikipedia:Preparing images for upload.

Looking it over, I think your solution might be to place the larger image on the right, which makes it work correctly. I think this type of template is what the imageright parameter was designed for. --CapitalR (talk) 02:12, 11 May 2008 (UTC)

I never have liked that image anyway, I can't tell the difference between the two sides. :) Kelly ^hi! 02:13, 11 May 2008 (UTC)

Yup, that too. :) --CapitalR (talk) 02:16, 11 May 2008 (UTC)

Right, that div with a fixed width of 52 pixels is there so that when several boxes stack on top of each other the left side of their texts will line up nicely. And that also limits the max size of left side images to 52 pixels width, or you get padding and overflow problems. That's the solution that was chosen for ambox and I copied it here since I like it.

As CapitalR pointed out we have fixed so the right side can take large images, so use the right side. The right side doesn't cause ugly alignment problems between boxes as easily since only some boxes use a right side image.

For more discussion about this see the section Image parameters above.

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

OK, thanks for the info. We should probably also make the image a bit larger so you can tell the difference more easily. —Remember the dot ^(talk) 03:36, 11 May 2008 (UTC)

Another protected template

{{PD-self}} is ready for update, with code on talk page. This will give the server some work, so I will hold off on doing any other widely-used license templates tonight. Kelly ^hi! 01:50, 11 May 2008 (UTC)

 Done --CapitalR (talk) 01:58, 11 May 2008 (UTC)

Well, the job queue is only around 250,000 now which is very low, so I don't think we need to worry about server load for the moment. :))

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

Most pd-self images are on Commons anyway. — Edokter • Talk • 11:57, 11 May 2008 (UTC)

Two more

{{GFDL-self}} and {{GFDL-self-with-disclaimers}} are ready for update, code on talk pages. Kelly ^hi! 14:14, 11 May 2008 (UTC)

Both are done. — Edokter • Talk • 14:58, 11 May 2008 (UTC)

Background color check

Just as a sanity check: are we summarily getting rid of the different background colors for templates like {{Copyrighted free use}}, are we keeping those colors, or are we treating them on a case-by-case basis? There's quite a few (see User:Kelly/Image_license_templates), so I want to be sure before any mass conversion. --CapitalR (talk) 04:19, 12 May 2008 (UTC)

Yes, they are all to be standardised to "license" grey. And I think in that case the icon should perhaps be changed to Image:PD-icon.svg .

--David Göthberg (talk) 04:41, 12 May 2008 (UTC)

Great, just making sure. --CapitalR (talk) 04:46, 12 May 2008 (UTC)

Okay, I just converted 400 license templates to use imbox and all looks well so far (see User:Kelly/Image_license_templates for the results; note that due to the 2mb post-expand limit, the last 50 templates or so are cut off). The remaining license templates couldn't be easily converted by my script, so we'll have to do them by hand. I'm going to bed now, but if there's any problems let me know and I'll fix them first thing in the [California-time] morning. With that many conversions it's pretty much guaranteed that I screwed something up on at least one template, so any help fixing collateral damage is appreciated (though I don't see any yet...). --CapitalR (talk) 09:59, 12 May 2008 (UTC)

"Commons file" box

I haven't even been able to find a template creating the box saying "This is a file from the Wikimedia Commons. The description on its description page there is shown below." I feel that it should conform to the imbox style, because:

• It is located before the other Wikipedia templates, and not after them, unlike the other Commons boxes. That is the right location, of course, but there is a visual awkwardness, or even tension, which I think should be resolved.
• It actually appears, in principle, to be a Wikipedia template referring to Commons, not a Commons template. Technically, of course, it is probably the other way round, which is why I cannot see what we could do.

But there are people with better knowledge of these things, whom I invite to comment here. Waltham, The Duke of 22:06, 12 May 2008 (UTC), modified 22:11, 12 May 2008 (UTC)

See #Deploying! above. It's at MediaWiki:Sharedupload. The consensus seems to leave it alone for the time being, because it should match the templates at Commons itself; Commons images never display local (imbox) templates anyway. — Edokter • Talk • 22:20, 12 May 2008 (UTC)

I respectfully disagree. Actually, half the TFPs in May's archive seem to disagree: even if it is only for the FA message boxes, there are local templates.

As far as the discussion above is concerned... Well, I cannot say I've followed it very closely; in the technical sense, I am rather ignorant in anything more complex than succession boxes. Waltham, The Duke of 01:47, 13 May 2008 (UTC)

Featured images on Wikipedia that are hosted on Commons will probably make up a minority relative to those images that are hosted on Commons but are not featured images on Wikipedia. As such, I don't think that we can justify changing MediaWiki:Sharedupload without a substantial cross-standardization with Commons. Nihiltres^{t.l} 05:02, 13 May 2008 (UTC)

Pity... Waltham, The Duke of 06:19, 13 May 2008 (UTC)

Imbox CSS classes

I have now added the imbox CSS classes to MediaWiki:Common.css.

Due to caching of the style sheet in the web browsers we can not use these classes in the imbox template until 13 June. Until then imbox has to continue to use hardcoded styles. But we can use the classes for testing in the {{imbox/sandbox}}.

If anyone wants to have a look at the classes they are easier to view and there is some explanation at MediaWiki talk:Common.css#Ambox, imbox and cmbox.

--David Göthberg (talk) 02:47, 13 May 2008 (UTC)

Left image cell width

Can someone take a look at {{cc-by-sa-2.0-de}} and figure out a good way to imbox it? I'm having trouble making it look good because of the 52px left image restriction. If you can get that one to work I can mass convert the rest of the CC templates. --CapitalR (talk) 07:28, 12 May 2008 (UTC)

I think we need to trim some of the whitespace from around Image:CC some rights reserved.svg. As I've said above, perhaps a slightly larger image size than 52px would be appropriate for imbox - 70px perhaps? Happy‑melon 08:38, 12 May 2008 (UTC)

Tough one... If we increase the width, I suggest 72px. Or the "Some rights reserved" could be moved to the right. — Edokter • Talk • 09:34, 12 May 2008 (UTC)

That'd look a bit wierd, and adopting the policy of using |imageright= as a dumping ground for oversized images strikes me as trying to avoid dealing with the problem :D. Any particular reason to prefer 72px? Happy‑melon 09:45, 12 May 2008 (UTC)

Just speculating that the 52px was chosen to allow 2px for padding/bordering, so the same should apply to 70/72px. — Edokter • Talk • 09:57, 12 May 2008 (UTC)

Okay, since this width discussion seems to come back all the time. Lets discuss this seriously. First of all, I have changed the code in {{imbox/sandbox}} to use a 70 pixel div on the left side. Take a look. (Note: the sandbox might change, so this is just a temporary show.) I think it gets too wide for the small icons. And it still is too tight for some left side images like the Cc-by-sa image. So we need to do something else.

So here are the options, lets discuss WHICH option we should use:

1. Simply not allow left side images over 52 pixels width. As is the case for the current code now and for ambox. I guess from the discussions that pop up here that this might not be an option? The reason we made it so for ambox was that we wanted the texts in different boxes to line up nicely above each other even if the different icons had different widths.
2. Set the left cell width to say 70 pixels. I don't think this works, looks bad for the smaller images and is still too small for the larger images.
3. Drop the demand that texts in different boxes line up and let every box have its own left side position of the text. The images should still be fed the old way with the full Wikipedia image syntax. So no change in parameters and how we use imbox, just a slight change in looks looking less orderly when boxes are stacked on each other.
4. Add an optional parameter "imagewidth". If not fed then the width of the left image cell defaults to 52 pixels and texts of stacked boxes are lined up. But if imagewidth is fed then that width is used instead. The images should still be fed the old way with the full Wikipedia image syntax, thus allowing to feed any kind of object or multible stacked images and so on to the left side. The imagewidth parameter is only used to set the left side div size. (We can make it so that the imagewidth parameter is smart and defaults to 52 pixels if a value lower than 52 is fed, so that the box texts line up neatly for smaller images even if people feed the size of their small images.)

I have coded up examples of option 3 (and that kind of also shows how option 4 will look) so everyone can see how it looks. See the bottom of {{imbox/sandbox}}. After seeing that example I think I prefer option 3 since it is simple, robust, and didn't look as bas as I expected. Although I expect this to cause that people will use wildly varying image sizes, just like before. (I have noticed that some Americans like to feed HUGE US flags to the right side...)

So, what option do you people prefer?

--David Göthberg (talk) 12:29, 12 May 2008 (UTC)

I think your examples look ok - option 3 gets my !vote. It's not possible to set min/max widths, allowing for variation between those limits? If so, I think we could get the best of both worlds by setitng them at say, 52/122. Alternatively, if it couldn't be enforced in the code, we could just put a big instruction in the documentation not to use images over a certain size. Happy‑melon 14:02, 12 May 2008 (UTC)

There must be a way to force a consistent cell-width, and I think I know how... hold on. — Edokter • Talk • 14:04, 12 May 2008 (UTC)

OK, I figured out why setting a minimum width in the image cell will not work; the text cell is set to 100%, which overrides other cells everytime. That is the reason why the DIV is there, but that in turn causes a problem in Firefox. In this light, and considering that no images smaller then 40 px are going to be used. I think letting the image cell decide it's own width is the best way to go. All that needs to be done is remove the div. — Edokter • Talk • 14:27, 12 May 2008 (UTC)

Same problem affects {{Convert to SVG and copy to Wikimedia Commons}}. —Scott5114↗ [EXACT CHANGE ONLY] 21:59, 12 May 2008 (UTC)

So is there a resolution to this? It seems a few people have agreed on David's option 3 above, which is fine by me. When I mass converted the license templates to use imbox I manually fixed the left images to all be 52px, so none of them should be affected. We can just doc that 52px is highly recommended and hope that most people stick to it. Oh, and as for those huge American flags on the right, I took care of that problem by shrinking flags for all nations to a reasonable size (and imposed a 100px limit on all other images). --CapitalR (talk) 04:09, 16 May 2008 (UTC)

Copy to Wikimedia Commons

What has happened to {{Copy to Wikimedia Commons}}? It is displaying in Ambox format when used outside the image namespace. I can't think of any cases where an Ambox-type version of this template would be needed. Kelly ^hi! 23:38, 15 May 2008 (UTC)

I can't either from the top of my head, but I imagine it has it's uses. There are more templates that use this trick. — Edokter • Talk • 23:46, 15 May 2008 (UTC)

There are quite a few galleries in mainspace that are tagged with this template. - AWeenieMan (talk) 23:47, 15 May 2008 (UTC)

Ah, that explains it. The only problem now is that it looks weird in lists and how-tos for imagespace templates in project and template space. Kelly ^hi! 00:01, 16 May 2008 (UTC)

Yeah, since it mostly will be used on image pages it is better if it has the default style as imbox, and only show ambox styles on article pages. So I changed it to that. Note that the template understands the "demospace" parameter so you can tell it which style to show when you show it in how-to guides etc. When you want to force it to show the ambox style:

{{Copy to Wikimedia Commons|demospace=main}}

And since the imbox style now is default, when you want to show the imbox style:

{{Copy to Wikimedia Commons}}

--David Göthberg (talk) 02:48, 16 May 2008 (UTC)

As always, David - great work, and thanks! Kelly ^hi! 03:52, 16 May 2008 (UTC)

PD template

Could someone with access to the tools please override the default border color on {{PD}} and change it from gray to red? This is to reflect that it is a deprecated license. Thanks! Kelly ^hi! 12:31, 14 May 2008 (UTC)

Do you have an example of an already decrapeated template converted to imbox with the right colors? — Edokter • Talk • 12:50, 14 May 2008 (UTC)

Tricky case. I see why you want to make it look different. If it is going to have a warning colour it should not be red, since red means the image is going to be deleted and that is not the case here. So perhaps a yellow or even an orange border. But then we are making a new box type and I don't like that. Instead I see two other solutions:

• We can make the warning text "This tag is deprecated!" more prominent by putting it on top of the box and with larger text style.
• We can even put a second yellow or orange warning box above it that tells "The below license is deprecated". Thus making it two boxes that gets transcluded together onto the image pages.

I don't know which is best, I'll make a sandbox for it and try both ways.

--David Göthberg (talk) 14:31, 14 May 2008 (UTC)

Yeah, I wasn't sure what to do. I need to go back and update some other license tags that have been deprecated also - {{PD-Russia}} and {{PD-LOC}} are two that come to mind. Those boxes also need to have their icons changed to the "PD-maybe" one. Kelly ^hi! 14:36, 14 May 2008 (UTC)

I made two alternatives over at Template:PD/sandbox, take a look. I don't know if the warning box should be above or below the license box in the second example, but I think both above and below works so doesn't matter much. I prefer the example with double boxes, it looks cleaner to me.

--David Göthberg (talk) 15:01, 14 May 2008 (UTC)

I added two 'nested' alternatives... — Edokter • Talk • 15:17, 14 May 2008 (UTC)

I added some margins to the inner boxes in the nested alternatives and then they actually look pretty good. Of the nested alternatives I prefer the second one. I am not sure if I prefer the double box alternative or the second nested alternative. (Without margins I would not want the nested alternatives at all.)

--David Göthberg (talk) 15:38, 14 May 2008 (UTC)

Good work drawing up those alternatives. I like the same two as you, but I prefer the "double box alternative" slightly more than "nesting alternative 2". I'm happy either way though. --CapitalR (talk) 15:50, 14 May 2008 (UTC)

Same here - please hold off on making the update until later, though - there's some changes to the template verbiage that need to be made also, and it might as well all be in one edit. I'm pressed for time at the moment, but will make the change and drop a note here. Kelly ^hi! 15:57, 14 May 2008 (UTC)

I'm not quite fond of the double-box version, because it isn't clear the decrapated massage would apply to the licence box. — Edokter • Talk • 16:02, 14 May 2008 (UTC)

I listed an alternative as "Nested alternative 2 with needed verbiage change", but the change was to include a notice at the end that the license should not be considered valid if used after a cutoff date. Please include this in whatever version is selected, thanks! Kelly ^hi! 16:54, 14 May 2008 (UTC)

Yes, a cutoff date like that probably is right.

I think that in a way the nested alternative 2 is the most logical. That is, it is a license tag that is placed on the image pages. Then that license tag itself is tagged with an orange warning tag.

But it looks slightly crowded, so the double box alternative looks cleaner. And the nested alternatives use a code hack that might cause problems in the future if the imbox code is changed. And that code hack will probably be pretty confusing to other editors who don't know how imbox works internally. So the double box alternative is simpler more robust code. So for those reasons I now prefer the double box alternative.

--David Göthberg (talk) 18:15, 14 May 2008 (UTC)

I've made 'Nested alternative 3'. I'm useless at coding so it looks slightly sloppy but...... Dendodge .. Talk^Help 18:43, 14 May 2008 (UTC)

Ideally, I'd like the triangle to be half way down the bit about it being depreciated but I can't do that so...... Dendodge .. Talk^Help 18:49, 14 May 2008 (UTC)

Imbox is not likely to change in a way that breaks the 'hack'; it's simply a new table cell. So I much prefer the nested 2 version. We could loose the hack, meaning the inner box shifts to the right... I still think having two seperate boxes is confusing. — Edokter • Talk • 10:21, 15 May 2008 (UTC)

PS. I've made my examples collapsible. Thoughts? — Edokter • Talk • 13:31, 15 May 2008 (UTC)

I like the collapsibility, I'd try it out on nested 3 but, even thought it looks simple, I can't seem to get it right...... Dendodge .. Talk^Help 15:49, 15 May 2008 (UTC)

Those boxes are going on image pages, not articles. I see no reason to have them collapsible. I don't think we should hide any data about the images and their licenses. And that hides the info about that images that are uploaded after a certain date and that use that license might be deleted.

And the nested alternatives are already broken. I added some code to {{PD/sandbox}} to show one of the cases when it breaks. But sure, that case can be fixed by adding some more code to those examples. See why I prefer to avoid hand coded special solutions on individual message boxes? Sorry to be so negativistic, but I don't like the thought of having to search for and fix lots of templates when we discover more breaks.

--David Göthberg (talk) 16:15, 15 May 2008 (UTC)

It's not broken; it's because imbox still uses inline CSS instead of the CSS in common.css. As for the hidden information; the important part is still visible, only the extra info is hidden but easily reachable. But of course, collpasibility part is optional, and not everyting has to be hidden. — Edokter • Talk • 18:42, 15 May 2008 (UTC)

I've made Nested and collapsible alternative 3, slightly rearranged, which makes the warning more prominent and explains the purpose of the 'show' button. It also gets rid of that ugly whitepace...... Dendodge .. Talk^Help 19:28, 15 May 2008 (UTC)

(unindent) I saw no ugly whitespace. However, I'm not a fan of alt three, becuase it is a bit of a kludge codewise (in that I share David's concern). Alt 2 is still my choice because the licence box should be the main box, instead of the warning box (as in alt 1), which could be mistaken to apply to the whole page. — Edokter • Talk • 20:49, 15 May 2008 (UTC)

Also, another malfunction has seemingly cropped up, maybe related to {{image other}}...images with this tag should be included in Category:PD tag needs updating, but they're not for some strange reason. Kelly ^hi! 05:09, 16 May 2008 (UTC)

I think I just took care of the problem...when I initially converted it to imbox I had accidentally put in an extra pipe in the {{image other}} template call which prevented the category from working properly. Should be fixed now. --CapitalR (talk) 05:16, 16 May 2008 (UTC)

CapitalR: I took a look at your edits to {{PD}}, and yes, you are now using {{image other}} in the right way.

I am almost starting to think the interface and the naming for {{image other}} is not enough "talkative", since people are mixing it up pretty often. Or perhaps this is just a learning period? I have made a more talkative (and way more versatile) variant, but I think that one will cause other kinds of usage mistakes instead: {{namespace detect}}.

--David Göthberg (talk) 15:55, 16 May 2008 (UTC)

Middleman template

I like nested-2, as seems to be popular above. The concerns about the awkward 'hack' code required are valid, but I see this as an opportunity for further standardisation. Let's create a {{deprecated license}} midleman template as a framework for these more complicated imboxes; I'm sure we're all aware of the familiar list of advantages of centralising code like this: consistent fomatting, ease of maintenance, and a quick-and-dirty way of finding deprecated licenses through WhatLinksHere. Plus, we can make the code as complicated as necessary, knowing that it only has to be done once. Happy‑melon 08:11, 16 May 2008 (UTC)

I like that idea! In fact, it's now demonstrated in the Nested 2 example. — Edokter • Talk • 13:54, 16 May 2008 (UTC)

I've used {{Deprecated license PD}} instead, as other non-PD decrapated licences may have other text. — Edokter • Talk • 14:06, 16 May 2008 (UTC)

I am probably late for the party, but it matters little, because, as it stands now, "Nested and collapsible alternative 2" is my choice of preference. It looks nice and conveys the desired message well.

Quick question: is middleman template a template to be used in the templates? Just to make sure I (and perhaps other readers with little template experience) understand. Waltham, The Duke of 21:19, 16 May 2008 (UTC)

Yes: {{PD}} will call {{Deprecated license PD}}, which will in turn call {{imbox}} with the necessary styling hacks. Happy‑melon 21:29, 16 May 2008 (UTC)

Ok, I've created {{deprecated license}} based on the nested-2 style, and added a new example to Template:PD/sandbox to demonstrate it. What do you think? Happy‑melon 21:39, 16 May 2008 (UTC)

I already had a middleman template ready ({{Deprecated license PD}}), geared towards PD licences. I think that's more convenient then using a blanket template, requiring to pass the text from every parent template. — Edokter • Talk • 21:41, 16 May 2008 (UTC)

They're slightly different principles, though - yours is more a bolt-on extension to 'existing' templates, wheras mine is more a general framework. I'm not entirely sure which system is better. Happy‑melon 22:15, 16 May 2008 (UTC)

Well, obviously, I prefer mine :) Kidding aside; use of the middle-man solution should have a minimum impact on the licence tag itself. Your solution completely replaces the original code, while mine is indeed a 'bolt-on'. My solution also centralizes the decrapated message text used (though one does wonder how many decrapated PD licences are there), and can have different version as seen by the red links on my template. I think it is simply the more elegant solution. — Edokter • Talk • 22:26, 16 May 2008 (UTC)

I think which solution is better is rather dependent on how many deprecated license templates there are, and how many have the same deprecation wording. If they're almost all the same, then yours is the more comprehensive and has maximum code-centralisation... but if most of the deprecated licenses need their own deprecation wording, then a more general template would be better. Perhaps a more "elegant" solution still would be to have {{deprecated license PD}} call {{deprecated license}}, which we could convert to just incorporate the hack for the nested imboxes, and the 'standard' features of the inner box (the css class, image and general layout - rather like the bottom part of {{deprecated license}}'s current code). That achieves the best of both worlds - all code and text is centralised at one level or another, and is easy to use at each stage, the functionality of each template remains broadly the same. Then again, that would leave us with a chain of four templates just to get one deprecated license to display nicely :D... I think I need to sleep on it. Happy‑melon 22:34, 16 May 2008 (UTC)

<undent>I deal a lot with image licenses...there are not many deprecated templates, most get cleaned up fairly quickly. After {{PD}}, which has about 10,000 usages and will take a long time to clean up, the next most common deprecated license is {{PD-Russia}}, with somewhere under 1000 usages. The verbiage on PD-Russia is somewhat different from {{PD}}. After that, I think the next most commons was {{PD-LOC}} - it was used on several hundred images but I finally finished cleaning that up after a n effort of several weeks and nominated the license for deletion. Kelly ^hi! 00:57, 17 May 2008 (UTC)

In that light, I say keep it simple. These's no need for multiple nested templates when one will suffice, and even that isn't even realy necessary, just conveniant. — Edokter • Talk • 08:47, 17 May 2008 (UTC)

Go with {{deprecated license PD}} then - seems mine is designed for a class of templates that doesn't actually exist :D... Happy‑melon 10:44, 17 May 2008 (UTC)

Updated

I was bold and updated {{PD}} with the nested 2 version using {{deprecated license PD}}. Shall I update {{PD-Russia}} in teh same way? — Edokter • Talk • 11:48, 17 May 2008 (UTC)

Looks good! Yes, also please do PD-Russia in the same way. Kelly ^hi! 15:21, 17 May 2008 (UTC)

Done. The imageright= threw me off for a bit, but I managed to fix that. — Edokter • Talk • 16:25, 17 May 2008 (UTC)

There is now a general nesting template at {{Imbox nested}}. — Edokter • Talk • 17:27, 23 May 2008 (UTC)

di-no license

The protected template {{Di-no license}} requires conversion by an admin. Kelly ^hi! 19:57, 18 May 2008 (UTC)

Converted by Edokter. Nihiltres^{t.l} 03:08, 19 May 2008 (UTC)

Deploying!

I see that some of you have already started deploying this template. And it seems we have a fairly good consensus on the functions and looks of this template.

Special:MostLinkedTemplates is only updated about once every second day or so. So while waiting for proper stats I have done a rough calculation of how many pages now use {{imbox}} based on some other sources. It seems imbox already is used on at least 277,000 pages! That means it is already the 18th most used template.

So can we say we are now officially deploying this template?

--David Göthberg (talk) 14:42, 11 May 2008 (UTC)

I think it's safe to say that :) — Edokter • Talk • 14:50, 11 May 2008 (UTC)

Imbox is now used on at least 345,000 pages and thus is the 14:th most used template, right after ambox. So it is perhaps a bit late, but since I have wanted to say this for a long time:

Ladies and gentlemen, fire up your browsers and start converting image message boxes!

--David Göthberg (talk) 22:06, 11 May 2008 (UTC)

The official stats from Special:MostLinkedTemplates now says that {{imbox}} is used on 752,000 pages, which makes it the 4th most used template. Good work people!

--David Göthberg (talk) 16:17, 13 May 2008 (UTC)

We beat {{ambox}}?? I wasn't expecting that! Given that according to Special:Statistics we only have ~783,000 media files, that means we've hit over 96% of the image namespace. It will be interesting to see how those numbers line up: doing an intersection of Special:Allpages/Image: and not Special:Whatlinkshere/Template:Imbox would be a quick way of flagging unlicensed images, images with wierd or substituted templates, and general rubbish we need to clean out. Happy‑melon 17:37, 13 May 2008 (UTC)

Haha, yeah, such high numbers that quick kind of feels weird. But now that I have a better understanding of this I think we might actually reach more than "100%". That is, since Special:Statistics says "we currently have 783,069 media files (excluding files from the Wikimedia Commons)". But we know that also some of the files from Commons do have image pages here with message boxes on. So just 100% would indicate that many pages need to be handled the way you described.

Kelly: Now you can brag about that a template you started is the 4th most used on Wikipedia! :))

--David Göthberg (talk) 19:24, 13 May 2008 (UTC)

I can't brag - you guys did all the work, I just thought of the name. :) I am happy with how smoothly everything has gone so far (at least from my perspective). Kelly ^hi! 20:04, 13 May 2008 (UTC)

Just noticed that Special:MostLinkedTemplates says imbox is used on 789,619 pages, and Special:Statistics says there are 786,907 media files, so we now have 100,34 % coverage. Which sounds about right. :))

--David Göthberg (talk) 06:03, 26 May 2008 (UTC)

Have you forgotten how to count? 100.34% is severely inadequate. Unless coverage reaches 121.7698513%, all the trouble we've been through is wasted effort. What a disappointment, really... Waltham, The Duke of 06:51, 26 May 2008 (UTC)

"File from commons" box

One of the candidates is the "This is a file from Commons..." box. It is not a template however, but I can't find it anywhere. OK, it's here. Should this message be made to look like Imbox too? — Edokter • Talk • 23:04, 11 May 2008 (UTC)

That was discussed somewhere recently, I clearly remember the discussion. But I can not find the discussion. (Not joking.) Anyway, the comments were that MediaWiki:Sharedupload is a system message and should not be changed. Besides if it should be changed it probably should match the commons boxes instead since it will be shown together with them.

--David Göthberg (talk) 00:24, 12 May 2008 (UTC)

Creative Commons licenses

I noticed that the Creative Commons license templates have not yet been updated (most are protected). Was there a technical issue with image size? I can't remember. Kelly ^hi! 15:22, 17 May 2008 (UTC)

Yes, the image is restricted to max 52px, and the "Some rights reserved" image is wider then that. I think the discussion was archived. — Edokter • Talk • 15:53, 17 May 2008 (UTC)

Ugh. I have no idea how to solve this other than moving the image to the right, which is inconsistent with other licenses. Are we going to need a special template for these licenses? Kelly ^hi! 16:33, 17 May 2008 (UTC)

We were concidering an additional parameter (wideimage=yes ?) to accomodate for these images, but some felt this as feature creep. I don't know... there should be a way around it. We should pick one and sandbox it. — Edokter • Talk • 16:54, 17 May 2008 (UTC)

In my opinion, it's one area that does justify an additional feature. It's not creep if we genuinely need it for consistency, and I'd say that it'd be both consistent with the left-image style we've been using and the old template's good-looking setup. Nihiltres^{t.l} 17:45, 17 May 2008 (UTC)

I may have a solution; not setting a div widht at all, accomplished by using bigimage = yes. But I don't have firefox at hand. Can someone look at Template:Imbox/sandbox#Examples of varying width and see if the text overlaps the big CC logo? (Also look at the big book icons above that.) If not, we have a solution. — Edokter • Talk • 18:07, 17 May 2008 (UTC)

Looks fine for me in Firefox, and I think I have the latest version. Kelly ^hi! 18:12, 17 May 2008 (UTC)

Looks fine in Safari 3.1.1 on Mac OS 10.4.11. Nihiltres^{t.l} 16:35, 18 May 2008 (UTC)

Everything on that page looks good on IE7/XP. I think here we can indeed justify a new parameter. Happy‑melon 17:10, 18 May 2008 (UTC)

OK, I've put it in. Now we can start converting the CC licences. Just put in bigimage = yes if the template has images wider then 52px. — Edokter • Talk • 18:27, 18 May 2008 (UTC)

Does this affect the changes David G made to Mediawiki? Kelly ^hi! 18:28, 18 May 2008 (UTC)

What changes? I've already done a couple from your list, and I see no adverse effects. — Edokter • Talk • 19:08, 18 May 2008 (UTC)

Sorry I'm not real savvy on Mediwiki jss stuff, but David G put the imbox code there a few days ago and I was just wondering if subsequent changes would have an impact on that. If I'm off the reservation then excuse my ramblings. :) Kelly ^hi! 19:12, 18 May 2008 (UTC)

Ah, Common.css. No, that won't interfere. — Edokter • Talk • 20:23, 18 May 2008 (UTC)

Ouch. I go out dancing for two nights and you guys rush ahead and add new parameters to imbox. We already had a simple and robust solution that doesn't need any new parameters. Look at suggestion 3 in the section Left image cell width above, which by the way have not been archived yet. The reason I waited to add that solution was that I wanted more responses/discussion before we do any changes to imbox.

I don't like the new "bigimage" parameter since it adds complexity, and worse is that in some web browsers the need for it is not visible at all so many editors will probably not bother to use the parameter when needed.

So, let me ask this again: Do we need to have the left side of the text in the boxes line up when we stack them, or can we allow them to always adapt to the image sizes thus being able to handle any sized images? (Then not needing any extra parameter like "bigimage".)

--David Göthberg (talk) 06:35, 19 May 2008 (UTC)

Arrrgh! Me did feature creep :S !! Lol... Yes, you're right, we had practically agreed to do away with the div entirely. Happy‑melon 07:46, 19 May 2008 (UTC)

I don't know, it didn't get that much support. Loosing the div (or just the width) will cause the smaller image to be squeezed all the way to the left unles we use generous padding. But yeah, that could be another solution. Asuming the smallest image would be 40px, we should use 6px padding left and right. In short, replace width: 52px; with padding: 0 6px;. — Edokter • Talk • 13:25, 19 May 2008 (UTC)

OK, see the sandbox. — Edokter • Talk • 13:31, 19 May 2008 (UTC)

Right, if we drop the demand for fixed width for the left image cell then we should remove the div and use more padding for the left image cell. Just like we do for the right image cell now. There is no need for the div to cause the padding. I intend to use a total of about 0.8em padding on both sides of the image in the image cell. But not in the way you right now are showing in the sandbox. And some other code fixes are needed to accomodate this for all usage cases. (Especially when no image is used.) So PLEASE do not rush away and change imbox again, okay? Remember, each time we change imbox 753,000 pages have to be re-rendered.

I have a bigger plan with this: I want to keep ambox, imbox and cmbox parameter-compatible. Since I intend to make compatible standardised message boxes for talkpages and for "other space", thus covering all namespaces. Because then we can make an ambox compatible "multibox" that can detect what namespace it is in and change appearance accordingly. The multibox should of course only be used for templates that are intended to be used in several namespaces.

So the question still stands: Do we need to have the left side of the text in the boxes line up when we stack them, or can we allow them to always adapt to the image sizes thus being able to handle any sized images? (Then not needing any extra parameter like "bigimage".) —Preceding unsigned comment added by Davidgothberg (talk • contribs)

Just one question... why loose the div? Becasue like you said yourself: noimage will cause padding problems (due to cell-padding). Why not leave the div in, and have it handle padding? noimage = no div. Oh, And I prefer to use 6px for padding, as that corresponds most closely to ambox (52-40). — Edokter • Talk • 18:57, 19 May 2008 (UTC)

And to answer your question... It is simply not possible to line up stacked templates and use images over 52px at the same time, unless we statically set it wider (ie 96px), which in turn may look bad with small images. The way the table is built (to ensure 80% width at all times) prevents us from doing that. I can live with non-aligning text, as that will provide the most flexibility with regards to the image cell. — Edokter • Talk • 19:04, 19 May 2008 (UTC)

Break, image size and divs

Edokter: Well, because I know how to do it better without the div. The way I have in mind (and that we have already tested in the sandbox before) will cause less code and will make it simple to instead fully skin the padding from the CSS classes. And what I meant about the noimage case is that it needs some modification of the code that I would like to add at the same time, but I know how to do that, so no worries. (And I will of course code it up and show it in the sandbox again, before we deploy it.) The noimage case already does have the wrong left margin in ambox, cmbox and imbox, and the div does not fix that.

Just like you I usually prefer to specify padding in pixels, not ems. But back when we made the ambox the "CSS experts" preferred ems, one of their reasons was that ems work better on odd screens like handhelds and in other special situations. (And please, I don't want to spend a page of text explaining why that is so.)

I know how to code the different approaches better than the current code. What I do need is that people answer the question about which functionality we should have, and I have asked that repetedly above. Since I prefer to have consensus before I do changes to widely used templates like this.

Edokter: You are correct that we can not have the text line up for large images, but you are misunderstanding my question.

So I repeat, and this question is for everybody: The question is if we should continue to line up the text for the small images but then having the trouble with extra parameters for the large images? Or if we instead should treat small images the same way as large images and let the text adapt to them too, thus making things very simple?

--David Göthberg (talk) 19:57, 19 May 2008 (UTC)

To answer that: I prefer the simple way (remove bigimage and let the images size themselves). — Edokter • Talk • 20:02, 19 May 2008 (UTC)

I also prefer the simpler method of letting images size themselves and getting rid of the extra parameters. We should also prominently doc that images should be set to 52px whenever possible. --CapitalR (talk) 20:14, 19 May 2008 (UTC)

Agree with CapitalR: leave instructions to standardise where possible, but leave the technical means to use whatever size image is necessary. Happy‑melon 08:57, 20 May 2008 (UTC)

Hah, I just had a flash of insight. We can use a *transparent* image with background of default imbox background set to 0% opacity, automatically set to the right size, to mimic the normal indentation for image=none. That way we get pretty text indenting, without an image appearing, without messing up the big image workaround stuff. Nihiltres^{t.l} 20:23, 20 May 2008 (UTC)

Nihiltres: Haha, you are too image centric. I assume you did not mean "image=none" but rather "image=blank", right? And instead of using a blank image for that case I think it is better to simply insert a div for that specific case. Although now that the image cell width will vary then "image=blank" will be even less meaningful than before.

CapitalR: I agree, 40px images are a bit small for the image message boxes since they usually have more text than article message boxes. So we should perhaps recommend about 50px. That is the same size that was standardised for talk page message boxes long ago: Wikipedia:Talk page templates.

--David Göthberg (talk) 04:01, 22 May 2008 (UTC)

I thought we purposfully did not implement the "image = blank" feature? — Edokter • Talk • 10:34, 22 May 2008 (UTC)

David, yeah, good point – though I had thought we were perhaps almost doing away with the div, but I've probably just gotten some of the hypotheticals here confused. Just setting the width of the padding-div on the case of image=none or, as it may be, image=blank would be quite effective. Nihiltres^{t.l} 14:23, 22 May 2008 (UTC)

Break, new code

Correction: Gah! It is confusing to have so many different mboxes. Yet another reason to not have too many different types of them...

Edokter is right, the {{imbox}} does not have the "image=blank" option. Only {{ambox}} has it. So for {{imbox}} we now don't need any div at all, since "image=none" never used a div.

--David Göthberg (talk) 01:33, 23 May 2008 (UTC)

I have now coded up an imbox version without the div and that doesn't need the "bigimage" parameter. To make it look good I had to increase the padding in the code somewhat.

The new version has some changes in the code for the "image=none" case since the left side padding got too large for that case. The old code kept the padding in the left cell even in the "image=none" case, thus adding that to the text's own left side padding. So the change is really a fix of a bug in the old code.

Just to try it out I also added a "below" parameter since there have been several cases suggested when such a parameter would be useful. See forinstance sections Deploying on non-free licence tags and PD template above. Having the below parameter a part of the imbox code makes the nested message box a cleaner case that works well even when different combinations of left and right side images are used. I used the same padding for the below area as in the text cell, since that feels most logical. We of course have to discuss if we should have the "below" parameter.

The new imbox code version with examples is available at {{imbox/test1}}.

I especially want to know if the example box that only contains the text "No type and image=none" has the same width as the other boxes when viewed with Safari and with recent versions of Internet Explorer? (The new code revealed that the "empty" cell must have some width or content like at least a 1px padding, otherwise the whole message box shrinks to fit the text in several browsers.)

--David Göthberg (talk) 02:01, 23 May 2008 (UTC)

If below= is mainly going to be used for nested imboxes, you might want to check out {{Imbox nested}}; that way you can save on yet another parameter. — Edokter • Talk • 18:15, 24 May 2008 (UTC)

Edokter: I have looked at {{imbox nested}}, that one uses broken code. You can not use a fixed "colspan=3" like that since if there is no right side image then imbox only has two columns and that means in some browsers a third (sometimes very visible) empty cell will be added to the first row. I see you have made the same error in several other places, and you have edited my suggested code at {{imbox/test1}} to have the same error. Please do not change the code I suggest in a special subpage that states so. If you want to experiment or suggest other code then use {{imbox/sandbox}} or why not make a {{imbox/test2}}?

I have tried to avoid saying this, but it seems I have no choice: It is time I am very frank with you Edokter: Many of the edits you do to imbox and related templates break things. You don't seem to understand the details here. A minor example is that you removed "width: 100%;" from the below cell in my suggested code at {{imbox/test1}}. If you had bothered to read my edit comments in the history of that page you would have seen that the reason that cell has "width: 100%;" is that I intend to use the CSS class "imbox-text" also for the below cell. And thus it will have "width: 100%;". I use the same hard coded styles now as we are going to have in the CSS classes so we can see now if the classes will work or not.

Please do not change code you don't understand. Lately I have had to spend most of my time here explaining things to you and repairing things you have damaged instead of doing productive coding. That is very frustrating. Often the things you ask about or misunderstand have already been explained in sections further up on the same talk pages or in the edit comments of the templates. PLEASE, start to read things first, read the talk pages, read the edit comments, then take some time to think. Realise and accept that there is much more to these things than you currently understand. So read, think and ask, instead of just do.

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

Since no one has responded about the new code (apart from the below parameter that was the least important of the changes) I have deployed the "image=none" fix to {{cmbox}} instead, to get some real world testing of it. But that doesn't test the rest of the new left side image handling.

I still would like to know if anyone has any comments on the new code at {{imbox/test1}} before I deploy it? Or should I just deploy it? (I won't deploy the below parameter since that one probably needs further discussion.) I still want to know if the example box that only contains the text "No type and image=none" has the same width as the other boxes when viewed with Safari and with recent versions of Internet Explorer?

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

Looks fine on IE7. Happy‑melon 17:09, 25 May 2008 (UTC)

David, Wikipedia is supposed to be a collaborative project; If you cannot tolerate others working with you, then I shall leave this project well alone. I fully understand all the code involved; do not asume that I am some amature. If I made an error, rervert it, but please do not make me out to be a code-breaker out to destroy your work. My only goal is to get as clean code, with as least ambiguous code as possible. In fact, here's a tip: don't use inline CSS at all, as that only hampers development. Instead, put the CSS in your monobook, or put it in a subpage and import that into your monobook. That way, these kind of frustrations will be cut entirely. — Edokter • Talk • 16:29, 25 May 2008 (UTC)

That would limit the people able to make constructive appraisals of the new code to those on-the-ball enough to add the necessary code to their monobook, and raise the possibility of people erroneously reporting problems with the sandboxes that are actually just due to them not having the right CSS; we'd have to respond to every comment with "have you imported the CSS?", which would get annoying very quickly. Happy‑melon 17:09, 25 May 2008 (UTC)

Fair point, but it worked pretty well with the navbox overhaul. It had a prominent message in the sandbox about the needed CSS, keeping inqueries virtually absent. — Edokter • Talk • 18:48, 25 May 2008 (UTC)

Yes Edokter, I should perhaps have explained better what I meant: I know that you are a very skilled template coder and that you know a lot about about HTML and CSS coding. And you seem to be smart. So I do value your knowledge and input. But you tend to rush away doing things or saying/asking things seemingly without thinking first and without reading what has been said on the same talk page and in the edit comments.

And you just made a splendid example of that in your comment, since we have several times discussed on these talk pages why we currently use inline CSS for this template instead of using CSS classes in MediaWiki:Common.css. The inline CSS is just temporary while we test and deploy. So we don't have to wait 30 days for each change we deploy. Using CSS in MediaWiki:Common.css really mostly has the benefits that things can be skinned and CSS styling can be modified/fixed centrally, and without causing server load. But for a new meta-template where we still are changing the non-CSS code pretty often those benefits are anyway not useful. Actually, it is still less than 30 days since the first version of the CSS classes for imbox were added to MediaWiki:Common.css and those classes are already wrong if/when we add the improvements we have been discussing lately, thus we will have to wait yet another 30 days before we can use those CSS classes.

And the navbox case is different. There already were a working navbox that people could use while waiting 30 days for the next version. This imbox case is instead like when we deployed the ambox: A new meta-template that many people wanted to deploy, preferably "yesterday". People were so enthusiastic that they started to deploy the ambox immediately without waiting the 30 days and there were no stopping them (short of blocking them all, but blocking enthusiasts like that would be bad). And that caused a lot of problems since the new CSS classes were not yet loaded in many reader's web browsers. So for imbox and cmbox instead we catered to that enthusiasm by using inline CSS so people could start deploying immediately. And as you perhaps have seen, editors who haven't even taken part in the discussions on these talk pages and that don't even respond to messages on their talk pages have converted lots of image message boxes to use imbox.

--David Göthberg (talk) 22:00, 25 May 2008 (UTC)