MarioWiki:Proposals/Archive/44

Split Badge and Clothing by game
SPLIT 7-0

Badge and Clothing are currently long articles with several different lists; in Badge's case, you have both Paper Mario and Mario & Luigi games lumped in there. I think these lists, when split by game, are more manageable and serviceable when they are separate articles. In navigation templates, readers can look up the appropriate section rather than have their browser load a huge page with several irrelevant games. It would also be consistent to split them by game, since we already have other charts split by game. Finally, in Badge, while Dream Team and Bowser's Inside Story sections are rather small, I think it's still doable to leave them separate for consistency sake they can work if they get merged to their parent page, which is also consistent in other cases, which Walkazo has pointed out in her support.

Both will still stay as a lone article, but it's there to link all the badge/clothing lists by game into one article, and, at least in Badge's case, it will retain its history section.

Finally, the List of badge names in other languages (and clothing, if it has one; as far as I know, it doesn't) can be merged into these split articles, so it also eliminates an odd page that was created due to the badly-organized nature of those pages.

Proposer: Deadline: November 30, 2015, 23:59 GMT.

Support

 * 1) I think these two pages are better off split by game. Yeah, Badge is probably not going to remain featured, but that shouldn't be a reason against the merge, IMO. Featured articles were unfeatured as a result of organization and deletion proposals before, so that reason in of itself isn't good.
 * 2) - I supported the idea on the forum, and I support it here too. Except the part about splitting the BIS and DT badges: I disagree that it needs to be done for consistency, since we have plenty of cases where something split for one game remains merged in another (usually merged to the parent game article, rather than a separate page, but whatever, close enough). EDIT: Including the part about merging the BIS and DT badges to the game articles.
 * 3) – Per Walkazo, especially about leaving the Mario & Luigi: Bowser's Inside Story and Mario & Luigi: Dream Team Bros. information already present on the article as is.
 * 4) - Per Walkazo.
 * 5) Per all.
 * 6) Per proposal but not Walkzao, I think everything should be separated for both consistency and because it's still two separate games.
 * 7) Per all.

Comments
RandomYoshi: I think what Walkazo is trying to say is that the small information in Bowser's Inside Story and That Other Game can be just moved to a subsection in their parent articles. E.g. we remove Mario & Luigi: Bowser's Inside Story in Badge and add this same section under "Items" in Mario & Luigi: Bowser's Inside Story. 17:47, 24 November 2015 (EST)
 * If this is what was meant, then I understand the situation better. In fact, it's way better that way, so yay. 14:42, 26 November 2015 (EST)
 * I was actually advocating to leave the badges where they are, but moving them to the game pages makes more sense, and is more in line with existing coverage practices (which I was referring to as being similar to my original idea). -
 * I myself thought your implications (along with the "whatever, close enough" at the end) were that the moving method is the preferred and usual method. 16:15, 26 November 2015 (EST)
 * Nope, just that separate pages weren't the only way, as game pages retained things sometimes, so why not the badge page too? - or so I was arguing (but not anymore). -

Do not relegate charts to templates
PASSED 11-0

This proposal affects, , , and any other similar templates that have been overlooked. These three are charts that were once part of their respective articles (Super Smash Bros. for Wii U, Mario Kart 7, and Mario Kart 8), but were unceremoniously split into those templates. Nobody complained, and here we are. I think it's about time somebody complained. Simply put, the advantages do not outweigh the disadvantages. I brought the topic up on one of the template's talk pages, and Walkazo, BL, and LGM chimed in with their own comments. Moving the charts doesn't make editing all that much simpler, since that's what editing via section is for, and it just makes editing the charts more complicated. Since the article still has to load the template as well, I believe that it wouldn't help all that much for loading times either. Meanwhile, sticking the charts on a template by themselves is inconvenient and makes no sense considering that they're only going to be used on one or two articles, max. These charts can easily be reincorporated back into their articles.

This proposal is not affecting rules and other protected page, such as the proposal header, since they are kept separate in order to ensure that they can only be edited by the right people.

Proposer: Deadline: December 17, 2015, 23:59 GMT

Support

 * 1) I support my proposal.
 * 2) Per proposal. Having them as templates makes it slightly more difficult/time-consuming to edit them. Templates are mainly for use on multiple pages, it makes no sense to create an entire template just for one page...
 * 3) Per myself and all involved in the talk. Get rid of 'em.
 * 4) - Per TT, I see no benefits in the current situation.
 * 5) I actually complained in person with Baby Luigi and was about to bring it up, but the latter never occurred to me. Anyway, per my comment in the talk page; templates are intended to save repetition on particular coding when it is used several times, such as navtemplates, infoboxes, notice templates, and button input. This may save text or so when you're editing an entire page, but the savings are measly when it is much more inconvenient for editors and has virtually no advantages for our readers. So, yeah, just move them back to their parent page.
 * 6) Per all.
 * 7) Just because I have no idea what "relegate" means doesn't mean a chart isn't the same as a template. Per all.
 * 8) Per all.
 * 9) Per all.
 * 10) – Per all.
 * 11) - It would make sense if content was being duplicated on multiple pages, but simply outsourcing chunks of a single page is unnecessary added complication with very little gain: long sections aren't that big of a deal, and this trend should be stopped before it spreads any further.

