MarioWiki:Proposals/Archive/55

OK Boomer (Move Boomer (Super Paper Mario) to Boomer (Pixl)?)
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: Deadline: Jan 6, 2020; 23:59 GMT Date withdrawn: December 31, 2019, 01:56 GMT

Move Boomer (Super Paper Mario) to Boomer (Pixl) only

 * 1) - 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

 * 1) 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 -- 20:56, December 30, 2019 (EST)

Compile Play Nintendo puzzle activities in a single page
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:

A few notes:
 * 1) 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.
 * 2) 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: Deadline: January 16, 2020, 05:27 GMT

Support

 * 1) per proposal
 * 2) - 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.
 * 3) Per Obsessive Mario Fan.
 * 4) - Per all.
 * 5) Per all.
 * 6) Agreed - I support the idea of using less space and simplifying navigation without losing the actually relevant information
 * 7) Per all.

Remove tense
The 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 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:

Deadline: Feb 18, 2020, 23:59 GMT

Support (Delete the template)

 * 1) per proposal.
 * 2) Ye I had no idea it was a thing, but it's pretty much pointless. Per proposal.
 * 3) - Yeah, that makes sense to me.
 * 4) - It's only used on one page, and it doesn't even have a dedicated subcategory, so I'm for deleting this.
 * 5) We don't need sub-templates for every specific way an article can be badly written. Just use the "reason" parameter.
 * 6) Per all.
 * 7) Per proposal.
 * 8) Per all.
 * 9) This template is redundant. Per all.
 * 10) Per all.
 * 11) Practically useless. It's an issue that's extremely easy to fix.
 * 12) Per all.
 * 13) Per all.
 * 14) If it’s redundant and almost unused, we can get rid of it.
 * 15) As another proposal by Super Radio (or is it Results May Vary), this is redundant.
 * 16) Per all.
 * 17) If it is hardly used, it must be removed.

Comments
Actually, it's on Mario & Sonic at the Olympic Games Tokyo 2020, too. But I still don't see a use for it. 00:31, February 12, 2020 (EST)

New Template:Gamma Image
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,, would be placed on the documented images with gamma brightening:  This image contains gamma brightening, and should not be optimized.

 This image contains gamma brightening, and should not be optimized.

Such images seen thus far is:
 * 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:

Deadline: Feb 19, 2020, 23:59 GMT

Support (Create template)

 * 1) Per proposal
 * 2) per proposal
 * 3) - Per proposal.
 * 4) - 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.
 * 5) 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.
 * 6) Per all.

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. 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! 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. 15:05, February 19, 2020 (EST)

It seems that "original" does not necessarily equal "accurate" in all cases. Take File:NSMBU Luigi Jumping Artwork.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  option to   or the   option to. 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.-- 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. -- 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. -- 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. -- 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. -- 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. -- 18:24, February 19, 2020 (EST)
 * Perhaps it would be more appropriate then to use, 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 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:

Deadline: March 1, 2020, 23:59 GMT

Support (delete it)

 * 1) Per proposal
 * 2) - Per proposal.
 * 3) - Per proposal.
 * 4) Per proposal.
 * 5) Agreed.
 * 6) Per all.
 * 7) Per all.

Delete Category:User eo
The language of Esperanto is not a real language. The auxiliary language was initially created by some linguists to attempt to be universal in application, but nobody really picked it up. As a result, it is not even a secondary language for any country in the world, and has fewer than 10000 'native' speakers (about 5000). Henceforth, it's application in the real world is virtually non-existant. As I like to joke, since we keep this around, why not add Klingon?

Nobody speaks this language. Nobody utilizes the category to speak this language. Nintendo does not even sponsor or support it as a language. It's unnecessary and (frankly somewhat appalling) that we continue to support a language that does not exist, and therefore this category should be removed.

Proposer:

Deadline: March 5, 2020, 23:59 GMT

Support (delete category and esperanto support)

 * 1) Per proposal
 * 2) Laŭ propono
 * 3) - Per proposal.
 * 4) - Per proposal (I'm all for a Klingon template, though).
 * 5) Per proposal.

Add categories to the MarioWiki babel for Bengali, Urdu, and Hindi-speaking users
A proposal is not necessary for creating categories for languages, especially such common ones as these. As Babel already says, if you speak the language, you're free to just create one.

I look at the MarioWiki babel and see three languages missing: Bengali (also known as Bangla in Bangladesh), Urdu, and Hindi. As a user of Bangladeshi descent, I'm quite surprised to see that Bengali isn't included in the babel; I'm also surprised that Urdu and Hindi haven't made it into the babel yet, either. It's proven that 425 MILLION people worldwide speak Hindi, another 300 mil speak Bengali, and another 100,000,000 speak Urdu. We're talking close to 850M speakers of these 3 languages; that's a rather large portion of the world's population! Don't ya guys think it's time we update the babel?

