Template talk:Stub

A nice gray border might be good. Para Yoshi Wahoo! 19:32, 18 October 2006 (EDT)

Nooooo... Not really. 3dejong


 * I don't think it looks very nice. It kind of separates the template from the article. Monty Mole ( Talk&middot;Contribs ) 19:43, 18 October 2006 (EDT)

I made it look a little better. Yep, still don't think it's needed. -- Steve (talk) 19:46, 18 October 2006 (EDT)

Thats good. XyzCoRy123ABC 04:03, 14 October 2008 (EDT)

Hey...
Since any article that is a stub is deleted, why do we still HAVE this template? TheGreatBlockyBoo 19:02, 25 August 2007 (EDT)


 * There are still a ton of stub articles on the wiki that were previously created. -- Son of Suns


 * About stubs.... What if there is little info and no way to get more? TheGreatBlockyBoo 20:29, 26 August 2007 (EDT)


 * There should always be a way to get more info. Be creative! -- Son of Suns

So... Once the stubs are gone, the template goes too?


 * Well, we don't need to delete it, just in case stubs become okay again (which won't happen until we expand our current stubs). -- Son of Suns


 * <.> Why is it that we hate stubs? TheGreatBlockyBoo 20:43, 26 August 2007 (EDT)


 * I don't think we should be deleting any stub articles, isn't SOME info better then NONE?
 * Well most articles only state obvious and can hurt the wikis image, I'd rather have no info then one line stubs.
 * Well, there's a difference between "Pirate Goomba is a Pirate goomba." style article and other that state some info, but could be expanded greatly.

Gofer
 * WHAT HE SAID. TheGreatBlockyBoo 20:55, 26 August 2007 (EDT)

S***. Some info is better than none. XyzCoRy123ABC 04:03, 14 October 2008 (EDT)

Stub or Rewrite-expand?
Is there any policy of when to use this template and when that one? To me, they seem to serve exactly the same purpose. I always wonder which to use on short articles (using both seems redundant). 13:16, 19 September 2008 (EDT)
 * The way I saw it used, Stub seems to be used for articles that amount to nothing more than "X is a character/items/thing in [game]", while RW-expand is for article that do have informations, but incredibly unspecific and poorly written. But yeah, there's no policy for those templates. --Blitzwing 14:15, 19 September 2008 (EDT)

Revision
Is it cool if I replace the link on "stub" to PipeProject:Unstubify instead of the category? The link to the category is unnecessary anyway since it shows up at the bottom.-- 17:38, 24 December 2009 (EST)
 * Fine for me. BUt it will still categorize them, right? -- 17:45, 24 December 2009 (EST)
 * Yup, categorizing is a totally different feature thanks to
 * That's actually a splendid idea! - 18:24, 24 December 2009 (EST)

Merge contents with
NO CHANGES 6-1

I am proposing here instead of at because I thought it would be neater that way. Anyways, I had a discussion over at Template talk:Sectionstub about merging with  and came up with User:Wildgoosespeeder/Stub/sandbox that is being used on File:Glide64 2.png for testing. It would also be better to remember and keep track of one less template. Seems kind of redundant to have two. Essentially, I want to match our other templates, such as, , and , in terms of function. I am not totally against doing the opposite, like towards for example. I am looking for some consistency with our templates. I didn't know that existed because I was using  all this time.

There were concerns about Category:Section stubs and Category:Stubs being combined into one category. The two categories will remain intact. That was already addressed before concerns were raised. This bit of code decides if it should go in Category:Section stubs or Category:Stubs:

Proposer: Deadline: February 27, 2016, 23:59 GMT

Add Scripting to

 * 1) Sounds like a good idea.

Do Nothing

 * 1) Was a little bit late to the party, since I commented here before realizing the proposal is active, but I'll say it again: I think it's better off if those two are different. While I do see the benefits in the long run by a little tweaking around with improvement templates to make them match consistency and therefore make it easier for new and experienced editors alike to use (therefore I completely disagree with the appeal to tradition that we shouldn't improve accessibility because it's too much of a "hassle" while ignoring the long term benefits), I also see the benefits in keeping them separate since I feel these two entities are distinct enough to warrant their own separate template. Also, with the whole tweaking thing, if the accessibility lends itself to messy coding as Walkazo had brought up, then I would be opposed to it as well, hence why my vote is staying in oppose.
 * 2) - Due to the different designs, wording, categorization, link and clear functions, merging the templates requires five switchers, plus an extra one nested within one of them to get the optional section link working, and at that point, might as well just stick to two templates. Just because it's doable doesn't mean it's worth it to jam them together (unlike the superficial single word changes needed for all the other template), and sometimes having a pair of similar-but-different things is okay (this isn't the only case). The unobtrusive footnote-style Stub templates are already completely different from top-of-the-page/section notice templates in design and function, so if they're different in execution as well, that doesn't seem like a big problem to me.
 * 3) – The templates are completely different. Completely. Different. This is a non-issue. These templates exist literally everywhere on the Wiki. Indeed, doing this would be even more taxing than just doing the reasonable thing: doing nothing. This is a wholly inefficient way of dealing with this. Awful. Bad. Never supporting this.
 * 4) Per all. Lot of work for little pay off. As has been said in the past, repeatedly and directly to the proposer, this is a non-issue.
 * 5) It's rather unfortunate that the template was created years ago and thus gave it a lot of time to be widely used to the point where attempting to nest sectionstub as a version of stub would be impractical. Per all.
 * 6) I'll say per all!

Comments
, look at File:Glide64 2.png. It can put in one of two categories thanks to. Can you please change or remove your vote? -- 03:16, 13 February 2016 (EST)

, I don't see much of a design difference between my sandbox and /. As for the switches, there isn't that many and it is very easy to work with. I can understand having 50 or so and the code is a mess. I tried to keep it as clean as possible. If you have suggestions to make it even cleaner, voice them! -- 16:31, 13 February 2016 (EST)

If anyone is worried about edits that transclude would not be worth the time, I can perform all those edits. Or maybe I'm not getting why people think this is too much work considering I got the code near-finalized and I would be the one to make the edits. All it would take is one template edit via copypasta by a moderator and I can get to work. -- 03:41, 19 February 2016 (EST)