MarioWiki:Proposals/Archive/47

Merge Redundant Paper Mario Items
There are several items from Paper Mario: The Thousand-Year Door which are clearly intended to return in Super Paper Mario, but have different pages due to having different English names. Considering that they look identical and usually have the same name in every country except the US, they should probably be merged as per the precedent set by more proposals than I can count. As for the items having slightly different effects between games, that happens all the time.

Here's a list of the proposed changes:


 * Koopa Bun would be merged with Koopa Dumpling
 * Mango Delight would be merged with Mango Pudding
 * Mousse Cake would be merged with Mousse
 * Omelette Meal would be merged with Omelette Plate
 * Shroom Roast would be merged with Roast Shroom Dish
 * Spaghetti would be merged with Spaghetti Plate

If there are any I missed, let me know.

Proposer: Deadline: April 5, 2017, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) I would question whether or not this proposal is necessary, but either way it would be nice to have a single proposal to point towards should the issue ever come up again.
 * 3) I am wondering about whether it should be a proposal. Either way, Spaghetti and Spaghetti Plate are the only ones mentioned that actually have a big noticeable difference. Besides that, Roast Shroom is slightly different texture from Shroom Roast. That said, I am not 100% sure if we should merge Spaghetti and Spaghetti Plate, but I am 100% ok with the others merging.
 * 4) If they have similar attributes, then a merge is totally acceptable. It's possible name changes can occur over time, after all.
 * 5) Almost all of them look very similar to each other, and, since multiple proposals that are very similar to this have been made before, I support these merges. The only one that I am not 100% sure about is Spaghetti and Spaghetti Plate, since they have big differences in their appearance.
 * 6) Per all.
 * 7) Per all.
 * 8) Per all.
 * 9) Per all.
 * 10) Per all. Besides, we have Duel Glove, Ztar, and Fluffin' Puffin as notable precedents. Hopefully you'll understand what I mean by clicking the links.
 * 11) Per all.
 * 12) Per all.

Allow users to make a user subpage for 'Shroom sections
I made a proposal that would allow users to make a sub page filled with all of their 'Shroom sections. (See the proposal archives) Only I voted so it was 'NO QUORUM'. I am asking for more users to vote, not just me.

In the page, users would copy their section from an issue of The 'Shroom and paste it onto their page (unless if there is a way to translude it). Users can choose what sections to put in it. They can put either all of their sections, their favourite ones, or have one section and replace it each time they write for The 'Shroom. Users can slo choose to link sections if they want to.

This would make it easier to find sections made by a certain user without wasting time looking through the archives. This page will also make it easy to count how many sections a particular user has written.

Proposer: Deadline: "April 6, 2017, 23:59 GMT"

Support

 * 1) Per my prioposal.

Oppose

 * 1) This wouldn't be a good idea in the long run. Many 'Shroom writers, such as myself, have written massive sections in the past, or have simply written a very large amount of sections. Transcluding whole sections into a userpage would lead to said pages easily taking up 100k+ bytes, reducing load times and clogging up the wiki. Userpages simply made for linking to sections seem rather unnecessary as well, as it could just as easily be done on the writer's main userpage.
 * 2) Per Lord Bowser. Also, the rules say that subpages that serve the wiki can be created in addition to signatures and the like. Having a separate page filled with 'Shroom sections wouldn't really serve the wiki.
 * 3) Per all.
 * 4) – Per LB. Users may reproduce (a reasonable number) or link to written sections on their main userpage if they wish.
 * 5) Per all.
 * 6) Per all.
 * 7) Per all.
 * 8) Per Lord Bowser and Shokora.

Comments
You forgot to title your proposal, by the way. 14:26, 30 March 2017 (EDT)

I want to point out, regarding the "make it easy to count how many sections a particular user has written", we do have this. -- 03:52, 31 March 2017 (EDT)

Repurpose
As highlighted by in this forum post, the necessity of the  template has come under question. His main concerns are that it seems redundant to hand out when a user overly edits in their userspace, and that the template itself is too wordy and takes too long to get to the point. also mentioned that many users with high userspace edits often have it due to experimentation with wiki coding, which is a productive use of editing if it is meant to go onto official articles.

