MarioWiki:Proposals/Archive/70: Difference between revisions

From the Super Mario Wiki, the Mario encyclopedia
Jump to navigationJump to search
No edit summary
m (Text replacement - "{{MarioWiki:Proposals/Archive/Template|current=yes}}" to "{{MarioWiki:Proposals/Archive/Template}}")
 
(15 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{MarioWiki:Proposals/Archive/Template|current=yes}}
{{MarioWiki:Proposals/Archive/Template}}


===Overturn the [[MarioWiki:Proposals/Archive/55#Delete_Category:User_eo|proposal]] that resulted in the deletion of [[:Category:User eo]] (category for speakers of {{wp|Esperanto}})===
===Overturn the [[MarioWiki:Proposals/Archive/55#Delete_Category:User_eo|proposal]] that resulted in the deletion of [[:Category:User eo]] (category for speakers of {{wp|Esperanto}})===
Line 758: Line 758:


Going ahead and cancelling, since I considered to myself that this would technically cover the in-game "artwork" for MKT and the spirits in Ultimate, both of which are ridiculously large and can't be shown at raw size on a gallery page anyway. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 12:56, October 28, 2024 (EDT)
Going ahead and cancelling, since I considered to myself that this would technically cover the in-game "artwork" for MKT and the spirits in Ultimate, both of which are ridiculously large and can't be shown at raw size on a gallery page anyway. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 12:56, October 28, 2024 (EDT)
===Remove all subpage and redirect links from all navigational templates===
{{Proposal outcome|passed|9-0|Remove the extra links from navigational templates}}
Navigational templates are one of this wiki's best features. They're a really convenient way to get around the wiki. However, one common pitfall of the templates is bloat, in particular in the form of links to subjects that do not have dedicated articles. I have previously made [[MarioWiki:Proposals/Archive/66#Trim Super Smash_Bros. navigational templates|a proposal about this subject]] specifically in the context of the ''Super Smash Bros.'' series, but the problem extends to navigational templates across the entire wiki.
In principle, navigational templates should be '''directories of articles on the wiki'''. What advantage does it give the reader for [[Template:WWMI]] to have a whole section dedicated to eighteen separate links to subsections of [[Form Stones]] on ''top'' of a link to the main article itself? Why does [[Template:Humans]] link to all seven individual members of [[List of show hosts in All Night Nippon: Super Mario Bros.|List of show hosts in ''All Night Nippon: Super Mario Bros.'']] individually? Does the already crowded [[Template:Super Mario games]] really need to use precious space on a link to [[List of unreleased media#Tesla Mario Kart game|a two-sentence section]] about a theoretical game that Elon Musk claims to have failed to have pitched to Nintendo?
I propose that, across the board, '''all subpage and redirect links on all navigational templates should be either removed or replaced'''. (''Red links'' are relatively fine, as long as the things they don't link to theoretically ''should'' be articles that just haven't been made yet. Edge cases like "[[Unnamed Worlds A-C Human]]" should be decided case-by-case in [[Template talk:Humans#Unnamed Worlds A-C Human|the relevant talk pages]].)
'''Proposer''': {{User|JanMisali}}<br>
'''Deadline''': October 31, 2024, 23:59 GMT
====Remove the extra links from navigational templates====
#{{User|JanMisali}} As proposer.
#{{User|Hewer}} To be honest, the main reason I'm supporting this is because I hate how cluttered [[Template:Super Mario games]] is with useless links, and this would help solve that problem. We don't need to list every single game to ever have been pitched there.
#{{User|Camwoodstock}} This makes sense to us. It's much easier to just list a page link once and only once.
#{{User|OmegaRuby}} Per all.
#{{User|EvieMaybe}} per all
#{{User|ThePowerPlayer}} When I think about it, it's an extreme stretch to e.g. list [[Mario Chase]] on the [[Template:Super Mario games|list of ''Super Mario'' games]] just because it was a reworked demo, or to give real estate to ''[[List of unreleased media#Mario's Castle|Mario's Castle]]'', a concept so nebulous that it is covered by a list article in a grand total of two sentences. I feel more ambivalent about entries that are clearly their own games, such as ''[[Mario Party 4#Arcade|Dokidoki Mario Chance!]]'' or ''[[Reflex Rally#Browser game|Reflex Rally]]'', but those could be split on a case-by-case basis if necessary.
#{{User|SeanWheeler}} If we're not allowed to link redirects, how could our templates have redirect links?
#{{User|Jdtendo}} No need to clutter navboxes with useless links.
#{{User|DryBonesBandit}} I was always annoyed by this. Per all.
====Do nothing====
====Comments====
Wait, that ANN thing is a page? I was unaware. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:51, October 17, 2024 (EDT)
:A page that's linked to on nearly 900 (!!) other pages! But since those links are hidden in a big bloated alphabetical list of characters (only most of which have actual articles), it's not nearly as visible of an article as it otherwise would be. {{User:JanMisali/sig}} 19:09, October 17, 2024 (EDT)
::When I made that proposal not too long ago on that game, my idea was a page for each since they're all based on real people and look different despite having the same role (like the people in Mario is Missing and the NES Mario's Time Machine). [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 19:13, October 17, 2024 (EDT)
:::That sounds perfectly reasonable. If/when those dedicated articles ''are'' created, then including links to them in Template:Humans would make sense. As it stands now, of course, linking to one list article several times is just messy and unhelpful. {{User:JanMisali/sig}} 19:20, October 17, 2024 (EDT)
Speaking of that "Unnamed Worlds A-C Human", has anyone attempted a thorough search through the history of ''All Night Nippon'' to identify the guy? As I said on the relevant talk, I ''assume'' it's also a radio host, since all the other Toad replacements are hosts as well, but I can't say with certainty (might as well be a higher-up at Fuji TV) {{User:Arend/sig}} 18:13, October 25, 2024 (EDT)
===Prioritize MESEN/NEStopia palette for NES sprites and screenshots===
{{proposal outcome|passed|13-0|prioritize MESEN/NEStopia palette}}
I want to preface this by saying this proposed change will NOT be a one-person job to go back and change all instances of uploaded images. This will be more a general guideline going forward, and a thing anyone who wants to help can do without feeling like it might be unnecessary or unwanted. If this succeeds, the only immediate change needed to be considered "put into effect" is an edit to the image policy, though there will probably be a lot of quality tags for blatantly off colors.
For context of this, the NES and the Japanese FamiCom/Disk System do not have a "native" hard-coded palette. As such, different machines display different colors. However, a ''majority'' of contemporary televisions in the NTSC region (which includes both Japan and America, so where the FamiCom and the NES were initially respectively developed - sorry PAL pals) would display them with a particular muted palette. Many early computer-based emulators instead displayed an extremely bright palette with colors that tended to clash with each other, which is still present on many old images on the site. Even a few today are like that, such as FCEUX, which while great for ripping tiles, has a very odd color display.
MESEN and NEStopia are NES emulators that display that more "accurate" (for lack of better term) color. It is widely recommended by sources such as The Spriters Resource and The Cutting Room Floor as a good way to ensure color consistency. Even Nintendo themselves seems to prefer its colors, as official emulators like the Nintendo Switch Online use that type of palette. I think we should start prioritizing it going forward as a general rule so there's more consistency to the uploads color and quality.
For an example of what I am talking about, see the upload history for {{File link|SMB Goomba Sprite.gif}}. A lot of the fixes have already been historically done; I myself worked a lot on the ''Famicom Grand Prix'' and ''Golf'' series images. Most of what's left are random images in larger platforming games as well as assorted more obscure games (looking at you, ''Wario's Woods''), as well as newer uploads from people using older sources without realizing or caring about this issue (which is the main thing this proposal hopes to address).
(As a side note, I spent yesterday evening collecting the NEStopia colors for ''Super Mario Bros. 2'' by playing through the whole game and applying them to the pre-existing level maps (which were ripped originally in one of those odd bright emulators), so assistance with applying them to the innumerable screenshots, sprites, and animations for the game would be greatly appreciated.)
'''Proposer''': {{User|Doc von Schmeltwick}}<br>
'''Deadline''': November 3, 2024, 23:59 GMT
====Supportopia====
#{{user|Doc von Schmeltwick}} - De vunderbar vald of color. Co''RR''ECT color.
#{{User|Nintendo101}} I think utilizing a unified palette is a smart idea. It would look nice, unified, and would mitigate potential confusion as to how colors differ between subjects.
#{{User|Camwoodstock}} The weirdly vibrant colors are a rare FCEUX L, as far as we're concerned, and it'd be nice to have some guidelines in place to encourage consistency.
#{{User|SolemnStormcloud}} Though my ''Mega Man''-brained self prefers the FCEUX palette in the context of that series due to MisterMike's sprite rips as well as it being the basis of  ''Mega Man 9'' and ''10''{{'}}s palette, this isn't a ''Mega Man'' wiki, so per all.
#{{User|ThePowerPlayer}} It's better to use the most accurate colors to the original output, to match the accuracy of the resolution of game screenshots.
#{{User|LinkTheLefty}} TCRF standards FTW.
#{{User|Killer Moth}} Per all.
#{{User|EvieMaybe}} it's worth noting that CRTs and LCDs display color differently, so a direct rip of what the nes displays to an LCD might not be properly accurate. however, if both TSR and TCRF recommend it, then i have to defer to their opinion
#{{user|wildgoosespeeder}} I have had Mesen [[User:Wildgoosespeeder/sandbox#NES/Famicom/Famicom Disk System/SNES/Satellaview|as a mention]] for years. It has the highest accuracy I have ever seen in an NES emulator. However I have always treated it as a fallback option to FCEUX. Reason being TASVideos.org availability. There is a section on TCRF about [[tcrf:Help:Contents/Taking Screenshots#NES|applying the correct color pallete when using FCEUX]].
#{{User|Mario}} I suppose there's no way to have all monitors display the exact colors uniformly, might worth documenting the colors.
#{{User|ThatOneSuperCircuitGuy}} Looking at the color pallets between FCEUX and a real NES, the color pallets are slightly brighter compared to a real CRT. I'm glad that the Delta devs use the correct pallets. (I think)
#{{User|Pseudo}} Remaining as accurate as possible to the original games should probably be prioritized.
#{{User|SmokedChili}} Should have made it clearer in the first place the palette in question is based on [https://tcrf.net/File:NES_NTSC_Palette.zip YUV palette aka 15° Canonical]. Per all.
====Opposeux====
====Commesents====
[https://tcrf.net/Help:Contents/Taking_Screenshots#NES Here's] the source on The Cutting Room Floor's preference for the MESEN/NEStopia palette, in case anyone needs it. Sorry if it's unnecessary, but I think the claim of the other websites' stances could've had links provided. [[User:SolemnStormcloud|SolemnStormcloud]] ([[User talk:SolemnStormcloud|talk]]) 15:47, October 20, 2024 (EDT)
:Thank you, now I can actually use FCEUX without needing to back-and-forth between emulators. Maybe I can get back into ''U.S. Course''{{'}}s prize card again... [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:01, October 20, 2024 (EDT)
{{@|SolemnStormcloud}} - Not to gossip but FR MisterMike'd be the best NES sprite ripper ever if not for exclusively using FCEUX palette. His ''Zelda'' 1 rips were... eyebrow-raising, to say the least, which is part of what inspired me to prioritize the NEStopia palette. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 15:58, October 20, 2024 (EDT)
{{@|EvieMaybe}} - Note the "closest to contemporary NTSC display" thing, so that'd be close-to-CRT. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 00:16, October 22, 2024 (EDT)
:makes sense! i figured that by "contemporary" you meant an LCD or an OLED, thanks for clarifying [[User:EvieMaybe|EvieMaybe]] ([[User talk:EvieMaybe|talk]]) 11:12, October 22, 2024 (EDT)
===Encourage concise, consistent and minimalistic layouts and design for tables===
{{Proposal outcome|passed|19-7|Encourage}}
Tables in game articles are a total playground. Overall, they often are as inconsistent and showy as they can be, and are often laid out in such a way that it makes them worse to read. Some are more extreme than others, like driver and track tables in [[Mario Kart (series)|''Mario Kart'']] articles, such as [https://www.mariowiki.com/index.php?title=Mario_Kart_64&oldid=4402277#Courses this] and [https://www.mariowiki.com/index.php?title=Mario_Kart_7&oldid=4401364#Drivers this]. Those ostentatious charts look like they belong in a promotional website rather than in an encyclopedia, and do not prioritize ease of reading and data relevancy. Some are not all that exaggerated, but still look over the top, overstyled and are more spacious than they need to be. Maybe people think it is more fun to design them like that, but they look unprofessional.
That being said, these are the points I judged good ones to encourage when it comes to creating tables:
'''1. Uniformly use plain wikitable style for regular tables.''' Pages often use several styles for tables for no reason (the [https://www.mariowiki.com/index.php?title=Paper_Mario:_Sticker_Star&oldid=4399708 article for ''Paper Mario: Sticker Star''] uses four styles throughout, [https://www.mariowiki.com/index.php?title=Paper_Mario:_Sticker_Star&oldid=4399708#Status_effects here], [https://www.mariowiki.com/index.php?title=Paper_Mario:_Sticker_Star&oldid=4399708#Characters here], [https://www.mariowiki.com/index.php?title=Paper_Mario:_Sticker_Star&oldid=4399708#Locations here] and [https://www.mariowiki.com/index.php?title=Paper_Mario:_Sticker_Star&oldid=4399708#Super_Flags here]). The wikitable style is pretty standard, so it makes sense to use it consistently.
'''2. Prefer to lay out table data in simple rows.''' If the table data fits well in a "one entry per row" format, do it, rather than attempting to use more elaborate, arbitrary layouts. Some examples of such arbitrary layouts are [https://www.mariowiki.com/Mario_Kart_7#Vehicle_parts this table], which is laid out like it is a grid of infoboxes, and [https://www.mariowiki.com/index.php?title=Super_Mario_RPG:_Legend_of_the_Seven_Stars&oldid=4379392#Objects this set of tables]. If you judge it wouldn't work to make a table fit that minimal layout, try making it the closest possible to it. Although arranging entries in columns may work in some cases, prefer to have each subject as a row, as that preserves the reading direction, arranges the related data more properly in the HTML, and allows the table to be sortable if needed.
'''3. Avoid using images of text in lieu of actual text.''' This is often done for the name of the subject, and it is purely for decoration purposes. Cases include Mario's name and stat names [https://www.mariowiki.com/index.php?title=Paper_Mario:_Sticker_Star&oldid=4399708#Mario.27s_stats here] and board names [https://www.mariowiki.com/index.php?title=Mario_Party_2&oldid=4403544#Boards here] (notice that the images in those examples are not there for mere visual reference, as they replace links; the editor likely wanted to add some flavor to the table). It makes the text less straightforward to read, in some cases duplicates it, because normal text is used alongside the image. Another common occurence is using images of stars or other icons to represent scales (such as "X out of 5 stars" scales), when you could use standard star characters (★ and ☆) instead. That does not mean to ''never'' use images instead of text, only consider whether it is worth it or not. For example, [https://www.mariowiki.com/index.php?title=Mario_Kart_8&oldid=4403601#Drivers.27_and_vehicle_parts.27_statistics_2 this] is a ''good'' use of images replacing text because writing the names for each driver and part as text would make it harder for the reader to quickly find the desired info.
'''4. Avoid using more images than necessary to illustrate the subject.''' This is also often used for decoration and visual effect. As an example, playable character tables in sports games articles (such as [https://www.mariowiki.com/index.php?title=Mario_Superstar_Baseball&oldid=4392117#Characters this] and [https://www.mariowiki.com/index.php?title=Super_Mario_Kart&oldid=4392250#Drivers this]), where the playable characters' table entries often include both an illustration of the character ''and'' that character's in-game icon (which is just the character's head graphic), which is redundant (if I already have an illustration as visual reference for the character, an icon showing the same thing is unnecessary, and vice versa). This is a specific example but that happens with other kinds of tables, like [https://www.mariowiki.com/index.php?title=Mario_Kart_64&oldid=4402277#Courses the ''Mario Kart 64'' track table] featuring both an image of the track ''and'' the track's thumbnail. Consider whether adding extra images actually make sense or if it's just filler.
'''5. Avoid decoration in general, such as coloring text and cell backgrounds.''' Take the colored table [https://www.mariowiki.com/index.php?title=Super_Mario_3D_World&oldid=4405481#Characters here] for example. As I said before, it is more about the visuals than the info, and it looks like some sort of promotional material. Instead, save coloring text and table cells for cases where it aids in reading data in some way.
Notice I've been proposing for these guidelines to be encouraged rather than enforced because some of them depend largely on the judgement of the editor.
'''Proposer''': {{User|Bro Hammer}}<br>
'''Deadline''': November 6, 2024, 23:59 GMT
====Support====
#{{User|Bro Hammer}} Per my proposal.
#{{User|Waluigi Time}} The only thing this proposal is missing is encouraging tables to be horizontally aligned in accordance with web design standards, but otherwise, pretty spot on. I think a little visual flair with coloration is okay, but since this is more of a guideline to be encouraged, I'm fine voting for this as-is.
#{{User|Nintendo101}} I will say, I have used colors for some of the tables I have crafted for the mainline series articles I have worked on, but it is always with illustrative intent. When all the tables in an article look indistinguishable from one another, it can sometimes be easy to lose one's place or not easily understand how some bits of information relate to others. But otherwise, I thinks these are great guidelines and they have my support.
#{{User|Camwoodstock}} Per all, especially Nintendo101; color has a time and a place, but stuff like the SM3DW character chart just kinda feels like a meld. That's not to say we should be replacing everything with the dull greys, of course, but we should probably dial it back at least a ''little'' bit. No real objections to the other parts, we should probably standardize as best we can.
#{{User|Ninelevendo}} I just don’t like what’s been done to the Mario Golf: Toadstool Tour character table so whatever it takes to fix that.
#{{User|Koopa con Carne}} per all
#{{User|Lakituthequick}} Per proposal and per WT – I have indeed commented a few times on tables and how they should be used for tabular data (more notably [[Talk:Mario_Kart_Wii#Decide_how_to_present_courses|for ''Mario Kart Wii'']]), and this proposal will start enforcing tables to do that.
#{{User|Cadrega86}} Wholeheartedly agree with all your points. These tables are over-designed and often include superfluous information (e.g. the track table in the Mario Kart 64 page, why don't we also add staff ghost times and future appearances while we're at it?)
#{{User|Shy Guy on Wheels}} Per all.
#{{User|SolemnStormcloud}} Per all.
#{{User|EvieMaybe}} per Camwoodstock and Waluigi Time
#{{User|TheFlameChomp}} Per all.
#{{User|MCD}} Per all.
#{{User|Sparks}} Per all.
#{{User|Fun With Despair}} Per all. Information should remain accessible and easy to reference, and tables utilizing images instead of easily transcribed or copied text are the opposite of that.
#{{User|PnnyCrygr}} Per all; MarioWiki is not a fansite, it's a wiki! A wiki's tables should therefore be formal and not unconventionally designed.
#{{User|ThePowerPlayer}} Per all. Table design on this wiki has bothered me for a while, and these guidelines are a great solution.
#{{User|Mario}} Current tables are too cluttered with information and are quite hostile to editing. This is a case of less is more imo.
#{{User|SmokedChili}} Per all.
====Oppose====
#{{User|Tails777}} I can agree that there should be a bit more consistency and organization on when and where to use certain elements for a table, but I also believe in making tables both informative and entertaining to look at. I see nothing wrong with using board logos to represent names for some of the earlier ''Mario Party'' boards that had them or using colored backgrounds on tables (something I've already supported). And while I can agree that some of the ''Mario Kart'' related tables are a bit all over the place, I believe we could take certain similar cases (tracks, boards, statistics, etc) and maybe make guidelines for each based on the topic. I get that this isn't outright enforcing the outage of these elements, but I don't really think we should actively enforce minimalist designs for tables, rather deciding what to do on a more case-by-case basis.
#[[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) - As the person who made many of the more "showy" ones, I'm kinda societally obligated to oppose this as a matter of course. <small>I can't let my MS in CS with a few classes on advanced web design/web app programming and an undergraduate Minor in Art go to waste</small> and I find it more engaging and explanatory as to the different aspects of whatever entity is being described to have both an in-game graphic and either an artwork or a screenshot. Stat bars and star-bubble fill-in charts with color-coding are also a lot more immediately understandable than numbers alone. To quote Bowser, [https://youtube.com/clip/UgkxjfSn6biDqu-61p6UwftFsKbsS2_1O8vX?si=0CqbG4WO7I7GE8V3 "Haven't you heard? A picture's worth a thousand words."] (People also generally seem to approve of my tables for the ''[[Golf]]'' games...) Anyways, I'm not gonna make this a big to-do, since I still can be beautiful on [[User:Doc von Schmeltwick/Projects/Fun with tables|my own page]], but I still think it looks and functions better than a schedule-looking list with inconsistent image resizings and row heights.
#{{User|OmegaRuby}} Per all. Some consistency between tables in articles would be nice, but I feel the rules this proposal would put in place are a bit too much. I mean, we did recently pass a proposal ''allowing'' [https://www.mariowiki.com/MarioWiki:Proposals/Archive/68#Allow_colorful_tables_again colorful tables] again.
#{{User|DesaMatt}} Per all. While consistency is good, there's a point where it becomes unnecessary and repetitive, and in my view this is that point. Also, I disagree with the idea that MarioWiki isn't a fan site. It will always be a fan site as long as it's not officially affiliated with Nintendo and is operated by fans.
#{{User|Scrooge200}} I actually really like the trend of giving games uniquely stylized tables, it helps give them a bit more personality. All the information is there and you can still read it effectively. I think I worked on some of the modern ''Paper Mario'' tables, and nobody seemed to have a problem with them until now.
#{{User|Hewer}} Per all.
#{{User|Salmancer}} Colored backgrounds are too much (as in, the ones where each entry has a different background), but I think there's a time and place for non-standard tables, so I wouldn't want a blanket ban.
====Comments====
{{@|Tails777}} Using images as a substitute for text is very poor for accessibility and searchability with ctrl+f, though. --{{User:Waluigi Time/sig}} 22:08, October 23, 2024 (EDT)
:True and perhaps I can agree to not substituting text with images. But I still stand by what will be my main point: tables can be presentable and professional without being a bore to look at. I still see nothing wrong with colored tables at the very least. {{User:Tails777/sig}}
With regards to colours and visuals as is most often used as a counterpoint: I believe those are strictly speaking less important than being informative and clear, but I do love myself tables that look good as well. I can see a future proposal to establish some generic reusable table styles and colours for specific purposes. To take one back a while, Walkazo did [[MarioWiki:Proposals/Archive/30#Navigation_Templates|just that for navigation templates]], which, [[MarioWiki:Proposals/Archive/36#The_Template_Shuffle|with updates]], resulted in [[MarioWiki:Navigation_templates#Coloration|this chart]] to be created, still in use today. ''The 'Shroom'' for instance also features [[The_%27Shroom:Issue_211/Pipe_Plaza#The_.27Shroom_Report|its own table styles]] which are pleasant to look at, and which use colours [[The_%27Shroom:Issue_211/Strategy_Wing#An_Octet_Gazette|that match the page's theme]]. {{User:Lakituthequick/sig}} 08:41, 24 October 2024 (UTC)
:I'm staunchly against using the fugly ass gray and grayer tables across all articles and I'm definitely perring LTQ's suggestion for themes. I like the red header in the Super Mario World article and the green header in the Yoshi's Island article, it's deliberately done to match the nav templates the articles use and I'd be in full support of making tables be consistent with that. {{User:Ray Trace/sig}} 15:51, October 24, 2024 (EDT)
There are a ton of tables on here that use STRONG, EXTREME colours in attempt to look flashy but just end up being really hard to read, and I think above all else those need to go. Colour should be used very sparingly. I came across this recently looking at the MK8 Color Scheme tables for [[Standard Kart]] and [[Standard Bike]]. When you see things like '''{{color|lightcoral|Pink}}''', '''{{text outline|{{color|#E0E0E0|White}}}}''', '''{{color|#E6CC00|Medium yellow}}''', '''{{color|gold|Yellow}}''', '''{{color|lawngreen|Chartreuse}}''', '''{{color|#F2DFA6|Light-gold}}''', '''{{text outline|{{color|#F2DFA6|light-gold}}}}''' and especially '''{{color|#FF6633|In}}{{color|lawngreen|k}}{{color|deeppink|l}}{{color|blue|in}}{{color|#990099|g}}{{color|#00E6CC|s}}''', it's murder on the eyes... [[User:Shadow2|Shadow2]] ([[User talk:Shadow2|talk]]) 04:45, October 24, 2024 (EDT)
:Hmm, would it be acceptable if we kinda did {{iw|inkipedia|Template:Ink|what Inkipedia does with ink colors}}, and have a colored square show before the color terms? {{User:Arend/sig}} 12:31, October 24, 2024 (EDT)
:e.g. <span style="width: 1rem; height: 1rem; display: inline-block; vertical-align: middle; border-radius: 0.4rem; background-color:lightcoral">&nbsp;</span> Pink, <span style="width: 1rem; height: 1rem; display: inline-block; vertical-align: middle; border-radius: 0.4rem; border: 1px solid #000000; background-color:#E0E0E0">&nbsp;</span> White, <span style="width: 1rem; height: 1rem; display: inline-block; vertical-align: middle; border-radius: 0.4rem; background-color:#E6CC00">&nbsp;</span> Medium yellow, <span style="width: 1rem; height: 1rem; display: inline-block; vertical-align: middle; border-radius: 0.4rem; background-color:gold">&nbsp;</span> Yellow, <span style="width: 1rem; height: 1rem; display: inline-block; vertical-align: middle; border-radius: 0.4rem; background-color:lawngreen">&nbsp;</span> Chartreuse, <span style="width: 1rem; height: 1rem; display: inline-block; vertical-align: middle; border-radius: 0.4rem; background-color:#F2DFA6">&nbsp;</span> Light-gold. {{User:Arend/sig}} 14:55, October 24, 2024 (EDT)
{{@|OmegaRuby}} the guidelines stipulate to "save coloring text and table cells for cases where it aids in reading data in some way." The colors used on those tables provide quick distinction between ''New Super Mario Bros. U'' and ''New Super Luigi U'', so I don't think they would be impacted by this proposal. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 11:32, October 24, 2024 (EDT)
:I hold my opposition on the idea of any tables not being colorful at all, regardless if it assists reading data or distinguishes things - like I said, while I believe there should be consistency in tables in wiki articles I do not believe more bland, grayscale tables should be pushed when adding a dash of color or an image representing a subject doesn't exactly harm readability if implemented correctly. I do know that the proposal pushes for encouragement towards this sort of standard, but I feel as if even the simple suggestion will sway many editors into setting this as a standard. <small>I am also personally a fan of the pretty tables Doc has made, but looking at them from a readability standpoint I do know for sure they're a little ''too'' flashy and would hurt specifically the mobile wiki experience.</small>--{{User:OmegaRuby/sig}} 08:28, October 25, 2024 (EDT)
{{@|Doc von Schmeltwick}} I question why exactly you keep bringing up the fact that you have a degree in web design and art in each of these table proposals as though it serves an argumentative point. I do not feel as though it tends to add much to the conversation, nor do I feel that anyone cares. Obviously it is good to have a level of professional training in a subject, however it comes across less as a point in your favor, and more as something you choose to flex whenever anyone disagrees with you on the matter of these tables, which hurts your arguments if anything. Personally as someone who uses a wiki, I would prefer information be conveyed in a simple manner across all the devices I use, and I would prefer that information be accessible and easy to reference in text form - which images hinder. I don't really care if someone with a degree says otherwise, because I know what I prefer - and many members seem to prefer the same thing with regards to simplified tables. Just bringing up your degree as an argument and excuse to ignore feedback does not make people impressed, just annoyed and like they're being talked down to when art is a completely subjective field to begin with. --[[User:Fun With Despair|Fun With Despair]] ([[User talk:Fun With Despair|talk]]) 15:05, October 24, 2024 (EDT)
:I say that because it illustrates why I'm this weird combination of artsy and HTML-based in what I do, not to act high-and-mighty. As well as my massive inferiority complex coupled by my inability to get a job due to the current job market, I need to have ''something'' going for me or I'm worthless - and I need to do ''something'' with that training or it was all a waste of time, and I don't want to have wasted 7 years of my life. I don't think it's important or authoritative by any means - that's the reason it's shrunk. Also I like pictures. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 15:08, October 24, 2024 (EDT)
::Doc, I say this with earnest respect for the struggle to find a job and an understanding that there are difficult times in our lives during which we may lean more heavily on external sources of validation, such as our accomplishments and creations, as founts of our self-worth. I also say this recognizing that, to some degree, there may be a bit of tongue-in-cheek exaggeration in your previous response. While I think it is commendable you have the self-awareness to recognize that some of your pointing to your degree again and again in these discussions arises from your struggles to land a job in an oversaturated market and the effect that has on your own perception of the effort you put into acquiring your degree, it would be prudent to further reflect on ''why'' it serves neither yourself nor the wiki to let those struggles color your decisions and discussions regarding wiki policy, and thus why it might rub others the wrong way to have the point repeated.
::There is nothing wrong with taking pride in the work you have done for the wiki. As I understand, you have done a great deal. It doesn't serve you, however, to rely upon that work - especially any single element of it - to seek validation of your major decisions in life through that work. The nature of a wiki is collaboration and change. If not in the near future, if not through the decisions in this proposal, at some point the tables you have contributed to will change, whether it be because the collective aesthetic sensibilities of the userbase have changed, or because of a technical update necessitating it, or because someone sees an opportunity to add further information, or for any number of reasons. Staking the value of your degree to tables bound to change is building an edifice of sand by the ocean and expecting it to stand for years.  Don't tie the value of your degree to transient projects; find the intrinsic value of your degree, such as the knowledge you gained in pursuing it, and use that to bolster your perception of it and yourself.
::Further, while perhaps useful as additional context to other wiki editors explaining why your degree is so often referenced, this response also indicates this is not something which is actionable to other wiki editors. A self-described "inferiority complex" is a personal matter which only you can address, and the general wiki editor is not equipped to help you in this respect. If this is the driving factor behind your position, you may need to reevaluate whether it is truly germane to the best interests of the wiki.
::So as not to stray too far off-topic, ultimately, I want to acknowledge that this is not necessarily your only reason for opposing this proposal and plainer tables, and it does not in any way invalidate or impact your other points. It is only a word of advice. You have shown the self-awareness to acknowledge what drives you to mention your degree; extend that thinking and see why, then, that is not relevant and should not be relevant to decisions and discussions on wiki policy. [[User:Hooded Pitohui|Hooded Pitohui]] ([[User talk:Hooded Pitohui|talk]]) 16:33, October 24, 2024 (EDT)
:::Thanks. Again, I used small text to display it as not-too-relevant in the grand scheme of things but part of my basis. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:36, October 24, 2024 (EDT)
As I said on the MarioWiki Discord, "i do believe practicality of a table should prevail over the aesthetics of a table. that way, the table can be easier to comprehend. the tables as of right now look more like they belong to a fansite [...] stop all these gaudy, garish tables". {{User:PnnyCrygr/sig}} 21:50, October 24, 2024 (EDT)
:To be fair, this is a fansite. {{User:Hewer/sig}} 04:20, October 25, 2024 (EDT)
{| class="mw-collapsible mw-collapsed" style="width: 40%; float: right; text-align: center;"
|- style="background: whitesmoke;"
!Example
|-
|
{| class="wikitable"
!colspan=2 |Entry
!Name
!Value A
!Value B
|-
|style="width: 3px; background: #380000" |
!First entry
|First name
|1A
|1B
|-
|style="width: 3px; background: #9A0607" |
!Second entry
|Second name
|2A
|2B
|-
|style="background: #FEC724" |
!Third entry
|Third name
|3A
|3B
|-
|style="background: #ACBBC3" |
!Fourth entry
|Fourth name
|4A
|4B
|}
{| class="wikitable"
|-style="background: #380000; color: #fff;"
!Entry
!Description
!Another value
|-
!A
|This is the description A for the first entry.
|1A
|-
!B
|This is the description B for the first entry.
|1B
|-
!C
|This is the description C for the first entry.
|1C
|}
{| class="wikitable"
|-style="background: #9A0607; color: #fff;"
!Entry
!Description
!Another value
|-
!A
|This is the description A for the second entry.
|2A
|-
!B
|This is the description B for the second entry.
|2B
|-
!C
|This is the description C for the second entry.
|2C
|}
{| class="wikitable"
|-style="background: #FEC724; color: #000;"
!Entry
!Description
!Another value
|-
!A
|This is the description A for the third entry.
|3A
|-
!B
|This is the description B for the third entry.
|3B
|-
!C
|This is the description C for the third entry.
|3C
|}
{| class="wikitable"
|-style="background: #ACBBC3; color: #000;"
!Entry
!Description
!Another value
|-
!A
|This is the description A for the fourth entry.
|4A
|-
!B
|This is the description B for the fourth entry.
|4B
|-
!C
|This is the description C for the fourth entry.
|4C
|}
|}
In my opinion, Wikipedia has an elegant way of dealing with color in tables: they rarely use it for the visuals, but when they do, it just makes sense to have it. Take for example how they present seasons of TV shows in the example. Also, maybe people think that articles would become "too boring" or "too gray" if tables were ''completely'' standardized with no decoration at all and whatnot, but that happens because articles overuse tables in my opinion. But that's a different topic. {{User:Bro Hammer/sig}} 11:53, October 26, 2024 (EDT)
:These examples are indeed in line with the idea of generic themes I mentioned above. Of course, these examples are still on the tamer side and other styles can be added on top, but it does already look less dull while still maintaining clarity. {{User:Lakituthequick/sig}} 15:08, 28 October 2024 (UTC)
{{@|Waluigi Time}} Thank you for the suggestion. I wanted to read about horizontally aligned tables being a standard, but I couldn't find anything about it. Do you have a link you can share? {{User:Bro Hammer/sig}} 11:53, October 26, 2024 (EDT)
:Unfortunately I don't have a link on hand and wasn't able to find it myself - my knowledge on this admittedly comes from talking to people who are much more well-versed than me - but I've asked Lakituthequick to look into it. For what it's worth, the documentation I've looked at doesn't explicitly say anything about it, but all examples provided are horizontal. In the meantime, a few points in favor of horizontal alignment (in other words, one subject per row instead of per column):
:*It preserves the natural left-to-right reading flow used by the rest of our content. I think screen readers also do this, so a vertical alignment ends up being especially confusing for anyone using one, which isn't good for accessibility.
:*Only horizontal tables can be sorted, since that function works off of the headings.
:*The code is much easier to understand and edit since all the information on one subject is kept together neatly. (e.g. Horizontally, you get Mario grouped with all of his stats in a game. Vertically, you're just left with a bunch of character names, and their stats are scattered in multiple chunks further down the page.) Incidentally, this criticism is what created that "grid of infoboxes" layout you mentioned to preserve the column alignment.
:So if I was mistaken on this being an explicit standard, it still seems like best practice, at least. --{{User:Waluigi Time/sig}} 14:22, October 26, 2024 (EDT)
::Can confirm this; additionally, web standards are just written in such a way that tables have headers and footers at the top and bottom, respectively (it is worth noting that wikicode doesn't support separating [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/thead header], [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tbody body], and [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tfoot footer] elements in a table – heck, the parser actively rejects those elements when used directly). In print, this is not so much of an issue. ''Technically'' it is probably possible to rotate a table by 90° while maintaining the said pros, but this likely involves throwing a bunch of CSS (hacks) at it that require work to look good in each instance and may not be worth it in most cases. {{User:Lakituthequick/sig}} 15:08, 28 October 2024 (UTC)
{{br}}
===Stop considering reused voice clips as references (usually)===
{{proposal outcome|passed|27-2|Do not consider them references}}
More often than not, if you look at a game's list of references to other games, you'll find something about how so-and-so character reuses voice clips from so-and-so game. This has been bugging me for a while because these just aren't references. Nintendo has been reusing voice clips for multiple decades now, so this isn't anything new. When a new ''Mario Kart'' game comes out and some of the drivers reuse some wahoos or hurt sounds or whatever else from an old ''Mario Party'' game, it's not because the developers wanted to give a nod to that ''Mario Party'' game, it's because they had those clips on hand and could easily repurpose them instead of dragging the voice actor back into the recording booth. I propose removing reused voice clips from the references to other games/references in later games lists, with one exception that I'll get to shortly.
For a particularly egregious example, here's all the "references" of this type currently listed on ''Super Mario Party''. Notice how vague these entries are and how many of them don't even specify which characters have clips reused.
*''[[Super Mario Strikers]]'': Some of Hammer Bro's voice clips are reused from this game.
*''[[Mario Party 8]]'': Hammer Bro's artwork, as well as some voice clips, are reused from this game.
*''[[Mario Kart Wii]]'': Some voice clips are reused.
*''[[Mario Super Sluggers]]'': [...] Some voice clips are reused.
*''[[New Super Mario Bros. Wii]]'', ''[[New Super Mario Bros. 2]]'', and ''[[New Super Mario Bros. U]]'': [...] Some voice clips are reused.
*''[[Super Mario Galaxy 2]]'': Some of [[Yoshi]]'s voice clips are reused from this game.
*''[[Mario Kart 7]]'': Flutter's voice clips are recycled from [[Wiggler]]'s voice clips in this game.
*''[[Mario Party 9]]'': [...] Some voice clips are reused.
*''[[Mario Party: Island Tour]]'': [...] Some of Bowser Jr.'s voice clips are reused from this game.
*''[[Super Mario 3D World]]'': [...] Some voice clips are reused.
*''[[Mario Kart 8]]'': Some voice clips are reused from this game.
*''[[Mario Tennis: Ultra Smash]]'': Some of Mario's voice clips are reused from this game.
*''[[Super Mario Odyssey]]'': [...] Some of [[Mario]] and [[Luigi]]'s voice clips are recycled.
The exception to this would be if a voice clip, within the context it appears in the game, is clearly a reference to another work. I'm not sure of any actual examples off the top of my head, but hypothetically, if Luigi reused some of the "MARIO!" voice clips from ''Luigi's Mansion'' in [[Luigi and the Haunted Mansion]] from ''Super Mario Galaxy'', that would probably be considered a reference. In this case, the entry should explain exactly what clip(s) are being used and what it is about the situation that makes it a reference. That leads me into what should probably be a good rule of thumb for this exception: if you can't explain why it's a reference beyond just being in that game, then it's probably not a reference.
'''Proposer''': {{User|Waluigi Time}}<br>
'''Deadline''': November 8, 2024, 23:59 GMT
====Support====
#{{User|Waluigi Time}} Waluigi Time's support vote is reused from this proposal.
#{{User|Nightwicked Bowser}} These voice clips are most likely used without their game of origin in mind.
#{{User|Super Mario RPG}} Per both.
#{{User|Sparks}} Per all.
#{{User|LadySophie17}} ''[[Donkey Kong (game)|Donkey Kong]]'': Mario's mustache is reused from this game.
#{{User|TheFlameChomp}} Per all.
#{{User|Nintendo101}} Repurposing an asset — voice clip or otherwise — is rarely a reference in isolation.
#{{user|Doc von Schmeltwick}} - I ''swear'' this has already been proposed and passed....
#{{User|Arend}} I think this is more worth to be its own trivia subsection ("Reused assets"?) than treating it as a specific "reference" and lumping it among the more legit ones.
#{{User|Shadow2}} Per all.
#{{User|Camwoodstock}} Per all. Reuse of assets isn't really a "reference" in the usual sense, as there's plenty of non-callback reasons to do so. We don't think the re-used Charles Martinet lines in the ''TTYD'' remake were done out of wanting to do a cameo from Charles, they probably just didn't feel like bringing Kevin back into the recording booth when they already had a cohesive library of voicelines from the original game. ;P
#{{User|EvieMaybe}} per all
#{{User|DesaMatt}} per all.
#{{User|PnnyCrygr}} Per all as This "reusal of voices" statement is getting done to death over and over again. And a reuse of assets is not an allusion/reference to something.
#{{User|ThePowerPlayer}} ThePowerPlayer's "Per all" vote is reused.
#{{User|Cadrega86}}, the same also goes for generic artwork (so unless it's specifically stylized or features stuff specific to a single game/subseries). These are not references but just "lazy" asset re-usage.
#{{User|Technetium}} Per all.
#{{User|Jdtendo}} Per all.
#{{User|Ray Trace}} Grunts, screams, and whoohoos aren't uttered with a specific game in mind and our articles shouldn't reflect that.
#{{User|Scrooge200}} This has been bugging me for a while. This is just asset reuse to save budget and because there's very few specific lines that need to be newly recorded.
#{{User|Mario}} Just because it was first heard in a game doesn't mean it was recorded for this game. It might be a stock sound that went unused and eventually found its way into a future game. Additionally there are clips that are better known in other games than the one it originated in. "That's-a so nice!" Is commonly heard when Mario clears a level in New Super Mario Bros., but this quote is first heard in Mario Kart Double Dash, barely audible in the Awards Ceremony. Unless the clip itself is made specifically for a game (Mario vs. Donkey Kong!!! Finding its way in a Mario Kart game as a store speaker or something) it's best not to list as a reference. That being said, there should be ways to list if voices have been reused.
#{{User|Tails777}} This is on par with referencing ''Super Mario Galaxy'' every time Rosalina appears. Pretty sure we had a proposal at some point opting to exclude these types of recurring things from the references section and this is just following in suit. Per proposal.
#{{User|DryBonesBandit}} Reusing a "per all" vote from previous proposals.
#{{User|BlueBirdBlues}} Reusing assets are, in most cases, not references. That being said, I do feel like we should document these reused assets ''somewhere'', perhaps on a separate [[List of reused assets]] article? Creating a new subsection in each article for these reused assets would work too, I suppose.
#{{User|SeanWheeler}} Don't want to bloat the references section of each game's page.
#{{User|ExoRosalina}} Reused are unlikely as references, especially voice clips.
#{{User|Okapii}} Per all; voice lines in the Mario franchise have been reused so many times that what game they originated in feels almost meaningless, and making a note for every time any character reuses a specific line just feels like pointless bloat for the reference section.
====Oppose====
#{{User|Hewer}} I think a game reusing assets like voice clips from a previous one is still worth noting, and the reference sections are a handy place to do it. I don't see why we must restrict the section to only when "the developers wanted to give a nod".
#{{User|Pseudo}} Per Hewer. I do get that it's not an intentional reference per se, but this is still information worth documenting on the wiki (if a different place to note this information would be proposed, I'm all ears).
====Comments====
I do know Luigi's "Gotcha!" was made for ''Luigi's Mansion'' as a thing he says when he catches ghosts, then became a standard voice clip for him in 64DS and NSMB, despite no longer making as much sense there. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 11:46, October 27, 2024 (EDT)
I would also like a place for people to note when new voice clips get recorded. I think the Protrayals section of character articles makes a fair amount of sense. Or maybe in Development sections of games? [[User:Salmancer|Salmancer]] ([[User talk:Salmancer|talk]]) 21:07, October 30, 2024 (EDT)
===Encourage game-related "icon"-type images to have consistent file dimensions with each other when applicable to their origins===
{{proposal outcome|failed|6-22|Do not adjust the rules}}
[[MarioWiki:Proposals/Archive/70#Prioritize sprite/tile uploads that have their original file parameters (or clean divisions of them)|My last proposal]] related to this subject had too many holes in it due to being too wide to make an actual rule on the subject. Indeed, not all sprites really need the blank space, not all "icons" are sprites at all. To recap:
;this looks good:
<gallery heights=64 widths=64>
MKDD_Mario.png
MKDD_Luigi.png
ToadIcon-MKDD.png
PeachIcon-MKDD.png
MKDD_Yoshi.png
MKDD_DK.png
BowserMKDD.png
MKDD_Wario.png
</gallery>
;this does not:
<gallery heights=72 widths=72>
MarioMPT.png
Luigi MPT.png
Shy Guy MPT.png
Peach MPT.png
Yoshi MPT.png
DK MPT.png
Bowser MPT.png
WarioMPT.png
</gallery>
Notice how half of the MPT ones (second row) are awkwardly, inconsistently stretched in various gross ways that makes some of the pixels be rectangles, and none are at a proper size relative to each other - this is an obsessive-compulsive spriter's worst nightmare. Meanwhile, the MKDD ones (first row) look crisp, clean, and are at a nice size relative to each other. Why is this? Because since they are icons, they are programmed to occupy the same type of space in select screens and player standings in-game. They're ''supposed'' to be at around the same size, which is accomplished through the small amount of empty space some have in the upper right corners - which the origin images have in the game's files. We should reflect this for the simple reason that we're only going to be putting these in galleries and table cells with each other ''anyway'', so it makes the most sense to have them take up the same amount of space here as well. They should either be at their raw parameters, or if they are cropped, cropped to the exact same size as all the others for that type in that game so as to not screw up formatting and table cell sizes (and we shouldn't be increasing the size of sprites that are at this size by default anyway). This goes for selection icons, rank icons, map icons, that sort of thing. Cropping them down needlessly leads to the grossness that the second gallery there displays.
This is already something of an unofficial rule on here; a majority of the games with this sort of icon have them uploaded at a consistent size already for the same pragmatic reasons I just listed. I'm just trying to make this more clear-cut. It's like how "don't optimize images with color-changing metadata" is a rule - most people can't tell the difference, but it minorly affects the accuracy and presentation, so that's why that rule is in place. This is also for the "accuracy and presentation" reasoning. Also, I fail to see what the difference is between this and preferring screenshots be uploaded at native res rather than boosted resolution.
'''{{color|purple|THIS DOES NOT COVER THE RARE INSTANCES GAME ICONS ACTUALLY ''DO'' HAVE DIFFERENT SIZES AS STORED IN-GAME.}}''' Instances of that are quite rare, especially for character icons that swap locations, but they can happen. Since they aren't the same size to begin with, there's nothing to match up with. It also does not apply to ones that are extrapolated from a singular group image containing all of them.
'''{{color|purple|PLEASE NOTE THAT MOST IMAGES OF THIS TYPE ON THE WIKI ALREADY FOLLOW THIS RULE.}}''' Attempting to do the opposite, therefore, will take more effort for less reward.
'''{{color|purple|ADDITIONALLY, I WANT TO CLARIFY THAT THIS IS NOT SPECIFICALLY STATING THEY NEED TO KEEP THEIR NATIVE DIMENSIONS.}}''' Rather, it is saying that if you ''do'' decide to crop them, you should crop them to consistent parameters, ie, the width of the widest one and the height of the tallest one. Having to resize images on an individual basis is tedious and can lead to extra HTML bloating the page that would be a non-issue if they were uploaded at the same size to begin with.
'''{{color|purple|EDIT:}}'''
Here's a better illustration of why I think this is necessary:<br>
https://www.marioboards.com/attachments/49667.png
<br>Notice how with them cropped to content, their vertical (and horizontal if they were stacked, thanks to Klap Trap's muzzle and Diddy's hat) positions are all over the place. To someone with OCD, that's maddening. Not unlike [https://www.xkcd.com/1015/ bad kerning]. This is what this proposal hopes to avoid. And no, that's not something a "rawsize" thing can do, that's gallery-only - and this inconsistent positioning would be an even bigger issue with the images in a gallery, since those ''don't'' have positioners available. And while technically, HTML ''can'' fix the positioning on the table (but again, not in a gallery), that would require a bunch of finagling span classes that would bloat the page's byte count unnecessarily - not to mention take potentially hours of trial and error depending on the image amount - when the obvious solution is to give the images the consistent parameters they were deliberately made to have - and yes, that's deliberate in more than just "limited by sprite parameters," because they used them to position them accurately in the character/level select, as I am doing with this table.
'''Proposer''': {{User|Doc von Schmeltwick}}<br>
'''Deadline''': November 11, 2024, 23:59 GMT
====Support - consistent icons (change the few remaining icon images and make it a general rule for the future)====
#{{user|Doc von Schmeltwick}} - ''Icon'' haz dead, never-funny-in-the-first-place memes about fast food sandwiches?
#{{user|Super Mario RPG}} - Accurate to how the graphic or texture is stored in game.
#{{User|Hewer}} Per fast food sandwiches
#{{User|Ahemtoday}} Per proposal.
#{{User|blueberrymuffin}} Per proposal.
#{{user|wildgoosespeeder}} I don't bother cropping anything for this kind of reason. [[tcrf:The Cutting Room Floor|The Cutting Room Floor]] doesn't do something like this because of prioritizing consistency in dimensions, where possible.
====Oppose - who needs consistency? (do nothing)====
#{{User|Waluigi Time}} Rawsize exists.
#{{User|Koopa con Carne}} There's no sense in ''deliberately'' translating the functional limitations of a game onto a wiki. The site's educational purpose dictates that official material shown on a wiki be inherently recontextualized, and showing that material at a different scale than originally intended is in line with that idea. Even taking into account the niche interests of a sprite enthusiast (which TBH is fair, the wiki is a gateway to Mario material for anybody), the sprites in and of themselves are accurate to how they were extracted when you view them on their dedicated file pages; it's only their appearance on mainspace pages that is subject to alterations, and what to what degree that is beneficial is better scrutinized on a case-by-case basis than through a global proposal. TLDR If the sprites are too uncomfortably big just resize them, or use rawsize like Waluigi Time says.
#{{user|Lakituthequick}} Per WT.
#{{User|UltraMario}} Per all. This can easily be taken care of by either a gallery or a table's settings, I am very sure of that. We don't need to be unnecessarily tampering with perfectly cropped files. I am not 100% sure of the technical site of the wiki but I am very sure that there are better ways to go about fixing sizing of things in tables not being adequate without just having to overhaul image uploads entirely, rather than just playing around with a table.
#{{User|Fun With Despair}} Seems like a huge amount of work for what is... honestly imperceptible to 99.9% of users such as in your example. Busywork for the sake of busywork.
#{{User|Shy Guy on Wheels}} Per all. I see no real benefit from this.
#{{user|Sdman213}} Per all.
#{{User|Camwoodstock}} Per all, especially Waluigi Time. We already have tools capable of representing these icons more accurately to their in-game versions as necessary without requiring deadzones or other such things to be baked into the image itself. In fact, baking it into the image itself can cause issues when attempting to use the same image on different pages not fitted for them; such as how the image on the infobox for [[Blooper (Paper Mario: The Thousand-Year Door)]] is markedly smaller because it retains the blank space for the sake of [[Paper Mario: The Thousand-Year Door (Nintendo Switch) bestiary|the bestiary article]]. While we should strive for accuracy, we shouldn't let it get in the way of making the information actually accessible and readable; besides, if someone wanted the raw, original images, including any blank space around them, they would likely check The Spriter's Resource, not us.
#{{User|Ray Trace}} Per Koopa Con Carne. Zero readers care if an asset is cropped to content to dimensions in the power of 8 or if they have the ripped dimensions, especially if all said images are there to illustrate a gallery and especially if there is copious amounts of empty space just to pad the image to appropriate dimensions for a game engine. We aren't a game engine (modern game engines are perfectly capable of having textures in resolutions not in powers of 8 by the way), official websites such as the Mario Kart 8 Deluxe's official website [[:File:MK8DX Baby Luigi Icon.png|crop to content]] because image editors know that it doesn't need to be in those dimensions (let's not get into how these assets are actually made, they're scaled down in the first place 100% for game engine reasons) icons should be cropped to editor's discretion without bludgeoning editors over the head about it, we should prioritize optimization and readability over faithfulness to asset dimensions. I can see cases where consistent sizes can work out, namely the character icons as listed in this proposal, but the general rule ''should'' be crop to content, but leave some in exceptions in regards to formatting tables, not the other way around.
#{{User|TheFlameChomp}} Per all.
#{{User|ThePowerPlayer}} Per all.
#{{User|Shoey}} Per all.
#{{User|Jdtendo}} Per all.
#{{User|Cadrega86}} Per all, especially Koopa con Carne and Ray Trace.
#{{User|Axii}} Per all.
#{{User|SeanWheeler}} Some really small icons like the Super Smash Bros. series stock icons would look really bad if they were resized to be consistent with Mario Kart ranking icons.
#{{User|Mario}} The additional caveats in the proposal trying to address this issue is nice I guess but it makes the proposal much less clear in what it's trying to accomplish and it comes off as this user trying to bludgeon over their approach to these images in opposition with several other people's while tacking on qualifications and caveats after the fact. It doesn't help that the terminology of the proposal is imprecise (what is a "game-related 'icon'-type image"?? Does the proposal apply to whatever is a "game related 'non-icon' type image"?)  Per all.
#{{User|Killer Moth}} Per all. I don't see the point in doing this.
#{{User|Nintendo101}} I will reiterate what I said below: if folks want to maintain unified dimensions around certain assets, like the ones in the ''Diddy Kong Pilot'' example, that is completely fine and okay to do. I agree it looks nice. However, folks should have the freedom to choose whether they want to do that or not with the tables and templates they have developed. To experiment. I agree with the opposition that cropping to the visual content of an asset is not inherently destructive, while recognizing there are real examples on this wiki where assets benefit from having unified dimensions outside of galleries. But those were choices made because they are visually appealing and convey information - not out of a unique reverence for how computer engines spatially store assets, and while I know this proposal is not explicitly advocating for that, it derives from similar arguments made in the previous one, and I wanted to touch upon that here. We adjust assets all the time for the sake of illustrative intent. We assemble disembodied sprites. Adjust/add colors to reflect in-game appearances (especially when they are not actually coded as such for older consoles). We pose models. We approximate lighting conditions. We crop out screenshot details for a focused view. We narrow displays to omit details that the player typically has [[:File:MagmawNSMBU.png#File history|no way of seeing]]. From my experience, none of these choices have been considered controversial, and they should not be. They are not dissimilar from {{wp|taxidermy}}, {{wp|Conservation and restoration of paintings|art restoration}}, and similar curatorial techniques that are exercised in museums worldwide. To me, cropping to visual content - the pixels that people can actually see - is no different from these methods and not an inherent problem. If folks want to keep unified dimensions around the assets they are working with or see use outside of galleries, that is fine and good. This is the opinion of some other folks in the opposition, like fellow ripper Ray Trace, as evident [[:File:WarioMASATOG.png#File history|here]]. However, if folks do not want to do that, or use tables built on the expectation that assets they are using are cropped to content, or they are cropping the content around assets that are only found in galleries, I think they should have that freedom too.
#{{User|MCD}} Per all.
#{{User|FanOfYoshi}} No. No, both look good in their own right. Per all.
#{{User|SmokedChili}} Per all.
====Comments====
{{@|Waluigi Time}} - Rawsize doesn't help for tabular data. Only for galleries. Only way to get it there would be to separately size each cell, and even that doesn't keep them in the correct position within the cell. Wouldn't it be more pragmatic to just have the images at the correct size rather than having to mess with the HTML each time? And we do indeed use these for tabular data, like ghost times, tennis rivals, that sort of thing. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:43, October 28, 2024 (EDT)
:And would that not be easily solved by displaying the image at its native resolution (or at least consistent resolutions for all of them) and centering it? --{{User:Waluigi Time/sig}} 16:51, October 28, 2024 (EDT)
::No, it absolutely wouldn't. Because not all the icons are themselves centered, such as the MKDD ones above. They all come out of the lower-left corner. And that's not getting into how some games have a variant with an actual shaped background alongside clear-background ones, like ''[https://www.spriters-resource.com/wii/mariostrikerscharged/sheet/195218/ Strikers Charged]'' for example. It'd make the most sense to match those up relative to where the square bounds are for their respective size, IMO. Also, when they need shrunk for smaller tables, it's easier to do that when they have the same x-y parameters anyway so you don't have to check every. Last. One. And do the math each time. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:52, October 28, 2024 (EDT)
::{{@|Waluigi Time}} - Rawsize also doesn't work for sizing images down. Only sizing them as-is or sizing them up. So it's still not a perfect solution for all occasions anyway. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 02:48, October 29, 2024 (EDT)
:All of these things can be fixed using <code>text-align: center</code>, <code>vertical-align: middle</code>, and the inherent ability of tables to size columns and rows based on their contents. {{User:Lakituthequick/sig}} 20:55, 28 October 2024 (UTC)
::I already said that's not true, because not all of them are centered in their origin. If you want DK's image's left border touching the left border and his right border touching the right border, and the same to go for Luigi, that will absolutely not work unless they are uploaded at their intended size. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:58, October 28, 2024 (EDT)
{{@|Koopa con Carne}} - I thought you didn't want math to be forced onto the site. In order to resize them consistently if they aren't uploaded at the intended consistent size, you have to go through ''every single one'' and check their sizes individually, ''then'' apply whatever size change also individually in order to be consistent. Keeping them as they are intentionally incorporated into the game is much cleaner on both counts. If mediawiki had a "50%" in addition to the pixel resizing, that wouldn't be an issue, but they don't. And applying a same-pixel-size on sprites with different base sizes is just dirty. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:04, October 28, 2024 (EDT)
:You're misconstruing my point about math on the wiki. I never suggested curbing the use of math in the back end by editors (even then, I don't recall ever actually mathing my way through editing a page other than establishing sizes of things like images and charts). It was strictly in reference to the math that is displayed, for one reason or another, to readers, specifically how serviceable it is for articles to show readers more complex formulas versus simple tallies of elements in a level. I've long digressed though, lol.<br>The issues you bring up are solvable on a case-by-case basis. I like consistency and tidiness, too, however, those ought to have a healthy marriage with the wiki's primary interest to educate. [[Mario_Kart_Tour_race_points_system#Object interactions|Here]], you'll notice I purposefully enlarged the icon for the Giant Banana item relative to the regular banana peel, because it used to look about the same size, which was odd. I understand where you're coming from and I support giving a sense of scale to sprites of a certain type in a row if it would otherwise look too messy or unnatural, but I don't believe that has to be enforced among all these sprites indiscriminately. {{User:Koopa con Carne/Sig}} 18:23, October 28, 2024 (EDT), edited 19:03, October 28, 2024 (EDT)
::Well this proposal isn't about "all sprites," it is specifically about icons within a particular family, ie, all MKDD character select icons are one family, all MKDD item icons are another family, all MKW select icons are yet another family, etc. etc. etc. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:30, October 28, 2024 (EDT)
:::I understand. That's what I meant when I said "sprites of a certain type in a row". That's a tad wordy, so I guess "sprite family" can indeed be used for the purposes of this proposal instead. {{User:Koopa con Carne/Sig}} 18:59, October 28, 2024 (EDT)
::::OK so.... what is the negative you are seeing to this? It seems like you agree with what the proposal actually aims to do, so I'm not really understanding your opposition. It's like how "don't optimize images with color-changing metadata" is a rule - most people can't tell the difference, but it affects the accuracy and presentation, so that's why that rule is in place. This is also for the "accuracy and presentation" reasoning. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 19:07, October 28, 2024 (EDT)
:::::What I agree with, is that assets extracted from the game shouldn't be tampered with before they are uploaded on the wiki. The native size and optimizations should still inherently be part of the asset. What I disagree with, is that such a principle should extend to their presentation on mainspace articles. An image gallery is not a sprite sheet, it's '''demonstrative'''. If you think a gallery of assets can benefit from a few fine adjustments to accommodate scale and aesthetic sensibility, by all means do it. I agree the Shy Guy icon you show in the proposal looks too large and should be scaled down a little, as I did with the giant banana I mentioned previously. Enforcing the standard you propose across a demonstrative gallery is shifting the priority on technical accuracy. {{User:Koopa con Carne/Sig}} 12:19, October 29, 2024 (EDT)
::::::The actual argument of this proposal is different from the last one. This isn't specifically aiming for native dimensions, though that would still be the "easy way" imo. This allows for cropping as long as the cropping is to a consistent size for said related assets. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 12:40, October 29, 2024 (EDT)
{{@|UltraMario}} - You... ''do'' realize that ''cropping'' the files is where the "tampering" comes into play, right? If they're displayed as they are in the game, they are ''un''tampered with. Cropping them down is, by definition, tampering with them. I think you need to reword that. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:07, October 28, 2024 (EDT)
{{@|Fun With Despair}} - Except most of them are ''already'' like this - this is just making an unofficial rule we've used for years an official one for practicality. In this case, doing the ''opposite'' would be busywork. And making them consistent is busywork I am willing to ''do''. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:35, October 28, 2024 (EDT)
:Besides, being a lot of work hasn't stopped [[MarioWiki:Proposals/Archive/68#Require citations for names in other languages|proposals that take even more work to implement]] from passing. It's a flimsy reason to oppose a change. {{User:Hewer/sig}} 18:02, October 28, 2024 (EDT)
::Not opposing because it's a lot of work, opposing because it's a lot of work in service of something that is unnoticed and not cared about by the vast majority of users. The citation proposal is a bad example because that is actually something important to the accuracy of information on the wiki. This doesn't do much of anything at all besides force small edits to many old images.--[[User:Fun With Despair|Fun With Despair]] ([[User talk:Fun With Despair|talk]]) 18:33, October 28, 2024 (EDT)
:::That could be said about proposals in general. If it doesn't matter to you, wouldn't it make more sense to not vote at all? If I see a proposal on a subject I don't care about, I just don't vote. After all, if it matters to ''someone'', it matters in general and shouldn't just be opposed because of what amounts to "I don't care about this." [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:36, October 28, 2024 (EDT)
:::I'd argue a majority (or at least significant number) of readers likely don't care either way about citations for names in other languages. But that doesn't mean people who do care about the change don't exist, or that it's inherently a bad change. I think "eh who cares" is also a flimsy reason to oppose a change. {{User:Hewer/sig}} 18:38, October 28, 2024 (EDT)
Wait, so if this is already often the way things are, will the oppose option change that? That would mean this proposal lacks a "do nothing" option. {{User:Hewer/sig}} 18:07, October 28, 2024 (EDT)
:Oppose is a "do nothing." I'm not going to include an option for what I would consider a ''negative'' change. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:28, October 28, 2024 (EDT)
::Wasn't suggesting you should, just got confused since you were making comments about "doing the opposite". {{User:Hewer/sig}} 18:31, October 28, 2024 (EDT)
:::That was mainly directed at the "too much work" argument. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:32, October 28, 2024 (EDT)
{{@|Camwoodstock}} - Things like the TTYDr bestiary images are not covered by this proposal, only small icon sprites that are intended to be square anyway. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 19:46, October 28, 2024 (EDT)
:For the record, we know that wasn't exactly what the proposal was targetting, we mostly mentioned it as it's a pretty striking example of how including these transparent margins in the images themselves can backfire (besides, it's one of the most recent examples of such a thing happening.) We hope that makes sense, anyway. {{User:Camwoodstock/sig}} 19:48, October 28, 2024 (EDT)
::I still don't see why it's preferable to be forced to use the HTML to make them somewhat close-ish to accurate when simply letting it have the one or two columns of blank pixels that it's supposed to have on one side of it would look better for practical reasons anyway. It's a lot simpler and doesn't hurt anything to do. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 19:52, October 28, 2024 (EDT)
:::Because sometimes, you ''don't'' want them to be entirely accurate; while an original-resolution image might be wanted for, say, a gallery or a table, in an article, template, or especially in an infobox, you probably don't want the original size and would want something a lot more readily scalable, without transparent margins baked into the image that you need to futz with. At best, it would be too small to add a proper caption to; at worst, you basically gut the clarity of the image itself. For example, while not an "icon" in the sense of the original proposal, the articles for various objects from [[Super Mario Land]] upscale the images outside of their original context. Infoboxes on articles such as the [[Lift Block]] would be rendered borderline incomprehensible if the images were not enlarged like this. And the grown image size is accomplished not via baking it into the files themselves, but via using fairly basic wikiscript or HTML; that way, on the main article, they can still appear in their original format. This general philosophy applies to icons as well, which is why we bring it up.<br>Again, if someone was looking for the raw, unedited sprites, they would likely head to The Spriter's Resource and not us; our goal here is to make these images accurate, of course, but we need to make them both usable in articles and also keep them standardized between one another; baking transparent margins into the images themselves, even if technically accurate to the source material, does run counter to that latter goal. {{User:Camwoodstock/sig}} 21:09, October 28, 2024 (EDT)
::::There are plenty of instances where we'd have to edit ripped textures anyway because they're ripped rotated or flipped. Cropping to content is similar to those nondestructive edits and I still fail to see how it's such a big issue, we don't need to preserve transparent pixels just because image editors deliberately padded out assets just for the game engine to decipher properly. Otherwise we should upload sprites without any color data and their palette data as separate entities. {{User:Ray Trace/sig}} 21:15, October 28, 2024 (EDT)
:::::It's destructive to me. ._. Also, saying "zero" readers is obviously wrong if there's people supporting this. "Who cares" is never a good argument. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 22:10, October 28, 2024 (EDT)
::::{{@|Camwoodstock}} - Boosting them by a consistent size factor (like 50%, 200%, 300%, etc) is perfectly fine - Lift Block, for example, is sized up by 1000%. And it's a lot easier to do that when they have consistent base dimensions so you don't have to look the specific dimensions to resize them by for each image separately. Having all the 32px images display at 64px is a lot simpler than having to look through each to see which needs to be at 64, which needs to be at 62, which needs to be at 58, and so on. That's pointless, tedious, and can be prevented completely by doing what this proposal aims for. And again, non-consistent size factors, like "just make them all display at 50px!" are really messy - see the ''Mario Power Tennis'' example above, and how Shy Guy's icon is ultra pixelated while Bowser's is fairly crisp. It's grossly inconsistent, and on a table, it can't just be rawsized with a percentage (and rawsize in galleries only works for making them ''bigger'', not ''smaller''). [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 00:45, October 29, 2024 (EDT)
::I was the one who uploaded these bestiary images, and I had a few reasons. The main one is that some images like Smorg are cut off by the borders and would look strange when cropped. Also, since each of the Tattle Log images display against a border and background that I was also able to rip, I was hoping we'd be able to fit the enemy images over the background and border so it'd be more accurate to how it appears in-game. {{User:Scrooge200/sig}} 20:30, October 29, 2024 (EDT)
By the way, a striking example of ripped assets that are extremely counterpoint to this proposal are the [[Mario_Party:_Island_Tour#Spaces|Mario Party: Island Tour]] space icons. Every single one of those icons are cropped from a single texture that compiles all of them, absolutely requiring you to crop images and then crop to content because none of the options suggested that would "encourage" them cover those instances. Hence why I think it's extremely pertinent to encourage crop to content except for formatting purposes in regards to tables. In addition, icons ripped may also come with engine gamma-fixes or even be outright flipped or rotated all which require correction in display for browsing purposes. {{User:Ray Trace/sig}} 21:10, October 28, 2024 (EDT)
:Hence "when applicable to their origins". As that one is done differently, it is not applicable. {{file link|MK8DX-BCP audience TVV.png|This texture}} was stored in a similar manner with all eight of its frames in a single image (evenly spaced), while there's also {{file link|MKAGP audience.png|this group texture image}} that has someone sideways. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 22:06, October 28, 2024 (EDT)
Some important things to note:<br>
'''1.''' The proposal only applies to icons that have a natural similarity, such as characters, items, board spaces, badges, etc. It does not apply to textures, screenshots, logos or scanners.<br>
'''2.''' In fact, the wiki and the TSR do not have the same purpose. The wiki is not a graphics museum, nor does the TSR have informational content. But this has nothing to do with what the proposal suggests is the organizational factor.<br>
'''3.''' "Who cares?" Yes, the readers and Super Mario enthusiasts who visit the site every day may not care. But the proposal is not for them. After all, are they the ones who vote here? The proposal is for the editors, for those who submit images and create galleries. Approving this would only be a way to better organize what is already common practice.<br>
'''4.''' This prevents things like {{file link|M&S2014 Mii Costume 55.png|it}}.<br>
[[User:blueberrymuffin|blueberrymuffin]] ([[User talk:blueberrymuffin|talk]]) 17:44, October 29, 2024 (-03 UTC)
:What constitutes as an "icon" is entirely arbitrary in terms of graphics, there is technically no difference between graphics HUD of a character's disembodied head in a map and images used as flair in menus, or images of items in say Mario Party 4, or little images in the group photo in ''Mario Superstar Baseball''. As for the "who cares" statement, that's specifically why I voted to oppose: '''I''' don't care about what this proposal wants to implement, I think it's way too draconian for the purposes of this wiki, and I am having my voice heard, and there is a discernible amount of people who share that sentiment. ''Editors use this wiki too''. I also don't see the issue with the cropped Mii suits, MediaWiki has the tools to format those images should they be formatted. {{User:Ray Trace/sig}} 23:18, October 29, 2024 (EDT)
::"MediaWiki has the tools," does it? Please tell me how, using the <nowiki>[[File:xxxxxxx.png]]</nowiki> type of image, you can implement a resizing of, say, "50%" rather than individually going in and checking the pixel dimensions and dividing it by two yourself. As far as I am aware, you cannot, and when there's 70 or so images all with different dimensions, that's adding a needless amount of tedious work when the obvious solution is to give them the same dimensions in the first place so it only needs done for ''one'' value. And obviously, what makes an icon is determined by whether it is ''used'' as an icon. That doesn't even need said, so I don't know where you were going with that. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 00:29, October 30, 2024 (EDT)
I do not know if this has been mentioned or demonstrated yet, but '''this is what the ''Mario Kart: Toadstool Tour'' icons look in a gallery when rawsize is integrated''':
<gallery class=rawsize>
MarioMPT.png
Luigi MPT.png
Shy Guy MPT.png
Peach MPT.png
Yoshi MPT.png
DK MPT.png
Bowser MPT.png
WarioMPT.png
</gallery>
and this is what they look like when it is added to '''the gallery as laid out in this proposal, with heights and widths set to 72'''.
<gallery class=rawsize heights=72 widths=72>
MarioMPT.png
Luigi MPT.png
Shy Guy MPT.png
Peach MPT.png
Yoshi MPT.png
DK MPT.png
Bowser MPT.png
WarioMPT.png
</gallery>
I do not know if this is apparent in all displays, but Donkey Kong and Bowser are smaller than they should be in the second row. This is happening because the dimensions set for the gallery (72) are smaller than the dimensions of the sprites for DK and Bowser. '''When the heights and widths are changed to 79 (the pxl height of the biggest sprite), it looks like this''':
<gallery class=rawsize heights=79 widths=79>
MarioMPT.png
Luigi MPT.png
Shy Guy MPT.png
Peach MPT.png
Yoshi MPT.png
DK MPT.png
Bowser MPT.png
WarioMPT.png
</gallery>
I do not know if has been alluded to elsewhere in the discussion or changes anything, but I just wanted to point this out. In galleries, you can use rawsize to accurately display assets to scale as long as their are no dimensions set for the gallery, or the dimensions set are larger than the largest sprite. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 20:04, October 29, 2024 (EDT)
:But you can't ''shrink'' them or use that outside of galleries, so it is not a solution to the primary issue of "it screws up table cell widths and heights," and "you'd need to go in and resize each individually on a table since mediawiki doesn't have a percent-based standard image-resizer, only a pixel-based one, and that's an unnecessarily large amount of work and added HTML for adding proper-sized bounding boxes separately, needlessly bloating the page's byte count when the easy, practical, and obvious solution is to just upload them with the intentional shared dimensions in the first place." [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 00:26, October 30, 2024 (EDT)
::I honestly feel these are valid points. I found instances where it is easier to us certain assets in tables when they are all squared in dimension, and I personally have not heard persuasive reasons why easy integration into templates or tables should always take a backseat to their presence in galleries since we are primarily a resource to be read. Not just browsed. However, this is again a case where I feel allowing users to exercise discretion would be better than a rule. For example, I agree that squaring the ''Double Dash!!'' icons is nice, but I don't know how that really benefits the display for the ''Mario & Sonic'' Mii costumes.
::For clarity, I would not support a proposal that insists we must always crop to content. I understand assets are not always restricted to galleries, and tables and templates are often setup with reliable size parameters. It is generally easier to edit an asset once rather than adjust all the tables it appears to ensure it is displayed in a preferred way, and while cropping to content is nice, I do not personally think it really "ruins" the display in a gallery if one or two assets are out of alignment with their neighbors or look smaller in preview. I at least do not think it is so unsightly that cropping to content should be prioritized over their utility outside of galleries. Users should have the ability to exercise discretion. It remains an important part of making this a communal space. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 02:28, October 30, 2024 (EDT)
:::Keep in mind the proposal is not specifically about keeping the original dimensions, it's more about consistency - cropping can occur as long as that too is consistent. And if an icon is completely unique and not part of any "family" with other ones, then it doesn't matter. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 02:36, October 30, 2024 (EDT)
{{@|Doc von Schmeltwick}} I think you're missing the point the opposition here or in the previous proposal is trying to make. As far as I'm aware, no one's saying "never do this". It's already done on the wiki, and it's good when the circumstances call for it. I don't think the ''Diddy Kong Pilot'' example you posted is that bad but it's definitely better at the consistent dimensions, and I don't see anyone here clamoring to crop down the ''Double Dash'' icons either. What I take issue with, and I assume many of my fellow voters feel the same, is this proposal's goal to essentially enforce that across the wiki whether it's helpful and wanted for design purposes or not. The ''Mario Power Tennis'' icons you used as an example aren't currently used anywhere on the wiki where inconsistent dimensions actually matter. I assume the [[Mario_%26_Sonic_at_the_Sochi_2014_Olympic_Winter_Games#Costumes|''Mario & Sonic'' Mii costumes]] would also get caught up in this since they're technically icons, but in my opinion, consistent sizing is unnecessary and the images look worse with the extra space needed to accommodate the largest costumes. At the very least you can't say it looks objectively worse that they're not all centered in this case. You've mentioned having OCD several times in these types of discussions, so I recognize and sympathize that some of these inconsistencies can be frustrating for you, but your personal preferences and irritations aren't always going to reflect the majority of the userbase.
Also, the reason rawsize keeps getting brought up is because ''you'' were the one who started this proposal with a comparison of images in galleries and made it seem like a key point of your proposal. I'm not sure why you did that, and it feels misrepresentative of the situation at best since [[MarioWiki:Proposals/Archive/68#Expand_use_of_.22rawsize.22_gallery_class|you were the one who proposed its wider usage a few months ago]] and should've known it was an easy solution to the specific problem you were presenting. --{{User:Waluigi Time/sig}} 14:59, October 30, 2024 (EDT)
:I know I proposed that addition. I mainly used a gallery as an example here because it was convenient to bang out quickly, not at an illustration that it is the only issue brought on by this. In regards to making it a rule though, please recall I am not stating here it "has" to be the native dimensions specifically. Also, we have other image upload rules that some people and/or wikis might consider "draconian" but have been around long enough here that they make perfect sense to us (don't upload non-animated .gif's, don't convert .jpg's to .png's and especially don't give them transparency, don't optimize images with metadata, and the above proposed one with currently unanimous support regarding NES palettes), so I really don't see how this ends up any different. I specifically noted in the proposal and its very title that if it straight-up doesn't work in whatever context, that it doesn't need done for it, so I don't see how it ends up as a problem anyway. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 15:58, October 30, 2024 (EDT)
:: This unfortunately contributes to the same problem I had with the previous proposal. Your reply here makes it sound like there would be no substantive or practical difference between how folks generally handle assets already, making it unclear what would actually change if the proposal were to pass. What would change? — [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 16:42, October 30, 2024 (EDT)
:::Because when I tried to enforce "how folks generally handle assets already" it was treated as me going notably out-of-line. There's always gonna be ''someone'' who uploads a .jpg -> .png image because they don't know any better or don't realize it (I'm guilty of the latter from before I knew to check with the "save image as" function), and that needs to be corrected - it is how we "generally do things," but we do it because that is a thing that needs discouraged, hence there being a rule. I see this as no different from that. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:52, October 30, 2024 (EDT)
::::This proposal is just going to result in a patchwork of interpretation of how to approach these assets. It's a sign of a very flawed proposal. Doesn't help that your entire bedrock of reasoning that led to this kind of proposal (that we should be encouraged to maintain the original dimensions of a ripped sprite), which I have deemed utter nonsense and I stand by it being utter nonsense, continues to be maintained. This leaves me with a not very confident impression you have any clue how these assets are created, stored, and used in a video game, that you understand ''why'' an asset is padded and has dimensions of 128x256 or something and ''why'' this doesn't mean a wiki should be necessarily maintaining these dimensions. {{User:Mario/sig}} 00:33, October 31, 2024 (EDT)
:::::I have explained time and time and time and time and time and time again that ''this'' proposal ''does NOT'' require the original dimensions. Just ''shared'' dimensions. I figured putting it at the top in '''{{color|purple|ALL-CAPS BOLDED BRIGHT PURPLE}}''' would be enough to get people to actually read and realize this, but apparently not. Please acknowledge this and stop treating it as though that is my argument here when it is ''not''. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 01:02, October 31, 2024 (EDT)
::::::Let me clarify: when I mentioned the bedrock of reasoning, I meant to contextualize the situation that led up to the proposal. It's to support my criticism of your proposal, which was made in response to the earlier one that was canceled from mounting opposition, that this follow up proposal is poorly made. Due to the timing of things, it comes off as an attempt to simultaneously continue your practices of insisting that image dimensions are important information to maintain (they are not) but with flawed solutions designed around this flawed principle. To me, this is a confusing proposal that will lead to conflicting approaches to how an asset will be handled, and the examples used don't do a great job clarifying points (this example shouldn't even be a table imo). {{User:Mario/sig}} 02:04, October 31, 2024 (EDT)
:::::::They absolutely are, but regardless of that, if it ''wasn't'' a table and were instead a gallery, the OCD-triggering vertical position issue would be even worse. (Seriously, I'd get less feeling of disgust from an animated loop of Wario puking up an endless stream of black dioxic squid ink onto Penny than I get from this - hell, that wouldn't even be half of it. This is trypophobia-level shit here.) In regards to that edit you made to your vote, obviously non-icons are completely unrelated to this. I worded this as specifically as I could to avoid it being abused. This is for icons and icons alone, and by "game-related," I mean such as "MKDD-related" or "MPT-related" to determine which group gets which parameters. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 02:21, October 31, 2024 (EDT)
::::I think there was some misunderstanding amongst parties after the previous proposal was cancelled. I at least do not think anyone intentionally meant any harm. The impression I have is that a lack of familiarity with certain tools lead to some bad-faith interpretations of why folks did the things that they did. But regardless, I think a gentler, less heavy-handed approach to these types of things would be better going forward. I do not think this needs to be strict policy, or something staff and other users need to enforce. But generally, as a courtesy, if one wants to adjust assets that are being used in particular fashions outside of galleries, it does not hurt to reach out and ask if it would be okay to adjust their dimensions. And if a user cropped material, one should not invoke rules that do not exist as actual policy, or bring up some "innate" sprite-ripping principals that do not exist. (I understand the point of this specific proposal is to make certain rules concrete, but I am referring to some of the interactions I saw between users before this current proposal was raised.) Rather, there is no harm in explaining why it is helpful to keep certain assets at particular dimensions for tables and templates. I know some folks have mentions CSS coding, but no one has bothered explaining what that would look like, and generally, adjusting the empty space around an asset is the most user-friendly and intuitive path to take. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 01:28, October 31, 2024 (EDT)
@SeanWheeler: I believe the proposal is just for the icons within a particular "set" to be consistent with each other, not icons of different sets. {{User:Hewer/sig}} 08:46, October 31, 2024 (EDT)
{{@|Killer Moth}} - See the ''Diddy Kong Pilot'' table above and the alignment issues it had before I enacted this principle on it, and how it's much more eye-pleasing afterward? ''That'' is the point. Without it, they tend to look gross - like that table did before. If you can't see why that's an issue, then I envy you, but it really looks bad - the version with the alignment lines is how ''my'' eyes see it even when they aren't there. And I have still yet to see any actual downside to this other than people trying to cram them into signatures, which is... not what the wiki is about and that absolutely should ''not'' take priority in presentation. Same reason we don't add fake armbands to Bowser's SMB1 sprite since that's transparency. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 12:50, October 31, 2024 (EDT)
:Again, the dominant perspective of the opposition is '''not''' "no, this is a bad idea. No one is allowed to set up assets to make them aligned as they appear in the ''Diddy Kong Pilot'' table." Personally, I think the ''Diddy Kong Pilot'' example you provided is aesthetically pleasing when the sprites are all aligned, and folks should have the freedom to do that. It is for similar reasons that I integrated organized 100x100px sizing for all images in the mainline game tables and try to ensure columns are the same width across all tables in an article. Rather, the oppositional perspective is, "no, we do not want to police this or make this a type of rule. People should have the freedom to experiment with what types of dimensions they want for the assets used in their tables, and we do not agree that cropping to visual content is inherently destructive of an asset." - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 13:11, October 31, 2024 (EDT)
::I feel doing this is an absolute good, and if someone has the freedom to crop, I have the freedom to restore. Two-way street and all that. Also, LGM's argument from what I can tell is exactly that (which coupled by the general belligerent/caustic directing of profanity towards it) fueled most of this. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 13:57, October 31, 2024 (EDT)
:::I respect that you view a policy revision like the one advocated for in this proposal is an "absolute good," but I do not think you have made a compelling persuasive argument as to why, or at least not one to me. And I understand your concerns over a "two way streak," but we do have [[MarioWiki:Courtesy|courtesy policies]] on this wiki. Many of them seem relevant, but the one I would like to highlight is that '''users should not participate in other users' editing projects without asking them first'''. Galleries are more of a shared neutral space, but if one wants to crop to content or retain space around ones that are integrated into tables in a spatially-dependent way, it would be courteous for one to reach out to the uploader of those assets first or at least touch base with them. The ''Mario Power Tennis'' ones, for example, have only been integrated in [[Mario Power Tennis#Participants|one table]] at the time of this comment and cropping them does not seem to have impacted the layout or scaling in any perceivable way to me. There was no demonstrable harm.
:::I do not think LGM is advocating that arranging tables like the one in the ''Diddy Kong Pilot'' example should not be allowed, or at least that is not my reading of her comments. I believe her perspective is not dissimilar from mine. I would personally appreciate it if you reviewed what I wrote in my vote above. I think it would be clarifying.
:::I could be wrong, but I believe the curtness comes from statements you had included in the previous proposal that, from her experience as someone who also rips assets and someone who participates on this wiki very regularly, she knew were objectively false, but you were presenting them as hard facts and even invoking them to talk down to another user. This is understandably not appreciated conduct, and it is not uncommon from you. She can speak more to that if she wants to. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 16:13, October 31, 2024 (EDT)
::::The statements I made then were accurate too, our perspectives are just completely incompatible. And considering in the cases of those Mii costume images, here, the original uploader (who is supporting this proposal) explicitly wants to keep them they way they were uploaded in, which is what I reverted them to, and LGM is reverting them from. The specific thing she has said that I take issue with is her claim that the space is absolutely worthless and should be removed from everywhere it feasibly can be, which naturally I perceive to be extremely misguided. As for the ''Mario Power Tennis'' table, it only looks as good as it does thanks to my own ingenuity of hiding a cell divider bar to make two cells look like one cell - that table is ''the'' one that has given me trouble in that regard. Presumably if they are changed to a tabular form, those icons will remain useful if we start covering rivals for it like we do for the 64 game, but by then it'd be easier if they did share parameters. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:39, October 31, 2024 (EDT)
:::::Maintaining space needs to be done for a good reason, and having it simply because it was ripped that way ''is not a good reason''. It is okay to find an example where extra space is needed but that table provided is a heavily flawed example due to being an inappropriate use of a table and the suggestion below that does fix the issue to begin with (and probably there is a code for horizontal alignment too). As for Mario Power Tennis table, if you're referring to this one[https://www.mariowiki.com/index.php?title=Mario_Power_Tennis&oldid=4392103#Participants] that's another fundamentally flawed table which was one of the many other tables that prompted criticism by multiple users and would not be my example to try to illustrate a proposal. The ''one'' example I think may work is [[:File:MK8 Mario Icon.png]] due to its use in multiple pages and being in an array with similar scaled images, which were all put in a 128x128 box. Not sure if cropping to content is going to lead to unexpected results but for the record, I don't see the point of cropping to content for these Mario Kart 8 things either, since they're already reasonably occupying the space (unlike those Mario Kart Double Dash map icons which were heavily padded); it's a case of don't fix what isn't broken. The proposal doesn't really advocate any of this. It's, what I can glean, a way to maintain aspect ratio while cropping tightly as possible without losing information, but dressed up in bad examples and imprecise wording (like the proposal does not even define what a "game-related 'icon-type' image" is, so). {{User:Mario/sig}} 20:56, November 2, 2024 (EDT)
::::::I was more referring to how the N64 Mario Tennis had a separate "partners/rivals" table before I incorporated that information into the main character table, and it used the face icons. I was saying if MPT did something similar, which it probably should if there is indeed a hard-coded system like that in the game. I don't really think I need to define the icon thing; but if you insist, I mean "icon" as in "a small image representing a subject," with "game related" simply meaning as a per-game basis (ie, MK64 icons have no bearing on MKDD icons). (Also, off-topic, but how else would the ''Diddy Kong Pilot'' example be handled if not as a table? There's other information below it that's been cropped out.) [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 21:52, November 2, 2024 (EDT)
The ''Diddy Kong'' example, too, can be easily fixed with aforementioned styling, in this case by using <code>vertical-align: bottom</code>. That is to say however that those sprites are of a size where it makes sense for all of them to just retain their original size, I would not crop those either. There are cases like the Mii suits from the other day where it does make sense to crop them. {{User:Lakituthequick/sig}} 17:14, 31 October 2024 (UTC)
:Not all of them have flat bottoms in other games, of course, while that also doesn't fix the left-right issue. But yes, I digress. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 13:57, October 31, 2024 (EDT)
Another thing I want to ask the opposition: if {{file link|058-SMMMontyMole.png|this}} is to not be cropped, why should any of the other things? [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 19:24, November 6, 2024 (EST)
:That should be cropped to content. The large blank space serves a purpose to optimize the graphic in a game, not so much here. {{User:Koopa con Carne/Sig}} 17:06, November 9, 2024 (EST)
All right, if this is going to continue to be "case by case," then expect a ''looooooot'' more discussions on this in the future. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 20:29, November 10, 2024 (EST)
:Trust me, there won't be. {{User:Ray Trace/sig}} 15:53, November 11, 2024 (EST)
::...what is ''that'' supposed to mean? Because it sounds like either a taunt or a threat, and both are highly uncalled for. [[User:Ahemtoday|Ahemtoday]] ([[User talk:Ahemtoday|talk]]) 18:08, November 11, 2024 (EST)
:::I've been on this wiki for 15 years. Image edits like this have never been an issue and it won't be. The fears over potential edit wars regarding this is unfounded. {{User:Ray Trace/sig}} 18:13, November 11, 2024 (EST)
::::[[Warp Pipe]]'s name wasn't an issue until someone brought up recently it was likely being misused. Sometimes things slip through for a very long time. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:44, November 11, 2024 (EST)
:::::Warp Pipe's name is an entirely different beast. This asset thing and how to curate it hasn't been a problem until it suddenly became one. {{User:Ray Trace/sig}} 18:51, November 11, 2024 (EST)
:Doc, it's a bunch of video game assets. Is this topic really worth pushing this far? Is it worth building up so much unrest over? I mean, we're all a nerdy bunch here curating video game content, sometimes discussions get understandably a bit heated (and I'm certainly no saint in this respect), but ''damn'', there's a limit past which certain reactions are disconcerting. Please simmer down, if not for the comfort of other users, then for your own. {{User:Koopa con Carne/Sig}} 18:31, November 11, 2024 (EST)
::I fail to see how "if this is going to continue to be case-by-case rather than having a general guideline in place, then I'm going to discuss every time someone does it a way I personally disagree with so it can be figured out" is overreacting in any way. Because that's obviously what I said. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:44, November 11, 2024 (EST)
:::That was not obvious at all from your message, which could very well be interpreted as "I'm never gonna cease bringing this up". Even with your clarification, I don't understand why'd you use a vaguely threatening tone to convey that message, or why you'd even feel the need to make such an obvious remark in the first place. Yes, as a matter of course, some people are going to question and discuss a given thing whether you brought it up beforehand or not. You seem to be under the impression that this proposal's passing would have acted as a failsafe of sorts, that future users would look back on it and observe it as an unquestionable guideline, and that it could be a handy tool in sealing off new debates on the topic. This was never going to be a guarantee. {{User:Koopa con Carne/Sig}} 19:50, November 11, 2024 (EST)
===Either remove non-English names from cartoon dubs that weren't overseen by Nintendo or affiliated companies, or allow English names from closed captions===
{{proposal outcome|passed|8-1-0|Allow English names from closed captions}}
"What does one have to do with the other?" You'll see!
Back in 2021, there was a [[MarioWiki:Proposals/Archive/56#"Closed caption of the Mario cartoons"|proposal]] to allow closed captions used on ''Mario'' cartoons uploaded or streamed officially online to be used as sources on the wiki. It encountered massive opposition, with one comment left by a user in a previous discussion acting as the cornerstone of the opposition's rationale. The link intended to lead to that comment, seen under that proposal, doesn't do its job any more, so I'm copy-pasting it here for your convenience.
<blockquote><span class="quote" style="font-family:Times New Roman;font-size:11pt;font-style:italic">“re closed caption: The relation between WildBrain and video streaming platforms like Netflix is the same one Nintendo has with retaillers like Gamespot: meaning the owner of the property sells the product to the retailler/streaming website, and they may supply other material (like artwork, press releases, etc) to help the client market the product. However, that doesn't mean everything the client does with the product is now official; for instance, Gamespot has in the past created fake placeholder boxarts for Mario games using edited official artwork. Gamestop may be an authorized (or "official") retailler of Mario products but it doesn't make those placeholder boxarts by association as they were made entirely by Gamespot without inputs from the creators of the source material.
“In that respect, closed captions fall in the same category as placeholder retailler-made boxarts. Closed captions are made by people with no relation to the source material or access to behind-the-scenes material like script, and who are just writing down what they hear by ear. They are not an acceptable source for spellings.”</span>
~ '''{{user|Glowsquid}}, 2021'''
</blockquote>
This is valid. In all this talking about what is official and what is not, I suppose it feels right to draw a concrete line somewhere. Someone who acquires the rights to use Nintendo's or one of their partners' IP to use it for a given purpose is technically an authorized party, but they're no authority themselves over the content within. Makes sense.
...Meaning the multilanguage names invoked in the proposal's title stick out all the more like a sore thumb. A good chunk of them, at least. Why would the wiki treat a studio or company that dubs and distributes syndicated Mario cartoons to a given demographic as particularly authoritative over the content? Ultimately, it's the same situation as the one described in the quote, the apparent clincher being that it's in a different language, and I apologize, but I don't see how it is consistent to prohibit third-party English subtitles but allow foreign dubs by people that are just as far-removed from the parent company. I propose a compromise.
Of course, not all foreign dubs would be off limits as sources should the second option of this proposal win. If one can provide sufficient proof that a given dub was supervised by one or more employees representing a company with authority over the original product, i.e. that the company left their mark on the endeavor, sourcing it is absolutely fine. As it stands, though, I can already point to the Romanian dubs of the Mario DIC cartoons as ineligible for sourcing given my failing to find any evidence DIC Entertainment ever put its signature on them. (This is coming from someone who contributed a significant amount of names from these dubs. Sometimes you gotta kill your darlings.)
"'''So if option 1 wins, 'Ahehehaue' is considered official again?'''"
No. That doesn't come from a closed caption, and I consider WildBrain's issue of circular sourcing to be a whole other can of worms best left out of this week's topic.
(added 17:42, October 30, 2024 (EDT)) "'''Does the proposal extend to the live-action segments of the ''Super Show''?'''"
Yes, they're within the same package.
'''Proposer''': {{User|Koopa con Carne}}<br>
'''Deadline''': November 12, 2024, 23:59 GMT
====Allow the sourcing of English closed captions from officially uploaded and streamed ''Mario'' animated works====
#{{User|Hewer}} Perhaps I just have a more liberal understanding of "official" (as an Ahehehauhe defender), but after proposals like [[MarioWiki:Proposals/Archive/57#Allow/prohibit fan work by former Nintendo staff|this]], [[MarioWiki:Proposals/Archive/67#Allow quotes of characters being voiced by their official actors in unofficial media|this]], and [[Talk:Fangamer#Delete this article|this]], I feel like all these should be close enough to official to be worth documenting. And aren't games like [[Hotel Mario]] a bit of a similar case, where the "official" involvement didn't go much further than licensing them?
#{{User|Ahemtoday}} I think the difference between closed captions and placeholder retailer box art is that the closed captions are a(n optional) part of the media as it can be officially experienced. As such, I think it counts as "official" regardless of who did it.
#{{User|SeanWheeler}} Well, we would need some kind of source for names of characters that never appeared in English localizations.
#{{User|Pseudo}} These names would be familiar to some viewers of the material, if nothing else, and it seems a bit odd to consider them completely unofficial even if they weren't overseen by the original creators.
#{{User|EvieMaybe}} a license is a license
#{{User|UltraMario}} Per all. I still believe that these should still count as official enough, as they are the providers of the content and it's like a license of a license.
#{{User|Camwoodstock}} In the absence of any alternative names from Nintendo or the original team at DiC (since goodness knows that that isn't coming anytime soon), we feel like these are fair ''enough''. While not exactly a primary source by any means, if we permit names from various strategy guides, we feel like names from closed captions officially provided by the distributors should be fair game.
#{{User|Cadrega86}} These are no different than names from ''licensed'' strategy guides or other content written or localized by third parties.
====Remove names that originate from non-English dubs of ''Mario'' animated works that were not overseen by Nintendo or an affiliated company====
#{{User|Nintendo101}} Per proposal. I found the argument persuasive.
====Do nothing====
====Comments (closed captions vs. foreign dubs proposal)====
Waltuh... I'm not voting right now, Waltuh... {{User:Koopa con Carne/Sig}} 14:01, October 30, 2024 (EDT)
{{@|Koopa con Carne}} By "not overseen by Nintendo/DiC", do you mean they gave the go-ahead but didn't have any direct involvement in production, or the dubs were produced by a third party with no permission whatsoever? I'd consider being more charitable for the former, but if it's completely unauthorized then that's basically equivalent to a bootleg or fan translation and probably shouldn't be covered. --{{User:Waluigi Time/sig}} 17:07, October 30, 2024 (EDT)
:First one. The proposal only touches on the scenario where a company that airs a dubbed ''Mario'' cartoon has a license to do so from the work's owner. Anything outside of such a licensing agreement is completely unofficial, like you pointed out. {{User:Koopa con Carne/Sig}} 17:42, October 30, 2024 (EDT), edited 17:44, October 30, 2024 (EDT)
Added stipulation that the proposal extends to live-action ''Super Show'' segments. {{User:Koopa con Carne/Sig}} 17:42, October 30, 2024 (EDT)
:What is "Ahehehauhe?" [[User:SeanWheeler|SeanWheeler]] ([[User talk:SeanWheeler|talk]]) 23:29, October 30, 2024 (EDT)
::It's a [https://youtu.be/OdLFZ5RAPTU clip] of a ''Super Show'' episode uploaded to YouTube by WildBrain, the current owners of most of DIC Entertainment's library (including their Mario shows). On the wiki, "Ahehehauhe" used to redirect to that episode's article because it was deemed an "official" alternate title given WildBrain's ownership status over the material, which many found outrageous since it barely passes as a "title" and is simply a transcription of the characters cackling in that clip. We don't even know if a human consciously named the clip that; it could've been a bot. {{User:Koopa con Carne/Sig}} 06:28, October 31, 2024 (EDT)
::Now, "Ahehehauhe" isn't linked to the WildBrain-related circular sourcing issues I mentioned in the proposal (they used names from the wiki in promotional texts, which Ahaha isn't one of). However, if the same policy used for the English Super Mario Encyclopedia is to be applied to WildBrain on the same grounds, then the only case where a name they used for a given subject should be employed by the wiki is (a) if the name didn't come from the wiki in the first place, and (b) there are no other known names for that subject. Even if we're to consider Ahahahue a unique and proper way to call an episode of a TV show, its use would still be untenable under the second point. {{User:Koopa con Carne/Sig}} 06:39, October 31, 2024 (EDT)
:::If the same ''Encyclopedia'' logic applied, shouldn't it still be a redirect at least? [[User:LinkTheLefty|LinkTheLefty]] ([[User talk:LinkTheLefty|talk]]) 08:24, November 8, 2024 (EST)
::::Ah, I didn't know that was the case with the Encyclopedia. Still, I don't think many would be keen on treating an onomatopoeia as an alternate title for an episode anyhow. {{User:Koopa con Carne/Sig}} 17:11, November 9, 2024 (EST)
:::::Why would "Ahehehauhe" be considered as an ''alternate title for a full episode'' when it's only been used as a name for a ''15-second clip from said episode'', anyhow? It's only a short moment of the episode! I don't think other wikis for TV series consider official names of clips from a short moment of a particular episode to be an alternate title for the full episode either, whether it's some funny-sounding onomatopoeia or a more descriptive caption. I'd be all for using Ahehehauhe as a redirect if it was actually used as the name for the full episode, but it simply ''isn't'': it was only used for a small fragment and nothing more. {{User:Arend/sig}} 19:38, November 10, 2024 (EST)
===Allow unregistered users to comment under talk page proposals===
{{Proposal outcome|passed|14-1|Allow}}
One thing I never understood about rule 2 is why unregistered users are not allowed to comment under proposals. The rule states: "Only registered, autoconfirmed users can create, comment in, or vote on proposals and talk page proposals." While it makes sense on this page, it is semi-protected after all, talk page proposals are a different story. Why should IPs be prevented from commenting under talk page proposals? Most IPs are readers of this wiki and they should be allowed to express their opinion on wiki matters too. I've seen several examples of IPs making good points on talk pages, I imagine most of them are regular visitors who are more interested in reading rather than editing, and allowing them to leave a comment under a TPP would only be beneficial.
If this proposal passes, unregistered and not-autoconfirmed users would be permitted to comment under talk page proposals. They still wouldn't be allowed to vote or create proposals, only comment.
'''Proposer''': {{User|Axii}}<br>
'''Deadline''': November 14, 2024, 23:59 GMT
====Support (unregistered users proposal)====
#{{User|Axii}} Per proposal.
#{{User|Hewer}} Wait, this was a rule?
#{{User|Pseudo}} This rule doesn't really seem like it accomplishes anything.
#{{User|Blinker}} Per proposal.
#{{User|FanOfYoshi}} Why wasn't this already applicable?
#{{User|EvieMaybe}} it makes sense if it's just for comments
#{{User|Drago}} The rule was only [[Special:Diff/1858371|changed]] because of this page's semi-protection and not, as far as I can tell, because of any misuse of comment sections by unregistered users. Per all.
#{{User|ThePowerPlayer}} This is a reasonable change.
#{{User|Dine2017}} Per proposal.
#{{User|Ray Trace}} Anons use the wiki too and should be able to voice their concerns in the comments section, there's no reason to bar them the ability to comment.
#{{User|Mario}} We'll see if the Bunch of Numbers behave.
#{{User|Nintendo101}} Per proposal.
#{{User|Killer Moth}} Per proposal.
#{{User|Mari0fan100}} IP addresses can leave comments on unprotected talk pages. If they can do that, shouldn't they be able to comment in talk page proposals as well, given that they're not protected? Per all.
====Oppose (unregistered users proposal)====
#{{User|SeanWheeler}} Unregistered users just have numbers for their names, so that looks awkward with the way the votes are counted. It's easy to use your IP to sockpuppet, so I wouldn't want anyone doing that for the votes. And even for just the comments, I wouldn't want anyone to sockpuppet in an argument for manipulation tactics. Nor do I want to see poor grammer or vandalism. Anyone who wants to participate in voting discussions should sign up. This page was semiprotected for a reason. [[User:SeanWheeler|SeanWheeler]] ([[User talk:SeanWheeler|talk]]) 00:19, November 1, 2024 (EDT)
====Comments (unregistered users proposal)====
"While it makes sense on this page, it is semi-protected after all"<br>If the protection history displayed above this page's edit box is any indication, it was the other way around. There was already a rule against anonymous voting on this page by the time it was semi-protected. In that case, it might be useful to look into the reasons this rule was made in the first place and, if there's any disagreement, extend this proposal to this page too. As to where these reasons are stated, I don't know. My assumption is that the rule exists because anons are more prone to shit up the place than registered and autoconfirmed users. {{User:Koopa con Carne/Sig}} 16:15, October 31, 2024 (EDT)
:I couldn't find a reason why IPs were disallowed to comment. My only assumption is that when this page was protected the rule was modified to mention that IPs couldn't comment, but talk page proposals weren't considered. I'll look into it more and potentially add a third option to allow IPs to comment here as well. [[User:Axii|Axii]] ([[User talk:Axii|talk]]) 16:20, October 31, 2024 (EDT)
{{@|SeanWheeler}} - This isn't about voting, it's about commenting. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 01:04, November 1, 2024 (EDT)
:For real, do you even read before voting on proposals? It's a small paragraph that makes it very clear that it's only about commenting under talk page proposals, not even on this page. [[User:Axii|Axii]] ([[User talk:Axii|talk]]) 01:07, November 1, 2024 (EDT)
===Decide whether to cover the E3 2014 ''Robot Chicken''-produced sketches===
{{proposal outcome|passed|9-1|cover ''Robot Chicken''}}
For {{wp|E3 2014}}, Nintendo's press conference was a video presentation similar to today's Nintendo Directs, featuring [https://www.youtube.com/watch?v=4FgzkZC0reE clips of stop-motion sketches] by the producers of ''{{wp|Robot Chicken}}''. I feel that these qualify to receive coverage on this wiki, since their appearance in a video published by Nintendo means that they are officially authorized, and they prominently feature ''Mario'' franchise characters. However, I have never seen the sketches discussed in any wiki article, nor are they listed on [[MarioWiki:Coverage]], so I thought it would be appropriate to confirm their validity for coverage with a proposal.
The following articles would be affected by this proposal if it passes (since the E3 2014 video is not a game, film, etc., coverage is best suited to an "Other appearances" section):
*[[History of Mario]]
*[[History of Bowser]]
*[[History of Princess Peach]]
*[[History of Wario]]
*[[Reggie Fils-Aimé]]
*[[Fire Flower]]
*[[Bullet Bill]]
*[[List of implied entertainment]] (In the last sketch, Mario mentions the fictional game ''Mario Ballet'').
Regardless of which option ends up winning, a note should be added to MarioWiki:Coverage to explain how these sketches are classified. Also, I'm clarifying that this proposal does not involve any sketches from ''Robot Chicken'' itself, since those are clearly parodies that have no approval from Nintendo.
'''Proposer''': {{User|ThePowerPlayer}}<br>
'''Deadline''': November 16, 2024, 23:59 GMT
====Support====
#{{User|ThePowerPlayer}} Per proposal.
#{{User|Hewer}} This feels logical enough that I'm not sure it needs a proposal or even an explicit note on the coverage policy, but per proposal just in case.
#{{User|EvieMaybe}} per proposal
#{{User|Tails777}} Some of them were Mario related so I don't see any reason not to mention them. Per proposal.
#{{User|Ray Trace}} Per proposal.
#{{User|Camwoodstock}} At first, we were a bit confused as to why ''only'' E3 2014 was getting this treatment, but it turns out that no, actually, we do mention a few things from E3 presentations and Nintendo Directs in these articles, we just never internalized that information. If we cover [[History of Wario#Other appearances|that Wario animatronic puppet from E3 1996]], and we cover [[History of Bowser#Other appearances|Bowser in Bayonetta 2]], we don't see why we shouldn't cover this specific E3's trailers just because it was by a different producer.
#{{User|Nintendo101}} Don't see why not.
#{{User|Killer Moth}} Per proposal.
#{{User|Jdtendo}} It is no less official than [[Shitamachi Ninjō Gekijō]] or [[Super Mario-kun]]. Per all.
====Oppose====
#{{User|SeanWheeler}} Robot Chicken is an adult parody show. To cover Robot Chicken in Mario's history is like taking the Family Guy cutaway gags as canon. The Robot Chicken sketches including the E3 specials are covered in [[List of references in animated television]].
====Comments====
Uh, SeanWheeler? You may want to see [[MarioWiki:Canonicity]]. There is no canon in Super Mario. And being an "adult" show shouldn't prevent text from being referenced in normal articles given the wiki does not censor anything. (The last point on [[MarioWiki:Courtesy]], and the set of arguing over [[Bob Hoskins]]'s page quote.) I guess one could discount the sketches on account of them as parodies, but given the "no canon" bit that seems hard to justify. [[User:Salmancer|Salmancer]] ([[User talk:Salmancer|talk]]) 21:01, November 3, 2024 (EST)
:It's been a hot minute, but aren't the 2014 E3 sketches not even a part of Robot Chicken, anyways? Just produced by the same team behind them. It would be like prohibiting mention of [[Ubisoft]] because they developed those South Park games. And even if the sketches for E3 2014 were particularly "adult", [[List of unofficial media acknowledged by Nintendo#Super Hornio Brothers|overwhelmingly adult content hasn't stopped us before]]. {{User:Camwoodstock/sig}} 09:43, November 4, 2024 (EST)
::We might not have any canon, but Robot Chicken sketches are like the Family Guy cutaways. We don't cover Family Guy despite having a few Mario cameos. They only get listed in [[List of references in animated television]]. And no, it's nothing like prohibiting Ubisoft for their South Park games. We have [[Ubisoft]] for their involvement in the [[Mario + Rabbids (series)|Mario + Rabbids]] crossover series. We don't cover South Park. Prohibiting the mention of Ubisoft for just one unrelated series would be ridiculous. [[User:SeanWheeler|SeanWheeler]] ([[User talk:SeanWheeler|talk]]) 15:25, November 9, 2024 (EST)
:::So what if these are "like the Family Guy cutaways"? We don't cover Family Guy because we're not a Family Guy wiki. As far as I know, no Mario cameos in Family Guy were officially authorised by Nintendo, so it couldn't get its own article anyway. Meanwhile, these sketches were officially posted by Nintendo and featured Mario characters prominently. As for the part of your comment about Ubisoft and South Park, you've just described the point Camwoodstock was making by bringing that up. {{User:Hewer/sig}} 16:59, November 9, 2024 (EST)
{{@|ThePowerPlayer}} Looking at these sketches, why not create an article covering them? It would be inconsistent not to cover them separately as well, not just as sections of other articles. [[User:Axii|Axii]] ([[User talk:Axii|talk]]) 13:26, November 4, 2024 (EST)
:The proposal is to cover them in "Other appearances" sections, which are [[MarioWiki:Proposals/Archive/57#Define the scope of "Other appearances" sections|supposed to cover things without articles]]. Also, to my knowledge, they don't exactly have an official title that we could use. {{User:Hewer/sig}} 13:32, November 4, 2024 (EST)
::This is exactly why I brought it up. It would be weird not to have a page on them when all other content does. Lack of an official title never stopped us either :) <br>[[User:Axii|Axii]] ([[User talk:Axii|talk]]) 03:42, November 5, 2024 (EST)
:::My point is that not "all other content" has a page, and that's what "Other appearances" sections are for. I don't think these short, nameless skits from an E3 presentation that are more about Nintendo in general than specifically Mario are really in need of an article when this proposal passing would mean their entire relevance to Mario would already be covered on the wiki. They aren't even the only skits with Mario characters from an E3 presentation, E3 2019 has an appearance from Bowser. {{User:Hewer/sig}} 06:34, November 5, 2024 (EST)
::::Exactly. Making an article would just lead to a lot of unnecessary descriptions of content that has nothing to do with the ''Super Mario'' franchise. {{User:ThePowerPlayer/sig}} 19:44, November 5, 2024 (EST)
===Require citations for dates===
{{proposal outcome|passed|7-0|Require citations}}
Recently, a proposal decided that not sourcing a foreign name puts the article into a meta category of "unsourced foreign names". But I'd say a similar idea should be implemented to dates for things such as media releases, company foundations, and game, company and system defunction. Because, for example, there's been many times where I've seen an exact release date pinpointed and I think "where did they get that date from?", and after a bit of research, I can't find any reliable source with said exact release date. Dates being sorted like this would be nice.
'''Proposer''': {{User|Starluxe}}<br>'''Deadline''': November 16, 2024, 23:59 GMT
====Support====
#{{User|Starluxe}} Per my proposal
#{{User|ThePowerPlayer}} Per proposal.
#{{User|Super Mario RPG}} I agree.
#{{User|Camwoodstock}} Wait, how is this ''not'' already policy??? Per proposal.
#{{User|Shy Guy on Wheels}} I personally find that a lot of release dates for games on the internet come from hearsay, and copying what other sites say without actually double checking that info, so this would be great for guaranteeing accuracy.
#{{User|Technetium}} Per proposal.
#{{User|Mario}} The next time Peach asks Mario out, I am sooo citing this proposal.
====Oppose====
====Comments====
What source you think is acceptable for release dates? I personally use GameFAQs. {{User:Ray Trace/sig}} 20:05, November 2, 2024 (EDT)
:GameFAQs isn't officially related to Nintendo, right? If so, then no. It needs to be an official source. Because if anything, GameFAQs' release dates could be taken from another unofficial source, making that an unacceptable source. {{User:Starluxe/sig}} 13:00, November 6, 2024 (EDT)
::But that is a major problem of mine regarding old games, especially those that came out before the internet. Game sites such as GameFAQs and Wikipedia have it down all the time, especially those as old as GFAQs, but I don't think Nintendo themselves keep track of it too much barring recent titles or titles they are currently selling, with rare cases of them citing release dates in games themselves (like Super Smash Bros. Brawl's chronicles). For example, Wikipedia does cite Mario Kart: Double Dash's release date in a financial statement by Nintendo but other games such as the original Thousand Year Door's release dates remain unsourced. I'll need an answer to what sources you plan on using to cite the release data. {{User:Ray Trace/sig}} 18:28, November 7, 2024 (EST)
:::This has come up [[Talk:Donkey Kong (game)#Arcade release dates|a]] [[Talk:VS. Super Mario Bros.|few]] [[Talk:Donkey Kong Country 2: Diddy's Kong Quest#NA release date|times]], but the state of proper video game release date archival is dreadful. I would argue it was around the time of digital storefronts that they were catalogued more seriously. I really want to support this proposal, but first, I think it's really important to decide what type of sources are usable. Sites like GameFAQs and MobyGames? They're actually user-contributed, in theory, I guess. You can contribute there. The problem is that I don't know anything about their curation. Unlike a wiki, you can't look back. Someone can contribute something else that overrides your contribution, and you won't know why (probably something to the effect of "another online source"). So, I wouldn't take sites like them, despite search results doing a good job of making sure they're one of the first things you see. Wikipedia has taken to citing the copyright office, but as far as I know, details like that are not always the same thing as an actual release/airing date. My suggestion is that this needs a whole source priority of its own, preferably contemporary sources like magazines and press releases. [[User:LinkTheLefty|LinkTheLefty]] ([[User talk:LinkTheLefty|talk]]) 08:24, November 8, 2024 (EST)
Seeing how this could also apply to other things like defunction dates, I've added so to my explanation. {{User:Starluxe/sig}} 12:16, November 7, 2024 (EDT)
What about dates tied to in game events, especially of the mobile game variety? Super Mario Run's notification menu doesn't appear to have a web browser equivalent and there isn't a dedicated Super Mario Run social media account to my knowledge. For the major events (ie, the ones that promote other video games) a date could be tracked down. But all those Weekend Spotlights and other rotating events don't sound feasible to attempt to cite. I suppose they're at least isolated to one or so pages. [[User:Salmancer|Salmancer]] ([[User talk:Salmancer|talk]]) 18:07, November 14, 2024 (EST)

Latest revision as of 20:30, November 16, 2024

All past proposals are archived here. This page is protected to preserve the discussions as they were.
Previous proposals

Overturn the proposal that resulted in the deletion of Category:User eo (category for speakers of Esperanto)

Overturn 20-0
Myself, I don't care about this language, and needless to say, neither do most people on the planet, but I take issue with the proposal that had it removed in the first place for a few reasons.

  • The proposal argues that this language "is not a real language", that "nobody really picked it up", and likens it to the fictional language of Klingon. Despite its status as a constructed language, it is, in fact, very much a real language intended and created to be functional. It has a(n admittedly small) number of speakers across the planet, some of whom may well be potential editors on this wiki for all we know. The comparison to Klingon, which was created with an artistic purpose, is misleading.
  • The proposer was outed as an extremist (read up on the details at your own risk) who seemingly was planning to have other language-based user categories removed, as he followed up with another proposal targeting the Georgian user category. The wiki's policies outline that we shouldn't assume bad faith in users, but given the circumstances here, I hope you'll allow me the assumption that this user had ulterior motives in their little curatorial project, namely in altering the wiki ever so slightly according to their outlooks. Proposal failed and the user was banned for their concerning behavior, preventing further such proposals from being made.

Now, as you'd expect, the Esperanto user category certainly never saw much use--in fact, only one user employed it as of 2014 (archive.org) and even then only listed Esperanto as a second language (archive.org) (though, the very point of Esperanto was to be an auxillary language between people who don't speak the same native language). That user, who goes by Pakkun (talk), has since taken the category off their page, so you could argue that this proposal lacks a tangible purpose as "User eo" would be dead on arrival should it be recreated.

The point of this proposal, however, isn't to recreate this language immediately; it is to negate the proposal that currently prevents its creation if someone ever considers they'd derive some use from it. This community should be open to anyone regardless of their cultural background. The previous proposal is contrary to that.

Proposer: Koopa con Carne (talk)
Deadline: October 5, 2024, 23:59 GMT

Support

  1. Koopa con Carne (talk) per proposal.
  2. Ahemtoday (talk) Per proposal.
  3. Camwoodstock (talk) Honestly, we would be down for more Conlangs to have user categories. We can't imagine the overlap of, say, Vötgil speakers to Mario Wiki users is very large, but like, in regards to a strictly English wiki, the Conlang categories in particular are just for-fun categories at the end of the day, and who the hey are we to expressly prohibit other people's fun? And even in the most generous reading of the events, it still feels like a bit of warped priorities when some categories have been in need of reforms for awhile now (sorry about the Thieves category thing, we're still thinking of that and honestly at this point we wouldn't mind someone else chipping in with that) and haven't gotten them, but we have an entire proposal dedicated to... Deleting a category for Esperanto speakers??? (And for the record, this was back when Category:Canines was called Dogs--something something, obligatory mention of Penkoon.)
  4. Shadow2 (talk) We DID this? wtf??
  5. Nintendo101 (talk) Per proposal.
  6. DryBonesBandit (talk) Per proposal.
  7. Hewer (talk) Per proposal.
  8. Arend (talk) With the provided context, something about Trig Jegman's proposals rubs me the wrong way. If it's true that he was trying to gradually remove other languages, where would he stop? He stated that Esperanto and Gregorian are languages not supported by Nintendo (a weak argument IMO, as Nintendo =/= this wiki), and not widely spoken, so would he first try to get all small-spoken languages removed? Would he eventually try to get larger languages removed just because Nintendo doesn't support these languages? Would he eventually go even further and get even languages that are supported by Nintendo removed because they're not as widely spoken as other languages? Would he eventually make it so that English is the only language remaining? Would he then remove that category too because if that's the only language category for users, then what's the point of keeping it? Or worse, is this a ploy to recognize who is native to other languages and would he try to get non-English users banned so only English-speaking users have access to the wiki (and then remove the English category)? ...Uh...fearmongering aside, per all.
  9. Waluigi Time (talk) No harm having it if people want to use it.
  10. TheFlameChomp (talk) Per all.
  11. ThePowerPlayer (talk) Per all.
  12. Axii (talk) Per all.
  13. Mario (talk) The more the Marior. That older proposal was dumb.
  14. Jazama (talk) Per all
  15. SeanWheeler (talk) I'm not a fan of banning users for off-site drama, especially when it's political. But if his proposal was bigoted, then maybe it should be overturned.
  16. FanOfYoshi (talk) Per all, especially Sean. This proposal was asinine at best, in retrospect, and harmful at worst. And that's coming from a man who doesn't have full context as to what happened.
  17. Shy Guy on Wheels (talk) Per all. That category never hurt nobody.
  18. Killer Moth (talk) Per all.
  19. Pseudo (talk) Per all. This is a really gross thing to delete.
  20. FanOfRosalina2007 (talk) Per all. That was just mean to delete a language category. People still speak this language, so we should represent it!

Oppose

Comments

The real question is if we can have a Klingon category (as a certain other editor who is no longer with us due to concerning behavior mentioned on that proposal). Doc von Schmeltwick (talk) 17:11, September 28, 2024 (EDT)

Up for debate whether user categories can have some basis in fiction. -- KOOPA CON CARNE 17:16, September 28, 2024 (EDT)
We think that Conlangs in general should just be allowed, just because it both feels really, really weird to try to police what Conlangs "count" as languages, and because the idea of focusing even more proposals on such a for-fun topic feels.... A little too much, when that effort is best used elsewhere. ;P ~Camwoodstock (talk) 18:14, September 28, 2024 (EDT)

We should be open for Inklingese and Smurf. ArendLogoTransparent.pngrend (talk) (edits) 20:24, September 28, 2024 (EDT)

Per Arend. --Green Yoshi FanOfYoshi 05:50, September 30, 2024 (EDT)

@FanOfRosalina2007's vote reminded me of a point I wanted to add to the proposal within its first three days, but forgot: there is a category for speakers of Latin, a dead language, so that old proposal's argument that "Esperanto is spoken by too few people to be relevant" is bust as long as the wiki supports Latin. -- KOOPA CON CARNE 17:29, October 4, 2024 (EDT)

Should we add an Occitan category, perhaps? It's a near-dead language that has actual historical significance in certain areas, unlike Esperanto's status as a conlang with "official" linguistic status. Doc von Schmeltwick (talk) 15:56, October 5, 2024 (EDT)

Lower the requirement for a disambiguation page from 5 to 4

Lower requirement to 4 7-0
As of now, the requirement for a disambiguation page's creation is five pages:

"If there are five or more pages which could be reasonably associated with a given name, then a disambiguation page must be created" (MarioWiki:Naming)

This rule feels needlessly restrictive, considering the amount of clutter links make at the very top of the page. "For a minigame in the WarioWare series, see X. For an object in Super Mario Odyssey found in the Luncheon Kingdom, see Y. For an underwater enemy from...", you get the idea. If this proposal passes, the threshold on MarioWiki:Naming will be lowered from 5 to 4.

Proposer: Axii (talk)
Deadline: October 6, 2024, 23:59 GMT

Support

  1. Axii (talk) ^
  2. ThePowerPlayer (talk) One or two other articles are fine, but having three separate articles in the {{about}} template at the top of the page is the point where a disambiguation page is ideal.
  3. SeanWheeler (talk) We don't need to clutter the {{About}} template.
  4. Killer Moth (talk) Per proposal.
  5. Pseudo (talk) Frankly, I'd support bringing the requirement as low as 3. Per proposal.
  6. Mariuigi Khed (talk) I too I'd go with 3. Per proposal
  7. Dine2017 (talk) Per proposal.

Oppose

Comments

Do you have any examples of how many subjects would be affected by this change? — Lady Sophie Wiggler Sophie.png (T|C) 10:52, September 29, 2024 (EDT)

I don't think there's an easy way to tell, but I can't imagine it being too many. Axii (talk) 12:05, September 29, 2024 (EDT)

Character gallery division by each generations

canceled by proposer
The character gallery proposal was passed a month ago, but I failed to add new suggestion to proposal before passed. Sometimes the Japanese and oversea release dates are different when classified by decade. If the Japanese release date is 2009 and the North American release date is 2010, the division will be different. However, if it divided by generations, this problem disappears.

Mario's gallery page is still long sized despite divided by each decade. Some characters' gallery are short and can be merged with the previous ones without any problems. Since Donkey Kong didn't have his own series in 2020s and only appeared in Mario spinoffs, so it's fine to merge it with the 2010s. If there is no proper appearance for a long time, it can last more than 15 years.

I offer the following options:

Option 1
Divide by 6-8 years for Mario by each mainline, and every almost a decade from the year of most important work for other characters. If the proposal fails, split only to Princess Daisy.
Option 2
Divide for Mario by one console generation, and two console generations for other characters.
  • Mario
    • Mario (1981-1994) (2nd/3rd; Until NES)
    • Mario (1989-1998) (4th; SNES/GB)
    • Mario (1996-2001) (5th; N64/GBC)
    • Mario (2001-2005) (6th; NGC/GBA)
    • Mario (2004-2012) (7th; Wii/DS)
    • Mario (2011-2018) (8th; Wii U/3DS)
    • Mario (2017-present) (8.5th; Switch)
  • Luigi
    • Luigi (1983-1998) (3rd/4th; NES/SNES)
    • Luigi (1996-2005) (5th/6th; N64/NGC)
    • Luigi (2004-2018) (7th/8th; Wii/Wii U)
    • Luigi (2017-present) (8.5th; Switch)
  • Princess Peach
    • Princess Peach (1985-1998) (3rd/4th; NES/SNES)
    • Princess Peach (1996-2005) (5th/6th; N64/NGC)
    • Princess Peach (2004-2018) (7th/8th; Wii/Wii U)
    • Princess Peach (2017-present) (8.5th; Switch)
  • Princess Daisy
    • Princess Daisy (1989-2018) (4th to 8th)
    • Princess Daisy (2017-present) (8.5th)
  • Yoshi
    • Yoshi (1990-2001) (3rd/4th/5th)
    • Yoshi (2001-2012) (6th/7th)
    • Yoshi (2011-present) (8th/8.5th)
  • Toad
    • Toad (1988-2001) (3rd/4th/5th)
    • Toad (2001-2012) (6th/7th)
    • Toad (2011-present) (8th/8.5th)
  • Wario
    • Wario (1992-2001) (4th/5th)
    • Wario (2001-2012) (6th/7th)
    • Wario (2011-present) (8th/8.5th)
  • Donkey Kong
    • Donkey Kong (1981-1996) (2nd/3rd/4th; Until SNES)
    • Donkey Kong (1996-2012) (5th/6th/7th; N64/NGC/Wii)
    • Donkey Kong (2011-present) (8th/8.5th; Wii U/Switch)
  • Bowser
    • Bowser (1985-1998) (3rd/4th; NES/SNES)
    • Bowser (1996-2005) (5th/6th; N64/NGC)
    • Bowser (2004-2018) (7th/8th; Wii/Wii U)
    • Bowser (2017-present) (8.5th; Switch)

Proposer: Windy (talk)
Deadline: October 15, 2024, 23:59 GMT

Option 1 (Split by each mainline)

Option 2 (Split by console generation)

Oppose

  1. Hewer (talk) The obvious subjectivity of "important works" makes these divisions feel unhelpfully arbitrary. Also, you can't say "if the proposal fails, split only to Princess Daisy" (assuming I'm understanding that correctly), proposals need an option that results in no changes being made.
  2. Nintendo101 (talk) A good organizational scheme is intuitive, and both options seem to require completely different rules for each character. This is what I said about console generations in the proposal that had passed, "Not all of the material in these galleries come from video games, and it is inherently more intuitive for viewers not very versed in gaming culture to use the same dates they use in their everyday lives. There are also some disagreements on which consoles belong to which generations. So while there are certainly other ways this material can be subdivided, the Gregorian calendar is the simplest."
  3. Killer Moth (talk) Per all.
  4. OmegaRuby (talk) While I get what you're going for as someone who is very passionate about the design evolution of Super Mario series characters over the years and console generations, the design of this just feels too convoluted and confusing to maintain especially as we move forward and go into new console generations and design changes. Per all.
  5. YoYo (talk) per all.
  6. Camwoodstock (talk) Per all, especially Hewer; this is way too subject to, well, subjective opinion as to who's important enough, as evidenced by the fact the "oppose" option was originally "no matter what, we're doing this to Princess Daisy anyways".
  7. Nightwicked Bowser (talk) Per all, also you were warned before for enacting a proposal that failed.
  8. Ahemtoday (talk) Per all.

Comments

What about, instead, dividing it per series? Like, one for the mainline games, the Advances, the Parties, the Karts, just to be more coherent, 'cause... take a look at Mario: first a 9-years span, then 5-year span, again a 5-year span, then an 8-year span... doesn't really look that organized/coherent: if we instead divide it by series, it would be more coherently grouped. --My avatar's face to use in the signature Mariuigi Khed 05:03, October 8, 2024 (EDT)

The "important works" is renamed as "each generations". We should divide it into approximately 7-year units based on the year the Mario mainline was released. Without a proper standard, there were many cases where it ended in failure. Windy (talk) 05:44, October 8, 2024 (EDT)

If this proposal fails, I would like to merge some characters so that they allow to have more than 15 years since their debut (example: Gallery:Bowser (1985-1999)), as less than 10 years from their debut is too insufficient. (less than 10,000 bytes) Windy (talk) 10:38, October 8, 2024 (EDT)

@Windy you cannot execute changes from a failed proposal, per rule 18 above, which states:

Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

- Nintendo101 (talk) 13:38, October 8, 2024 (EDT)

I do think the "by decade" approach has an issue in that it assumes the person looking for an image knows which decade something released, which can be especially hard to remember even for experts in years that are near the turn of the decade. Doc von Schmeltwick (talk) 12:06, October 8, 2024 (EDT)

There's this tho -- KOOPA CON CARNE 13:41, October 8, 2024 (EDT)
I agree with you, Doc. But why doesn't anyone agree to change the classification? Windy (talk) 14:25, October 8, 2024 (EDT)
I'd suggest looking at their reasoning in opposition. It may not be a perfect system now, but they clearly feel your proposed alternative isn't better. Doc von Schmeltwick (talk) 14:32, October 8, 2024 (EDT)
I understand you. Gallery:Mario is still a long sized even when it divided by 10 years. The others are small enough that the first few years can be merged into the next decade. As time goes by, it may become difficult to find the game without knowing the platform or decade. We need to distinguish between 2D and 3D. Windy (talk) 14:48, October 8, 2024 (EDT)
Which can be annoying to have to flip to (and I currently have five tabs open for this site specifically lol) Doc von Schmeltwick (talk) 14:32, October 8, 2024 (EDT)

Shorten the disambiguation identifier for Yoshi's Island pages with the subtitle only - take two

Do not shorten 5-13
Last season, I had to cancel my last proposal since I was caught plagiarizing someone else's proposal. This time, I've come up with another proposal that is not plagiarized.

Take the "Choose a Game" screen and the main game's title screen in Yoshi's Island: Super Mario Advance 3 for example. As you see, the logo for the main game on both screens ONLY reads Yoshi's Island, not Super Mario World 2: Yoshi's Island.

The following pages will be affected:

Current name Will be moved to
Fuzzy (Super Mario World 2: Yoshi's Island) Fuzzy (Yoshi's Island)
King Bowser's Castle (Super Mario World 2: Yoshi's Island) King Bowser's Castle (Yoshi's Island)
Magnifying Glass (Super Mario World 2: Yoshi's Island) Magnifying Glass (Yoshi's Island)
Spiked Fun Guy (Super Mario World 2: Yoshi's Island) Spiked Fun Guy (Yoshi's Island)
World 1 (Super Mario World 2: Yoshi's Island) World 1 (Yoshi's Island)
World 2 (Super Mario World 2: Yoshi's Island) World 2 (Yoshi's Island)
World 3 (Super Mario World 2: Yoshi's Island) World 3 (Yoshi's Island)
World 4 (Super Mario World 2: Yoshi's Island) World 4 (Yoshi's Island)
World 5 (Super Mario World 2: Yoshi's Island) World 5 (Yoshi's Island)
World 6 (Super Mario World 2: Yoshi's Island) World 6 (Yoshi's Island)

Once this proposal passes, we'll be able to use the shorter disambiguation identifier with ONLY the subtitle for the Yoshi's Island pages.

Proposer: GuntherBayBeee (talk)
Deadline: October 10, 2024, 23:59 GMT

Support (Yoshi's Island)

  1. GuntherBayBeee (talk) Per proposal
  2. LinkTheLefty (talk) You know what? I'm actually going to agree with this. One reason is because, according to this, this has to move, and there were concerns raised with the overly long identifier that I agree with. The other reason is because Yoshi's Island is a perfectly valid shorter name for this game. Look at any of the Super Mario Advance 3 materials: the Super Mario World 2 portion was removed. Also, outside of Super Mario Advance 3, Yoshi's Island has been used as the shorter title on occasion. This is in keeping with other proposals about using shorter identifier titles where applicable, and it will not conflict with "(Yoshi's Island series)".
  3. SolemnStormcloud (talk) Per LinkTheLefty.
  4. Doc von Schmeltwick (talk) - Per LTL. I personally prefer to shorten it to Super Mario World 2, but that's clearly not Nintendo's own preference, so that is moot.
  5. Altendo (talk) Per all.

Oppose (Super Mario World 2: Yoshi's Island)

  1. Hewer (talk) Reusing my oppose vote from last time: the remake replaces (and reorders) the subtitle rather than just removing it, so we've never had a game just called Yoshi's Island, and I don't know of any other time we've used a title for a game identifier that isn't actually a title for a game. "Yoshi's Island" also isn't quite as immediately obvious what it refers to compared to "Super Mario RPG", "Donkey Kong Country 2", or "Donkey Kong Country 3". I think this is going a bit too far and ends up a little more confusing than helpful.
  2. Axii (talk) Per Hewer
  3. ThePowerPlayer (talk) Per Hewer.
  4. Shy Guy on Wheels (talk) Per Hewer.
  5. Shadow2 (talk) Long titles are not a problem.
  6. SeanWheeler (talk) It's funny seeing Hewer support a full name this time. And like my points against him about Fox, Sonic and Shadow, Yoshi's Island is pretty vague. But unlike those crossover characters where I'm worried about hypothetical confusion of newer readers, or new species articles in the case of Fox, I might actually think the identifier is referring to the island, not the game.
  7. Sdman213 (talk) Per all.
  8. TheFlameChomp (talk) Per all.
  9. Nintendo101 (talk) Clarifying.
  10. OmegaRuby (talk) Regardless of what Nintendo goes with, I'd rather it be shortened to Super Mario World 2 or nothing at all. Yoshi's Island feels too broad as it's a series of games. Feels like changing the game identifier for every Donkey Kong Country-specific article to just (Donkey Kong Country). Which one is it talking about? Won't know until you open the article.
  11. FanOfYoshi (talk) As a guy who became very active during the period in which i played SMW2YI a lot, so much so that i ended up registering under my current username, i'd say only using "Yoshi's Island" would be counterproductive, because it would imply some enemies have made reappearances outside of the original game (when it isn't necessarily the case for some). Per all.
  12. Camwoodstock (talk) Per all; plus, and this is a more personal thing, but we think these truncated names are particularly confusing in regards to the World names in particular, since "Yoshi's Island" is sometimes colloquially used to refer to the Yoshi platformer games (in contrast to, say, games like Yoshi Touch & Go or those puzzle games).
  13. Sparks (talk) Per all.

Comments

@Hewer I respectfully disagree. "Yoshi's Island" is actually short for both "Super Mario World 2: Yoshi's Island" and "Yoshi's Island: Super Mario Advance 3", so I think there's a possibility to use the "Yoshi's Island" disambiguation identifier for Yoshi's Island pages, even if it is confusing. GuntherBayBeee.jpgGuntherBayBeeeGravity Rush Kat.png 08:39, October 4, 2024 (EDT)

Why do it if it could be confusing? MarioWiki:Naming advises: "When naming an article, do not use game abbreviations. (e.g. use Bully (Mario & Luigi: Partners in Time) as opposed to Bully (M&L:PIT))." Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 09:59, October 4, 2024 (EDT)

What makes this different from the prior proposals is that, officially speaking, there is no game titled "Yoshi's Island" in full; we commonly refer Super Mario World 2: Yoshi's Island as such, but unlike with SMRPG or the DKC games, this isn't the full title of the game or any of its rereleases. It'd be kinda like calling Mario & Luigi: Superstar Saga JUST "Mario & Luigi", you know? ArendLogoTransparent.pngrend (talk) (edits) 03:44, October 7, 2024 (EDT)

SNES Classic lists it as "Yoshi's Island." Which got me confused when I was looking for it in the game list since that changes where it goes alphabetically... Doc von Schmeltwick (talk) 12:33, October 7, 2024 (EDT)

@SeanWheeler: If you think me supporting full names is funny, you'll love this proposal. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 08:11, October 7, 2024 (EDT)

@Axii @ThePowerPlayer @Shy Guy on Wheels @Shadow2 @SeanWheeler @Sdman213 @TheFlameChomp @Nintendo101 @OmegaRuby @FanOfYoshi I respectfully disagree. The term "Super Mario World 2" disambiguation identifier is obviously confusing, so I think you should take a look at my comment from above. Anyway, @Hewer, I think I know why there's a possibility to use the "Yoshi's Island" disambiguation identifier for Yoshi's Island pages, even if it is confusing. Because it will match similarly to the Super Mario RPG, Donkey Kong Country 2, and Donkey Kong Country 3 disambiguation identifiers. GuntherBayBeee.jpgGuntherBayBeeeGravity Rush Kat.png 10:33, October 8, 2024 (EDT)

Confusing? No? And even if it was, it doesn't stop it from being an official name, anyway! --Green Yoshi FanOfYoshi 10:38, October 8, 2024 (EDT)
I don't know of any time just "Super Mario World 2" on its own was officially used to refer to the game. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 11:01, October 8, 2024 (EDT)
I already explained how this case is different from those other three in my vote. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 11:01, October 8, 2024 (EDT)
To be clear, I would not support a proposal that truncated the game's name to Super Mario World 2. - Nintendo101 (talk) 18:20, October 8, 2024 (EDT)
We're more of a fan of Super Mario Advance 3: Super Mario Bros. 4 2: Super Mario Bros. 5, ourselves. ~Camwoodstock (talk) 18:50, October 8, 2024 (EDT)

Separate character content for transformations in the Gallery

Do not separate 1-5
The characters are all mixed up in the transformation gallery; Gallery:Fire Mario. Besides Mario, there are times when have to dig deep to find transformations for specific characters. Also, the transformations for characters other than Mario haven't been written enough. As the number of transforming characters other than Mario is increasing, I think the gallery content is necessary to separate them. A specific transformation for any characters on one page, with add content name. 

==Artwork==
===Video games===
(Listing multiple characters)
====Fire Mario====
(Listing focused character)
====Fire Luigi====
====Fire Toads====
==Sprites and models==
====Fire Mario====
====Fire Luigi====
====Fire Toads====
====Fire Toadette====
...
====Fire Mini====
==Screenshots==
====Fire Mario====
====Fire Luigi====
====Fire Toads====
==Merchandise==
====Fire Mario====
====Fire Luigi====
====Fire Toads====

Proposer: Windy (talk)
Deadline: October 15, 2024, 23:59 GMT

Accept

  1. OmegaRuby (talk) The gallery by decade proposal was made for ease of navigation, so this should reasonably pass too.

Decline

  1. Waluigi Time (talk) I can see some merit to doing this on a case-by-case basis, but we don't need it for every one of these pages. For example, Gallery:Propeller Mario is small enough already that there's no need to divide it into smaller sections, and Gallery:Gold Mario would have a lot of sections that are either short or only a single image because most of it is Mario already.
  2. ThePowerPlayer (talk) Per Waluigi Time.
  3. Hewer (talk) Per all, this isn't necessary to make into policy.
  4. Technetium (talk) Per Waluigi Time.
  5. Nintendo101 (talk) Per Waluigi Time.

Comments

This seems like a fine idea for the Fire power-up specifically, but I'm not sure for the other ones if there's enough images to justify splitting it like that. Doc von Schmeltwick (talk) 17:55, October 8, 2024 (EDT)

Maybe, just for convenience’s sake, I would keep the Toad under one section together, considering also how Toad returned to be blue in SM3DW and SMM --My avatar's face to use in the signature Mariuigi Khed 08:49, October 9, 2024 (EDT)

We should keep colored Toads under one section, listing as "Toads". Also Yellow Toad in the penguin form is named as "Penguin Toad" in Mario Kart Tour. Windy (talk) 02:48, October 10, 2024 (EDT)

Revise how long proposals take: "IT'S ABOUT (how much) TIME (they take)"

Two weeks 14-0-3-8
Currently, the way our proposals are set up, there are two deadlines. On the main proposals page, they last for 1 week. On talk pages, or for writing guidelines proposals, 2 weeks. Now, this is fine. We're not going to claim this is like, some total deal-breaker or nothing. However, lately, there have been a few concerns raised about this inconsistency, and we figured, what the hey, why not put it up to vote?

A few concerns we've seen, both from others and from us, in no particular order;

  • The largest one to us is just that, unless a proposal is really specific, it's just not worth it to make a talk page proposal over a main page proposal, since it'll end faster. The only thing immune to this are writing guidelines proposals.
  • While the proposals themselves are different lengths, the duration before you can make a second proposal on them remains the same. Thusly, if you want to set a policy in stone, you would actually want to make it a writing guidelines/talk page proposal over an ordinary one, as that means it will last for, at least, 6 weeks (4 weeks for the cooldown, and 2 weeks to put it to proposal again.)
  • Lastly, talk page proposals just inherently take longer to happen. This can be an issue if their changes are, overall, quite small (like a simple merge/split or rename), or the consensus is reached very quickly; this stings when an ordinary proposal would happen twice as fast with the exact same amount of votes!

Now, there's a few ways you can go about this, but there's one in particular we've taken a liking to: uh, just make all proposals take 2 weeks, lmao.

"BUT CAM & TORI!", we hear you shout, "BUT YOU SAID 2 WEEKS PROPOSALS TAKE TOO LONG??? WHY WOULD YOU CHANGE THEM TO SOMETHING YOU HATE???", and to that we say... No! We actually like the 2 weeks proposals! They have a distinct benefit to them! The problem is that they're juxtaposed with the 1 week proposals. Let's run through those same bullet points.

  • If all proposals were 2 weeks, well, there's no real loss to making a talk page proposal over a main proposal page proposal, as they'll all last 2 weeks anyways. (Sure, a proposal can take longer if there's a tie, but that just happens for all proposals anyways.)
  • There's also no incentive to make a talk page proposal/writing guideline proposal if you particularly want your porposal to stick around, as again, now every proposal is guaranteed to last for, at the very least, 6 weeks.
  • Now. While it's annoying that all proposals will take 2 weeks, despite the inherent risk of some coming to their consensuses much faster than the deadlines, for one, this is also an issue with talk page proposals as-is. For two, the extra time can offer extra time for new information to come to light or for particularly close votes to make their cases and form a proper consensus, without needing a tiebreaker. Lastly, if it's really that big of an issue, we could perhaps create a rule that if a proposal comes to a particularly large consensus a week in, it'll pass early (the finer details would be created as necessary).

There is, of course, the alternative of making all proposals 1 week. While we realize this does also resolve a lot of things, it does also necessarily mean that some proposals that would want to happen slower, now don't have that time, and are rushed. Even making only talk page proposals take only 1 week means that Writing Guideline proposals will be at a unique disadvantage for how long they take/an advantage for how long they last if they pass. (And of course, we could just leave everything as they are, but that goes without saying.) That being said, we have provided options for these, and you're free to make your case for these.

Proposer: Camwoodstock (talk)
Deadline: October 16, 2024, 23:59 GMT

Make all proposals last for 2 weeks

  1. Camwoodstock (talk) If it's not obvious, this is our primary option; we're a big fan of the idea of global 2 week proposals!. Even with their caveats, in the worst-case scenario, we could make a clause to prevent proposals for lasting too long if they reach their consensus early, or we could simply revert back to the current system. We think the added consistency and preventing of shenanigans is very potent, and it also means that you have to put a bit more thought into your proposal as you make it. Patience fans will be eating good if this passes.
  2. Hewer (talk) Per proposal and what was said here. However, I'd also be fine with an option to just shorten writing guidelines proposals to be one week. I don't really understand the third option here, writing guidelines proposals being two weeks felt to me like the worst inconsistency of the bunch. I still don't see what about "writing guidelines" specifically means they inherently need more time than the other categories on this page.
  3. OmegaRuby (talk) Regular proposals and TPPs are just as visible as one another and should be treated equally, especially when regular page proposals can be the home of very important decisions (such as this one!) and are just given 1 week. Per all.
  4. Waluigi Time (talk) 1 week proposals have always felt a little short to me. I'd rather err on the side of some proposals running a little longer than needed than not having enough discussion time (I don't like banking on a controversial proposal tying). Having to wait an extra week to implement a proposal isn't the end of the world anyway - proposals are rarely, if ever, urgent enough that an extra week with no change would be detrimental to the wiki (and if that were the case, the change should probably come immediately from wiki staff).
  5. Killer Moth (talk) Per all. Giving an extra week to discuss and vote on proposals is a good thing.
  6. Drago (talk) Per Waluigi Time.
  7. Doc von Schmeltwick (talk) - Per, I never got why sitewide ones always got less time to discuss.
  8. Pseudo (talk) Per proposal and the talk page discussion.
  9. Tails777 (talk) Per proposal.
  10. Jdtendo (talk) I feel like the inconsistency is not justified, and one week may be too short to make an informed decision.
  11. FanOfRosalina2007 (talk) Per all. I was one of the people who participated in the conversation that sparked this proposal, and my reasons are stated there.
  12. Shy Guy on Wheels (talk) Per all.
  13. ThePowerPlayer (talk) I think that the reason site-wide proposals still get only 1 week is to necessitate engagement so that a decision can be reached, due to their importance compared to talk page proposals. However, that logic is flawed since it incentivizes discussion which is quick and not well thought out, so I think the consistency of 2 weeks for every proposal would be better here.
  14. TheFlameChomp (talk) Per Waluigi Time. Compared to shortening all proposals, I feel like this is the better option if we are wanting to make all proposals the same length, as I would prefer not to cut discussion time on all proposals just because some of them might not need extra time to reach a consensus.

Make all proposals last for 1 week

Make all proposals except for writing guidelines proposals last for 1 week

  1. Camwoodstock (talk) Secondary option. While we like this much less, we do see the merit of making Talk Page Proposals 1 week, and it's not exactly the end-all-be-all. However, we would vastly prefer 2-week proposals, and keeping Writing Guidelines proposals 2-week is kind of a necessary evil to prevent them from being too rushed for their own good. However, compared to truly all 1-week proposals, this is better... though, not as good as all 2-week proposals.
  2. 7feetunder (talk) For me, it's either this or bust. New information coming to light can still invalidate a proposal's entire premise too late and require a counterproposal even with a 2 week deadline, so extending the deadline of main page props to 2 weeks won't stop that from happening from time to time. Most proposals that don't reach a consensus in a week will probably require extensions anyway. TPPs being less "visible" than main page proposals was more of an issue back when no quorums were immediate, but that's no longer the case.
  3. Axii (talk) Voting for this just so the first option doesn't win.

Do nothing

  1. 7feetunder (talk) If making TPPs last 1 week isn't desirable, I say just keep the status quo. While the current system does encourage making main page proposals over TPPs when possible if one wants their prop to pass faster, I'm fine with that. A controversial prop is not going to end in a week, and a prop with unanimous or near-unanimous support probably doesn't need that extra time in the oven. I'd be more open to global 2 weekers if a "early consensus = early pass" sub-rule was already in effect, but it isn't, and there's no guarantee that such a rule would be accepted by the community.
  2. Axii (talk) The solution isn't solving anything. There was never a problem with inconsistency. Talk page proposals last for two weeks because they're far less visible to people. Mainspace proposals page is frequently visited by many, having proposals last for 2 weeks instead of one doesn't change anything. It doesn't help the community settle on anything, one week is more than enough. Proposals that are tied already get extended automatically, if anything, I would argue writing guidelines proposals should last a week instead. I proposed a different solution on the talk page as well. If a user making a proposal (or an admin) feel like one week wouldn't be enough, they should be able to extend it to two. (I specifically added "or an admin", because most users don't want a proposal to last for two weeks.) Either way, the fact that users often choose mainspace proposals over talk page is perfectly fine as well. It's not about the time in the oven but the visibility of the proposal to the wiki community. Writing guidelines (if they remain at two weeks) could instead be clarified. Right now it is unclear what writing guidelines proposals even are, I think this is the main problem that should be looked at.
  3. Waluigi Time (talk) Secondary choice. The inconsistency isn't that bad and I prefer that to all proposals being shortened.
  4. Killer Moth (talk) Second choice.
  5. Nintendo101 (talk) I think it is worth scrutinizing our proposal policies and the issues people brought up are valid, but I do not think setting the same time for everything is necessarily the best solution. I will elaborate on my thoughts below.
  6. FanOfYoshi (talk) Per all.
  7. Sdman213 (talk) Per all.
  8. TheFlameChomp (talk) This is my second choice, as I would prefer to keep the current method over shortening all proposals. However, if this option were to win, I think it might make sense to discuss clarifying what qualifies as a writing guidelines proposal and the purpose for its length inconsistency.

Comments

Something that occurred to me: The time allowed to edit TPPs was originally 3 like main page proposals, but eventually doubled to 6 to go with their extended duration. If TPPs are shortened to 1 week, would the time allotted to edit them be reverted? Dark BonesSig.png 19:30, October 2, 2024 (EDT)

That seems only fair to put them back to 3 days if that option passes--after all, it would be a glaring oversight to retain that and effectively allow for proposals that were en route to pass suddenly being hijacked on the last day, and pivoting from the original purpose, while still retaining the vote. The plan here is to de-jank the proposal time-lengths and make them more consistent--not to introduce even more shenanigans! ~Camwoodstock (talk) 20:18, October 2, 2024 (EDT)
Then I also suppose that, if all proposals are going to last two weeks, then the time allowed to edit/cancel those proposals would also be doubled to six days, in order to reflect with the TTPs, right? I've been worried since this was not mentioned in the proposal either. ArendLogoTransparent.pngrend (talk) (edits) 07:58, October 6, 2024 (EDT)

@7feetunder: Of course there's still a chance for new information to come too late with any proposal length, but longer proposals mean the chance is lower. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 02:44, October 3, 2024 (EDT)

@7feetunder: On your reasoning under Do nothing, the idea of an early-consensus-early-conclusion rule for proposals is intriguing... I feel as if we have 2-week proposals that can end early if everyone has a near unanimous consensus on what to do with the proposal, we'd have an ideal middle ground. --OmegaRuby (talk) 08:55, October 3, 2024 (EDT)

While finding the discussions where this first took place have not been successful (with the closest approximate being tracked down by retired staff here, which alludes to this issue), there was wisdom in having longer time for talk page proposals, because they would often would get overlooked and fail simply due to lack of engagement, not because there was anything wrong with them. That may not be the case today, but I see a different set issues that this proposal does not address.

Personally, I think certain proposals - regardless of whether they are on the main page or a talk page - are very niche and entail a very granular change that probably does not need two weeks of discussion or even one to be implemented. Proposals that have wide and systematic changes for the site, such as a policy revision or something that would change many pages, do benefit from longer discussion time because the impact would be significant and affect a lot of people. Whether a proposal has narrow or broad impact has nothing to do with whether it is on an article's talk page or this main page.

Additionally, while it may seem like there should be some sort of rule that allows proposals that gain consensus quickly to be implemented, there have been concerns among staff that users have raised similar proposals to ones that had failed in the past with the hope of getting the attention of a different pool of users who may agree with them. (To clarify, there is a difference between raising a new proposal based on one that had previously failed using new information and arguments, versus one using essentially the same argument). If we had some sort of rule that allowed the passing of a proposal due to quick engagement and support, I can see it being abused in such cases and resulting in proposals passing that people at large may not have agreed with.

I don't like complicated rules. I believe the best policies and rules are straight forward, clear, and unambiguous. There is not use in having rules that people cannot easily understand and follow, imo. However, in this case, I think applying a blanket term policy for all proposals (be it two weeks or one) is too broad and does not address the issues I have observed, or even some of the ones raised by other folks on the main proposal page's talk page. - Nintendo101 (talk) 16:18, October 3, 2024 (EDT)

If you ask me, "talk page proposals are two weeks, but the ones on the main page are one week, except writing guidelines which are also two weeks for some reason" is an overly complicated rule. Every now and then, confusion about the "writing guidelines are two weeks" stipulation arises in proposal comments, which I think is telling. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 17:54, October 3, 2024 (EDT)

I think my main issue is the difference with writing guideline proposals specifically. Mostly because it's hard to determine what a writing guideline even means, or which proposal should fall under which category. I'm not sure where I'll place a vote yet, but I do at least think there should be consistency between all main proposal types. Technetium (talk) 16:22, October 3, 2024 (EDT)

If this passes, will it immedately affect all ongoing proposals, or just new ones going forward? LinkTheLefty (talk) 14:31, October 5, 2024 (EDT)

I think we should not modify the deadline of ongoing proposals if this proposal passes. Since the deadline is set when a proposal is created, extending it afterwards for an already existing proposal would feel like a retroactive change. Jdtendo(T|C) 11:30, October 7, 2024 (EDT)

Not voting because I think the current setup is "don't fix what isn't broken", but I'll be willing to try something new. I'll just wait and see. Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 15:52, October 5, 2024 (EDT)

Clarify coverage of the Super Smash Bros. series

Clarify 14-2
I've pitched this before, and it got a lot of approval (particularly in favor of one-at-a-time small proposals), so I'm making it a full proposal:
I have thought long and hard about the "proper" way for us to cover Super Smash Bros. in a way that both respects the desire to focus primarily on Super Mario elements while also respecting the desire to not leave anything uncovered. As such, the main way to do this is to give pages only to Super Mario elements, whilst covering everything else on the pages for the individual Super Smash Bros. games; unless otherwise stated, they will instead link to other wikis, be if the base series' wiki or SmashWiki. For instance, Link will remain an internal link (no pun intended) because he's crossed over otherwise, Ganondorf will link to Zeldawiki because he hasn't. Link's moves (originating from the Legend of Zelda series) will link to Zeldawiki, while Ganondorf's moves (original moves due to being based on Captain Falcon's moves) will link to Smashwiki.
Other specific aspects of this, which for the most part make the game pages' internal coverage be more consistent with how we handle other games':

  1. Structure the "List of items in Smash" to how Super Mario RPG (talk) had it in this edit, albeit with the remaining broken formatting fixed. That page always bothered me, and that version is a definite improvement.
  2. Merge the "enemies" pages to their respective game - they're already structured like any other game's enemy tables anyway. These pages also always bothered me.
  3. Merge the "Subspace Army" and "Subspace Stages" lists to each other to recreate a watered-down version of the Subspace Emissary page (to split from the Brawl page due to length and being exclusive to that campaign); it would also include a table for characters describing their role in said campaign, as well as objects/items found exclusively in it (Trophy Stands, the funny boxes, the metallic barrel cannons, etc... a lot of things from the deleted "List of Super Smash Bros. series objects" page, actually) - once again, all except Mario-derived things will link elsewhere (mostly to Smashwiki in this case).
  4. Section each game akin to how I had the SSB64 page as of this edit, including sections for Pokemon, Assist Trophies, Bosses, etc., and links to other wikis for subjects that we don't need pages on. Other sections can be added as needed, and table structure is not specifically set, so further info can be added.
  5. Leave the lists for fighters, stages, and (series-wide) bosses alone (for now at least), as they make sense to have a series-wide representation on here in some capacity. Also, you never know when one of them is going to cross over otherwise, like Villager, Isabelle, and Inkling suddenly joining Mario Kart, so it's good to keep that around in case a split is deemed necessary from something like that happening down the line.
  6. Have image galleries cover everything that can reasonably be included in an image gallery for the game, regardless of origin. This includes artwork, sprites, models, screenshots, etc, for any subject - yes, including Pokemon, so that will undo that one proposal from a month ago. Just like on the game pages, the labels will link to other sites as needed.
  7. Leave Stickers and Spirits alone (for now at least), their pages are too large to merge and are fine as they are for the reasons that opposition to deleting them historically has brought up.
  8. Include the "minigame" stages (Break the Targets, Board the Platforms, Race to the Finish, Snag Trophies, Home Run Contest, Trophy Tussle, the Melee Adventure Mode stages) in the "list of stages debuting in [game]" articles. For ones like Targets, it would just explain how it worked and then have a gallery for the different layouts rather than describing each in detail (and if we later want to split the Mario-based ones into their own articles, I guess we can at some point). Said minigame pages should be merged to a section in the SSB series article covering the series' minigames. The Subspace Emissary stages will get a section with a {{main}} to the stage section of the Subspace Emissary article (detailed in an above point).
  9. Keep trophy, assist trophy, challenge, and soundtrack pages covering only Mario things, leave the remainder of the images in the game gallery (fun fact: Smashwiki does not have game galleries, nor does their community want them; we can base what we could do on if other wikis do something, but not base what we cannot do from those - nothing forbids coverage just because of that).

People may wonder, "What about Nintendo Land and Saturday Supercade? Why don't they get this level of coverage?" It's simple, really: In Smash, you can have Mario throw a Deku Nut at Ridley in Lumiose City and nobody bats an eye at how absurd that situation is. In those other games, the different representations are very much split apart; all Mario-related stuff is within a few minigames that do not overlap whatsoever with any of the other ones. In Nintendo Land, you cannot have Mario fighting Ridley in the Lost Woods, despite (representations of) all of those things appearing in the game. In Smash, anyone can interact with anything, regardless of origin, so Mario characters can interact with anything, and anyone can interact with Mario things. That's why Smash, the melting pot it is, gets more focus than Nintendo Land, where everything's more of a side dish.

Proposer: Doc von Schmeltwick (talk)
Deadline: October 17, 2024, 23:59 GMT

Support - clarify it like this

  1. Doc von Schmeltwick (talk) - Per
  2. Axii (talk) Even though I disagree with points 6, 7, and especially 8 (Mario-themed minigames should be covered separately), I feel like this is the solution most would agree to compromise on.
  3. Camwoodstock (talk) While we would like to do some stuff of our own (cough cough, maybe a proper solution to Smash redirects clogging categories), this is a good start, we feel. If push comes to shove, we could always revert some of these changes in another proposal.
  4. Ahemtoday (talk) This is a great framework for our coverage of the series. I still would like a better handling of smaller things like trophies, stickers, spirits, and music, but I'm not sure what that would look like and we could always make that change later.
  5. Hewer (talk) Per proposal, this is a good step towards cleaning up our Smash coverage.
  6. Metalex123 (talk) Per proposal
  7. Tails777 (talk) I’d like to see where this goes. Per proposal.
  8. SolemnStormcloud (talk) Per proposal.
  9. ThePowerPlayer (talk) I've reconsidered my hardline stance since the previous proposal, and I can now agree with most of the points listed here. However, like others have said, I do want to revisit the coverage of massive lists like those for stickers and spirits in the future.
  10. Superchao (talk) Per the proposal. Hving the itemized list will allow for simpler debate and discussion in the future, rather than our ad-hoc coverage status built over time. Lay the groundwork, then discuss the details.
  11. Arend (talk) Per proposal.
  12. OmegaRuby (talk) Per proposal.
  13. Pseudo (talk) The idea that other series' relevance to the Mario franchise within Smash compared to other examples like Nintendo Land resonates greatly with me. Per proposal.
  14. Killer Moth (talk) Per all.

Oppose - don't clarify it like this

  1. SeanWheeler (talk) We might actually need to reduce the Smash coverage a bit more. We especially can't undo that proposal that reduced Pokémon. And those sticker and spirits list really should have been reduced to Mario subjects like the trophy list. The fact that the middle spirit list doesn't have a single Mario spirit is absurd. And maybe those fighter lists should be split back into their own character pages again. Most of them had appeared in Super Mario Maker. I have a different idea of how we should handle Smash.
  2. SmokedChili (talk) This wiki really doesn't need to cover every series that appears in Smash Bros. extensively. Would be better to limit full coverage to both Mario itself and Smash since that's the host series while minimizing exposure to others if there's some connection to Mario, like, which stickers boost tail damage for Yoshi. General info on all of the modes (Classic, collections, settings), that's fine. Characters, stages, items, Assist Trophy spawns etc., just list the Mario content, mention the totals and the proportions from Mario, and include screenshots of full selections if possible.

Comments - clarify the clarification?

(I was gonna name the options "Smash" and "Pass," but I thought that might be too dirty) - Doc von Schmeltwick (talk) 15:38, October 3, 2024 (EDT)

@Axii - I wouldn't say any of the minigames are really innately Mario-themed, though. If any were, I'd have them stay separate. Doc von Schmeltwick (talk) 16:02, October 3, 2024 (EDT)

As I mentioned on your talk page, Break the Targets and Board the Platforms have Mario-themed stages Axii (talk) 23:57, October 3, 2024 (EDT)
Yes, and as I mentioned in the proposal, those can be separately split later if it is determined to be acceptable. The minigames themselves, however, are not Mario-themed. Doc von Schmeltwick (talk) 00:19, October 4, 2024 (EDT)
Why not leave them out of this proposal though. Why should we merge Mario content? Axii (talk) 09:29, October 4, 2024 (EDT)
The current articles don't actually describe the individual stages anyway, just an overview of the mode. Also, those list pages already include the Mario stages, just with a "main article" template. Doc von Schmeltwick (talk) 13:56, October 4, 2024 (EDT)
It just means 4 more weeks before it can be split. I just don't see a need to decide on these in this proposal. Axii (talk) 04:41, October 9, 2024 (EDT)

@Doc von Schmeltwick I know you are familiar with my crossover article draft using Zelda as a base, but I do not think I clarified some of the intents I had with it, which I shared here with Mushzoom. I do not think it intersects with what you layout above, but I just wanted to let you know. (I also welcome other folks to check it out.) - Nintendo101 (talk) 16:45, October 3, 2024 (EDT)

I think both can coexist dandily. Doc von Schmeltwick (talk) 16:56, October 3, 2024 (EDT)

@SeanWheeler: Though the middle spirit list has no spirits of Mario characters, it's not irrelevant to Mario because Mario characters, stages, items, etc. appear in many spirit battles. In fact, the very first spirit on that page (Jirachi) has Mario relevance (you need Luma and Starlow to summon it). Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 18:09, October 3, 2024 (EDT)

@SmokedChili - What about non-Mario characters that we cover anyway due to them crossing over outside of Smash, like Link, Isabelle, and Banjo? Surely their presence in another crossover deserves to be acknowledged. That's one of the main issues that arises with the "nuclear" mindset. Doc von Schmeltwick (talk) 13:32, October 4, 2024 (EDT)

What about those? Them crossing over in Mario isn't the same thing as crossing over in Smash. That's where the complete selection screenshots come in, make them image maps where crossover subjects with Mario Wiki articles get image map links with necessary notes. That way lists don't have to bleed over to include anything else but Mario.
On another note, shouldn't you have just waited four more weeks? You posted here your concern over those two proposals stalling you further with this if they passed, but that's not how rule 7 works. It says 'any decision'. That means voting to keep status quo is also what can't be overturned for 4 weeks. SmokedChili (talk) 09:28, October 5, 2024 (EDT)
My understanding is that, because those two proposals failed, neither of this proposal's outcomes would contradict that. The coverage that they were trying to remove is kept either way here. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 11:25, October 5, 2024 (EDT)
Honestly, I think all those points should be in their own separate proposals. I would support #1 if it was a talk page proposal for Talk:List of Super Smash Bros. series items, but combined in a wiki proposal with other things I don't want, I had to oppose. @Axii is that month really worth having #6, #7 and #8? @Camwoodstock, sure we can revert some of these changes with another proposal, but the proposal rules state we have to wait four weeks before we have a counterproposal to a part of this proposal. And if Hewer is right about failed proposals not counting, then would opposing this be the better choice of action when you disagree with just one thing? Oh, and @Hewer, if I make a proposal to reduce the Spirit List, I would definitely want to keep the Spirit Battles that involve Mario fighters and stages. And with stickers, I would get rid of the non-Mario stickers that don't specifically boost Mario characters. And, I definitely do not want Smash 64's page in that way. It should be as focused on Mario like how Bulbapedia's Super Smash Bros. series game pages focus on the Pokémon content, and how the Sonic Wiki Zone's page on Super Smash Bros. Brawl was more about Sonic. #4 is going to make our Smash game pages more comprehensive than Smash Wiki's game pages. If we're really that worried about losing stuff in our reduction of Smash coverage, why don't we talk to Smash Wiki's admins about merging the pages we don't need into Smash Wiki's articles? There's got to be some cross-wiki communication if the Donkey Kong Wiki merged into us. SeanWheeler (talk) 01:11, October 6, 2024 (EDT)
My long term goal is only having non-Mario Smash content on the game page itself. If it means compromising to get more people on board, I'm all for it. I'm going to make a prediction that in 5 years the idea to cover Smash like a guest appearance won't be much controversial Axii (talk) 02:04, October 6, 2024 (EDT)
As I said in the proposal, "we can base what we could do on if other wikis do something, but not base what we cannot do from those - nothing forbids coverage just because of that." Also Sonic is a bad example since he was only introduced in the third game, while Bulbapedia is built around the very rigid structure of the main Pokemon games anyway. Doc von Schmeltwick (talk) 02:12, October 6, 2024 (EDT)
I think folks engaging with this proposal should think critically about what type of titles the Super Smash Bros. games are in relation to Super Mario? Are they:
A. Proper Mario crossovers on par with Mario & Sonic at the Olympic Games and Itadaki Street DS? or
B. Games that have some Mario material in it on par with Punch-Out!! (Wii), NES Remix, The Legend of Zelda: Link's Awakening, and NBA Street V3? or
C. Neither or something in between?
I think part of the issue with this in particular is not only that Smash Bros. articles had seen full support on the wiki for a very long time, but many of the characters and elements in it do appear with Super Mario in completely other contexts. Almost none of the Fighter lists we have on Super Mario Wiki exclusively cover the Smash Bros. title of their respective articles and it is just odd to organize information that way. Super Mario also represents the greatest percentage of material in every Smash Bros. game.
I do not know if it is worth holding on to any spirit, sticker, or trophy lists, but if we did, and restricted to to ones that are not only of Super Mario subjects, but things that can be applied to Mario fighters, I would personally find lists like that so fragmented that the articles would basically be useless. What's the point of having intentionally fragmented articles and lists that no one is going to read? - Nintendo101 (talk) 02:22, October 6, 2024 (EDT)
The trophy lists already got trimmed to just Mario ones, which is easier to do there because the non-Mario ones don't interact with Mario characters like stickers and spirits do. I wouldn't want to remove Mario-relevant information, but I also agree with your "fragmented articles" comment, so I think not trimming the stickers and spirits is the best choice. Plus, in the case of spirits, they can all be used by Mario characters, so you can justify it similarly to the list of items. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 07:01, October 6, 2024 (EDT)
To be clear, failed proposals do count for the four-week no overturning rule, I was just saying that the failed outcome of those two specific proposals doesn't contradict either of this proposal's outcomes. If this proposal were to fail, it'd still be four weeks until a proposal to only do some of its changes could be made. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 06:43, October 6, 2024 (EDT)
I'd say Smash should be something between a guest appearance and crossover. Smash is the biggest crossover ever, but to cover it as fully as Mario & Sonic, we'd be competing against Smash Wiki. But we can't treat Smash as a guest appearance because Mario is more overrepresented than Fire Emblem, and because Link's Awakening is not covered on Link's page despite having a page for it. If we could merge with the DK Wiki, then maybe there could be some cross-wiki discussion to merge pages not relevant to Mario into Smash Wiki. Maybe we should get the CrossWiki Team involved? I don't know how this works. I don't see the DK Wiki merge in the proposal archive. SeanWheeler (talk) 00:47, October 7, 2024 (EDT)
I do not think this is the same situation because DK Wiki was consolidated with Super Mario Wiki due to low community activity, maintenance, and attention. (It should be noted that Super Mario Wiki was covering the Donkey Kong franchise concurrently at the time anyways, even for the many years when DK Wiki existed.) It was the Donkey Kong Wiki's admins that sought consolidation with us. Both Super Mario Wiki and Smash Wiki are in the good fortune of having dedicated communities, so there isn't exactly the same kind of pressure.
At this point, I do not think there are any Smash Bros. articles on Super Mario Wiki that are not also already on Smash Wiki. In my view, what differentiates some of these articles is "tone" and how subjects are covered. - Nintendo101 (talk) 01:13, October 7, 2024 (EDT)
Well, of course there wouldn't be any Smash Bros. articles on Super Mario Wiki that isn't already on Smash Wiki. And there weren't any Donkey Kong Wiki pages that weren't already on Super Mario Wiki was there? What did we do in that merge, cut-and-paste text from DK Wiki into the Donkey Kong related pages here? I would want Smash Wiki on board so that they don't accuse us of plagiarism when merging like that. And if our tone is not compatible with theirs, or if their pages are better than ours, I wouldn't mind if we straight up delete content here. Admins can undelete them if we ever need them later. I definitely do not want this proposal to undo the Pokémon proposal. SeanWheeler (talk) 15:06, October 7, 2024 (EDT)
Where did this whole idea of us "competing" with SmashWiki come from anyway? Even besides the fact we don't have to base what we do on other wikis, the two wikis here have vastly different coverage from one another despite some overlap (SmashWiki has a lot of separate pages that this wiki no longer does, coverage on the fanbase and players, etc., while this wiki covers the whole Mario franchise, obviously). This isn't like Donkey Kong Wiki, where the entirety of its scope was also covered by this wiki. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 15:51, October 7, 2024 (EDT)
Up until this proposal, Super Mario Wiki fully covered the Super Smash Bros. series per the MarioWiki:Coverage policy for crossovers, meaning that for a significant amount of time, the Super Mario Wiki covered about as much Smash as Smash Wiki. In fact, before Smash Wiki joined NIWA, Bulbapedia linked the characters without a NIWA wiki to Super Mario Wiki. Here's the edit to Brawl that relinked characters from Super Mario Wiki to Smash Wiki in 2010]. It's actually a good thing that we're reducing Smash coverage. Doc's proposal that is going to bring back more Smash content would actually be regressive, especially when it undoes the reduction of Pokémon content. Why does Doc want the Pokémon stuff back? Other than Pikachu appearing with Mario characters in the Smash 64 commercial, Mario fighting Charizard in Greninja's reveal trailer, Rayquaza grabbing Diddy Kong in the Subspace Emmisary, and of course the gameplay of Smash allowing Mario characters to fight Pokémon and pick up Poké Balls, Pokémon has nothing to do with Mario. If someone were to write an article on Maggie Lockwood from Chicago Med on the Super Mario Wiki, with so much detail about her history in the episodes of Chicago Med, Chicago Fire and Chicago P.D. without plagiarizing the Chicago Med Wiki article and written well according to the manual of style, of course we'd delete that article because we don't cover the Chicago franchise at all as those shows are not even remotely related to Nintendo. And if it's written so professionally that the only rule broken is the Coverage policy, it wouldn't be funny enough to make it to BJAODN. Unless someone finds it funny that a non-Mario article was written so well on the Super Mario Wiki? But, if the user were to admit that the article was made for BJAODN, that's a real dealbreaker. Sometimes we have to permanently remove content. And in the case of Super Smash Bros, it would be better for use to focus on the Mario, Yoshi, Donkey Kong and Wario series content in the Smash game instead of acting like another Smash Wiki. Do not bring back the unnecessary clutter. SeanWheeler (talk) 01:52, October 9, 2024 (EDT)
Except that the proposal isn't about adding articles on Pokémon, it's just to keep all the information about the Smash games on the games' own pages, which I think is reasonable as a middle ground between guest appearance and full Mario crossover. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 03:50, October 9, 2024 (EDT)
But it wants to add more irrelevant images to the galleries. Honestly, maybe we should treat Smash more like a guest appearance. Sure, the Super Mario franchise has been overrepresented in Smash to the point of getting more series symbols for spinoffs, but when there's a NIWA wiki, it's best to let Smash Wiki handle Smash. We don't need the list of Pokémon on the game pages. I'd check Bulbapedia's version of those pages instead. We shouldn't cram everything about the Smash games. There's a reason why we're splitting histories and galleries of major Mario characters. There is MarioWiki:Article size to consider. Other NIWA wikis would focus on their series in the Smash games. When a majority of NIWA wikis handle Smash a certain way, it might be a good idea to follow their example. And I think those lists of Smash content should be reduced to Mario-relevant information. And the lists that only include stuff that don't have their own pages should be deleted. Characters who cameoed in Super Mario Maker and other Mario-related appearances outside of Smash should be split from those lists because we would have some information that Smash Wiki wouldn't cover. SeanWheeler (talk) 00:06, October 10, 2024 (EDT)
As I said in the proposal, "We can base what we could do on if other wikis do something, but not base what we cannot do from those - nothing forbids coverage just because of that." Also "irrelevant" is entirely subjective. Doc von Schmeltwick (talk) 00:33, October 10, 2024 (EDT)
Relation to Mario should be a major factor for relevance to a Mario wiki. There's a reason why Mario cameos are given less coverage than the half-Mario crossovers like Mario & Sonic at the Olympic Games. In Smash, Mario's the most overrepresented series, but is one of many series in Smash. SeanWheeler (talk) 04:01, October 10, 2024 (EDT)
Bringing up an extent of coverage we have that I feel is super important--SmashWiki does not do game galleries, and, to my knowledge, they do not want game galleries. Our coverage of Smash provides some images that would otherwise not be seen in places other than, say, The Spriters Resource, which in my opinion is more difficult to navigate for a few images than a wiki such as this. Thinking specifically about the proposal passed to remove "excessive Pokémon lists and images"--to my knowledge, those images are not present (or are not present for the most part) on SmashWiki. --OmegaRuby (talk) 11:43, October 10, 2024 (EDT)
Smash Wiki has gallery sections for each game. Maybe not gallery pages, but still. And besides, the images from that proposal were deleted weren't they? SeanWheeler (talk) 02:04, October 11, 2024 (EDT)
You said it yourself. "Admins can undelete them if we ever need them later." That's what this is. Doc von Schmeltwick (talk) 23:52, October 11, 2024 (EDT)
But that proposal passed for a good reason. Those images and those lists of Pokémon aren't much use for a Mario Wiki. And besides, the individual Pokémon pages on Smash Wiki is full of images of those Pokémon in Smash. I can't remember what Pokémon images we had here, but I don't think they really have any more value than what's on Smash Wiki. Also, not everyone who voted their support actually supports your entire proposal. Axii doesn't support #6, #7 or #8, and Camwoodstock is thinking of reverting some of these changes with another proposal. So are we going to undo that Pokémon removal proposal only to redo it next month? Wouldn't it be kind of counterproductive to delete them for a month, restore them for another month, and then delete them again? That would look like a deletion war, which is more insane than any edit war because only admins could delete and restore pages. Guys, if you don't want #6 enforced, please oppose this proposal. It would be better to wait and then propose the changes you want individually than it is to undo a proposal you just supported. Would you really want that back-and-forth with the Pokémon content you got rid of? SeanWheeler (talk) 01:06, October 12, 2024 (EDT)
We will have to wait four weeks regardless if this proposal passes or fails, at least some positive changes can be implemented now. It doesn't hurt to take our time and get the rest of the community on board. Axii (talk) 01:14, October 12, 2024 (EDT)
"Doesn't hurt to take our time"? You tell that to Doc. Going back to that subject, what gets me is why would he react like those last two proposals would hold him back (if they succeeded, as he thinks)? That implies there is something in those proposals that he saw overlapping with this, and he's keeping mum because a) he thinks others have already answered that, and b) given his track record, the more invested he becomes in wanting to pass his favored changes, the more likely he is to sidestep the rules. SmokedChili (talk) 17:34, October 12, 2024 (EDT)
What? Those two proposals were about removing content from the pages on the games, and that goes against this proposal because one of its main goals is to keep the pages and galleries on the games comprehensive while trimming on other pages. There's no mysterious conspiracy to "sidestep the rules" here. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 20:23, October 12, 2024 (EDT)
You have to wait four weeks to do something that contradicts a passed proposal or re-proposes a failed proposal. If a proposal fails, there's nothing stopping you from making a counter-proposal immediately, since that indicates community consensus may already be mostly on-board with the opposite of the original proposal. Since those two proposals failed, it ended up not mattering - what I was complaining about then was it pushing it back further if they passed or went into overtime. Also, as it is, I normally play the long game and had been doing so on this subject for years until these past several proposals spurred me into action (if you look seven years ago, I was the one complaining about an omnibus proposal for Smash coverage, so things change... and also that one resulted in a lot of the half-baked oddities of the current system that this one aims to address). Doc von Schmeltwick (talk) 12:27, October 15, 2024 (EDT)
Still not how the rule works, if a proposal failed then any proposal following it, a counter-proposal included, is bound to wait those four weeks. Nothing about community consensus there. SmokedChili (talk) 14:06, October 17, 2024 (EDT)
False. The only rule on the subject (rule #7) says "No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old." Also, no one complained when I made a proposal to split the "truck" page immediately after my "merge all traffic" proposal failed, since that was doing the opposite. Doc von Schmeltwick (talk) 14:19, October 17, 2024 (EDT)
@SeanWheeler personally, without getting into semantics, having curated and organized galleries is just nice to have and I do not think it has to be the big deal it is being laid out to be. One of Super Mario Wiki's strengths as a historical and artistic reference is its preservation of important assets, artwork, and material, and organizing them. Applying that muscle to the Super Smash Bros. series is, in my view, just objectively wonderful because it is such an important game series and there is not support for this anywhere else. For contrast, this is Smash Wiki's gallery section for Super Smash Bros. Brawl. And here is ours. For many years, these galleries were the primary Smash Bros. material I would engage with on Mario Wiki because Smash Wiki, for as thorough as it is, just does not support them and the community there has a more utilitarian philosophy. There's nothing wrong with that, but it does mean Mario Wiki is supporting something that Smash Wiki just isn't, and unless there is a future where they decide to support this type of infrastructure themselves, I personally think having complete galleries for the Super Smash Bros. series on Super Mario Wiki is an objective good. Maybe I would feel differently if the discussion was that we should be building up these galleries from scratch. But given they are already on the site and have been for years, little is gained from stripping them of material. A fair bit would be lost. - Nintendo101 (talk) 12:54, October 15, 2024 (EDT)

Cite relevant proposals and discussions on policy pages and guidelines

Cite 7-0
Despite how restrictive these pages are to editors below a certain rank, there is truth in saying they are just as community-driven as other pages--often, it's through a consensus among people like me and you that certain rules are implemented or removed. To those who peruse the wiki's policies, it may be helpful to know how the community came to such an agreement on a certain matter, i.e. seeing precisely what arguments lay behind it in a way that the policy page itself may deem excessive to elaborate. Even in the case of a policy that fully reiterates what a discussion put forward, or a proposal where the only one who employed any arguments was the proposer themself, with other users unanimously supporting it through a mere "Per all", there's still value in knowing that there was consent from the community in implementing what was proposed.

The wiki could satisfy this need by citing, as one does in mainspace articles, the discussion that led to the policy change. Said discussion doesn't need to be a proposal (i.e. where the consensus is quantifiable through votes); it could be any kind of user exchange, on this wiki or even on the forums, that thrusted the change into action. Citations could be added to any guideline specifically laid out in aid of editors on this wiki, so not just on pages that are part of the "MarioWiki:" namespace, but also formatting templates or Help pages.

Here is how I propose this is put into action, using snippets from policy and guidelines. I suggest collating these discussion links in a dedicated "discussion" ref group to set them apart from miscellaneous citations that may be present alongside.

MarioWiki:Manual of Style#Non-fiction

Future tense should be avoided when referring to subjects appearing in upcoming media; as trailers and screenshots show said subjects to have already been incorporated into and are thus presently in the game, present tense must be used.[discussion 1]

Template:Rewrite-expand

A specific reason must be added as a parameter (e.g., {{rewrite-expand|Give more detail on the difference between Red and Green Koopa Troopas}}) and it needs to be a clear, actionable point (i.e., simply slapping the template on a page with "bad writing" as the reason is not sufficient), otherwise the template will be removed from whatever page it was applied to.[discussion 2]

MarioWiki:Naming#Shared titles

If there are four or more pages which could be reasonably associated with a particular title,[discussion 3] [...]

  1. ^ MarioWiki:Proposals/Archive/53#Ban_certain_cases_of_future_tense_from_the_wiki
  2. ^ MarioWiki:Proposals/Archive/61#Discourage_drive-by_templating
  3. ^ MarioWiki:Proposals/Archive/70#Lower_the_requirement_for_a_disambiguation_page_from_5_to_4

Note that should this proposal pass, not every bit of policy will require some retroactively-made discussion to be cited. A lot of them just happened to be, either out of common sense or through internal talks. This proposal strictly targets policies and guidelines that already have a relevant discussion available somewhere publicly in the community.

Proposer: Koopa con Carne (talk)
Deadline: October 17, 2024, 23:59 GMT

Support

  1. Koopa con Carne (talk) per proposal.
  2. OmegaRuby (talk) Fantastic idea that supports the community just by way of making it known that we can make big changes.
  3. Arend (talk) Actually not bad of an idea at all. Per proposal.
  4. ThePowerPlayer (talk) Per proposal.
  5. Pseudo (talk) This would be very useful and is something I have often wondered about while looking through policy pages historically.
  6. Camwoodstock (talk) While you could argue this is redundant in the face of just, manually updating the links to proposals, we don't see any harm in trying to standardize that process like this.
  7. FanOfYoshi (talk) Per all.

Oppose

Comments

Was this proposal not just made? How come it's due by tonight? --OmegaRuby (talk) 08:05, October 10, 2024 (EDT)

Corrected. I'm sorry. -- KOOPA CON CARNE 08:26, October 10, 2024 (EDT)

I have a list of proposals that decided coverage status for every guest appearance title, maybe it could help. Axii (talk) 13:55, October 15, 2024 (EDT)

Recreate Smash Bros. DOJO!!

Do not recreate 4-9
As far as I can tell, this proposal won't contradict the big ongoing proposal. 17 years ago this proposal removed Smash Bros. DOJO!!, an official website for Brawl that contains some cool content about the game. The website is still accessible, which is really surprising for Nintendo. The proposal decided that all website articles should be deleted, something this wiki no longer does (just look at Play Nintendo, Wario's Warehouse, and Nintendo Kids Space). Smash Bros. DOJO!! contains plenty of Mario content (mostly in the form of articles similar to Wario's Warehouse) that should be covered on its own page.

Proposer: Axii (talk)
Deadline: October 22, 2024, 23:59 GMT

Support

  1. Pseudo (talk) Per proposal.
  2. Tails777 (talk) Per proposal
  3. Camwoodstock (talk) We're surprised this was deleted given we're currently the last line of defense for Wario's Warehouse nowadays--talk about a change of heart! We wouldn't be opposed to greater documentation of Nintendo's promotional websites, frankly, and this'd be a good starting point for that. Smash DOJO is one of the most famous examples of one of these promotional sites, and while we are a little shaky given it's Smash and not Mario outright, there's nothing preventing us from doing something similar for more Mario-related websites down the road.
  4. FanOfYoshi (talk) Per all.

#Koopa con Carne (talk) Per proposal.

#OmegaRuby (talk) Per proposal.

#Axii (talk) A proposal to reinstate a deleted Smash page, unbelievable

Oppose

  1. Ahemtoday (talk) The Dojo is the same as the Smash 4 or Ultimate websites — all three of them, like most official video game websites, are basically advertisements for their respective games. We're not the Smash Wiki — I see zero need for our coverage of the Smash series to go so deep as to begin to cover its promotional material.
  2. EvieMaybe (talk) we don't need to keep eating smashwiki's lunch. if there's enough exclusively mario-centric content to warrant making a page out of, i'll change my vote, but for now i'm firmly on the camp of "smash stuff is not mario stuff"
  3. SeanWheeler (talk) If we have the official website for Brawl, will we create pages on the Smash 4 and Ultimate websites, the SmashBoards forums and every website Smash Wiki has?
  4. Shy Guy on Wheels (talk) Smash Bros. DOJO!! is the website for Super Smash Bros. Brawl, and I don't know of any instances of this wiki actually making a page for a game's official website, so this would just be incosistent. I'm fine with the general idea of covering the posts on the website, but this would also be inconsistent as neither the posts on the Super Smash Bros. Ultimate website, or Super Smash Bros. 4's "pic of the day" series, have pages here. I want to stress that I don't take issue with either of these concepts as a whole, I'm just not a fan of making a change to create an article on this one topic, and would prefer a bigger proposal that allows coverage of similar topics as well.
  5. Mario (talk) Not relevant to MarioWiki's goals.
  6. Sparks (talk) Per all.
  7. ThePowerPlayer (talk) Super Smash Bros. ≠ Super Mario. SmashWiki already covers this website well, and even if we're talking about a Mario game, there's no precedent on the Mario Wiki to give a game website its own article, as Shy Guy on Wheels brought up.
  8. Power Flotzo (talk) Per everyone.
  9. Super Mario RPG (talk) Per Ahemtoday, EvieMaybe, Shy Guy on Wheels, and others.

Comments

I'd suggest that the website's (textual) contents not be entirely copied and pasted here, though. I understand why this was done with Wario's Warehouse, as that site pretty much disappeared without a trace, but Smash DOJO's still officially up and has been backed up on Internet Archive (thank god Wayback Machine's at least read-only now). I envision its wiki article having a summary of each section of the site and a list of blog posts with relevant links for each section. -- KOOPA CON CARNE 14:22, October 15, 2024 (EDT)

Unless Nintendo takes it down, that's the plan. Axii (talk) 14:29, October 15, 2024 (EDT)

"We wouldn't be opposed to greater documentation of Nintendo's promotional websites, frankly, and this'd be a good starting point for that."
Play Nintendo, Nintendo Kids Space, SMBPlumbing.com, and Welcome to Greedville are a joke to you??? :'((( -- KOOPA CON CARNE 16:47, October 15, 2024 (EDT)

We know this was probably a goof, but honestly, those articles are a very nice basis for what we're talking about! We mostly mean we could also add stuff like the old flash-based NSMB website that had a boatload of downloadables and even hints for the game itself (the former have an incomplete list on that game's gallery, the latter seem to be entirely AWOL), or maybe even stuff like the Japanese Paper Mario site that had pre-created lists of badge setups for the player to try out, complete with descriptions of their strategies. ~Camwoodstock (talk) 16:55, October 15, 2024 (EDT)

@SeanWheeler why are you implying fan websites would get covered? This is not Smash wiki. This is a Mario wiki that should cover everything Mario, and Smash Bros. DOJO!! contains just that. Official Mario content published by Nintendo. Axii (talk) 02:25, October 16, 2024 (EDT)

@Shy Guy on Wheels there is really nothing stopping people from making a page about other official websites if they have enough unique Mario content on them. SMBPlumbing.com is a good example of that. If anything it would be inconsistent if we didn't cover major websites when there's official Mario content on them. This proposal specifically targets DOJO because it has a unique name, historical significance, and plenty of content about Mario. Axii (talk) 09:50, October 16, 2024 (EDT)

@EvieMaybe why are you opposed to covering official Mario content on the Super Mario Wiki? Axii (talk) 09:51, October 16, 2024 (EDT)

@Ahemtoday so, the same as SMBPlumbing.com? Why should we avoid making a page for a website that contains Mario content released by Nintendo just because it's related to Smash? Axii (talk) 09:53, October 16, 2024 (EDT)

Rescinding my vote because, honestly, having browsed the website quite a bit, I'm left wondering what type of content there justifies treating it as a work separate from the object it promotes, in a way that other promo websites aren't. DOJO is definitely more insightful than your average Nintendo game microsite, doubling as a blog where the director himself spills much ink on Brawl's intricacies, but it's not that different in principle--its purpose is still almost solely to give you information on the elements you can expect in a potential future purchase, along with the fringe player-centric content such as fan-submitted snapshots and world records in minigames. Portals like Play Nintendo, SMBPlumbing.com, Welcome to Greedville, and The Lab, while indeed also built entirely in service of one or more products, provide experiences in and of themselves, either by being a hub of activities or by supplementing the fiction within said product(s) and therefore expanding Mario's universe (i.e. SMBPlumbing.com is a make-believe business site for the Mario Bros.; of course it would have an article, it's meant to exist within the Mario movie).
I understand the... let's say, cultural importance of Smash Bros. DOJO, that it represented the bells-and-whistles of Brawl prior to its release, and the fact that it provided direct and constant communication from the game's director, so, yes, it is a special product in its own way. Heck, the title itself is unique and suggests a departure from the average promo site, as opposed to a more generic "Official Super Smash Bros. Brawl(TM) Website". However, it is also inextricably linked to the game. The best course, IMO, would be to summarize the website in a section of Brawl's article and limit it to that, especially against the backdrop of all these attempts to restrict Smash Bros coverage. To be honest, I think Super Mario Maker Bookmark deserves more to have an article. -- KOOPA CON CARNE 12:38, October 16, 2024 (EDT)

I don't know if the Bookmark site should get a page. There's just nothing to write about, no extra information, just a search and bookmarking function. DOJO, on the other hand, contains news publications. It's not an interactive website, but it doesn't devalue all the posts on it. Anything Nintendo puts out online is inherently an advertising material, but, given that Nintendo published articles on it for a year, it should be covered on this wiki. The opposition has mentioned that this proposal would open a can of worms of its own, namely which websites should we even cover, and I think it needs to be addressed by a different proposal at some point in the future regardless of the outcome of this proposal. But for now, I see no harm in making a page for a website with historical significance, unique name, and Mario content exclusive to it. Axii (talk) 12:53, October 16, 2024 (EDT)
Koopa con Carne makes a good point. Rescinding my vote as well, but not switching to oppose, as I wouldn't really mind if we had an article for it anyways. --Small Luigi doing the V-sign in the Super Mario All-Stars remaster of Super Mario Bros. OmegaRuby [ Talk / Contribs ] 14:13, October 16, 2024 (EDT)
The fact that not every Mario website gets an article here would be a strong point against DOJO's return. Why should a Smash official site get an article when not every Mario site has one? Not even Nintendo.com has a page here. DOJO has even less Mario content than Brawl itself. And Smash Wiki has an article on it if you want to read it on a wiki. What is even worth having that article here? Is it going to focus on the Mario content, or would it focus on details that were too unnecessary for the Smash Wiki page? Could someone who undeletes pages check what was on the page the proposal is trying to restore? Was the page a stub? How similar was the page to the Smash Wiki page? Well, even if it was a good article, I think we should give all Mario websites pages before we consider crossover websites like the Smash Bros. Dojo pages. Yes, even the Super Mario Wiki should get a page on itself that isn't the Main Page before we do Smash websites. SeanWheeler (talk) 01:55, October 17, 2024 (EDT)
The quality of the original article is irrelevant, what matters is how much Mario content there is to cover. As I said above, this wiki should have guidelines on website coverage, but it's not for this proposal to decide. And no, this wiki shouldn't cover fan websites. Axii (talk) 03:26, October 17, 2024 (EDT)
In terms of Mario content, it wouldn't be much. It would be almost like having a page about Smash Wiki focusing on their Mario pages. Except that there's even less Mario content on that than there is on Smash Wiki because it is focused on Brawl which has less Mario stuff than Ultimate. The home page shows a wider version of the game's cover art which has Mario, Wario and Peach on it along with eight non-Mario characters. The character's gallery has only Wario and Diddy Kong out of the twelve characters in the newcomers section; Mario, Bowser, Peach, Donkey Kong and Yoshi out of the thirteen veterans, and the only secret character who is Mario-related is Luigi. The Mario universe doesn't even take up half the roster. Now, let's look at the stages. Delfino Plaza, Yoshi's Island, Rumble Falls, WarioWare Inc.; Mario Circuit and Mushroomy Kingdom are the 6 Mario stages out of the 23 visible stages in the Stages category not counting the links to the two lists of Melee stages. Well, I guess the first part is not much of a list because it only has the Temple from Zelda. But in Melee Stages Part 2, there is Yoshi's Island and Rainbow Cruise as the two Mario stages out of the list of five. Not even half of the stuff on the DOJO is Mario related. I don't see how it could warrant an article when a purely Mario official site like the Super Mario Maker Bookmark doesn't. SeanWheeler (talk) 23:30, October 18, 2024 (EDT)

For everyone's information, I added a section about the site on Brawl's article. I don't believe the outcome of this proposal has any bearing on the manner this subject is currently handled, seeing as the sole goal of the proposal is to give it a separate page. I also disagree with the idea that the site is irrelevant to the wiki, for the simple reason that, much like the game it advertises, it has lots of Mario content on it and is official. -- KOOPA CON CARNE 11:04, October 18, 2024 (EDT)

Most of the opposition has valid takes, but I still don't understand why @SeanWheeler brought up the SmashBoard forums in his oppose vote, as well as all websites covered by the SmashWiki, which in turn includes websites like Source Gaming and Anther's Ladder/Smashladder. Those are fan websites. The Super Mario Wiki does not cover fan content at all, let alone fan websites. In fact, I'd argue that this wiki would sooner give the Smash Bros DOJO its own article than, say, the Mario Fan Games Galaxy, despite the latter befitting the Mario theming better; because the DOJO is at least an official Nintendo website. It feels a little weird to include sites like Smashboards among the official Super Smash Bros websites in your argument as if they're all on equal footing, when they're clearly not. ArendLogoTransparent.pngrend (talk) (edits) 16:09, October 21, 2024 (EDT)

My own issue with this proposal is that there is no policy on website coverage we could refer to. I also recognize that other official Smash websites contain news articles similar to DOJO. I still believe that this website should get its own page, mainly because of a unique name assigned to it that makes it stand out among other websites from the same series and the amount of Mario content featured on it.

I believe this wiki needs proper guidelines for website coverage, because right now it feels like an inconsistent mess. Play Nintendo's coverage is so excessive that everything from opinion polls to cards and prints gets covered, but then something like DOJO gets the short end of the stick. It's not like this proposal wants non-Mario Smash content to be added, but the criticism of "it's Smash, so it's not our job to cover it" is still being made. This proposal is flawed to the core, in the sense that it has no legs to stand on. I'll see you in four weeks! Axii (talk) 16:34, October 21, 2024 (EDT)

The first two Smash games also had uniquely named websites, albeit Japanese-only. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 13:38, October 22, 2024 (EDT)
@Arend I had no idea what our policy was about fan content. I mean, it's obvious that we don't cover fanon, but in terms of websites, I didn't even know what kind of websites we cover. It's only now that I've discovered the Internet category here, and that's from trying to look up "Category:Websites" after reading your comment. Also, please do not refer to me by the singular they. I am a he. Your comment was more correct before you added that pronoun. SeanWheeler (talk) 19:01, October 22, 2024 (EDT)
The wiki makes a point of not covering fan content, why would websites be an exception? Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 02:46, October 23, 2024 (EDT)
What Hewer said.
Also, I use "they" whenever I'm uncertain about one's gender, so I'm sorry about the potential misgendering. I'll quickly correct it for you. ArendLogoTransparent.pngrend (talk) (edits) 05:45, October 23, 2024 (EDT)

Forbid negative criticism of other NIWA wikis

canceled by proposer
Recently I've been concerned over the criticism of our affiliated wikis in NIWA, particularly in proposals. This proposal will not affect the style of our wiki (i.e. we don't start using tabbers just because other wikis do so). It's just encouraging other users to be friendlier to other NIWA wikis. We all feel strongly about the same endeavor of being independent. To quote the front page, all NIWA wikis are united by the following values and highlight the values that will back my proposal:

We are driven by our focus on our fans:

  • Fan communities should be run by the fans, and not corporate entities that don't put the community first.
  • Fan communities should be run for the fans, by people who will always think about how they can continue to enhance the enjoyment of everyone in the community.
  • Fan communities should be run together with the fans, embracing a spirit of co-operation and camaraderie.

To give one example of what won't be allowed if this proposal passes, you cannot say "I don't think WiKirby is a good example -- of anything." WiKirby is a different experience from this wiki, as is any NIWA wiki, but everyone in the WiKirby community is friendly people who are trying their best at giving the best Kirby coverage on the internet.

To back up my reasoning behind the above paragraph, the about page says "Each maintains their own unique designs, values and traditions. We are bound together by our common desire to better ourselves (and each other) while retaining our own identities and autonomy." Putting other wikis down, like the example above, goes against the very principles of what it means to be part of NIWA. The Courtesy policy states that it is not in one's place to pick at the shortcoming of others. Why should we limit that treatment that treatment to only users on our wiki, especially when editors from other wikis edit here all the time? We're all in this battle against Fandom together, and we've made marvelous progress that no single wiki community alone could do.

Why be rude to other wikis, even? I've seen great nods to this wiki like with the WarioWare pages on Fire Emblem Wiki and Zelda Wiki. I love the franchise and series pages that @Nintendo101 is working on (and it's helping with my pet peeves with excessive coverage), since I think it could resolve a lot of coverage issues here, and reciprocate nods back over to our friends on other NIWA wikis.

If this proposal passes, the Courtesy page will be updated to address this, accordingly.

Proposer: Super Mario RPG (talk)
Deadline: November 6, 2024, 23:59 GMT

Support

  1. Super Mario RPG (talk) Per
  2. Killer Moth (talk) Per proposal. Keeping this place a positive and healthy community is only a good thing, so making sure we don't alienate other NIWA wikis is important.

Oppose

  1. Axii (talk) Criticism of other wikis is a good thing. Community discussion and pointing out flaws isn't "being mean" to other wikis, neither is using them as an example of what we should avoid doing. "...Everyone in the WiKirby community is friendly people who are trying their best at giving the best Kirby coverage on the internet." I'm sure they are, but discussion of other wikis' flaws has nothing to do with it. Nothing says camaraderie like discussing issues openly. There is no harm in comments like "I don't think WiKirby is a good example -- of anything". Silencing it only risks people avoiding mentioning other wikis in anything but a positive light in fear of getting a reminder or a warning.
  2. Hewer (talk) Being openly rude to other people is already forbidden in the courtesy policy, so having a specific ruling about this feels redundant. At best, it's an extra rule that doesn't serve much of a purpose, and at worst, it's limiting people's freedom to say what they think. No wiki is infallible, whether we're in an alliance with them or not, and I don't think one person making a small remark about what they feel are shortcomings of another wiki indicates disrespect to that wiki's community or undermines the alliance in any way.
  3. Nintendo101 (talk) Forgive me for the strong language, but this is absolutely outrageous. Good-faith criticism is an intrinsic component of any communal creative project, as well as an important freedom of the people involved. There are not many things that I would consider being more disrespectful to our NIWA affiliates, or the SMW userbase, than stymying what people can say about our fellow wikis in good faith. I would be disturbed if any of our NIWA affiliates had a similar policy about Super Mario Wiki.
  4. LinkTheLefty (talk) Let's make one thing very clear: criticism and flaming are not the same thing. Some users are, on an individual level, more opinionated than others, but none of it affects the wiki as a whole or its aims.
  5. Sparks (talk) Per all.
  6. Koopa con Carne (talk) Per Axii and Hewer. Self-righteousness and fake positivity are some of the most insidiously harmful traits that a community can foster anywhere. Whether you're one person or a community, one of the most important things you should do if you seek to improve your work is to be open to criticism, be able to pick it apart, and internalize the constructive parts. I was here to witness it when the phrase "oddly enough", a tentpole of Mario Wiki writing in the late 2000s and early 2010s, slowly went the way of the dinosaur, which I heard owed to the ridicule of fellow Mario fansite TheMushroomKingdom.com. There could be more examples of such undertakings I'm not aware of, but as someone who's long been involved in this project I actually welcome any and all criticism coming my way or our way with great radiant warmth.

Comments

Question: Do the other NIWA wikis have similar rules in place about us in kind? LinkTheLefty (talk) 14:45, October 23, 2024 (EDT)

I kind of thought it's a given, based on the front page of niwanetwork.org, but there's no harm in clarifying it on wikis themselves. Super Mario RPG (talk) 14:48, October 23, 2024 (EDT)

@Axii Pointing out flaws of other wikis isn't our role, nor anything this particular wiki and its endeavors can do anything about. To give the tabber example, others can still criticize what they don't like about it, but without pointing fingers at other wikis. Super Mario RPG (talk) 14:50, October 23, 2024 (EDT)

It isn't this wiki's role, and the wiki doesn't do it. Criticizing an aspect of something isn't being mean to it. When an editor says "SmashWiki's coverage is poor for a casual player", they don't mean "SmashWiki is terrible". They mean "this specific aspect of the SmashWiki isn't good". Criticizing something isn't insulting, it's bringing up an issue to light. Noone on this wiki goes around badmouthing other wikis. It only comes up as an example of what should be avoided. If other wikis' editors happen to read it, they can consider if it's worth bringing up to their own community. It harms noone, it only benefits everyone in the long term. Axii (talk) 14:56, October 23, 2024 (EDT)
Yes, but we are a wiki on Super Mario. Saying things (like the SmashWiki example) is counterproductive to this wiki's goals. And when I said "criticism" in the proposal title, I was not referring to it as "constructive criticism." There is no way to spin "WiKirby is not good at anything" as something that's intended to come across as positive, constructive, and supportive. Super Mario RPG (talk) 15:01, October 23, 2024 (EDT)
Using another wiki as an example of what should be avoided isn't counterproductive, as I said already, noone here goes around badmouthing other wikis. Even small comments like "WiKirby is not good at anything" are opinions of individual editors that harm noone. Sure, not everything is constructive, but I believe it's better not to introduce it as a rule anyway because all it does is make people avoid mentioning other wikis. Not to mention, it would be hypocritical to criticise Fandom and pretend like NIWA should be given a special treatment. I believe this rule would only hinder discussion. If users feel the need to use another wiki as an example of what should be avoided, they should be able to. Axii (talk) 15:08, October 23, 2024 (EDT)
If pointing at another wiki as an example of what to be avoided, it may upset others from that community if they read it. Super Mario RPG (talk) 15:31, October 23, 2024 (EDT)
Why do you say it "isn't our role" and "we are a wiki on Super Mario" as though we're putting criticisms of other wikis in mainspace? This is a proposal about limiting what people can say on discussion pages. "We", the Super Mario Wiki, don't criticise other wikis at all. Individual people might in discussions where it's relevant, but they don't speak for the whole wiki. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 15:32, October 23, 2024 (EDT)
I didn't mean to suggest mainspace. I was trying to suggest, for example, "being concerned over how Kingdom Hearts character pages look on the KH Wiki shouldn't be a concern of this wiki as a whole. Super Mario RPG (talk) 15:35, October 23, 2024 (EDT)
As I said though, it's not a concern of this wiki as a whole. It might potentially be brought up by a user on a discussion page if it was relevant in some way, but that user doesn't speak for "this wiki as a whole". Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 15:39, October 23, 2024 (EDT)
Criticizing another wiki could be tantamount to saying how we want them to do things. What if our wiki was the recipient of such a remark from one of our affiliates? Super Mario RPG (talk) 15:45, October 23, 2024 (EDT)
I don't see such criticisms as coming from "the wiki" or "us", they come from individual people who, once again, don't necessarily speak for the whole community of the wiki they happen to edit on, and don't necessarily speak against the whole community of a wiki they happen to have an issue with. There's nothing wrong with individual people having or expressing their own opinions. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 16:22, October 23, 2024 (EDT)

@Hewer Does the courtesy policy mention being rude to people on this wiki or in general? Super Mario RPG (talk) 15:31, October 23, 2024 (EDT)

It only explicitly talks about people on this wiki, but it's common sense that you shouldn't be rude to people on other wikis either. I don't agree with characterising any criticism of another wiki as being rude to that wiki, though. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 15:39, October 23, 2024 (EDT)

@Nintendo101 It's okay if you oppose, of course, though I updated the title of the proposal to get rid of the suggestion that this wiki is aiming to ban good-faith criticism. Super Mario RPG (talk) 15:49, October 23, 2024 (EDT)

While appreciated, it does not seem like the aims of the proposal have shifted. If the goal is to ban "bad-faith" criticism, then I don't feel like any of the examples provided reflect that. The one exception is the comment about WiKirby being a little rude, but it comes from a proposal where all of the other remarks were substantive, so it was really the exception, not the rule. Similar with the remarks about ZeldaWiki's adoption of tabbers. Additionally, our courtesy policies already promote good faith because it is the right thing to do.
In my view, we should not be controlling expression and speech in our userbase. All we ask is that comments are courteous, substantive, good faith, and not rude. Criticism is not in opposition to those aims. I also think criticism is sometimes at its best when it comes externally. If WiKirby were critical of some of the choices made on Super Mario Wiki, I would embrace that, especially since all NIWA wikis share a common set of tools. It's one of the ways we can improve ourselves. - Nintendo101 (talk) 16:09, October 23, 2024 (EDT)

Prioritize sprite/tile uploads that have their original file parameters (or clean divisions of them)

canceled by proposer
This proposal relates to the above, and like it, the only direct change it will bring is an addendum to the image policy.

Most sprites in games are coded so that their parameters are divisible by 8 (though ones that don't follow that exist, particularly in later machines, they are still highly rare). This is due to the same binary-based system that gave us things like "8-bit," to make a long story short it's easier for computers to understand. In sprites, this is not always filled in; for example, you might see a Boo sprite that's only 14x15px filled in rather than 16x16, but that blank space making up the remainder of that 16x16 area is still part of the sprite as it was drawn and programmed in-game. Aside from putting it at the same resolution of the other sprites, odds are the hitbox is still 16x16 pixels, so it still effects the game.

Donkey Kong's icon in Mario Kart: Double Dash!!

If anyone is still confused at what I'm talking about since I am primarily talking in a spriter-based mindset, see the blank areas to the right and top of DK? That is hard-coded in the game's graphic data so it's 64 pixels by 64 pixels, so it is absolutely meant to be there.

Basically, I want to reflect that as much as possible. Aside from the hitbox and resolution thing, this also makes them easier to animate and is just a neat little "visual" bit of trivia that can only be seen by accurately displaying their parameters, including the small amount of blank space some may have. I don't know if it will make it easier for the wiki's storage or not, but if it does, that's an added bonus.

Now, this is not attempting an across-the-board shift towards this; the key is feasibility for each image. An image from an NES game or a mugshot icon for a large-cast game will invariably be simple enough for this, but then there's convoluted things like Roger the Potted Ghost or Air Bag that are mishmashes of distorted sprites and models. There's no way to follow this guideline for them to the letter because of that, and those are hardly the only weird things - or even edge cases - out there. Essentially, if an image can be displayed in a manner that is true to its internal parameters while still resembling how it appears in-game, it's better that it does. If it can't, then just don't worry about it, it's a non-issue. Uploading one that does not follow it is also not an issue, but if a replacement can be uploaded that follows it, then it will have priority. If an image has an utterly ridiculous amount of blank space disproportionate to its size or the size of related images, then it can be cut down to a still 8x8-numbered smaller size if it covers them all; for instance, according to the TSR rip it is sourced from, thisMedia:DKP03 health Donkey Kong.png sprite was from a 64x64-sized tile that only had the graphic in the 16x16 section of the middle. Granted, it may just not have been cut down during development since it was canceled, or that may be artificial on Ragey's part, but the point is that there's a point where it's unnecessary, but there are better ways to deal with it than purely cutting down to the visible portion's size. Additionally, the course map for GCN Dry Dry Desert could be cropped by half while keeping 128px parameters and not affecting the vertical positioning on center-aligned displays (like consistent-sized galleries and table rows), so that is an example of a cropping-to-save-space that does not really lose anything - and the kind that this proposal would still consider within reason to cut down by.

TL;DR: Cutting down big images with large amounts of blank space is fine as long as the final image still has dimensions at a factor of 8x8, as that is generally how tiling and computer systems work. Weird graphics that are assemblies of distorted sprites or inconsistent tilings are not bound by this whatsoever. This is more focused on small sprites, icons, and fractalled textures.

Proposer: Doc von Schmeltwick (talk)
Deadline: November 6, 2024, 23:59 GMT

Support-by-sixteen

  1. Doc von Schmeltwick (talk) - I'm tiled of the confusion
  2. Super Mario RPG (talk) Per proposer.
  3. Hewer (talk) Doesn't hurt to be more accurate to what's official, per proposal.
  4. EvieMaybe (talk) supporting this primarily for smaller 8/16 bit sprites that actually stick to tile rectangles (ie, no DKC). i'm not sure if we should do this on texture-type assets

#PnnyCrygr (talk) I'm supporting this so that we can have consistent display resolutions of sprite. Consistency always is great. Per Doc

Oppose-by-seven

  1. Nintendo101 (talk) I think sometimes the display and formatting demands of our articles entails adjusting the empty space around some assets, and I do not think that is inherently a wrong thing to do. We have animated and assembled sprites to reflect their in-game appearances in ways that do not reflect how the assets are stored in the game's files in order to reflect how they actually look to the player during gameplay, and I view narrowing the empty space around an asset as the same type of revision. If folks truly want assets displayed as the raw materials they appear in the files, without any curatorial adjustments, the Spriters-Resource is available to them. (For clarity, I am not opposed to folks wanting to hang onto the empty space around an asset, but I do not think there should be a blanket rule mandating we "must" do it.)
  2. Waluigi Time (talk) Per Nintendo101. As a wiki, the main reason we have sprites is to illustrate a subject, not to show the hitbox or archive a particular asset exactly as it was programed into the game. Sometimes there's a good reason to have some empty space on an image (all playable character icons being the same size is nice, for example) but other times preserving it is arbitrary or even makes them look worse when in use.
  3. PnnyCrygr (talk) Per all. Best leave the spaces filled especially when theres a great deal of space around the graphic. I have seen Mega Party Games asset dumps of character sprites from my Dolphin, and boy they look small with all that big, wasted space around Mona, Crygor, Kat, etc..
  4. Arend (talk) It's optimal at times, but I don't think it needs to be enforced, especially if there's loads and loads of empty space. Take File:DryDryDesertMap-MKDD.png for example. When I reuploaded the file back in 2023, I decided to crop the thing in a 128 x 128 square (keeping it divisible by 8) instead of keeping the original ratio of 128 x 256, because, quite frankly, at least half of the image's height is empty space. You restored the original ratio because that's how it was stored in the data, hereby recreating the bulk of unnecessary empty space again.
  5. OmegaRuby (talk) Per all. Better to be able to see the contents of an image without having to zoom in and view.
  6. Ray Trace (talk) No. Images such as this and this have been cropped from their original dimensions because the extra space is worthless space. The only reason textures even have blank space like this to begin with is primarily programming-related: back then, it's much easier for computers to compute image dimensions in powers of 8 hence why textures are at resolutions with 8, 16, 32, 64, etc which is not useful for image display purposes on this wiki, and modern computers don't need to abide by these restrictions any more (esp Switch titles, which can have widely varying dimensions in their textures). I do get in certain cases, consistency is key such as the Donkey Kong portrait in Double Dash having minimal amounts of empty space, but for my aforementioned examples, crop to content would serve a much better purpose, leaving this better off using individual discretion wherever to leave empty space or not.
  7. Sparks (talk) Per all.
  8. Jdtendo (talk) Per all, keeping extra space or only cropping to 8x8 tiles is not beneficial to the wiki.
  9. ThePowerPlayer (talk) This is completely empty space that only obstructs the presentation of an image. As Nintendo101 mentioned, The Spriters Resource is the place to find sprites as the game stores them.
  10. Scrooge200 (talk) It's unreasonable to expect uploaders to be able to know the original data-stored parameters of a sprite they upload, given the different ripping methods and how some games might be difficult to rip from. And as someone who usually downloads images from the wiki for projects, I like having them cropped to content.
  11. Mario (talk) There are times where padding space or keeping dimensions the same as ripped helps but in plenty of cases, there's no need to maintain game engine limitations on the wiki. If we are going to insist that a a small sprite in a 128x256 asset of blank space needs people to know it originated in that dimensions officially why not list other properties of an image such as mipmap count or compression being dxt5 (and not rgb888) with a positive boolean value for texture clamp? If a game engine corrects a gamma but the texture itself is actually much darker than it is, should we upload it with an gamma fix or not?
  12. UltraMario (talk) Per all. This is getting insanely ridiculous lately. The space isn't at all needed and the gallery page can just be adjusted to fit the new space.
  13. Sdman213 (talk) Per all.
  14. TheFlameChomp (talk) Per all. It makes to try to keep uploads accurate to the official appearance, but I do not see the benefit of keeping unnecessary empty space.

Comments-by-64

@Nintendo101 - TSR doesn't always have that either, though, and I don't think it's really our place to wholesale rely on other websites for this sort of thing. Besides, this also looks better and makes things easier when using the multiframe and multiple-image templates since the boxes are at a consistent size and both match each other and don't need to have their sizes checked individually when adding the template in. Also, I'd like you to read the last paragraph of the proposal and tell me where that "must" came from. Doc von Schmeltwick (talk) 17:30, October 23, 2024 (EDT)

Again, if folks choose to do that for individual assets or articles, that's fine. But I would not support a blanket rule. Speaking for myself, I have put a lot of careful thought into how sprites and models are displayed on things like Template:Icon or the tables for the mainline games. The removal or presence of space around an asset is largely deliberate, and is part of the curatorial craft of presenting information. I know I would find contributing to the site a lot less enjoyable if I had to undo much of that work for something like this. - Nintendo101 (talk) 17:37, October 23, 2024 (EDT)
Again, where are you getting the idea of a "blanket rule?" The proposal says that this is done case-by-case, doesn't need enforced, and involves no punitive measures. It's more of a general suggestion. Doc von Schmeltwick (talk) 17:41, October 23, 2024 (EDT)
I guess I just don't understand why this proposal was enacted, or how it would be substantively realized if it passes, if it does not necessitate any actual changes. From your perspective, how would things be different if the proposal were to pass? What would actually happen that is different from how things are handled now? If I uploaded a sprite that was narrowed to the visible parts of a sprite with deliberate intent, and it was replaced with a version that retained the empty space around it with this proposal cited, would I have the freedom to change it back? Because if that is the case, then it does not really seem like this proposal is very necessary unless we had a rule that insists we "must" crop to content. To the best of my knowledge, a rule like that isn't on the books. - Nintendo101 (talk) 17:50, October 23, 2024 (EDT)
Again, they would be prioritized so they'd be reverted to the non-narrowed version, but this isn't a call to enact a sweeping change. This is more to clarify if that should be done. As a sprite-ripper, I think it absolutely should. Doc von Schmeltwick (talk) 18:02, October 23, 2024 (EDT)
So for clarification, I would not have the freedom to change it back if this proposal were to pass? - Nintendo101 (talk) 18:04, October 23, 2024 (EDT)
Why would you want to? What benefit does 14x14 have over 16x16? Doc von Schmeltwick (talk) 01:03, October 24, 2024 (EDT)
Because sometimes retaining the empty space around a sprite knocks it out of alignment with other assets when displayed in a table, gallery, or template (or renders it completely unusable for something like a template), and because the visual material we have is meant to be illustrative it seems needless to retain that when there is nothing visual informing the reader. I value the freedom to exercise discretion, and I suspect I am not alone in that. - Nintendo101 (talk) 13:04, October 24, 2024 (EDT)
That empty space is the alignment, though. And I have yet to see a 16x16 image become less useful for a template or table than an artificially shrunk 14x14 one - if anything, consistent image sizes make that easier because they don't cause table cells to become inconsistently sized (AKA OCD's biggest nightmare). Doc von Schmeltwick (talk) 13:50, October 24, 2024 (EDT)
In your view, it is alignment. For others, it may not be and that is not inherently invalid. If you want examples, I can point out that Template:Icon was developed to integrate icons alongside text, similar to Template:Button and Template:World, and so it is important that those icons match the same scale as text. That is not always possible if the surrounding space is retained, rendering icons smaller next to text than they should be. There are sprites displayed alongside artwork and models for subjects in the Super Mario 64 and Super Mario Odyssey articles, and they are all unified to be displayed at 100x100px resolution for unified display. If some of those assets were amended to retain the empty space around them, they would needlessly be display at smaller size than the subjects around them. But fundamentally, I do not think I needed to have provided any examples of why. My point is that users should have the freedom to exercise discretion, and I don't think that should by taken away.
You may say this is not a "sweeping change." To you, it may not be. But if I (or anyone else) cannot retain an asset displayed at specific dimensions, regardless of the reason, because of this proposal (which is the impression imparted from our exchange here), then I think it has bigger ramifications than you say and I don't think it is something I could support. I would feel similarly of a proposal that mandates we "must" crop to content, because I don't think users should be hamstrung to things like that. - Nintendo101 (talk) 14:26, October 24, 2024 (EDT)
If you look at my conversation with Arend below, I explain some more examples of "good" types of discretion, like with maps where they're still in 8x8 multiples and the vertical positioning is kept. Meanwhile, platformer sprites in a grid-based game (so basically any Super Mario Bros. or Super Mario Land game) do not need to be cropped down to below their smallest raw amount unless there is a literal fully blank tile involved. For instance, I cannot see any benefit provided by this changeMedia:SML2 Sprite Cannonball (Space Zone).png. It may be your discretion that it made sense to do, but it's my discretion that it helped nothing and should be changed back. As such "discretion" is not really a good argument to say that the current system (or lack thereof) is better. I wouldn't use this to enforce anything involving the DKC or DKL games (like Evie said), because their sprite tiling is all over the place and inconsistent even within the same animations, but those are the exceptions, not the rule. Doc von Schmeltwick (talk) 14:48, October 24, 2024 (EDT)
I noticed the SML2 cannonball sprites looked smaller than their neighbors in Gallery:Cannonball when I included them on the page, and I thought the size uniformity would look nicer. That was the only reason I cropped to visual content, and I think that was substantive and harmless because it did not compromise the asset. If you did not like that, there was nothing stopping you from reaching out to me.
I don't think you have really said anything yet that has made me feel more comfortable with this proposed policy revision. This is a communal craft and space. I still do not think users should be hamstrung and should have freedom to exercise discretion. - Nintendo101 (talk) 15:59, October 24, 2024 (EDT)
And again, my discretion is the opposite of yours, so that's another issue with just saying "keep it as available to discretion," because that could lead to its own endless series of debates. In regards to this, though, remember the "rawsize" proposal. That combined with this should solve both issues that gallery might have. Doc von Schmeltwick (talk) 16:31, October 24, 2024 (EDT)

@PnnyCrygr - "If an image has an utterly ridiculous amount of blank space disproportionate to its size or the size of related images, then it can be cut down to a still 8x8-numbered smaller size if it covers them all" Doc von Schmeltwick (talk) 18:32, October 23, 2024 (EDT)

@Arend - The issue there is that for the gallery to work right the images - all the same ratio in the data - need to be at the same size. If they were all different anyway (like MK64's maps), that edit wouldn't have been an issue, but since they are all equivalent in size, the gallery ought to reflect that. Doc von Schmeltwick (talk) 12:20, October 24, 2024 (EDT)

The MKDD map sprite galleries all seem to be preset with widths=128px heights=256px anyway, meaning that the galleries wouldn't suddenly change size or look all wonky: the worst that could happen is if the original image was off-center and that being no longer reflected, but I don't recall that being the case with Dry Dry Desert's map (even then, the maps being off-center was something I tried keeping in mind when cropping them). And in my upload, the width was unchanged anyway, too. ArendLogoTransparent.pngrend (talk) (edits) 13:25, October 24, 2024 (EDT)
Well I mean, I guess as long as the height's not off-center, there's no harm, no foul, as long as it doesn't screw up the course tables on the main page. I've gone ahead and reverted it and the similar ones; that's an example of a "good" crop, akin to the Diddy Kong Pilot icons or the Count Down background. Doc von Schmeltwick (talk) 13:42, October 24, 2024 (EDT)

Abstaining for now, but we wonder if there should be like, an option for a more case-by-case approach; NES and SNES games get the full aspect ratios, but N64 onwards are fine to crop. Or, alternatively, NES, SNES, and N64 get the aspect ratios, and the GameCube is the cutoff point. ~Camwoodstock (talk) 13:16, October 24, 2024 (EDT)

The current one is intended to be case-by-case; see the discussion I had with Arend above. Doc von Schmeltwick (talk) 13:45, October 24, 2024 (EDT)

@Ray Trace - Again, note the thing about the MKDD maps. As long as the result is accurate to the 8x8 tiling, it's a non-issue to remove that amount of empty space. This focuses on small amounts of empty space. Doc von Schmeltwick (talk) 16:32, October 24, 2024 (EDT)

@ThePowerPlayer - And as I mentioned, TSR doesn't have them in most rips, particularly older ones. We shouldn't rely on other sites, and I fail to see how a row or two of pixels obstructs anything. Doc von Schmeltwick (talk) 13:51, October 26, 2024 (EDT)

One thing I do want to ask the opposition: if we obtain an asset, wouldn't it be more accurate, or dare I even say honest, to portray it exactly how it was made or displayed, without cutting it down? The obvious exception being music due to the legal issues those could cause. Doc von Schmeltwick (talk) 18:45, October 26, 2024 (EDT)

Not in my view, because we (or at least I) upload assets for people to look at them, and the empty space around an asset is invisible. - Nintendo101 (talk) 19:16, October 26, 2024 (EDT)
I believe that it acts as a sort of "visual trivia" to them that can't really be explained in words, but isn't hurting anything to include in some capacity. It also does marginally affect gameplay visuals particularly in older games, where only a certain number of sprite tiles can horizontally overlap at once before they start disappearing - and that includes blank space overlapping and causing actual visible pixels in other sprites to start disappearing. Doc von Schmeltwick (talk) 20:16, October 26, 2024 (EDT)

@Scrooge200 - as I said, prioritize, not outright ban uploads that don't have them. As previously stated, there are no punitive measures involved (also several fan projects, notably fan animations and fan games, would be better served with the space there - the main reason I haven't animated the Mario Power Tennis audience, for example, is the sprite rip on TSR lacks that spacing completely, so I have no idea how they cleanly go together). Doc von Schmeltwick (talk) 11:09, October 27, 2024 (EDT)

@Mario - Imitating in-game corrections is fine on both counts (though there's no reason both can't be uploaded in separate capacities, as some are simply results of ambient lighting; plus, ones with normals applied in-game should obviously have said normals applied on here, and that currently takes priority over ones without the normals - like the NSMBU-styled SMM sprites - so I don't see why this shouldn't too). This is strictly for x-y parameters. Doc von Schmeltwick (talk) 13:07, October 27, 2024 (EDT)

I don't think so, it's just recommended we include a gamma fix via Switch Toolbox or something similar so you know the asset has been color corrected. I don't think normal maps (normals themselves are a component of a model; normal maps govern how light interacts with red and green channels of this map is put on a model) are same deal as a texture dimension especially for a UI graphic this proposal focuses on. As stated, these textures are in particular dimensions due to design constraints, vs normal maps which are intended to be applied on top of an asset. Normal maps drastically change how an asset looks, not so much with padded space around a texture, in my opinion. Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 20:50, October 27, 2024 (EDT)

On the proposal above this one, there seems to be a general consensus that we should do things more as TCRF does them, since they're documenting which specific tiles are unused. This proposal would also align with that as they also use full tiles.... as do most of our "unused sprite" rips. It seems odd to hold the unused sprites to a higher standard than the used ones. Doc von Schmeltwick (talk) 02:03, October 28, 2024 (EDT)

Going ahead and cancelling, since I considered to myself that this would technically cover the in-game "artwork" for MKT and the spirits in Ultimate, both of which are ridiculously large and can't be shown at raw size on a gallery page anyway. Doc von Schmeltwick (talk) 12:56, October 28, 2024 (EDT)

Remove all subpage and redirect links from all navigational templates

Remove the extra links from navigational templates 9-0
Navigational templates are one of this wiki's best features. They're a really convenient way to get around the wiki. However, one common pitfall of the templates is bloat, in particular in the form of links to subjects that do not have dedicated articles. I have previously made a proposal about this subject specifically in the context of the Super Smash Bros. series, but the problem extends to navigational templates across the entire wiki.

In principle, navigational templates should be directories of articles on the wiki. What advantage does it give the reader for Template:WWMI to have a whole section dedicated to eighteen separate links to subsections of Form Stones on top of a link to the main article itself? Why does Template:Humans link to all seven individual members of List of show hosts in All Night Nippon: Super Mario Bros. individually? Does the already crowded Template:Super Mario games really need to use precious space on a link to a two-sentence section about a theoretical game that Elon Musk claims to have failed to have pitched to Nintendo?

I propose that, across the board, all subpage and redirect links on all navigational templates should be either removed or replaced. (Red links are relatively fine, as long as the things they don't link to theoretically should be articles that just haven't been made yet. Edge cases like "Unnamed Worlds A-C Human" should be decided case-by-case in the relevant talk pages.)

Proposer: JanMisali (talk)
Deadline: October 31, 2024, 23:59 GMT

Remove the extra links from navigational templates

  1. JanMisali (talk) As proposer.
  2. Hewer (talk) To be honest, the main reason I'm supporting this is because I hate how cluttered Template:Super Mario games is with useless links, and this would help solve that problem. We don't need to list every single game to ever have been pitched there.
  3. Camwoodstock (talk) This makes sense to us. It's much easier to just list a page link once and only once.
  4. OmegaRuby (talk) Per all.
  5. EvieMaybe (talk) per all
  6. ThePowerPlayer (talk) When I think about it, it's an extreme stretch to e.g. list Mario Chase on the list of Super Mario games just because it was a reworked demo, or to give real estate to Mario's Castle, a concept so nebulous that it is covered by a list article in a grand total of two sentences. I feel more ambivalent about entries that are clearly their own games, such as Dokidoki Mario Chance! or Reflex Rally, but those could be split on a case-by-case basis if necessary.
  7. SeanWheeler (talk) If we're not allowed to link redirects, how could our templates have redirect links?
  8. Jdtendo (talk) No need to clutter navboxes with useless links.
  9. DryBonesBandit (talk) I was always annoyed by this. Per all.

Do nothing

Comments

Wait, that ANN thing is a page? I was unaware. Doc von Schmeltwick (talk) 18:51, October 17, 2024 (EDT)

A page that's linked to on nearly 900 (!!) other pages! But since those links are hidden in a big bloated alphabetical list of characters (only most of which have actual articles), it's not nearly as visible of an article as it otherwise would be. jan Misali (talk · contributions) 19:09, October 17, 2024 (EDT)
When I made that proposal not too long ago on that game, my idea was a page for each since they're all based on real people and look different despite having the same role (like the people in Mario is Missing and the NES Mario's Time Machine). Doc von Schmeltwick (talk) 19:13, October 17, 2024 (EDT)
That sounds perfectly reasonable. If/when those dedicated articles are created, then including links to them in Template:Humans would make sense. As it stands now, of course, linking to one list article several times is just messy and unhelpful. jan Misali (talk · contributions) 19:20, October 17, 2024 (EDT)

Speaking of that "Unnamed Worlds A-C Human", has anyone attempted a thorough search through the history of All Night Nippon to identify the guy? As I said on the relevant talk, I assume it's also a radio host, since all the other Toad replacements are hosts as well, but I can't say with certainty (might as well be a higher-up at Fuji TV) ArendLogoTransparent.pngrend (talk) (edits) 18:13, October 25, 2024 (EDT)

Prioritize MESEN/NEStopia palette for NES sprites and screenshots

prioritize MESEN/NEStopia palette 13-0
I want to preface this by saying this proposed change will NOT be a one-person job to go back and change all instances of uploaded images. This will be more a general guideline going forward, and a thing anyone who wants to help can do without feeling like it might be unnecessary or unwanted. If this succeeds, the only immediate change needed to be considered "put into effect" is an edit to the image policy, though there will probably be a lot of quality tags for blatantly off colors.

For context of this, the NES and the Japanese FamiCom/Disk System do not have a "native" hard-coded palette. As such, different machines display different colors. However, a majority of contemporary televisions in the NTSC region (which includes both Japan and America, so where the FamiCom and the NES were initially respectively developed - sorry PAL pals) would display them with a particular muted palette. Many early computer-based emulators instead displayed an extremely bright palette with colors that tended to clash with each other, which is still present on many old images on the site. Even a few today are like that, such as FCEUX, which while great for ripping tiles, has a very odd color display.

MESEN and NEStopia are NES emulators that display that more "accurate" (for lack of better term) color. It is widely recommended by sources such as The Spriters Resource and The Cutting Room Floor as a good way to ensure color consistency. Even Nintendo themselves seems to prefer its colors, as official emulators like the Nintendo Switch Online use that type of palette. I think we should start prioritizing it going forward as a general rule so there's more consistency to the uploads color and quality.

For an example of what I am talking about, see the upload history for File:SMB Goomba Sprite.gifMedia:SMB Goomba Sprite.gif. A lot of the fixes have already been historically done; I myself worked a lot on the Famicom Grand Prix and Golf series images. Most of what's left are random images in larger platforming games as well as assorted more obscure games (looking at you, Wario's Woods), as well as newer uploads from people using older sources without realizing or caring about this issue (which is the main thing this proposal hopes to address).

(As a side note, I spent yesterday evening collecting the NEStopia colors for Super Mario Bros. 2 by playing through the whole game and applying them to the pre-existing level maps (which were ripped originally in one of those odd bright emulators), so assistance with applying them to the innumerable screenshots, sprites, and animations for the game would be greatly appreciated.)

Proposer: Doc von Schmeltwick (talk)
Deadline: November 3, 2024, 23:59 GMT

Supportopia

  1. Doc von Schmeltwick (talk) - De vunderbar vald of color. CoRRECT color.
  2. Nintendo101 (talk) I think utilizing a unified palette is a smart idea. It would look nice, unified, and would mitigate potential confusion as to how colors differ between subjects.
  3. Camwoodstock (talk) The weirdly vibrant colors are a rare FCEUX L, as far as we're concerned, and it'd be nice to have some guidelines in place to encourage consistency.
  4. SolemnStormcloud (talk) Though my Mega Man-brained self prefers the FCEUX palette in the context of that series due to MisterMike's sprite rips as well as it being the basis of Mega Man 9 and 10's palette, this isn't a Mega Man wiki, so per all.
  5. ThePowerPlayer (talk) It's better to use the most accurate colors to the original output, to match the accuracy of the resolution of game screenshots.
  6. LinkTheLefty (talk) TCRF standards FTW.
  7. Killer Moth (talk) Per all.
  8. EvieMaybe (talk) it's worth noting that CRTs and LCDs display color differently, so a direct rip of what the nes displays to an LCD might not be properly accurate. however, if both TSR and TCRF recommend it, then i have to defer to their opinion
  9. wildgoosespeeder (talk) I have had Mesen as a mention for years. It has the highest accuracy I have ever seen in an NES emulator. However I have always treated it as a fallback option to FCEUX. Reason being TASVideos.org availability. There is a section on TCRF about applying the correct color pallete when using FCEUX.
  10. Mario (talk) I suppose there's no way to have all monitors display the exact colors uniformly, might worth documenting the colors.
  11. ThatOneSuperCircuitGuy (talk) Looking at the color pallets between FCEUX and a real NES, the color pallets are slightly brighter compared to a real CRT. I'm glad that the Delta devs use the correct pallets. (I think)
  12. Pseudo (talk) Remaining as accurate as possible to the original games should probably be prioritized.
  13. SmokedChili (talk) Should have made it clearer in the first place the palette in question is based on YUV palette aka 15° Canonical. Per all.

Opposeux

Commesents

Here's the source on The Cutting Room Floor's preference for the MESEN/NEStopia palette, in case anyone needs it. Sorry if it's unnecessary, but I think the claim of the other websites' stances could've had links provided. SolemnStormcloud (talk) 15:47, October 20, 2024 (EDT)

Thank you, now I can actually use FCEUX without needing to back-and-forth between emulators. Maybe I can get back into U.S. Course's prize card again... Doc von Schmeltwick (talk) 16:01, October 20, 2024 (EDT)

@SolemnStormcloud - Not to gossip but FR MisterMike'd be the best NES sprite ripper ever if not for exclusively using FCEUX palette. His Zelda 1 rips were... eyebrow-raising, to say the least, which is part of what inspired me to prioritize the NEStopia palette. Doc von Schmeltwick (talk) 15:58, October 20, 2024 (EDT)

@EvieMaybe - Note the "closest to contemporary NTSC display" thing, so that'd be close-to-CRT. Doc von Schmeltwick (talk) 00:16, October 22, 2024 (EDT)

makes sense! i figured that by "contemporary" you meant an LCD or an OLED, thanks for clarifying EvieMaybe (talk) 11:12, October 22, 2024 (EDT)

Encourage concise, consistent and minimalistic layouts and design for tables

Encourage 19-7
Tables in game articles are a total playground. Overall, they often are as inconsistent and showy as they can be, and are often laid out in such a way that it makes them worse to read. Some are more extreme than others, like driver and track tables in Mario Kart articles, such as this and this. Those ostentatious charts look like they belong in a promotional website rather than in an encyclopedia, and do not prioritize ease of reading and data relevancy. Some are not all that exaggerated, but still look over the top, overstyled and are more spacious than they need to be. Maybe people think it is more fun to design them like that, but they look unprofessional.

That being said, these are the points I judged good ones to encourage when it comes to creating tables:

1. Uniformly use plain wikitable style for regular tables. Pages often use several styles for tables for no reason (the article for Paper Mario: Sticker Star uses four styles throughout, here, here, here and here). The wikitable style is pretty standard, so it makes sense to use it consistently.

2. Prefer to lay out table data in simple rows. If the table data fits well in a "one entry per row" format, do it, rather than attempting to use more elaborate, arbitrary layouts. Some examples of such arbitrary layouts are this table, which is laid out like it is a grid of infoboxes, and this set of tables. If you judge it wouldn't work to make a table fit that minimal layout, try making it the closest possible to it. Although arranging entries in columns may work in some cases, prefer to have each subject as a row, as that preserves the reading direction, arranges the related data more properly in the HTML, and allows the table to be sortable if needed.

3. Avoid using images of text in lieu of actual text. This is often done for the name of the subject, and it is purely for decoration purposes. Cases include Mario's name and stat names here and board names here (notice that the images in those examples are not there for mere visual reference, as they replace links; the editor likely wanted to add some flavor to the table). It makes the text less straightforward to read, in some cases duplicates it, because normal text is used alongside the image. Another common occurence is using images of stars or other icons to represent scales (such as "X out of 5 stars" scales), when you could use standard star characters (★ and ☆) instead. That does not mean to never use images instead of text, only consider whether it is worth it or not. For example, this is a good use of images replacing text because writing the names for each driver and part as text would make it harder for the reader to quickly find the desired info.

4. Avoid using more images than necessary to illustrate the subject. This is also often used for decoration and visual effect. As an example, playable character tables in sports games articles (such as this and this), where the playable characters' table entries often include both an illustration of the character and that character's in-game icon (which is just the character's head graphic), which is redundant (if I already have an illustration as visual reference for the character, an icon showing the same thing is unnecessary, and vice versa). This is a specific example but that happens with other kinds of tables, like the Mario Kart 64 track table featuring both an image of the track and the track's thumbnail. Consider whether adding extra images actually make sense or if it's just filler.

5. Avoid decoration in general, such as coloring text and cell backgrounds. Take the colored table here for example. As I said before, it is more about the visuals than the info, and it looks like some sort of promotional material. Instead, save coloring text and table cells for cases where it aids in reading data in some way.

Notice I've been proposing for these guidelines to be encouraged rather than enforced because some of them depend largely on the judgement of the editor.

Proposer: Bro Hammer (talk)
Deadline: November 6, 2024, 23:59 GMT

Support

  1. Bro Hammer (talk) Per my proposal.
  2. Waluigi Time (talk) The only thing this proposal is missing is encouraging tables to be horizontally aligned in accordance with web design standards, but otherwise, pretty spot on. I think a little visual flair with coloration is okay, but since this is more of a guideline to be encouraged, I'm fine voting for this as-is.
  3. Nintendo101 (talk) I will say, I have used colors for some of the tables I have crafted for the mainline series articles I have worked on, but it is always with illustrative intent. When all the tables in an article look indistinguishable from one another, it can sometimes be easy to lose one's place or not easily understand how some bits of information relate to others. But otherwise, I thinks these are great guidelines and they have my support.
  4. Camwoodstock (talk) Per all, especially Nintendo101; color has a time and a place, but stuff like the SM3DW character chart just kinda feels like a meld. That's not to say we should be replacing everything with the dull greys, of course, but we should probably dial it back at least a little bit. No real objections to the other parts, we should probably standardize as best we can.
  5. Ninelevendo (talk) I just don’t like what’s been done to the Mario Golf: Toadstool Tour character table so whatever it takes to fix that.
  6. Koopa con Carne (talk) per all
  7. Lakituthequick (talk) Per proposal and per WT – I have indeed commented a few times on tables and how they should be used for tabular data (more notably for Mario Kart Wii), and this proposal will start enforcing tables to do that.
  8. Cadrega86 (talk) Wholeheartedly agree with all your points. These tables are over-designed and often include superfluous information (e.g. the track table in the Mario Kart 64 page, why don't we also add staff ghost times and future appearances while we're at it?)
  9. Shy Guy on Wheels (talk) Per all.
  10. SolemnStormcloud (talk) Per all.
  11. EvieMaybe (talk) per Camwoodstock and Waluigi Time
  12. TheFlameChomp (talk) Per all.
  13. MCD (talk) Per all.
  14. Sparks (talk) Per all.
  15. Fun With Despair (talk) Per all. Information should remain accessible and easy to reference, and tables utilizing images instead of easily transcribed or copied text are the opposite of that.
  16. PnnyCrygr (talk) Per all; MarioWiki is not a fansite, it's a wiki! A wiki's tables should therefore be formal and not unconventionally designed.
  17. ThePowerPlayer (talk) Per all. Table design on this wiki has bothered me for a while, and these guidelines are a great solution.
  18. Mario (talk) Current tables are too cluttered with information and are quite hostile to editing. This is a case of less is more imo.
  19. SmokedChili (talk) Per all.

Oppose

  1. Tails777 (talk) I can agree that there should be a bit more consistency and organization on when and where to use certain elements for a table, but I also believe in making tables both informative and entertaining to look at. I see nothing wrong with using board logos to represent names for some of the earlier Mario Party boards that had them or using colored backgrounds on tables (something I've already supported). And while I can agree that some of the Mario Kart related tables are a bit all over the place, I believe we could take certain similar cases (tracks, boards, statistics, etc) and maybe make guidelines for each based on the topic. I get that this isn't outright enforcing the outage of these elements, but I don't really think we should actively enforce minimalist designs for tables, rather deciding what to do on a more case-by-case basis.
  2. Doc von Schmeltwick (talk) - As the person who made many of the more "showy" ones, I'm kinda societally obligated to oppose this as a matter of course. I can't let my MS in CS with a few classes on advanced web design/web app programming and an undergraduate Minor in Art go to waste and I find it more engaging and explanatory as to the different aspects of whatever entity is being described to have both an in-game graphic and either an artwork or a screenshot. Stat bars and star-bubble fill-in charts with color-coding are also a lot more immediately understandable than numbers alone. To quote Bowser, "Haven't you heard? A picture's worth a thousand words." (People also generally seem to approve of my tables for the Golf games...) Anyways, I'm not gonna make this a big to-do, since I still can be beautiful on my own page, but I still think it looks and functions better than a schedule-looking list with inconsistent image resizings and row heights.
  3. OmegaRuby (talk) Per all. Some consistency between tables in articles would be nice, but I feel the rules this proposal would put in place are a bit too much. I mean, we did recently pass a proposal allowing colorful tables again.
  4. DesaMatt (talk) Per all. While consistency is good, there's a point where it becomes unnecessary and repetitive, and in my view this is that point. Also, I disagree with the idea that MarioWiki isn't a fan site. It will always be a fan site as long as it's not officially affiliated with Nintendo and is operated by fans.
  5. Scrooge200 (talk) I actually really like the trend of giving games uniquely stylized tables, it helps give them a bit more personality. All the information is there and you can still read it effectively. I think I worked on some of the modern Paper Mario tables, and nobody seemed to have a problem with them until now.
  6. Hewer (talk) Per all.
  7. Salmancer (talk) Colored backgrounds are too much (as in, the ones where each entry has a different background), but I think there's a time and place for non-standard tables, so I wouldn't want a blanket ban.

Comments

@Tails777 Using images as a substitute for text is very poor for accessibility and searchability with ctrl+f, though. --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 22:08, October 23, 2024 (EDT)

True and perhaps I can agree to not substituting text with images. But I still stand by what will be my main point: tables can be presentable and professional without being a bore to look at. I still see nothing wrong with colored tables at the very least. Sprite of Yoshi's stock icon from Super Smash Bros. Ultimate Tails777 Talk to me!Sprite of Daisy's stock icon from Super Smash Bros. Ultimate

With regards to colours and visuals as is most often used as a counterpoint: I believe those are strictly speaking less important than being informative and clear, but I do love myself tables that look good as well. I can see a future proposal to establish some generic reusable table styles and colours for specific purposes. To take one back a while, Walkazo did just that for navigation templates, which, with updates, resulted in this chart to be created, still in use today. The 'Shroom for instance also features its own table styles which are pleasant to look at, and which use colours that match the page's theme. Lakituthequick.png Lakituthequick 08:41, 24 October 2024 (UTC)

I'm staunchly against using the fugly ass gray and grayer tables across all articles and I'm definitely perring LTQ's suggestion for themes. I like the red header in the Super Mario World article and the green header in the Yoshi's Island article, it's deliberately done to match the nav templates the articles use and I'd be in full support of making tables be consistent with that. BabyLuigiFire.pngRay Trace(T|C) 15:51, October 24, 2024 (EDT)

There are a ton of tables on here that use STRONG, EXTREME colours in attempt to look flashy but just end up being really hard to read, and I think above all else those need to go. Colour should be used very sparingly. I came across this recently looking at the MK8 Color Scheme tables for Standard Kart and Standard Bike. When you see things like Pink, White, Medium yellow, Yellow, Chartreuse, Light-gold, light-gold and especially Inklings, it's murder on the eyes... Shadow2 (talk) 04:45, October 24, 2024 (EDT)

Hmm, would it be acceptable if we kinda did what Inkipedia does with ink colors, and have a colored square show before the color terms? ArendLogoTransparent.pngrend (talk) (edits) 12:31, October 24, 2024 (EDT)
e.g.   Pink,   White,   Medium yellow,   Yellow,   Chartreuse,   Light-gold. ArendLogoTransparent.pngrend (talk) (edits) 14:55, October 24, 2024 (EDT)

@OmegaRuby the guidelines stipulate to "save coloring text and table cells for cases where it aids in reading data in some way." The colors used on those tables provide quick distinction between New Super Mario Bros. U and New Super Luigi U, so I don't think they would be impacted by this proposal. - Nintendo101 (talk) 11:32, October 24, 2024 (EDT)

I hold my opposition on the idea of any tables not being colorful at all, regardless if it assists reading data or distinguishes things - like I said, while I believe there should be consistency in tables in wiki articles I do not believe more bland, grayscale tables should be pushed when adding a dash of color or an image representing a subject doesn't exactly harm readability if implemented correctly. I do know that the proposal pushes for encouragement towards this sort of standard, but I feel as if even the simple suggestion will sway many editors into setting this as a standard. I am also personally a fan of the pretty tables Doc has made, but looking at them from a readability standpoint I do know for sure they're a little too flashy and would hurt specifically the mobile wiki experience.--Small Luigi doing the V-sign in the Super Mario All-Stars remaster of Super Mario Bros. OmegaRuby [ Talk / Contribs ] 08:28, October 25, 2024 (EDT)

@Doc von Schmeltwick I question why exactly you keep bringing up the fact that you have a degree in web design and art in each of these table proposals as though it serves an argumentative point. I do not feel as though it tends to add much to the conversation, nor do I feel that anyone cares. Obviously it is good to have a level of professional training in a subject, however it comes across less as a point in your favor, and more as something you choose to flex whenever anyone disagrees with you on the matter of these tables, which hurts your arguments if anything. Personally as someone who uses a wiki, I would prefer information be conveyed in a simple manner across all the devices I use, and I would prefer that information be accessible and easy to reference in text form - which images hinder. I don't really care if someone with a degree says otherwise, because I know what I prefer - and many members seem to prefer the same thing with regards to simplified tables. Just bringing up your degree as an argument and excuse to ignore feedback does not make people impressed, just annoyed and like they're being talked down to when art is a completely subjective field to begin with. --Fun With Despair (talk) 15:05, October 24, 2024 (EDT)

I say that because it illustrates why I'm this weird combination of artsy and HTML-based in what I do, not to act high-and-mighty. As well as my massive inferiority complex coupled by my inability to get a job due to the current job market, I need to have something going for me or I'm worthless - and I need to do something with that training or it was all a waste of time, and I don't want to have wasted 7 years of my life. I don't think it's important or authoritative by any means - that's the reason it's shrunk. Also I like pictures. Doc von Schmeltwick (talk) 15:08, October 24, 2024 (EDT)
Doc, I say this with earnest respect for the struggle to find a job and an understanding that there are difficult times in our lives during which we may lean more heavily on external sources of validation, such as our accomplishments and creations, as founts of our self-worth. I also say this recognizing that, to some degree, there may be a bit of tongue-in-cheek exaggeration in your previous response. While I think it is commendable you have the self-awareness to recognize that some of your pointing to your degree again and again in these discussions arises from your struggles to land a job in an oversaturated market and the effect that has on your own perception of the effort you put into acquiring your degree, it would be prudent to further reflect on why it serves neither yourself nor the wiki to let those struggles color your decisions and discussions regarding wiki policy, and thus why it might rub others the wrong way to have the point repeated.
There is nothing wrong with taking pride in the work you have done for the wiki. As I understand, you have done a great deal. It doesn't serve you, however, to rely upon that work - especially any single element of it - to seek validation of your major decisions in life through that work. The nature of a wiki is collaboration and change. If not in the near future, if not through the decisions in this proposal, at some point the tables you have contributed to will change, whether it be because the collective aesthetic sensibilities of the userbase have changed, or because of a technical update necessitating it, or because someone sees an opportunity to add further information, or for any number of reasons. Staking the value of your degree to tables bound to change is building an edifice of sand by the ocean and expecting it to stand for years. Don't tie the value of your degree to transient projects; find the intrinsic value of your degree, such as the knowledge you gained in pursuing it, and use that to bolster your perception of it and yourself.
Further, while perhaps useful as additional context to other wiki editors explaining why your degree is so often referenced, this response also indicates this is not something which is actionable to other wiki editors. A self-described "inferiority complex" is a personal matter which only you can address, and the general wiki editor is not equipped to help you in this respect. If this is the driving factor behind your position, you may need to reevaluate whether it is truly germane to the best interests of the wiki.
So as not to stray too far off-topic, ultimately, I want to acknowledge that this is not necessarily your only reason for opposing this proposal and plainer tables, and it does not in any way invalidate or impact your other points. It is only a word of advice. You have shown the self-awareness to acknowledge what drives you to mention your degree; extend that thinking and see why, then, that is not relevant and should not be relevant to decisions and discussions on wiki policy. Hooded Pitohui (talk) 16:33, October 24, 2024 (EDT)
Thanks. Again, I used small text to display it as not-too-relevant in the grand scheme of things but part of my basis. Doc von Schmeltwick (talk) 16:36, October 24, 2024 (EDT)

As I said on the MarioWiki Discord, "i do believe practicality of a table should prevail over the aesthetics of a table. that way, the table can be easier to comprehend. the tables as of right now look more like they belong to a fansite [...] stop all these gaudy, garish tables". Don't click Penny PnnyCrygr User contributions 21:50, October 24, 2024 (EDT)

To be fair, this is a fansite. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 04:20, October 25, 2024 (EDT)
Example
Entry Name Value A Value B
First entry First name 1A 1B
Second entry Second name 2A 2B
Third entry Third name 3A 3B
Fourth entry Fourth name 4A 4B
Entry Description Another value
A This is the description A for the first entry. 1A
B This is the description B for the first entry. 1B
C This is the description C for the first entry. 1C
Entry Description Another value
A This is the description A for the second entry. 2A
B This is the description B for the second entry. 2B
C This is the description C for the second entry. 2C
Entry Description Another value
A This is the description A for the third entry. 3A
B This is the description B for the third entry. 3B
C This is the description C for the third entry. 3C
Entry Description Another value
A This is the description A for the fourth entry. 4A
B This is the description B for the fourth entry. 4B
C This is the description C for the fourth entry. 4C

In my opinion, Wikipedia has an elegant way of dealing with color in tables: they rarely use it for the visuals, but when they do, it just makes sense to have it. Take for example how they present seasons of TV shows in the example. Also, maybe people think that articles would become "too boring" or "too gray" if tables were completely standardized with no decoration at all and whatnot, but that happens because articles overuse tables in my opinion. But that's a different topic. Bro Hammer (Talk • Cont) 11:53, October 26, 2024 (EDT)

These examples are indeed in line with the idea of generic themes I mentioned above. Of course, these examples are still on the tamer side and other styles can be added on top, but it does already look less dull while still maintaining clarity. Lakituthequick.png Lakituthequick 15:08, 28 October 2024 (UTC)

@Waluigi Time Thank you for the suggestion. I wanted to read about horizontally aligned tables being a standard, but I couldn't find anything about it. Do you have a link you can share? Bro Hammer (Talk • Cont) 11:53, October 26, 2024 (EDT)

Unfortunately I don't have a link on hand and wasn't able to find it myself - my knowledge on this admittedly comes from talking to people who are much more well-versed than me - but I've asked Lakituthequick to look into it. For what it's worth, the documentation I've looked at doesn't explicitly say anything about it, but all examples provided are horizontal. In the meantime, a few points in favor of horizontal alignment (in other words, one subject per row instead of per column):
  • It preserves the natural left-to-right reading flow used by the rest of our content. I think screen readers also do this, so a vertical alignment ends up being especially confusing for anyone using one, which isn't good for accessibility.
  • Only horizontal tables can be sorted, since that function works off of the headings.
  • The code is much easier to understand and edit since all the information on one subject is kept together neatly. (e.g. Horizontally, you get Mario grouped with all of his stats in a game. Vertically, you're just left with a bunch of character names, and their stats are scattered in multiple chunks further down the page.) Incidentally, this criticism is what created that "grid of infoboxes" layout you mentioned to preserve the column alignment.
So if I was mistaken on this being an explicit standard, it still seems like best practice, at least. --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 14:22, October 26, 2024 (EDT)
Can confirm this; additionally, web standards are just written in such a way that tables have headers and footers at the top and bottom, respectively (it is worth noting that wikicode doesn't support separating header, body, and footer elements in a table – heck, the parser actively rejects those elements when used directly). In print, this is not so much of an issue. Technically it is probably possible to rotate a table by 90° while maintaining the said pros, but this likely involves throwing a bunch of CSS (hacks) at it that require work to look good in each instance and may not be worth it in most cases. Lakituthequick.png Lakituthequick 15:08, 28 October 2024 (UTC)

Stop considering reused voice clips as references (usually)

Do not consider them references 27-2
More often than not, if you look at a game's list of references to other games, you'll find something about how so-and-so character reuses voice clips from so-and-so game. This has been bugging me for a while because these just aren't references. Nintendo has been reusing voice clips for multiple decades now, so this isn't anything new. When a new Mario Kart game comes out and some of the drivers reuse some wahoos or hurt sounds or whatever else from an old Mario Party game, it's not because the developers wanted to give a nod to that Mario Party game, it's because they had those clips on hand and could easily repurpose them instead of dragging the voice actor back into the recording booth. I propose removing reused voice clips from the references to other games/references in later games lists, with one exception that I'll get to shortly.

For a particularly egregious example, here's all the "references" of this type currently listed on Super Mario Party. Notice how vague these entries are and how many of them don't even specify which characters have clips reused.

The exception to this would be if a voice clip, within the context it appears in the game, is clearly a reference to another work. I'm not sure of any actual examples off the top of my head, but hypothetically, if Luigi reused some of the "MARIO!" voice clips from Luigi's Mansion in Luigi and the Haunted Mansion from Super Mario Galaxy, that would probably be considered a reference. In this case, the entry should explain exactly what clip(s) are being used and what it is about the situation that makes it a reference. That leads me into what should probably be a good rule of thumb for this exception: if you can't explain why it's a reference beyond just being in that game, then it's probably not a reference.

Proposer: Waluigi Time (talk)
Deadline: November 8, 2024, 23:59 GMT

Support

  1. Waluigi Time (talk) Waluigi Time's support vote is reused from this proposal.
  2. Nightwicked Bowser (talk) These voice clips are most likely used without their game of origin in mind.
  3. Super Mario RPG (talk) Per both.
  4. Sparks (talk) Per all.
  5. LadySophie17 (talk) Donkey Kong: Mario's mustache is reused from this game.
  6. TheFlameChomp (talk) Per all.
  7. Nintendo101 (talk) Repurposing an asset — voice clip or otherwise — is rarely a reference in isolation.
  8. Doc von Schmeltwick (talk) - I swear this has already been proposed and passed....
  9. Arend (talk) I think this is more worth to be its own trivia subsection ("Reused assets"?) than treating it as a specific "reference" and lumping it among the more legit ones.
  10. Shadow2 (talk) Per all.
  11. Camwoodstock (talk) Per all. Reuse of assets isn't really a "reference" in the usual sense, as there's plenty of non-callback reasons to do so. We don't think the re-used Charles Martinet lines in the TTYD remake were done out of wanting to do a cameo from Charles, they probably just didn't feel like bringing Kevin back into the recording booth when they already had a cohesive library of voicelines from the original game. ;P
  12. EvieMaybe (talk) per all
  13. DesaMatt (talk) per all.
  14. PnnyCrygr (talk) Per all as This "reusal of voices" statement is getting done to death over and over again. And a reuse of assets is not an allusion/reference to something.
  15. ThePowerPlayer (talk) ThePowerPlayer's "Per all" vote is reused.
  16. Cadrega86 (talk), the same also goes for generic artwork (so unless it's specifically stylized or features stuff specific to a single game/subseries). These are not references but just "lazy" asset re-usage.
  17. Technetium (talk) Per all.
  18. Jdtendo (talk) Per all.
  19. Ray Trace (talk) Grunts, screams, and whoohoos aren't uttered with a specific game in mind and our articles shouldn't reflect that.
  20. Scrooge200 (talk) This has been bugging me for a while. This is just asset reuse to save budget and because there's very few specific lines that need to be newly recorded.
  21. Mario (talk) Just because it was first heard in a game doesn't mean it was recorded for this game. It might be a stock sound that went unused and eventually found its way into a future game. Additionally there are clips that are better known in other games than the one it originated in. "That's-a so nice!" Is commonly heard when Mario clears a level in New Super Mario Bros., but this quote is first heard in Mario Kart Double Dash, barely audible in the Awards Ceremony. Unless the clip itself is made specifically for a game (Mario vs. Donkey Kong!!! Finding its way in a Mario Kart game as a store speaker or something) it's best not to list as a reference. That being said, there should be ways to list if voices have been reused.
  22. Tails777 (talk) This is on par with referencing Super Mario Galaxy every time Rosalina appears. Pretty sure we had a proposal at some point opting to exclude these types of recurring things from the references section and this is just following in suit. Per proposal.
  23. DryBonesBandit (talk) Reusing a "per all" vote from previous proposals.
  24. BlueBirdBlues (talk) Reusing assets are, in most cases, not references. That being said, I do feel like we should document these reused assets somewhere, perhaps on a separate List of reused assets article? Creating a new subsection in each article for these reused assets would work too, I suppose.
  25. SeanWheeler (talk) Don't want to bloat the references section of each game's page.
  26. ExoRosalina (talk) Reused are unlikely as references, especially voice clips.
  27. Okapii (talk) Per all; voice lines in the Mario franchise have been reused so many times that what game they originated in feels almost meaningless, and making a note for every time any character reuses a specific line just feels like pointless bloat for the reference section.

Oppose

  1. Hewer (talk) I think a game reusing assets like voice clips from a previous one is still worth noting, and the reference sections are a handy place to do it. I don't see why we must restrict the section to only when "the developers wanted to give a nod".
  2. Pseudo (talk) Per Hewer. I do get that it's not an intentional reference per se, but this is still information worth documenting on the wiki (if a different place to note this information would be proposed, I'm all ears).

Comments

I do know Luigi's "Gotcha!" was made for Luigi's Mansion as a thing he says when he catches ghosts, then became a standard voice clip for him in 64DS and NSMB, despite no longer making as much sense there. Doc von Schmeltwick (talk) 11:46, October 27, 2024 (EDT)

I would also like a place for people to note when new voice clips get recorded. I think the Protrayals section of character articles makes a fair amount of sense. Or maybe in Development sections of games? Salmancer (talk) 21:07, October 30, 2024 (EDT)

Encourage game-related "icon"-type images to have consistent file dimensions with each other when applicable to their origins

Do not adjust the rules 6-22
My last proposal related to this subject had too many holes in it due to being too wide to make an actual rule on the subject. Indeed, not all sprites really need the blank space, not all "icons" are sprites at all. To recap:

this looks good
  • MKDD Mario.png
  • MKDD Luigi.png
  • ToadIcon-MKDD.png
  • PeachIcon-MKDD.png
  • MKDD Yoshi.png
  • MKDD DK.png
  • BowserMKDD.png
  • MKDD Wario.png
this does not
  • MarioMPT.png
  • Luigi MPT.png
  • Shy Guy MPT.png
  • Peach MPT.png
  • Yoshi MPT.png
  • DK MPT.png
  • Bowser MPT.png
  • WarioMPT.png

Notice how half of the MPT ones (second row) are awkwardly, inconsistently stretched in various gross ways that makes some of the pixels be rectangles, and none are at a proper size relative to each other - this is an obsessive-compulsive spriter's worst nightmare. Meanwhile, the MKDD ones (first row) look crisp, clean, and are at a nice size relative to each other. Why is this? Because since they are icons, they are programmed to occupy the same type of space in select screens and player standings in-game. They're supposed to be at around the same size, which is accomplished through the small amount of empty space some have in the upper right corners - which the origin images have in the game's files. We should reflect this for the simple reason that we're only going to be putting these in galleries and table cells with each other anyway, so it makes the most sense to have them take up the same amount of space here as well. They should either be at their raw parameters, or if they are cropped, cropped to the exact same size as all the others for that type in that game so as to not screw up formatting and table cell sizes (and we shouldn't be increasing the size of sprites that are at this size by default anyway). This goes for selection icons, rank icons, map icons, that sort of thing. Cropping them down needlessly leads to the grossness that the second gallery there displays.

This is already something of an unofficial rule on here; a majority of the games with this sort of icon have them uploaded at a consistent size already for the same pragmatic reasons I just listed. I'm just trying to make this more clear-cut. It's like how "don't optimize images with color-changing metadata" is a rule - most people can't tell the difference, but it minorly affects the accuracy and presentation, so that's why that rule is in place. This is also for the "accuracy and presentation" reasoning. Also, I fail to see what the difference is between this and preferring screenshots be uploaded at native res rather than boosted resolution.

THIS DOES NOT COVER THE RARE INSTANCES GAME ICONS ACTUALLY DO HAVE DIFFERENT SIZES AS STORED IN-GAME. Instances of that are quite rare, especially for character icons that swap locations, but they can happen. Since they aren't the same size to begin with, there's nothing to match up with. It also does not apply to ones that are extrapolated from a singular group image containing all of them.

PLEASE NOTE THAT MOST IMAGES OF THIS TYPE ON THE WIKI ALREADY FOLLOW THIS RULE. Attempting to do the opposite, therefore, will take more effort for less reward.

ADDITIONALLY, I WANT TO CLARIFY THAT THIS IS NOT SPECIFICALLY STATING THEY NEED TO KEEP THEIR NATIVE DIMENSIONS. Rather, it is saying that if you do decide to crop them, you should crop them to consistent parameters, ie, the width of the widest one and the height of the tallest one. Having to resize images on an individual basis is tedious and can lead to extra HTML bloating the page that would be a non-issue if they were uploaded at the same size to begin with.

EDIT: Here's a better illustration of why I think this is necessary:
49667.png
Notice how with them cropped to content, their vertical (and horizontal if they were stacked, thanks to Klap Trap's muzzle and Diddy's hat) positions are all over the place. To someone with OCD, that's maddening. Not unlike bad kerning. This is what this proposal hopes to avoid. And no, that's not something a "rawsize" thing can do, that's gallery-only - and this inconsistent positioning would be an even bigger issue with the images in a gallery, since those don't have positioners available. And while technically, HTML can fix the positioning on the table (but again, not in a gallery), that would require a bunch of finagling span classes that would bloat the page's byte count unnecessarily - not to mention take potentially hours of trial and error depending on the image amount - when the obvious solution is to give the images the consistent parameters they were deliberately made to have - and yes, that's deliberate in more than just "limited by sprite parameters," because they used them to position them accurately in the character/level select, as I am doing with this table.

Proposer: Doc von Schmeltwick (talk)
Deadline: November 11, 2024, 23:59 GMT

Support - consistent icons (change the few remaining icon images and make it a general rule for the future)

  1. Doc von Schmeltwick (talk) - Icon haz dead, never-funny-in-the-first-place memes about fast food sandwiches?
  2. Super Mario RPG (talk) - Accurate to how the graphic or texture is stored in game.
  3. Hewer (talk) Per fast food sandwiches
  4. Ahemtoday (talk) Per proposal.
  5. blueberrymuffin (talk) Per proposal.
  6. wildgoosespeeder (talk) I don't bother cropping anything for this kind of reason. The Cutting Room Floor doesn't do something like this because of prioritizing consistency in dimensions, where possible.

Oppose - who needs consistency? (do nothing)

  1. Waluigi Time (talk) Rawsize exists.
  2. Koopa con Carne (talk) There's no sense in deliberately translating the functional limitations of a game onto a wiki. The site's educational purpose dictates that official material shown on a wiki be inherently recontextualized, and showing that material at a different scale than originally intended is in line with that idea. Even taking into account the niche interests of a sprite enthusiast (which TBH is fair, the wiki is a gateway to Mario material for anybody), the sprites in and of themselves are accurate to how they were extracted when you view them on their dedicated file pages; it's only their appearance on mainspace pages that is subject to alterations, and what to what degree that is beneficial is better scrutinized on a case-by-case basis than through a global proposal. TLDR If the sprites are too uncomfortably big just resize them, or use rawsize like Waluigi Time says.
  3. Lakituthequick (talk) Per WT.
  4. UltraMario (talk) Per all. This can easily be taken care of by either a gallery or a table's settings, I am very sure of that. We don't need to be unnecessarily tampering with perfectly cropped files. I am not 100% sure of the technical site of the wiki but I am very sure that there are better ways to go about fixing sizing of things in tables not being adequate without just having to overhaul image uploads entirely, rather than just playing around with a table.
  5. Fun With Despair (talk) Seems like a huge amount of work for what is... honestly imperceptible to 99.9% of users such as in your example. Busywork for the sake of busywork.
  6. Shy Guy on Wheels (talk) Per all. I see no real benefit from this.
  7. Sdman213 (talk) Per all.
  8. Camwoodstock (talk) Per all, especially Waluigi Time. We already have tools capable of representing these icons more accurately to their in-game versions as necessary without requiring deadzones or other such things to be baked into the image itself. In fact, baking it into the image itself can cause issues when attempting to use the same image on different pages not fitted for them; such as how the image on the infobox for Blooper (Paper Mario: The Thousand-Year Door) is markedly smaller because it retains the blank space for the sake of the bestiary article. While we should strive for accuracy, we shouldn't let it get in the way of making the information actually accessible and readable; besides, if someone wanted the raw, original images, including any blank space around them, they would likely check The Spriter's Resource, not us.
  9. Ray Trace (talk) Per Koopa Con Carne. Zero readers care if an asset is cropped to content to dimensions in the power of 8 or if they have the ripped dimensions, especially if all said images are there to illustrate a gallery and especially if there is copious amounts of empty space just to pad the image to appropriate dimensions for a game engine. We aren't a game engine (modern game engines are perfectly capable of having textures in resolutions not in powers of 8 by the way), official websites such as the Mario Kart 8 Deluxe's official website crop to content because image editors know that it doesn't need to be in those dimensions (let's not get into how these assets are actually made, they're scaled down in the first place 100% for game engine reasons) icons should be cropped to editor's discretion without bludgeoning editors over the head about it, we should prioritize optimization and readability over faithfulness to asset dimensions. I can see cases where consistent sizes can work out, namely the character icons as listed in this proposal, but the general rule should be crop to content, but leave some in exceptions in regards to formatting tables, not the other way around.
  10. TheFlameChomp (talk) Per all.
  11. ThePowerPlayer (talk) Per all.
  12. Shoey (talk) Per all.
  13. Jdtendo (talk) Per all.
  14. Cadrega86 (talk) Per all, especially Koopa con Carne and Ray Trace.
  15. Axii (talk) Per all.
  16. SeanWheeler (talk) Some really small icons like the Super Smash Bros. series stock icons would look really bad if they were resized to be consistent with Mario Kart ranking icons.
  17. Mario (talk) The additional caveats in the proposal trying to address this issue is nice I guess but it makes the proposal much less clear in what it's trying to accomplish and it comes off as this user trying to bludgeon over their approach to these images in opposition with several other people's while tacking on qualifications and caveats after the fact. It doesn't help that the terminology of the proposal is imprecise (what is a "game-related 'icon'-type image"?? Does the proposal apply to whatever is a "game related 'non-icon' type image"?) Per all.
  18. Killer Moth (talk) Per all. I don't see the point in doing this.
  19. Nintendo101 (talk) I will reiterate what I said below: if folks want to maintain unified dimensions around certain assets, like the ones in the Diddy Kong Pilot example, that is completely fine and okay to do. I agree it looks nice. However, folks should have the freedom to choose whether they want to do that or not with the tables and templates they have developed. To experiment. I agree with the opposition that cropping to the visual content of an asset is not inherently destructive, while recognizing there are real examples on this wiki where assets benefit from having unified dimensions outside of galleries. But those were choices made because they are visually appealing and convey information - not out of a unique reverence for how computer engines spatially store assets, and while I know this proposal is not explicitly advocating for that, it derives from similar arguments made in the previous one, and I wanted to touch upon that here. We adjust assets all the time for the sake of illustrative intent. We assemble disembodied sprites. Adjust/add colors to reflect in-game appearances (especially when they are not actually coded as such for older consoles). We pose models. We approximate lighting conditions. We crop out screenshot details for a focused view. We narrow displays to omit details that the player typically has no way of seeing. From my experience, none of these choices have been considered controversial, and they should not be. They are not dissimilar from taxidermy, art restoration, and similar curatorial techniques that are exercised in museums worldwide. To me, cropping to visual content - the pixels that people can actually see - is no different from these methods and not an inherent problem. If folks want to keep unified dimensions around the assets they are working with or see use outside of galleries, that is fine and good. This is the opinion of some other folks in the opposition, like fellow ripper Ray Trace, as evident here. However, if folks do not want to do that, or use tables built on the expectation that assets they are using are cropped to content, or they are cropping the content around assets that are only found in galleries, I think they should have that freedom too.
  20. MCD (talk) Per all.
  21. FanOfYoshi (talk) No. No, both look good in their own right. Per all.
  22. SmokedChili (talk) Per all.

Comments

@Waluigi Time - Rawsize doesn't help for tabular data. Only for galleries. Only way to get it there would be to separately size each cell, and even that doesn't keep them in the correct position within the cell. Wouldn't it be more pragmatic to just have the images at the correct size rather than having to mess with the HTML each time? And we do indeed use these for tabular data, like ghost times, tennis rivals, that sort of thing. Doc von Schmeltwick (talk) 16:43, October 28, 2024 (EDT)

And would that not be easily solved by displaying the image at its native resolution (or at least consistent resolutions for all of them) and centering it? --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 16:51, October 28, 2024 (EDT)
No, it absolutely wouldn't. Because not all the icons are themselves centered, such as the MKDD ones above. They all come out of the lower-left corner. And that's not getting into how some games have a variant with an actual shaped background alongside clear-background ones, like Strikers Charged for example. It'd make the most sense to match those up relative to where the square bounds are for their respective size, IMO. Also, when they need shrunk for smaller tables, it's easier to do that when they have the same x-y parameters anyway so you don't have to check every. Last. One. And do the math each time. Doc von Schmeltwick (talk) 16:52, October 28, 2024 (EDT)
@Waluigi Time - Rawsize also doesn't work for sizing images down. Only sizing them as-is or sizing them up. So it's still not a perfect solution for all occasions anyway. Doc von Schmeltwick (talk) 02:48, October 29, 2024 (EDT)
All of these things can be fixed using text-align: center, vertical-align: middle, and the inherent ability of tables to size columns and rows based on their contents. Lakituthequick.png Lakituthequick 20:55, 28 October 2024 (UTC)
I already said that's not true, because not all of them are centered in their origin. If you want DK's image's left border touching the left border and his right border touching the right border, and the same to go for Luigi, that will absolutely not work unless they are uploaded at their intended size. Doc von Schmeltwick (talk) 16:58, October 28, 2024 (EDT)

@Koopa con Carne - I thought you didn't want math to be forced onto the site. In order to resize them consistently if they aren't uploaded at the intended consistent size, you have to go through every single one and check their sizes individually, then apply whatever size change also individually in order to be consistent. Keeping them as they are intentionally incorporated into the game is much cleaner on both counts. If mediawiki had a "50%" in addition to the pixel resizing, that wouldn't be an issue, but they don't. And applying a same-pixel-size on sprites with different base sizes is just dirty. Doc von Schmeltwick (talk) 17:04, October 28, 2024 (EDT)

You're misconstruing my point about math on the wiki. I never suggested curbing the use of math in the back end by editors (even then, I don't recall ever actually mathing my way through editing a page other than establishing sizes of things like images and charts). It was strictly in reference to the math that is displayed, for one reason or another, to readers, specifically how serviceable it is for articles to show readers more complex formulas versus simple tallies of elements in a level. I've long digressed though, lol.
The issues you bring up are solvable on a case-by-case basis. I like consistency and tidiness, too, however, those ought to have a healthy marriage with the wiki's primary interest to educate. Here, you'll notice I purposefully enlarged the icon for the Giant Banana item relative to the regular banana peel, because it used to look about the same size, which was odd. I understand where you're coming from and I support giving a sense of scale to sprites of a certain type in a row if it would otherwise look too messy or unnatural, but I don't believe that has to be enforced among all these sprites indiscriminately. -- KOOPA CON CARNE 18:23, October 28, 2024 (EDT), edited 19:03, October 28, 2024 (EDT)
Well this proposal isn't about "all sprites," it is specifically about icons within a particular family, ie, all MKDD character select icons are one family, all MKDD item icons are another family, all MKW select icons are yet another family, etc. etc. etc. Doc von Schmeltwick (talk) 18:30, October 28, 2024 (EDT)
I understand. That's what I meant when I said "sprites of a certain type in a row". That's a tad wordy, so I guess "sprite family" can indeed be used for the purposes of this proposal instead. -- KOOPA CON CARNE 18:59, October 28, 2024 (EDT)
OK so.... what is the negative you are seeing to this? It seems like you agree with what the proposal actually aims to do, so I'm not really understanding your opposition. It's like how "don't optimize images with color-changing metadata" is a rule - most people can't tell the difference, but it affects the accuracy and presentation, so that's why that rule is in place. This is also for the "accuracy and presentation" reasoning. Doc von Schmeltwick (talk) 19:07, October 28, 2024 (EDT)
What I agree with, is that assets extracted from the game shouldn't be tampered with before they are uploaded on the wiki. The native size and optimizations should still inherently be part of the asset. What I disagree with, is that such a principle should extend to their presentation on mainspace articles. An image gallery is not a sprite sheet, it's demonstrative. If you think a gallery of assets can benefit from a few fine adjustments to accommodate scale and aesthetic sensibility, by all means do it. I agree the Shy Guy icon you show in the proposal looks too large and should be scaled down a little, as I did with the giant banana I mentioned previously. Enforcing the standard you propose across a demonstrative gallery is shifting the priority on technical accuracy. -- KOOPA CON CARNE 12:19, October 29, 2024 (EDT)
The actual argument of this proposal is different from the last one. This isn't specifically aiming for native dimensions, though that would still be the "easy way" imo. This allows for cropping as long as the cropping is to a consistent size for said related assets. Doc von Schmeltwick (talk) 12:40, October 29, 2024 (EDT)

@UltraMario - You... do realize that cropping the files is where the "tampering" comes into play, right? If they're displayed as they are in the game, they are untampered with. Cropping them down is, by definition, tampering with them. I think you need to reword that. Doc von Schmeltwick (talk) 17:07, October 28, 2024 (EDT)

@Fun With Despair - Except most of them are already like this - this is just making an unofficial rule we've used for years an official one for practicality. In this case, doing the opposite would be busywork. And making them consistent is busywork I am willing to do. Doc von Schmeltwick (talk) 17:35, October 28, 2024 (EDT)

Besides, being a lot of work hasn't stopped proposals that take even more work to implement from passing. It's a flimsy reason to oppose a change. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 18:02, October 28, 2024 (EDT)
Not opposing because it's a lot of work, opposing because it's a lot of work in service of something that is unnoticed and not cared about by the vast majority of users. The citation proposal is a bad example because that is actually something important to the accuracy of information on the wiki. This doesn't do much of anything at all besides force small edits to many old images.--Fun With Despair (talk) 18:33, October 28, 2024 (EDT)
That could be said about proposals in general. If it doesn't matter to you, wouldn't it make more sense to not vote at all? If I see a proposal on a subject I don't care about, I just don't vote. After all, if it matters to someone, it matters in general and shouldn't just be opposed because of what amounts to "I don't care about this." Doc von Schmeltwick (talk) 18:36, October 28, 2024 (EDT)
I'd argue a majority (or at least significant number) of readers likely don't care either way about citations for names in other languages. But that doesn't mean people who do care about the change don't exist, or that it's inherently a bad change. I think "eh who cares" is also a flimsy reason to oppose a change. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 18:38, October 28, 2024 (EDT)

Wait, so if this is already often the way things are, will the oppose option change that? That would mean this proposal lacks a "do nothing" option. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 18:07, October 28, 2024 (EDT)

Oppose is a "do nothing." I'm not going to include an option for what I would consider a negative change. Doc von Schmeltwick (talk) 18:28, October 28, 2024 (EDT)
Wasn't suggesting you should, just got confused since you were making comments about "doing the opposite". Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 18:31, October 28, 2024 (EDT)
That was mainly directed at the "too much work" argument. Doc von Schmeltwick (talk) 18:32, October 28, 2024 (EDT)

@Camwoodstock - Things like the TTYDr bestiary images are not covered by this proposal, only small icon sprites that are intended to be square anyway. Doc von Schmeltwick (talk) 19:46, October 28, 2024 (EDT)

For the record, we know that wasn't exactly what the proposal was targetting, we mostly mentioned it as it's a pretty striking example of how including these transparent margins in the images themselves can backfire (besides, it's one of the most recent examples of such a thing happening.) We hope that makes sense, anyway. ~Camwoodstock (talk) 19:48, October 28, 2024 (EDT)
I still don't see why it's preferable to be forced to use the HTML to make them somewhat close-ish to accurate when simply letting it have the one or two columns of blank pixels that it's supposed to have on one side of it would look better for practical reasons anyway. It's a lot simpler and doesn't hurt anything to do. Doc von Schmeltwick (talk) 19:52, October 28, 2024 (EDT)
Because sometimes, you don't want them to be entirely accurate; while an original-resolution image might be wanted for, say, a gallery or a table, in an article, template, or especially in an infobox, you probably don't want the original size and would want something a lot more readily scalable, without transparent margins baked into the image that you need to futz with. At best, it would be too small to add a proper caption to; at worst, you basically gut the clarity of the image itself. For example, while not an "icon" in the sense of the original proposal, the articles for various objects from Super Mario Land upscale the images outside of their original context. Infoboxes on articles such as the Lift Block would be rendered borderline incomprehensible if the images were not enlarged like this. And the grown image size is accomplished not via baking it into the files themselves, but via using fairly basic wikiscript or HTML; that way, on the main article, they can still appear in their original format. This general philosophy applies to icons as well, which is why we bring it up.
Again, if someone was looking for the raw, unedited sprites, they would likely head to The Spriter's Resource and not us; our goal here is to make these images accurate, of course, but we need to make them both usable in articles and also keep them standardized between one another; baking transparent margins into the images themselves, even if technically accurate to the source material, does run counter to that latter goal. ~Camwoodstock (talk) 21:09, October 28, 2024 (EDT)
There are plenty of instances where we'd have to edit ripped textures anyway because they're ripped rotated or flipped. Cropping to content is similar to those nondestructive edits and I still fail to see how it's such a big issue, we don't need to preserve transparent pixels just because image editors deliberately padded out assets just for the game engine to decipher properly. Otherwise we should upload sprites without any color data and their palette data as separate entities. BabyLuigiFire.pngRay Trace(T|C) 21:15, October 28, 2024 (EDT)
It's destructive to me. ._. Also, saying "zero" readers is obviously wrong if there's people supporting this. "Who cares" is never a good argument. Doc von Schmeltwick (talk) 22:10, October 28, 2024 (EDT)
@Camwoodstock - Boosting them by a consistent size factor (like 50%, 200%, 300%, etc) is perfectly fine - Lift Block, for example, is sized up by 1000%. And it's a lot easier to do that when they have consistent base dimensions so you don't have to look the specific dimensions to resize them by for each image separately. Having all the 32px images display at 64px is a lot simpler than having to look through each to see which needs to be at 64, which needs to be at 62, which needs to be at 58, and so on. That's pointless, tedious, and can be prevented completely by doing what this proposal aims for. And again, non-consistent size factors, like "just make them all display at 50px!" are really messy - see the Mario Power Tennis example above, and how Shy Guy's icon is ultra pixelated while Bowser's is fairly crisp. It's grossly inconsistent, and on a table, it can't just be rawsized with a percentage (and rawsize in galleries only works for making them bigger, not smaller). Doc von Schmeltwick (talk) 00:45, October 29, 2024 (EDT)
I was the one who uploaded these bestiary images, and I had a few reasons. The main one is that some images like Smorg are cut off by the borders and would look strange when cropped. Also, since each of the Tattle Log images display against a border and background that I was also able to rip, I was hoping we'd be able to fit the enemy images over the background and border so it'd be more accurate to how it appears in-game. Scrooge200 (talk) PMCS Mustard Cafe Sign.png 20:30, October 29, 2024 (EDT)

By the way, a striking example of ripped assets that are extremely counterpoint to this proposal are the Mario Party: Island Tour space icons. Every single one of those icons are cropped from a single texture that compiles all of them, absolutely requiring you to crop images and then crop to content because none of the options suggested that would "encourage" them cover those instances. Hence why I think it's extremely pertinent to encourage crop to content except for formatting purposes in regards to tables. In addition, icons ripped may also come with engine gamma-fixes or even be outright flipped or rotated all which require correction in display for browsing purposes. BabyLuigiFire.pngRay Trace(T|C) 21:10, October 28, 2024 (EDT)

Hence "when applicable to their origins". As that one is done differently, it is not applicable. This textureMedia:MK8DX-BCP audience TVV.png was stored in a similar manner with all eight of its frames in a single image (evenly spaced), while there's also this group texture imageMedia:MKAGP audience.png that has someone sideways. Doc von Schmeltwick (talk) 22:06, October 28, 2024 (EDT)

Some important things to note:
1. The proposal only applies to icons that have a natural similarity, such as characters, items, board spaces, badges, etc. It does not apply to textures, screenshots, logos or scanners.
2. In fact, the wiki and the TSR do not have the same purpose. The wiki is not a graphics museum, nor does the TSR have informational content. But this has nothing to do with what the proposal suggests is the organizational factor.
3. "Who cares?" Yes, the readers and Super Mario enthusiasts who visit the site every day may not care. But the proposal is not for them. After all, are they the ones who vote here? The proposal is for the editors, for those who submit images and create galleries. Approving this would only be a way to better organize what is already common practice.
4. This prevents things like itMedia:M&S2014 Mii Costume 55.png.
blueberrymuffin (talk) 17:44, October 29, 2024 (-03 UTC)

What constitutes as an "icon" is entirely arbitrary in terms of graphics, there is technically no difference between graphics HUD of a character's disembodied head in a map and images used as flair in menus, or images of items in say Mario Party 4, or little images in the group photo in Mario Superstar Baseball. As for the "who cares" statement, that's specifically why I voted to oppose: I don't care about what this proposal wants to implement, I think it's way too draconian for the purposes of this wiki, and I am having my voice heard, and there is a discernible amount of people who share that sentiment. Editors use this wiki too. I also don't see the issue with the cropped Mii suits, MediaWiki has the tools to format those images should they be formatted. BabyLuigiFire.pngRay Trace(T|C) 23:18, October 29, 2024 (EDT)
"MediaWiki has the tools," does it? Please tell me how, using the [[File:xxxxxxx.png]] type of image, you can implement a resizing of, say, "50%" rather than individually going in and checking the pixel dimensions and dividing it by two yourself. As far as I am aware, you cannot, and when there's 70 or so images all with different dimensions, that's adding a needless amount of tedious work when the obvious solution is to give them the same dimensions in the first place so it only needs done for one value. And obviously, what makes an icon is determined by whether it is used as an icon. That doesn't even need said, so I don't know where you were going with that. Doc von Schmeltwick (talk) 00:29, October 30, 2024 (EDT)

I do not know if this has been mentioned or demonstrated yet, but this is what the Mario Kart: Toadstool Tour icons look in a gallery when rawsize is integrated:

  • MarioMPT.png
  • Luigi MPT.png
  • Shy Guy MPT.png
  • Peach MPT.png
  • Yoshi MPT.png
  • DK MPT.png
  • Bowser MPT.png
  • WarioMPT.png

and this is what they look like when it is added to the gallery as laid out in this proposal, with heights and widths set to 72.

  • MarioMPT.png
  • Luigi MPT.png
  • Shy Guy MPT.png
  • Peach MPT.png
  • Yoshi MPT.png
  • DK MPT.png
  • Bowser MPT.png
  • WarioMPT.png

I do not know if this is apparent in all displays, but Donkey Kong and Bowser are smaller than they should be in the second row. This is happening because the dimensions set for the gallery (72) are smaller than the dimensions of the sprites for DK and Bowser. When the heights and widths are changed to 79 (the pxl height of the biggest sprite), it looks like this:

  • MarioMPT.png
  • Luigi MPT.png
  • Shy Guy MPT.png
  • Peach MPT.png
  • Yoshi MPT.png
  • DK MPT.png
  • Bowser MPT.png
  • WarioMPT.png

I do not know if has been alluded to elsewhere in the discussion or changes anything, but I just wanted to point this out. In galleries, you can use rawsize to accurately display assets to scale as long as their are no dimensions set for the gallery, or the dimensions set are larger than the largest sprite. - Nintendo101 (talk) 20:04, October 29, 2024 (EDT)

But you can't shrink them or use that outside of galleries, so it is not a solution to the primary issue of "it screws up table cell widths and heights," and "you'd need to go in and resize each individually on a table since mediawiki doesn't have a percent-based standard image-resizer, only a pixel-based one, and that's an unnecessarily large amount of work and added HTML for adding proper-sized bounding boxes separately, needlessly bloating the page's byte count when the easy, practical, and obvious solution is to just upload them with the intentional shared dimensions in the first place." Doc von Schmeltwick (talk) 00:26, October 30, 2024 (EDT)
I honestly feel these are valid points. I found instances where it is easier to us certain assets in tables when they are all squared in dimension, and I personally have not heard persuasive reasons why easy integration into templates or tables should always take a backseat to their presence in galleries since we are primarily a resource to be read. Not just browsed. However, this is again a case where I feel allowing users to exercise discretion would be better than a rule. For example, I agree that squaring the Double Dash!! icons is nice, but I don't know how that really benefits the display for the Mario & Sonic Mii costumes.
For clarity, I would not support a proposal that insists we must always crop to content. I understand assets are not always restricted to galleries, and tables and templates are often setup with reliable size parameters. It is generally easier to edit an asset once rather than adjust all the tables it appears to ensure it is displayed in a preferred way, and while cropping to content is nice, I do not personally think it really "ruins" the display in a gallery if one or two assets are out of alignment with their neighbors or look smaller in preview. I at least do not think it is so unsightly that cropping to content should be prioritized over their utility outside of galleries. Users should have the ability to exercise discretion. It remains an important part of making this a communal space. - Nintendo101 (talk) 02:28, October 30, 2024 (EDT)
Keep in mind the proposal is not specifically about keeping the original dimensions, it's more about consistency - cropping can occur as long as that too is consistent. And if an icon is completely unique and not part of any "family" with other ones, then it doesn't matter. Doc von Schmeltwick (talk) 02:36, October 30, 2024 (EDT)

@Doc von Schmeltwick I think you're missing the point the opposition here or in the previous proposal is trying to make. As far as I'm aware, no one's saying "never do this". It's already done on the wiki, and it's good when the circumstances call for it. I don't think the Diddy Kong Pilot example you posted is that bad but it's definitely better at the consistent dimensions, and I don't see anyone here clamoring to crop down the Double Dash icons either. What I take issue with, and I assume many of my fellow voters feel the same, is this proposal's goal to essentially enforce that across the wiki whether it's helpful and wanted for design purposes or not. The Mario Power Tennis icons you used as an example aren't currently used anywhere on the wiki where inconsistent dimensions actually matter. I assume the Mario & Sonic Mii costumes would also get caught up in this since they're technically icons, but in my opinion, consistent sizing is unnecessary and the images look worse with the extra space needed to accommodate the largest costumes. At the very least you can't say it looks objectively worse that they're not all centered in this case. You've mentioned having OCD several times in these types of discussions, so I recognize and sympathize that some of these inconsistencies can be frustrating for you, but your personal preferences and irritations aren't always going to reflect the majority of the userbase.

Also, the reason rawsize keeps getting brought up is because you were the one who started this proposal with a comparison of images in galleries and made it seem like a key point of your proposal. I'm not sure why you did that, and it feels misrepresentative of the situation at best since you were the one who proposed its wider usage a few months ago and should've known it was an easy solution to the specific problem you were presenting. --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 14:59, October 30, 2024 (EDT)

I know I proposed that addition. I mainly used a gallery as an example here because it was convenient to bang out quickly, not at an illustration that it is the only issue brought on by this. In regards to making it a rule though, please recall I am not stating here it "has" to be the native dimensions specifically. Also, we have other image upload rules that some people and/or wikis might consider "draconian" but have been around long enough here that they make perfect sense to us (don't upload non-animated .gif's, don't convert .jpg's to .png's and especially don't give them transparency, don't optimize images with metadata, and the above proposed one with currently unanimous support regarding NES palettes), so I really don't see how this ends up any different. I specifically noted in the proposal and its very title that if it straight-up doesn't work in whatever context, that it doesn't need done for it, so I don't see how it ends up as a problem anyway. Doc von Schmeltwick (talk) 15:58, October 30, 2024 (EDT)
This unfortunately contributes to the same problem I had with the previous proposal. Your reply here makes it sound like there would be no substantive or practical difference between how folks generally handle assets already, making it unclear what would actually change if the proposal were to pass. What would change? — Nintendo101 (talk) 16:42, October 30, 2024 (EDT)
Because when I tried to enforce "how folks generally handle assets already" it was treated as me going notably out-of-line. There's always gonna be someone who uploads a .jpg -> .png image because they don't know any better or don't realize it (I'm guilty of the latter from before I knew to check with the "save image as" function), and that needs to be corrected - it is how we "generally do things," but we do it because that is a thing that needs discouraged, hence there being a rule. I see this as no different from that. Doc von Schmeltwick (talk) 18:52, October 30, 2024 (EDT)
This proposal is just going to result in a patchwork of interpretation of how to approach these assets. It's a sign of a very flawed proposal. Doesn't help that your entire bedrock of reasoning that led to this kind of proposal (that we should be encouraged to maintain the original dimensions of a ripped sprite), which I have deemed utter nonsense and I stand by it being utter nonsense, continues to be maintained. This leaves me with a not very confident impression you have any clue how these assets are created, stored, and used in a video game, that you understand why an asset is padded and has dimensions of 128x256 or something and why this doesn't mean a wiki should be necessarily maintaining these dimensions. Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 00:33, October 31, 2024 (EDT)
I have explained time and time and time and time and time and time again that this proposal does NOT require the original dimensions. Just shared dimensions. I figured putting it at the top in ALL-CAPS BOLDED BRIGHT PURPLE would be enough to get people to actually read and realize this, but apparently not. Please acknowledge this and stop treating it as though that is my argument here when it is not. Doc von Schmeltwick (talk) 01:02, October 31, 2024 (EDT)
Let me clarify: when I mentioned the bedrock of reasoning, I meant to contextualize the situation that led up to the proposal. It's to support my criticism of your proposal, which was made in response to the earlier one that was canceled from mounting opposition, that this follow up proposal is poorly made. Due to the timing of things, it comes off as an attempt to simultaneously continue your practices of insisting that image dimensions are important information to maintain (they are not) but with flawed solutions designed around this flawed principle. To me, this is a confusing proposal that will lead to conflicting approaches to how an asset will be handled, and the examples used don't do a great job clarifying points (this example shouldn't even be a table imo). Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 02:04, October 31, 2024 (EDT)
They absolutely are, but regardless of that, if it wasn't a table and were instead a gallery, the OCD-triggering vertical position issue would be even worse. (Seriously, I'd get less feeling of disgust from an animated loop of Wario puking up an endless stream of black dioxic squid ink onto Penny than I get from this - hell, that wouldn't even be half of it. This is trypophobia-level shit here.) In regards to that edit you made to your vote, obviously non-icons are completely unrelated to this. I worded this as specifically as I could to avoid it being abused. This is for icons and icons alone, and by "game-related," I mean such as "MKDD-related" or "MPT-related" to determine which group gets which parameters. Doc von Schmeltwick (talk) 02:21, October 31, 2024 (EDT)
I think there was some misunderstanding amongst parties after the previous proposal was cancelled. I at least do not think anyone intentionally meant any harm. The impression I have is that a lack of familiarity with certain tools lead to some bad-faith interpretations of why folks did the things that they did. But regardless, I think a gentler, less heavy-handed approach to these types of things would be better going forward. I do not think this needs to be strict policy, or something staff and other users need to enforce. But generally, as a courtesy, if one wants to adjust assets that are being used in particular fashions outside of galleries, it does not hurt to reach out and ask if it would be okay to adjust their dimensions. And if a user cropped material, one should not invoke rules that do not exist as actual policy, or bring up some "innate" sprite-ripping principals that do not exist. (I understand the point of this specific proposal is to make certain rules concrete, but I am referring to some of the interactions I saw between users before this current proposal was raised.) Rather, there is no harm in explaining why it is helpful to keep certain assets at particular dimensions for tables and templates. I know some folks have mentions CSS coding, but no one has bothered explaining what that would look like, and generally, adjusting the empty space around an asset is the most user-friendly and intuitive path to take. - Nintendo101 (talk) 01:28, October 31, 2024 (EDT)

@SeanWheeler: I believe the proposal is just for the icons within a particular "set" to be consistent with each other, not icons of different sets. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 08:46, October 31, 2024 (EDT)

@Killer Moth - See the Diddy Kong Pilot table above and the alignment issues it had before I enacted this principle on it, and how it's much more eye-pleasing afterward? That is the point. Without it, they tend to look gross - like that table did before. If you can't see why that's an issue, then I envy you, but it really looks bad - the version with the alignment lines is how my eyes see it even when they aren't there. And I have still yet to see any actual downside to this other than people trying to cram them into signatures, which is... not what the wiki is about and that absolutely should not take priority in presentation. Same reason we don't add fake armbands to Bowser's SMB1 sprite since that's transparency. Doc von Schmeltwick (talk) 12:50, October 31, 2024 (EDT)

Again, the dominant perspective of the opposition is not "no, this is a bad idea. No one is allowed to set up assets to make them aligned as they appear in the Diddy Kong Pilot table." Personally, I think the Diddy Kong Pilot example you provided is aesthetically pleasing when the sprites are all aligned, and folks should have the freedom to do that. It is for similar reasons that I integrated organized 100x100px sizing for all images in the mainline game tables and try to ensure columns are the same width across all tables in an article. Rather, the oppositional perspective is, "no, we do not want to police this or make this a type of rule. People should have the freedom to experiment with what types of dimensions they want for the assets used in their tables, and we do not agree that cropping to visual content is inherently destructive of an asset." - Nintendo101 (talk) 13:11, October 31, 2024 (EDT)
I feel doing this is an absolute good, and if someone has the freedom to crop, I have the freedom to restore. Two-way street and all that. Also, LGM's argument from what I can tell is exactly that (which coupled by the general belligerent/caustic directing of profanity towards it) fueled most of this. Doc von Schmeltwick (talk) 13:57, October 31, 2024 (EDT)
I respect that you view a policy revision like the one advocated for in this proposal is an "absolute good," but I do not think you have made a compelling persuasive argument as to why, or at least not one to me. And I understand your concerns over a "two way streak," but we do have courtesy policies on this wiki. Many of them seem relevant, but the one I would like to highlight is that users should not participate in other users' editing projects without asking them first. Galleries are more of a shared neutral space, but if one wants to crop to content or retain space around ones that are integrated into tables in a spatially-dependent way, it would be courteous for one to reach out to the uploader of those assets first or at least touch base with them. The Mario Power Tennis ones, for example, have only been integrated in one table at the time of this comment and cropping them does not seem to have impacted the layout or scaling in any perceivable way to me. There was no demonstrable harm.
I do not think LGM is advocating that arranging tables like the one in the Diddy Kong Pilot example should not be allowed, or at least that is not my reading of her comments. I believe her perspective is not dissimilar from mine. I would personally appreciate it if you reviewed what I wrote in my vote above. I think it would be clarifying.
I could be wrong, but I believe the curtness comes from statements you had included in the previous proposal that, from her experience as someone who also rips assets and someone who participates on this wiki very regularly, she knew were objectively false, but you were presenting them as hard facts and even invoking them to talk down to another user. This is understandably not appreciated conduct, and it is not uncommon from you. She can speak more to that if she wants to. - Nintendo101 (talk) 16:13, October 31, 2024 (EDT)
The statements I made then were accurate too, our perspectives are just completely incompatible. And considering in the cases of those Mii costume images, here, the original uploader (who is supporting this proposal) explicitly wants to keep them they way they were uploaded in, which is what I reverted them to, and LGM is reverting them from. The specific thing she has said that I take issue with is her claim that the space is absolutely worthless and should be removed from everywhere it feasibly can be, which naturally I perceive to be extremely misguided. As for the Mario Power Tennis table, it only looks as good as it does thanks to my own ingenuity of hiding a cell divider bar to make two cells look like one cell - that table is the one that has given me trouble in that regard. Presumably if they are changed to a tabular form, those icons will remain useful if we start covering rivals for it like we do for the 64 game, but by then it'd be easier if they did share parameters. Doc von Schmeltwick (talk) 16:39, October 31, 2024 (EDT)
Maintaining space needs to be done for a good reason, and having it simply because it was ripped that way is not a good reason. It is okay to find an example where extra space is needed but that table provided is a heavily flawed example due to being an inappropriate use of a table and the suggestion below that does fix the issue to begin with (and probably there is a code for horizontal alignment too). As for Mario Power Tennis table, if you're referring to this one[1] that's another fundamentally flawed table which was one of the many other tables that prompted criticism by multiple users and would not be my example to try to illustrate a proposal. The one example I think may work is File:MK8 Mario Icon.png due to its use in multiple pages and being in an array with similar scaled images, which were all put in a 128x128 box. Not sure if cropping to content is going to lead to unexpected results but for the record, I don't see the point of cropping to content for these Mario Kart 8 things either, since they're already reasonably occupying the space (unlike those Mario Kart Double Dash map icons which were heavily padded); it's a case of don't fix what isn't broken. The proposal doesn't really advocate any of this. It's, what I can glean, a way to maintain aspect ratio while cropping tightly as possible without losing information, but dressed up in bad examples and imprecise wording (like the proposal does not even define what a "game-related 'icon-type' image" is, so). Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 20:56, November 2, 2024 (EDT)
I was more referring to how the N64 Mario Tennis had a separate "partners/rivals" table before I incorporated that information into the main character table, and it used the face icons. I was saying if MPT did something similar, which it probably should if there is indeed a hard-coded system like that in the game. I don't really think I need to define the icon thing; but if you insist, I mean "icon" as in "a small image representing a subject," with "game related" simply meaning as a per-game basis (ie, MK64 icons have no bearing on MKDD icons). (Also, off-topic, but how else would the Diddy Kong Pilot example be handled if not as a table? There's other information below it that's been cropped out.) Doc von Schmeltwick (talk) 21:52, November 2, 2024 (EDT)

The Diddy Kong example, too, can be easily fixed with aforementioned styling, in this case by using vertical-align: bottom. That is to say however that those sprites are of a size where it makes sense for all of them to just retain their original size, I would not crop those either. There are cases like the Mii suits from the other day where it does make sense to crop them. Lakituthequick.png Lakituthequick 17:14, 31 October 2024 (UTC)

Not all of them have flat bottoms in other games, of course, while that also doesn't fix the left-right issue. But yes, I digress. Doc von Schmeltwick (talk) 13:57, October 31, 2024 (EDT)

Another thing I want to ask the opposition: if thisMedia:058-SMMMontyMole.png is to not be cropped, why should any of the other things? Doc von Schmeltwick (talk) 19:24, November 6, 2024 (EST)

That should be cropped to content. The large blank space serves a purpose to optimize the graphic in a game, not so much here. -- KOOPA CON CARNE 17:06, November 9, 2024 (EST)

All right, if this is going to continue to be "case by case," then expect a looooooot more discussions on this in the future. Doc von Schmeltwick (talk) 20:29, November 10, 2024 (EST)

Trust me, there won't be. BabyLuigiFire.pngRay Trace(T|C) 15:53, November 11, 2024 (EST)
...what is that supposed to mean? Because it sounds like either a taunt or a threat, and both are highly uncalled for. Ahemtoday (talk) 18:08, November 11, 2024 (EST)
I've been on this wiki for 15 years. Image edits like this have never been an issue and it won't be. The fears over potential edit wars regarding this is unfounded. BabyLuigiFire.pngRay Trace(T|C) 18:13, November 11, 2024 (EST)
Warp Pipe's name wasn't an issue until someone brought up recently it was likely being misused. Sometimes things slip through for a very long time. Doc von Schmeltwick (talk) 18:44, November 11, 2024 (EST)
Warp Pipe's name is an entirely different beast. This asset thing and how to curate it hasn't been a problem until it suddenly became one. BabyLuigiFire.pngRay Trace(T|C) 18:51, November 11, 2024 (EST)
Doc, it's a bunch of video game assets. Is this topic really worth pushing this far? Is it worth building up so much unrest over? I mean, we're all a nerdy bunch here curating video game content, sometimes discussions get understandably a bit heated (and I'm certainly no saint in this respect), but damn, there's a limit past which certain reactions are disconcerting. Please simmer down, if not for the comfort of other users, then for your own. -- KOOPA CON CARNE 18:31, November 11, 2024 (EST)
I fail to see how "if this is going to continue to be case-by-case rather than having a general guideline in place, then I'm going to discuss every time someone does it a way I personally disagree with so it can be figured out" is overreacting in any way. Because that's obviously what I said. Doc von Schmeltwick (talk) 18:44, November 11, 2024 (EST)
That was not obvious at all from your message, which could very well be interpreted as "I'm never gonna cease bringing this up". Even with your clarification, I don't understand why'd you use a vaguely threatening tone to convey that message, or why you'd even feel the need to make such an obvious remark in the first place. Yes, as a matter of course, some people are going to question and discuss a given thing whether you brought it up beforehand or not. You seem to be under the impression that this proposal's passing would have acted as a failsafe of sorts, that future users would look back on it and observe it as an unquestionable guideline, and that it could be a handy tool in sealing off new debates on the topic. This was never going to be a guarantee. -- KOOPA CON CARNE 19:50, November 11, 2024 (EST)

Either remove non-English names from cartoon dubs that weren't overseen by Nintendo or affiliated companies, or allow English names from closed captions

Allow English names from closed captions 8-1-0
"What does one have to do with the other?" You'll see!

Back in 2021, there was a proposal to allow closed captions used on Mario cartoons uploaded or streamed officially online to be used as sources on the wiki. It encountered massive opposition, with one comment left by a user in a previous discussion acting as the cornerstone of the opposition's rationale. The link intended to lead to that comment, seen under that proposal, doesn't do its job any more, so I'm copy-pasting it here for your convenience.

“re closed caption: The relation between WildBrain and video streaming platforms like Netflix is the same one Nintendo has with retaillers like Gamespot: meaning the owner of the property sells the product to the retailler/streaming website, and they may supply other material (like artwork, press releases, etc) to help the client market the product. However, that doesn't mean everything the client does with the product is now official; for instance, Gamespot has in the past created fake placeholder boxarts for Mario games using edited official artwork. Gamestop may be an authorized (or "official") retailler of Mario products but it doesn't make those placeholder boxarts by association as they were made entirely by Gamespot without inputs from the creators of the source material.

“In that respect, closed captions fall in the same category as placeholder retailler-made boxarts. Closed captions are made by people with no relation to the source material or access to behind-the-scenes material like script, and who are just writing down what they hear by ear. They are not an acceptable source for spellings.”

~ Glowsquid (talk), 2021

This is valid. In all this talking about what is official and what is not, I suppose it feels right to draw a concrete line somewhere. Someone who acquires the rights to use Nintendo's or one of their partners' IP to use it for a given purpose is technically an authorized party, but they're no authority themselves over the content within. Makes sense.

...Meaning the multilanguage names invoked in the proposal's title stick out all the more like a sore thumb. A good chunk of them, at least. Why would the wiki treat a studio or company that dubs and distributes syndicated Mario cartoons to a given demographic as particularly authoritative over the content? Ultimately, it's the same situation as the one described in the quote, the apparent clincher being that it's in a different language, and I apologize, but I don't see how it is consistent to prohibit third-party English subtitles but allow foreign dubs by people that are just as far-removed from the parent company. I propose a compromise.

Of course, not all foreign dubs would be off limits as sources should the second option of this proposal win. If one can provide sufficient proof that a given dub was supervised by one or more employees representing a company with authority over the original product, i.e. that the company left their mark on the endeavor, sourcing it is absolutely fine. As it stands, though, I can already point to the Romanian dubs of the Mario DIC cartoons as ineligible for sourcing given my failing to find any evidence DIC Entertainment ever put its signature on them. (This is coming from someone who contributed a significant amount of names from these dubs. Sometimes you gotta kill your darlings.)

"So if option 1 wins, 'Ahehehaue' is considered official again?"

No. That doesn't come from a closed caption, and I consider WildBrain's issue of circular sourcing to be a whole other can of worms best left out of this week's topic.

(added 17:42, October 30, 2024 (EDT)) "Does the proposal extend to the live-action segments of the Super Show?"

Yes, they're within the same package.

Proposer: Koopa con Carne (talk)
Deadline: November 12, 2024, 23:59 GMT

Allow the sourcing of English closed captions from officially uploaded and streamed Mario animated works

  1. Hewer (talk) Perhaps I just have a more liberal understanding of "official" (as an Ahehehauhe defender), but after proposals like this, this, and this, I feel like all these should be close enough to official to be worth documenting. And aren't games like Hotel Mario a bit of a similar case, where the "official" involvement didn't go much further than licensing them?
  2. Ahemtoday (talk) I think the difference between closed captions and placeholder retailer box art is that the closed captions are a(n optional) part of the media as it can be officially experienced. As such, I think it counts as "official" regardless of who did it.
  3. SeanWheeler (talk) Well, we would need some kind of source for names of characters that never appeared in English localizations.
  4. Pseudo (talk) These names would be familiar to some viewers of the material, if nothing else, and it seems a bit odd to consider them completely unofficial even if they weren't overseen by the original creators.
  5. EvieMaybe (talk) a license is a license
  6. UltraMario (talk) Per all. I still believe that these should still count as official enough, as they are the providers of the content and it's like a license of a license.
  7. Camwoodstock (talk) In the absence of any alternative names from Nintendo or the original team at DiC (since goodness knows that that isn't coming anytime soon), we feel like these are fair enough. While not exactly a primary source by any means, if we permit names from various strategy guides, we feel like names from closed captions officially provided by the distributors should be fair game.
  8. Cadrega86 (talk) These are no different than names from licensed strategy guides or other content written or localized by third parties.

Remove names that originate from non-English dubs of Mario animated works that were not overseen by Nintendo or an affiliated company

  1. Nintendo101 (talk) Per proposal. I found the argument persuasive.

Do nothing

Comments (closed captions vs. foreign dubs proposal)

Waltuh... I'm not voting right now, Waltuh... -- KOOPA CON CARNE 14:01, October 30, 2024 (EDT)

@Koopa con Carne By "not overseen by Nintendo/DiC", do you mean they gave the go-ahead but didn't have any direct involvement in production, or the dubs were produced by a third party with no permission whatsoever? I'd consider being more charitable for the former, but if it's completely unauthorized then that's basically equivalent to a bootleg or fan translation and probably shouldn't be covered. --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 17:07, October 30, 2024 (EDT)

First one. The proposal only touches on the scenario where a company that airs a dubbed Mario cartoon has a license to do so from the work's owner. Anything outside of such a licensing agreement is completely unofficial, like you pointed out. -- KOOPA CON CARNE 17:42, October 30, 2024 (EDT), edited 17:44, October 30, 2024 (EDT)

Added stipulation that the proposal extends to live-action Super Show segments. -- KOOPA CON CARNE 17:42, October 30, 2024 (EDT)

What is "Ahehehauhe?" SeanWheeler (talk) 23:29, October 30, 2024 (EDT)
It's a clip of a Super Show episode uploaded to YouTube by WildBrain, the current owners of most of DIC Entertainment's library (including their Mario shows). On the wiki, "Ahehehauhe" used to redirect to that episode's article because it was deemed an "official" alternate title given WildBrain's ownership status over the material, which many found outrageous since it barely passes as a "title" and is simply a transcription of the characters cackling in that clip. We don't even know if a human consciously named the clip that; it could've been a bot. -- KOOPA CON CARNE 06:28, October 31, 2024 (EDT)
Now, "Ahehehauhe" isn't linked to the WildBrain-related circular sourcing issues I mentioned in the proposal (they used names from the wiki in promotional texts, which Ahaha isn't one of). However, if the same policy used for the English Super Mario Encyclopedia is to be applied to WildBrain on the same grounds, then the only case where a name they used for a given subject should be employed by the wiki is (a) if the name didn't come from the wiki in the first place, and (b) there are no other known names for that subject. Even if we're to consider Ahahahue a unique and proper way to call an episode of a TV show, its use would still be untenable under the second point. -- KOOPA CON CARNE 06:39, October 31, 2024 (EDT)
If the same Encyclopedia logic applied, shouldn't it still be a redirect at least? LinkTheLefty (talk) 08:24, November 8, 2024 (EST)
Ah, I didn't know that was the case with the Encyclopedia. Still, I don't think many would be keen on treating an onomatopoeia as an alternate title for an episode anyhow. -- KOOPA CON CARNE 17:11, November 9, 2024 (EST)
Why would "Ahehehauhe" be considered as an alternate title for a full episode when it's only been used as a name for a 15-second clip from said episode, anyhow? It's only a short moment of the episode! I don't think other wikis for TV series consider official names of clips from a short moment of a particular episode to be an alternate title for the full episode either, whether it's some funny-sounding onomatopoeia or a more descriptive caption. I'd be all for using Ahehehauhe as a redirect if it was actually used as the name for the full episode, but it simply isn't: it was only used for a small fragment and nothing more. ArendLogoTransparent.pngrend (talk) (edits) 19:38, November 10, 2024 (EST)

Allow unregistered users to comment under talk page proposals

Allow 14-1
One thing I never understood about rule 2 is why unregistered users are not allowed to comment under proposals. The rule states: "Only registered, autoconfirmed users can create, comment in, or vote on proposals and talk page proposals." While it makes sense on this page, it is semi-protected after all, talk page proposals are a different story. Why should IPs be prevented from commenting under talk page proposals? Most IPs are readers of this wiki and they should be allowed to express their opinion on wiki matters too. I've seen several examples of IPs making good points on talk pages, I imagine most of them are regular visitors who are more interested in reading rather than editing, and allowing them to leave a comment under a TPP would only be beneficial.

If this proposal passes, unregistered and not-autoconfirmed users would be permitted to comment under talk page proposals. They still wouldn't be allowed to vote or create proposals, only comment.

Proposer: Axii (talk)
Deadline: November 14, 2024, 23:59 GMT

Support (unregistered users proposal)

  1. Axii (talk) Per proposal.
  2. Hewer (talk) Wait, this was a rule?
  3. Pseudo (talk) This rule doesn't really seem like it accomplishes anything.
  4. Blinker (talk) Per proposal.
  5. FanOfYoshi (talk) Why wasn't this already applicable?
  6. EvieMaybe (talk) it makes sense if it's just for comments
  7. Drago (talk) The rule was only changed because of this page's semi-protection and not, as far as I can tell, because of any misuse of comment sections by unregistered users. Per all.
  8. ThePowerPlayer (talk) This is a reasonable change.
  9. Dine2017 (talk) Per proposal.
  10. Ray Trace (talk) Anons use the wiki too and should be able to voice their concerns in the comments section, there's no reason to bar them the ability to comment.
  11. Mario (talk) We'll see if the Bunch of Numbers behave.
  12. Nintendo101 (talk) Per proposal.
  13. Killer Moth (talk) Per proposal.
  14. Mari0fan100 (talk) IP addresses can leave comments on unprotected talk pages. If they can do that, shouldn't they be able to comment in talk page proposals as well, given that they're not protected? Per all.

Oppose (unregistered users proposal)

  1. SeanWheeler (talk) Unregistered users just have numbers for their names, so that looks awkward with the way the votes are counted. It's easy to use your IP to sockpuppet, so I wouldn't want anyone doing that for the votes. And even for just the comments, I wouldn't want anyone to sockpuppet in an argument for manipulation tactics. Nor do I want to see poor grammer or vandalism. Anyone who wants to participate in voting discussions should sign up. This page was semiprotected for a reason. SeanWheeler (talk) 00:19, November 1, 2024 (EDT)

Comments (unregistered users proposal)

"While it makes sense on this page, it is semi-protected after all"
If the protection history displayed above this page's edit box is any indication, it was the other way around. There was already a rule against anonymous voting on this page by the time it was semi-protected. In that case, it might be useful to look into the reasons this rule was made in the first place and, if there's any disagreement, extend this proposal to this page too. As to where these reasons are stated, I don't know. My assumption is that the rule exists because anons are more prone to shit up the place than registered and autoconfirmed users. -- KOOPA CON CARNE 16:15, October 31, 2024 (EDT)

I couldn't find a reason why IPs were disallowed to comment. My only assumption is that when this page was protected the rule was modified to mention that IPs couldn't comment, but talk page proposals weren't considered. I'll look into it more and potentially add a third option to allow IPs to comment here as well. Axii (talk) 16:20, October 31, 2024 (EDT)

@SeanWheeler - This isn't about voting, it's about commenting. Doc von Schmeltwick (talk) 01:04, November 1, 2024 (EDT)

For real, do you even read before voting on proposals? It's a small paragraph that makes it very clear that it's only about commenting under talk page proposals, not even on this page. Axii (talk) 01:07, November 1, 2024 (EDT)

Decide whether to cover the E3 2014 Robot Chicken-produced sketches

cover Robot Chicken 9-1
For E3 2014, Nintendo's press conference was a video presentation similar to today's Nintendo Directs, featuring clips of stop-motion sketches by the producers of Robot Chicken. I feel that these qualify to receive coverage on this wiki, since their appearance in a video published by Nintendo means that they are officially authorized, and they prominently feature Mario franchise characters. However, I have never seen the sketches discussed in any wiki article, nor are they listed on MarioWiki:Coverage, so I thought it would be appropriate to confirm their validity for coverage with a proposal.

The following articles would be affected by this proposal if it passes (since the E3 2014 video is not a game, film, etc., coverage is best suited to an "Other appearances" section):

Regardless of which option ends up winning, a note should be added to MarioWiki:Coverage to explain how these sketches are classified. Also, I'm clarifying that this proposal does not involve any sketches from Robot Chicken itself, since those are clearly parodies that have no approval from Nintendo.

Proposer: ThePowerPlayer (talk)
Deadline: November 16, 2024, 23:59 GMT

Support

  1. ThePowerPlayer (talk) Per proposal.
  2. Hewer (talk) This feels logical enough that I'm not sure it needs a proposal or even an explicit note on the coverage policy, but per proposal just in case.
  3. EvieMaybe (talk) per proposal
  4. Tails777 (talk) Some of them were Mario related so I don't see any reason not to mention them. Per proposal.
  5. Ray Trace (talk) Per proposal.
  6. Camwoodstock (talk) At first, we were a bit confused as to why only E3 2014 was getting this treatment, but it turns out that no, actually, we do mention a few things from E3 presentations and Nintendo Directs in these articles, we just never internalized that information. If we cover that Wario animatronic puppet from E3 1996, and we cover Bowser in Bayonetta 2, we don't see why we shouldn't cover this specific E3's trailers just because it was by a different producer.
  7. Nintendo101 (talk) Don't see why not.
  8. Killer Moth (talk) Per proposal.
  9. Jdtendo (talk) It is no less official than Shitamachi Ninjō Gekijō or Super Mario-kun. Per all.

Oppose

  1. SeanWheeler (talk) Robot Chicken is an adult parody show. To cover Robot Chicken in Mario's history is like taking the Family Guy cutaway gags as canon. The Robot Chicken sketches including the E3 specials are covered in List of references in animated television.

Comments

Uh, SeanWheeler? You may want to see MarioWiki:Canonicity. There is no canon in Super Mario. And being an "adult" show shouldn't prevent text from being referenced in normal articles given the wiki does not censor anything. (The last point on MarioWiki:Courtesy, and the set of arguing over Bob Hoskins's page quote.) I guess one could discount the sketches on account of them as parodies, but given the "no canon" bit that seems hard to justify. Salmancer (talk) 21:01, November 3, 2024 (EST)

It's been a hot minute, but aren't the 2014 E3 sketches not even a part of Robot Chicken, anyways? Just produced by the same team behind them. It would be like prohibiting mention of Ubisoft because they developed those South Park games. And even if the sketches for E3 2014 were particularly "adult", overwhelmingly adult content hasn't stopped us before. ~Camwoodstock (talk) 09:43, November 4, 2024 (EST)
We might not have any canon, but Robot Chicken sketches are like the Family Guy cutaways. We don't cover Family Guy despite having a few Mario cameos. They only get listed in List of references in animated television. And no, it's nothing like prohibiting Ubisoft for their South Park games. We have Ubisoft for their involvement in the Mario + Rabbids crossover series. We don't cover South Park. Prohibiting the mention of Ubisoft for just one unrelated series would be ridiculous. SeanWheeler (talk) 15:25, November 9, 2024 (EST)
So what if these are "like the Family Guy cutaways"? We don't cover Family Guy because we're not a Family Guy wiki. As far as I know, no Mario cameos in Family Guy were officially authorised by Nintendo, so it couldn't get its own article anyway. Meanwhile, these sketches were officially posted by Nintendo and featured Mario characters prominently. As for the part of your comment about Ubisoft and South Park, you've just described the point Camwoodstock was making by bringing that up. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 16:59, November 9, 2024 (EST)

@ThePowerPlayer Looking at these sketches, why not create an article covering them? It would be inconsistent not to cover them separately as well, not just as sections of other articles. Axii (talk) 13:26, November 4, 2024 (EST)

The proposal is to cover them in "Other appearances" sections, which are supposed to cover things without articles. Also, to my knowledge, they don't exactly have an official title that we could use. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 13:32, November 4, 2024 (EST)
This is exactly why I brought it up. It would be weird not to have a page on them when all other content does. Lack of an official title never stopped us either :)
Axii (talk) 03:42, November 5, 2024 (EST)
My point is that not "all other content" has a page, and that's what "Other appearances" sections are for. I don't think these short, nameless skits from an E3 presentation that are more about Nintendo in general than specifically Mario are really in need of an article when this proposal passing would mean their entire relevance to Mario would already be covered on the wiki. They aren't even the only skits with Mario characters from an E3 presentation, E3 2019 has an appearance from Bowser. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 06:34, November 5, 2024 (EST)
Exactly. Making an article would just lead to a lot of unnecessary descriptions of content that has nothing to do with the Super Mario franchise. ThePowerPlayer Slug.png ThePowerPlayer 19:44, November 5, 2024 (EST)

Require citations for dates

Require citations 7-0
Recently, a proposal decided that not sourcing a foreign name puts the article into a meta category of "unsourced foreign names". But I'd say a similar idea should be implemented to dates for things such as media releases, company foundations, and game, company and system defunction. Because, for example, there's been many times where I've seen an exact release date pinpointed and I think "where did they get that date from?", and after a bit of research, I can't find any reliable source with said exact release date. Dates being sorted like this would be nice.

Proposer: Starluxe (talk)
Deadline: November 16, 2024, 23:59 GMT

Support

  1. Starluxe (talk) Per my proposal
  2. ThePowerPlayer (talk) Per proposal.
  3. Super Mario RPG (talk) I agree.
  4. Camwoodstock (talk) Wait, how is this not already policy??? Per proposal.
  5. Shy Guy on Wheels (talk) I personally find that a lot of release dates for games on the internet come from hearsay, and copying what other sites say without actually double checking that info, so this would be great for guaranteeing accuracy.
  6. Technetium (talk) Per proposal.
  7. Mario (talk) The next time Peach asks Mario out, I am sooo citing this proposal.

Oppose

Comments

What source you think is acceptable for release dates? I personally use GameFAQs. BabyLuigiFire.pngRay Trace(T|C) 20:05, November 2, 2024 (EDT)

GameFAQs isn't officially related to Nintendo, right? If so, then no. It needs to be an official source. Because if anything, GameFAQs' release dates could be taken from another unofficial source, making that an unacceptable source. Starluxe Shy Guy in Super Mario Maker. 13:00, November 6, 2024 (EDT)
But that is a major problem of mine regarding old games, especially those that came out before the internet. Game sites such as GameFAQs and Wikipedia have it down all the time, especially those as old as GFAQs, but I don't think Nintendo themselves keep track of it too much barring recent titles or titles they are currently selling, with rare cases of them citing release dates in games themselves (like Super Smash Bros. Brawl's chronicles). For example, Wikipedia does cite Mario Kart: Double Dash's release date in a financial statement by Nintendo but other games such as the original Thousand Year Door's release dates remain unsourced. I'll need an answer to what sources you plan on using to cite the release data. BabyLuigiFire.pngRay Trace(T|C) 18:28, November 7, 2024 (EST)
This has come up a few times, but the state of proper video game release date archival is dreadful. I would argue it was around the time of digital storefronts that they were catalogued more seriously. I really want to support this proposal, but first, I think it's really important to decide what type of sources are usable. Sites like GameFAQs and MobyGames? They're actually user-contributed, in theory, I guess. You can contribute there. The problem is that I don't know anything about their curation. Unlike a wiki, you can't look back. Someone can contribute something else that overrides your contribution, and you won't know why (probably something to the effect of "another online source"). So, I wouldn't take sites like them, despite search results doing a good job of making sure they're one of the first things you see. Wikipedia has taken to citing the copyright office, but as far as I know, details like that are not always the same thing as an actual release/airing date. My suggestion is that this needs a whole source priority of its own, preferably contemporary sources like magazines and press releases. LinkTheLefty (talk) 08:24, November 8, 2024 (EST)

Seeing how this could also apply to other things like defunction dates, I've added so to my explanation. Starluxe Shy Guy in Super Mario Maker. 12:16, November 7, 2024 (EDT)

What about dates tied to in game events, especially of the mobile game variety? Super Mario Run's notification menu doesn't appear to have a web browser equivalent and there isn't a dedicated Super Mario Run social media account to my knowledge. For the major events (ie, the ones that promote other video games) a date could be tracked down. But all those Weekend Spotlights and other rotating events don't sound feasible to attempt to cite. I suppose they're at least isolated to one or so pages. Salmancer (talk) 18:07, November 14, 2024 (EST)

Retrieved from "https://www.mariowiki.com/index.php?title=MarioWiki:Proposals/Archive/70&oldid=4434722"