Split all remaining courts/boards based on recurring places from their parent articles
passed 4-0
There's big inconsistently going on around the wiki partially revolving around stages in the sports games as well as Fortune Street that articles based on new places would be allowed their own article but those based on recurring locations will be forced to share an article (Bowser's Castle and Luigi's Mansion (location) amount the biggest offenders). What I don't get is that if they happen to stages from more popular games such as Mario Kart and Super Smash Bros., they get their own articles which isn't really fair. So I propose that all these sports courts and party boards are split from their parent article as I think the wiki is better off that way.
I was oringnally going to have this as a TPP on Bowser's Castle but I realised this issue was much present outside the article.
Proposer: NSY (talk) Deadline: September 24, 2016, 23:59 GMT
Yoshi the Space Station Manager (talk) per all. By the way, this proposal can be used for finding out which people are willingly wanting to be involved. If there is someone who is determined not to do it, that person would most likely oppose; but not all opposes (in theory) will be from people who are that way; there could be some who just don't want those to split but would do it if this passes.
Oppose
Comments
I like the proposed idea, but only if someone were willing to take the responsibility of making sure that the splitted sections do not become stub articles. For example, the Mario Hoops section in Luigi's Mansion (location) is severely lacking in information, and if that area in the game isn't very unique as it sounds (I know nothing about Mario Hoops 3 on 3), then it would turn out to be an awful article. Fawfulfury65 (talk)
I can ensure that those sections that are currently in states that would result in them benign stuby would be expanded to contain enough information. All the other courts from Mario Hoops 3 on 3 have enough info on them so it shows that it can be expanded to a decent length. NSY (talk)
NSY, there is nothing that has "forced" the merge with the main place articles. Nor does it depend on how "popular" games are. MarioWiki:New articles#Level articles already states that all individual stages (including SSB stages, party boards, racing and other kinds of sports stages) be given a stand-alone article. Most splits should be done immediately due to the acceptable size of the article sections. Some still require a "layout" section (such as the Fortune Street series boards which are still merged), which would guarantee an acceptable size according to the policy. The article identifiers would need to be determined, I suggest these for all the boards/sports courts.
Bowser's Castle (Fortune Street series)
Bowser's Castle (Mario Sports Mix)
Bowser's Castle (tennis court)
Bowser's Castle (basketball court)
Luigi's Mansion (Mario Sports Mix)
Luigi's Mansion (basketball court)
Luigi's Mansion (baseball field)
Peach's Castle (Fortune Street series)
I think these titles would be acceptable. The bottom line is, you don't actually need to pass a proposal to split these articles; we just need users who are willing to do so. This proposal should best be withdrawn. – YoshiKong (talk) 04:05, 18 September 2016 (EDT)
Pixl Queen, Waffle Kingdom, and Croacuses (rulers)
vetoed by the administrators This proposal is very disorganized; it's what should be three separate TPP's merged into one vague proposal. Additionally, you can't have a proposal ignore a rule (Rule #2) by saying users can only vote for one option.
It may seem like common sense to do right now the first two, but the third one wasn't mentioned in the passed proposal. The Pixl Queen story had a major part of the story before Super Paper Mario happened. The Waffle Kingdom has many characters from it. As for the Croacuses, they are former rulers of Floro Sapiens. I would like all three (more like 6 because the croacuses rulers are four, but I could do just the actual three rulers not the prince. Either way, the Croacuses are together.) be split from the respective articles, yet still have some kind of a mention in them. Because how this proposal is set up, only one choice can be chosen by a voter.
If you vote here, please say which two. The 2 highest will be chosen.
Do only one
If you vote here, please say which one. The highest will be chosen.
Tails777 (talk) Of all the three listed, the Croacus family are the only ones who are physically seen in some way. While they are just photos, having info on their pasts as well as an idea of what they look like puts them at more of an advantage against the Pixel Queen and the Waffle Kingdom. So if I'm gonna pick and choose, I'd say that the Croacus family should get separate articles, mainly since they have a bit more to work off of.
Alright, the options in this proposal are a mess. You can't have specific conditions on each option, options need to be absolute and clear. And you can't make the proposal ignore a rule (saying users can only vote for one option). To be honest, this feels like three proposals crammed into one. Either split this into three TPP's in List of implied characters our outright remove this proposal. --™The 'Shroom 22:45, 1 October 2016 (EDT)
Ok, I will let the proposal run during the weekend and sometime on Monday or early Tuesday, I will move it over to a more clear proposal(s) or cancel it all together. It all depends on the votes cast during this time. All those who do cast votes during this time will be talked to get them to vote in the proposal(s) if I do move it. Yoshi the SSM (talk)
Create or delete categories about an area's citizens
DELETE THE CATEGORIES 2-6-3
As far as I know, there are only two categories that catalogue every inhabitant of an area: Category:Rogueport Denizens (for Rogueport) and Category:Glitzville Denizens (for Glitzville). It seems rather inconsistent for these two areas, densely populated as they are, to be the only ones to group an area's characters together. Such a category wouldn't be necessary for a lot of locations, but there are at least a few others, such as Toad Town, Flipside, Flopside, Shroom City (although that's a near-perfect overlap of Category:Mario Party Advance Characters), and possibly others. Since MarioWiki:Categories has a minimum amount of only five entries for a category to be created, this could theoretically get out of hand quickly, but there's nothing that's stopping us from moving the goalposts ourselves. At the same time, though, it's not as if the subcategories are all that necessary, since both the Rogueport and Glitzville citizens have a home in Category:Paper Mario: The Thousand-Year Door Characters, and they don't offera . So, let's put it to a vote: either we create new categories for other cities (within reason, unless it's discussed otherwise), delete the two categories that currently exist, or leave everything as it is and say that these are the only two areas that deserve categories.
Proposer: Time Turner (talk) Deadline: October 2, 2016, 23:59 GMTExtended October 9 2016 23:59 GMT
Create categories
Yoshi the Space Station Manager (talk) This is my primary choice. If I had the Paper Mario: The Thousand Year Door, I would be an actual helper rather than just a supporter.
Quizmelon (talk) My primary choice. It makes a lot more sense to create than delete, even if it does take more work.
Delete categories
Time Turner (talk) The characters that live in a given area can be listed on said area's article, and they can be included in a table that gives information about them; one example of this in action is this table on Goomba Village created by A gossip-loving Toad. Having these categories just doesn't seem beneficial to me.
AfternoonLight (talk) I agree with him! So, let's get rid of it and per him!
3D Player 2010 (talk) I think we should do something for consistency, but I do not care what course of action we take.
Tucayo (talk) - A table would work much better. Per TT.
LudwigVon (talk) The table look way better for this than category. So, per Time Turner.
Yoshi the Space Station Manager (talk) This is my second choice. This wiki shouldn't just delete categories just because there is not enough of that category to make 5. If there is less then five areas in a game, would it make sense to delete those categories? The answer, unless they have no problem being with the game's characters.
Quizmelon (talk) My second choice, I just don't think deleting is a good idea.
Comments
Just to clarify what the proposal is this effecting, which category? Paper Mario: The Thousand Year Door characters, area characters, Paper Mario: The Thousand Year Door area charcters or another? Yoshi the SSM (talk)
I'm quite neutral about it. 31 and 34 pages in the "denizens" categories would make a very large list, unlike the example that SMW:CAT gives on Aquatic Attackers, which is a very small list and already makes navigation with a category unnecessary. This is why we have "[game] Levels" categories, and "[game] Bosses". Sure, they could already be listed on the game article (with the table that you suggested). But since there's already a lot of other kind information on the game page, relying on a long and detailed page list could become quite exhaustive to navigate with. That's why we have "levels" and "bosses" categories for games. – YoshiKong (talk) 03:11, 25 September 2016 (EDT)
I didn't mean that the game's article would have a giant table; that would easily become way too big. I was suggesting that every location would have a table that lists the NPCs in that location. Hello, I'm Time Turner. 18:26, 25 September 2016 (EDT)
@Yoshi the SSM: By voting for the "Do nothing" option, you're saying that the Rogueport and Glitzville categories are the only two that should exist, and that no other will be created. Since you seemed confused about the proposal's intentions, I wanted to make that clear. Hello, I'm Time Turner. 18:26, 25 September 2016 (EDT)
Let me remind you that it is the second choice I am taking, not the first. It means that I would rather have nothing done than a deletion. I also rather create categories rather than doing nothing. Also, it is fact that people don't become leaders in most situations. Yoshi the SSM (talk) 23:23, 25 September 2016 (EDT)
I don't see what's wrong with with having a category for the citizens as well as a table on the locations' articles. The Donkey Kong Country article has a list of all the levels and the game also has a category for its levels. One is a list of links and the other is a list of information. The categories for the Mario Party Advance characters wouldn't be too small, either. There are several locations in every city with many characters. Same for Paper Mario places. Fawfulfury65 (talk)
I just find it to be a needless division that makes it harder to find certain information without offering much in return (as per MarioWiki:Categories, only the lowest subcategory is placed on an article; anything higher isn't used). I don't think it's particularly beneficial to have a category for a given location's characters when those characters are already listed on the location's article. Anyone looking for its inhabitants would already go to the location's article, so the category doesn't offer any added convenience. Hello, I'm Time Turner. 23:22, 28 September 2016 (EDT)
I'm not sure if I really like the "anyone looking for its inhabits would already go to the location's article". Wouldn't this be akin to saying that we have a list of all Goombas in the infobox of the Goomba article; therefore, we don't need a Goomba category? Or we have a giant list of enemies, we don't need Category:Enemies? And so forth. I myself don't exactly see the harm in including a category like this, which does add one layer of organization without being frivolous. The rules say, if the area is too small to have enough characters for a category, let common sense dictate that case and don't create the category. That doesn't seem that hard to me. It's me, Mario! (Talk / Stalk) 14:29, 29 September 2016 (EDT)
The Goomba article, at best, only has an undetailed list of species and characters in the infobox and a brief description of each of them smushed between the actual Goombas. A simple list alone is not what I want, but the table that I had suggested would be more helpful than the category. It's hardly unreasonable to say that someone who doesn't know the name of a character would go to the article of the location in which they appear, which is something that a category cannot do. The harm that I see in these categories is that the sky can actually be the limit: as I said, a category technically only needs a minimum of five entries to be accepted, and there are plenty of locations with more than five characters; common sense as to what the limit should be or which locations should or shouldn't get articles can vary wildly between people. Even if there's a rigid system that works perfectly and logically, the end result will be that there's a main category which contains the bulk of the characters and then a bunch of smaller categories that needlessly disperses a handful of other characters, making it harder for navigation. I do not see the benefit in having that. Hello, I'm Time Turner. 14:44, 29 September 2016 (EDT)
Move Yoshi, Donkey Kong and Wario (series) pages to * (franchise) and retool
Move and retool 6-0
This has been bugging me for a bit, and looking at the series pages (which are, in general, a fully acknowledged mess) while tidying up the tables over the past day or two hammered that these three are simply not series - for DK and Yoshi in particular, the only commonality between them is that they feature the named character to some degree, usually in the title, being motley mixes of platformers, puzzles and "other". In addition, there are a bunch of series-within-these-series (including Wario) that get their own pages with nigh-identical content based on a subset of the page, in clear violation of MarioWiki:Once and only once (compare Donkey Kong (series) to Donkey Kong Country (series), for instance).
What I'm proposing is that we retool along these lines. Not deleting or merging anything for now, just splitting a couple of things and reducing duplication on the basis that this'll be enough to be getting on with, since the series pages have long been a triumph of ambition over accomplishment...:
Donkey Kong
Nearly everything is already on a (sub-)series page anyway. Complete the job, remove the MW:O&OO-violating material and look to make a proper overview
Donkey Kong (franchise) - overview page. Initially this will probably be fairly short, but the ultimate goal is to have something along the lines of SethAllen623 (talk)'s reworking of Super Mario (franchise)
Donkey Kong (series) - basically, this becomes everything based on the original arcade game and the sequels thereof (so the arcade games and their ports, Game & Watches, Donkey Kong GB)
Donkey Kong Country (series) - in the short-term, not terribly different from now. (Currently includes DK64, and I would keep that. Indeed, I would merge...)
Donkey Kong Land (series) - frankly, I think this should be merged with the DKC series page, which it has to be viewed in the context of, but unless there's heavy support for that, keep it as it is for now
Yoshi the Space Station Manager (talk) Have those three as franchises? Yes. Have Donkey Kong Land part of the Donkey Kong Country? Best to keep them separate. How to do the franchises? Just like Super Mario (franchise). Why do I support the idea of making like the Mario (franchise)? Franchises must be similar in appearance. Series can be better, but I don't care much what happens to them. Also, they are more than just series. If you were to look at Super Smash Bros. (series), you will find out that their symbol is the franchise they are from. How long this will take to get completely done? Quite a while. 5th year of the Nintendo Direct will come before this is completed and probably the NX will come before this is 100% completed, but this last one is a bit of a stretch since the official date isn't known and this should take more than a month to do. Short answer is, I support the decision to do the proposal.
Luigi 64DD (talk) This sounds like a good idea to me. About merging the DKC series and the DKL series, it sounds like a good idea because they are so similar, but I'm not sure because of the name difference.
Fawfulfury65 (talk) Per above. Also, I want to comment that I understand the reasoning behind wanting to merge the DKC and DKL series, even though I don't like the idea. While it's true that the DKL games are in no way remakes of the DKC games, they do have the same protagonists and antagonists, which make up the main bulk of the Donkey Kong Country (series) article. If we put that info in the DKL article, which is awfully short without it, the information would be repeated.
Oppose
Comments
3D Player 2010: I genuinely don't think you understand what I'm suggesting. RIGHT NOW, "the Arcade based Donkey Kong games including the Mario vs. Donkey Kong series" are "lumped" "in with the more standard Donkey Kong series". I am not suggesting getting rid of, e.g., Mario vs. Donkey Kong (series) - note the words "not deleting or merging anything" as part of the proposal. Indeed, I'm suggesting creating a page JUST for "the Arcade based Donkey Kong games" at Donkey Kong (series), which is currently the "lump everything in" page. If this passes, there will be more pages, not fewer, but with less duplication [compare Donkey Kong (series)#1990-2000 and Donkey Kong Country (series)#Original titles as they presently stand). The retooling of what was "Mario (series)" and is now Super Mario (franchise) did not obliterate, for instance, the list of games on Super Mario (series). - Reboot (talk) 01:22, 12 October 2016 (EDT)
@Reboot: If it is okay with you, I will get to work on changing the Yoshi series to the Yoshi franchise as soon as this proposal passes. This would include creating two pages, so I have to ask. Yoshi the SSM (talk) 10:18, 17 October 2016 (EDT)
Okay. I want to do DK first anyway. - Reboot (talk) 17:17, 18 October 2016 (EDT)
Okay. I will get the first part done as soon as possible. Yoshi the SSM (talk) 17:24, 18 October 2016 (EDT)
Change the rules of BJAODN
canceled by proposer
I think that we should change 5 rules of BJAODN to allow things even funnier to happen.
Proposed Rule Changes:
These changes are things proposed to be added to the rules
These changes are things proposed to be removed from the rules
The bad jokes and other deleted nonsense archive is the fun and controversy archive on the super mairomario wiki. Its purpose? To have the most bad works documented. for fun!
On a more serious note, this archive was created to store vandalism and poor writing that users consider to be humorous. The archive is for anyone to edit, as long as the added content satisfies one condition: it must be funny.
Before editing, please read the following rules:
This is not a general vandalism archive.
While it is true that what may be considered "humorous" is fairly subjective, common sense should play a part here. The Mario article being replaced with something along the lines of "MARIO IS A [insert swear word here]" is not funny; it is childish and obnoxious.
Do not add impertinent content to the archive.
As stated above, information containing vandalism and poor writing is the only type of content that is acceptable to add here. Such content may include entire articles, sections of articles, or "joke" proposals, but may only be taken from valid wiki articles or MarioWiki:Proposals. Content derived from user talk pages or any other namespace is not allowed under any circumstances and will be removed on sight.
Users reserve the right to remove content which they wrote.
The focus of this archive is to store vandalism and poorly written material deemed to be humorous. However, there is an exception: if something you wrote happens to be archived here, you have the right to remove it if you wish for it not to be there (this obviously does not apply in the case of blatant vandalism). For this reason, there should not be any edit warring between users over any specific section being removed.
Newbie bashing is not tolerated.
There is a difference between poorly written articles that new users may be susceptible to creating and something so confusing and devoid of information that you become suspicious of the writer's sanity. We accept only the latter variety in this archive. An exception exists if a user wants to add content that they wrote themselves when they were a newbie themselves to the archives.
Don't write badly on purpose.
Don'tFeel free to create all-new material just to add to the archives, but don't alter existing material to "make it funnier" (although feel free to alter existing material to fix minor spelling and wiki formatting errors), and definitely don't vandalize actual articles in order to get them into BJAODN, because you will be punished.
Here are a few tips for organizing BJAODN pages:
Entries should be placed in alphabetical order.
Entries that have obviously bogus Red Links should be replaced with the {{fake link|}} template, like this.
Commentary is permitted, but users should show restraint in this matter. Commentary should make the entries funnier, and commenting just for the sake of commenting will be removed, as will lengthy back-and-forth exchanges.
You don't need to ask permission to add something.
Summary of ideas:
The first rule change is basically fixing a typo in the page.
The second rule change creates an exception to a rule. I understand why that rule exists, as we are trying to not offend people, but if someone thinks that something they wrote in the past when they themselves were a newbie, deserves to be added, why not? If having it added would truly offend them, then they would not add it. It's that simple.
Some people might have a desire to be creative with BJAODN entries. Currently, the rules do not allow that. The third rule change allows users to be creative, and expands what can be added to BJAODN, which would make BJAODN even funnier.
Sometimes BJAODN content is written with minor errors added onto the existing nonsense. I think we should cut out the minor errors, and simply leave only the nonsense remaining. The fourth rule change does just that, allowing users to fix spelling and wiki formatting errors in BJAODN entries, so that the entries become entirely nonsense.
The fifth rule change allows users to start conversations about how they feel about BJAODN entries. Having such conversations would make things funnier, by allowing users to talk about the nonsense, in addition to the nonsense already being there.
If necessary, we can implement a rule similar to the Userspace policy where excessive BJAODN editing is a warnable offense, so that people do not overdo it, or create an account just to participate.
Proposer: 3D Player 2010 (talk) Proposed Deadline: October 27, 2016, 23:59 GMT Date Withdrawn: October 20, 2016, 01:05 GMT
Baby Luigi (talk) Having a huge all-or-nothing proposal to "fix" some of BJAODN's "flaws" is not the right way to go: for example, the first change you proposed was fixing the intentionally misspelled "mairo", so that's something I'm already against as it goes against the point of that sentence. Another thing is, we strictly forbid the creation of new content to go into this page for a reason: people will end up vandalizing pages and writing poorly on purpose just to get an entry on this page because they think they're "funny XD", as opposed to unintentionally funny content due to the result of genuine intentions but terribad bad execution. A lot of these fixes are just not suitable for proposal format, and they're better off with a regular discussion on the BJAODN's talk page. In my opinion, none of these changes would be beneficial to the BJAODN and they add several layers of unnecessary complexity to what should be an easy-to-understand thing: just take badly written stuff that made you laugh and at it on there.
Bazooka Mario (talk) Ninja: Very bad idea. I see the BJAODN rules as is as fine. One, the misspelling of "Mario" is intentional, as inferred from the bad grammar. We also have had a proposal that wanted to allow users to write badly on purpose, which massively failed. The reasons I'm opposing are the same as that one: allowing users to intentionally create content for BJAODN defeats the entire purpose of its humor. It exists to surprise and amuse users that someone had written a part and had the poor judgement to believe that it is acceptable. This proposal promotes bad edits, which is goes against the core of what this wiki is supposed to be about. Sure, maybe some of the stuff in BJAODN are Poe's Law in action, but this proposal would just open the floodgates and, in my opinion, ruin BJAODN since the surprise is gone. There is nothing to gain from this proposal except allowing users to have a reason to write badly. Anyhow, there isn't a rule against people adding their own poor writing from years ago, as it still retains BJAODN's purpose. The conversations about BJAODN should also be short and sweet or else they'll just be a stick in the mud and weaken the effect of the entry itself. There isn't a subjective rule, but conversations go on other venues. Same thing for writing bad on purpose.
-The typo is intentional.
-If someone wants to add their own contributions to the archive, of course they can do that. It's an obvious exception that does not need to be said.
-BJAODN's whole point is showcasing well-meaning errors along with the rare bit of clever vandalism. When I proposed the page in like... 2009, I think?... one of my argument is that it could even be faintly educational by showing people what not to do. Just allowing anyone to shit up the page not only defeats any pratical purpose it might have, but also open the floodgates for unfunny monkeycheese; to recycle what I said in an earlier proposal, past attempts to add original material on BJAODN were less funny than a documentary on Darfur war refugee camps.
-BJAODN is meant to be an archive of crap. Allowing people to fix errors runs counter to its whole point.
-Excessive conversations were agreed to be removed in forum discussions because they were unfunny and made navigation more tedious.
I do not agree with any of the changes proposed. --Glowsquid (talk) 19:36, 19 October 2016 (EDT)
I probably did not think through the full effect of the changes I am suggesting would entail. Under normal circumstances, I would withdraw this proposal. However, this is not a normal circumstance. Since so many oppose votes have already been cast, I cannot withdraw this proposal, due to rule 4 "Talk page proposals may be closed by the proposer at any time if both the support and the oppose sides each have fewer than five votes." 3D Player2010 20:17, 19 October 2016 (EDT)
Your quote literally has the term "talk page proposals" in it. This is not a talk page proposal. Hello, I'm Time Turner. 20:18, 19 October 2016 (EDT)
canceled by proposer
I just got done de-{{color-link}}ing the various Mario Party series templates (e.g. {{MP1}}), because the character names were picked out in "relevant" colours (e.g., Mario in red). Not only was this inconsistent with basically every other series template, but a lot of the uses were at best borderline illegible, with colours like yellow, gold and limegreen against light yellow. This isn't the only example of colours like those being used across MarioWiki, and it's always random and frequently hard-to-read. Not to mention that picking out a {{color-link}} in red breaks one of the most basic wiki precepts, since "redlinks" are empty/uncreated pages.
So I'm suggesting that it's just stopped. The only valid use of these templates should be where the default text colour would be hard (or impossible) to read against a background - e.g., the SMM3DS link in the footer of {{SMM}} against the dark red, the external links in the right column of List of official Super Mario Maker courses against the SMB sky blue (since it was decided that would be the best colour to put the costume sprites against on Costume Mario) or a couple of the rows in the table on Crystal Stars. No "...while Luigi jumps higher..." stuff any more.
EDIT: This will not apply to User:* or Talk: pages (including non-mainspace talk).
EDIT2: Okay, I think some further clarification is needed - I'm not suggesting removing all coloured text or backgrounds from the wiki as certain users seem to think. What I *am* saying is that links or text should not be coloured using these templates in Skittles-like fashion. It looks unprofessional, removes a degree of Wiki functionality, is frequently near-illegible and could cause further legibility problems if a "dark mode" is ever created (as is occasionally requested), whereupon the legibility problem would flip for those users such that dark colours specified in ordinary text with these templates would be illegible to them. They're a blunt instrument that isn't particularly well-suited to anything except colouring text in tables, navboxes and infoboxes - and in the latter cases, the colours should probably be specified with CSS site-wide rather than template-by-template (in the same way they already are to some extent for navigation templates), and in the former case they should be primarily specified alongside the table background (and if there's no background specified, that's bad for the same reason it's bad in text).
Proposer: Reboot (talk) Proposed Deadline: November 1, 2016 23:59 GMT Date Withdrawn: October 28, 2016, 10:16 GMT
3D Player 2010 (talk) This proposal, as it is worded, will apply to more than just template and mainspace articles, but also to userpages, signatures, and not just arbitrary uses, but also to lists where coloring is used to signify categories of some kind, for example. This proposal is simply way too broad in application by word of suggestion, that I cannot support it.
Yoshi the Space Station Manager (talk) {A Toad says, “Hey! Mario! Hurry! Hurry!” Mario jumps into the castle then says Luigi out loud. Luigi walks into the castle finishing getting ready. A Toad says, “It’s a meeting! Big meeting! You’ve gotta hurry, please! Everyone’s wating, Mario! In the conference hall! …Oh. Luigi came too. Super...."} Bowser's Inside Story with commentary from me. If games do this, why does this wiki don't do this? Makes no sense to me. Oppose.
Luigi 64DD (talk) Coloring should not be used in navigation templates or sentences like the proposal's example about Luigi jumping. However, it should be used in situations like the two examples Megadardery put below. This proposal is too general for me to support for the reasons in the first two sentences.
Baby Luigi (talk) I like some of the ideas here, such as banning color-link text in character sections in the Mario Party templates (which you already took care of before you started this proposal), but I don't think proposals are the best idea to handle misuse of colored text. It's better if we go along by case-by-case basis. I'd like to point out that yes, we always strive to be legible in the first place, so saying we can't use colored text except for legibility reasons is a bit redundant with already what we want to do and thus that part doesn't really need to be proposed. I'd also like to per Bazooka Mario's comment as well.
Bazooka Mario (talk) Per Luigi 64DD and Baby Luigi. 3D Player 2010 misses the point and I've argued against Yoshi the Space Station Manager's position on color text, that the colors serve purely a gameplay purpose (which is highlighting / emphasis for the player) that doesn't translate well to the wiki (make it look garish and distracting). If emphasis for the readers' curiosities is so important, then just make them regular links, which can also be piped for clarification (e.g. It ate that fat man!). I also believe legibility is already something we do. The policy on navigation templates already assumes the navigation templates use plain blue links so there's that. I do support removing the color links on Mario Party navigational templates, Mario Kart character galleries, adjusting color links in 3D World's character gallery to make them black, and removing color links on Mario Party character galleries (while restructuring their table to be color-coded so we keep how the games color-code their characters, but not on minigame list articles or on quotes where colors serve a meaningful purpose like Fawful's battle quotes rather than simply highlighting important information.
Regardless of the side implications that this proposal may include, it seems that it is just a shot in the foot. Although I might agree on that some applications of the colors are terrible, others are pleasant, because the characters were depicted with these colors in-game. There is absolutely no need to outright ban them.--
18:21, 25 October 2016 (EDT)
And yet, in your "pleasant" example, "Princess Daisy" is only barely legible. I very much doubt a light-orange/yellow on white is in the game. - Reboot (talk) 18:35, 25 October 2016 (EDT)
To be honest, I think the colors on Mario Kart 64#Drivers are fine, because they are used to present information categories that, in my opinion, could not be presented any better than the way it is now. 3D Player2010 18:31, 25 October 2016 (EDT)
Like the vast majority of examples. With a background colour, or with text. Which wouldn't invoke red/green colourblindness problems. (I have, however, clarified above regarding User & Talk pages, since it wasn't my intent to change anything regarding those). - Reboot (talk) 18:35, 25 October 2016 (EDT)
@Yoshi the Space Station Manager: So, what about the redlink problem? And are you planning to go through the whole wiki and colour every "Mario" red? - Reboot (talk) 18:40, 25 October 2016 (EDT)
No, I am not going to change every instance of Mario to red. The redlink problem you're talking about; MarioWiki:Maintenance has a place to find redlinks. There is also a problem with your plan. I was looking at a userbox colored black. If it didn't have white words, one would have to highlight it to read it. Probably very limited that there is black places (more than just userboxes), but I want you to be aware of this. Yoshi the SSM (talk) 18:49, 25 October 2016 (EDT)
And the vast majority of users will never look at Special:Wantedpages. But they will read articles, and if they see a red link, if they're at all familiar with Wikipedia, MarioWiki, etc they'll realise it's a "dead" link and possibly be tempted to fill it out if they're familiar with the topic. The more links that don't follow the standard colour coding, the less chance that has of happening. It actively harms the wiki. - Reboot (talk) 19:27, 25 October 2016 (EDT)
I find it interesting that you don't like red links, yet you have red links all over the place. A simple fix would be to create a userpage for your red links that you have. Any reason why you haven't created a userpage? Yoshi the SSM (talk) 20:28, 25 October 2016 (EDT)
I don't see the need for one. My userspace isn't in the encyclopaedic portion of MW, and I'd rather not waste the site's bandwidth & CPU with a bunch of userboxes that serve no purpose. - Reboot (talk) 20:31, 25 October 2016 (EDT)
I doesn't have to be very long. Look at Steve's. Yoshi the SSM (talk) 20:34, 25 October 2016 (EDT)
@YTSSM: Reboot clarified above that he didn't intend this proposal to cascade onto userspace pages, so userboxes aren't an issue to be concerned about here. – YoshiKong(talk) 18:54, 25 October 2016 (EDT)
@YoshiKong: I said after that more than just userboxes. Yoshi the SSM (talk) 19:04, 25 October 2016 (EDT)
...do you know what "for legibility reasons" means? If you don't, you should withdraw your vote. - Reboot (talk) 19:27, 25 October 2016 (EDT)
@Reboot: There is another problem which new users will have. New users don't know how to color code yet, so they will be putting down blue links instead of black links. As a matter of fact, I learned how to color code when I wrote my oppose vote. Yoshi the SSM (talk) 19:20, 25 October 2016 (EDT)
And they SHOULD be putting down blue links! That is, as they say, not a bug but a feature. - Reboot (talk) 19:27, 25 October 2016 (EDT)
Let me quote you: "the external links in the right column of List of official Super Mario Maker courses against the SMB sky blue (since it was decided that would be the best colour to put the costume sprites against on Costume Mario)". You intend to make them a different color. That would mean that you want all links to be the same. At least, that is what is implied. The most obvious choice of color would be black since it is the default color of regular text. Yoshi the SSM (talk) 19:33, 25 October 2016 (EDT)
Actually, that relates (1) to external links, since the external link colour is very nearly the same colour as the background there, so the redlink thing doesn't apply and (2) easily falls under "for legibility reasons" in the same way that text on a black background should not be black. - Reboot (talk) 19:59, 25 October 2016 (EDT)
The Mario Party 3 example looks mostly fine to me, and frankly, Princess Daisy was only made a little harder to read. But if there is a color coding that makes it incredibly hard to read, it should be removed. I disapprove of YSSM's idea because, while it may be good for in game text, it's not good for Mario Wiki's encyclopedic appearance. Lastly, I think color coding should be removed from navigation templates and generally from paragraphs in articles, but situations like the MP3 example are fine. -- (talk · edits) 18:58, 25 October 2016 (EDT)
@Luigi 64DD: I did not suggest that we should change the coding one bit. Here for clarification for others too. Yoshi the SSM (talk) 19:04, 25 October 2016 (EDT)
@YSSM I think you misunderstood me. I'm not talking about coding. I'm talking about this: "In Luigi's Mansion, Mario's Cap is one of the five items that Mario lost, and Luigi must bring it to Madame Clairvoya to receive information regarding Mario's whereabouts." That example is from Mario's Cap article. I added colors to it to demonstrate. If that is what you are saying, then I disagree with it. -- (talk · edits) 19:10, 25 October 2016 (EDT)
@Luigi 64DD: Like I said, I don't plan on changing every instance of Mario to red. For starters, that will be ridicules. Secondly, that is not what I suggested (as you can see Mario and Luigi not having color all the time in the passage). Yoshi the SSM (talk) 19:15, 25 October 2016 (EDT)
Then what are you suggesting? Having coloring for quotes that had coloring in the games? -- (talk · edits) 19:18, 25 October 2016 (EDT)
To keep color coding how it is. Not to go around every article and change every color code to black. Direct quotes don't have to be color coded as the text in game. Yoshi the SSM (talk) 19:21, 25 October 2016 (EDT)
There are very few at the moment. Partly because most of them have been killed over time. Hence why stamping it out entirely is an option. - Reboot (talk) 19:27, 25 October 2016 (EDT)
@YSSM Oh...The quote you put is misleading, because coloring is not used in sentences on this wiki. The quote made me think you were suggesting doing that. That's also why Reboot thought you wanted to change every instance of Mario to red before you clarified. -- (talk · edits) 19:31, 25 October 2016 (EDT)
Bottom line is: I can't support this since the implied statements. And now that I started using color coding, I don't think that a hard time reading may be a bad idea. Except in cases where it is impossible. Do that (and not near impossible), and I might accept. Also, don't have any implied statements. Yoshi the SSM (talk) 19:39, 25 October 2016 (EDT) Actually, I don't think it should happen because I like it how some things are colored. I not going to support something that will get rid of it even at a small level. It will lead to many things. Yoshi the SSM (talk) 19:47, 25 October 2016 (EDT)
Concerning EDIT2: Seeing as the examples that I do not think the color should be removed in use the templates, I am not changing my vote.-- (talk · edits) 20:08, 25 October 2016 (EDT)
While I do agree that anyone who ever coded in css yellow text against the white wiki background should be shot, I also believe that parts of this proposal isn't needed and writing a proposal to end the trend of specific cases here and there isn't wieldly, especially when all the formatting you suggested should already be inline with the common rules of color theory and design and it's simply because people who edit this wiki either didn't caught up with color design, were ignorant of it, or just didn't care about it. Your "legibility" reasons, it's incredibly broad and vague. Define what it means. Does it mean a certain degree of readability, or does it mean passing the contrast test? To me, deep gold on yellow isn't that illegible, and it's easily fixable to by using an even deeper orange or a darker yellow, something that is compromisable. I don't think the colors should be used in navboxs (like entries such as "Mario" and whatever), but I do believe they should be kept on the Mario Party character gallery pages, as well as the color formatting used in the Mario Kart 8 article. I'd also argue for some cases of using red-text: in Mario's case, where red text is most commonly used, of course people would know Mario's page is already created, and while people on mobile suffer from this as they can't hover over the link, if you hover over a dead link, it links to something different than a real link, which is how I even learned red links are dead in the first place.
ie I think this is a complex problem that a proposal itself isn't the best tool for deciding on an entirely black or white basis. I feel like more discussion should have been made before you jumped to making a proposal abolishing this and that color links which have their uses, especially when used to highlight differences between such and such so people can more easily identify what is what. Ray Trace(T|C) 21:35, 25 October 2016 (EDT)
I don't support the blanket thrust this proposal has (mainly because it may have unforeseen effects), but I'm for limiting color use a bit. I don't think there's really a need to give those links a different color, but this proposal's provisions can cover aspects not intended (would List of Mario Party 5 minigames be affected?). Anyhow, copying game text detail-by-detail which includes the colors such as in Yoshi the Space Station Manager's example or in areas like Speak Up bonus panels text doesn't translate well at all since they're two very different media. The game needs to highlight such text for purely gameplay reasons, to highlight important information for the player. For an example, check this revision in WiKirby. This text is colored exactly how it appears in game, but this is garish in the wiki and greatly hinders legibility. On the other hand, it might be helpful to color some quotes by, say, Fawful to fully understand the context. Some words he says are either red or green. For example, "You have readiness for THIS???" If these words don't have a random color (such as THIS always being red), then it would make sense to give those words a color. Finally, I don't find color text too harmful on the eyes, though gold-yellow and light gray contrast very poorly with white. While Mario Party and Super Mario 3D World somewhat has some reason for its colors, since those colors are assigned and used, there is little reason we should give color links to characters in Mario Kart games. However, those color links aren't even necessary or even good in the 3D World example I gave because the contrast is very poor and we already have color codes in the form of background color. I think in the end, we'll have to decide a case-by-case rather than impose a blanket removal. In the end, I do support removing some color links and probably just replacing them with something more appropriate like a table with color-coded pastel backgrounds when possible. That means rearranging the character lists in the Mario Party articles (the one Megadardery (talk) provided can be easily changed into a colorful table while we nix the color links or at least adjust them to make them legible in the color table), removing the character-specific color links in the navigation template, removing most color links in flavor text, and keeping the color links that do serve a purpose (such as in List of Mario Party 5 minigames and potentially in Fawful quotes and other quotes that use colors for context reasons) intact. It's me, Mario! (Talk / Stalk) 21:44, 25 October 2016 (EDT)
I'd also say that sometimes you need to use color links in the case of tables but again, it's supposed to be part of the "legibility" part of the proposal which is so broadly and vaguely defined that I feel like it was slapped in as a side-note merely to address comments that may bring it up as a legit criticism of this proposal rather than specify what will be done about them. Which all turns around to my case-by-case argument again. Ray Trace(T|C) 22:03, 25 October 2016 (EDT)
Allow .APNGs and create a notice template related to them
canceled by proposer This proposal will not replace the .gif format as the preferred animated format. Instead, it will allow .apngs only in cases where there is a clear benefit to using them.
Examples of images negatively affected by our GIF-only policy. Note the rough border edges.
We briefly had some .apngs running around in this wiki, though we have disallowed them mainly because of lack of universal browser support (notably, in Chrome).
The current animated format we use and prefer, .gif, however, is highly flawed. Not to mention, it's very outdated. This is because it supports only 256 different colors, making the images indexed, which isn't really much of an issue because most sprites are below this format. It also does not allow semi-transparent values, thus making it "all-or-nothing". It also usually isn't a problem, but recently, we have several images that use semi-transparent values, but are forced into a .gif format, thus greatly reducing the quality of these images. It also forces the transparency to look horrible and resemble a poorly-cropped image that goes against our own policy on transparent images. Arguably, this forced change also goes against our aim to give game-accurate impressions.
APNGs are intended to be a replacement for the outdated .gif images, but again, its biggest issue is that it lacks universal browser support, as in the comments before. Otherwise, for any other browser that doesn't support APNG I don't think we should have to bend backwards to stick to a superseded format. Still, there is a sizeable amount of browsers that don't support .apngs, and it has been shown to me that a majority of users here are Chrome, so we should not go full-on transition to .apng. Additionally, thumbnails cannot be rendered as animated when they're .apng images due to technical limitations, so they may not be immediately apparent since many images are used as thumbnails.
If this proposal passes, we'll have to create a notice template as in this proposal (see comments section). I also don't think we should get out of our way to convert every single .gif to .apng either, but we have to, at the minimum, allow .apngs. We might have gotten away with .gifs due to the simplicity of most sprites, but we have some recent games that use sprites that don't transition well into .gif at all, which includes Wario Land: Shake It! and Paper Mario: Color Splash and we have some miscellaneous animated images as shown here that would benefit from staying as an .apng rather than a .gif.
In brief:
This proposal allows .apngs because of transparency and indexing issues with .gif. .gif is an outdated format, and it shows.
A template on apngs will be created to warn users that use browsers without .apng support.
This proposal does not intend that .gifs must be replaced with .apngs. In fact, most .gifs should remain the as is. We use .apngs only when they have a clear advantage, which is accurately preserving colors and transparency values.
Proposer: Bazooka Mario (talk) Proposed Deadline: November 25, 2016, 23:59 GMT Date Withdrawn: November 19, 2016, 07:09 GMT
Shokora (talk) – If Porple is willing, this has my support.
Mister Wu (talk) The palette of the GIF format was a bit worrying, as I had noticed that some colors were indeed being replaced by different ones. Since I like to have images as faithful to the original ones as possible within the upload limits, definitely supporting this proposal!
Alex95 (talk) I don't even know what APNG is, or whether my browser can run it, but why not? It sounds useful. Get with the times, Mario Wiki!
Eldritchdraaks (talk) I support allowing APNG, but gifs should remain the preferred format because of it's universal support across all devices and browsers and image editing programs.
Oppose
Comments
Actually, if APNG images saved as .png files are used instead, the browsers that don't support APNG images can still show the first frame. Should we recommend APNG images in .png files instead?--Mister Wu (talk) 20:53, 18 November 2016 (EST)
I don't think that would be necessary. We should be using .apng only when it is absolutely needed, like those Color Splash sprite animations. It's me, Mario! (Talk / Stalk) 22:36, 18 November 2016 (EST)
By the way, would it be affordable to use javascripts that display APNGs on browsers with HTML5 canvas support? Just an afterthought, though... --A gossip-loving Toad (talk) 23:24, 18 November 2016 (EST)
That'll be something to ask Steve, and that's assuming he's on board with this (I hope he is). It's me, Mario! (Talk / Stalk) 23:35, 18 November 2016 (EST)
Though I support uploading APNGs, each should have a gif version uploaded as well. Even though it's supported by Firefox, Safari, and soon Chrome, there are far more browsers that don't support it. Gif, while not as great, is supported across all devices and browsers, as well as being easy to make. In most cases the low quality doesn't matter. I've been uploading a fair amount of the color splash gifs lately, along with Mister Wu. For their purposes to show the enemy idle animations, the gifs do just fine. But, I agree that it would be great to save the animation from the wiki to the desktop and keep its full quality from the sprite sheet. In such case, we could add a link on the gif file pages that can take you to the APNG version. I use Microsoft Edge on my laptop, and Dolphin on my phone, and neither of those support APNG to my knowledge.-- 00:00, 19 November 2016 (EST)
The Paper Mario Color Splash idle animations are the primary reasons for this proposal. The .gifs aren't fine to me because they index the transparency so the image looks very bad when placed against a background. Yeah, I don't think either Edge or Dolphin support apngs but most major browsers do, so I think we should settle on a compromise. .gifs should still be the most common format but where .apng is clearly better, it should be used. It's me, Mario! (Talk / Stalk) 00:07, 19 November 2016 (EST)
53% of our visitors use Chrome. Just because there is a bug report for APNG support in Chrome (as there has always been) doesn't mean they have anyintention of actually including it. So you can think of this proposal as asking, "Should we break animated images for the majority of our visitors?" Even if Google comes out and says they will support it, I wouldn't do anything until we can actually see it in action on both desktop and mobile. --Steve (talk) 01:02, 19 November 2016 (EST)
Okey, good point. I've reworded the proposal to not replace .gif as the preferred format, but merely to allow animated .pngs in cases where preserving transparency and colors is a big benefit. It's me, Mario! (Talk / Stalk) 01:09, 19 November 2016 (EST)
After adding-in IE, Edge, and some miscellaneous browsers that don't support APNG, the image animations wouldn't work for about 60% of visitors. I understand your concerns about image quality, but is it really worth breaking the animation for 60% of people so that 40% can see it in higher-quality? Mainspace articles should work the same for nearly everyone. It's a whole different story if Chrome starts supporting it, but we would have to wait for that to happen first. --Steve (talk) 01:34, 19 November 2016 (EST)
Hm, probably not. I would almost recommend making .apngs separate, which would work fairly well for the animated sticker images, but I realized that'll mean reuploading all those Color Splash enemies as .apngs as well AND providing .gifs and static .pngs to boot. Not a pretty picture. Anyhow, probably withdraw the proposal. Thanks, Google. It's me, Mario! (Talk / Stalk) 01:51, 19 November 2016 (EST)
My Browser doesn't support OGGs on this wiki. If I can handle that (even though I will never use it), then I can handle not being able to see APNGs. But I do agree that GIFs and APNGs have links to each other. Yoshi the SSM (talk) 01:53, 19 November 2016 (EST)
.oggs aren't as widespread as images though, so I think that's something we can conveniently ignore. It's me, Mario! (Talk / Stalk) 01:56, 19 November 2016 (EST)
That's why I said it depends on Chrome. Edge is such a small percentage that we wouldn't wait for their support. --Steve (talk) 02:00, 19 November 2016 (EST)
I would like to say that I use Microsoft Edge. Also, Paint Guy Idle Animation has a very small but noticeable bad look. It only comes when I look at it very carefully. But after seeing the flaw, I think that this flaw should not exist even if it isn't noticeable. One thing I don't really understand is why browsers don't support APNGs, but support PNGs. Yoshi the SSM (talk) 01:15, 19 November 2016 (EST)
The Paint Guy idle is only meant to be temporary. I knew it was bad when I made it, but I had no other options. 01:25, 19 November 2016 (EST)
Clarify the Wiki's policy on APNG images in .png files
withdrawn by the administrators and enforcing the "no change" decision At the time of the initial deadline, the proposal should have in fact passed when following a pending change to rule 9. The admins are currently working on updating the rule, and are withdrawing this proposal with a "no change" enforcement in order to avoid confusion once the rule is updated later this week. Asides from this, the wiki's proprietor doesn't wish to change any policies or regulations about animated PNG images, until it gains more support across different browsers and devices.
The replacement of .gif files with .apng files is not yet viable due to the lack of support on the browsers that have the majority of market share. There is however, a second case which is similar but also importantly different: that of APNG images in .png files. The first frame of this kind of images is shown by all browsers that support PNG images but not APNG images. In fact, as this example showsMedia:PMCS Ludwig Animated.apng, the Wiki infrastructure already supports them as well, to the point that the details about the animation are shown next to the image name, and there is even a warning message about the automatically generated thumbnails not being animated. The current image use policies don't forbid them either, the only way to know that they are not recommended is seeing an old proposal.
At this point, I think a final clarification on this special kind of images should be done, and since it is impossible for them to be used for all kinds of animation, I see two possible policies, beside that of not changing anything:
TOLERANCE
The APNG images in .png files should be tolerated in special cases where the first frame is already informative enough, while not being mentioned in the policies in order to avoid suggesting their use; for example, a rescaled (250px of width) version of my example image might seem viable for infoboxes (please note that it won't be actually used as such, it's just an example image!), as the first frame is already informative enough, while the animation is a welcome plus. Note that this scenario does not enforce modifying the current infrastructure to generate animated thumbnails; while this would be a welcome feature, ultimately an user using this kind of images should also take on themselves the burden of uploading and using versions of said images with appropriate width and height on the Wiki, with due notices when this needs to happen and it's not happening.
COMPLETE AVOIDANCE
The current image use policies should be updated to explicitly forbid the use of APNG images in .png files, automated measures to issue warnings on APNG images on .png files might be done as well, but they are not part of this choice, since the Wiki staff should be able to handle the few cases in which these images are uploaded already well.
Proposer: Mister Wu (talk) Proposed Deadline: November 26, 2016 December 3, 2016, 23:59 GMT Date Withdrawn: November 28, 2016, 22:48 GMT
Tolerance
Mister Wu (talk) I still think that, while they cannot fully replace GIF images and they cannot even be suggested as viable format for animated images, the APNG images on .png files can be useful in cases like the one I mentioned.
Yoshi the Space Station Manager (talk) For me, a static picture on my end would be better than a bad looking picture. And when the day comes that Google does support APNGs, APNGs will become more popular. Especially since GIFs are outdated a bit. I support APNGs in PNGs.
Lakituthequick (talk) I've been supportive in the past of APNG's that enhance the visual experience without being required, per that. Also see my comment below.
Bazooka Mario (talk) I think it's better to abstain until Chrome officially has APNG, which we hope won't be far away. Until then, we should just continue as we should.
Comments
Quoting myself from here: "There is no such thing as a .apng file, in the same fashion as there isn't a .agif file. The extension is always .png, animated or not." Be mindful of this.
Bulbapedia is a good example of good use. A lot, if not most sprites are APNG's over there. They don't appear to have any form of policy that I could find on it though, everyone just seems to go with it and tag them with a template. Lakituthequick 15:03, 19 November 2016 (EST)
Should we then create a template that highlights the nature of the APNG? The bold warning below the text may not be immediately apparent. It's me, Mario! (Talk / Stalk) 19:26, 19 November 2016 (EST)
A template more or less is a must-have to avoid people replacing them with static images. Here's an example of usage. To illustrate the effect, two animated sprites are used in the template, with the warning not to replace the image if neither sprite moves. Images are also categorised. We should have a similar template to warn users to not upload static images (minus the first frame thing, as that isn't always the case). Lakituthequick 04:04, 20 November 2016 (EST)
Thanks, though those pages are for the Wiki's main language (US English) only and won't affect users with a different display language. Lakituthequick 16:43, 20 November 2016 (EST)
Although the quality is nice and can completely replace GIF, APNG is not a mainstream format nor is it an official format like GIF is. Internet Explorer doesn't support it and Google Chrome requires a plug-in. Also PNG Monstrous doesn't play nice with it because it removes metadata, and I think APNG's frames are metadata to the PNG format. Also what are some programs that could be used to create these APNGs? It would be much better to distinguish APNG with PNG by extension instead of a template. I think that MediaWiki can support the extension, judging by Special:MediaStatistics. MNG is being developed by the same group as PNG so there will be a distinction unlike PNG and APNG, but no MediaWiki support yet. --Wildgoosespeeder (talk) (Stats - Contribs) 04:49, 20 November 2016 (EST)
MNG has already been released, but no browser development team wants to support it (Mozilla dropped support in its browsers in 2003); currently it's impossible to upload .apng images on this wiki (I tested this personally); the program you can use to create those APNG images are GIMP (I personally used it to create my example image) and VirtualDub (which I used to create this image); finally you're right, the other frames are in the ancillary chunks, meaning you should not use optimizers that get rid of ancillary chunks in these kinds of images (you should never get rid of ancillary chunks, by the way, as there are also those about gamma (gAMA chunk) and color space (cHRM, iCCP and sRGB), so you should seriously reconsider the use of these kinds of optimizations).--Mister Wu (talk) 06:26, 20 November 2016 (EST)
There is no reason to go about MNG as absolutely no support exists for it whatsoever, which isn't the case with APNG. Secondly, PNG is build around chunks, of which Mister Wu named a few. Some are indeed metadata, no problem (some of which you shouldn't delete, like author and copyright comments), others are used for the right display, gamma and animation chunks being examples. Optimisers just need to support these chucks in order to be viable, either be optimising them or ignoring them. The way PNG is build up makes the metadata-ness of a chunk up to what it does, not it's build. Another editor to add to Mr. Wu's list is RealWorld Paint, and there are some programs you can feed separate PNG's and frame durations. Lakituthequick 06:42, 20 November 2016 (EST)
This brings up an interesting question about how to optimize APNGs. Just like Photoshop, GIMP doesn't optimize its output if saved in the PNG format. PNG was never designed to be animated because the group thought that it would be dumb to add confusion to the format. Are there any programs that just "stitch together" PNGs to be outputted as APNG (no loading of the image to just be resaved and undo optimizations)? That's the only way I see optimization happen with APNGs. --Wildgoosespeeder (talk) (Stats - Contribs)!
I think this is outside the scope of the proposal, but I believe that most outputters will only save the changed region of the image as a frame, i.e. if only a small region changes, only that region is saved. This is according to standard and is good practice anyway. A frame is saved in the exact same format as a normal PNG image (though all frames must use the same format), just named differently. You can choose to replace the entire aforementioned region, or paint over it, the latter being a good thing if the region doesn't change much, but does contain a lot of detail. Enough optimisation opportunities. Lakituthequick 16:43, 20 November 2016 (EST)
THe APNG specification allows to code differences from previous frames using the Alpha channel, indeed, when adding the Alpha Channel in VirtualDub I obtained smaller file sizes in two cases I tested, in the case of my aforementioned example, without Alpha Channel the size is 224 MB, with Alpha Channel the size is 135 MB, so there are indeed many possible ways to optimize the output files; some of which are apparently already in use by current software.--Mister Wu (talk) 17:14, 20 November 2016 (EST)
Here's a different question; do APNGs work in iOS or Android? Also since the whole file is downloaded and nothing gets animated if it isn't supported, this could be really be detrimental to people with slow or metered connections. I'm pretty sure that GIF is massively supported and preferred in these cases. --Wildgoosespeeder (talk) (Stats - Contribs) 18:24, 20 November 2016 (EST)
They work in iOS, and are even used and recommended for iMessage. They will likely be supported in Android as soon as Google Chrome supports them (this might happen earlier than expected, as development should start in Q4 of this year according to the Google Chrome staff). Regarding the concern of data use, my example, despite being formed by 7 frames at 786 × 890 resolution at 32 bits per pixel (8 bits per color channel + 8 bits Alpha channel), is still a 686 KB file, while the GIF is a 345 KB file despite being palettized; since there is a 10MB upload limit on the Wiki and due to the nature of the proposal, the APNG images would be used mostly for in-game data, which is easily compressible with the PNG format.--Mister Wu (talk) 19:03, 20 November 2016 (EST)
For the sake of correctness, neither of the images were optimized; using GIMP's "Optimize (for GIF)" command I could reduce the file size of the GIF file to 201 kB, while the APNG image, optimized with APNG Optimizer 1.4 and 15 iterations of Zopfli, has now a size of 276 kB; I could verify that in the latter case the optimizations didn't change the images using APNG Disassembler 2.8 on both the original and optimized version and comparing the individual frames with WinMerge 2.14, showing that indeed there were no changes in each of the frames. I'm sorry for having reported data about unoptimized images, hopefully this wasn't relevant for the votes.--Mister Wu (talk) 21:59, 27 November 2016 (EST)
Current rule 9 still is All proposals that end up in a tie will be extended for another week. Proposals with more than two options must also be extended another week if any single option does not have a majority support: i.e. more than half of all votes cast must be for a single option, rather than one option simply having more votes than the other options., though. At this point, we need a clarification from the staff.--Mister Wu (talk) 19:27, 26 November 2016 (EST)
There are eight total votes, four cast for "not changing anything". That's not more than half, five votes would have been needed. --™The 'Shroom 20:50, 26 November 2016 (EST)
Thanks for the clarification!--Mister Wu (talk) 21:15, 26 November 2016 (EST)
No problem :) --™The 'Shroom 11:28, 27 November 2016 (EST)
But you misunderstood the proposal I linked to. There are 7 voters; as 1 voter picked multiple options. Because of that proposal; that is what counts, not the fact that there are 8 votes. There are 4 votes for the not changing anything option. That is a majority of voters (4 to 3); just as was decided to be necessary by the linked proposal. 3D Player2010 11:37, 27 November 2016 (EST)
The archives say that even though that proposal passed, the change hasn't been made yet. For some reason. SmokedChili (Talk) (Thoughts) 11:56, 27 November 2016 (EST)
We are currently reviewing this case and I'll get back to you. --™The 'Shroom 11:57, 27 November 2016 (EST)
All bestiaries will use templates rather than tables. ( look here ) - This gives a more appealing look, like an ID card, and makes it easier to fill out future bestiaries.
Each template will be based on the respective RPG infobox - Doing this keeps the enemy stats consistent between the bestiary and infobox.
All RPG infoboxes will use transclusion to display stats directly from the bestiary. ( look here ) - This makes distributing the infoboxes to each page easier, and ensures the infoboxes will ALWAYS have the exact same stats as the bestiary.
Now here is the code to display the Super Mario RPG bestiary template:
This keeps everything before it from being transcluded.
This is the label for this particular section.
This prevents the bestiary template from being transcluded.
This makes the infobox be transcluded on the target page only.
The name and the label must be the same.
(common, miniboss, boss, support, optional)
This allows the image to be changed separately in the infobox.
This allows controls of the infobox alignment. DON'T CHANGE HERE.
This keeps everything after it from being transcluded.
Now below is the code used for placing the infobox:
Yoshi the Space Station Manager (talk) It is about time I supported. I am not going to wait any longer. I didn't want to discourage other people from going first. Anyways, one of the reason why the Once and only once policy was enforced was because of the need to keep everything updated and editors may not get to all versions. This new proposal will transfer all information and even if it does break the Once and only once policy (which will most likely not happen due to the information needing to be both on the bestiary and the enemy which is part of the bestiary), it will not break the reason why it was enforced because if the bestiary is updated, the other places will automatically update and the editor won't have to worry about the other versions. And sorry if this is quite long, but I needed to say something about it kind of helping out the Once and only once policy.
Megadardery (talk) Per all, this is a great idea! Each game should have it's own template to transclude from as needed. I have a few further maintenance ideas that I will work on though.
Do the color-scheme you use for the templates here will be implement if your proposal passed? Walkazo's RPG infoboxes use the same colour-scheme as navigation templates for consistency, neatness and easy readability and in my opinion those color-scheme are better.--(TALK) 12:30, 22 November 2016 (EST)
The colors I used are not set in stone. I used the header color from the tables in each bestiary. The color-scheme will not be the same as the navigation templates, rather they will be different for each game.-- 12:45, 22 November 2016 (EST)
It looks like you thought everything through, but do we have to use your name to use the template? That seems a little inconvenient. And I agree with Ultimate Mr. L up there; it would take a while to implement them. 12:49, 22 November 2016 (EST)
No, you won't, don't worry. That is just temporary. That links to the bestiary page for that game, which right now is my userspace.-- 13:00, 22 November 2016 (EST)
This idea is fantastic, the template will indeed ensure that any stat corrections on the bestiary will automatically be corrected on the transcluded articles as well. I do have a question first: do you intend to only apply this to specific character bestiary pages, such as "List of Goomba profiles and statistics"? Or is there the potential to extend this to game bestiaries as well, such as "Mario & Luigi: Paper Jam bestiary"? Shokora (talk · edits) 18:02, 22 November 2016 (EST)
Everything you just said is exactly what I am proposing. This applies to all.-- 18:26, 22 November 2016 (EST)
Great, definitely supporting. I asked because I wasn't positive that it was taken into account with the single example that you gave. Shokora (talk · edits) 19:25, 22 November 2016 (EST)
I didn't give just a single example. I provided two links above to show the templates in use, and to show the stats transcluded to the infobox.-- 19:31, 22 November 2016 (EST)
Those would likely be replaced with enemy boxes. -- 12:05, 25 November 2016 (EST)
And become a duplication of the bestiary? I'd like there to be another template (in addition to {{User:Eldritchdraaks/PITbestiary}} and {{pitenemy}}) that extracts the HP, EXP, coin and location and put them into the original tables, because they looks so nice, and the misc stats will be too cumbersome when folded into cards. This also makes a sortable version of the bestiary available. --A gossip-loving Toad (Talk) 03:09, 26 November 2016 (EST)
It just seems unnecessary. Actually, it should probably be removed due to the "Once and Only Once policy". Your idea for a second template like the bestiary template doesn't make sense. That template creates a nice display on the bestiary page, it doesn't affect the enemy box at all. I get what you're going for though, but I can't setup another template like you want without breaking the first the system. Still the table there should probably go, even if my proposal doesn't pass.-- 03:30, 26 November 2016 (EST)
Worse comes to worse, if some people can't be bothered to look at previous edits of a bestiary's history when as a sortable table -- and believe me, there are folks out there that would still prefer to sort through enemies' stats, and that was my intention when making most of the bestiaries anyway -- then I suppose having an external link to such a version would be alright? --Zootalo (Talk)
Actually, using the history isn't that bad of an idea. PM, PMTTYD, and PMCS could be replaced with a sortable table, then we could revert that edit and place a link to it on the current page. But I still think having a second table like that on the main article would be against the "Once and Only Once" policy. It has to be directly transcluded from the bestiary, and we can't do that from template to table, or vice versa.-- 12:48, 26 November 2016 (EST)
It's possible with <includeonly>{{#if: {{{table|}}}|pittablerow|pitenemy}}</includeonly> and then {{MLPIT bestiary|transcludesection=xxx|table=yes}}. Another approach is to implement an ad-hoc alignment that output code for a table row, besides right, left and horizontal that output infoboxes. Haven't tried either approach, though. --A gossip-loving Toad (Talk) 00:06, 27 November 2016 (EST)
Actually, I think it would be best to do it just like Paper Mario: The Thousand-Year Door#Bosses. Here, only the bosses of the game are listed, and the bestiary is linked just above it. The formatting is decent, and the same thing is done for Super Paper Mario and Paper Mario: Sticker Star. After looking over the articles for the Mario & Luigi games, there really is a lot of content that doesn't need to be on the main article, especially the enemy tables.-- 06:14, 27 November 2016 (EST)
GIF vs. PNG Sprites: What to Keep/Delete
keep both png and gif sprites 2-1-7-1 A redesign of bestiaries passed and an unforeseen consequence of that is some GIFs that were in use got placed in Special:UnusedFiles (might see them elsewhere because this page is using them). Further concerns were added once L151 (talk) approved the deletions. There are some of those kinds of files pending deletion right now (some images that are currently there don't count for this proposal because they are either replacements or duplicate images). I was just cleaning up files leftover from the change and Eldritchdraaks (talk) had some concerns with my {{delete}} tagging. I find it redundant to have both a static PNG and animated GIF of the same enemy uploaded for the bestiary enemies. You can see my arguments here. Let's settle this by choosing what should be done about these for future uploads. My votes below explain how each option works.
Wildgoosespeeder (talk) My preferred choice. Not every static sprite had an animation counterpart (as far as I could tell).
Zootalo (talk) Per Wildgoosespeeder, though I wouldn't mind the animated GIFs being placed elsewhere, like in galleries of the respective game or character.
Prefer GIF and Delete PNG Versions
Wildgoosespeeder (talk) If we must use GIF, get rid of the PNGs because it's just redundant to have it when the GIF animation contains the static PNG frame. If no GIF animation exists, keep using PNG until a GIF version is uploaded. Currently deleted GIFs will be restored and have their PNG versions deleted.
Keep Both
Eldritchdraaks (talk) - I want to use the static PNGs on the bestiary, and the dynamic gifs in the enemyboxes, via transclusion. Other than that I don't think we should favor one over the other here.
Mister Wu (talk) Since at least Paper Mario: Sticker Star sprites that involve more than 256 unique colors have started to appear, and Paper Mario: Color Splash even has sprites with 8-bit Alpha Channel, causing artifacts if palettization is forced on them, thus PNG is needed for the appropriate display of the newer sprites; since APNG support is being completed in Chromium in these days, it is not yet possible to use PNG both for static and animated images, thus requiring also the use of GIF for the second purpose as a necessary compromise. In my opinion, by default, both should be kept, and is up to the uploader to use them properly; if they can't, one of them will become unused and then deleted anyway.
Yoshi the Space Station Manager (talk) I say keep both. PNGs can be used if it needs to be exact color, and GIFs can be used if it needs to have life. This will work until Google supports APNGs. I suggest that if there is any unused images, put them on that subjects gallery.
@Eldritchdraaks
That might make editing the enemy pages more confusing keeping both where the PNG is for bestiary only and GIF for enemy pages only. --Wildgoosespeeder (talk) (Stats - Contribs) 02:27, 11 December 2016 (EST)
That can be easily remedied by using on the bestiary pages. You can place the bestiary image in there and choose a different image while editing the page with the enemy box.-- 02:40, 11 December 2016 (EST)
Outsiders might not know to edit a bestiary page instead of the enemy page to change the sprite(s) for said enemy page. --Wildgoosespeeder (talk) (Stats - Contribs) 02:44, 11 December 2016 (EST)
They wouldn't have to. By default, the enemy box would display the image on the bestiary, but you could chose to instead edit the enemy page to use a different image.-- 03:06, 11 December 2016 (EST)
Are there any reasons to provide an override when the default image is satisfactory? --Wildgoosespeeder (talk) (Stats - Contribs) 04:08, 11 December 2016 (EST)
See Megasparkle Goomba. The page currently uses promotional artwork for the Megasparkle Goomba, rather than the in-game sprite used in the bestiary. For this character and the use of the enemy box, this works.-- 14:49, 11 December 2016 (EST)
Because GIF is better. Just too much of it is distracting. --A gossip-loving Toad (Talk) 18:33, 11 December 2016 (EST)
IMO, this proposal isn't worded very well. At a glance, it seems to be a general preference, but this proposal actually deals with a preference for .GIFs and .PNGs in the bestiaries. For future reference, I think we should change the title a bit. It's me, Mario! (Talk / Stalk) 19:43, 11 December 2016 (EST)
Is it worth animating in the first place? Aside from animations that demonstrate something, are animations for looks all that useful to the wiki or is it extra work with little payoff and has some drawbacks? Also keep in mind that it is possible to break the 256 color limit. I think the SM64DS animation I linked to is demonstrative of this. Still not a 24-bit color animation like APNG, but it is a noticeable improvement over the previous version of the image and the GIF artifacts are barely noticeable. --Wildgoosespeeder (talk) (Stats - Contribs) 01:47, 12 December 2016 (EST)
Example of a gif that shows the dynamic motion of an enemy.
It provides visitors with an extra flair, showing how an enemy moves in the case of the bestiary/enemybox. It's not up to anyone but ourselves to decide if making these gifs are worth it. I've been slowly making the enemy gifs for Color Splash, and while I have neglected to upload pngs at the moment, the gifs bring these enemies to life.-- 02:46, 12 December 2016 (EST)
Expand the "Outcome template" rule to appeal outcomes
create template 10-0
Eight months ago, Baby Luigi (talk) expressed concern about the misuse of proposal outcome headers. Her rationale was that introducing a template to use in all future proposal outcomes would make implementing the archive much easier, and that the usage of Verdana as a font rather than Comic Sans was important because it was web-friendly, and looked more professional. While the proposal brought up a good, well-thought-out idea, and I would have supported it myself, the thing that still bothers me is, why does it only affect proposals and TPPs? I don’t see why it can’t affect the appeals system at all. I do understand that most appeal headers are seldom improperly formatted, but introducing a template could simplify the archiving of the appeals system, let alone the proposal system. For this reason, I have created a draft template, which you can view here for reference on how the archiving system can work via a template. It's still a start, but let's start keeping the archival systems consistent.
Baby Luigi (talk) The only reason the appeal outcomes haven't been included is that I completely forgot about them, really. Per proposal, and per consistency.
I just fixed a formatting error in your original proposal text where you linked to your main userpage, instead of the subpage you seem to have intended to link to. 3D Player2010 18:17, 31 December 2016 (EST)
Thanks for doing that! (T|C) 18:26, 31 December 2016 (EST)
How funny :) I created a draft for that like 7 months ago for LGM, I didn't notice it wasn't implemented yet.--
create template 10-0
Details here. It explains everything while containing the code used to achieve it. Two articles I can think of that uses the Media: prefix are Nintendo Switch and Electrodrome.
User:Wildgoosespeeder/media link - This page (MarioWiki:Proposals/Archive/46) should show up in the file usage section of the file supplied for the template to the left while still providing a link to the file page
Shokora (talk) – I like this idea; it brings together the benefits of both "File:" and "Media:" links. And I can't think of any potential drawbacks, so per proposal.
Mister Wu (talk) I definitely can see the benefits of this, as the image's page might have interesting information that is going to be missed when just using the "Media:" links.
I'm confused... What exactly are you proposing? (T|C) 19:28, 1 January 2017 (EST)
Pretty much a way to add a link to the image's page while having the image indicated as used in the page containing the link. At the moment, the image is indicated as used only if you use the Media link, which directly leads to the image, making it cumbersome to read the additional information contained in the image's page, which might sometime be useful. Hopefully soemone else will be able to explain it in more simple terms than me... I would like to support the idea, but I want to know if this workaround does not go against a deliberate choice made by the Wiki's staff to force the use of the Media link.--Mister Wu (talk) 20:46, 1 January 2017 (EST)
I don't think this goes against sysop wishes. At most, we continue using Media: as we always had (citations with <ref>) but this time we use {{media link}} instead. That way the link generated is something more desired if we click it while making sure that the linked file stays out of Special:UnusedFiles. --Wildgoosespeeder (talk) (Stats - Contribs) 16:46, 2 January 2017 (EST)
Splitting Large Galleries
Split larger galleries 14-0
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:
Gallery:(name) artwork and scans
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) sprites
This gallery page would contain the many sprites of the subject.
Gallery: (name) screenshots
This gallery page would contain all the screenshots from games and animation we've captured of the subject.
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 [[Gallery:Mario artwork and scans|here]].
<gallery><image><image><image></gallery>
For sprites of Mario, see [[Gallery:Mario sprites|here]].
<gallery><image><image><image></gallery>
For screenshots of Mario, see [[Gallery:Mario screenshots|here]].
<gallery><image><image><image></gallery>
For the gallery of images relating to Mario's younger form, Baby Mario, see [[Gallery:Baby Mario|here]].
For images relating to Mario's powered-up forms, see [[:Category:Forms|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 MarioWiki:Galleries page should be updated to reflect this change. The {{galleries}} navbox would also have to be updated to reflect the change, for example: "Mario (Artworks and Scans · Sprites · Screenshots)"
Proposer:Alex95 (talk) Deadline: Friday, January 27th, 2017, 23:59 GMT
Toadette the Achiever (talk) 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 {{galleries}} 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.
Bazooka Mario (talk) 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...
The Koopa Bro. (talk) Per all. Hopefully this can happen on most of the larger galleries.
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) Lakituthequick 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.) Lakituthequick 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. --™The 'Shroom 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)
@Toadette the Achiever (talk), you bring up a point I completely forgot about: the {{galleries}}. 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. (T|C) 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. Shokora (talk · edits) 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
Prohibit Converting Between GIF, JPEG, and PNG Formats 4-0
Introduction
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.
What this proposal applies to
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 doesn't apply 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.
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.
Exceptions
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.
Conclusion
In short, keep the original format and don't convert directly. Do things properly. If this proposal passes, MarioWiki: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.
Toadette the Achiever (talk) It took me two whole days to read and fully digest what this proposal means to the quality of images, considering how complicated it is, but after some thought, I've decided to support. It helps to have near pixel-perfect image conversions that don't affect the format (because affecting the format of an image is actually harder than it sounds). I also appreciate the fact that you're planning to update the written policy on images since, again, considering how complicated it is, this proposal, should it pass, is better written than unwritten. So long as you know exactly what you're proposing, well, per proposal!
I think {{image-quality}} 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. --A gossip-loving Toad (Talk) 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:Images to be reuploaded with higher quality). --Wildgoosespeeder (talk) (Stats - Contribs) 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.) --A gossip-loving Toad (Talk) 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. --Wildgoosespeeder (talk) (Stats - Contribs) 15:41, 23 January 2017 (EST)
If I wanted to make a jpg transparent (make it a png), would this be allowed based on your proposal? --Andymii (talk) 23:46, 27 January 2017 (EST)
What if the image is a scan (like most of the pre-internet artworks)? What's wrong with making them transparent so they don't have fuzzy backgrounds? I feel it would be better if each case was taken upon individually, instead of having a sweeping rule that may in fact get in the way for certain cases. --Andymii (talk) 12:59, 29 January 2017 (EST)
This is a matter of image format and understanding what format is best for what situation and understanding that converting between formats doesn't increase quality. PNG doesn't mean higher quality. PNG means that it will preserve an image in whatever state it is in 100% accurately. BMPs are ideal for PNG because no degradation occurred. JPEG uses encodings that estimate what a color is at certain pixels, divided into blocks, which is why it is regarded as a lower quality lossy format that degrades an image. There is nothing wrong with JPEGs if that is all that is available at this time. It's also better for photographs or other images that are complex with colors and patterns, which can often compress better than PNG. JPEG is a tradeoff of lower space requirements for images that can get away with quality loss, which visually, could be undetectable. [1]
This is also a matter of patience and making things easier to track what needs a high quality replacement at some point, if at all. High quality versions of images will eventually come. Just a month or two ago, Shokora (talk) (formerly YoshiKong (talk)) found BMPs of Super Mario World artwork that MarioWiki hosted JPEG versions of instead. The JPEGs were replaced with the BMPs (converted to PNG). That's something we don't have to worry about anymore. --Wildgoosespeeder (talk) (Stats - Contribs) 18:35, 29 January 2017 (EST)
How come that if something doesn't increase quality it must be forbidden? It is true that PNG encodes a photo worse than JPG, but it encodes better than GIF a pixel artwork < 256 color, such as early images on Nintendo's website before PNG came. --A gossip-loving Toad (Talk) 21:30, 29 January 2017 (EST)
We should focus on constructive edits. Converting wastes time and makes things more confusing in the long run and problems can go unnoticed for years. At least if we forbid conversion, we can track JPEG and GIF by extension instead of by visually scanning the image for imperfections if it was converted to PNG and tagging them with {{image-quality}}, thus keeping Category:Images to be reuploaded with higher quality more manageable. The extension is like a MediaWiki maintenance category in disguise. Just have to use Special:Export (formerly could use Special:MIMESearch) and remove the PNGs from the list of possible JPEGs and GIFs that should see a replacement.
PNG isn't encoding. It's the result of reducing data redundancy without affecting the image's pixel data. JPEG goes about compression much differently, which leads to detail loss.
I am kind of iffy converting those GIFs to PNG because GIF has an inferior algorithm compared to PNG but there could be a better version floating around where the colors aren't limited to 256 colors.
I mostly agree with your proposal, however, I disagree with this:
Exceptions
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.
I would truthfully rather have no image at all for a given subject in cases like this if the alternative is an image with lossy compression. 3D Player2010 16:41, 30 January 2017 (EST)
Two problems with that. Resolution reduction isn't desirable. Also you would have to ask Porplemontage (talk) to increase the upload file size limits. This is also a very rare case. I have only come across a situation like this twice out of the 70,000+ files we have uploaded. --Wildgoosespeeder (talk) (Stats - Contribs) 17:54, 30 January 2017 (EST)
Changing the Super Mario Wiki Logo!
Change Logo 23-1
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:
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?
Owencrazyboy9 (talk) 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.
Bazooka Mario (talk) Goody. Though I wish it was a little less generic.
Toadette the Achiever (talk) While the current logo is at least somewhat generic, the artwork of Mario and the game screenshots are from around a decade ago, which might not be as appealing to readers. Having a logo with a good enough genericness would give that logo a much longer life span. And yes, we as a wiki also provide details about the Yoshi and Wario series, so having a simple Mushroom would be good enough, since Yoshi and Wario are too connected to Mario to have their own wikis. However, I do agree with Baby Luigi's comment about converting the image to vector scale, but we can always cross that bridge if and when we come to it.
Infinite8 (talk) The Super Mushroom represents the Mario franchise, like the emblem used to represent the Mario universe in the Smash Bros series. And also this is the perfect time to switch to the new logo to coincide the "new Nintendo", with their brand logo changed from "grey logo on white" to "white logo on red". Per all.
Andymii (talk) The new logo isn't very unique or clever, so I'm hesitant to support it. However, it's definitely better than what we have now, so I guess it's okay.
MKS1675 (talk) Per all. This logo is cool, much better than the old one.
Keep the Current Logo
Tails777 (talk) 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)
Barely related, but how does everyone feel about naming this Wiki Mushroom Kingdom Wiki? Not something that is going to be changed any time soon or even through a proposal to make the change, but I think it is worth discussing just as a hypothetical. --Wildgoosespeeder (talk) (Stats - Contribs) 20:56, 27 January 2017 (EST)
Along with the new logo, can this wiki change its wiki skin to Vector (with the search bar on the top right) as default? The new logo skin wouldn't fit in with the MonoBook skin. The Zelda Wiki, Smash Wiki and Nintendo Wiki all have the Vector skin as default. Infinite8 21:45, 27 January 2017 (EST)
One change at a time! Isn't it possible to have it's size reduced or create a smaller one, though? ...Eh, I'd likely keep my setting to MonoBook anyway. 22:10, 27 January 2017 (EST)
One thing about the SVG version placed here last night is that while a PNG of 150px is 23KB, the vector is 342KB, which is significant. I would then use the PNG instead.
You can also use a PNG of 300px instead to accommodate for high density screen users (51KB), or both and have it be switched as needed by CSS. Lakituthequick 09:52, 28 January 2017 (UTC)
If filesize is a concern, the SVG can just be scaled down to the desired x150px and uploaded as that, right? Shokora (talk · edits) 08:18, 28 January 2017 (EST)
That's not how SVG works. SVG grows in size as the complexity of the image increases, not the resolution. Lakituthequick 13:29, 28 January 2017 (UTC)
Ah, gotcha. In that case, I think we're better off uploading a PNG at the appropriate 150px size for use in the CSS, and keeping the full SVG available for potential use elsewhere. Shokora (talk · edits) 08:37, 28 January 2017 (EST)
This isn't about png or svg, it's about the logo design. I've already discussed the png vs svg with Steve.-- 12:32, 28 January 2017 (EST)
The format is good to think about though. What was the outcome of your discussion? Can't seem to find it on his talk. Lakituthequick 21:44, 28 January 2017 (UTC)
It's a private discussion. The proposal isn't about the format; it's not something up for discussion here, and will be decided by Steve himself.-- 17:31, 28 January 2017 (EST)
And the bookmark icon too. --Andymii (talk) 14:53, 1 February 2017 (EST)
If the png is run through PNG Monstrous, it can be reduced from 23334
bytes to only 18881 bytes. I would recommend doing it. 3D Player2010 15:14, 1 February 2017 (EST)
It looks like Steve changed the logo early, but it's not the right one... so I'm confused.-- 15:18, 1 February 2017 (EST)
Scratch that, it's all good now.-- 15:25, 1 February 2017 (EST)
withdrawn by the proprietor (see post)
Just now, a motion has passed to change the Super Mario Wiki logo. The logo change was overwhelmingly supported with a final tally of 23-1. However, I believe there is still need for discussion, and thus I am calling for a localized reopening of the proposal.
I do NOT seek to repeal the decision to change the old logo (that's why "keep the old logo" is not an option). The motion has passed fairly, and overturning it at this point would be against proposal regulations. The change will stick. This is not a nullification, it is an expansion. I feel that the proposal has failed to examine ALL factors of this debate, and thus should not be considered closed until all relevant factors have been explored.
What I am specifically talking about is that, during discussions on the forum, an alternative logo has been suggested. I've read the proposal, and this new suggestion was not considered while the vote was in progress. I therefore think the discussion is incomplete. For the proposal to cover ALL aspects of this debate, and to ensure that all information is evaluated, users should be made aware of the options they have, and then allowed to vote which logo they want to replace the old one with.
Logo #1
Logo #2
Change is inevitable, but we have not yet adequately explored which direction we want to change in.
Proposer: Gabumon (talk) Proposed Deadline: February 8, 2017, 23:59 GMT Date Withdrawn: February 2, 2017, 00:51 GMT
Switch to Logo #1
Owencrazyboy9 (talk) I think it's best to stick with the proposed logo from before. To rephrase what Eldritchdraaks said in the previous proposal, the new logo symbolizes the Mushroom Kingdom, in a similar way that the wiki covers all things Mario-related, including Donkey Kong, Yoshi and Wario games, not just Mario's. The alternative logo just makes it look like we cover just material with Mario in it, not all things Mario-related. In all, I'm going to have to oppose the other design and go with this one.
Glowsquid (talk) - people following the twatter account seems to like this one, for what it's worth.
Switch to Logo #2
Gabumon (talk) - The alternative logo is visually more interesting, as it provides a nice color contrast instead of just being uniformly red.
Lord Bowser (talk) honestly the new logo looks visually uninteresting. I agree that the old logo was a bit of a mess, but this new logo is on the opposite end of the spectrum; too simple. logo #2 provides a good compromise in my opinion.
DragonFreak (talk) - Per all plus the red text on red mushroom blends in too much.
Comments
If Porplemontage (talk) is willing to create more skins (themes), why not just have each theme have a different logo? I would go as far as creating a "night" theme (dark color scheme). --Wildgoosespeeder (talk) (Stats - Contribs) 19:22, 1 February 2017 (EST)
Ooh, I'd like that :) 19:26, 1 February 2017 (EST)
I think that sounds like a good idea. --TheFlameChomp (talk) 19:27, 1 February 2017 (EST)
@Owencrazyboy9: Well, I would say that Mario is the champion of the Mushroom Kingdom, and thus something that represents him does, by extension, represent the Mushroom Kingdom. I don't really see the DK/Yoshi/Wario games point, because mushrooms are only tangentially related to those series and don't really adequately represent them. Bananas, garlic, and eggs are what first comes to my mind when I think of those. In fact, if you wanted to use something that's featured in all of these series, it should really be a coin. -- Gabumon (talk)
I'm fairly certain that despite what you are saying, this still goes against rule #7: "No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old." Also, if you had an issue with this, you didn't even vote on the previous proposal nor did you leave any sort of comment. The new logo had full support by Porplemontage (talk) and when I made the proposal, he said to create the two options I did.-- 19:35, 1 February 2017 (EST)
Because I only learned of this proposal today. I would have loved to be part of the conversation before, but one week is a pretty narrow time window, and I just didn't see it in time. Also, I believe wholeheartedly that this is still within the scope of the rules, but I may be mistaken, and if I am I submit my proposal and myself to whatever countermeasure the sysops deem fit. I just think that, if people make a decision like this, they should be allowed to know all of their options. Rest assured: Once this proposal resolves or is removed, I will drop the issue. -- Gabumon (talk)
Create template 11-0
You can see details here. Essentially this should make linking to talk page proposals easier. It's tedious to copy the same code over and over again for bolding, linking, and saying deadline.
Alex95 (talk) Decided to test what is already made and "Test Proposal" is all that shows :P Maybe I'm not doing it right, but I like the idea, so per Wildgoosespeeder.
Baby Luigi (talk) Agreed with this. Though I'm very used to the traditional way of doing things, I feel this will save some convenience in the long run.
What's the point of having a "failed" part in that parameter, failed TPPs are removed from the page upon failure? Yoshi876 (talk)
You don't have to use that. It was just something that came to mind. The parameters are just plain text and the formatting is simple instead of the more complex {{ProposalOutcome}}. There is room for formatting changes and should be very easy to implement onto the template itself. --Wildgoosespeeder (talk) (Stats - Contribs) 16:31, 16 February 2017 (EST)
That was resolved. This template will need to be added to that category I created on that talk page if the proposal passes. --Wildgoosespeeder (talk) (Stats - Contribs) 03:17, 17 February 2017 (EST)
DON'T SPLIT 2-9
Have you fellas take a look at that thing? it's humongous! it's clogged with so many links it's tiresome to even look at it. Now, if this wiki was called Video Game Wiki, it'd make perfect sense to have this colossal navbox. I find it more appropriate to have several navboxes each focused on a game series rather than having them all together in an oversaturated box. For instance, I suggest we create a navbox that solely focuses on games from the main Super Mario series, another one for the Mario vs. Donkey Kong games, one for the Mario RPG games, one for the Mario Kart series, one for the Mario Party series and so on. How it will be handled needs to be settled, but first, a huge thing like this shouldn't be here, it's very redundant to have a navbox like that on the Mario Wiki.
Proposer: Byllant (talk) Deadline: March 2, 2017, 23:59 GMT
Support
Byllant (talk) - Several distinctive navboxes seems more practical than the colossal thing we already have.
Toadette the Achiever (talk) Per all the reasons why they were merged this way in the first place. The whole reason why we don't split the template at all is to make navigation easier, not more difficult, for other users; size should be no excuse. Additionally, you fail to indicate where to draw the line for splitting. Even if we split it by genre (Super Mario, Mario Kart, Mario Party, RPGs, etc.), it would result in mini-navigational templates that would be much smaller in comparison to other navigational templates. Again, there's a reason why we keep the template's genres merged together in the first place.
Luigi 64DD (talk) Per all. I suggest using the approach used by Nintendo Wiki here to make it look less huge.
Comments
It does appear as a wall of text without anything to make it easier to look at. Instead of splitting the template, which is opposed by most voters, how about hiding sections or structuring each entry better into a grid? --Wildgoosespeeder (talk) (Stats - Contribs) 16:49, 26 February 2017 (EST)
I would support the approach of showing/hiding sections much better than what is currently proposed. (You could look at Template:Galleries as a near-perfect example.) When this proposal ends, I might create an alternate proposal that provides multiple options concerning how to trim down the franchise navigational templates. Thank you for your suggestion. (T|C) 18:30, 1 March 2017 (EST)
Create {{editneeded}} template
canceled by proposer
There are some articles or sections that need improvements that are not covered by existing templates. The purpose of this template would be to allow users to flag articles or sections in need of a specific edit. Currently, most of such articles use the {{rewrite}} template, which is intended to be used for articles that are poorly written, not for articles that need other types of improvements. For example: articles that need a table, articles that need sections, articles that need a more specific topic, etc.
This article is in need of the following edit: {{{1}}}. You can help the Super Mario Wiki by making it.
Proposer: Supermariofan67 (talk) Proposed Deadline: March 26, 2017, 23:59 GMT Date Withdrawn: March 19, 2017, 23:44 GMT
Baby Luigi (talk) I don't see the point of this template. If this specific article needs a certain edit, then actually make them. The reason we flag articles with rewrite and construction typically cover huge projects that users can't simply just drive in and change in one go. Hell, by the time you tag this template up in articles, you'd already be done making the edit the article needs. Anything bigger than what this template suggests is already covered by rewrite and construction, so its purpose is pretty void. Also you mentioned that rewrite templates "shouldn't" cover articles beyond poorly written, and I don't see why it should not, since that's how we always used that template when it needs more content. We additionally have "rewrite-expand" for that, or we can always list reasons for the rewrite template. Or there's the construction template if you're working on the project.
Wildgoosespeeder (talk) We really need to consider that {{rewrite-expand}}, {{stub}}, and {{stub}} already exist to satisfy the need to get specific content in the article. Stubs are already confusing because some users, like myself, feel confused that stub means missing content, not short article, because the word "stubby" means short. I think we need to combine these three templates into one and call it {{incomplete}}, to follow Bulbapedia's example. Don't get me wrong, the template is a good idea, but not fully just yet. Needs more thought put into it.
Luigi 64DD (talk) The current templates (such as rewrite and rewrite-expand) can relay the necessary information on what needs to be edited well enough as long as it is specified what needs to be added. In other words, instead of just putting a rewrite template, one should write what needs to be fixed. I find it annoying when this is not done as just the rewrite template alone is often too vague to properly explain the article's issue.
Allow users to make a user subpage for 'Shroom sections
no quorum 1-0
The subpages allowed for userpages are for only for things like signatures, archives, wiki projects and other stuff. What you cannot make is a sub page filled with all the 'Shroom sections you have made. In this proposal I am wanting to change the rule so that you can have a user sub page for 'Shroom sections. In it, users would either link to all their sections or transclude their sections onto their page (e.g. {{The 'Shroom:Issue 120/Fun Stuff#Guess That Game!}}).
That would make it easier for users who want to read all sections made by a particular user, or to simply find a certain section to read. It is hard to find a particular 'Shroom section in the archives because there are so many issues released, and if you don't know Roman numerals finding an issue before issue 100 would be hard! This new sub page would also make it easier for 'Shroom writers and other users to count how many sections they've written, without having to look through every issue of The 'Shroom.
A couple of comments before casting a vote: {{The 'Shroom:Issue 120/Fun Stuff#Guess That Game!}} doesn't work for transclusion, it transcludes the entire page; when you mention it's hard to find a particular section in the archives, do you mean like "I want to read Guess That Game! from Issue 80" or "I want to find that review of Super Mario 64 but I have no idea which issue it appeared in"? --™The 'Shroom 05:00, 22 March 2017 (EDT)
Interesting idea, but I've been including my own sections on my userpage for some time now :P
The thing with this though is that the writer would still have to manually include their section into their userpage. Some of the 'Shroom writers are no longer around, so, unless this particular userpage was unprotected like a talk page, it'd be difficult to maintain.
Additionally, and I just tried this myself, you can search for a writer's segment in The 'Shroom using the search function. Simply type in a user, go to "Advanced", check only The 'Shroom, and you'd end up with this. It's not exact, but it'll get you close. 12:01, 22 March 2017 (EDT)
@Alex95: I still have no opinion on this, but the comments might be of use. I'll keep myself posted. (T|C) 18:26, 22 March 2017 (EDT)
If translusion wouldn't work, then just link to your sections on your userpage. I don't think it's necessary to have a separate user subpage for them. Shokora (talk · edits) 18:34, 22 March 2017 (EDT)
That's exactly what I was thinking. The links would probably not clog your page up. Even if you did write that many sections, there would be ways to make it not clogged. (talk · edits) 20:00, 22 March 2017 (EDT)
The main reason I created this proposal was mostly so that users can put their Shroom sections on it. Linking it was just something else you could do (though if you created the extra Shroom subpage, it would be easier to find your sections without searching through your userpage). There must be some other way to easily translude their sections onto that page. Otherwise, users would just have to copy their section the long way. But there's nothing wrong with doing that (unless you have written like 50 or more sections, and that would take forever!) If you have enough patience, you could create a nice looking page filled with all your 'Shroom sections! Mr squidTalkEdits 04:23, 23 March 2017 (EDT)