These two reasons is why I propose a restructuring of the userspace template; removing the too many userspace edits reason, and just sending out (in)formal reminders for that instead on a case-by-case basis. I also propose reformatting the template so that it only covers genuine violations of the userspace policy and gets to the point faster. This way, the template won't need to be handed out so liberally, and it will better get the attention of those in violation of the policy.

Proposer: Deadline: April 12, 2017, 23:59 GMT

Repurpose the template

 * 1) Per my proposal.
 * 2) Per Lord Bowser. The userspace warning has always seemed odd among the other warning templates. It's just too lengthy.
 * 3) per all.
 * 4) It's always felt kinda large and long to me.
 * 5) Per all.
 * 6) While it seems detrimental to retire the temple altogether, it also seems pointless to not improve it. Perhaps it should only be issued if A) the user in question makes more than five or six major edits (500 bytes or more) to their userspace, and B) these edits all have little or no relevance to the project (such as, you know, using the wiki as a web host). While the status quo isn't the worst (Bulbapedia, for example, has an even stricter (and maybe an even more "needlessly patronizing") policy on userpages), I'd say it's definitely worthy of improvement.
 * 7) Per all.
 * 8) Per all.
 * 9) Per all.
 * 10) Per myself and Baby Luigi in the linked forum thread.
 * 11) - Per all; trimming it down and making it clear when (not) to use it is a needed improvement to the template
 * 12) Having experienced the overuse of this reminder first hand (although it was overturned by an Admin almost immediately), I agree we need to make more clear what type of situations this reminder should be issued in. Per all.
 * 13) Per proposal.
 * 14) Per my comments

Leave as is

 * 1) You can say that a userpage is a great place to practice MediaWiki syntax but we should encourage redirecting those people's attention to do that in Sandbox. Keeps attention off the user namespace. There is a reasonable argument that, in general, Bulbapedia is too strict. In general, I feel that MarioWiki is too relaxed. I think we can find a happy middle ground, but this proposal as it stands right now isn't it.

Comments
@Toadette the Achiever - I don't propose removing it entirely, since it can still serve a legitimate purpose. I just wanted to retool and rewrite it so that it would only be issued in the case of userspace policy violations, and informal reminders being sent out in the case of excess unproductive userspace edits. This would increase to formal reminders and warnings if it persists, similar to the current policy in place. 19:02, 5 April 2017 (EDT)

Something lacking is the link to Special:Editcount. This is clearer than Special:Contributions because one page keeps count of edits while the other lists each edit made by the user. Here's me: For new users, Special:Editcount is more useful while for long time users or frequent editors, Special:Contributions is more useful. -- 19:10, 5 April 2017 (EDT)
 * Special:Editcount/Wildgoosespeeder
 * Special:Contributions/Wildgoosespeeder

@Wildgoosespeeder - It is important to remember that many users, including yourself and myself, have their own personal sandboxes under userspace, used for things such as template drafts, policy drafts, experimentation, and so on. All of these edits add up on Special:Editcount under the User row. Encouraging people to use the wiki sandbox when you have your own personal one is contradictory and borderline hypocritical. 04:15, 6 April 2017 (EDT)
 * I am aware, as I do the same thing. I thought we were talking the main page only (no slashes), the page where we can personalize to our liking. Sub pages are the exception, as long as they serve the wiki. -- 04:39, 6 April 2017 (EDT)