Comments
Wording title is kind of weird, the proposal's strength in the future may be better if it said "Stop outsourcing entire chart content to templates"; "stop" is more precise since the outsourcing is ongoing; "relegate" is vague compared to "outsource". 15:53, 10 December 2015 (EST)
 * That seems pedantic.
 * I don't see why you're always so defensive to my wording suggestions. IMO, making the wording more precise makes it easier for referrals in the future. 17:35, 11 December 2015 (EST)
 * You didn't have to make it personal. The title gets the point of the proposal across and it can be clarified as needed in the archive.

Poking around a bit more, I actually found a bit more justification for the SSB4 template: it was meant to go on both Super Smash Bros. for Wii U and Super Smash Bros. for Nintendo 3DS, so rather than having all the identical info duplicated, it'd just be in one central place, saving space and making upkeep easier, which, assuming the two games remain identical in their rosters, does make sense. The guy who made the template initially put it on both pages, but then there was an edit war on the 3DS page and ended in the removal of the template, but really, looking at the two charts, I fail to see a difference, and really, that edit summary is contradictory to what the chart was envisioned to do (and I checked, and it looks like the pre-template version of the 3DS chart was indeed the same as the Wii U / current one). I agree that a one-template-to-one-page substitution is needless complication (we actually told people to stop doing it on userpsace years ago), but it could make sense for pages that share large chunks of content. (But even then, prior discussion would be better than just striking out on one's own.) - 16:01, 10 December 2015 (EST)
 * For this case I do see the use in having the template. Maybe the proposal could be modified to say templates only used on one page are useless whereas if they're used on more than one it's fine to have them? --
 * My sister brought it up previously: "it's more convenient to edit the template once than go through it twice" but it may not have been clear to you at the time. Anyway, I've said this already: templates are supposed to make repetitive content easier to implement, but I think we can go through case-by-case rather than make a flimsy qualifier in this proposal. 16:10, 10 December 2015 (EST)


 * Just to note: the difference in the Smash Bros. tables is that certain characters that are unlockable in the Nintendo 3DS version (Bowser Jr., Ganondorf, and Ness) are available by default in the Wii U version, and both tables reflect that by listing those characters in the appropriate sections. If we were to use one table then we would have to show that difference.


 * -Toa 95 (talk)
 * Well, there goes that. There is no reason to create the template for those either. I knew there was some catch between the 3DS and Wii U games when it comes to characters. 16:18, 10 December 2015 (EST)
 * I didn't see the talk page again after I made my comment - got too busy and forgot to check back. And ah, okay, I didn't catch the different between-header placements: I just thought there were arbitrary order differences at times and the headers blended into everything. Too bad - it'd be easier to manage one set of info, but yeah, setting up a switch function to have those characters appear in different places depending on the page would probably be too much trouble for most peoples' tastes. - 16:35, 10 December 2015 (EST)

Create a Account creation encouragement template
DELETED BY PROPOSER

Sometimes there are great ip users who make tons of useful contributions that help this wiki grow. Those ips are extremely welcome contributors who unfortunately, are ineligible to do advance things such as editing semi-protected pages, moving pages, creating new pages, and various other useful contributions due to their non-registered status. I think we should create a template to encourage them to join as registered. The template would be placed on ip user talk pages. I have drafted a design for this template:

Hello [ insert ip address here ], have you considered creating an account here. Your contributions to this wiki have been very appreciated but in order to unlock various other useful feature in this wiki, you will need to have an account. Having an account will increase your tool options by allowing you to create new pages, edit protected pages, vote in proposals and other discussions, upload new file media, rename pages, have a personal username and userpage. We strongly recommend you create an account to unlock these feature. Proposer: Deadline: December 25, 2015, 23:59 GMT

Support

 * 1) per proposal.

Oppose

 * 1) Per the arguments that were brought up the last time this idea was proposed: it's tedious and frankly unreasonable to have someone or even several people keeping track of every IP that pops up, IP's can be accessed by numerous individuals, and a blanket template probably won't convince them to sign up if they hadn't done so already.
 * 2) There are two main reasons this probably wouldn't work: 1.) Most IPs edit once and leave, others edit about once every few months. I haven't noticed all that many IPs who make enough edits (that is, within a reasonable time period) to make an account in the three years I've been here. 2.) Rather than a template, couldn't we just tell them in an informal message?
 * 3) Just leave it up to the individual operating the IP to see if they want to have an account or not, no need to nag them with an unnecessary template. Per Time Turner.
 * 4) - Per all here, and per the opposers of the last proposal. Also, that template is garish and painful to look at.
 * 5) Per all.
 * 6) I think this template will actually discourage users. If there are anons that are being super active and helpful, then it's better to thank them formally to encourage their signing up than to give a less caring, automated template.
 * 7) – Per all.
 * 8) Per all. I really don't think this is something we'll ever agree to doing.
 * 9) Per all.
 * 10) IPs can be IPs if they WANT to, they don't need an account to edit. per all.
 * 11) Per all; If an IP doesn't want an account, they don't need to make one.
 * 12) I don't see this going well. A lot of IP's make useful edits, but a lot of them also make edits that are very unnecessary. If we incourage them to make an account, especially the bad ones, we're going to have a problem. A lot of IP's only make one edit and leave anyway. Plus, why can't we just say it in an informal message?
 * 13) While I usually dismiss such arguments like "no one can do it" as laziness, in this case, it really is near impossible to keep track of all the IPs. No one is going to be like, "hey, I recognize that IP before!" Additionally, it's highly unlikely for IPs to check their talk pages; most just edit casually. And if the IPs really want an account, they will choose to do it themselves; I doubt that many people who acceses this site are actually aware of the account feature. They're staying an IP for a reason.

