MarioWiki:Proposals/Archive/78

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

Dictate that names for musical themes without original names fall under derivation

canceled by proposer
I would like to propose the following change to the below section in the naming guidelines for musical theme titles:

Current:

• If no original name exists, the article should use the next suitable name selected from one of its other official names (for example, something like "Underwater Theme" or "Underwater BGM"). This may need to be decided via community consensus on a talk page.

Proposed:

• If no original name exists, the article should use a suitable derived name based on the names of reuses, arrangements, or other musical themes which play in similar contexts (for example, "Underwater Theme" or "Underwater BGM" for a theme which plays in an underwater level). This may need to be decided via community consensus on a talk page.

At present, many of these cases use the name of a reuse or arrangement. This proposal intends to treat such cases as falling under derivation, seeing as reuses and arrangements are often intended for different contexts, and as such their names may not directly apply to the original theme. This incompatibility is also directly acknowledged in the naming guidelines' reasoning as to why original names should be used over those of later appearances.

As a result, this change is also intended to allow for derived names which are more accurate to the context behind the original versions of these themes. For example, the themes for Mario Kart courses such as that of Vancouver Velocity from Mario Kart Tour, which is currently named "Tour Vancouver Velocity" - the name of its Mario Kart 8 Deluxe arrangement. The presence of the "Tour" prefix is specific to its Mario Kart 8 Deluxe appearance, with past precedent from themes such as "Rainbow Road" from Super Mario Kart and "Kalimari Desert" suggesting that an official name for the original theme would not use it and instead simply be "Vancouver Velocity".

Proposer: Polley001 (talk)
Deadline: August 13, 2025, 23:59 GMT

Support BGM

1. Polley001 (talk) Per proposal.
2. EvieMaybe (talk) tentative proposal EDIT: support, not "proposal". proofread your stuff, evie! for now. i agree with the example given, but i worry that without solid guidelines, this implementation could lead to some issues.

Tour Oppose Overpass (theme)

1. Altendo (talk) Per EvieMaybe in the other option, funnily enough. I don't think this proposal has solid enough guidelines and could cause some issues. I believe that what Evie said about this being a "tentative proposal" means that this should have required a bit more thoughtwork (like through discussion) before making a proposal. The example shown is something I can agree on, but that's just an example, and how this proposal affects other pages is something I am not so sure about.
2. Salmancer (talk) This is one of those proposals where we go "Yes, problem solved!" when it passes and then a week later go "Oh. Oh. Oh no..." Because yes, it does fix Vancouver Velocity. How many more articles is it going to affect? Are there going to be cases where we have the name of only one jingle in one game and assume that every other unnamed jingle in that game follows from the example we have? Heck, sometimes songs genuinely have nonsenical names: who'd ever thought that "Ground BGM (Super Mario Bros.)" and "Invincibility BGM" would have the same kind of name when the first is a regular looping track meant to theme levels set above ground and the latter is a very short looping track meant to inform the player that they are currently Invincible Mario? (Well, except Nintendo I guess). Enemy variants, which this proposal allowing for derived names is based on, tend to be much much simpler and less likely to deviate than song titles, especially when we leave the utilitarian world of Super Mario Bros. series games and Mario Kart games, so applying the policy meant for the first group to the second may well be dangerous in ways we have not thought about yet. Short answer: I can only retract this vote if this proposal clearly indicates examples of what kinds of articles are within its scope, so the wiki knows exactly what it's getting into if this passes.
3. Camwoodstock (talk) Per Altendo and Salmancer, but more pragmatically, we would prefer a rework of the music naming guidelines, as many people have brought up both on-wiki and in the Discord that, if you took things exactly at face-value as they are right now, you could create a genuine argument to move Totaka's Song to "Title Screen 2", a move that absolutely nobody agreed with when it was brought up hypothetically. We'd rather deal with untangling the mess that having Nintendo Music as the top-most priority has dealt us in only a few weeks of retrospect first, than worry ourselves with a few prefixes baked into song titles here-or-there.
4. PopitTart (talk) Opposing on the argument that this is not what the derived name policy is for. Derived names were instated to allow subjects with existing internal or foreign names to be moved to their trivially comparable English names, such as Comet Tico to Comet Luma and Fire Gabon to Fire Spike. It does not apply to replacing existing official English names, or making up names that aren't derived from a non-English name for the subject.

Permit creation of categories based on "microgame" themes