If anyone was curious, I've created a potential new userspace template on my sandbox. Feel free to comment on anything that should be changed within it. 04:48, 6 April 2017 (EDT)


 * Damn Wildgoosespeeder, you've got more edits than me :'( @Lord Bowser, that proposed template seems fine. Like Template:Sigfix, the wording around the policy is very general, which leaves it to those who are issuing the reminder to personally advise the user on exactly what they've done wrong (such as excessive userpage edits, creating unnecessary subpages). 08:13, 6 April 2017 (EDT)

I think that number of user space edits alone does not determine whether a user is editing their user space too much. For example, a user may use a sandbox to work on a very big project. This would not be in violation of policy because it is helpful to the wiki. What is not allowed is making a very large number of edits on pages that are not helpful to the wiki, such as a main userpage, while making little to no mainspace edits. I think that the template cloud be rewritten to make that clear, as well as adding detail about other types of userspace violation. -- 08:56, 6 April 2017 (EDT)

Discourage OGG Extension (Not Format)
The *.ogg extension is a generic extension to describe the *.ogv and *.oga file formats. To put that into perspective, that would be like clumping all *.jpg, *.png, and *.gif file extensions to be under *.img or something *.html, *.xml, and *.rtf formats to be included with what we expect of the *.txt extension. Yes, those files all contain easily readable text if opened in Notepad, but it would be very hard to tell each file apart if all HTML, XML, and RTF files all had the TXT extension instead. To make things more easily identifiable on MarioWiki, I propose that *.ogg be a discouraged extension for a file of this type when uploading. Sure, MediaWiki can detect the MIME type regardless of extension, but that's not immediately clear when sifting through categories.

Xiph.Org Foundation, the developers of OGG, recommend the extensions I am proposing. VLC Media Player already registers all known extensions of this standard. My guess is back in the day, OGG was just audio (such as DX-Ball 2) but things were getting more complex so they needed to have a better extension to represent the complexities of the standard and discourage the old extension.

To be clear, I am not looking to discourage the format, just the one extension of the format. OGV and OGA are perfectly safe. There are around 1,000 files to check and move. Let's get them changed before we end up with a insurmountable amount of files to make changes to. I think Pywikibot can do this stuff automatically.


 * Files tested to be moved successfully:
 * File:SMS Opening.ogg to File:SMS Opening.ogv
 * File:VBWL-Title Screen Theme.ogg to File:VBWL-Title Screen Theme.oga


 * Categories to sift through (recommended order to do them in):
 * Category:Fair use video samples
 * Category:Fair use music samples


 * Affected templates that need consideration:
 * - Update it to allow for OGV and OGA as well? Code for row one but apply similar code for each row after it:
 * - Behaves like  but for OGV only
 * - Behaves like  but for OGA only
 * - Only works for files with extension OGG. Deprecate it?


 * Related proposals:
 * Proposals/Archive 29

Proposer: Deadline: May 02, 2017, 23:59:59 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) My browser (at least the one I use the most as I also have Google Chrome, but I not really going to mess with ogg) doesn't even support OGG, OGA, or OGV. But, OGA and OGV are very different from each other. Banning use of OGG for both audio and video sounds good. But, what about applications if they ever become part of this wiki? What will happen to those? (I am only asking to point out all possibilities.) As for vandels that happen during this, there is a option not to show/hide bots which I have chosen to hide them and this is the only thing I have chosen to hide due to when bots work, it makes a lot of changes reflected on Recent Changes. Overall, I will support this decision.
 * 4) Per proposal.
 * 5) Per proposal.
 * 6) Per proposal.
 * 7) Nothing wrong with encouraging a better extension than a blanket one. The proposal previously supported a complete ban on .ogg which was too extreme for my tastes, but this is something I could get behind.
 * 8) I'm now convinced that this proposal will succeed. Per Baby Luigi and my comment below.
 * 9) If this simplifies life for the Wiki editors and staff, I support the idea. It is recommended by the Xiph.Org Foundation anyway.
 * 10) I'm in the same boat as Yoshi; my Browser (Firefox is what I'm using currently) doesn't even support .OGG files. I definitely support this idea.

