MarioWiki:Proposals

List of talk page proposals

 * Split Category:Super Mario 64 into Category:Super Mario 64 and (discuss) Deadline: Passed

Writing guidelines
None at the moment.

New features
None at the moment.

Removals
None at the moment.

Splitting Large Galleries
As I mentioned here, Mario's gallery page is incredibly large; over 87,000 bytes, which makes loading take a significant amount of time. The following proposal wouldn't just effect Mario's gallery, but all gallery pages in general.

Once a gallery page reaches a certain number of bytes, around 50-60K, it starts to lag on loading time. So I'm proposing we split those pages up once they reach that amount into separate pages to help cut down on loading times and lessen the strain on our computers, as well as making navigation easier. The page would be split into the following pages like this:

This gallery page would contain all the artwork from various games as well as scans of the subject from books, magazines, manga, etc. I'm grouping them together as these two things seem to coincide with each other, and it doesn't seem right to split them.
 * Gallery:(name) artwork and scans

This gallery page would contain the many sprites of the subject.
 * Gallery:(name) sprites

This gallery page would contain all the screenshots from games and animation we've captured of the subject.
 * Gallery: (name) screenshots

In the case of the original gallery page, it would become a disambiguation to guide users and readers to the proper location. Additionally, sample images relating to the linked page can be included to give readers an example of what to expect. In Mario's case, the page would look like this:

"Due to the size of this gallery, it has been split to reduce loading times.
 * For artworks and scans of Mario, see here.


 * For the gallery of images relating to Mario's younger form, Baby Mario, see here.
 * For images relating to Mario's powered-up forms, see here ."

I don't know if the opening statement really needs to be there, but it'll help users who weren't aware of this proposal to split (should it pass) explain why this gallery page is different from the rest.

Should this proposal pass, the Galleries page should be updated to reflect this change. The navbox would also have to be updated to reflect the change, for example: "Mario (Artworks and Scans · Sprites · Screenshots)"

Proposer: Deadline: Friday, January 27th, 2017, 23:59 GMT

Support

 * 1) Per my proposal above.
 * 2) – Per proposal.
 * 3) Sounds like a good idea to me. Especially since Mario gets like 4 or 5 pieces of individual artwork per game.
 * 4) – Per all.
 * 5) - This is definitely needed, per proposal.
 * 6) - Per all.
 * 7) Splitting pages to curb length and loading time strain is relieving and sometimes even necessary considering that browsing through high-traffic pages can be overwhelming both for the browser and the reader. In addition to this, splitting upon length alone is a much easier task with galleries than it is with articles, because they're, well, image repositories. The only things I feel need to be covered are how the  will be edited accordingly to this change and where or whether we should draw the line for gallery sizes, but other than that, everything looks fine, so per Alex95.
 * 8) Per all. (Note: I am wondering which galleries are above 50GB? It will help the proposal.)
 * 9) Per all
 * 10) Anything to keep loading times more bearable. Sure thing except finding appropriate Mario images to shitpost in the forums will be more of a challenge tho . Now, what do we do with those Bowser and Mario pages in this wiki...
 * 11) Per all. Hopefully this can happen on most of the larger galleries.
 * 12) Per all.
 * 13) Per All
 * 14) Per all.

Comments
Let me get one thing straight, while the Wiki-code for Gallery:Mario is 87KB, the generated HTML (i.e. the code that actually gets loaded) is 997KB (which is compressed to 95KB when sent to your browser). Including the images, the size (compressed) will be 21MB, which is the actual culprit of the loading time (1+ minute). (On mobile devices this is even 58MB / 2 minutes) 18:31, 20 January 2017 (UTC)
 * Ah, okay. I, uh... didn't know the technical stuff. I just knew the page was taking too long to load and I wanted to do something to fix it. 13:38, 20 January 2017 (EST)
 * The problem is valid though, even if the effective numbers come from a somewhat different source. (Also, just an info, you can vote and support in your own proposals.) 23:17, 20 January 2017 (UTC)
 * Yep, completely forgot to do that. I'm out of it today... 18:22, 20 January 2017 (EST)

