Wikipedia:Templates for discussion/Log/2011 July 2

July 2 edit

Template:Infobox Babylon 5 character edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Substitute and delete. Ruslik_Zero 16:29, 10 July 2011 (UTC)[reply]

Template:Infobox Babylon 5 character (talk · history · transclusions · logs · subpages)

With the exception of the in-universe trivia, which can be removed, this is redundant to {{infobox character}}. Chris Cunningham (user:thumperward) - talk 21:02, 2 July 2011 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:GLAM Article edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was No consensus. I believe relisting will not help. NAC. Fleet Command (talk) 07:46, 16 July 2011 (UTC)[reply]

Template:GLAM Article (talk · history · transclusions · logs · subpages)

Unused; looks like test code that was never deployed. Chris Cunningham (user:thumperward) - talk 19:55, 2 July 2011 (UTC)[reply]

  • Comment: This template was used for a number of sandboxes that were later made live. It is incorporated into this guide which will be adapted and used again in the future. I'd appreciate if it wasn't deleted so I don't have to remake it at a later date. LoriLee (talk) 20:02, 2 July 2011 (UTC)[reply]
    • Could the content be reformatted for copy-paste and moved out of the template namespace? Using substituted templates for article skeletons is probably not a good idea, not least because it means the page has to actually be saved before the details can be filled in properly. Chris Cunningham (user:thumperward) - talk 20:07, 2 July 2011 (UTC)[reply]
      • Not trying to be difficult, but I'm interested in what the actual issue is with having suggested article formats as substituted templates. Is this a policy somewhere? I'm willing to hear out your reasoning for having to save the page first. But why is this a problem in a sandbox? I just ask because I've found such templates to be extremely useful on multiple occasions in guides I've created. The newbie Wikipedians that use them find them very helpful. LoriLee (talk) 17:22, 3 July 2011 (UTC)[reply]
        • I actually thought we did have a guideline which discouraged the use of skeleton-article templates, but it doesn't look like we do. My main concern is that this is in templatespace and doesn't have any directly associated documentated which explains what it does; I noticed it when it showed up in category:infobox templates with no data rows (designed to catch incorrect use of infobox templates). If anyone has any suggestions on a clean way to work around that then I'm all ears. Chris Cunningham (user:thumperward) - talk 08:38, 4 July 2011 (UTC)[reply]
      • There are many substitution preload templates in templatespace. The article wizards use such templates, for instance. 65.93.15.213 (talk) 04:51, 5 July 2011 (UTC)[reply]
  • I too think going in this direction for articles is a step forward, to increase uniformity of presentation and assist new editors. It is more adaptable and more controllable than doing things by copy-paste, a technique which really should be deprecated whenever there is a good alternative. DGG ( talk ) 21:41, 3 July 2011 (UTC)[reply]
  • Comment: Obviously it wouldn't have any transclusions because... this kind of thing is intended for substitution. —Tom Morris (talk) 15:28, 4 July 2011 (UTC)[reply]
  • Comment why would a substitution preload template have transclusions? 65.93.15.213 (talk) 04:51, 5 July 2011 (UTC)[reply]
  • Keep - subst'ed skeleton article templates are a good thing. Un-subst'ed ones are not (as things stand). Rich Farmbrough, 10:34, 6 July 2011 (UTC).[reply]
  • Delete. This is not the right direction. Using templates for writing articles will not encourage proper writing skills, but just "filling-in-the-blanks" approach, just like infoboxes make up most of the info for a lot of articles. -- P 1 9 9 • TALK 14:06, 9 July 2011 (UTC)[reply]
  • Move. Template space is for pages that are meant either for transclusion or for substing, and this isn't meant for either one. However, this looks like a useful page; it should be moved to being a subpage of WP:GLAM or moved into the userspace of someone who uses it frequently. Nyttend (talk) 23:10, 15 July 2011 (UTC)[reply]
  • Okay, I just realised that it is meant for substing. Since that's the case, Keep as a good example of a useful template. Nyttend (talk) 23:13, 15 July 2011 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:Subject bar edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Keep. No consensus for deletion. NAC. Fleet Command (talk) 15:48, 13 July 2011 (UTC)[reply]

Template:Subject bar (talk · history · transclusions · logs · subpages)