Oppose

 * 1) There is apparently no technical difference between .oga and .ogv, while there are differences between .png, .jpg, .gif, etc, which renders that point in the proposal moot. I can't really imagine a scenario where only having .ogg would hinder the wiki in any aspect, and besides, .ogg files are relatively infrequently uploaded and used here. Banning the .ogg extension in place of .ogv and .oga seems like a lot of hassle for little benefit, as like you said, thousands of files would need to be moved; however, even more articles than that would have to be edited in order to correctly reflect the moved files, which is a pretty big task even with bots. This is a good idea on paper, but the benefits of implementing this seem to be outweighed by the sheer level of editing that needs to be done across every article that uses .ogg files.
 * 2) Per Lord Bowser. It indeed sounds rock-solid on paper, but if you think more deeply about it, why would it even be necessary to ban one extension when the two umbrella extensions work very similarly to each other, yet are used differently? If anything, I say we ban OGA and OGV because sometimes having less options can actually benefit and relieve more than harm. Unless you can give some other reason for banning OGG, I'm afraid I'll have to oppose.
 * 3) The idea to split the sound files and video files into their own compartments sounds like a good idea on paper, but I think the creation of another category specifically dealing with .OGV versions of .OGG would be more useful in the long run, as we don't have to bend backward to change this rather common file extension across the wiki. As the above two stated, I think too much energy required is worth the hassle of what amounts simply a name change with very little benefit to it whatsoever. Furthermore, .OGG is the default extension for many programs I use such as VLC and Audacity, and I think it's just too much of a hassle going through the extra step of renaming the extension to meet these proposed standards. If you want to rename extensions from .OGG to .OGA or .OGV, no one is stopping you, since that's technically allowed, but I don't support an official, outright ban on .OGG formats either.

Comments
Sort of related...do we still need ? I thought browsers supported this by default. -- 17:43, 25 April 2017 (EDT)
 * With HTML5 supported video playback with the version of MediaWiki MarioWiki uses, that feature seems worthy of . -- 18:01, 25 April 2017 (EDT)

And what exactly is the difference between .oga and .ogv? Is it really significant enough to warrant banning the .ogg extension? This should really be further elaborated upon for those less experienced. 03:01, 26 April 2017 (EDT)
 * Technically, no difference between *.ogg, *.oga, and *.ogv. They are all defined by one standard, as I linked at the very beginning of the proposal. For MarioWiki, it would make maintenance easier by making all files by the standard easily identifiable by file extension rather than by MIME type. We should assign *.og a  for  a udio, assign *.og v  for  v ideo, and forbid *.ogg rather than use the extensions interchangeably with audio and video data streams. By posing these restrictions, we can integrate and  better than what is currently being done with the restrictive  for *.ogg files only. -- 04:33, 26 April 2017 (EDT)
 * No article editing required because the templates force .ogg, .ogv, and .oga for, , and respectively. Only one edit will take place, on . The rest is moving. You don't specify the extension if you use the template. Not sure why but OK. All that needs to be done is the move bot work, which I have my credentials hooked to, so this work is all me. I have done thousands of edits before at a time with Category:Beta Images by moving the remaining hundreds of images to Category:Pre-release and unused images. It got done in two hours or so. If a vandal runs rampant during the transition, I immediately stop the bot so that way Special:RecentChanges doesn't render the vandal unnoticed. -- 17:33, 26 April 2017 (EDT)

, this is just a browser issue. Chrome supports MP4, WebM, and OGG/OGV/OGA. Internet Explorer just MP4 (automatically) and WebM (with a codec installation by Google). For some reason, Internet Explorer forces you out of being able to play OGG/OGV/OGA. Just open up the file in an external application, such as VLC Media Player.

Applications? You mean like *.exe, *.zip, *.rar, *.7z? That's 's decision and I don't blame him for it.

People have brought up to flag my account as a bot temporarily but I don't use the bot often enough for it to be worth it. -- 18:21, 26 April 2017 (EDT)
 * When I say applications, I am referring to something else the OGG covers which can be viewed on the Wikipedia site provided. 18:26, 26 April 2017 (EDT)
 * I'm not entirely sure how MarioWiki can take advantage of those added perks of the OGG standard. Because of how the four media templates are coded, we just create additional templates for each extension and amend the switch.


 * .ogg
 * .ogv
 * .oga
 * .ogx
 * .ogm
 * .spx
 * .opus


 * If I really had my way with the four templates, I would delete the subpages and code everything into . -- 18:56, 26 April 2017 (EDT)

Xiph.Org Foundation recommends the extensions I am proposing. -- 18:56, 26 April 2017 (EDT)