Could it be worth to have a small sample of each gallery on the main Gallery page instead of it just being a disambiguation page? Or maybe link to all pages from the main article? I'm just trying to save some users a click. -- 18:56, 20 January 2017 (EST)
 * Some example images are perfectly fine, yeah, I added that in. And doesn't the disambig example list all the pages already? I just showed the coding so users would know what to include. 19:03, 20 January 2017 (EST)

@, you bring up a point I completely forgot about: the. I've seen other templates use the following format whenever there is a grouped subject, e.g.: Mario (Artworks and Scans · Sprites · Screenshots). Would that work? 19:39, 20 January 2017 (EST)
 * Yes, that probably would. I'm not sure what else to say here other than, yes, it's important to be consistent, especially with navbox templates. 21:09, 20 January 2017 (EST)
 * Consistency is important! 21:18, 20 January 2017 (EST)

@YtSSM, the only gallery I've found so far above 50KB is Mario's, but Luigi's is getting close and probably the Mushroom's? Regardless, this will effect a gallery should it end up beyond 50KB. 22:42, 20 January 2017 (EST)

@Alex95 – I think that gallery template format would work fine for the most part. The only problem I can think of is the entry being separated to another line, The alternative would be to link to the "hub" gallery only, which leaves the subject with a single link on Template:Galleries. Because thinking ahead, it would be confusing to see split parenthesis lines throughout the template. 05:37, 21 January 2017 (EST)
 * Only linking to the "hub" gallery would make it easier, sure, but makes an extra step in navigating. Should there be an "Additional Galleries" section on the template? I can see the original idea working fine, but... sheesh, I don't know anymore :P I'm open to ideas, but I'm having trouble finding ways to make them all work correctly... 12:35, 21 January 2017 (EST)

Prohibit Converting Between GIF, JPEG, and PNG Formats
Converting between image formats is pointless and unconstructive maintenance. Why? Quality doesn't improve at all. There's also some misunderstandings how each image format works. JPEG to PNG preserves the JPEG artifacting (known as lossy compression). GIF to PNG keeps all the same pixels just to have a smaller file format because PNG compression is better than GIF compression (yes, there is a compression algorithm to GIF), which means improper colors are preserved because GIF is limited to 256 colors.
 * Introduction

PNG is the best format out there for web images but requires care to be wielded properly. It makes things harder to identify what needs replacing if improperly used. JPEG to PNG directly is improper use in general. This is especially true if it just to apply transparency that JPEG isn't capable of doing, which could fall under violation of a proposal prohibiting bad/fan transparency. The image that is in need of transparency should have a version that is officially applied by Nintendo, such as a press kit release. If it doesn't exist, don't convert to PNG (or edit the clean image if it is found to exist but not transparent). The file size will just be bloated at that point without affecting the quality at all.
 * What this proposal applies to

This doesn't apply to sprite rips or custom 3D model renders because the aliasing makes it super easy to apply so there is no potential for bad transparency. If there is a mistake, it can be corrected without affecting the overall image.
 * What this proposal doesn't apply to

This doesn't apply to replacing images if a clean version of that image exists or can exist. I replace screenshots and sprites often, especially if they are in the wrong format or improperly taken. You can see my images to see just how they compare to the image I was targeting to replace at the time.

If the image is found to be released in PSD or a similar format and it doesn't have transparency with all exposed layers, it might be possible to apply the transparency without it violating the bad transparency proposal.

Sometimes images are in the BMP format or some other raw format. That is OK to convert to PNG. No quality loss there.

However, if the PNG is seen to be too large for upload, even after compression optimization (10MB max at this time for each file), exceptions can be made to allow PNG to JPEG conversion. At that point, the JPEG will be of lower space requirements but the lower space requirements means lossy compression took place.
 * Exceptions

In short, keep the original format and don't convert directly. Do things properly. If this proposal passes, Image use policy needs to be amended to reflect the change. This applies to future uploading only. If it can be spotted that an image already uploaded is in violation of this policy change, deal with it on a case by case basis as things are discovered. No need to massively go through each an every image uploaded all at once.
 * Conclusion