The Wording on Proposals Archived by Their Proposer
WITHDRAWN BY PROPOSER

As you know, nowadays, whenever someone archives their own proposal, it is filed under "DELETED BY PROPOSER." It used to be the case that it would say "WITHDRAWN BY PROPOSER" instead. I bring this up because saying "deleted" is wrong. Deleting is more along the lines of removing altogether; this wording is odd in the case we're using it with. Here are some scenarios:

Deleted: Removed entirely from the wiki. Removed: Removed entirely from the wiki. Withdrawn: Voluntarily archived.

I'm sure there are others that could work but these are the only ones I can think of.

The two on top are misleading. The proposals aren't being obliterated from existence, except for some cases. When someone archives a proposal voluntarily because they don't want it up, they aren't really deleting it per se, only withdrawing it.

Finally, this wouldn't affect proposals vetoed by the admins and archived; they always have the wording "VETOED BY THE ADMINISTRATION." This would only affect ones removed by the proposer.

Proposer: Deadline: December 26, 2015, 23:59 GMT

Change the Wording

 * 1) My proposal.

Do Nothing

 * 1) - Seeing as most pass/fail messages are customized and unique, I feel like it's not worth bending over backwards to make the cancellation messages uniform. "Deleted" is by far the most popular choice, especially in older archives, and it works perfectly well unless you want to be really pedantic; "cancelled" and "removed" have been used as well and are also fine (but really, as long as it's grey, that's what matters most). It's simpler to just let users continue to choose whatever wording they want as long as it's clear, concise and professional, regardless of whether their proposal passed, failed or was taken down early.

Comments
For such administrators actions, it's better to contact them directly. I don't think it's important to move this thing through the slow process of proposals.-- 17:01, 19 December 2015 (EST)

Redesign RPG infoboxes and bestiaries
PASSED 13-0

Having multiple infoboxes side-by-side in stats sections looks terrible, so after months of forum discussion and design drafting in my userspace, I am proposing complete redesigns of all the RPG infoboxes, primarily to allow for them to be able to toggle between vertical and horizontal forms. Vertical forms can be used like normal, at the tops of enemy pages as their main infoboxes: clutter is bad), but now for stats sections, the horizontal forms can be stacked on top of each other instead of haphazardly floating side-by-side and at the whims of varying screen widths. This is the main purpose for this proposal (hence it's in "new features"), but at the same time, various other changes will happen:


 * 1) All RPG infoboxes will toggle between vertical and horizontal forms - See above. Note that the vertical forms are the defaults so this won't cause mass appearance chaos as soon as the templates are changed.
 * 2) All RPG infoboxes will use the same colour-scheme as navigation templates (as seen here) - This will create consistency and ensures neatness and easy readability.
 * 3) All RPG infobox pages will have usage instructions and an input chart - This will make them easier to use.
 * 4) All RPG infoboxes will use consistent inputs whenever possible - This will also make them easier to use (less memorization and guessing), although it also means some inputs are being renamed and/or combined and will need to be updated on the articles (noted in red on the draft pages below).
 * 5) Some RPG infoboxes will be expanded with additional info - The infoboxes should have all the stats that we know of present, rather than forcing folks to look up supplemental charts in the bestiaries or elsewhere.
 * 6)  will need to be (re)created - Right now, Paper Mario and TTYD use the same infobox, but once all the new stats and featured are added, that won't be possible anymore, plus it's inconsistent and unnecessary to have two games in one.
 * 7) RPG infoboxes embedded in History sections should be moved to stats sections - If it's not the enemy's overall infobox, it should be in a stats section: it's just inconsistent clutter anywhere else.

It sounds like a lot, but the redesigned templates have all been drafted and are completely ready to go. All that needs to be done is updating the articles themselves by adding inputs to bring the templates up-to-date, and reorganizing the stats sections (including moving some infoboxes down there from History sections). Examples of the templates in action can be found here, and the drafts are as follows:


 * User:Walkazo/Test9 - - Super Mario RPG
 * User:Walkazo/Test1 - - Paper Mario
 * User:Walkazo/Test3 - - Paper Mario: The Thousand-Year Door
 * User:Walkazo/Test4 - - Super Paper Mario
 * User:Walkazo/Test6 - - Paper Mario: Sticker Star
 * User:Walkazo/Test2 - - Mario & Luigi: Superstar Saga
 * User:Walkazo/Test5 - - Mario & Luigi: Partners in Time
 * User:Walkazo/Test7 - - Mario & Luigi: Bowser's Inside Story
 * User:Walkazo/Test8 - - Mario & Luigi: Dream Team