Little-used variant of the existing sisterlinks system which causes inconsistency, requires editors to have to decide to use one or the other, and places portals in the wrong section (they should be in the see also section, not in a footer). Chris Cunningham (user:thumperward) - talk 18:46, 2 July 2011 (UTC)[reply]

  • Comment. I don't like the "floating right" portals (they look junky). I like inline, on the left, like "all the rest of the See Also" content. I think at the end, with the categories and heirarchy templates is not bad either. In other words, I don't see that we have completely figured out great rules, that work, and should never be modded. That said, I'm kinda suspicious of this template and not liking the clunkiness of it's look. And not crazy about it being dropped into articles by the template makers, when they did not work on the article and it...looks clunky. However, really, I would be fine with portals and the almost default Commons link going to the end with the cats and other template like thingies. (They are different type of content than a specific article). Sorry for the TLDR explanation, but I guess what I'm saying is I don't like the template OR Chris's reasoning. I guess I would vote keep so that at least we have and test options for content organization (we DON'T have it all nailed down well, yet). That said, please keep that clunky thing OUT of "my" articles.  ;-) TCO (talk) 19:28, 2 July 2011 (UTC)[reply]
    • I'm not opposed to wider discussion of changing the way we format these things; the sisterlinks system has come a long way since it was first devised. However, the correct way to get that changed would be to make a central proposal and make a mass-move to the new layout (updating the MoS and such along the way). Simply inventing a new system and adding it to random articles is absolutely the wrong way to do it. It took a long time to sort out the mishmash of ways people added these things once upon a time. Chris Cunningham (user:thumperward) - talk 19:59, 2 July 2011 (UTC)[reply]
      • Disagree. I think this is normal allowed variation.TCO (talk) 21:15, 2 July 2011 (UTC)[reply]
  • Keep Sometimes, the footer is the best place for a portal link. Some articles are so comprehensive, a "See also" section is redundant and removed, leaving no place for portals. These typically get shunted to the external links section, which is unhelpful if they are not clearly segmented from external links. This template effectively does that.--Cast (talk) 21:56, 2 July 2011 (UTC)[reply]
    If there are no other see alsos then prepending the portal template with ":" will bring it to the right. Rich Farmbrough, 10:39, 6 July 2011 (UTC).[reply]
  • Keep Admittedly, I'm the creator of the template, but my reasons for creating it are posted on the template's talk page. I have yet to receive a reply. The template was also discussed at the Village Pump, so look it up if you want. Also, I don't recall ever placing this template in other people's articles (*cough* WP:OWN *cough*). I use it only in my articles, which have passed WP:FAC with the template in place. If people like it, they can use it. But for now, we are being far from consistent in handling this stuff, as well as nav templates and white space issues. – VisionHolder « talk » 22:47, 2 July 2011 (UTC)[reply]
  • Keep, this template is an excellent way to group portals, books and Wikimedia links together horizontally rather than vertically. --Gyrobo (talk) 21:29, 3 July 2011 (UTC)[reply]
  • Keep or Merge into a centralized easy to use template. I really do not like floating portals and whatnot. Horizontal or inline is far far better in terms of scaling. This is especially apparent for me because I have dual monitors of different aspect ratios - a common 4:3 and a widescreen 16:9. Floating portals result in very unpredictable behaviors when I switch between different screens. (Same reasoning as per below nomination of {{Portal bar}})-- ObsidinSoul 16:10, 5 July 2011 (UTC)[reply]
  • Keep this looks so much better then the alternative. I have used it several times and it looks more professional then the right hand boxes --Guerillero | My Talk 21:02, 9 July 2011 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:Portal-inline edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Keep. No consensus for delete. However, there seems to be a consensus that using this template solves some layout problems. NAC Fleet Command (talk) 15:52, 13 July 2011 (UTC)[reply]

Template:Portal-inline (talk · history · transclusions · logs · subpages)