Again, I'll be doing the work to get things up to standards. It's a one time deal. Title changed so the file extension is acceptable but should be moved to a better extension. -- 20:39, 26 April 2017 (EDT)
 * Yeah...dissuasion is usually better than an outright ban. 21:02, 26 April 2017 (EDT)
 * @Wildgoosespeeder, I've read everything, and I understand what you want to do, but I don't entirely understand why. First, you mention that "it would make maintenance easier by making all files by the standard easily identifiable by file extension rather than by MIME type." From an organizational standpoint, it makes sense, but what do you mean by "maintenance," and how does keeping the .ogg extension currently complicate things? Second, you said that "by posing these restrictions, we can integrate and  better than what is currently being done with the restrictive  for *.ogg files only." Is there only an organizational benefit here, or am I missing the bigger picture?
 * Proposal now has a reason to move over each file to the extension based on standards by Xiph. Consider each subcategory of Category:Media by game. They contain a mixture of audio and video under the extension OGG in most cases (only five uploaded files are up to Xiph's extension standards). I also explain a better example with text files why keeping the OGG extension is a bad idea. Right now, is calling  only 30 times. With the switch code I can implement very easily,  could call, , or  depending on the   specified. The OGA and OGV templates were proposed, passed, and created, just never properly implemented. Also, Media/OGA and Media/OGV isn't transcluded very much compared to Media/row. The special thing about templates and categories is that if you edit the template to change its category, it affects all places it is transcluded, autosorting everything in Category:Pages with media files to go into Category:Pages with audio files and Category:Pages with video files. -- 21:55, 26 April 2017 (EDT)

, you don't even need to do it through Audacity. You can just use Windows Explorer (or equivalent file manager) to change the extension or redlink with the OGA/OGV extension and upload the source file that kept OGG. File contents doesn't change. Just the file name extension. This is similar to how you can upload a file with the *.jpg extension onto a file using *.jpeg because File:New Nintendo 3DS and New Nintendo 3DS XL.jpg can exist separately. -- 21:09, 27 April 2017 (EDT)
 * Just as I suspected. So it's just like changing a notepad file to a .bat file, nothing would really change if I edited the extension. Thanks for clearing that up. 22:55, 27 April 2017 (EDT)
 * Exactly. To make it even more clear, MediaWiki would have thrown an error if I were to move an PNG image to a page with a JPEG extension for example. I tested OGV and OGA moves with two OGG files, described in the proposal, and MediaWiki didn't throw any errors. -- 02:14, 28 April 2017 (EDT)

Create Template:Pmitem-infobox
I've noticed that pages for Paper Mario series items don't really have a consistent format, usually having either Template:Item-infobox or Template:Recipe-Infobox. The problem is, neither template works very well, especially in terms of documenting the items' descriptions between games (the item infobox looks bad with multiple descriptions stacked on each other, and the recipe infobox doesn't even have a description field). Because of that, I propose that we create a new infobox for Paper Mario items, that way it's easier to document series-specific info in a convenient way.

Here's the current draft in my sandbox, which is mostly incomplete at the moment.

Proposer: Deadline: May 4, 2017, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Sure, but we would have to get rid of recipe-info box because it repeats everything already mentioned, while what is proposed will bring new info as well. I also like the proposed name better than the recipe one.
 * 3) Sounds like a good idea to me. Per proposal.
 * 4) Per all. Would the Template:Recipe-Infobox be necessary anymore? All of the pages it is used on are Paper Mario items, and the new infobox would repeat certain information.
 * 5) That definitely sounds fine to me. I also agree that Template:Recipe-Infobox would no longer be needed should this proposal pass. However, I wonder if we can do the same to the Mario & Luigi series, since the items listed are also in need of an infobox. Nonetheless, it's a good idea, and I see no reason to oppose in the long run.
 * 6) I don't know why we don't have this already. Per all.
 * 7) Per all.
 * 8) The new template makes more sense, so I approve!
 * 9) What about Paper Mario: Sticker Star and Paper Mario: Color Splash? I know they use Battle Cards, Stickers, and Things, but could they be integrated somehow?
 * 10) Per Proposal.
 * 11) Per all.
 * 12) Per all.

Comments
I think it should really be called, since I don't see why this can't include the Mario & Luigi series as well. 20:28, 28 April 2017 (EDT)
 * I plan to make it easier to implement series-specific sections if necessary, though. Niiue (talk) 23:22, 28 April 2017 (EDT)