As seen in the proposal's title, bestiaries are also on the slab here, and the reason why is because, rather than having multiple and/or too-wide-for-1024px-screen tables that force readers to scroll up and down and back and forth, from now on, bestiaries should take the form of multiple stacked horizontal infoboxes. Basically, anyway - as seen on Megadardery's test pages here and here, a slightly different template will be used to change the headers from the game titles to just the enemy names, and the bestiaries will still need to include the templates in an overall table for slightly more compact stacking and uniform column widths. However, the important part is that the bestiaries' inputs will all be the same as the corresponding infoboxes', making it a simple matter of cutting and pasting to move and update information between the bestiaries and the enemy pages, or at least make it easier to use both (even the how-to information is mostly the same). A final note is that the bestiaries will now use colour-coding in the names to denote enemy types (bosses vs. enemies vs. support), as explained in the nice legend at the top of the first test page I liked to in this paragraph.

Unlike the infoboxes, only the Paper Mario bestiary is drafted and ready, but I think it's still better to get the ball rolling on this overall stats project sooner than later and start working on getting those horizontal infoboxes out there: more bestiaries can follow in time.

Proposer: (with input from  and others; bestiary work by ) Deadline: January 11, 2016, 23:59 GMT

Support

 * 1) - Per proposal.
 * 2) Per proposal.
 * 3) Though I haven't commented, I've been in support of an RPG infobox template overhaul since the day it was suggested. It, at the current moment, is extrmeley unsightly, ugly, and most importantly, horribly formatted to not fit in with the stats and the like. Therefore, I'm in major support with this proposal and I want it to pass ASAP.
 * 4) – Per proposal.
 * 5) The way the vertical layout of RPG infobox templates are used is utterly miserable. Here are some examples: Dry Bones, Fawful, Lava Piranha, Blooper, Spiny, Buzzy Beetle, Elite Trio, the list goes on, but it's no small sample. They leave behind lots of white space, are extremely cluttery and overall messy, and they're not very reader-friendly. Worse, practically any recurring enemy article from a MaRPG game is doomed to have several of these templates, which are not designed with recurring enemies in mind. I also support moving infoboxes that otherwise clutter the article like in Boo or Hammer Bro. to stats section and get converted to the horizontal design. I'm glad we're going to redesign some of the wiki's biggest eyesores.
 * 6) Very sharp looking compared to the dated templates we are using now.
 * 7) per all
 * 8) - Per Walkazo.
 * 9) Per Walkazo
 * 10) Per all.
 * 11) Per Bazooka Mario and proposal.
 * 12) Definitely per proposal
 * 13) – Per all, this looks a lot better than what we currently have.