Little-used portal variant. Any minor wins in article layout on very short articles are contrary to the problems with inconsistency (not to mention WP:MOSICON) introduced by having several ways to lay out the same information. Chris Cunningham (user:thumperward) - talk 18:42, 2 July 2011 (UTC)[reply]

  • Keep. Inline looks much better. I use it. The floating right looks like crap. TCO (talk) 19:29, 2 July 2011 (UTC)[reply]
    • If the alternative is better in general then there should be central discussion to get the default changes, rather than someone starting a brand new style and then deploying it piecemeal (which simply confuses both readers and editors). Chris Cunningham (user:thumperward) - talk 19:57, 2 July 2011 (UTC)[reply]
      • I do not think we have converged to a one way or the other. And I certainly think using deletion of the alternative is capricious. Instead discuss, debate, etc. the use of alternatives. Not take a template away that some minority chooses to use. Oh...and the portals look like crap floating on the right. (and they are really more like cats or nav templates than See also specific articles.  :-) TCO (talk) 21:18, 2 July 2011 (UTC)[reply]
        • That is because they are used, IMHO, far to widely. They should be used on key articles where the portal is an appropriate See also not on every article that is remotely related. Rich Farmbrough, 10:49, 6 July 2011 (UTC).[reply]
  • Keep or Merge I was not aware of this template, and I imagine many editors are also not or it would be in wider use. I certainly would like to use it more now, as I can think of several articles which would benefit from it off the top of my head. In my defense of Template:Portal bar, also nominated for deletion by this nominator, I suggested an alteration to the coding of Portal box which would offer alignments as "Left" and "Right" for a floating box, and "Bar" as a centered footer. I would now also suggest "in-line" which would alter the floating bar as a left aligned bullet-point list, effectively merging these templates.--Cast (talk) 21:55, 2 July 2011 (UTC)[reply]
  • Keep it is preferable to use the inline version when you want a see also to more than two portals. 65.94.47.63 (talk) 03:00, 3 July 2011 (UTC)[reply]
  • Keep. While currently seldom transcluded, this may be useful in some situations. Many articles, especially large ones, don't have a See also, in which case the {{Portal}}s are usually put at the External links section. This may not always work out, however, for instance when the section already has several boxes piled up on each other, gobbling up all space. In such cases, Portal-inline may be a neat solution. See Berlin#External_links for an example of this. Cheers, theFace 10:29, 3 July 2011 (UTC)[reply]
  • Keep. Same function as {{Commonscat-inline}} and other inline variants but more important: Prevent the article from getting disfigured. And while sister project templates site in the External Links section, portal templates sit in the See Also section and may disfigure the multicolumn References sections. Fleet Command (talk) 22:35, 3 July 2011 (UTC)[reply]
  • Keep I've used this sometimes. It keeps layout sane in articles which have lots of infoboxes and pictures etc. on the right hand side. And yeah, I too think inline is sometimes far better than floating (which makes them far less noticeable leading to people who keep adding galleries because they don't notice the commons floating box).-- ObsidinSoul 16:02, 5 July 2011 (UTC)[reply]
  • Delete I know this is a nice idea but far better is a simple bulleted wikilink.
  • Portal:Trains.
  • Like that. Rich Farmbrough, 10:49, 6 July 2011 (UTC).[reply]
    • No, it isn't. It is oversimple. Portal's icon should be displayed. Fleet Command (talk) 13:28, 6 July 2011 (UTC)[reply]
  • Keep, displaying the portal's icon serves as a visual metaphor, which a plain bulleted item cannot do. This is arguably an accessibility issue. --Gyrobo (talk) 22:51, 7 July 2011 (UTC)[reply]
  • Keep - Sometimes I use it also. It could be useful for layout, when necessary to have it inline as for the template:commonscat-inline. --Dэя-Бøяg 09:11, 13 July 2011 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:Portal bar edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Keep. The main consensus for keeping seems to be "I like it" but there is even less consensus for deletion. NAC. Fleet Command (talk) 15:56, 13 July 2011 (UTC)[reply]

Template:Portal bar (talk · history · transclusions · logs · subpages)

