MarioWiki:Proposals/Archive/55

All past proposals are archived here. Please add archived proposals to the bottom of the page. Previous proposals Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15 Archive 16 Archive 17 Archive 18 Archive 19 Archive 20 Archive 21 Archive 22 Archive 23 Archive 24 Archive 25 Archive 26 Archive 27 Archive 28 Archive 29 Archive 30 Archive 31 Archive 32 Archive 33 Archive 34 Archive 35 Archive 36 Archive 37 Archive 38 Archive 39 Archive 40 Archive 41 Archive 42 Archive 43 Archive 44 Archive 45 Archive 46 Archive 47 Archive 48 Archive 49 Archive 50 Archive 51 Archive 52 Archive 53 Archive 54 Archive 55 Archive 56 Archive 57 Archive 58 Archive 59 Archive 60 Archive 61 Archive 62 Archive 63 Archive 64 Archive 65 Archive 66 OK Boomer (Move Boomer (Super Paper Mario) to Boomer (Pixl)?) withdrawn by the proprietor (see comment) Interestingly, there are two different identifiers for these two Super Paper Mario pixls: Boomer (Super Paper Mario) and Slim (Pixl). Since there is an inconsistency, it would make sense for both pixls to share the same identifier. Since Slim (Flopside) prevents the use of using (Super Paper Mario), it would make sense to move Boomer (Super Paper Mario) to Boomer (Pixl). This further makes more sense as naming policy suggests using a "Thing" identifier (pixl) over a game identifier. Such a page move would be fairly innocuous. However, this would create a minor secondary discrepancy with the other two Boomer pages, both of which are using game identifiers. Should both of these pages be moved to be more specific to their pages, such as Boomer (boss) and Boomer (bear), as well as Boomer (Pixl)? Proposer: Trig Jegman (talk) Deadline: Jan 6, 2020; 23:59 GMT Date withdrawn: December 31, 2019, 01:56 GMT Move Boomer (Super Paper Mario) to Boomer (Pixl) only Trig Jegman (talk) - Well I made it, but I don't necessarily think it would be a big deal if the other two variants remained the same. - 23:01, December 29, 2019 (EST) Move all three Boomer pages to be more specific While I suggest Boomer (boss) and Boomer (bear), these could be discussed further Do nothing Toadette the Achiever (talk) See here, here, and here for a full explanation. Comments This further makes more sense as naming policy suggests using a "Thing" identifier (pixl) over a game identifier. The "thing" in this case is character. If character can't be used, then you move to #2, which is game. Slim is forced to go to #4 since game can't be used, while Boomer can safely stay at #2 and use game. That the two Pixls end up in different places is simply a result of them needing to differentiate from different things (Slim (Flopside) forces it). I understand it can be considered annoying, but whether or not they match is really neither here nor there - they are each a different case with different needs. As you said, if you do the move then these three links are inconsistent since one wouldn't use game (and there is no reason for it not to use game since they are all from different games). So basically you want to open up the character identifier to get more specific before moving to game (as it used to be). This gets into its own weird problems of what should be used, and having some awkward identifiers. I think going to the game name sooner avoids that awkwardness in the most objective way possible. If you tally up the amount of "problems" with each system, I'll take the current Pixl "mismatch" and a bunch of objective game identifiers versus a ton of human/flower/whatever identifiers. The Slim (Pixl) case is a direct result of Nintendo using the same character name twice within one game and rightfully should be the one awkward situation because that is a confusing thing to do. Opening up custom character identifiers before moving to game creates awkward cases which are completely the wiki's doing, and we should try keep our hands clean and minimize any impact. No matter what system we land on there will be weird cases to deal with. I think the current system minimizes the damage and is the "least bad" option, and I don't want to keep changing things around. So I'll veto --Steve (talk) 20:56, December 30, 2019 (EST) Compile Play Nintendo puzzle activities in a single page MERGE PUZZLES 7-0 I don't think the Play Nintendo jigsaw puzzles, such as this one, this one and this one, deserve their own pages as much as the other Play Nintendo activities do. The reason skill quizzes and personality quizzes need their own pages is to neatly list all the correct answers for each, in a similar fashion to how we handle the quizzes from the Paper Mario games. However, those jigsaw puzzles all have the exact same "gameplay" where you choose a difficulty of 8, 18 or 50 pieces and then use them to build the base picture; the only difference is the picture you have to build, but this isn't a strong enough reason to keep these puzzles on separate pages. This can be easily managed in a table that contains the preview and description used on the website, what the completed puzzle looks like, and a link to the actual puzzle. I therefore propose that we make a list of Play Nintendo puzzles where we compile every single one of them, with the following layout for the table: Preview Completed puzzle Play Nintendo description Web page name Link [pic] A (puzzle) piece of art Put together the puzzle pieces to get a closer look at the Mushroom Kingdom. You can choose between Easy (8 pieces), Medium (18 pieces), or Hard (50 pieces!). Good luck! Nintendo Online Jigsaw Puzzle Game [1] A few notes: The website description takes priority over the tab title of the puzzle because the words used in it also serve as search keys on Play Nintendo, whereas the tab title seems more like a simple placeholder typed out by the publisher (and cannot be used to search the puzzle). We'll offer a direct link anyways, so the reader won't have to personally go type it out in the search bar, but this decision is taken to more or less highlight the importance of the description on the website. That one Mario jigsaw puzzle on the Nintendo Kids Club website (Play Nintendo's European counterpart) won't be affected by the proposal, as it is considered in relation to other games on the website (Luigi's Word Jumble, Captain Toad's Dungeon Dash! etc.) If the proposal passes, any puzzles that already have their own pages will be merged in a List of Play Nintendo puzzles. I was planning on organizing the other activities similarly, since the current list on the Play Nintendo page doesn't have much of a rhyme or reason. If the proposal is unsuccessful, then the jigsaw puzzles will continue to have their own pages like the rest of the Play Nintendo activities. Proposer: Bye Guy (talk) Deadline: January 16, 2020, 05:27 GMT Support Bye Guy (talk) per proposal Obsessive Mario Fan (talk) - Since all the puzzles are the same but with different pictures and text, this works best. Also, each puzzle has a unique message when completed, so that should be included too. Power Flotzo (talk) Per Obsessive Mario Fan. TheDarkStar (talk) - Per all. Waluigi Time (talk) Per all. Mister Wu (talk) Agreed - I support the idea of using less space and simplifying navigation without losing the actually relevant information Jazama (talk) Per all. Oppose Comments Remove tense DELETE TEMPLATE 17-0 The Template:Tense has been around for almost 10 years, and despite this, it is almost never used. Tense is so infrequently used that while discussing it with long time wiki editors, they didn't believe it was a thing. Tense serves virtually no purpose anymore, as changing word tense is generally very easy to do, especially with tools like Find/Find Next being commonplace. If a situation is truly dire, it doesn't make sense to not simply use {{Rewrite}} over Tense, since a majority of people don't either know it exists and cannot find the section in which it is documented, or people don't suspect a tense issue because they are so infrequent. Because of this, I propose that the tense template is deleted. Proposer: Trig Jegman (talk) Deadline: Feb 18, 2020, 23:59 GMT Support (Delete the template) Trig Jegman (talk) per proposal. Doc von Schmeltwick (talk) Ye I had no idea it was a thing, but it's pretty much pointless. Per proposal. Alex95 (talk) - Yeah, that makes sense to me. TheDarkStar (talk) - It's only used on one page, and it doesn't even have a dedicated subcategory, so I'm for deleting this. 7feetunder (talk) We don't need sub-templates for every specific way an article can be badly written. Just use the "reason" parameter. Scrooge200 (talk) Per all. Mario jc (talk) Per proposal. Sdman213 (talk) Per all. Obsessive Mario Fan (talk) This template is redundant. Per all. Niiue (talk) Per all. Toadette the Achiever (talk) Practically useless. It's an issue that's extremely easy to fix. TheFlameChomp (talk) Per all. Yoshi the SSM (talk) Per all. Mister Wu (talk) If it’s redundant and almost unused, we can get rid of it. FanOfYoshi (talk) As another proposal by Super Radio (or is it Results May Vary), this is redundant. Supermariofan67 (talk) Per all. White Lightning (talk) If it is hardly used, it must be removed. Oppose (Keep the template) Comments Actually, it's on Mario & Sonic at the Olympic Games Tokyo 2020, too. But I still don't see a use for it. Scrooge200 (talk) 00:31, February 12, 2020 (EST) New Template:Gamma Image create template 6-0 An interesting oddity that I and few other users have noticed while dealing with images is a very interesting type of metadata called Gamma Brightening. In short, what gamma brightening does is change the way the colors of an image are displayed. This is generally very rare, but it is important as the differences between images is severely drastic. After some internal discussion, most notably with Steve, the unspoken policy course of action is to not optimize images with gamma brightening, and leave that metadata on the image if it is the way the source image provides the picture. The purpose of the proposal is to make this unspoken policy a spoken policy. People should know when an image has a special property and should be treated differently. The following template, {{Gamma-Brightening}}, would be placed on the documented images with gamma brightening: This image contains gamma brightening, and should not be optimized. <div class="notice-template" style="display:flex;text-align:center;background:#BF5FFF;margin:0.675em 2% 1.75em;padding:0 1em;border:2px solid black;color:black"> '''This image contains ''[[User:Trig Jegman#What's Gamma Brightening?|gamma brightening]]'', and should not be optimized.''' </div><includeonly>[[Category:Gamma Image|{{PAGENAME}}]]</includeonly><noinclude> Such images seen thus far is: File:Hammer Bro-NSMBU.png File:MP8 Hammer Bro Artwork.png File:NSMBDS Goomba Artwork.png File:BulletBillWii.png File:NSMBDS Buzzy Beetle Artwork.png File:NSMBW Mario Holding Green Shell Artwork.png File:NSMBW Mario Jumping Artwork.png File:Blueboostblock.png It would also be suggested, but not required, to create a MarioWiki page discussing gamma brightening over using a section on my user page. Comparison image: Proposer: Trig Jegman (talk) Deadline: Feb 19, 2020, 23:59 GMT Support (Create template) Trig Jegman (talk) Per proposal Bye Guy (talk) per proposal TheDarkStar (talk) - Per proposal. Results May Vary (talk) - It might be odd seeing this on many image pages, but otherwise it is a reasonable decision. We want to preserve the original nature of the image as much we can. Although personally I prefer the Gamma brightness removed for the Hammer Bro pic but just in this case, and it's only my opinion. mister Wu (talk) I’m still wondering if removing metadata doesn’t create more problems than it solves (it’s often a few bytes of data where the IDAT chunk is orders of magnitude bigger), but since current optimization software removes them and since the gAMA chunk definitely must not be removed, it’s better to add this template. FanOfYoshi (talk) Per all. Oppose (Do not create template) Comments I mentioned you could simply say this information in the aboutfile template. Because of that, I don't see a need for this template, as it would only really apply to a handfull of images. But I'll remain neutral, as I'm not directly opposed to it, either. 11:21, February 12, 2020 (EST) Not sure what to think of this yet, but I think the purple should be a lighter color to make the text more readable. --DeepFriedCabbage 14:46, February 13, 2020 (EST) I can easily change the color to be more reader-friendly. I will hunt for a similar purple that's easier to read. Trig - 16:42, February 13, 2020 (EST) Thanks! --DeepFriedCabbage 20:07, February 13, 2020 (EST) is #cb7eff or #debffb more appropriate? demonstration; original demonstration; option 1 demonstration; option 2 I personally enjoy the original or lean towards the darker side of purple but it's up to the community. (I've never been great with color) Trig - 17:21, February 14, 2020 (EST) I'd go with option 1. --DeepFriedCabbage 15:05, February 19, 2020 (EST) It seems that "original" does not necessarily equal "accurate" in all cases. Take File:Luigi - New Super Mario Bros U.png for example. Note that the optimized version contains a darker green and the gamma ("original") version contains a lighter green. Then look at File:NSMBU FourCharacters.png from the same game, where the opposite is true. Therefore, it seems that there are some images where gamma correction produces an accurate image, and other images where gamma correction produces an inaccurate image. Given this, I think we can't say that gamma should always or never be removed, since it depends on the image. How do we determine when the original is accurate, and when the optimized version is accurate? A side note: it is possible to keep certain metadata, such as the gamma chunk or embedded ICC profiles, while still optimizing the image, such as by passing the --keepchunks=iCCP,gAMA,cHRM option to zopflipng or the -kiCCP,gAMA,cHRM option to pngout. See this page for further explanation. I tested it on File:NSMBDS Goomba Artwork.png. Note: preserving only the iCCP chunk has worked for every image I've tested so far, but theoretically there may be older images that rely on the gAMA or cHRM chunks. Since these legacy chunks are very small, it's probably worth preserving them also. Maybe we could include this information in the policy, so that we can optimize the images without removing gamma.--Super Mario Fan 67 (T•C•S) 00:01, February 16, 2020 (EST) We could modify the template/proposed policy to consider this. Maybe something like: This image contains gamma brightening, and should not be optimized without preserving iCCP metadata. --Super Mario Fan 67 (T•C•S) 14:31, February 16, 2020 (EST) The image-critical ancillary chunks are tRNS (used on Captain Toad: Treasure Tracker ripped textures by APNG Optimizer to greatly reduce file size), sBIT, pHYs, and the color space chunks, sRGB (when it specifies a different rendering intent than the default one), gAMA, cHRM and iCCP. So far only the tRNS, sRGB and gAMA/iCCP have been spotted, but I’m not sure if the others are featured as well, press release material might be the most at risk, if it was generated using the AdobeRGB color space. In any case, this specific proposal deals with the gAMA chunk and possibly the iCCP chunk.—Mister Wu (talk) 18:55, February 16, 2020 (EST) I'm not sure we should mention performing image optimization on the template at all given that it's now heavily discouraged at best by the image use policy. -- Too Bad! Waluigi Time! 19:24, February 16, 2020 (EST) The Image Use Policy only discourages "Re-uploading existing images solely to optimize file size," not optimizing images you are planning to upload anyway. There could be other reasons (such as cropping) that one may modify an existing image, and many people such as myself optimize all pngs uploaded, including images to reupload. --Super Mario Fan 67 (T•C•S) 19:30, February 16, 2020 (EST) I would suggest writing a specific new page about Gamma Brightening, and having two sections to the page. One, very general in description, explaining what it is as simply as possible (metadata is a thing and while usually ok is not here and therefore needs to be kept, here's why we keep it), and the second half getting into the really technical stuff involved. While I like the detail that SMF67 and Wu are providing, I have absolutely no idea what just about any of that means. On the second point, I usually optimize uploads that are new nowadays, but I am duplicating them to compare them, just in case. Also, input on the color would be nice. Trig - 20:50, February 16, 2020 (EST) I like color option 2 the most. --Super Mario Fan 67 (T•C•S) 17:58, February 17, 2020 (EST) @Trig Jegman, @Mister Wu, I made a quick (still incomplete) draft of a page that could describe the technical parts of color-correction metadata and how to safely optimize these images in my sandbox. There are still a few missing details I haven't figured out yet, and anyone is encouraged to add to it or take details from it to make something else (we don't have to use it of course, I don't know if all of the information is relevant/important to include). Additionally, while it might be nitpicky, I think it might be a good idea to refer to the metadata as "color-correction metadata" rather than "gamma brightening," since technically gamma is only one type of color-correction metadata and iCCP seems to be the most common from the images I've tested. --Super Mario Fan 67 (T•C•S) 18:24, February 19, 2020 (EST) Perhaps it would be more appropriate then to use {{color-corrected}}, with the following? The link would be a new page that explains color correction in a much more broad sense with a section on how to properly optimize the images. Trig - 19:00, February 19, 2020 (EST) This image has color changing metadata and should not be optimized. Delete Template:No license Images should have licenses. That's how copyright law works! It's critically important that if we have an image on the site, then we use some form of copyright with it. Sometimes, the uploader doesn't know how to tag it. If they don't they can use {{don't know}} and Category:Uploader unsure of copyright status (which has a fairly large number of items in it, by the way) and request another user that knows how to categorize the image to indicate it. This template, however, does not make sense to have. Simply put, if we the collective don't know the copyright status of an image, we do not keep that image. Its so rare that one cannot be categorized anyway, but should an image be so uncertain that multiple people cannot determine its status, it will err towards safety and not use said image. In short, delete this template and its category because the image that would be tagged with this would be deleted anyway. Proposer: Trig Jegman (talk) Deadline: March 1, 2020, 23:59 GMT Support (delete it) Trig Jegman (talk) Per proposal TheDarkStar (talk) - Per proposal. Supermariofan67 (talk) - Per proposal. FanOfYoshi (talk) Per proposal. Toadette the Achiever (talk) Agreed. Obsessive Mario Fan (talk) Per all. Niiue (talk) Per all. Oppose (keep it) Comments