Comments
While I'm supportive of the redesign, I have a few suggestions to go with it. 15:48, 5 January 2016 (EST)
 * 1) Infoboxes should probably ignore the direction parameter in the mobile version, as it looks pretty bad when vertical there. (I'm not entirely sure yet how that'd work though.)
 * 2) You should put the CSS that goes into these infoboxes into Common.css to avoid all that clutter.


 * The mobile stuff's beyond my abilities, I'm afraid, and I generally prefer not to add stuff to the css if I can help it. Most of the clutter you're highlighting is unavoidable anyway, as things like the widths, colours and underlining aren't uniform for cells, rows and columns, and will always have to be specified in the templates. Other things like the float and margin coding are affected by the switch function, so again, they have to be in the templates afaik. All the ugly-looking border-radius stuff is just because of the use of, so in the actual editing windows, there's not nearly that much clutter up top, and it's not like this small handful of templates will need to be edited often either way (hopefully). - 12:19, 6 January 2016 (EST)


 * I generally prefer not to add stuff to the css if I can help it. – These templates are included in 1046 pages in total as of now. All those pages include the same coding over and over again, which is exactly what CSS files were invented for; styling similar elements with the same code multiple times. Not to mention the loading times and stress on the server by keeping everything self-contained.
 * Most of the clutter you're highlighting is unavoidable anyway, as things like the widths, colours and underlining aren't uniform for cells, rows and columns, and will always have to be specified in the templates. – It is not unavoidable at all, quite the opposite. I have made this page with an example of . You can see here that the tables and a few special cells where just assigned a few CSS classes, and the rest all gets filled in by the complimenting CSS.
 * Other things like the float and margin coding are affected by the switch function, so again, they have to be in the templates afaik. – These things also can be generalized in the CSS, see the first five selectors in the CSS on the example page, and the align parameter in the Wikicode. (btw, your margin code doesn't work, it needs a default or it will be left empty.)
 * All the ugly-looking border-radius stuff is just because of the use of  – Yeah about that, only border-radius: xx is needed, the rest really is unnecessary clutter. But that is a thing that can be accounted for on a different occasion.
 * 14:29, 7 January 2016 (EST)

There's not a infobox for Mario & Luigi: Paper Jam enemies or there will be one, but it is not done yet?-- 15:22, 7 January 2016 (EST)


 * Okay, I switched everything to "border-radius:5px" to get rid of that clutter, and having "horizontal" in the align function rather than its own thing is a good idea too, so I'll convert the templates to that (skips a bit of redundancy and fixes a really trivial irritation I had with the lack of margin in the template pages). But I'm still against outsourcing the designs to the css. Navigation templates are much more widespread, yet we don't bother doing anything more than the series-specific background colours and basic franchise-wide things like the borders, text and link colours. It's just easier to deal with template design when the design's in the template, not off in the css, which the vast majority of users would have no idea how to deal with - including admins. Plus, we're the only ones who can edit the css anyway, adding another level of complication to what should be an accessible operation: wikis are supposed to be user-friendly, but needing to get help to change a column width is not user-friendly. @LudwigVon: There wasn't a M&L:PJ template while I was working on the designs, and not knowing anything about the stats that might be applicable to the game, I didn't want to hazard a guess at a template design - then someone did make a template at the last-minute, which I didn't find out about until after I made the proposal, but its a bit dodgy and currently only in use on one page, so I was going to hold off on making a new draft for it until I've had time to check out the game mechanics myself, or see other users vetting it. - 16:04, 7 January 2016 (EST)


 * I can see where you are coming from, but I don't agree about keeping everything in the templates themselves. Making it less open may be true to an extend, but infoboxes (and navtemplates too) are things that are supposed to look uniform on the wiki in whole, and I don't suppose there is a lot of reason to change the width of a column any time soon. I think it would protect the design rather than 'closing' the openness.
 * If not moving to the common css, I would at least suggest updating obsolete code. On your Essay page with all those templates, the W3C's Validator return 329 errors. I was going to bring this up at some point anyway as it is a wikiwide problem, but now is as good a time as any.
 * 17:47, 7 January 2016 (EST)


 * Every time an input needs to be added, it'll potentially force things to be shuffled around, and it'll be easier to design new templates with old ones readily available in full. The only thing I'd concede to for the css is a proper, overall infobox class or two to cover the basics (cellpadding, cellspacing, maybe border and font stuff), the way there's an overall nav template class, but that's a whole other kettle of fish since there are a lot of infoboxes that will have to be dealt with: it's beyond the scope of what this proposal is about. Anyway, I fixed all the non-padding/spacing obsolete coding in my drafts here (and there weren't 329 errors from the templates alone - the essays page had a lot more content on it). You're not the first to voice concerns about the wiki as a whole having a lot of depreciated coding, but no one's ever really cared enough to try to do anything about something that basically seems like an invisible non-issue that's beyond the knowledge of the majority of users. You could try to set up a wiki collab about it if you really wanted to. - 23:15, 7 January 2016 (EST)


 * If there where at least some base classes that would be a big improvement already (seeing the table opening tag is the worst offender everywhere), but you are right that this is outside the scope of this proposal.
 * I have been planning on making some form of collab sometime already as 'non-issue' is not really the case but that also is outside this proposal's scope so that's a discussion for then. 11:05, 8 January 2016 (EST)
 * Yeah, I was surprised when I checked common.css and found that there actually wasn't an "infobox" class, even though all the infoboxes start out that way: fixing that's definitely on my to-do list now (maybe after the rollout of this proposal's done). - 11:28, 8 January 2016 (EST)

A quick note, regarding the, the score and card how (under the name: card location) have been added to all the templates, the tattle was changed to card description and the tippi was changed to tattle for better clarity. The draft should be updated accordingly.-- 05:59, 9 January 2016 (EST)
 * Alright, updated, thanks. Changing the "tippi"/"tattle" thing was definitely a good idea, although tbh I would've recommended shorthand rather than long "card location" and "card description" inputs, but ah well, too late now. -
 * pssst, you forgot to change the second card how...-- 16:19, 9 January 2016 (EST)

Prohibit the Usage of in Headers
PASSED 14-1

Using in headers has a couple of issues. For one, it looks ugly and inconsistent with how other headers look like. The only acceptable text formatting in headers should be italicising as to indicate that it's a piece of fiction being talked about. Underlining text in headers is very bad. Furthermore, it breaks the Recent Changes. Using the Recent Changes, a user may jump directly to a section of an article if only a section was edited. However, should the header contain, this feature is broken. Having a feature that breaks a vital function of the Wiki should never be allowed. Sure, you could just hop to the section manually, but why would you do that when the Wiki can provide you a function that does that for you automatically?

I do realise and acknowledge that there is an issue with this: how do we notify the reader that these names are conjectural? The solution is simple.

===Thing that is conjecturally named===  is a thing blah blah blah blah

That way, we get the information that it's conjecturally named across, it doesn't break the Recent Changes, and it makes headers look consistent. This means that all information is preserved, and we don't have to implement a feature that breaks a very vital function of the Wiki. Alternatively and depending on the kind of section being worked with, the text doesn't need to be in a bold typeface. This also gives us the possibility to quickly summarise what the section is about in one sentence before describing the rest of the subject in greater detail. Furthermore, this methodology ensures no unnecessary and ugly notification templates need to be used at all. Additionally, removing does not break section linking at all, so all links that already exist and link to headers that already contain  will not be broken and still work.

But how do we go about finding these? The answer here is also simple. This is how.

EDIT: The old link for finding the instances of the template did not work, so this will be used instead.

Proposer: {{User|RandomYoshi}} Deadline: January 11, 2016, 23:59 GMT

Support

 * 1) – Per proposal.
 * 2) - Per RandomYoshi.
 * 3) Per RandomYoshi.
 * 4) – Per RandomYoshi.
 * 5) - Per Pi.
 * 6) - Per π
 * 7) &mdash; Per RandomYoshi.
 * 8) I hate the use of the conjectural text template in headers, it's time to end that practice once and for all.
 * 9) Per all.
 * 10) Sure thing.
 * 11) Per all.
 * 12) per all
 * 13) Per all.
 * 14) Per everyone except Wildgoosespeeder.