this is just a more distracting layout for {{portal box}}. It doesn't make sense to have two competing layouts for the same thing, especially when the right-floating version has been used exclusively for years now. Chris Cunningham (user:thumperward) - talk 18:36, 2 July 2011 (UTC)[reply]

  • Keep. Hate floating right portals. Consistency to something bad is the wrong consistency. Let's at least keep technical options.TCO (talk) 19:50, 2 July 2011 (UTC)[reply]
    • If the alternative is better in general then there should be central discussion to get the default changes, rather than someone starting a brand new style and then deploying it piecemeal (which simply confuses both readers and editors). Chris Cunningham (user:thumperward) - talk 19:56, 2 July 2011 (UTC)[reply]
      • Agree to disagree. I think people use the alternative and using a deletion is a capricious way to try to standardize.TCO (talk) 21:19, 2 July 2011 (UTC)[reply]
  • Keep or Merge Since discovering this template, I've been swapping in place for articles where the Portal box has been poorly employed. Serving as a floating box to the right of a See also section, some articles reference more portals than related articles, which means the box sprawls into the next section, effecting page layout for useful images and graphs. The Portal Bar effectively solves the problem. Deleting with no effective replacement standardizes a flawed design. An alternative to keeping would be to alter the coding so that an optional alignment setting would be "Left", "Right", and "Bar". This centralizes our template use while giving editors effective autonomy to cater the Portal box for an article's specific needs. --Cast (talk) 21:42, 2 July 2011 (UTC)[reply]
Use the {{Clear}} to prevent "sprawling into the next section", and prepend a : to left justify. Also consider if the portal links are appropriate. Portals were initially linked to only from key subject articles, now they are widely used,it seems to me, as advertisements for WikiProjects. Rich Farmbrough, 10:44, 6 July 2011 (UTC).[reply]
I've long employed Template:Clear as a half measure to solve the sprawl, but it leads to new aesthetic problems, such as excessive white space where an an article is left blank. Template:Clear has it's uses, but at times, new solutions are called for. Template:Portal bar is one such. --Cast (talk) 19:02, 6 July 2011 (UTC)[reply]
  • Merging with {{Subject bar}} (also up for deletion above) could be an option, since it can also display portals (and only portals) in the same way. – VisionHolder « talk » 22:03, 3 July 2011 (UTC)[reply]
  • Keep as the template's creator. Like the {{Subject bar}}, also nominated for deletion, there are issues of inconsistency in how this stuff is currently handled, and my reason for creating the template (as well as the more inclusive "Subject bar") can be found on the Subject bar's talk page. If anything, I think we should be deleting the left-aligned portal boxes and starting a full-scale discussion how to organize content at the bottom of each article. I tried that at the Village Pump when I created these templates, but the topic got little attention... aside several from comments that indicated that left-aligned portal boxes were disliked. – VisionHolder « talk » 22:55, 2 July 2011 (UTC)[reply]
  • Keep we use navigation footers, so I fail to see what's wrong with this. 65.94.47.63 (talk) 03:02, 3 July 2011 (UTC)[reply]
  • Delete. Needlessly big and cluttering. Not sure of a substitute for it though. Let's have a look at Barbara Gordon. This is how it currently looks, which I think is ugly. Here are three alternatives: [1] [2] [3]. I think the last one looks best in this context. Cheers, theFace 11:38, 3 July 2011 (UTC)[reply]
  • If the layout doesn't look good, it may just need fixing. That's not a reason to delete the template. It may also be worth seeing if the {{Subject bar}} template (also suggested for deletion) handles it the same way. – VisionHolder « talk » 22:03, 3 July 2011 (UTC)[reply]
  • VisionHolder is right. It needs a bit of tweaking for that much portal entries. But deletion for such a small issue, is unwarranted. As a general rule, not every template is good for every situation; a certain degree of care is required for every template. Fleet Command (talk) 13:34, 6 July 2011 (UTC)[reply]
  • Keep or Merge into a centralized easy to use template. I really do not like floating portals and whatnot. Horizontal or inline is far far better in terms of scaling. This is especially apparent for me because I have dual monitors of different aspect ratios - a common 4:3 and a widescreen 16:9. Floating portals result in very unpredictable behaviors when I switch between different screens.-- ObsidinSoul 16:08, 5 July 2011 (UTC)[reply]
  • Keep, this can really help with layout. --Gyrobo (talk) 04:33, 8 July 2011 (UTC)[reply]
  • Keep, but reconsider how we use it. I really don't like full-width non-text items like this within in article unless they're panoramic images (and even then only with good reason). Those of us with professional printing and publishing experience know that's one of those things you just don't do. It's very unlikely the reader will continue after you've essentially painted a huge border in the middle of the page. If these portals (and I agree with those above who aren't sure why we got to using these boxes so much) fill up so much of a vertical box that a bar would be better, let's put the bar down with the navboxes and browse boxes where they'd be more at home aesthetically (Here's a possible solution: Could {{Portal box}} be edited to allow for columns and rows?). Daniel Case (talk) 06:11, 8 July 2011 (UTC)[reply]
    • {{portal box}} currently uses a table; reimplementing it as a list would make columns trivial, though that might mean a fair bit of work in reimplementing the general portal system. Nevertheless it's theoretically doable, though I think there's consensus above that the floating box isn't always desirable (even though that contradicts years of work in standardising these things in the first place for IMO minor aesthetic gains). Chris Cunningham (user:thumperward) - talk 08:36, 8 July 2011 (UTC)[reply]
  • Keep ~ Different layout and different scope. I think it is useful. –pjoef (talkcontribs) 10:06, 12 July 2011 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:Say what? edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Delete, no transclusions and has had no transclusions for years. Plastikspork ―Œ(talk) 01:07, 14 July 2011 (UTC)[reply]