Proposer: Deadline: March 23, 2020, 23:29 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal.

Delete Category:User ka
The Georgian language is esoteric to say the least. With just under four million native speakers, it's not a common language to come across. Simply put, it does not have a common application. Nintendo does not support Kartuli Ena (the language) on it's consoles or releases either. It is unlikely that there is ever a need for this language to be spoken, but should it be desired later that someone wants to show they speak the language, it could just be represented by the direct code. It does not make sense to support something that has been unused (and is unlikely to be used).

Proposer: (Blocked)

Deadline: March 22, 2020, 23:59 GMT

Support

 * 1) - Per proposal.

Oppose

 * 1) The thing is, this wiki should be a place pertaining to everyone. So what if Georgian is a less commonly spoken language? Does that mean we're gonna exclude the Georgian-speaking minority by removing their language?
 * 2) Per MarioManiac1981.
 * 3) Per all. I understood the Esperanto one somewhat, but I personally feel trying to prune every single instance of an "unpopular" language is a bit above and beyond the call. I feel like the "not an officially supported language" reasoning is flawed, since that shouldn't and doesn't necessarily stop a fandom developing among those speakers - fan translation communities do exist for the "bigger" languages after all, and the Babel doesn't exactly have any entry barriers to those wishing to utilize it, as JC indicated.
 * 4) - Per all.
 * 5) Per all, Lord Grammaticus in particular. Also, you say this could be represented through code if needed in the future, but if the category's deleted there's no substitute for it. Whether or not a language is supported by Nintendo is a moot point as you can speak that language while still enjoying their games (i.e. fan translations, knowing a secondary language that is supported, or just ignoring text entirely if you want to go about it that way). Trimming language support here down to what's "official" because Nintendo supports it is going a little off the deep end in my opinion.
 * 6) - I don't really see the disadvantage of keeping it around, considering that it actually has native speakers (unlike Esperanto).
 * 7) Per all. The fact that it's not on Nintendo systems doesn't disclude it from here, and "because it isn't spoken much" isn't a great reason either.
 * 8) Per all.
 * 9) Per all.
 * 10) Per all.

Create a "character/species" infobox
So as time has gone on, we've gotten to where entities can be interchangeably considered characters and species. Some of these, like Yoshi, Toad, and Kamek/Magikoopa, have enough respective information they can stay split relatively soundly. Others, like Draggadon, Dorrie, Koopa Kid, and Wiggler (to an extent) are not split, and doing so would be inconvenient both to read and to write and would more than likely require fancrufting to decide where the distinction lays. Others, like Birdo, Boom Boom, Krusha, and Klump probably should be merged due to how their creators treat them wholly interchangeably as a character or species, but are still split nonetheless. The main reason I see preventing that (as well as making the already-merged ones a bit awkward) is having to decide which infobox to use: character or species?

My proposed solution is simple: just have a combined infobox for wider-interpreted entities. This way, we can say other members of a species and their relatives while still acknowledging the "character" aspect exists to whatever extent it does in that particular case. I have code below, view page source to see. It includes all the main important facets (including the "relatives" parameter I didn't realize we'd implemented...) without any redundant parameters like "species."

Proposer: Deadline: April 16, 2020, 23:59 (GMT)

Support

 * 1) Per proposal
 * 2) Per Doc's reasons, he's already done something similar on a wiki we've been working on. This isn't completely related, but one reason I'd support is because the current species infobox have parameters like   which displays "Variant of"--this makes the source name inconsistent with the displayed name. It would be great if we could change these parameters, which I've been wanting for a while.
 * 3) Well, I think having a unified template can help as an initial step in trying to approach this character/species oddity, even though at the beginning it might be used just for a few cases like Draggadon and Dorrie
 * 4) Sounds like a good idea, and honestly, Boom Boom should have just been merged a long time ago as the two separate articles are pretty much duped: we can easily make a general Boom Boom article and note discrepancies in their general information section surrounding the inconsistency.
 * 5) Per proposal.
 * 6) I don't really want to go down the "merging characters and species" rabbit hole, but admittedly that's just me clinging to nostalgia and this would probably be better for organization.
 * 7) Per all.
 * 8) Per all.
 * 9) Doc's got the right idea, it's a small step at the moment but it'll be something.
 * 10) Per all.
 * 11) As they say, "why can't we do both"?

Comments
Not sure how I feel about this right now, but this got me thinking - why don't species infoboxes already have a section for portrayals? Shy Guy and Wiggler come to mind as enemies that could benefit from it, and it's a lot neater than just throwing it in the opening somewhere, or worse, neglecting to mention it at all. -- 12:03, April 9, 2020 (EDT)