Oppose

 * 1) To me, this could just be a MediaWiki bug. Before making changes to pages to adapt around the bug, have  update the software that MarioWiki uses and report the bug to the developers of MediaWiki if the bug persists.

Comments
Unfortunately MediaWiki search is broken, so the link you provided will not help us find the pages. But as far as I've seen, the only pages with conjectural section titles are the Galaxies and list of Glitches, which should be easy enough to track down. Otherwise, how is the suggested workaround going to work in the list of glitches pages? It doesn't seem efficient to specify the glitch name in every section. I think we need a better idea to over all say "Yo guys, these are all made up names so don't quote us on them will ya?".-- 12:03, 4 January 2016 (EST)
 * How about making a similar template to Template:Conjecture, but that states something like "The titles of the following sections of this article are conjectural; [and the rest is equal to the base template]"? It could have a "section=" variable that, if set to yes, states "The title of the following subsections of this section [equal to normal]". The first is used in glitch pages, the second in Galaxies pages.
 * Having additional notice templates is only going to help in increasing how messy pages look like. It's not going to be the end of the world if we repeat it for every subject we talk about. In fact, it's better to first aptly summarise a subject in one concise sentence before prattling on about the minor details of a subject: that way, readers who only wish to gain an elementary understanding of a topic can choose only to read the first sentence of a paragraph, whilst others that feel like they want a more in-depth analysis can do so by continuing to read about the subject. Because is used in the beginning of the sentence and has the subject bolded (or not), the information that they're conjecturally named is still going to be conveyed in the same way it's done at this point, except it won't break the Recent Changes and generate unprofessional-looking headers. To summarise, it won't hurt us, it won't hurt the reader, it won't hurt the page by introducing a whole batch of notice templates, and it certainly won't hurt the Recent Changes.  13:47, 4 January 2016 (EST)
 * No, it would be repetitive to state the nonofficial name of the glitch underneath every glitch section with that exact same title, it seems okay in the introduction of main articles, because you really are introducing the main element of the page, however in glitches' pages, it becomes overly annoying to read the same thing over and over again. It's like going over every section in the Mario article starting it with "[..] is a game that Mario stars in." which would be insane. Don't get me wrong, I support this proposal, because this issue is super annoying when it comes to actual editing and linking. However, the consequences of doing it this way is not something I support. I don't support the idea of the notice template either, it would be an eye catcher. However, adding it to the introduction of the list in one short sentence is not something I'm keen on, but not something I'm against either.-- 15:10, 4 January 2016 (EST)
 * I agree with RandomYoshi at this point. However, I have another idea: if templates are not good, let's just add a sentence just before the various section start. It should say "NOTE: All the glitches'/galaxies' names in this page are conjectural. Fitting names have been given by the editors.". This may seem repetitive, but remember that phone users have no way to read the message shown by hovering the cursor over conjectural text.

So, I used the link above to track down all the pages that have conjecturaltext templates in at least an header, and oooh boy, there's a very long list awaiting...

I figured out how we're going to deal with the Super Mario Galaxy and the Super Mario Galaxy 2 Galaxy levels with their planets and such. In each section about a planetoid, a picture of this planetoid should be accompanied. In this picture is usually found a small description of the planetoid. In this thumbnail should the name of the planetoid always be found. This is the instance that can have on it. How does this sound? 15:59, 5 January 2016 (EST)
 * It's a good idea. I don't know, however, if everyone reading the Galaxies' pages would stop to read thumbnails. Should we make the planet's name bold in the thumbnail, so it's more apparent?

So, we're about to settle about how to apply conjecturaltext changes on the various types of pages, but there's still an archetype: 50 pages about Wario Land II pages. Here, the problem is in the Hidden Treasure section: a conjectural name, stating what's the treasure, is in the header. However, the paragraph doesn't ever repeat this name, and we can't do the same thing RandomYoshi proposed for Galaxies because the images are far too small. The only idea I have is removing that name altogheter: I don't think it's even needed. Do you have any other ideas?


 * Been mulling it over, and I think just having a "Note: all these names are conjectural." message (in bold, even) at the tops of the "Planets/Areas" sections (on the galaxy and mission pages) would be the most efficient way to deal with the situation, avoiding the use of the specific template at all (or the need to hide the names in the thumbnail descriptions - which would be inconsistent with the rest of the wiki). As for the WLII items, I agree that it'd be simpler to remove them from the headers, and instead just describe them in the body text without having to pass them off as names. For example, Turn off the alarm clock!'s header would be "Hidden Treasure : Viking Helmet " and then the text will simply read "...The treasure of this level is a horned viking helmet that bears some resemblance to the Bull Pot..." (underline showing new content). - 12:38, 6 January 2016 (EST)
 * There are some areas that are officially named, like Cosmic Cove Galaxy's Twin Falls and Cosmic Cavern. Should we note that these are exceptions to the rule by just saying "NOTE: This area is officially named.", and provide a source for its name? 13:10, 6 January 2016 (EST)
 * Or just say "NOTE: Unless otherwise marked, all names are unofficial." and then for the ones with real names, do specifically mention and bold the names in the text with a ref ("The Twin Falls[1] area consists of..."), and that should be enough to tip readers off that those are the official ones. Then the mission articles could go a step further and say "NOTE: Unless otherwise marked with a reference, all names are unofficial." since there's no headers to worry about gunking up, just thumbnails (of if using refs for the mission pages seems like overkill, asterisks could work instead). - 13:40, 6 January 2016 (EST)
 * Deal. 13:55, 6 January 2016 (EST)