Template:Say what? (talk · history · transclusions · logs · subpages)

Under-used template. No transclusions. Redundant to actual editing. The effort it takes to add this tag is only a little less than it takes to rephrase a problem sentence oneself. LordVetinari 13:38, 2 July 2011 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:Infobox School district edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Delete. Ruslik_Zero 16:16, 10 July 2011 (UTC)[reply]

Template:Infobox School district (talk · history · transclusions · logs · subpages)

Duplicates a better infobox at Template:Infobox school district. Kudpung กุดผึ้ง (talk) 11:28, 2 July 2011 (UTC)[reply]

Two fields in the Template:Infobox School district or an appropriate improvement for:
| image          = 
| image caption  = 
should be added to infobox Template:Infobox school district. I have added a request at Template talk:Infobox school district.
SBaker43 (talk) 04:04, 4 July 2011 (UTC)[reply]
Just to note that while these are nice things to have (or seem to be), that the template proposed for deletion isn't actually used suggests that this needn't be a prerequisite for redirection. Chris Cunningham (user:thumperward) - talk 06:31, 4 July 2011 (UTC)[reply]
I have responded to the above request by User:SBaker43 at Template talk:Infobox school district#Image fields. Cheers, theFace 10:33, 4 July 2011 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:PD-art-uk edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Replace with PD-art and Delete. Ruslik_Zero 16:23, 10 July 2011 (UTC)[reply]

Template:PD-art-uk (talk · history · transclusions · logs · subpages)

This had been re-directed to PD-art , but I'm not so sure. Hence I've re-instated the template with a minor wording change.

However, I'm not sure a license tag vs a restriction tag is the best way of handling images from sources that are less favourable to PD-art terms.

Hence this TFD nom to try to 'settle the matter'... Sfan00 IMG (talk) 14:59, 4 May 2011 (UTC)[reply]


Relisted to generate a more thorough discussion so a clearer consensus may be reached.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 19:55, 14 May 2011 (UTC)[reply]

Relisted to generate a more thorough discussion so a clearer consensus may be reached.
Please add new comments below this notice. Thanks, JPG-GR (talk) 06:05, 8 June 2011 (UTC)[reply]

  • Comment I think a licence tag is better than a restriction tag.Curb Chain (talk) 10:04, 8 June 2011 (UTC)[reply]
  • This seems to have been put together for the specific purpose of avoiding a repeat of the National Portrait Gallery furore in July 2009. I'm not sure that was ever necessary as the thing wouldn't have been avoided just by use of a better copyright tag. We can probably be safely rid of this. Chris Cunningham (user:thumperward) - talk 13:22, 13 June 2011 (UTC)[reply]

Relisted to generate a more thorough discussion so a clearer consensus may be reached.
Please add new comments below this notice. Thanks, JPG-GR (talk) 07:40, 2 July 2011 (UTC)[reply]

  • Comment Going a little against the standard by doing a third relist here as the desired outcome for this template is unclear. Delete it? Replace it with PD-art? Evaluate each image on a one-by-one basis? So far the only clear outcome seems to be "this template needs work." JPG-GR (talk) 07:40, 2 July 2011 (UTC)[reply]
  • Delete. Redundant to {{PD-art}}; it really adds no new message that I can perceive. Eventually, message remains the same. Optionally, minor modifications can be applied to PD-art to add more emphasis on "sweat of the brow" doctrine, as well the image (in)eligibility of transfer to Commons. Fleet Command (talk) 16:13, 5 July 2011 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.