@Wildgoosespeeder: I wouldn't worry about that too much at the moment, considering that the Stickers/Battle Cards don't currently have their own pages. Niiue (talk) 23:23, 28 April 2017 (EDT)
 * @Niiue: Perhaps then it would be better to create as well...? Maybe both could be created, but then I think they would have to match the respective color schemes for navigation templates.  11:14, 29 April 2017 (EDT)
 * Sounds good. Niiue (talk) 16:16, 29 April 2017 (EDT)

New template
Like many other readers of Super Mario Wiki, I have made the big mistake of reading the "Story" sections of game pages. This section gives spoilers that don't make the game as fun. I propose that we make a template that warns users for spoilers. This template would go directly beneath the "Story" heading in game articles. Also, if this proposal is successful, I would like to know how to make this template, so please post here on my talk page.

Proposer: Deadline: May 12, 2017, 23:59 GMT

Support

 * 1) Per my proposal.
 * 2) Honestly, I don't see the harm in this. Every other game wiki I've been to has some variant of it, after all.

Oppose

 * 1) – Per the arguments in this proposal. Essentially, entire articles could be spoilers. And as an encyclopedia, we should be presenting information as professionally and candidly as we can.
 * 2) Spoilers in general, why are people so picky with plot details being revealed, even to the point of trying to get others to censor their own material? Also, how much time must pass for it to not be considered a spoiler anymore? Oftentimes, reveals are out of context. Reading text isn't as compelling as playing the game itself or watching someone else play. It's much more fun wondering how the conclusion is reached rather than seeing what the conclusion is. With something like the Mario games, we all know how things go. When has there ever been a plot twist? Spoilers are a mess that observers created and is out of control. In the context of a wiki, too much editing with little pay-off.
 * 3) Almost the whole wiki contains spoilers. This would mean that almost all pages would require the template. Instead of doing this, it would make more sense to put a message on the front page (if we should do anything at all).
 * 4) Per all. Almost every page would require the template, and About already warns that the Wiki coverage includes unmarked spoilers.
 * 5) Per the proposal Shokora mentioned.
 * 6) per all.
 * 7) Per all. I'm not even sure if this proposal should be here, considering it's contradicting a past proposal.
 * 8) Per All. This entire wiki is a spoiler. If people want to avoid spoilers, they might as well stay of the internet, spoilers are everywhere.
 * 9) - Per the About page. It already warns that there can be spoilers. General disclaimer there. If you want this template made, we're going to have to rewrite policy.
 * 10) Per the reasons it got removed in the first place.

Comments
@Niiue: We are not every other wiki, though. Every wiki has their own rules. 12:22, 5 May 2017 (EDT)

Create templates for the Super Smash Bros. head images
I've noticed looking though Equipment that all of the head images for the characters in Super Smash Bros. look kind of tedious to type out. So, I thought it'd be easier and more efficient to have templates for the heads instead.

The code would be like for the Mario image from Super Smash Bros. Melee, which would turn out like this:. Currently, it's all linking to the image itself and, again, is rather tedious to type out:.

Codes would be as follows for each game (and just substitute "Mario" for the character):
 * would lead to SSBMarioHead.png
 * would lead to Mario SSBM.png
 * would lead to Mario_SSBB.png
 * would lead to Mario Head SSB4.png

In many cases, like the linked Equipment page above, these would be great to have. They're quick, efficient, and consistent. Unlike how the Equipment page is set up, where the coding is everywhere... These can be useful in several charts, either already created or could be created, where we would need to show only the head of the character for easy reference.

Proposer: Deadline: May 18, 2017, 23:59 GMT

Support

 * 1) - Per me.

Comments
I don't understand why this would be only for Super Smash Bros. characters. In the wiki, multiple instances of this is already used, like in Mario Kart 8, Mario Kart 7, Superstar Challenge. I personally don't see much benefit for this template. 00:03, 12 May 2017 (EDT)
 * ...Oh. I was thinking too single-focused here, it looks like. Completely forgot there were other games that used these types of mugshots. I could repurpose the proposal to cover everything like this, but.. oh, boy, that would be a lot of mugs to work with... Um, yeah, I think this was a good idea, but I'm just going to cancel this. I obviously didn't think this all the way through. Maybe I'll suggest this again in the future when I have all the facts and options straight. 00:18, 12 May 2017 (EDT)