See my opposition vote for details about my thoughts. I don't know what version of MediaWiki MarioWiki is using. -- 17:49, 7 January 2016 (EST)
 * Actually even if this issue persists forever there is an easy workaround. That is, use the template under each section. Just sayin, I still agree with this proposal because the look of the hovertext in the section titles.-- 09:50, 8 January 2016 (EST)
 * Like Megadargery states above me, getting rid of the hover text is also one that needs to be done. Even if we were to place s everywhere, it would be ugly and awful. The solution that is proposed is fine. 15:57, 8 January 2016 (EST)

Protect all series page
DELETED BY PROPOSER

What I mean by series, I mean the page name like, Mario (series), Paper Mario (series), Mario & Luigi (series) so that only autoconfirmed user can edit them.

The reason I wanted all this page to be protect is because, I think these pages are often vandalized and that several false information on those pages are added. In addition, when a new official game comes out, it is also impossible for those who are not autoconfirmed user to created a page for this game.

Proposer: Deadline: January 24, 2016, 23:59 GMT

Support

 * 1) Protect those page indefinitely.

Oppose

 * 1) We should protect these pages only on a case-by-case basis, as some series are not as popular as others, and making a blanket ban on them would be in my opinion unwise. It's best left to see what peoples do to this page in the first place and drive-by wandals who wandalize the page aren't really common anyway.

Comments
I agree with Baby Luigi, I found that my proposal is pointless after all.-- 12:47, 17 January 2016 (EST)

Split the Mario & Luigi and Super Mario RPG consumables into separate articles
SPLIT 11-0

Remember back in the day when the word "stub" was thrown around like it was going out of fashion and everything smaller than Bowser's article was a stub? This resulted in a lot of articles being clumped together into one superarticle, which is kind of like Superman if he had to wear Kryptonite. What I want to bring up today involves several articles merged during that period, including Super Syrup, Ultra Syrup, Max Syrup, Super Mushroom, Ultra Mushroom, Max Mushroom, and plenty more (including subjects that were affected long after the merges). Every article that I want to split will be listed in the comments. So, the reason I want to split these articles is because there's no reason for them to be merged in the first place. They're individual items with individual names, individual effects, individual buying/selling prices, and individual locations that the games treat like individuals. In some cases, they even have individual appearances, and no, some items having the same appearance is not enough to keep them merged when everything else about them is different. The clumped articles themselves aren't all that pleasant, trying to hop from several topics in rapid succession when that information would be more easily presented in separate articles. Also, having a bunch of Foreignname templates stacked on top of each other is not good in the slightest. I was one of the people who supported those proposals, but looking back, I simply cannot see how the articles are "clearly not working seperate". In light of the recent splits, I thought this would be appropriate.

Proposer: Deadline: January 17, 2016, 23:59 GMT

Split

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) – Consistency is key. Per proposal.
 * 4) - Per Time Turner.
 * 5) Per proposal.
 * 6) Per all.
 * 7) Should've happened earlier.
 * 8) - Per TT.
 * 9) - Cautious support. I agree with the general thrust of the proposal, but there does have to be a threshold below which two things are similar/minor enough to go on the same page. One-sentence pages, even if notionally complete, don't help anything. (I presume that last sentence doesn't apply to any of these specific splits)
 * 10) Per all
 * 11) Per proposal