Proposer: Deadline: January 30, 2017, 23:59 GMT

Support

 * 1) Per proposal
 * 2) - Per Wildgoosespeeder

Comments
Anything unclear? -- 22:45, 22 January 2017 (EST)

I think suffices to tell other editors that the image in question has JPEG artifacts or GIF 256-color limits. There are benefits of keeping things in a single format when the image size is small. When I created the list of Star Pieces in Paper Mario, I first used the screenshots from a 100% Paper Mario run on the Internet, which were similar to JPG, then replaced them with GIFs from the Star Piece guide on RPGClassics and finally retook them myself for successively higher quality. Since things were done in PNG at first, this saved the work of replacing all the images two times, with the additional benefit of preserving all the older versions for historical reference. -- 00:42, 23 January 2017 (EST)
 * There has been much debate over the use of that tag. I think it's best to just prohibit future uploads from converting the images so that way new debates if the tag should be placed on those images don't get started and existing debates can get resolved ASAP (any affected images that currently occupy Category:Quality requested). -- 01:10, 23 January 2017 (EST)
 * What if someone takes a screenshot from a YouTube video, like a Nintendo ad? I would save it as PNG to avoid another layer of compression, but the result would still be PNG with lossy compression. (Correct me if I'm wrong.) -- 09:54, 23 January 2017 (EST)
 * Even though the content is definitely heavily lossy compressed, compressing it as JPEG would cause further losses in quality, furthermore it can be subsequently replaced with a proper PNG screenshot without renaming. If no uncompressed or at least high bitrate lossy compressed source video can be found I would therefore say that in this case it is fine saving as PNG, stating that the source is a video and possibly including a link to the actual video.--Mister Wu (talk) 10:41, 23 January 2017 (EST)
 * I don't think those kinds of images apply to the proposal. This is more for artwork, screenshots, or other images obtained by means through someone else rather than through the submitter's own doing, like if the image they find through a Google Image Search is in the JPEG or GIF format and they submit it as a PNG instead. In general, I find that kind of practice plagiarism, unless the source is specified and there is no way for the submitter to replicate the result. -- 15:41, 23 January 2017 (EST)

Changing the Super Mario Wiki Logo!
It's time for the wiki to get a facelift and receive a brand new logo. The matter was brought up on the forums recently and I've been discussing it with several users, including Porplemontage. I presented a proposed design for the logo, and after a few adjustments I can now present it here: http://www.mariowiki.com/images/mariowiki_new.png This new logo is simple. Rather than displaying a piece of Mario himself, it shows the iconic mushroom. The mushroom is a symbol of the Mushroom Kingdom as a whole, similarly to how the wiki covers the entire franchise as a whole, even when Mario isn't the focus of a game. The current logo (seen at the top left of the page) is very dated, featuring artwork and screenshots from games that came out almost a decade ago. The proposed design is unique in that it won't become dated in a few years by each game that comes out.

What do you think? Should we change the logo to this new design, or keep the current logo?

Proposer: Deadline: February 1, 2017, 23:59 GMT

Switch to New Logo

 * 1) Per proposal
 * 2) I'm honestly going to miss the old one, but I agree, it's long overdue for a change.
 * 3) I like it!
 * 4) The design looks really good and everything Eldritchdraaks said about it symboling the Mushroom Kingdom instead of just Mario is really accurate. In other words, I like it enough for it to be the new logo. Per all.
 * 5) Per all.
 * 6) Preferably should be drawn with vectors, though
 * 7) Per all
 * 8) Per all
 * 9) Per all
 * 10) Since Mario's cap is not proposed as alternative logo, voting this one. Surely, a logo that doesn't become outdate is better.

Keep the Current Logo

 * 1) At the risk of sounding picky, I kinda like the current logo better. I have nothing against the one shown, but it's a matter taste and I just like the current one. If I need a reason why I like the current one, I like the screenshots behind Mario and the logo itself. While they are kinda hard to see, they do show a bit of the various games in the series overall.

Comments
The original file IS drawn with vector... mostly. It's x1500px.-- 22:45, 25 January 2017 (EST)

Miscellaneous
None at the moment.