Create categories 6-0
Microgames in the WarioWare series (e.g Super Wario Bros., and Tooth Haste) have "themes"; microgames with a special setting (e.g Intro Games, and That's Life). Now, despite the microgames themselves having "themes", no themes on the Super Mario Wiki has categories on them. I'm proposing to permit creation of said categories. I know, there will be some exceptions (e.g Beat-Down, and Track and Field) since they don't have "official" themes. Please note that this is just a proposal for "themes" categories: this proposal is not intended for creation of categories based off the "controls" (e.g mircogames with "Twist" or Touch" controls) or "creator" (e.g Mona or Dr. Crygor). Also, microgames like Breaking Up can have "Fantasy" and "IQ" categories, since they have both theme in different games.

Proposer: PawPatroler (talk) (blocked)
Deadline: August 3, 2025, 23:59 GMT

Themes for the win! (support)

1. Tails777 (talk) I'm kinda on board with this. While maybe not every microgame belongs to a theme, many of them do, particularly ones from WarioWare Gold and recurring Nintendo themed microgames. I don't see any harm in creating categories for these, especially if one were to want to see all options in one place.
2. Salmancer (talk) I'm fairly certain the reason microgames don't have theme/genre categories is that no one wanted to edit hundreds of articles to add them. It is an official grouping of things that is more than 10 strong. You probably could have just made the categories without a proposal.
3. Arend (talk) Kind of surprising that we haven't done this sooner. Yes, we probably wouldn't be accounting microgames from Twisted, Touched, Smooth Moves and Move It due to most of the microgames being sorted by form and gameplay style, but Mega Microgame$, D.I.Y. (and Showcase), Gold and Get It Together do show them having all these themes, so...
4. Rykitu (talk) Yes
5. Shoey (talk) Yeah sure per all.
6. Scrooge200 (talk) Would make a lot of sense, and Gold retroactively gives categories to a lot of microgames.

#PawPatroler (talk) I believe themes should have categories.

Comments

Also pointing out we should really stick to things in the user interface, so no categorizing every mircogame of double length in "Category:IQ microgames" Salmancer (talk) 22:51, July 19, 2025 (EDT)

Since presumably this requires going a large number of microgames in the series, we should probably also categorize them by creator and by their WarioWare Gold control type. Salmancer (talk) 22:51, July 19, 2025 (EDT)

Please note that this is just a proposal for "themes" categories: this proposal is not intended for creation of categories based off the "controls" (e.g mircogames with "Twist" or Touch" controls) or "creator" (e.g Mona or Dr. Crygor).

--Tails101 (talk) 23:02, July 19, 2025 (EDT)

...why is it spelled "mircogame" instead of "microgame"? — eviemaybe (talk / contributions) 11:36, July 22, 2025 (EDT)

I think that's a spelling error. Maw-Ray Master (talk) 14:26, July 22, 2025 (EDT)

Add visual editor back

canceled by proposer
Now I know that people have tried this proposal a bajillion times before, but not having a visual editor may make us lose Super Mario fans that don't know how to code with this wiki's code to fandom wikis because Fandom automatically has a visual editor on any wikis created through their service.

Proposer: Colin's world 3 YT (talk)
Deadline: August 18, 2025, 23:59 GMT

Support: Add back visual editor

1. Colin's world 3 YT (talk) Per proposal
2. Stache (talk): I'm gonna be bold with this one, even though it's going to be defeated right by almost everyone else anyway. However, I support the addition only if it's not used as default option, and make it well hidden from new users or restrict the use to the more established users who have a need for as a compromise in my opinion.

Oppose: don't add back visual editor

1. Camwoodstock (talk) Visual editor leaves behind messy, borderline unreadable source text that makes editing more cumbersome for all involved--this point has been explained in basically every prior proposal, so we won't harp on it too much. For the point the proposal brings up, however, it is not that hard to learn how wiki syntax works; if you know how to bold a message in Discord, you know how to type wiki text. The barrier for entry is so low, it's practically non-existent, and the cost of adding visual editor and gumming up a ton of pages indiscriminately is way too large in comparison to the "problem" of new editors possibly being confused when they see {{Curly brackets around a template's name}}--something that can be explained away rather quickly. EDIT FROM THE FUTURE: Also, a good chunk of wiki syntax is actually explained away in a handy cheat-sheet in the "> Help" drop-down menu in the editor itself. Could this be made clearer? Probably. But if you know it's there, it can help explain the bulk of strange syntax that may be intimidating to a newer editor.
2. Jdtendo (talk) Per Camwoodstock.
3. EvieMaybe (talk) hot take: being inaccessible to people unwilling to learn even the slightest bit of wiki syntax might be a good thing?
4. Xiahou Ba, The Nasty Warrior (talk) This wiki never had visual editor to begin with.
5. Sparks (talk) Per all.
6. Polley001 (talk) Per all.
7. JanMisali (talk) Per all.
8. YoYo (talk) its not here for many reasons, it's foolish to assume such reasons do not exist. Also what Evie said, it's like saying "we need to make game development more accessible to people who don't know the most basic programming". it makes no sense, it's only going to lead to sloppy disasters.
9. DryBonesBandit (talk) Per all. Here’s hoping for an early close.
10. Altendo (talk) While I am for accessibility, we shouldn't add a feature that could cause more harm than good.
11. Sdman213 (talk) Per all.
12. Dominoes (talk) Per all.
13. Rykitu (talk) Per all. The Mario Wiki does not deserve the Visual Editor, case closed.
14. Pseudo (talk) Per EvieMaybe, there being a certain bare minimum requirement for understanding the underlying functionality of the wiki is very much a good thing in my view.

Comments about this proposal

"Add visual editor back", "add back visual editor"... that implies that the feature was already added at one point, but then removed later. However, I'm pretty sure that the feature had never been added before in the first place. Just because it's been the umpteenth attempt to add it doesn't mean it had been added once before. rend (talk) (edits) 02:40, August 5, 2025 (EDT)

As a bit of an aside, since it's related to the conversation of how accessible the wiki is to edit, personally, we disagree with the idea that "oh, someone put off from learning Wiki Syntax should just not bother". Mostly because that's extremely reductive and can lead to some pretty bone-headed decisions all on its own (trust us, we've seen how that can backfire!), but the far more productive thing is not to implement a tool like visual editor, but simply make the tools to learn syntax more accessible. It's extremely easy to forget, since we know it's probably long since become a part of the peripheral visions of Literally Everyone In This Proposal, but the editor literally has a drop down menu labeled "Help" that's a cheat-sheet for wiki syntax, built into the editor itself. Anyone could just clicked this at any point, and there's an almost entirely complete list of basic wiki syntax in there--the only obviously missing thing we found was, funnily enough, {{Template syntax}}, something we noted would be potentially confusing to a new editor that is worth learning early on.
For one, how long has this been here?! Was it some plug-in that added this, or is this literally just part of MediaWiki and we've somehow never noticed before? For two, though, we feel like just raising awareness that that's even there in the first place could go a long way in helping catch new editors up to speed in a way that is both welcoming (i.e. not exclusionary to those that don't have prior experience) and productive (i.e. they can immediately figure out from there how to write perfectly clear and clean wiki syntax.)
Obviously, if someone doesn't want to bother learning even with a handy list of resources baked into the editor, then that's very much a "them" issue, so-to-speak. You can lead a horse to water, etc. But quite frankly, the bar for "learning wiki syntax" is a lot lower than some people might assume it is, and we'd prefer a push to bring awareness of how surprisingly straight-forward wiki syntax can be, rather than putting down newbies that don't know better. If that makes sense, anyways... It's 3am here, and we're not quite sure who's in the proverbial driver's seat here. ^^; ~Camwoodstock ( talk ☯ contribs ) 03:05, August 5, 2025 (EDT)

Clarify Korean romanization

Adopt Revised Romanization as specified 9-0
After Chinese and Russian, it's about time we tackle Korean romanization.

The most prominent system for romanizing Korean is Revised Romanization of Korean: not only is it the official Korean romanization system in South Korea, it is also already used throughout the wiki for Korean names. It is therefore natural that we formally adopt Revised Romanization. However, there are some discrepancies that I would like to address.

Firstly, some Korean names on the wiki currently use a transliteration variant which converts each jamo (Korean letter) to the same Latin letter regardless of its position or pronunciation (e.g., "ㅂ" is always transliterated b). This proposal aims to adopt the actual Revised Romanization, which takes Korean's phonology into account: e.g., "랩" must be transcribed raep like it's pronounced, not laeb like it's transliterated.

Secondly, some ambiguities can arise in Revised Romanization, such as ui that could be two vowels ("우이") or one vowel ("의") if no symbol is used to disambiguate them. To avoid that, we should take inspiration from Wiktionary's guidelines and use apostrophes to prevent ambiguity in some syllable boundaries. Apostrophes are preferred over hyphens for this purpose so that hyphens can be used for semantic division only: e.g., "강원도" Gang'won-do, with do meaning "Province". Note that this convention is already in use on the wiki.

An apostrophe must be inserted:

• Between two separate vowels that could be mistaken for a digraph (ae, eu, eo, oe, or ui): e.g., "루이지" Ru'iji vs "릐지" Ruiji, "애우" ae'u vs "아으" a'eu.
• Between a syllable that ends in k, t, or p and a syllable that starts with the same consonant: e.g., "앜카" ak'ka vs "아까" akka, "합피" hap'pi vs "하삐" happi.
• Between a syllable that ends in ng and a syllable that starts with a vowel, y, or w: e.g., "망아" mang'a, "강원" Gang'won.
• Between a syllable that ends in n and a syllable that starts with g: e.g., "만가" man'ga, "간권" Gan'gwon.

(Some of the example words above are meaningless and only serve to illustrate the rules.)

Proposer: Jdtendo (talk)
Deadline: August 7, 2025, 23:59 GMT

Support: adopt Revised Romanization as specified

1. Jdtendo (talk) Per proposal
2. Camwoodstock (talk) If this is already what we do for the majority of pages, we may as well make it officially part of the style guide. Per proposal.
3. Altendo (talk) This makes it easier to romanize without disambiguating. Per proposal.
4. EvieMaybe (talk) per all
5. Mario4Ever (talk) Per all.
6. Power Flotzo (talk) Per all.
7. LadySophie17 (talk) Per all.
8. Scrooge200 (talk) Per all.
9. Dominoes (talk) Per all.

Comments (KorR)

I might be wrong here but does the wiki not already use this? - YoYo (Talk) 03:48, July 24, 2025 (EDT)

Currently, there is no Korean romanization system in the wiki's guidelines. Many romanizations of Korean names on the wiki already use the system described in the proposal, but it's better to formally adopt it and add it to the romanization guidelines, alongside romanization rules for other languages that have been determined by previous proposals. Jdtendo^(T|C) 06:04, July 24, 2025 (EDT)

Include the wiki's policy on unofficial strategy content in its rules

do not add policy 1-7
Generally speaking, this wiki seems to have a stance of not allowing any unofficial strategy content on its pages. It is also already self-evident to most users that this wiki is to be an encyclopedia of strictly factual information, and not a strategy guide. However, other more subtle types of unofficial strategy content can sometimes become harder to identify, as it may often overlap with content the wiki does explicitly cover; glitches are a prime example as many are incorporated into the core strategy of their origin games, such as the BLJ for Super Mario 64.

An example of a case I believe to not overlap in the same way is the existence of shortcuts for Mario Kart tracks that are not intended but also not glitches; their subsequent documentation is done in an objective manner that naturally fits alongside other shortcuts for the same track, but they nonetheless count as unofficial strategy content and would thus would be breaking the wiki's rules... if the rules ever actually stated the wiki's stance on such content.

As is, not a single page offers any mention of unofficial strategy content, despite the wiki's strict enforcement of removing such content, and I believe it would be in the wiki's long term best interest to remedy this. This proposal would aim to update the wiki rules with a definition of unofficial strategy content, and have them clearly state to what degree it is permitted on this wiki. I am operating under the assumption that the wiki's stance is to be something along the lines of "No unofficial strategy content that does not fall into a category already covered by the wiki", and that the best place for it would be the MarioWiki:Good writing page; however, I will of course leave such decisions to wiki staff.

Update: The primary area of contention seems to be the idea that the policy itself of generally forbidding unofficial strategy content is unjustifiable. I cannot emphasize the point enough: That does not matter for this proposal. This proposal is solely about incorporating the existing policy, as it is already enforced, into the wiki's actual rules, regardless of what that specifically looks like. If the policy is deemed unjustifiable, declining to add it to the rules will not improve that situation in any way, it will only help to muddy the semantics of what the policy actually is or is not. Adding it to the rules would instead yield better transparency, clarity, and consistency that would make amending such a policy easier if needed, along with better accessibility for editors.

Proposer: RocketLauncher (talk)
Deadline: August 8, 2025, 23:59 GMT

Support

1. RocketLauncher (talk) Per proposal.

#PawPatroler (talk) We should go with this.

Oppose

1. Hewer (talk) It seems this proposal is assuming that the wiki not having this rule is some kind of accident and doesn't really provide an argument for why it's a rule that we actually should have. I believe the wiki should cover anything it can that's objectively factual about the contents of the Mario games. Why shouldn't we cover unintended shortcuts if we're covering glitches? One is no more unintended than the other, and you could even make an argument that these shortcuts fit the definition of a "glitch" due to being unintended (we've already got coverage of multiple "skips" on List of Mario Kart 64 glitches). This feels like just an arbitrary limitation on the wiki's coverage. (Also per my comments here.)
2. Camwoodstock (talk) A question we've had since the original talk, which admittedly, we didn't ask as we're stuck on mobile, is... What do we do about World 4-3 (Super Mario Bros. Special)? For those not aware, World 4-3 in SMBS is functionally impossible unless you know about a glitch with the game, and how to prevent it from creating an unwinnable scenario. If the idea is to, in the extreme case, cull glitch coverage for being "too strategy", what exactly do we say about a level where it is entirely impossible unless you know about a glitch? This proposal fails fo address this, making no real attempt to assert some path forward for clarifying what actually counts as "strategy", so we don't think we feel confident in supporting this.
3. YoYo (talk) as a wise Hewer once said, "Why establish a rule if you can't justify it?"
4. Glowsquid (talk) My scorching hot take is that including "strategy" content should be No Big Deal and that if anything, we should have more coverage of "strategy" content. I surmise that approximately 99.98978% of people who've ever read our NSMB level pages did so because they wanted to know where the Star Coins are and not because reading a flat dry description of a Mario level is some kind of pleasurable or enlightening pursuit.
5. Rykitu (talk) As a wise YoYo once said, "as a wise Hewer once said, "Why establish a rule if you can't justify it?""
6. Altendo (talk) I'm not going to continue with this "as a wise [user] once said" joke, but per Hewer.
7. Scrooge200 (talk) "Strategy" writing and solutions is one of the main reasons I use the wiki, as a Mario player. Listing where collectibles are and how to get them is still part of the overall game design.

Comments

@Hewer: I definitely could have made this more clear, but the main idea is that the wiki currently has a strictly enforced policy, on something that can sometimes be ambiguous and difficult to identify, on the basis of no actual wiki rules. The wiki rules should then be updated to fix this. RocketLauncher (talk) 14:34, July 25, 2025 (EDT)

Does the wiki currently have a strictly enforced policy about this? I've been editing here for six years and this is the first I'm hearing about it. And should we enforce a policy if it doesn't actually benefit the wiki? I don't think "we're already doing this" on its own is enough justification for something like this. Also, like I mentioned in my vote, we already have some coverage of "skips" in Mario Kart courses, so it can't be that strictly enforced. Hewer (talk · contributions · edit count) 14:48, July 25, 2025 (EDT)

The example of unintended shortcuts in Mario Kart courses is not a point of intentional lax enforcement, it is a point of how the idea of unofficial strategy content can be difficult to identify to begin with, hence it going under the radar. RocketLauncher (talk) 15:05, July 25, 2025 (EDT)

So when has this supposed policy been enforced? Can you point to any discussion where people agreed to enforce this "policy"? And if the coverage of Mario Kart shortcuts that go against the policy was just an accident that went under the radar, why is the same not true of glitches? Hewer (talk · contributions · edit count) 15:47, July 25, 2025 (EDT)

I've been here for 15 years, this has never been strictly enforced at that level, only time it has was through second person writing (including implied "you's") or clear editorialization from editors(eg various recipe pages that used to say "Tayce T.'s Burnt Coal" should never be cooked because it's outclassed by "Tayce T.'s Tears"). If skips in Mario Kart tracks found through glitches or exploits are possible, such as the Grumble Volcano glitch or the Maka Wuhu glitch are found, they should be documented. Xiahou Ba^{(the Nasty Warrior)} 23:36, July 25, 2025 (EDT)

@Camwoodstock: I have already accounted for this by specifying that unofficial strategy content would only be excluded if it is not already a glitch or some other form of content this wiki does explicitly cover. Besides, that's not the point of this proposal: The proposal is about firmly establishing the wiki's stance on unofficial strategy content in the actual rules, not changing what the stance actually is. RocketLauncher (talk) 14:37, July 25, 2025 (EDT)

Can you provide any actual reason why glitches are more worthy of coverage than so-called strategy content? We should be able to justify our policies. Hewer (talk · contributions · edit count) 14:48, July 25, 2025 (EDT)

No, because that's again not the point of this specific proposal; this proposal is simply for establishing the current policy in the actual rules, not trying to justify the wiki's policy merits to begin with. If a policy's merits are questionable and it ought to be amended, then by all means that can happen afterwards. But that will be more difficult to bring to fruition if current policy is not clearly documented and clarified to begin with. RocketLauncher (talk) 15:05, July 25, 2025 (EDT)

Why establish a rule if you can't justify it? Why bother implementing a bad rule and then changing it if we can instead just not implement the bad rule in the first place? The point of rules is to help the wiki. Hewer (talk · contributions · edit count) 15:47, July 25, 2025 (EDT)

Do not have a separate "multimedia" section on recurring theme articles

passed 8-0
So one month ago, I made this proposal to restructure the recurring theme sections to center around a single "history" section (as most other articles on the wiki do). There were two options, distinguished by one trait: one of them would also create a "multimedia" section, which all of the audio samples would be moved to. That was the option that ended up winning, so when I began going through the navbox and making the changes to the articles, that was how I structured the articles.

However, in hindsight, I think having that option was a mistake — I don't think that way of doing it is very helpful to readers. It's best shown by Title BGM (Donkey Kong), which has the most appearances of any theme I got to, and is the article that made me commit to trying to change course on this. Separating the audio files from the descriptions of where they appear results in a history section of dry text unable to truly show the subjects its talking about, and a tower of media files that (personally) my eyes kind of slip around on. The media table template is also kind of unwieldy to edit with how it needs each parameter numbered for each file — that article has its media table go up to nineteen.

If this proposal passes, it'll basically be like the first option won in the aforementioned proposal instead of the second. (Would that make the proposal turn yellow on the archives? I'm not sure. Maybe it should...) As such, each audio file in the multimedia section will instead be in the history subsection of its debut game.

Proposer: Ahemtoday (talk)
Deadline: August 17, 2025, 23:59 GMTClosed early on August 10, 2025, 23:59 GMT

Support (theme sectioning)

1. Ahemtoday (talk) Per proposal.
2. Hewer (talk) I think this option is much better organised since it puts the audio files next to the text describing them, and it makes it easier to see at a glance which appearances of the theme are new arrangements.
3. Jdtendo (talk) Per Hewer.
4. Camwoodstock (talk) Per Hewer especially. A big Multimedia section at the end brings to mind something more akin to a Gallery, being a more-or-less comprehensive section of any Multimedia related to the subject. This is fine enough when the subject is "the Multimedia of a game" or "the Multimedia of a subject", but when the page itself is about multimedia, it instead becomes a pace-killer. Trying to refer to the multimedia in question in both its text and its excerpt becomes an infuriating tug-of-war, scrolling back-and-forth. In that case, it's very nice to have the multimedia just be in its corresponding section. We did get rid of Once and Only Once, so in an extreme case, we could even keep those huge multimedia tables at the bottom while still having the individual pieces of multimedia be in their corresponding sections; the form factor of a media table is far, far different from that of a gallery, so we could see the merit in doing both... Though, for now, if it's just one or the other, yeah, no, having these in their corresponding sections is a no-brainer.
5. EvieMaybe (talk) this would bring them back to how they were before, right? i'm down for that. for those concerned about space, maybe the music player could be placed on the side a la thumbnail image?
6. Scrooge200 (talk) As a multimedia-er, this makes it way easier to add new tracks, since they're already in the right order and you don't need to mess with the numbering of the files. It also makes it easier to tell which arrangements are missing: if the section lists four in its prose but only three files are in its audioboxes, you can clearly tell. If they were all crammed at the bottom, who would check?
7. Waluigi Time (talk) Yeah sure, I'm convinced.
8. Altendo (talk) Well, after WT's vote, I might have misunderstood what this proposal was meant to do.

Oppose (theme sectioning)

#Altendo (talk) Per Waluigi Time in the earlier proposal. Unless a section is expanded to include every game that cover is used in (which then creates problems in itself as a cover can be used in too many games to add to a section header without looking and, more importantly, being overwhelming, which is especially true with section linking and wanting to keep the table of contents easy to navigate), this will confuse users wanting to find a specific cover (like Waluigi Time's Player Down example). As for showing which games it appears in, putting the information in an audiobox would look and be a lot less overwhelming than in a header and table of contents. And if the solution is to just make additional sections for every game a cover is reused in, this would either create an inconsistency, which also adds to "dry text unable to truly show the subjects its talking about" for these sections on top of having the audioboxes only appear on the debut game and would in fact have the "dry text" sections dominate these pages due to a lot of these games reusing covers from previous games (unless multiple games are placed into a single section, which is unoptimal as I described earlier), or require audioboxes put into every section, which not only is overwhelming in itself, but also unnecessarily places the same file multiple times on a single page, which dramatically extends page load times.

Comments (theme sectioning)

@Altendo To begin with, I'd like to be clear that the plan is not to increase the scope of history subsections to cover multiple games or to have multiple instances of the same audiobox. Each game that has the theme in it gets its own subsection (which is happening anyway; that was part of the last proposal), and each distinct arrangement's first appearance has the audiobox. (I've edited the proposal description to hopefully make this clearer.) This means that, at maximum, a user looking for a specific appearance of the theme can just use the table of contents to find the game they're looking for, see where the arrangement of the theme originates, and then use the table of contents to find that section to see the audiobox. This does mean some sections will have audioboxes and others will not, but I don't view arrangements' first appearances getting the audiobox as inconsistent. This does mean that there will still be some dry text sections, but framing this as an issue that would be caused or even just aggravated by this proposal passing is... counterfactual. The dry text is already here. It is our current policy. I haven't implemented it because once I saw it was flawed, I was waiting to correct it, but it is our current policy. Moving the audioboxes into the history section cannot make the dry text dominate the sections more; it is the exact opposite of that. Ahemtoday (talk) 00:34, August 3, 2025 (EDT)

I get your point but I would still rather be consistent with how games are treated in this regard. When the audioboxes are all at the bottom, they make the sections consistent, as none of the non-media sections get audioboxes and the only one that does is like the "gallery" of the page. Altendo 00:50, August 3, 2025 (EDT)

It makes lots of sense for an article about music to have more prominently-placed audio files than an article about a game, I don't think we need to worry about "consistency" here. Hewer (talk · contributions · edit count) 05:45, August 3, 2025 (EDT)

Revamp Colorful Tables: PAINTING PARITY EDITION

NOTE: This proposal generally assumes some familiarity with Help:Table/creating and styling tables, namely some terms from it (wikitable, noalt, and especially the sentence "Any of the navbox series coloration classes are available to wikitables as well". You should be fine if you just use your eyeballs, but it's recommended you read up so you know what term's what.
In addition, we will refer to large headers as "banners" and smaller subheaders as "headers" throughout this, and our documentation, as that's what the CSS calls them.
Lastly, it should go without saying, but check out our proposed colors here!

We've mentioned a good few times before plans to renovate the various series-based table classes, and we finally found the time to finish the work on that. It's finally time to put it to vote, we think!

For awhile now, the wikitable class has had vague support for series-specific colors. For a very long time, this was limited to simply generic dk, mario, wario, and yoshi colors. These had some quirks, namely how only Donkey Kong had alternating colors, and how these were used very sporadically throughout the wiki (we'll put a pin in that.), leading a few people to assume that the DK one was actually the only themed wikitable.

On March 18th of this year, this was expanded to be any of the series or subject matters that have navboxes, a nice bit of parity... But it came at a hefty cost. Because of this parity with navboxes, color issues arose, as without curation between banners and headers, tables that only had single headers without corresponding banners had heavily washed out colors for those headers; this was most obvious with the Mario series table, which suddenly took on a rather orange hue by default. And these were still implemented rather sporadically, with a good few pages--such as Super Mario Land--using a hard-coded style.

All-in-all, an improvement on some levels, but there were definitely a few setbacks that have caused some problems. As the ones behind the bulk of the dark mode navbox colors, we figure we may as well try and fix the bulk of those. So, with this lengthy preamble over, we begin an even lengthier description of the changes we wish to make, and the ways we could make them.

For a start, please, PLEASE, refer to this page we have created to demonstrate our new colors!! It would be far too much to put this into the proposal itself, as it is 20k bytes in size, and to be frank, you don't need to understand the bulk of it beyond "do you think the colors look nice?". If you have questions for our design process, however, we've written notes that explain our design philosophy well.

Our intent is not to create a strict, to-the-letter rule, and merely a guideline for where colored tables should be, with wiggle-room to add them to other pages as editors deem them necessary. In addition, some tables (usually those on subpages) such as List of shops in Paper Mario feature their own bespoke colors to further illustrate their contents, in an internally-consistent manner. These are clearly done for their own reasons, and thusly, are excused from this conversation. In addition, template tables such as (but not limited to) media tables, NIOL tables, bestiary tables, or smash trophy tables, all have their own specifically-curated colors, and are excused from this conversation.

With that mouthful being said, however, just showing these colors, saying "that's nice", and adding the CSS classes necessary would not be enough to put this to action. We need a plan for two things; where are we deploying these series-based wikitables, and what aspects of them will we include? This comes the probably a bit annoying but thankfully easy to explain fun part... Showing you a bunch of small tables and/or yapping, and asking what you like more.

Where do we deploy these new colors?

On multiple occasions, proposals have been made to widen or narrow what pages get these series colors, and their sporadic use across the wiki has not helped matters. Let's settle this, once and for all, where we should absolutely be giving tables color.

• Use series tables on all game/multimedia pages, and their subpages: The maximal case. This could be confusing for franchise-wide staples, as it could cause scenarios where the same page has multiple different kinds of colored wikitable--we've yet to find an example through chance, but we would be unsurprised to learn if one existed. In addition, this could cause a problem if the source has its own form of colored text, such as on Cluck-A-Pop.
• Use series tables on game/multimedia pages, but not their subpages: Self-explanatory. The page for the work in question gets the corresponding series table colors, but subpages for things from those games and pages for franchise-wide or generic subjects do not have to worry about these. In essence, Super Mario Bros. Special gets the colored tables, but World 1-1 (Super Mario Bros. Special) wouldn't have these colors added to its Enemies/Items tables.
• Use series tables on game pages, but not their subpages, and not for multimedia pages: An edge-case arises with pages for non-game media; due to how navbox colors themselves work, every piece of alternative multimedia, from movies to manga to albums, shares a color. This was formerly not much of a problem, but our expanded music coverage has resulted in a slew of pages for various albums... With track lists... Shown in the form of tables. Nevermind that some of these albums are based on games, with their own corresponding series. This option seeks to put these specific pages on the backburner for now; if this option passes, in the future, we will be making a proposal to adjust the navbox and table colors to diversify these multimedia colors more, in the wake of our expanded scope for them. (...If this doesn't win, provided the colors are actually implemented, we will probably make that proposal anyways, but it will be less pressing.)
• Up to editor discretion (status quo): Self-explanatory, people will simply add the series table colors as they feel them necessary, with no particular strategy. We don't see the need, as our intent is to create guidelines with room for curation efforts to enable this sort of thing anyways, and we would like to set a baseline, but the option is there.
• Nowhere, use stock colors for all/deprecate and retain as a legacy function: The minimal option. This would, in effect, repeal the "Allow colorful tables" proposal by Scrooge200, set back on July 9th, 2024. The series-specific colors would be kept as a legacy function, strictly for personal use on things such as user tables or for legibility on old page revisions. The tables which had color for more specialized reasons (direct curatorial vision, or being a template) will go untouched, since, as mentioned, this proposal does not concern them. Of course, it should go without saying that if this option succeeds, the other polls are mostly rendered moot, only impacting the legacy tables we leave behind--if you do this, we highly suggest voting the other options' status quo choices.

Which color set?

Samples will be provided for each table beyond this point (based on the Super Mario series set), so you can at least look at something and tell what you're voting for. However, this is fairly self-explanatory. What set colors are we using for these tables? (Before you ask, there is not an option for the legacy colors, as we had only made slightest of slight adjustments to those colors when making our own--namely as part of dark mode parity stuff, and one question below. As a result, there's not a reason we can think of to specifically use only the four legacy colors, over the full breadth of options.)

• Proposed set: These ones that we linked above, on multiple occasions.
• Navbox/status quo set: Self-explanatory, this uses the exact same colors as the navboxes.

Proposed set	Navbox/status quo set
Banner Header Header Item Item Item Item	Banner Header Header Item Item Item Item

What do we do for background colors?

This is probably the most contentious one, when it comes to when we discussed this in the Discord, so let's run through the options here. All of these will be using the proposed colors, mostly for sanity's sake:

• Alternating colors for all! (status quo): Yes, the status quo is the maximal case; every series wikitable has the functionality to add alternating lines by default. While one may use the noalt class to disable these, we've heard plenty of criticisms for alternating colors, ranging from them being distracting, to how they break in tables with forms of colspan. However, alternating colors do have their use of distinguishing between rows on larger tables, or as a disability aid.
• Alternating colors optional, default is solid: While this is technically our status quo, this is only because noalt is a new addition; in practice, as of writing this, the former is the de-facto status quo. If this was chosen, rather than making alternating colors opt-out, they would be opt-in.
• Only solid color, either base or alt: This ditches alternating colors altogether, and leaves only one true color. We've allowed for two sub-options here; either the "base" background, or the "alternate" color that it, well, alternates to. The alternate is darker on light mode, and brighter on dark mode, reducing a bit of contrast.
• Only headers get custom colors: Alternatively, some concern has been shown that colored cel backgrounds as a whole are rather distracting, especially since it draws attention away from where it matters most; the headers. This would result in tables that have their standard backgrounds, but still retain a colored header. (The example for this intentionally omits the border colors, but this is a separate option, seen below.) It should go without saying, by the way, that if a table has its own colored cel backgrounds for whatever reason, such as to properly display a sprite on a given background color, it will not be impacted by this, being out-of-scope for this proposal. This option is not a rule about all tables, but a guideline about the relevant tables; isn't "no cel colors ever", it's "no cel colors baked into the series style", and something like the black background on the enemy list in Donkey Kong 3: Dai Gyakushū will go untouched by this.

What about dark mode background colors?

There's also the question of how to handle dark mode tables, as unlike light mode, the dark mode tables' colors, both on the current and our re-design, are generally made with the idea that the cels are a very, very dark color; thusly, having the stock background can throw the contrast off. The options here are the same so we may vote on these individually, but with one extra:

• Do the exact same as light mode, no adjustment (status quo...?): We apply the same thought process to what we do for light mode; either we have alternating colors, have them be optional, have only a solid, or only give headers colors. This is a "status quo" in the sense that there has never been a distinction drawn before.

Alternating colors	Solid (main)	Solid (alt)	Banners/headers only
Banner Header Header Item Item Item Item	Banner Header Header Item Item Item Item	Banner Header Header Item Item Item Item	Banner Header Header Item Item Item Item

If we do the proposed color set: What do we do for the borders?

A conundrum arises with the light mode tables, as the border colors on the stock/default table are a middle gray, whereas the series tables have a solid black. The question is simple; what do we do for these borders?

• All black borders: All tables, including the stock series-less wikitable, get a black border.
• Series keep black, stock keeps gray (status quo): Self-explanatory.
• All gray borders: All tables, including the series wikitables, get a gray border. This would work well if we decide only banners and headers should get their corresponding colors, and go for a background-less approach.

As for dark mode, a similar conundrum arises, but there is no option for giving stock a designated color, as it's pretty redundant, as all tables have a distinct border color on dark mode, including the stock one.

• Keep specified border colors (status quo): Self-explanatory.
• All gray borders: All tables, including the series wikitables, get a gray border. This, again, would work well if we decide only banners and headers should get their corresponding colors, and go for a background-less approach.

	Border colors	All gray
Series, BG colors	Banner Header Header Item Item Item Item	Banner Header Header Item Item Item Item
Series, no BG colors	Banner Header Header Item Item Item Item	Banner Header Header Item Item Item Item
Stock table	Banner Header Header Item Item Item Item	Banner Header Header Item Item Item Item

...We're sorry for the mountain of tables, but it was pretty dang important to us that someone could comprehend what's going on here without understanding HTML/CSS, and just their eyes. Better to have over-explained something obvious to some, than to have under-explained something obvious to none. With that said, however, we leave the rest in everyone else's hands. If you're confused about something, and we cannot blame you, please, just ask us in the comments.

Proposer: Camwoodstock (talk)

Where do we deploy these new colors?

Game pages, not multimedia pages or subpages 2-5-7-0-0
7 out of 9 voters (77.8%) approve the first place option.
Deadline: August 14, 2025, 23:59 GMT

Game/multimedia pages, and their subpages (maximum)

1. GuntherBayBeee (talk) Primary choice. This option is a better idea than my edits on not only the New Super Mario Bros. and Costume Mario pages, but also the WarioWare series microgame lists.
2. Ahemtoday (talk) It could end up a bit weird, but if we limit these table stylings to games or other media... they show up on a small fraction of the wiki. At that point, it feels inconsistent — plus I just really like how these tables look.

Game/multimedia pages, not their subpages

1. Camwoodstock (talk) This is our personal preference. Juggling table colors on stuff like item pages (especially those that appear across the franchise) or even more specialized pages like WarioWare microgames and souvenirs would probably be annoying, but on game pages (Super Mario Land, Mario Clock) or media pages (Super Mario (Kodansha manga), Super Mario Bros. Special (album)),
2. Altendo (talk) Despite my initial doubts, seeing how this color set works in dark mode made me confident in this idea. Per proposal.
3. GuntherBayBeee (talk) Secondary choice.
4. PhDedede (talk) This one makes the most sense to me.
5. Salmancer (talk) I just don't like reading large blocks of text on colored backgrounds. And if the primary distinction for colors is to tell readers what kind of article they are reading, then being on a page titled List of souvenirs in WarioWare Gold or any other page where a game title is appended to another phrase should communicate that well enough.

Game pages, not multimedia pages or subpages

1. Camwoodstock (talk) Secondary option. Admittedly, in the case of media, there is no such distinction between them at the moment--both in navboxes and in tables--and so, both end up the same orange-gold color. Especially in the context of track lists, we can see this being potentially distracting, depending on which background colors we have. Since we'd like to get the idea out first, we'd be fine to relent on this specific edge-case, and potentially come up with some colors for print media, music, and other such misc. media to use--heck, we could even back-port those over to navboxes. Sky's the limit, really. But, well, when we're voting on what's currently here, we can understand someone saying to wait on them for now.
2. Altendo (talk) Secondary choice.
3. EvieMaybe (talk) per Camwoodstock's votes
4. GuntherBayBeee (talk) Tertiary choice.
5. Scrooge200 (talk) I can see the subpages thing messing with articles like List of hidden Toads in Paper Mario: The Origami King and Pi'illos, which use specially colored tables to indicate areas.
6. Dominoes (talk) Per all.
7. Salmancer (talk) Same as above.

Up to editor discretion (status quo)

Nowhere, use only default colors for all tables/turn into legacy function (minimum)

Which color set?

Use proposed color set 8-0
Deadline: August 14, 2025, 23:59 GMT Closed early on August 7, 2025, 23:59 GMT

Proposed color set

1. Camwoodstock (talk) Of course, per proposal. It doesn't make sense that a Mario table ends up orange because that happens to be the color navboxes use for headers.
2. Altendo (talk) Per proposer.
3. EvieMaybe (talk) per.
4. GuntherBayBeee (talk) Per all.
5. Ahemtoday (talk) Per proposer.
6. Scrooge200 (talk) Clearly a lot of work put into this, and the new colors do work better for accessibility and dark mode.
7. Dominoes (talk) The proposed color set looks better to me as well.
8. PhDedede (talk) Having spent a good 30 minutes swapping between light and dark mode looking at the proposed table colors, I'm pretty confident in saying these look really good.

Navbox/status quo set

What do we do for background colors?

Alternating colors optional, default is solid 4-7-0-0-4
7 out of 11 voters (63.6%) approve the first place option.
Deadline: August 14, 2025, 23:59 GMT

Alternating colors for all! (maximum) (status quo)

1. GuntherBayBeee (talk) Primary choice. See above.
2. Ahemtoday (talk) I think alternating colors improve table readability in a worthwhile way in all circumstances, even if sometimes it's more minor than other times. Merged cells probably mess with it, but from experience on the Donkey Konga articles I can confirm they work fine with sortable tables. (3's Famicom stages mess up, but that's because I had to put them in a different color manually. Might need to think of a different way to do that...)
3. PhDedede (talk) I think the alternating colors help readability a lot and I've never found them distracting or otherwise be a detriment to the page even if rowspan makes it a little messy. And speaking personally, I really like how all the Donkey Kong games have brown table cels and (most of) the Yoshi tables have green cels (and have wondered for awhile why we never committed to yellow/purple for Wario games... perhaps because of the small sprites?), it gives the wiki's coverage of the sister series a bit of character that I would be a tiny bit disappointed to see it go.
4. Doc von Schmeltwick (talk) - Per PhDedede, they definitely help readability.

Alternating colors optional, default is solid (status quo kinda?)

1. EvieMaybe (talk) in my opinion, the gold standard for a table in this wiki is Super Mario Bros. Wonder's enemy table. adding alternating rows to it by default would break the sorting categories, and it would not aid in readability. if more tables could look like it, the wiki would look better overall... however, for the rare compact and dense tables where alternating colors would genuinely help with readability, it would be strange to not allow them. ideally, i'd vote for a "only headers get colors by default, and adding noalt brings in the alternating colors" option, but this is the closest there is to it.
2. GuntherBayBeee (talk) Secondary choice.
3. Dominoes (talk) Alternating colors can aid in readability, but as Evie stated above, sometimes they may also make sorting messier. Same goes for when rowspan is used, which breaks the sense of uniformity.
4. PhDedede (talk) Secondary choice.
5. Salmancer (talk) There's probably some useful uses for merging rows in tables. Enable alternating where we can, but this option means it won't accidentally break them.
6. Waluigi Time (talk) Secondary choice, it gets messy when rowspans come into play and at least shouldn't be forced.
7. Jdtendo (talk) Per Salmancer.

Only solid color (standard on table)

Only solid color (alt on table)

Stock color, only headers get custom colors (minimum)

1. Camwoodstock (talk) Funny to see this from the ones that brainstormed all these colors, suggesting that we throw half of the background columns away! So it goes, we suppose. We're quite a fan of the style seen on tables such as the ones on Super Mario Land, and admittedly, we modeled some of these header colors off of those tables from tables like it... However, on dark mode, the tables look far worse with stock backgrounds. You truly do need the contrast the darker cels bring. Besides, in our opinion, the headers are where the color is most necessary--you need to distinguish between the headers and the actual "body" of the table, after all.
2. Altendo (talk) Per proposer, again.
3. EvieMaybe (talk) secondary choice, per proposal and my above comments. i'm okay with ditching alternating rows if it lets us ditch background colors.
4. Waluigi Time (talk) The colorful headers are enough to give them a splash of color without being too over the top, in my opinion. We also frequently display images and sometimes colored text in these, and it's just easier to work with that if it's the same colors across the board.

What about dark mode background colors?

Alternating colors optional, default is solid 1-3-5-0-0-0-0
5 out of 7 voters (71.4%) approve the first place option.
Deadline: August 14, 2025, 23:59 GMT

Exact same as light mode background colors (status quo...?)

1. GuntherBayBeee (talk) Primary choice. See above.

Alternating colors for all! (maximum)

1. Ahemtoday (talk) For consistency with my light mode vote.
2. PhDedede (talk) As a dark mode user I very much think the colored cels are better.
3. Doc von Schmeltwick (talk) - Once again, per PhDedede above.

Alternating colors optional, default is solid

1. Camwoodstock (talk) While we definitely dislike the colors on light mode, on dark mode, we find the tables a lot muddier without their background colors and custom borders--in particular, it looks a lot worse on tables with only headers, and not banners. Hence, we have opted to allow them on dark mode.
2. Altendo (talk) Do I even have to explain?
3. GuntherBayBeee (talk) Secondary choice.
4. Dominoes (talk) Per above.
5. PhDedede (talk) Secondary choice.

Only solid color (standard on table)

Only solid color (alt on table)

Stock color, only headers get custom colors (minimum)

Give dark mode solid colors (standard), even if light mode does not

If we do the proposed color set: What do we do for light mode borders?

Series tables get a black border, stock keeps gray 3-4-2
4 out of 6 voters (66.7%) approve the first place option.
Deadline: August 14, 2025, 23:59 GMT

All tables get a black border (maximum)

1. GuntherBayBeee (talk) See above.
2. Ahemtoday (talk) I think saturationless gray borders cleaving through colored cells looks bad.
3. PhDedede (talk) Secondary choice.

Series tables get a black border, stock keeps gray (status quo)

1. Ahemtoday (talk) Might be my secondary choice? Might be my primary — the stock tables having the gray looks nicer in a vacuum but the black would be more consistent with other tables.
2. Camwoodstock (talk) Secondary option. We're fine with the series tables having black borders, but really don't like the solid black on the stock/default table.
3. PhDedede (talk) Per all.
4. Jdtendo (talk) Per Ahemtoday and Camwoodstock.

All tables get stock/gray border (minimum)

1. Camwoodstock (talk) Our personal preference. We think it looks nicer when considering our vote on the background colors poll; the dark borders on light mode would be extremely distracting!
2. Altendo (talk) Ugh...

If we do the proposed color set: What do we do for dark mode borders?

All tables get specified border colors 6-0
Deadline: August 14, 2025, 23:59 GMT

All tables get specified border colors (maximum) (status quo)

1. Camwoodstock (talk) We could swing either way on this one. If we have background colors, then border colors should absolutely change, and if you are planning on expecting us to change our vote on any of this, you might as well make it this one now. However, if we go for "only headers get color, on both light and dark mode", then these border colors should likely stay the way they are.
2. Altendo (talk) (this would have been blank if either of these proposals passed...)
3. GuntherBayBeee (talk) Per all.
4. Ahemtoday (talk) Per proposal.
5. Dominoes (talk) Per all.
6. PhDedede (talk) Per all.

All tables get stock/gray border (minimum)

Comments (it takes all the colors...)

I'm pretty sure the default status quo borders in Dark Mode are very different from what you CLAIM are the status quo Dark Mode borders at a later point... (they look black, and I think it actually looks better on the Dark Mode table than gray OR colored...) rend (talk) (edits) 18:05, July 31, 2025 (EDT)

Ah, that was a bit unclear. We should probably adjust that second table, as it isn't clear what is meant by "status quo" there, and on dark mode, there's functionally no difference between the bottom two rows (after all, the border's already "colored" gray.). In addition, the "status quo" on the first table is referring to the color set there, and in the status quo color set, the borders are globally set to #000 on light anddark mode for series tables. Try calling for a wikitable mario sm table on the wiki, and you'll see what we mean. In contrast, the "status quo" default borders (which we didn't touch, as we didn't bother changing the default at all except for the hypothetical alternating colors-enabled version) are actually gray on dark mode. We hope that makes more sense? ~Camwoodstock ( talk ☯ contribs ) 18:18, July 31, 2025 (EDT)

I think you misunderstand. Concurrently, every colored Dark Mode table uses the black borders (I've also tested wikitable dk, wikitable mario (which appears to be identical to wikitable mario sm?), wikitable yoshi, wikitable wario, and wikitable spinoff mk: all of them use black borders in Dark mode); THAT would be the status quo of said borders right now. But here, you claim that the status quo for the Dark Mode borders are colored borders, with not a single option for black borders at all. The colored borders are actually a brand new option that the wiki never used before (and I think it kinda looks bad because the border color is nearly indistinguishable from the main header color).
It's also kinda weird that there's no option for the dark mode tables to keep the gray color for stock tables but have the colored tables have the black or colored border (when the light mode border poll does have that option), which would be the actual status quo from what I can gather. rend (talk) (edits) 18:31, July 31, 2025 (EDT)

...Okay, we definitely should've been clearer about the borders. Just kind of in general, we're realizing, whoops! In a bullet-pointed list, so this hopefully doesn't get too tangly to decipher:

• The colored borders were a thing in the four original series border styles, but were removed in the current ones, which just use solid black. Our curated set of colors inherited this, as we thought it looked a lot better on dark mode... On light mode, however, we definitely think that the black borders are better. Hence, on light mode, they stay black, despite still being called "colored" borders. (They are "colored" differently from the stock table. Just, y'know, colored as #000 black.)
• The options, then, are to keep the specified border colors on dark mode what we currently use, or default to the gray that all tables use. As of right now, this is black on the series tables, and gray for standard tables, on dark mode.
• The light mode version has three options. One is to give every table, including standard tables, a black border, like the series tables do. This, obviously, would be redundant on the dark mode poll, as in that case, "like the series tables do" would, in the context of the new color set... Give it a non-black border. Which it already has.
• The problem, if we're on the same page, arises because, uh, we accidentally put "status quo" for colored borders, when on light mode, this is not the case. While it's the status quo on dark mode, and for series tables on the light mode, it is absolutely not the status quo for the default table on light mode. We have changed this by way of removing the "status quo" label--so, um, we suggest not referring to it like that in the future.

...As for "there's no option to keep the gray border for the stock tables", that's our voting options being a tad unclear, and admittedly, that's on us. This thing is, for better or for worse, kind of a spider web, so let's run through those again while disregarding our accidental use of "status quo" when we shouldn't. ;P

• In the case of the light mode poll, if you disregard our accidental use of "status quo" when it Isn't, the polls should hopefully make more sense--either to give all tables a black border (including stock), to have series tables use black borders but have stock tables retain gray, and to just give all tables gray.
• In the case of the dark mode poll, uh, both options would keep a gray border--our curated set sets them to gray, the current set sets them to gray, and the last option literally means they're gray. The standard tables will always have a gray border on dark mode.

We hope that makes at least a tiny bit more sense... Even if it took a lot to explain, WHOOPS. If this wasn't good enough, then 1) oh gosh we're sorry 2) please let us know what exactly we need to clarify on, and we'll do our best, we suppose... As an aside, we're starting to wonder if we should've given this proposal this much granularity--we were a bit worried about taking the Curatorial Sledgehammer and going "These are the like, 5 options, take it or leave it.", but maybe that would've been more comprehensible to your average layman. Ah, well. ~Camwoodstock ( talk ☯ contribs ) 18:51, July 31, 2025 (EDT)

Adopt a romanization system for Modern Greek

Adopt ELOT 743 Type 2 for Modern Greek romanization 7-0
(Promised, this is my last romanization proposal for the foreseeable future.)

Currently, the romanization of Greek names on the wiki is very inconsistent: χ becomes sometimes ch or other times kh, φ becomes f or ph, υ becomes y, i, or bafflingly e… We clearly need to decide on a standardized romanization system for Modern Greek, and preferably an official one. I propose that we adopt ELOT 743 Type 2, a transcription system created by the Hellenic Organization for Standardization in 1982. This system is quite faithful to Greek orthography, but takes prononciation into account for some digraphs (e.g., μπ is transcribed b at the start of a word, αυ is transcribed as af or av depending on the following letter…). It is used on Greek and Cypriot passports and was adopted by the United Nations in 1987, by BGM and PCGN in 1996, and by the ISO in 1997 as ISO 843 (Table 2). Suffice it to say, this is the most official romanization system for Modern Greek.

The romanization system is detailed in this document. Accents and diaereses found in the Greek text must be kept in the romanization (e.g., Δοϊράνι → Doïráni). However, marks that are used in some ELOT 743 variants for transcribing some letters in a reversible manner must not be used: e.g., η must be transcribed i, not i, ī, or i¯.

There are also a few other romanization systems that are less common:

• The former BGN/PCGN romanization system adopted in 1962 that was more faithful to Greek prononciation for the most part but included some uncommon letter sequences (δ → dh), could lead to some ambiguities (ga could be the romanization of either γκα pronounced [ga] or γα pronounced [ɣ­a]), and was abandoned in 1996 when BGN and PCGN switched to ELOT 743 Type 2.
• ELOT 743 Type 1 that is a reversible transliteration system that almost always transcribe the same Greek letters to the same Latin letters; it is more spelling-based than Type 2 and does not take prononciation into account (e.g., μπ is always transcribed mp, αυ is transcribed au…).
• The ALA-LC romanization system from 2010 that seems less used and bases the transcription of some letters on Ancient Greek (e.g., η is transcribed ē despite being pronounced [i]).

Proposer: Jdtendo (talk)
Deadline: August 17, 2025, 23:59 GMT

Support: Adopt ELOT 743 Type 2 (ypostirízo)

1. Jdtendo (talk) Per proposal
2. Altendo (talk) Per proposal.
3. Camwoodstock (talk) Per proposal. Its use in official Greek documents definitely helps matters, in our opinion. As silly of a sentence it is to say, if it's good enough for their passports, surely this methodology is good enough for our wiki.
4. EvieMaybe (talk) if the government and the UN use it, why shouldn't we?
5. Scrooge200 (talk) Per proposal.
6. Dominoes (talk) Per all.
7. Καπετάνιος Σκορβού (Kaptain Skurvy) Ανά πρόταση.

Further clarify Cantonese romanization

Implement as specified 5-0-0-0
(I suppose that's still not the end of romanization proposals, as I just thought of one.)

As decided on my last proposal, Yale romanization of Cantonese is used to romanize the Cantonese variety of Chinese for several reasons, including its English compatibility and uniformity with Bulbapedia. However, there are still some problems to be addressed and codified if we use the system.

There are no official rules (either from the Yale University or from official bodies) as to how syllables should be spaced. As with Hanyu Pinyin, Hepburn romanization and Revised Romanization of Korean, Yale romanization is capable of grouping syllables together to indicate compound words or specific nouns. Grouping syllables together makes the structure of the passage much easier to understand, and helps with making it more consistent when paired with the other romanization systems. However, Cantonese has a richer library of consonants to be used, so ambiguities can occur when finals of a syllable (or lack thereof) and the initials of the next syllable are joined together (this problem is completely avoided in Jyutping by always separating syllables with a tone number, but we have decided to go ahead with Yale).

Similar to the above romanization systems, we may use apostrophes to disambiguate syllables when needed. As mentioned above, there is no official spacing rules, and no websites using Yale that I could find give any rules. Bulbapedia also uses apostrophes for separation (e.g. 可達鴨 Hódaaht'aap), but sometimes still fail at disambiguating syllables: 水箭龜 Séuijingwāi is supposed to be read as Séui-jin-gwāi, but can be instead read as Séui-jing-wāi 水幀威; conversely, 夢幻 Muhngwaahn is supposed to be read as Muhng-waahn, but can be instead read as Muhn-gwaahn 悶㴫. In addition, sometimes an apostrophe is still inserted even if the syllable breaking is already clear (e.g. 鐵螯龍蝦 Titngòuhlùhng'hā, even though Titngòuhlùhnghā is unambiguous), rendering the apostrophe unnecessary. I cannot locate any place in Bulbapedia that clearly codifies the rules either, and it appears to me that whether an apostrophe should be inserted or not is up to the editor's discretion.

Therefore, based on other romanization systems and Bulbapedia's (general) convention, we may formulate our own spacing rules for when an apostrophe should be inserted. Note that:

• All characters here are spaced with interpuncts (·) for extra clarity.
• Unnlinked examples below have no particular meanings, and only serves phonetic purposes for demonstration.

Rule	Examples
1. An apostrophe is always inserted between two syllables with the second one starting with a null initial (including syllabic "m" and "ng"). If a syllable with initial consonant (except "h" and "ng", see rules 3 and 4) succeeds another syllable without a final consonant, no apostrophe is inserted. This is similar to Hanyu Pinyin.	呼fū·吸kāp fūkāp	福fūk·噏āp fūk'āp	打dá·壓aat dá'aat
	幸hahng·好hóu hahnghóu		下hah·誤ngh·襖óu hah'ngh'óu
2. Because a syllable with initial "y" (IPA [j]) followed by vowel "yu" ([yː]) is written as "yu" as if it were a null initial ([jʷyː], null initial "yu" actually does not occur), and because [jʊ] is also written as "yu", an apostrophe is also inserted between a syllable ending with a final consonant or "h" as tone marker, and a syllable starting with "yu". If a syllable with initial consonant (except "h", see rule 3) and vowel "yu" (a syllable with initial "ng" and vowel "yu" never occurs) succeeds another syllable without a final consonant, no apostrophe is inserted, similar to rule 1. As "y" never appears as a final, no apostrophe is inserted between a syllable not ending in a final consonant or tone marker "h" and a syllable starting with "yu", as it is unambiguous.	復fuhk·原yùhn fuhk'yùhn		父fuh·權kyùhn fuhkyùhn
3. Because "h" also serves the purpose of tone marker for tones 4, 5 and 6, an apostrophe is still inserted between a syllable of tone 1, 2 or 3 without a final consonant and a syllable with initial "h". This ensures that the "h" is clearly indicated as a consonant instead of a tone marker. No apostrophe is inserted between a syllable of tone 4, 5 or 6 without a final consonant (i.e. syllable ending with tone marker "h") and a syllable with initial "h".	瑪Máh·利leih·歐āu Máhleih'āu	瑪Máh·[利3lei]·睺hāu Máhlei'hāu	瑪Máh·利leih·睺hāu Máhleihhāu
4. Between two syllables, if a vowel (or "h" as tone marker) of the first syllable is followed by an "n" of either syllables and then a "g" of the second syllable, an apostrophe must always be inserted to separate syllables for more clarity. If the first syllable ends with "ng" and the second syllable has a null initial or initial–vowel "yu", an apostrophe is inserted as per rules 1 and 2. If the first syllable ends with "ng" and the second syllable has an initial (except initial "w" or initial–vowel "yu"), no apostrophe is inserted as it is unambiguous. This is similar to Wiktionary's approach to the Revised Romanization of Korean, except that "ng" may also appear as an initial.	假gá·牙ngàh gá'ngàh	緊gán·㗎gàh gán'gàh	梗gáng·啊àh gáng'àh	梗gáng·瑕hàh gánghàh
5. An apostrophe is inserted to separate a syllable with finals "k" or "ng" and a syllable with initial "w". If a syllable with initial "kw" succeeds a syllable with no final consonant, no apostrophe is inserted as per rule 1. If a syllable with initial "gw" succeeds a syllable with final "n", an apostrophe is inserted as per rule 4.	詩sī·狂kwòhng sīkwòhng		識sīk·王wòhng sīk'wòhng
	慢Maahn·慢maahn·龜gwāi Maahnmaahn'gwāi		慢Maahn·孟maahng·威wāi Maahnmaahng'wāi

Proposer: Dominoes (talk)
Deadline: August 18, 2025, 23:59 GMT

Support: Implement as specified

1. Dominoes (talk) 帊Paa3舖pou3鋪pou1數sou2 (Pa poupōusóu, "To count the number of towels that cover a storePer proposal").
2. Jdtendo (talk) Per proposal.
3. EvieMaybe (talk) per proposal. i really appreciate how thorough this is, by the way.
4. Altendo (talk) Per.
5. Power Flotzo (talk) Per all.

Reinstate lists of appearances on music articles

passed 13-1
Well here we are with the second counterproposal regarding something that passed last month, what a world! Recently, a proposal passed to reorganize music articles to use traditional history sections. That's all well and good, but this also included the removal of the appearances tables at the bottom of the pages. I'm not sure that was communicated as clear as it could have been, as well as offering no option to keep them while implementing the other proposed changes, but that's neither here nor there. I don't think that was such a great idea, so I'm proposing reinstating them. There's several benefits to these tables, some of which I'll admit could also be accomplished by rewriting the pages, but others not so much.

• They provide easy, at-a-glance information on the appearances of these tracks, including the title and composer for arrangements when available.
• They offer a chronological timeline of appearances, something that our history sections can't do because we organize them by subseries, and I happen to know that this is something plenty of people are interested in.
• It's more clear when information isn't available thanks to blank cells. Removing the appearances table on Staff Roll (Super Mario 64), for example, makes it unclear that we don't know the title for Mario Kart World's arrangement, or the composer behind it. In its current state, a reader may very well assume that Koji Kondo is responsible for all of this track's arrangements since he's the only composer mentioned with nothing to say otherwise. Keep in mind that this is an extremely common state of affairs for the franchise - we could explicitly state that some info is unknown in thousands of sections across these pages but I think that's a very poor fix.
• Appearances on albums are easier to find instead of being buried in game sections. We're talking about music here, so this is important stuff!

Additionally, the previous proposal argues that these are redundant, but it's an odd thing to say when we've already had similar tables on many character and enemy articles for a long time. I say we should have more, not less - and if we're going to remove them then it should at least be consistent across the board, but that's a potential discussion for another time.

Proposer: Waluigi Time (talk)
Deadline: September 1, 2025, 23:59 GMT Closed early on August 25, 2025, 23:59 GMT

Support: Bring back the lists

1. Waluigi Time (talk) Per proposal.
2. EvieMaybe (talk) per proposal, this makes perfect sense
3. Camwoodstock (talk) Per proposal. We don't see why the appearances table should be removed, seeing as it has an entirely different function from the prose list.
4. Hewer (talk) Per proposal, they're a handy feature of these pages.
5. Sargent Deez (talk) Per proposal.
6. Tails777 (talk) The history section is for detail, the appearances section is for a quick run-down. Still seems useful to me.
7. Wilben (talk) Per proposal.
8. Nintendo101 (talk) It's nice to have an easy to reference list in addition to readable texts.
9. Rykitu (talk) Per all.
10. Mario jc (talk) Per proposal, they should've stayed. I imagine they even made it easier for YouTubers to compile them for videos, which are a good way to showcase the arrangements (like this one, which credited the wiki).
11. SGoW (talk) big fan of credits
12. The Dab Master (talk) Per all.
13. Killer Moth (talk) Per all.

Oppose: Keep getting rid of the lists

1. Ahemtoday (talk) My issue with these sections is that... they're just a restatement of the article's history section in a different order and format. I don't think the benefits outweigh the redundancy.

Move Nintendo Music OST pages to just OST pages

canceled by proposer
So, ever since the introduction of Nintendo Music, we've made articles for every Super Mario Soundtrack on it. Although I think It's time for this to change. Now, I don't mean delete the pages entirely, I mean move them all to OST pages. for example, Super Mario Bros. (Nintendo Music) would be moved to Super Mario Bros. OST. The reason I think this is a good change is because these are just the game's OSTs. There's nothing making it specifically a Nintendo Music OST.

Proposer: Colin's world 3 YT (talk)
Deadline: September 13, 2025, 23:59 GMT

Support

1. Colin's world 3 YT (talk) Per proposal

Oppose

1. Camwoodstock (talk) While we can definitely see the want to move to a less reliant-on-a-mobile-app name for these pages, especially as our coverage of music-related subjects is on the rise in general, "OST" just... Isn't a good name to move these to. Simply put, how, exactly, would we denote between Super Mario 64 Original Soundtrack (the album release, from 1996) and Super Mario 64 OST (the Nintendo Music release, from 2024)? Unless someone happens to know that the abbreviation refers to Nintendo Music, and is then comfortable making the leap in logic that the one that's not abbreviated isn't just a redirect, but is its own separate release, the "OST" name does more harm than good.
2. Hewer (talk) The current article titles reflect how the soundtracks are named in the app more accurately as well as making it more clear that they are specifically about Nintendo Music, I don't see why this needs changing.
3. Waluigi Time (talk) These do have info specific to Nintendo Music like playlists and when they were added. Moving would just make things more unclear for no benefit and conflict with other soundtrack releases.
4. Arend (talk) The current format of [game name] with the (Nintendo Music) identifier is clear and good enough. The soundtracks are all named simply "[game name]" without anything else attached, after all, and the (Nintendo Music) identifier helps to specify where the soundtrack is coming from. Also, as Waluigi Time explained, these pages do actually feature Nintendo Music-specific information as well, so the claim of "There's nothing making it specifically a Nintendo Music OST" is factually incorrect. Titling them "[game name] OST", on the other hand, is not a good idea at all. Not only do none of the soundtracks on Nintendo Music even HAVE the term "OST" in their titles, but it's also an abbreviation that is never used on soundtracks that even call themselves the "original soundtrack". Even then, it only makes it more confusing when you take the soundtracks that were officially released prior to Nintendo Music into account. After all, Super Mario Odyssey Original Soundtrack is ALSO "just the game's OST", with the exception that it's not on Nintendo Music, while Super Mario Odyssey (Nintendo Music) IS.
5. Polley001 (talk) "There's nothing making it specifically a Nintendo Music OST" being blatantly incorrect kind of says it all, doesn't it?
6. Rykitu (talk) Per all.

Visual editors

No visual editor 1-16
The Super Mario Wiki should have visual editor, as it could improve the user experience by making it easier and more intuitive for contributors to create and edit pages.

Proposer: Wariowarefan100 (talk)
Deadline: September 9, 2025, 23:59 GMT Closed early on September 2, 2025, 23:59 GMT

Support

1. Wariowarefan100 (talk) Per proposal.

Oppose

1. Ahemtoday (talk) Hasn't even been a month since the last proposal about this.
2. Rykitu (talk) Read below.
3. Camwoodstock (talk) We've been over this. Visual editor leaves messy source text that does more harm than good, and if someone is particularly struggling to understand Wiki syntax, the editor literally has a "Help" drop-down menu explaining the vast majority of it.
4. Nelsonic (talk) Per Camwoodstock.
5. EvieMaybe (talk) per the thousand times this has been proposed and rejected
6. Polley001 (talk) Per futility (and Camwoodstock, more importantly).
7. Altendo (talk) Per what I said in the previous proposal about this.
8. YoYo (talk) per my previous comments in the previous proposal from literally this month (countdown to this proposal being vetoed starts now.)
9. Hewer (talk) Down with visual editor.
10. DryBonesBandit (talk) Per all. Visualizing this proposal being thrown into the garbage.
11. Scrooge200 (talk) Not a fan of visual editor. I think requiring source has vastly improved this wiki's general editing. It doesn't take much to learn the syntax, there is a help menu and you can find examples everywhere on pages.
12. Colin's world 3 YT (talk) The visual editor is just for lazy slobs that don't wanna learn the simplest coding language ever.
13. SeanWheeler (talk) Even on FANDOM, I've preferred the source editor.
14. MeritC (talk) Per all; plus, we have a "Show Preview" button on here for a reason on each article's "edit" tab (especially in regards to main article pages where we're allowed to make our edits themselves whenever it is necessary).
15. Salmancer (talk) I don't really like the "minimum skill requirement" argument, gaming is for everyone and so should editing, but per everything else. Even without that argument, visual editor takes forever to load and is easy to accidentally click when a user wants to use source editing instead. Such mistaken visual editor selections swallow up valuable time for the sake of a feature which doesn't create better pages on its own.
16. The Eggo55 (talk) Per all.

Discussion

I seriously cannot be the only one who thinks the phrase "makes it more easy and accessible for anyone to edit" sounds extremely bleak? like... anyone can edit, anyone is able to access the editing tools, anyone can make some sloppy unpolished nonsensical edit they want because they were handed a tool that makes it so experience and ability are merely just a suggestion! tell me that's a good idea, just try and convince me it's a good idea to do that, especially on a site that's going to be mostly used by children. tell me that we should be letting children with zero experience with any form of documenting and programming make whatever contributions they want as simply as possible. there needs to be some kind of ability minimum else the whole place will be constantly filled with low effort sloppy edits that break every page. does it sound mean to say that? no, it doesn't. - YoYo (Talk) 08:13, August 27, 2025 (EDT)

I disagree the site is mostly used by children. Yeah, they're the main audience of Mario, but I get the impression most making good edits are lifelong fans. I do agree with the rest of what you say though, and think a visual editor may be an opening for less experienced users. Sounds like a good idea, but will equate to more vandalism and low effort edits. Also, I like the cozy and exclusive feel Mario Wiki has versus Wikipedia  — 21:19, August 31, 2025 (EDT)

Can we now bring in a "no more visual editor proposals" rule? This has been brought up again and again, and I don't see a change of consensus coming any time soon. Drago (talk) 14:04, August 27, 2025 (EDT)

I would rather a guideline page or section "Proposals that have failed multiple times in the past". Rule seems too... declarative, and there are things that have failed multiple times but succeeded eventually. Salmancer (talk) 14:07, August 27, 2025 (EDT)

Plus, having all all the failed proposal arguing for something in one place would encourage a further proposal on the topic to address the opposition for the older proposals and/or approach the topic from an angle those proposals did not. Salmancer (talk) 16:36, August 28, 2025 (EDT)

Absolutely not. We've seen wikis implement this sort of thing before, and have it backfire spectacularly on them. Even if the odds of adding visual editor are basically nonexistent, drawing a hard line and trying to ban "futile" proposal subjects is a huge no-no. ~Camwoodstock ( talk ☯ contribs ) 16:29, August 27, 2025 (EDT)

Nah, the first section says, "[Proposals] must have a strong argument supporting their idea and be willing to discuss it in detail with other users," and rule #9 says "Proposals cannot […] overturn the decision of a previous proposal that concluded less than four weeks ago," which is enough to mostly prevent this kind of stuff. Though I do agree with Salmancer about a dedicated section, which can be added without explicitly banning these proposals. The Dab Master

Might be just me, but I'm not in the mood to make another rule to keep track of something. If there is a proposal like this again that doesn't bring new arguments (such as in the future if VisualEditor is lightweight, efficient, and idiot-proof), ask for a staff member and we can cancel it. It's me, Mario! (Talk / Stalk) 15:47, August 29, 2025 (EDT)

I mean is it possible this one can be cancelled rn, I've never seen a vote ratio this horrendous before - YoYo (Talk) 06:11, September 1, 2025 (EDT)

Add an "abandoned" parameter to Template:Personal-file

Add parameter 13-7
This is pretty self-explanatory to explain what we want, but why we want it is a bit more roundabout. In short, we want the template to have the ability to mark its corresponding file as "abandoned", and, like Category:Files to be used, put the file in a category separate from Special:UnusedFiles, preventing it from appearing in the list.

Something that's irked us for awhile now is how a good portion of Unused Files (roughly 20% of it) has been clogged by personal files from users that have long since removed those images from their profiles, but never thought to request the file's deletion or other such. As a result, it both makes the Unused Files page that bit more cumbersome to navigate, and also gives a slightly skewed read on the Main Page's to-do bar... All in the pursuit of images like this:

...This image is only one year younger than my younger sister. We don't think it's getting used anytime soon. However, we feel rather skeeved about the idea of nuking old user images, mostly for the sake of old user page revisions, but also, it just kind of feels wrong. Hence, we'd like some meta-category to section these off and get them out of the Unused Files list. Heck, in some cases, maybe they could be adopted by other users, no longer being abandoned?

As for syntax, we think it's fairly straightforward how it should work internally, as it'd be roughly akin to how Template:Future-use works. Marking a user file as abandoned should be as simple as adding |abandoned=y to the template itself, and if this is set to true, deploy the whole "include only, a link to itself" thing.

Proposer: Camwoodstock (talk)
Deadline: August 26, 2025, 23:59 GMT Extended to September 2, 2025, 23:59 GMT

Support (add abandoned parameter)

1. Camwoodstock (talk) Per proposal.
2. The Dab Master (talk) Per proposal.
3. Rykitu (talk) Per proposal.
4. PopitTart (talk) Unused user images are very different from unused images intended for wiki use. Per proposal.
5. EvieMaybe (talk) per proposal
6. YoYo (talk) Per PopitTart especially
7. Sorbetti (talk) Per the pleasure of remembering.
8. Aomaf (talk) per proposal
9. Bro3256 (talk) Per proposal.
10. Scrooge200 (talk) The thought of deleting these images that may never have been preserved elsewhere just makes me feel really bad, like we're erasing parts of the wiki's early days. If someone wants it deleted, they can say so. We shouldn't just assume they do.
11. Altendo (talk) Per Scrooge. I understand some of the points the opposition has brought up but deleting these images that might never have been uploaded anywhere else feels like mutilating a time capsule, especially if these images no longer exist outside of the Super Mario Wiki, which is plausible considering how old they are. And even if these images can be viewed and restored by administrators, I still find it unfair to lock the ability to let others see these images to them, as they can choose not to restore them but rather to keep it a secret so only they can view it, and even if they can be restored upon the original uploader's request, I fear that most of them have since left the wiki, with some having been inactive for over a decade, which very likely would lead to this being moot.
12. Colin's world 3 YT (talk) I think this parameter should be added, but only if an image isn't used by the user that uploaded it but instead another user put it on their userpage, like File:CHEESE!.PNG shouldn't be deleted, even if Master Crash stopped using it, because 95 other users are using it still, so Master Crash wouldn't mark it for deletion, they would mark it as abandoned.
13. Reese Rivers (talk) Per proposal, and PopitTart/Scrooge/Altendo.

Oppose/Status Quo (it's unused, isn't it?)

1. Trig Jegman Been awhile since I've done this so apologies if the formatting's wonky. I don't agree with this, as user images as a whole should generally be limited for a reason; These images aren't meant to be a focus of the site, and if they're not going to see a reasonable use then there is no sense in keeping them present. We already delete images that don't get used within 24 hours so what makes an image that becomes unused much later down the line any different? What purpose would these serve? Would people really truly and honestly go through these for any valuable merit? More than a cursory "oh cool" glance, are a majority of these images actually going to impact anybody that's not the original uploader/user of the image? What about the people who have forgotten this site only to remember it years later only to find things considered embarrassing or even private information—wouldn't they kind of want that information to have been scrubbed when it wasn't relevant? They might have blanked their user page(s) for a reason. Nothing says images can't be undeleted if absolutely necessary, and the impact towards more important content is minimal. If anything, a full clear-out will still enable the ability to more precisely go through unused materials. It makes more sense to just delete things that have not been used to me, at least. Also, doesn't this kind of constitute a policy change for MarioWiki:Personal files rather than a new feature? Maybe I'm wrong. - 23:32, August 12, 2025 (EDT)
2. Mushzoom (talk) Per Trig Jegman.
3. PanchamBro (talk) Per Trig.
4. Ahemtoday (talk) Per Trig.
5. SGoW (talk) Considering how restrictive we currently are for personal images, it feels weird to just make an exception for unused files and leave them all up if they're personal images. Like maybe if you could casually just have 20 odd personal images I would get this, but with a hard limit of five I think it's fair game to just delete these.
6. Waluigi Time (talk) It feels kind of weird to intentionally hang on to old personal images if the users who uploaded them already stopped using them, especially if they've been inactive for a long time. The personal files policy even says that they have to be used within 24 hours of uploading or they'll be deleted, I don't see why it's different if they were previously in use but that's no longer the case.
7. DryBonesBandit (talk) Per all.

Make a navbox template for Satellaview

canceled by proposer
This is my first time making a proposal here, so apologies if the formatting is a little off. Otherwise, I don't have much to say that the title doesn't say already. I think the Satellaview should have its own navbox template, separate from the SNES. Though only an add-on, all its games have it listed as if it's a platform.

Proposer: Sargent Deez (talk)
Deadline: September 15, 2025, 23:59 GMT

Support

#Sargent Deez (talk) Per proposal.

Oppose

1. EvieMaybe (talk) it's already a section on Template:SNES, which makes sense for an add-on to the SNES. if we give the Satellaview its own navbox, will we have to give the FDS one too?
2. Altendo (talk) Per EvieMaybe. This will result in us splitting not only FCDS but also the 64DD, WiiWare, DSiWare, and maybe even the New Nintendo 3DS from their parent navboxes due to them having sub-generational exclusives.
3. Camwoodstock (talk) The Satellaview being singled out feels a bit too strange to us. We could go either way on a full split between consoles and their accessories/variants/digital storefronts (so long as said things actually have enough unique to them), but doing just the Satellaview like this feels... Weird.
4. Sargent Deez (talk) I'm abandoning this proposal, per EvieMaybe and Camwoodstoc. I failed to take into account other add-ons, and agree only the Satellaview getting a navbox template is weird.

Discussion

It seems like this proposal is intended to only have two options (support and oppose), in which case you want "basic" proposal formatting, not "poll" proposal formatting (which is for proposals that cover multiple related issues rather than only one). Hewer (talk · contributions · edit count) 20:26, September 1, 2025 (EDT)

Fixed, thanks for telling me  — 21:20, September 1, 2025 (EDT)

Responding to Camwoodstock (talk), I've been doing a lot of Satellaview edits lately, but think seperating all accessories is a good idea. May make a separate proposal in the future, as it wasn't on my mind at the time.  — 16:26, September 2, 2025 (EDT)

@Sargent Deez You are using the {{User}} template wrong. They are supposed to be curly brackets ({{User|Camwoodstock}}), not normal brackets like you used. Altendo 23:40, September 2, 2025 (EDT)

@Sargent Deez You can still cancel this proposal until September 5. You also need to cross out your removed vote(s) with >nowiki>#Sargent Deez (talk) Per proposal.</nowiki>, so that it can still remain visible, even if it is removed; it still won't count towards the vote if you do. Altendo 20:16, September 3, 2025 (EDT)

@Altendo how do I cancel it? Just by deleting it?  — 20:20, September 3, 2025 (EDT)

You can move the entire proposal to the current proposals archive and adding the {{proposal outcome}} template as {{Proposal outcome|canceled}} between the subheader and first paragraph. Altendo 20:30, September 3, 2025 (EDT)

Add sliding infobox images

Do not add 1-10
So, on Fandom, they have infobox images that can change with clicking the top of the image. Now, you may be wondering, how would this be useful? some examples are: two Dr. Mario image. one showing his white pants and one showing his SSB design. Two Lanky Kong images. one showing his DK64 design and one showing his SSB trophy and DKBB design.

Proposer: Colin's world 3 YT (talk)
Deadline: September 11, 2025, 23:59 GMT September 4, 2025, 23:59 GMT

Support

1. Colin's world 3 YT (talk)

Oppose

1. Doc von Schmeltwick (talk) 09:35, August 28, 2025 (EDT) - This is referring to {{tabber}}, which we don't use due to several downsides brought up in previous proposals.
2. Sdman213 (talk) Per.
3. Altendo (talk) This is just Tabber, which I previously spoke against due to them requiring either JavaScript or a good browser (which not everyone is lucky enough to have).
4. Rykitu (talk) Per Doc and Altendo. I am not good in Javascript (yet)
5. Camwoodstock (talk) This is just tabbers. While we do feel tabbers have some use, ultimately, keeping on top of them is more trouble than it's worth, especially in comparison to just using a gallery.
6. DryBonesBandit (talk) Per all.
7. Killer Moth (talk) Per all.
8. 1468z (talk) Per all.
9. Tails777 (talk) Per Doc, Altendo, Camwoodstock and previous oppositions. Yes, tabbers seem useful, but the hassle of keeping them up seems to outweigh their potential usefulness. Also, I'm still in the middle of removing all the multiple images in infoboxes as a result of dropping tabbers and I REALLY don't wanna go back on that.
10. MeritC (talk) Per all; plus, I think if this were even implemented, it would be nothing more than an additional hassle in regards to image management for infoboxes on this wiki.

Get rid of rule 21 "Proposals cannot be made about promotions and demotions."

vetoed by the administrators
Our current system works fine; this would just lead to issues.
We should get rid of rule 21 "Proposals cannot be made about promotions and demotions." Ending a rule that prohibits editors from proposing promotions and demotions can offer several benefits on the Super Mario Wiki, from increasing transparency to boosting editors' morale.

Proposer: Wariowarefan100 (talk)
Deadline: September 19, 2025, 23:59 GMT

Support

1. Wariowarefan100 (talk) Per proposal.

Oppose

1. Okapii (talk) absolutely not a good idea, all this would open the door to is petty disputes, promotion-begging, and general rudeness. The staff here is more than capable of handling these situations, and they can open things for discussion to the general userbase if they deem it necessary.
2. Nelsonic (talk) Per Okapii. This would most likely cause promotion/demotion proposals to happen incredibly frequently, and I believe that the latter could possibly be used maliciously. For instance, if X user does something that Y user does not like, Y user could make a proposal to demote X user because of it.
3. Altendo (talk) Per How do I become a patroller or admin?, rule 9 says, "Don't call us. We'll call you."
4. Salmancer (talk) This proposal is probably getting cancelled by staff. In the meantime, trust me here the kinds of reasons users get demoted are really bad to put up in a public vote. Usually because they are uninteresting (does not have time to be a staff member anymore) or are giant controversies which really want a solid singular staff response and not many different kneejerk user reactions. Oh, and per all as well.
5. Jdtendo (talk) Per all.

Formally ban AI-generated content (unless Nintendo made it)

vetoed by the administrators
AI-generated content is already banned per the Manual of Style
Lately, I've seen a few edits that use ChatGPT, Microsoft Copilot, Google Gemini, or other generative AI sources to write articles or find information. The problem with this is that the information we need is often so niche that AI hallucinates an answer, or the prose feels phony, overly long, and artificial. We have plenty of experienced editors and people who are willing to do research and put time into figuring things out, and that's the main draw of the wiki. What's here is, for the most part, true and sourced. Anyone can get an AI slop answer.

The inevitable problem with these discussions is people bringing up things that aren't AI and arguing semantics, usually to downplay the fact that they themselves use generative AI. No, a spell checker is not AI. Granted, spell checkers now may have AI tools to suggest rewrite or auto-complete sentences, but catching and fixing basic spelling errors is something that would be encouraged by human users. On the other hand, you know when you are using ChatGPT to write up an article. Here's some obvious cases where AI would not be allowed:

• using AI to generate prose for articles or sections of articles
• using AI to add information that has not been, or cannot be, verified
• using AI to upscale or generate images
• using AI to respond to users on talk pages

My other question, though, is what happens if Nintendo themselves uses gen AI? Say an official Mario product or promotion or something very clearly reeks of generative AI. This could be a Super Mario Bros. Encyclopedia situation where we willingly choose to ignore it, but I don't think that's going to happen. If this happens, we will cover any Nintendo-authorized AI slop, no matter how horrible and soulless it may be. Ride or die.

Proposer: Scrooge200 (talk)
Deadline: September 25, 2025, 23:59 GMT

Clean up the slop: Ban gen AI

1. Scrooge200 (talk) Per proposal.
2. NelsonicGPT (talk) Per proposal.
3. 1468z (talk) Per proposal.
4. Camwoodstock (talk) Please. Per proposal.
5. Hewer (talk) I wish this went without saying
6. The Dab Master (talk) Away with the clankers.

Comments (✨please talk to our new AI assistant✨)

Uh... bad news but the Manual of Style already says AI is not allowed. "Do not use generative AI to write articles or any other text on the wiki." Last line of the first paragraph. I think this proposal inherently gets cancelled as with this information in mind the proposal is no longer making any change to existing policy. Salmancer (talk) 17:22, September 11, 2025 (EDT)

I mean, the only case where I really see Nintendo using "AI" is in promotional material, which we can always ignore. Even then, I can't really think of any case where they've done that. If it's just them using something like ChatGPT to write some text in a game, we can only speculate that they did so (which isn't allowed here). The Dab Master 17:43, September 11, 2025 (EDT)

Remove Nintendo Switch 1 controllers from Nintendo Switch 2 games' input sections

Do not remove 0-3-5
I've noticed that each Nintendo Switch 2 game on the wiki has original Joy-Con/Pro Controllers listed as an available input. I personally feel like this is unnecessary, as the Switch 2 console, and a majority of Switch 2 games (as well as the updated Nintendo Classics apps) treat original Joy-Con and Pro Controllers as their Switch 2 counterparts (Joy-Con 2, SW2 Pro Controllers) in game, sans the JC2's Mouse Controls in games like Super Mario Party Jamboree + Jamboree TV and Nintendo Switch 2 Welcome Tour. An exception could be made for the DK Artist portion of Donkey Kong Bananza, but I haven't personally done research on that, so it would likely be one of several exceptions to this.

While I do recognize that JC/PC are valid inputs on SW2 games, I have reasons as to why I believe they shouldn't be listed normally.

1. As stated before, most games simply recognize them as a mirror of Joy-Con 2/SW2 Pro Controllers, not providing any special recognition for them, like unique controls or graphics.
2. If they are recognized like this, why isn't a similar thing done on other consoles? You can play Nintendo DS games on a 3DS, but they don't show a 3DS console as a unique input. Likewise, you can technically use a GameCube controller (or any of the NSO controllers) on any original Switch (or even Switch 2) game. But a majority of games similarly only recognize it as a USB Pro Controller. However, currently only Super Smash Bros. Ultimate and Super Mario 3D All-Stars show the GameCube controller as a unique input option, as they have special functionality specifically for the GameCube controller.
   • If this how past games (pre-Switch 2) are treated, I don't see any reason as to why Switch 2 games should be any different.

Proposer: The Eggo55 (talk)
Deadline: September 13, 2025, 23:59 GMT

Remove Joy-Con/NS Pro Controllers from Nintendo Switch 2 games' infoboxes

PopitTart (talk) If it's not treated as a unique input scheme by the software, then giving distinct inputs for any physical controller that can be used leads to absurd results. As the proposal covers, whats stopping us from listing all the NSO controllers? How about the WaveBird for GameCube? Are the NES Advantage or top-loader's "dog bone" controller distinct controllers? The answer should obviously be no, since they're simply different ways that the exact same button presses get sent to the console. And that's exactly what Joy-Con 1 do on most Switch 2 games. For games that do have unique input, such as Bananza, then the Joy-Con 1 entry should stay.

Remove SW1 inputs for games with identical function, keep them if they're different

• Per suggestion by Camwoodstock

1. The Eggo55 (talk) Per proposal
2. Camwoodstock (talk) Secondary option. While we still don't see the harm in keeping them for now, there's nothing too wrong with removing these so long as we're still properly tracking things when they are different.
3. PopitTart (talk) Per my original vote.

Do nothing; Leave the infoboxes as they currently are

1. Colin's world 3 YT (talk) Well they're different controllers, aren't they?
2. Jdtendo (talk) It's not obvious that Joy Con 1 can be used on Switch 2 games since some games could rely on Joy Con 2-specific features, notably mouse controls (e.g., Mario Paint can be played with Joy Con 2 but not Joy Con 1). The "DS game on a 3DS" comparison does not hold because that means playing an older game with newer hardware, whereas playing a Switch 2 game with Joy Con 1 means playing a newer game with older hardware, which is not as common.
3. Camwoodstock (talk) We feel like the Switch 2 is still a bit too young to be making such a wide assessment that there's going to be literally no difference between a Joy Con 1 and Joy Con 2--nevermind that, as Jdtendo pointed out, Mario Paint on NSO cannot be played with Joy Con 1s, and the Switch has to rely on a USB Mouse to actually play Mario Paint, while the Switch 2 gets to just use Joy Con 2s. Sure, in the case of Mario Paint, the "difference" between Joy Con 1 is simply that it can't, but we imagine as we approach the twilight years of Switch 1 support, we'll see at least a few more instances of bespoke controls between Joy Cons 1 and Joy cons 2. heck you could argue we're technically already there thanks to Deltarune but that is its own edge case not even related to mario. directly anyways
4. Killer Moth (talk) Per all.
5. Power Flotzo (talk) Per all.

Discussion

@Camwoodstock: Why don't we just list the controllers separately only if there is a difference between them in that particular game, as PopitTart suggested? We don't have to do the same thing for every game on the system. Hewer (talk · contributions · edit count) 14:09, August 31, 2025 (EDT)

That'd be fair, though currently, just blanket removal is the only option. If there was a "remove for games where they're the same, retain if they're different" option, we'd be happy to vote for that. ~Camwoodstock ( talk ☯ contribs ) 14:36, August 31, 2025 (EDT)

@Camwoodstock: I did intend for that to be the case, since of course there will inevitably be games which will have exceptions, like Donkey Kong Bananza and the aforementioned Mario Paint. It's probably a good idea to actually say that though, so I'll make it a new option since the original already has a vote. The Eggo55 (talk) 15:22, August 31, 2025 (EDT)

I think comparing running DS games on 3DS to playing Switch 2 games using Joy-Con 1s is a false equvalency. My understanding is that the Nintendo 3DS outright runs as a Nintendo DS to play Nintendo DS games. This is different from the Nintendo Switch 2, which does emulate the Nintendo Switch 1. I do not think it is an especially good argument in favor of the proposal. Salmancer (talk) 22:25, September 4, 2025 (EDT)

Decide how to cover the products listed on the future Unilever article

Be brief in the article and collect the product images in a separate page 2-3-11
11 out of 12 voters (91.7%) approve the first place option.

I'm currently working on a page for Unilever that seeks to document the products that were part of the company's Mario-themed campaign. You can see a near-finished draft in my sandbox (archive).

Unilever has a habit of purchasing existing brands across the world and leveraging them to sell their own stuff to particular markets. In other words, the things they sell often go by a different name depending on where you are. Anybody here ever had Algida ice cream? If your immediate answer is "no", chances are you're wrong--if you're American, it was just called Good Humor instead; if you're British, Wall's; if you're Dutch or Portuguese, Ola; and so on. Unilever's ice cream just happens to be sold as "Algida" in my ancestral homeland.

This practice is evident as you browse my draft. As you can see, I've chosen to exhibit Mario products from all of their dental care brands. Rather jarringly, the result is that every section in the article's gallery ends up literally reiterating the products listed before and after, the sole difference between the sections being what brand logo is shown. I was expecting the page to look somehwat more brief, but it's not panning out this way. Some toothpaste is called this in X country, another is called that in Y country, but ultimately they're all mere re-packagings of the same object, whereby Unilever got a Nintendo license to sell toothpaste with a picture of Baby Mario leering smugly at your 5-year-old.

Sure enough, the toothpaste presented here often comes in multiple flavours, but these are are standard across all of the children's toothpaste sold by Unilever, and are not unique to this Mario promotion.

Since this is a rather unique situation on this wiki, where attempting to document as many products from different brands comes across as unhealthily comprehensive, I've set up a proposal to hopefully gather some better coverage perspective. The options I have are as follows:

1. Only highlight each product from this line of Mario products once based on the character shown. The brand and flavor chosen to represent each product is at the editors' discretion, but should not be factored individually. For instance, for Baby Mario, you show one tube of Prodent strawberry-flavored toothpaste; for Toad, you show one tube of AIM fruity-flavored toothpaste; and so on until you have every character illustrated and, hopefully, as many brands and flavor variations represented while remaining brief.
2. Status quo. Continue documenting every single product in this line en detail. If the Baby Mario toothpaste is sold under six different brands, and some of these brands offer more than one flavor toothpaste, you list each variation individually.
3. Reshape the draft as proposed in the first option, but keep all images of the products and place them in a separate, Unilever-adjacent gallery page. (Added 14:05, September 8, 2025 (EDT) per Waluigi Time's suggestion.)

Regardless of the winning option, the article will still seek to textually clarify that these product variations are present in all of Unilever's dental care brands. If option 1 wins, the citations will remain for verifiability, but will be reincorporated in some form.

And most importantly, remember to brush your teeth two times a day.

Proposer: Koopa con Carne (talk)
Deadline: September 21, 2025, 23:59 GMT Closed early on September 14, 2025, 23:59 GMT

Option 1: be brief

1. Koopa con Carne (talk) Per proposal.
2. Altendo Series 10 (talk) Once and only once. I also agree with the last sentence of the proposal.

#Rykitu (talk) Per Altendo. Thank you Dentist Koopa con Carne for your service.

Option 2: be comprehensive

1. Hewer (talk) I don't see why we shouldn't be as comprehensive as possible. If a reader was interested enough to click on a page about Mario-themed toothpaste, we may as well show them all the Mario-themed toothpaste rather than only some arbitrary selections.
2. PopitTart (talk) Per Hewer. Sure, maybe it is excessive, but... its Nintendo and Unilever who are being excessive. We are just being faithful and accurate to official material. Imagine if we tried to cut our coverage of Tour's driver variants just because we thought it was "excessive"!
3. Salmancer (talk) I mean, if you come to specifically Super Mario Wiki, I believe you would expect "unhealthly comphrensive" coverage. We leave no stone unturned, even if they're the ones that are really, really dumb. (Like Play Nintendo terminolgy!) Besides, what's dumb for one person might be nostalgic for another: what if someone really really wanted to specifically see the Signal Baby Mario toothpaste container, and we didn't have it because we thought having it was silly and needless? I bet that person would think the wiki is being silly.

Option 3: be brief in the article (as per option 1), collect the product images in a separate page

1. Koopa con Carne (talk) Per Waluigi Time in comments.
2. Hewer (talk) Sure. I guess this proposal just had some teething troubles.
3. Okapii (talk) Per WT's comment, seems like a lovely compromise.
4. Rykitu (talk) Per comments.
5. Waluigi Time (talk) Per KCC.
6. Camwoodstock (talk) The way we see it, this is kind of like the Tour course icon variants, at least in regards to the main page. On the main page, we really should only be using one, but on a gallery specifically for them, sure, we can have more of them. (Granted, in Tour's case, we don't have a dedicated gallery for all of these icon variants, but shhhhh.)
7. Altendo (talk) Second choice.
8. Nintendo101 (talk) Nice ideas all around.
9. Salmancer (talk) per all
10. EvieMaybe (talk) per all.
11. Colin's world 3 YT (talk) per all.

Comments (toothpaste)

Would it be reasonable to implement option 1 for the main article and have a separate gallery page that contains all the variations? Stuff like this is easily lost to time so I don't feel too good about not keeping it at all, but I agree that the current state of the draft isn't ideal. -- Too Bad! Waluigi Time! 13:07, September 8, 2025 (EDT)

Huh. -- KOOPA CON CARNE 14:05, September 8, 2025 (EDT)

What to do with Template:Platforms

Keep and roll out 4-2-0
4 out of 6 voters (66.7%) approve the first place option.
This is about... Well... A template we made, actually! Namely, the Template:Platforms navbox. In retrospect, we probably should've proposed it first, but after spending 5 hours making it in a back-and-forth on Discord, it was only a few hours after we had created it that some expressed overt questioning as to if it was particularly necessary.

For the record, this proposal is not about:

• Trying to determine what should count as a platform in the first place (sorry, questioning if Spike Traps, Thwomps, Munchers, or Koopa Paratroopas are platforms is for another proposal)
• If the Platform page should continue to exist (this one came under less scrutiny)
• If the Template:Blocks navbox should continue to exist (this one also came under scrutiny at one point)

These things, if people find them contentious enough, should definitely be proposed later, outside of the context of this one.

In addition, we'd like to request that Template:Platforms not be added to any pages until after the proposal concludes (y'know, provided all are in favor of keeping it.) Likewise, it should probably be kept on the Platform page for right now--mostly since removing it would be a bit more trouble than it's worth.

So. What's the deal with the Platforms navbox? Well, simply put, it's a navbox... for Platforms. It's meant to serve as a navbox for Category:Platforms, Category:Lifts, Category:Mushroom Platforms, and for trampolines (which lack their own category at the moment). It serves as a companion to Template:Blocks, which similarly lists blocks. Lifts once had its own navbox, but it was deleted for being too small--hence, our Platforms navbox includes them together.

The main hurdle we've heard of is that what counts as a "platform" is, inherently, very broad, which lead to a rather large navbox. People's definitions of platform could be as specific as "a part of level terrain or geometry that you're supposed to stand on" to "literally any surface you can potentially stand on". And when we say "any", we mean "any"--Koopa Paratroopas were expressly cited in the ensuing Discord conversation. As a result, we've heard questions ranging from what should actually be on the template, to if the template is simply too broad to even exist--especially in the case of maximal views of what counts as a platform, as counting stuff like "every enemy in Super Mario Bros. 2" naturally would dilute what counts as a platform.

We, obviously, disagree with the notion that platforms are "too broad" to be worth a navbox--when creating the navbox, we were particularly careful to keep the scope rather narrow (limiting things to only things that serve as level terrain or geometry, objects that are serving as level terrain or geometry, can be stood on and platformed (verb) from to-and-from, either by walking or jumping across, and, if they are objects, they shouldn't damage the player unless it's part of a gimmick, or the enemy is expressly framed as a live platform). While we'd like to refrain from setting a concrete definition for "what is a platform" unless absolutely necessary, these limits were put into place both in pursuit of preventing the navbox from growing bloated (odds are, someone looking at the navbox for platforms doesn't want to see a random enemy from Super Mario Maker 2, and get told that it's there because of the SMB2 Mario form), but also as a sanity check (it turns out there are a lot of surfaces one can stand on in the Super Mario franchise!). The template, in its current state, meets the qualifications for species navboxes (which is not actually species-specific, as pointed out by the policy itself. confusing, we know. ;P) In addition, Template:Blocks has existed uncontested for decades, and is similarly broad in scope--we can't think of many reasons to nix a platform navbox, but keep the block one.

We have also heard suggestions to change the Platforms category to use this list, so in addition to straightforward "keep the template/remove it" options, we've supplied an option for that.

Proposer: Camwoodstock (talk)
Deadline: September 16, 2025, 23:59 GMT

Support/Keep/Roll it out

1. Camwoodstock (talk) Per proposal. We think a template like this has merit, obviously, we wouldn't have spent 5 hours creating a navbox and not want to keep it. While we do understand that some of the contents therein (or some of the absences) are contentious, we think it's a good baseline for what a navbox of this sort could be, and what exactly should be included/excluded can be determined in future proposals.
2. Altendo (talk) Sounds good from what I can see.
3. Sargent Deez (talk) Per all. I'm always for navboxes, even if what counts can be a little contentious, but as you said, that can be argued in the future.
4. Jdtendo (talk) I see no harm in keeping this navbox.

Convert Category:Platforms to use the navbox list, but don't keep the navbox

1. Salmancer (talk) I think the big difference between "platform" and "block" is that "block" is a Super Mario-ian concept so persistent that if Nintendo was feeling needlessly cruel they could probably trademark it. "Platform" in comparison is very generic and very hard to define. In addition, the blocks are mostly spelt out for us in subject names while platforms do so less often. I feel that a navbox for platforms will lead to many arguements over what is and isn't a platform, whereas the less prominent nature of a category will lead to fewer arguements.
2. DryBonesBandit (talk) Per Sal.

Comments (platform peril!)

We don't really agree with the thought process of "because a navbox would lead to arguments about what counts, we shouldn't do it" because... well, you can say that about a lot of things. Including categories themselves, in fact. It feels a bit weird to dismiss something just because someone can question what should count for it, especially in the series where there is, very famously, absolutely zero consensus for what counts as a "mainline" game in it. ~Camwoodstock ( talk ☯ contribs ) 18:18, September 5, 2025 (EDT)

So its like... imagine this set of events

• Goonie isn't a platform dummy! And [arbitrary], [arbitrary], and [arbitrary], aren't platforms either, while [arbitrary], [arbitrary], and [arbitrary] are platforms! I'm going to make a big edit that removes those not-platforms and adds these are-platforms! (navbox and category)
• Goonie isn't a platform dummy! Are [arbitrary], [arbitrary], and [arbitrary] platforms? I'm going to remove Goonie from the category, then check those articles to make sure they are platforms. (category only)

Basically, the navbox directs even the uninformed user to a complete listing that they may or may not object to, while the category is much more silent unless the link is used, instead being a marker for what something is. There will be more traffic if the navbox is implemented compared to if it isn't. As an aside note, it also helps that the page for a category has a listed definition and can set clearly visible rules. Navboxes do not have that luxury, and as a result when their inclusion rules aren't really obvious they can be prone to additions that don't fit in ways categories are less prone to. Considering "platform" is as difficult to define as it is, this property of naboxes will end up causing problems when the userbase incorrectly add platforms to the navbox that don't match the definition they didn't find because it would have to go on Template:Platform's talk page or something. And then there's the different categories of platform in the navbox. As has been stated on Discord, the distinction between "solid" vs "semisolid" collapses the second Mario enters the third dimension, with platforms gleefully being one or the other on a game-dependent basis. And so there will be edits moving platforms between both groups that would need substantial oversight to correct/confirm that at it does hold in the 2D games, and because you can't put a definition on a navbox the distinction that the navbox works on (mostly if it is solid or semisolid in a two-dimensional context) is invisible to the average user. I actually suggest making a Lifts navbox and a Trampolines navbox instead of a Platforms navbox, two things that have a large or decent number of members and are as obvious in their membership through names as the blocks. (Lifts less so, but at least we have Japanese names to help) Salmancer (talk) 18:55, September 5, 2025 (EDT)

A definition for what a platform is is already pretty clearly stated on Platform, that's not something you need a category to accomplish. And, if the worry is that these sorts of "should this count as a platform? I'm going to remove the category!" edits are going to be made anyways, why should we permit them for categories, but exclude them for navboxes?
As for a dedicated lift navbox and a trampoline navbox, not only do lifts fall into the exact same pitfalls of "what actually counts as a lift" being confusing (it is currently based entirely on what has the Japanese word for "lift" in the name--even if something has "Lift" in English, if it doesn't have it in Japan, it doesn't count), but we actually used to have a navbox for lifts... Which, was deleted, as it was too narrow. And if lifts can't support their own navbox, there's very little chance trampolines could, without dipping into a maximal case of "anything you can platform (verb) off of is a platform (noun)" and we start claiming that Goombas are trampolines, since you can bounce off of them. ~Camwoodstock ( talk ☯ contribs ) 19:03, September 5, 2025 (EDT)

The delete log says the lift navbox also had no sectioning, which contributed to the deletion. Surely some of them can be sectioned in logical ways, probably by how they move. Salmancer (talk) 09:28, September 9, 2025 (EDT)

I think an argument in favor of this proposal would be "'Platform' doesn't have a navigation template". I would consider putting platforms on a navbox of broader gaming concepts, so things like Level and Experience Point and Level up and minigame, thus granting the article "Platform" a navigation template without having to make a navigation template about platforms. Salmancer (talk) 09:28, September 9, 2025 (EDT)