Comments
Full list: I'm tempted to thrown in the Peppers alongside this proposal, but they're not quite in the same boat as the other ones. There's also the Mushroom that the Triplets give, which has a completely different effect to a regular Mushroom, but I don't know how the article would be properly identified if split.
 * Mushroom - Super Mushroom, Ultra Mushroom, Max Mushroom, Mid Mushroom, Bad Mushroom
 * Syrup - Super Syrup, Ultra Syrup, Max Syrup
 * Nuts - Super Nuts, Ultra Nuts, Max Nuts (on a side note, shouldn't it be "Nut"?)
 * Nut - Super Nut, Ultra Nut, Max Nut
 * 1-Up Mushroom - 1-Up Deluxe, Double 1-Up Mushroom
 * Drumstick - Hot Drumstick, Fiery Drumstick, TNT Drumstick
 * Candy - Super Candy, Ultra Candy, Max Candy
 * Any others that I've missed
 * It most definitely should be Nut instead of Nuts. It shouldn't be renamed right away, but it should be renamed after you've made the different Nut articles. You're allowed to link to just even if that would generate a red link.  20:17, 9 January 2016 (EST)

@Reboot: We're not giving articles to every subject under the angry sun (see: Fan (souvenirs), Lightwand), but the articles that I've listed all have more than enough information to support themselves individually.
 * I'm not sure if I understand the plan for the mushrooms. Is the intention to give the Super Mushroom from the various RPGs its own article(s), or merely move the information around to the existing one? Either way, it should be noted that the Mid/Super Mushroom and Max/Ultra Mushroom had identical Japanese names. It would appear to be another example of a translator – Ted Woolsey in this case – providing one-off separate names which would later be changed or reverted. The mushrooms in Super Mario RPG do heal different amounts of health, but those values are also inconsistent within the Mario & Luigi series itself. Mid/Super Mushroom definitely seems straightforward enough, but there is confusion with the Max Mushroom since it was actually introduced separately from Ultra Mushroom in the Mario & Luigi series, and it performs just like the original Super Mario RPG version in Superstar Saga and Partners in Time. That's not even considering Super Shroom and Ultra Shroom from Paper Mario (albeit colored differently). How does that all work out under this proposal? LinkTheLefty (talk) 03:00, 10 January 2016 (EST)

Pretty late in the proposal, but should Woo Beans, Hee Beans, Chuckle Beans, and Hoo Beans be added to this list? They're currently in Bean but I feel they can get their own article here. Does this proposal cover those? 00:14, 15 January 2016 (EST)
 * At this point, it's too late to change the proposal, but to me, they're in the same boat as the Peppers. I would like to see them split ASAP, but this proposal was meant for reverting the merges of yesteryear, and I felt that neither the Beans nor the Peppers were really a part of that. From day one, they were a part of the same article before the merges even started, so it would have been misleading to include them here. That's what talk page proposals are for!
 * I actually was about to contact you in your talk page, but better ask here now: are you planning on creating separate article for those aforementioned beans? It doesn't seem like something that would be a contentious issue since the four are pretty distinct enough, but I could be wrong... 00:28, 15 January 2016 (EST)
 * Considering their different locations, different appearances, different uses, and different names, I'm all for each Bean having its own article. I might also extend this to the stat-up Beans from later games, though I don't know enough about them to give a definite "yes this is a good idea".
 * Let's just stick with the Superstar Saga beans stuff. I think the stat-up beans shouldn't get their own page; as far as I remember, they all have the same sprite and don't differ as drastically as the Superstar Saga stuff. 00:47, 15 January 2016 (EST)
 * The Beans have different sprites in Dream Team, and considering they all increase a different stat and can be found in different locations, I wouldn't mind bringing them along for the split.
 * Fair point. Let's do that too. 16:19, 15 January 2016 (EST)

Require short detail of change in future Support/Oppose/Comment/etc proposal headers
FAILED 1-5

The reason for this is similar to the proposal above - when adding a vote or comment on a page that has a prior (usually settled) proposal, you get sent to the equivalent section for the first proposal. Similarly, the section link from RecentChanges will also send you to the wrong section in the same way (in either case, you're sent to, e.g., when the section you're looking for has an anchor along the lines of, even though the header is just ====Support==== ).

It wouldn't have to be long or complicated (e.g., this proposal could have headers of something like "Support/Oppose requiring short detail"/"Comment on requiring short detail"), the point is just for it to be unique on the page (although simplicity of rule-writing means that it would be better to include the first proposal on a page in it). Headers in past proposals wouldn't need to be changed; this would only apply to proposals, including Talk Page Proposals, started after the new policy would come into effect.

Proposer: Deadline: January 17, 2016, 23:59 GMT

Support

 * 1) . Per own proposal.

Oppose

 * 1) - Too much screwing around for something as superfluous as where you appear in the page after saving. The Table of Contents brings you to the right header, and when you try to edit, you're in the right section, so there's really no problem. Maybe someday the MediaWiki bug will be fixed, but in the meantime, it's not worth complicating basic header stuff.
 * 2) Aside from per Walkazo, since the page load bug is a bug, it's not something we can really fix.
 * 3) Per Walkazo and the comments below. It's a MediaWiki glitch that most likely won't be fixed in the near future. All this does is add unneeded tedium to the process of proposal creation; even though  does this, it doesn't mean we should all be required to do this. I get that we're trying to work around something the can possibly get very irritating (I actually talked to Porple about it because at that point, I didn't know it was a well known MediaWiki glitch), but like I said, all this rule (for lack of a better word) would do is add unnecessary and unwanted tedium to creating proposals; and besides, the only thing it would really be absolutely necessary for is TPPs because on this page, it doesn't take much effort to go from one proposal to the next, because scrolling from Proposal A over Proposal B to Proposal C does not take much effort at all. To sum up, it really should just be an option, not a requirement.
 * 4) Per all. I'd rather ignore the bug than go through an extra step in making creative proposal headers.
 * 5) Per all.

Comments
Ghost Jam: Isn't this what this proposal is all about, though? Circumventing a bug? 19:05, 11 January 2016 (EST)
 * Exactly. We can't fix it (it's more or less baked in - the only ways to technologically fix it would be [a] prohibit more than one section with the same name on a page by throwing an error when someone tries to save it as such or [b] make section anchors something like a random alphanumeric code with no connection to the actual header text. The former is a more extreme version of what I'm suggesting, and no-one anywhere wants the latter), but we can work around it. - Reboot (talk) 00:42, 12 January 2016 (EST)
 * Or just ignore it. It's a minor bug: not worth bending over backwards over and adding another, confusingly fiddly step to proposal-making - one that promotes inconsistency and needless wordiness, at that, which will then look terrible in the archives forever. Both the long-term and short-terms costs far outweigh any benefit from avoiding a glitch that causes a second's worth of inconvenience at a time: we've shrugged and carried on for over 8 years, and we should continue with that path of least resistance. - 01:12, 12 January 2016 (EST)