MarioWiki:Proposals/Archive/79

All past proposals are archived here. Please add archived proposals to the bottom of the page.

Content assessment

canceled by proposer
Let's be honest, Mario Wiki isn't the best at sorting articles based on quality. Featured Articles are supposed to be the best of the best, but when the only classifier below them are, the worst of the worst of, you have a massive gray area in the middle. Not to mention, some articles where improvements can be made, like Donkey Kong Country are Featured, while others that are decent, like Donkey Kong 3, are considered Stubs.

There are a few things worth keeping, such as voting on Featured Articles, but why only them? Shouldn't we vote on Stubs too? Actually, I'm not sure if classifiers should be added on the talk page, likeWikipedia or get voted on like Featured Articles. Maybe everything below Good Articles can be changed by anyone, but those have to get voted on? Having icons on the upper right corner is cute, but again, why isn't there one for Stubs? While clicking an icon on an article to find out it's well-written may give readers more trust in what they're reading, doing the same for Stubs may encourage people to help the article out.

So what's my solution and the point of this proposal? Content assessment, like on Wikipedia! This rough draft has six rankings: Featured articles, Good articles, B-Class articles, C-Class articles, Start-class articles and stub-class articles. Each classifier comes with a template and category that works the same way as that of Featured Articles. I'm not sure if individuals articles are needed for them, but that can be decided later. In fact, most of this proposal will have to. As a non-administrator, I have little power to carry out such a change, so this is less voting if you want this system added, and more do you want a system that expands on this added.

Edit: I've added a third option, Proposal B, also viewable here. Six categories is a little excessive, so I narrowed it down to four. Also, I'm not sure if the classifiers will be voted on, or just be changed, like Wikipedia.

Proposer: Sargent Deez (talk)
Deadline: October 1, 2025, 23:59 GMT

Proposal A

1. Sargent Deez (talk) Per proposal.

Proposal B

1. Sargent Deez (talk) Per proposal.

Oppose

1. Camwoodstock (talk) We feel like needing to vote to count a page as a stub, let alone sort pages into some "A-grade", "B-grade", or "C-grade" is vastly overthinking things. Ignoring how subjective the concept is--what exactly is the cutoff for an A-grade to B-grade, or a C-grade to stub-grade--the amount of pages that would even quality for some of these (namely "Start-grade") are few and fleeting. As in, basically just pages for upcoming titles (so, Mr. E (Yoshi and the Mysterious Book) or Baby Waluigi) and nothing else--it is currently policy to actively delete any page that is simply created for the sake of filling out a redlink, so there's no other real way for a "Start-grade" page to exist. And... Let's be honest. Does anyone want to vote on upgrading a page from "C-grade" to "B-grade?" It would be a tremendous amount of effort for, comparatively, next to no payoff. Just because Wikipedia does something, does not mean we need to do it. Our current system of just stubs/rewrites, normal articles, and featured articles is just fine.
2. Hewer (talk) The point of having featured articles is so that we can put them on the main page. I don't see how adding other quality-based categories would provide any benefit. I also don't see how stubs relate to featured articles, the stub template is just meant to indicate that the page has information missing that someone should add. Voting on stubs would be a waste of time and effort that could instead be spent improving them into not-stubs.
3. Rykitu (B-class editor) (talk) Heavy per all. Featured articles make sense, but this is going a bit too far.

Make articles for the licensed songs in The Super Mario Bros. Movie

Make the articles 6-1
I'm suprised the licensed songs in The Super Mario Bros. Movie, like "Take On Me" and "Thudnerstruck" don't have article. While not original Mario songs, neither are most songs in Donkey Konga 2 yet they have article, so shouldn't they too? I've made a rough draft for a "No Sleep till Brooklyn" article. It needs work, and I welcome all to help on the draft, but gives an idea of how articles on licensed songs should look, keeping it Mario centered.

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

Support

1. Sargent Deez (talk) Per proposal.
2. Rykitu (talk) If Donkey Konga game soundtracks have an article, these should too.
3. janMisali (talk) If "Walk the Dinosaur" gets an article for its appearance in the Super Mario Bros. movie then there's no reason not to do the same thing for the licensed music in the The Super Mario Bros. Movie movie too.
4. Colin's world 3 YT (talk) Per proposal and per janmisali
5. Salmancer (talk) We already opened the floodgates on music articles. The draft here is actually a better article than a number of our articles for Super Mario original songs. I think it would be lovely to have on the wiki, and anything else on the matter. Aside from that, it's not like the liscensed music is irrelevant to the film (even if the reviews generally responded negatively to it.) Someone picked the song, someone chose where it plays (or maybe the other way around) and someone approved of this being the right place to play whatever given song. Since The Super Mario Bros. Movie is full Mario media, that means the creative decisions that make it up are within our coverage.
6. Scrooge200 (talk) The scope is well-contained and these are part of an official movie. I see it as a similar way to our crossover articles.

Oppose

1. YoYo (talk) We recently just had a proposal pass asking for Nintendo Music pages to be split into a page for each soundtrack. It would be unusual to have that effect take place, but then instead have different pages for individual licensed music not even from the franchise have their own pages each. Instead, a page dedicated to all licensed music in a list, or simply listing the music on the movie's article and nothing more, is how I would handle this. These individual songs do not need their own dedicated pages each: even just a single Wikipedia link on the movie's page is more than enough. I personally have the same stance on the Donkey Konga 2 songs as well.

#Mario jc (talk) While I'm not opposed to covering the licensed songs per se, I'm more opposed to the scope of these articles you're suggesting with your draft. Adding a full composition and reception section is going too far and veers it out of Super Mario-related coverage when we should be giving brief context at most (what the song is and how the song performed is fine, but kept brief) and more focus on the song in relation to the Mario franchise (see actor pages such as Chris Pratt [which did have full early life and career paragraphs added at one point and removed for the same reason] - we don't cover their entire career and filmography). We have Wikipedia for that information.

Discussion

I'm honestly unsure what to vote for. On one hand, the Donkey Konga 2 music pages are also licensed songs, and only serve a fitting role in the greater Super Mario franchise in one piece of media. On the other hand, those pages have extra details, like length, BPM, and difficulty, things notable in video games but not in non-interactive media like movies. I think I'll just abstain for now knowing that I have feelings both for and against this proposal. Altendo 17:35, September 3, 2025 (EDT)

I don't think Donkey Konga 2 is a very good example to point to for precedent, as playable songs in a rhythm game are naturally more notable and have more Mario-relevant stuff to say about them than licensed songs in non-interactive media. However, we do have pages for licensed songs from the live-action film, Almost Unreal and Walk the Dinosaur, which are much more comparable to this situation. We also have lists of songs from each of the TV shows, of which two (The Super Mario Bros. Super Show and The Adventures of Super Mario Bros. 3) include licensed songs, and this proposal passed to split these lists into individual articles (though I'm not entirely sure if that was intended to include the licensed songs). Hewer (talk · contributions · edit count) 17:57, September 3, 2025 (EDT)

Thanks for the information. However, Almost Unreal was made for the Mario movie, while Walk the Dinosaur had its lyrics modified for the movie. I don't think any of the songs in TSMBM got this treatment. Altendo 18:06, September 3, 2025 (EDT)

I don't think it's accurate to go off what doesn't have articles, as none of the songs on Super Mario Compact Disco have any, despite being made for the album with explicitly Mario lyrics. I'd say a lack of interest is why few of the licensed songs in Mario movies have articles.  — 19:07, September 3, 2025 (EDT)

We're on the fence. Per Donkey Konga, it's not like licensed songs are out-of-bounds provided they can be directly linked to the Mario franchise, but then, what about Walk the Dinosaur, or any of the other tracks on White Knuckle Scorin'? ...In an extreme case, what about the music in SSX on Tour, which is all licensed music, without a single Mario-related track in the entire game, even in the Nintendo-themed course (due to how the game handles music?) This feels like something that should hold a bit more gravitas to it, we feel. We'd be fine if it was "licensed music is fine so long as there is at least one Mario-related track" since that would be a sanity check against SSX on Tour, but we can also definitely see that being a tad contentious. ~Camwoodstock ( talk ☯ contribs ) 18:26, September 3, 2025 (EDT)

We don't need to worry about SSX on Tour because it has guest appearance coverage rather than full coverage, meaning that only the game itself gets an article and not any of its non-Mario-related content (the same reason we don't have pages for any of the playable characters except Mario, Luigi, and Peach). Also, as I mentioned in my above comment, Walk the Dinosaur has an article. Hewer (talk · contributions · edit count) 18:54, September 3, 2025 (EDT)

what if we just have one big list article about the movie's OST, including licensed and non-licensed songs? — eviemaybe (talk / contributions) 10:30, September 4, 2025 (EDT)

That seems at odds with the consensus in this proposal. Hewer (talk · contributions · edit count) 12:15, September 4, 2025 (EDT)

@YoYo: Covering Nintendo Music soundtracks (or any soundtrack releases) has never been mutually exclusive with covering individual songs on separate articles. Per this proposal, every theme on Nintendo Music is eligible for its own page (since they all they all have official names), and indeed many of them already have their own pages. Hewer (talk · contributions · edit count) 08:08, September 5, 2025 (EDT)

Mario jc: Both the composition and reception sections are specifically on the song's inclusion in The Super Mario Bros. Movie. "Walk the Dinosaur" has information on the same things. The only thing that may be excessive are the differences between the original and the single artwork, which I added as I like having an identifying image.  — 23:49, September 6, 2025 (EDT)

Oh, so they are, sorry. It was late and I was reading both the draft and the Wikipedia article and must've gotten the two confused and somehow overlooked the parts referring to the movie. Mario JC 07:51, September 7, 2025 (EDT)

There's honestly no reason to have a page for every individual song, all their pages are mostly copy/paste and theyre not even mario material, and I feel it'll be much better if it was just one page listing all licensed music in games and movies and have them listed in a table, that would be much more convenient and more reasonable. The only exceptions would be songs with covers or unique renditions made for Mario media, like Walk the Dinosaur. - YoYo (Talk) 05:37, September 7, 2025 (EDT)

I believe many of the Donkey Konga songs are covers (and even if they weren't, songs in a rhythm game make sense to give their own articles since they're that game's equivalent of levels). Hewer (talk · contributions · edit count) 06:01, September 7, 2025 (EDT)

Make a redirect to every article which has a sourced foreign name

do not make redirects 2-6
What I mean is, for articles which have sourced foreign names, like how Peach has "Princesa Pêssego" in Portuguese and has Super Mario World as source, "Princesa Pêssego" should redirect to Princess Peach. But, if it's the Koopalings, for example, their Portuguese name isn't sourced, so it wouldn't have amy redirect. And, for articles which have the same foreign name in a specific language as another, like galoomba and Goombob (Goombob's foreign name which I'm talking about hasn't been sourced, but you get the idea,) the subject which is most "used" by Nintendo is the one which gets the redirect, so, in this case, galoomba. Note I'm not talking about only Portuguese in this proposal. I'm also talking abiut Japanese, French, every language. And, also, I have a problem with wording, so, if you don't understand the proposal, please tell me and I'll try to explain more clearly.

Proposer: Balugio (talk) (blocked)
Deadline: September 17, 2025, 23:59 GMT

Support

1. Hewer (talk) Honestly surprised we don't already do this (outside of a few exceptions for whatever reason). These are alternative names for these subjects, which is the very thing redirects are meant to be used for. More redirects isn't a bad thing (I wouldn't describe server space as "precious"), and if we're affording disambiguations for things like SMS, I don't see the problem with doing it here. The oppose argument basically seems to amount to "it's too much work", which isn't an argument I'm a fan of. (Granted, this proposal should probably be treated like this one or this one where we just allow the redirects to be made and mark the proposal as "implemented" without having made every single possible redirect, since otherwise it'd sit on the "unimplemented proposals" list forevermore.)
2. Salmancer (talk) My qualms have been assuaged. This change would be helpful to people around the world, and as a digital wiki it comes at extremely low resource costs. (Has this wiki ever had an issue of server space? I don't think it has, and I don't think redirects are going to move the needle on that.) While recent changes and frequent users of it will be annoyed by this, the feature is ulimately meant ot be transient content, and therefore a temporary hassle to that page should not prevent a permanent improvement to the wiki.

#Balugio (talk) Per me.

Oppose

1. Altendo (talk) This is an English wiki. While I do understand the accessibility, creating what could be hundreds of thousands of redirects just for the sake of accessibility is not worth it at all. Not to mention that "the subject which is most 'used'" is incredibly vague and what if two subjects with the same foreign name are used just as equally? Does this constitute more disambiguation pages just for those? I don't think this is worth it just for a little more accessibility. The Search function can adequately show the parent page just from a foreign name, like how "Princesa Pêssego" only shows Princess Peach and her language page. I don't think creating redirects just for this purpose would be helpful, and if anything, they will likely just take up precious server space that could be reserved for much better purposes, on top of slowing things down a lot due to how both the creation and maintenance of these redirects and disambiguation pages solely for foreign languages will clog up Special:RecentChanges, as they will likely be the largest spot for wiki-scale operations performed by PorpleBot.
2. Rykitu (talk) Per Altendo.
3. Nintendo101 (talk) Per Altendo.
4. Camwoodstock (talk) The only context we can imagine this being useful are for things where there are multiple foreign names, but no English name... but like... in that case, you can presumably just make those redirects without proposal anyways, and the situations where that's true are very, very slim. Off the top of our head, it's basically just Shitamachi Ninjō Gekijō, which has "Lily Franky Theater" and "Lower City Empathy Theater" as valid Japanese names. This would only serve to clog the search bar.
5. YoYo (talk) per Altendo
6. LadySophie17 (talk) Per Altendo.

Comments

Answering Hewer about the “few exceptions” thing, I actually once got a reason from Mario JC for that. It’s a “notable” foreign name. The problem is, in other countries, names other than the English ones are notable, so it’s kinda nonsensical. Balugio (talk) 17:15, September 3, 2025 (EDT)

I'd argue that if it's official, it's notable. Otherwise we wouldn't be noting it. Hewer (talk · contributions · edit count) 17:18, September 3, 2025 (EDT)

Exactly. Balugio (talk) 17:21, September 3, 2025 (EDT)

This sounds like a lot of trouble. We can barely keep our current redirects straight with all the page moves and content deletions that are eternally happening because the wiki is never complete, as you usually learn when a redirect takes the reader to the top of a page when the section it used to directly link to gets deleted. This proposal is slated to add thousands more redirects. Redirects, I might add, that are harder to maintenance than ones we already have because no single standard keyboard is equipped to handle every language the wiki supports in our Names in Other Languages sections. Most of the time, I use the search bar to bump into redirects, but that's a much harder option if I instead have to copy and paste text into the search bar from the bottom of each article. I think at some point, we can't make a redirect for everything someone could conceivably put into the search box, at least not without costs in terms of workflow which could cascade into usability concerns because we're spreading ourselves too thin. Salmancer (talk) 02:51, September 4, 2025 (EDT)

What do you mean you "have to" paste text into the search bar for these redirects? If your keyboard can't type out the redirect, you're not the person it's intended to help, and that's fine since you can just type out the actual name of the article to reach it instead. Either way though, if redirects in non-Latin scripts are such a problem (and I'll admit that their chance of being helpful would be quite small), we can just exclude them and only make Latin script redirects. Hewer (talk · contributions · edit count) 04:36, September 4, 2025 (EDT)

I mean like how "when a section's name changes, every redirect that goes to that section will break and only take the reader to the top of the page, and redirects breaking in this way is difficult to track so the only thing that has these redirects being fixed is someone with an account using the redirect, realizing it broke, and replacing the redirect's destination with the new name of the section." You know, like how Donkey Kong Country Returns (3D) sections became Donkey Kong Country Returns (3D / HD) sections with the release of Donkey Kong Country Returns HD. And with names in other languages, there's very good reason to use section links, as there are plenty of names that are only used for one game. I guess being sent to the top of the page instead of the intended section isn't that bad but its still a problem that would make the wiki look worse to have. You are right in that I personally don't have to try to fix these broken redirects as they arise, but I fear the people who support this proposal will just make the new redirects and then never look back, and of the people who will use the redirects, a decent number of them will not themselves be wiki editors and thus those people/users will not fix them if they are broken. Salmancer (talk) 14:25, September 4, 2025 (EDT)

I really don't think linking to the top of a page instead of a specific section is that huge a problem unless it's a list article or something, there are honestly cases where I would prefer that. A redirect that gets you generally where you're trying to go is better than no redirect at all, perfect is the enemy of good. Hewer (talk · contributions · edit count) 14:55, September 4, 2025 (EDT)

What about Template:Redirect and Template:Redirect-distinguish? Will those templates be added to new pages to account for redirects based on names in other languages? While we probably don't have to place "Kuribon or Goombruno may be referring to Goombob" at the top of Galoomba's page, there are cases where we might have to: Nanshī is both Raini and Zess T. in Japanese, Piattaforma girevole is Italian for both Single Swing Lift and Triple Swing Lift, and Ossec is French for both Honebon and Fish Bone. Nevermind the eternal problems "big enemies" cause us. Should there be a limit on the number of redirect templates on the top of the page, because having too many is bad? Maybe we make disambiguation pages for other languages, but that would be increasing the proposal's scope a bit. Maybe we just don't use Template:Redirect and Template:Redirect-distinguish at all? Salmancer (talk) 18:46, September 4, 2025 (EDT)

Is this not the entire purpose of those templates? I don't see the issue with just applying all our standard redirect procedures here. We even already do this in some language-related cases, look at the top of Vanna T.'s article. Hewer (talk · contributions · edit count) 19:59, September 4, 2025 (EDT)

Rework Super Mario Galaxy and Super Mario Galaxy 2 appearance tables

Use Rework A 10-1-7-0
During a conversation in the Discord server, the idea of reworking how we list appearances for subjects in Super Mario Galaxy and its sequel Super Mario Galaxy 2 was floated. The current implementation uses a specially-made table standard (see below for example), but various users voiced several perceived flaws with its design, such as:

• utilizing icons for conveying information when text suffices;
• combining icons representing mission type and icons representing subject presence, with only the latter being listed in the key;
• arbitrarily using the Pull Star icon for something that is not a Pull Star;
• not conveying mission names without hovering over or clicking on the icons, alienating readers not familiar with the Galaxy games;
• relying on hover text, which is unavailable on touchscreen devices like tablets or smartphones;
• taking up a lot of space, to the point of needing a collapsible section most of the time;
• being inconsistent with how subject appearances are listed in other games.

EvieMaybe drafted up an alternative to it, and Doc von Schmeltwick (who created the original tables) drafted up an alternative to that alternative. With three competing options, the most sensible choice was to put it up to vote. Then Altendo suggested another option, making it four. See below:

• Goomba's Super Mario Galaxy appearance list at the time of writing, for comparison and posterity. As Goombas are the most common enemies in the game, it serves as a good benchmark for how large each format can get.

• marks missions where they are completely absent.
• marks missions where they are loaded and may be visible, but cannot be encountered directly.

Domes	Galaxies	Missions
Gate	Gateway Galaxy
Terrace	Good Egg Galaxy
Fountain	Space Junk Galaxy
	Rolling Green Galaxy
	Battlerock Galaxy
	Hurry-Scurry Galaxy
Kitchen	Beach Bowl Galaxy
	Buoy Base Galaxy
	Bowser Jr.'s Airship Armada
Bedroom	Gusty Garden Galaxy
	Freezeflame Galaxy
	Dusty Dune Galaxy
	Bowser's Dark Matter Plant
Engine Room	Gold Leaf Galaxy
	Bowser Jr.'s Lava Reactor
Garden	Deep Dark Galaxy
	Dreadnought Galaxy
Comet Observatory	Rolling Gizmo Galaxy

• Rework A, by EvieMaybe: Focusing on compactness, it exclusively represents information through text, avoiding the usage of icons or hover text. However, it sacrifices displaying mission types, mission numbers, and domes.

Goombas appear in the following list of galaxies. If no mission is stated, Goombas appear during all missions:

• Gateway Galaxy
• Good Egg Galaxy
• Space Junk Galaxy
• Rolling Green Galaxy
• Battlerock Galaxy (exclusive to "Topmaniac and the Topman Tribe")
• Hurry-Scurry Galaxy
• Beach Bowl Galaxy (exists in all missions, but only accessible in "The Secret Undersea Cavern" and "Wall Jumping up Waterfalls")
• Buoy Base Galaxy
• Bowser Jr.'s Airship Armada
• Gusty Garden Galaxy (exists in all missions but "Major Burrows's Daredevil Run", but isn't reached in "The Golden Chomp")
• Freezeflame Galaxy (exclusive to "The Frozen Peak of Baron Brrr", "Freezeflame's Blistering Core", and "Conquering the Summit")
• Dusty Dune Galaxy (exclusive to "Soaring on the Desert Winds")
• Bowser's Dark Matter Plant
• Deep Dark Galaxy (exists in all missions, but only accessible in "The Underground Ghost Ship", "Bubble Blastoff", and "Boo in a Box")
• Dreadnought Galaxy (exclusive to "Infiltrating the Dreadnought")
• Rolling Gizmo Galaxy

• Rework B, by Doc von Schmeltwick. Serving as a compromise between the current standard and Rework A, it takes up a lot more space and utilizes icons to convey information, but it does include mission types, mission numbers, and domes. It is also simpler to edit the current setup into it via search-and-replace due to similar structure.

• Gate
  • Gateway Galaxy
    • 1. Grand Star Rescue
    • 2. Gateway's Purple Coins
• Terrace
  • Good Egg Galaxy
    • 1. Dino Piranha (mission)
    • 2. A Snack of Cosmic Proportions
    • 3. King Kaliente's Battle Fleet
    • 4. Dino Piranha Speed Run
    • 5. Purple Coin Omelet
    • 6. Luigi on the Roof
• Fountain
  • Space Junk Galaxy
    • 1. Pull Star Path
    • 2. Kamella's Airship Attack
    • 3. Tarantox's Tangled Web
    • 4. Pull Star Path Speed Run
    • 5. Purple Coin Spacewalk*
    • 6. Yoshi's Unexpected Appearance
  • Rolling Green Galaxy
    • 1. Rolling in the Clouds
  • Battlerock Galaxy
    • 3. Topmaniac and the Topman Tribe
  • Hurry-Scurry Galaxy
    • 1. Shrinking Satellite
• Kitchen
  • Beach Bowl Galaxy
    • 1. Sunken Treasure*
    • 2. Passing the Swim Test*
    • 3. The Secret Undersea Cavern
    • 4. Fast Foes on the Cyclone Stone*
    • 5. Beachcombing for Purple Coins*
    • 6. Wall Jumping up Waterfalls
  • Buoy Base Galaxy
    • 1. The Floating Fortress
    • 2. The Secret of Buoy Base
  • Bowser Jr.'s Airship Armada
    • 1. Sinking the Airships
• Bedroom
  • Gusty Garden Galaxy
    • 1. Bunnies in the Wind
    • 2. The Dirty Tricks of Major Burrows
    • 3. Gusty Garden's Gravity Scramble
    • 5. Purple Coins on the Puzzle Cube
    • 6. The Golden Chomp*
  • Freezeflame Galaxy
    • 1. The Frozen Peak of Baron Brrr
    • 2. Freezeflame's Blistering Core
    • 6. Conquering the Summit
  • Dusty Dune Galaxy
    • 1. Soaring on the Desert Winds
  • Bowser's Dark Matter Plant
    • 1. Darkness on the Horizon
• Garden
  • Deep Dark Galaxy
    • 1. The Underground Ghost Ship
    • 2. Bubble Blastoff
    • 3. Guppy and the Underground Lake*
    • 4. Ghost Ship Daredevil Run*
    • 5. Plunder the Purple Coins*
    • 6. Boo in a Box
  • Dreadnought Galaxy
    • 1. Infiltrating the Dreadnought
• Comet Observatory
  • Rolling Gizmo Galaxy
    • 1. Gizmos, Gears, and Gadgets

* marks missions where they are loaded and may be visible, but cannot be encountered directly.

• Rework C, generously provided by Altendo in the comments. Serving as an even less compromising compromise than Rework B, it mantains the use of icons, but implements them into the text directly. That, plus the addition of the column template, makes it the most visually compact of the four.

• Gateway Galaxy ( • )
• Good Egg Galaxy ( • • • • • )
• Space Junk Galaxy ( • • • • • )
• Rolling Green Galaxy ()
• Battlerock Galaxy ( • • • • • • )
• Hurry-Scurry Galaxy ()
• Beach Bowl Galaxy ( • • • • • )
• Buoy Base Galaxy ( • )
• Bowser Jr.'s Airship Armada ()
• Gusty Garden Galaxy ( • • • • • )
• Freezeflame Galaxy ( • • • • • )
• Dusty Dune Galaxy ( • • • • • • )
• Bowser's Dark Matter Plant ()
• Gold Leaf Galaxy ( • • • • • )
• Bowser Jr.'s Lava Reactor ()
• Deep Dark Galaxy ( • • • • • )
• Dreadnought Galaxy ( • • • • • )
• Rolling Gizmo Galaxy ()

If any Support option passes, the chosen standard will be gradually rolled out across every Galaxy and Galaxy 2 history section, replacing the current tables.

Proposers: EvieMaybe (talk) and Doc von Schmeltwick (talk)
Deadline: September 19, 2025, 23:59 GMT

Support: Use Rework A

1. EvieMaybe (talk) per proposal.
2. DryBonesBandit (talk) Per proposal. Information about the mission itself is irrelevant to listing appearances in my opinion, since the whole focus is about listing appearances. If the reader wants more info, they can go to the mission’s article.
3. Mario4Ever (talk) Per proposal.
4. Waluigi Time (talk) This is a nice design that's pretty much as compact as you can be with this. I don't think all the extra info about domes and star types is very important to the enemies themselves, but if there are interesting trends (e.g. an enemy mainly appears in comet missions or Grand Star galaxies, is more common towards the beginning/end of the game, etc.) that's worth explicitly noting in the text itself. I would suggest skipping this for enemies like Whimp that only appear in a single mission in a single galaxy and leaving that to the text, however.
5. SolemnStormcloud (talk) Per proposal.
6. Camwoodstock (talk) Maybe if the icons were a bit smaller, we'd be fine with Rework B? For now though, simplest is definitely best.
7. PopitTart (talk) the prose makes it very easy to get a grasp of the information in this one. The subject appears in this given galaxy, but only in the context of these star missions. On top of that its markedly more compact, not needing to iterate on every single mission if its in all of them, its just. in the galaxy. Plus, I think this scheme would be very easy to apply to the other games that use a similar format, where listing every single mission might be a ridiculously tall ask. Such as this for Sherm:
   • Wooded Kingdom (only after completing "Flower Thieves of Sky Garden"
   • Metro Kingdom (only in "The Scourge on the Skyscraper")
8. Nintendo101 (talk) I think this is the most intuitive option.
9. Dive Rocket Launcher (talk) My preference. I think option B takes up too much space, and I don't like how option C uses the hidden star icon to represent something different from what it means in the game itself.
10. Scrooge200 (talk) This one is the most obvious and doesn't require hovering to see certain missions' names.

Support: Use Rework B

1. Doc von Schmeltwick (talk) - Per proposal

#Sargent Deez (talk) Icons aren't necessary, but in longer articles, the more breaks from walls of text you have, the better.

Support: Use Rework C

1. Sorbetti (talk) It looks better. Per Camwoodstock.
2. Doc von Schmeltwick (talk) - Docky likey.
3. Altendo (talk) Guess I was beaten to first vote... nah, I'm kidding. Anyways, as the creator of the this option, I think it looks the most consistent with other enemy appearance sections as well as the most compact, on top of having each galaxy consistent with each other (which the first option doesn't have) and being incredibly compact (which the second option isn't).
4. Sargent Deez (talk) Good compromise
5. Tails777 (talk) I kinda like the idea of using icons to convey information. I abstained at first, but I do like this newly added option.
6. LinkTheLefty (talk) These substantial spaces are supermassive, so a slick, streamlined strategy is supremely sublime.
7. Pseudo (talk) This is a really pretty design, and I'm partial to the use of visual elements!

#Camwoodstock (talk) Secondary option. While we prefer the text, we do think this is a nice middle ground of visuals, while keeping information dense.

Super Comment Galaxy

I think these tables should just be deleted altogether. No other game aside from these two (as far as I can tell) have appearances subsections, and the tables, including the proposed solutions, all look jarring to me. Altendo 22:24, September 4, 2025 (EDT)

the plan is to have lists of appearances for every enemy in every mainline game, i think. i'm for it, and pretty much everyone else i've talked to is for it too. — eviemaybe (talk / contributions) 23:45, September 4, 2025 (EDT)

See Dry Bones for a page that currently does have them for most every game. Doc von Schmeltwick (talk) 01:12, September 5, 2025 (EDT)

Thank you, Dry Bones was the one page I never thought to look to. I was thinking of an even more middle ground, like this:

• Good Egg Galaxy ( • • • • • )
• Space Junk Galaxy ( • • • • • )
• Beach Bowl Galaxy ( • • • • • )

EDIT on 13:32, September 5, 2025 (EDT): I just read the flaws with the original design, and I think I didn't account for some of them when I initially did this. The second point is important, as people could mistake a mission where an enemy is loaded but not encountered with an actual hidden mission. I have modified the above table to account for this, only using normal Power Stars and colored Power Stars (like red and green) for the icons where they do appear in, making them consistent with the mission select screen in the Galaxy games:

• Good Egg Galaxy ( • • • • • )
• Space Junk Galaxy ( • • • • • )
• Beach Bowl Galaxy ( • • • • • )

This doesn't solve every problem with this (this still relies on icons and hover text), but my proposed solution likely will not need a collapsible section or even a subheader, as it is consistent (minus the mission icons) with how other games show which enemies appear in which levels. After all, no solution is going to be perfect, but I think my proposed one is the closest to the ones currently used for other games in the Dry Bones example.

As for the ones where enemies don't make an appearance, we don't have the sprite for it yet, but I found the one used in SMG2 on the Spriters Resource, and seeing how the hidden mission sprite is the same in SMG and SMG2, I can assume the same for the uncollected star sprite even though the sprites between the games are different, I think they will work for now as they are used in SMG galaxy pages, but I will still try to find or extract hidden and uncollected Power Star sprites from the first game.

Personally, this not only looks a lot more compact but also consistent with the other games in the Dry Bones example used. As for Grand Stars and Prankster Comets, although there is a sprite for an uncollected Prankster Comet available, because there are currently no sprites for uncollected Grand Stars, and because there are no "hidden" Prankster Comets or Grand Stars, I think using the normal hidden and uncollected Power Star sprite is fine, as the current tables do something similar, albeit with Pull Stars. I would like to hear what people think of this idea. Altendo 13:19, September 5, 2025 (EDT)

I like it. Doc von Schmeltwick (talk) 15:42, September 5, 2025 (EDT)

@Altendo interesting. if you format the Goomba section like it and paste it in my sandbox, i'll add it to the proposal. it's been less than four days, after all, so it can still be edited. — eviemaybe (talk / contributions) 15:46, September 5, 2025 (EDT)

I pasted it onto your sandbox. Altendo 20:12, September 5, 2025 (EDT)

Establish a general guideline for backdrop colors of sprites and models vs. other image types in galleries

Do not create guideline 1-10
Right now galleries often use backdrop of different colors for various reasons. If I understand it correctly, non-default colors are most often applied to sprites that contain white parts that would blend with the white backdrop, but some pages use custom colors to match background colors seen in-game (like in this gallery). However, whether a non-default background color is used or not is inconsistent.

This proposal doesn't aim to change any of the already applied background colors. I'm proposing the following guidelines:

• For artwork and screenshots, never use a colored backdrop except to make the image clearer. Reason: the white backdrop (in the light theme) matches the idea of an image meant for print or for a web page.
• For sprites, in-game renders and models, always use colored backdrops. By default, consider using grey (as some sprites in some galleries already do), especially for models and sprites after the 8-bit consoles. It's neutral and non-distracting, it's the most basic backdrop color for viewports in modeling software, and sort of implies the image is laid on a transparent background. For games that have an exclusively black backdrop (such as Donkey Kong or Wrecking Crew), consider having all backdrops be black instead. Again, these are suggestions for ease of reading and consistency, and backgrounds of other colors would still be acceptable.

Examples:

• 

  Print/promotional art (default backdrop)

• 

  In-game graphics (colored backdrop)

• 

  Screenshot (default backdrop)

• 

  Sprite/model (colored backdrop)

• 

  Sprite (colored backdrop)

• 

  In-game render (colored backdrop)

• 

  Model (colored backdrop)

• 

  Sprite (game with black backdrop; colored backdrop)

Proposer: Bro Hammer (talk)
Deadline: September 26, 2025, 23:59 GMT Closed early on September 19, 2025, 23:59 GMT

Support: create a guideline for gallery backdrops

1. Bro Hammer (talk) Per proposal.

Oppose: do not include guidelines for gallery background colors

1. Doc von Schmeltwick (talk) - I don't think this really needs all-or-nothing rules. Also, some sprites require a white background for the same reason as some require black (like Super Mario Land's), so unless you count that as "colored," then that won't work.
2. Altendo (talk) Per Doc.
3. Waluigi Time (talk) My preference is that colored backgrounds only be used when absolutely necessary for readability of the image.
4. EvieMaybe (talk) per Waluigi Time. personally, i would suggest changing the default gallery background to move it away from white slightly.
5. Colin's world 3 YT (talk) per Waluigi Time. this would be a lot of work to enforce.
6. Camwoodstock (talk) Per all, and the mere existence of Super Mario Bros. Special... no, actually, we have a concern about that game specifically. That game's (extremely gaudy) graphics were made with exactly 8 colors in mind, and thus, its gallery is set up very specifically to handle that. A blanket rule over everything, naturally, would pave over this, and cause problems, as of those 8 colors... None of them are gray. At all. And many sprites were made, expressly, to be viewed on a blue or black background. However ugly you think the game's graphics are, we think people would agree they'd look even uglier if the gallery didn't fit the graphics themselves. Imagining this already fairly muddy sprite with a dark gray border around it that doesn't fit the context is, no joke, a good enough reason in our eyes to say a blanket rule like this would be bad:
7. Arend (talk) Colored backdrops are typically used for either showing an image clearly (e.g. to show white elements which are hard to see on a VERY light background), or to have it shown as intended by the developers (e.g. some NES sprites use transparency on a black backdrop as a "fourth" color). The former can also work vice versa (i.e. showing dark gray elements that are hard to see on a dark background) when dark mode is involved, and the same goes for the latter (e.g. some Game Boy sprites have their "fourth color" be transparency on a white background). All well and good, but the biggest problem lies with the fact that it's being proposed to always use colored backdrops for sprites and models, even when it's not necessary at all, and to never use them on artworks (which, yes, includes logos); the latter being especially problematic because the whole clarity issue is NOT a sprite-exclusive issue: this wiki DOES host official logos and artworks (whether they be PNGs or SVGs) that are very difficult to see on the normally VERY light bg, and the same goes for logos and artworks that are difficult to see on dark mode's dark bg. The current case-by-case method is fine.
8. Jdtendo (talk) I would prefer that colored backgrounds be used only for making the image clearer, and not impose it for sprites and models.
9. Scrooge200 (talk) Agreed with Arend; this should mainly go if the sprite is difficult to see or displays improperly/inaccurately against a white background.
10. PanchamBro (talk) Implementing this would be an accessibility nightmare, especially considering the black backdrop would make it extremely hard to see the sprite at all.

Comments (Create a guideline for gallery backdrops)

“However, whether a non-default background color is used or not is inconsistent.”

—Bro Hammer
Have you looked at thise same galleries using non-default bg colors while using Dark Mode, too? Sometimes, a colored bg is used for sprites with black or dark gray elements to make them more clearly visible in dark mode as well. rend (talk) (edits) 06:33, September 12, 2025 (EDT)

Speaking of Dark mode and galleries... I think it'd be a good idea for galleries and {{class}} to get a few additional classes: darkmodebg and lightmodebg, which will force a gallery image to use that mode's background color (#333 for darkmodebg, #f8f9fa for lightmodebg), so that light mode users aren't confused why a normally clearly visible image has a different color background for some reason (and vice versa)... because it'll look all the same for them in light mode, while it won't look all the same in dark mode. rend (talk) (edits) 16:44, September 13, 2025 (EDT)

That actually is used in some places, like the SMB3 gallery. Usually as a section-wide thing, though. Doc von Schmeltwick (talk) 11:48, September 14, 2025 (EDT)

No it's not??? The SMB3 gallery uses blackbg and whitebg, as well as custom colored backgrounds that emulate the other in-game colored backdrops (which aren't visible in dark because no --darkbg equivalents had been implemented), and those colors are used to emulate how a sprite looks like in the game itself... which is NOT what I was talking about AT ALL.
MY suggestion to add lightmodebg and darkmodebg is about to make an image clearly visible in one skin mode, WITHOUT making it stand out in the OTHER skin mode (as it'd be already visible in said mode with its default gallery bg). For example:

• 

  By default, this gallery image's bg would be #f8f9fa in light mode, and #333 in dark mode (swap between modes and see for yourself)

• 

  My idea for lightmodebg is that it forces the image bg to be the same as light mode
  (#f8f9fa) regardless of skin

• 

  Likewise, my idea for darkmodebg is that it forces the image bg to be the same as dark mode (#333) regardless of skin

This would ensure that it makes an image clearly visible in, say, Dark Mode, without it making it stand out in Light Mode (due to the image already being visible), and vice versa; and I think that whole "standing out" thing is how this proposal came into fruition into the first place, as Bro Hammer appears to be under the impression that bg colors are sometimes being used haphazardly, when most of the time, they're not. rend (talk) (edits) 15:03, September 14, 2025 (EDT)

Out of curiosity, are there any specific use-cases you have in mind for the suggested lightmodebg over the pre-existing whitebg? Since, at least off the cuff, most of the use cases (read: most of what we're thinking of are Game Boy game sprites) would be largely redundant to just straight up white, and it's not like whitebg just fails to load based on light/dark modes.

• 

  See?

(as an aside, we kinda wish we could indent galleries, it's making this a bit annoying to follow ^^;) ~Camwoodstock ( talk ☯ contribs ) 15:13, September 14, 2025 (EDT)

whitebg is slightly different, as it is PURE white (#FFF), whereas the lightmodebg (#f8f9fa) is not. And there have been artworks (and logos) that blend too much with the default darkmodebg.

• 

  This image is a home page bg for the Super Mario Bros. 35th Anniversary, which looks pretty normal in light mode.

• 

  But in dark mode, it's barely visible.

• 

  Using lightmodebg with {{class}} will make it visible in dark mode without making it stand out in light mode

• 

  But using whitebg instead might make it stand out a tad too much in light mode

Admittedly, it's barely a difference in retrospect (in dark mode, anyway), especially compared to the huge difference that is blackbg vs. darkmodebg, so take it for what you will. rend (talk) (edits) 15:25, September 14, 2025 (EDT)

Change game quote lists to game scripts

Change to game scripts 10-2
Game quote pages have always felt like such a nebulous, impossible task. When are they done? They used to just list important or memorable quotes, but recently have spiraled into documenting every line of dialogue in a game, especially for RPGs. It feels like a bit of a waste to only include some dialogue based on what we deem "important." They're also a pain to actually make sense of, since a conversation between two characters can be buried in a list of other quotes with no indication they're part of the same scene.

Taking a cue from old GameFAQs documents, I propose renovating these into full-on "game scripts" that detail every interaction and cutscene in the game. Here's an example of what I would want out of one of these pages, using the opening cutscene of Hotel Mario as an example.

(Mario and Luigi walk towards a gate with "Mushroom Kingdom" written on it. Bowser looks out from behind the bushes.)

Bowser: (evil laugh)

Mario: Nice of the princess to invite us over for a picnic, eh, Luigi?

Luigi: I hope she made lots of spaghetti!

Mario: Luigi, look!

(Mario points off-screen, and Luigi turns to look. Wooden boards with "Klub Koopa Resort" have been nailed over a gate, and a letter is taped to the door. Mario takes the letter down.)

Mario: It's from Bowser! (reading the letter) "Dear pesky plumbers: The Koopalings and I have taken over the Mushroom Kingdom! The princess is now a permanent guest at one of my seven Koopa hotels! I dare you to find her if you can!" (stops reading, to Luigi) We gotta find the princess!

Luigi: (pointing to the camera) And you gotta help us!

Mario: If you need instructions on how to get through the hotels, check out the enclosed instruction book.

(Fade to black. Gameplay begins.)

It will be easier to know when a page is complete, or where additions are needed. You can look at it on a level-by-level basis and see what interactions cause which quotes to appear, so it's pretty obvious which parts of the game are missing and still need quotes.

An example of how this would be done for an RPG with an explorable area and multiple NPCs can be found here. The formatting is rough and subject to change, but documenting each line, the flow of the dialogue, and what options Mario has are the key points.

Games where quotes show up mostly at random, like Mario Kart and Mario Party, can stay mostly the same.

I can see a concern that this could increase flowery writing, but I think that would be easy to control. You're directly describing what happens in the game, and adding sentences like "Mario spins his hat and gives a thumbs up to the camera" or "Mario stares at the graffiti in confusion" for context between the dialogue just makes it easier to understand. It's no different than a usual plot or scene summary.

What if you want to find dialogue from a specific character? You can always use Ctrl+F, and if they only appear in one or two levels, all of that dialogue will still be in one place. It's just more in-context. I also think the character quote pages can stay how they are for now.

Proposer: Scrooge200 (talk)
Deadline: September 28, 2025, 23:59 GMT Closed early on September 21, 2025, 23:59 GMT

Support (All-Star Scripters)

1. Scrooge200 (talk) Per proposal.
2. Hewer: Game quote lists are currently quite unhelpful most of the time because the quotes are all scrambled and removed from their context, and this is a great idea to solve that. In the less likely scenario that you want to know only what a specific character says in a specific game, that's what the character quote lists are for (this proposal passing will make those pages less redundant too).
3. Altendo (talk) Per Hewer.
4. Rykitu (talk) Per all.
5. Camwoodstock (talk) Per proposal. We don't think these transcript pages would hurt. Even if they would take a lot of effort to compile, we are well aware of what this community is capable of when it puts its mind to things. As for concerns about copyright, a lot of this information is already out there, in the form of raw text dumps, spread sheets, or even entire dedicated websites, and the amount of times we've heard of one of those being taken down for being "too much" in terms of copyright infringement can be counted on one hand, since you can technically make your hand into a fist... our joking aside, if we're already covering some pretty technical information about a few of these games, we don't see why providing the game's text would somehow be a tipping point. A seldom few genres of game can realistically be replicated just from text dumps alone, and unless you really want to argue that a full transcript of the Swoon.exe sequence from Super Paper Mario counts as "a full game that can be replicated from dialogue alone", none of those genres are really represented in the Mario franchise.
6. SolemnStormcloud (talk) Per proposal.
7. Nelsonic (talk) Per proposal.
8. Pseudo (talk) Though it would likely take considerable time to implement, this would be a really useful feature for the wiki. I often find myself frustrated when I can't find certain quotes on this wiki. Documenting text here is really useful for reference purposes.
9. janMisali (talk) Per all. The quote pages as they're formatted now would make sense if they were a curated selection of memorable or notable quotes, but in practice they're far more comprehensive than that, and between the options "remove most quotes from quote pages" and "reformat the quote pages to put all the dialogue in context" the latter is the clearly better choice.
10. Reese Rivers (talk) Per all.

Oppose (It's Not 2007 Anymore)

1. Salmancer (talk) I'm not really a fan of "write down all the dialouge in the in the game" pages, and while this would improve the pages my dislike of the pages in question trumps that. If we as a wiki emphasize curation, as we seemingly are when people say that "we aren't an asset dump", then to wantonly plunk every scrap of text from almost every work would likely go against this by positioning the wiki as at least partially as a kind of text dump. I would much rather focus on copying transient content onto the wiki, like social media posts or website features, and yes also things that are as extremely obscure and hard to get a hold of like Saturday Supercade. (Not The Super Mario Bros. Super Show!, that's just old media since it can be accessed on Youtube.) But we should be staying far away from "every line of dialogue in Super Mario Odyssey. That's a problem for another website, probably one with fewer concerns over duplicating material under copyright than we have. Otherwise, why were we uploading 30 second snippets of songs instead of entire songs before the release of Nintendo Music, before there was a prominent reason for Nintendo to start handing out takedowns over music uploads?
2. LinkTheLefty (talk) Thinking on it, I don't agree that we're ready to add text dumps to our list of asset-dumps that pros and fans alike see. It's probably better to leave those resources on other sites for the time being.

Comments (Needs Revisions)

Does this affect quotes lists for TV shows? Those pages do suffer from similar issues to the game quotes pages, but the same solution of having full scripts for non-interactive media might not be ideal (a previous discussion about it brought up concerns of copyright infringement). There's also the quotes pages for films, but these seem to take a different approach of having non-exhaustive lists for each character followed by snippets of actual dialogue. Hewer (talk · contributions · edit count) 18:54, September 14, 2025 (EDT)

Honestly, transcripts for TV shows, and maybe even movies, feels like a very nice addition to have, though it's definitely a lot more involved. We don't see why it'd count as copyright infringement--we have seen multiple cartoons' wikis feature transcripts, and have never heard of a legal case over them--our concern is moreso in how, inherently, transcribing a whole movie is very time-consuming. ~Camwoodstock ( talk ☯ contribs ) 20:01, September 14, 2025 (EDT)

Well, so is maintaining a wiki on the world's biggest video game franchise. Hewer (talk · contributions · edit count) 20:10, September 14, 2025 (EDT)

Oh, make no mistake, we weren't saying that as a "oh, it's too much effort, so Why Bother?"--we were around for the Great Aboutfile Rush of Late 2024, so we know how this community can lock in. We're just saying that implementing this proposal would very much be a coordinated effort. ~Camwoodstock ( talk ☯ contribs ) 22:23, September 14, 2025 (EDT)

This proposal itself wouldn't affect anything from the shows, but I agree that having actual transcripts for those would be a big help -- especially for shows like Saturday Supercade where information is sparse and we should capture as much of it as we can. It could also cut down on how bloated and detailed some of the plot summaries are. The cartoons have been legally available for free on YouTube for over a decade now, so I can't imagine copyright takedowns would be too much of a problem. Mario show transcripts have also been put up on Lemmy's Land and Forever Dreaming, for reference, and those have been around for a while. I would personally wait on the movies, though, since they're very recent and part of a film franchise, with Nintendo and Universal being strict on copyright. Scrooge200 (talk) 20:59, September 14, 2025 (EDT)

Looking at your example, would it be possible to use a different shade of blue for the blue text? I get that important words are colored blue in the game proper, but as it is now, the blue text is indistinguishable from links. — SolemnStormcloud (talk) 00:15, September 16, 2025 (EDT)

Yes, this is just a placeholder. The current Superstar Saga list uses the same text color. Scrooge200 (talk) 19:42, September 17, 2025 (EDT)

@LinkTheLefty: I think people are missing the point: this isn't supposed to be a "text dump" as much as documenting games more in-depth, in a manner like Dialogue Tree. I would argue that putting these quotes in a single list with no context is arguably more of an asset dump. This can make it easier to find obscure interactions (for example, trying to buy items in RPGs without enough coins or a full inventory, attempting to leave an area you're not supposed to, bonus Easter eggs like repeatedly saying no to the Superstar Saga tutorial). We already do something more basic for the List of unnamed NPCs in Paper Mario and List of unnamed NPCs in Paper Mario: The Thousand-Year Door articles. Did you see the RPG example I linked? Scrooge200 (talk) 00:44, September 16, 2025 (EDT)

Delete Mario Party 7's minigame icons

Delete images 11-3-0
Currently, gathering dust in our unused files page, there are about 85 Mario Party 7 minigame icons that are essentially low resolution, horizontally squashed, screenshots of the minigames they represent. (88 if there's one for every minigame and I just missed some). I propose we delete them because of exactly that. The Super Mario Wiki is not a place to store all assets from a game, and since these icons are smaller versions of images we already have, they do not add anything and shouldn't be kept. Here are a few comparisons:

• Catchy Tunes Icon.png

  Catchy Tunes icon

• 

  Catchy Tunes screenshot

• Bubble Brawl Icon.png

  Bubble Brawl icon

• 

  Bubble Brawl screnshot

• Track & Yield Icon.png

  Track & Yield icon

• 

  Track & Yield screenshot

Alternatively, I propose that, if we simply must keep them, they should at least be added to their respective pages. I am including a status quo option per rules, but I strongly suggest people side one way or the other.

EDIT: I have looked a little further into this, and it seems like those "icons" are the first frames of the minigame preview videos that play before each minigame. I am unsure if they are even actually stored as images in the game or if they've been extracted for the wiki, if that makes any difference.

Proposer: LadySophie17 (talk)
Deadline: September 22, 2025, 23:59 GMT

Delete the icons

1. LadySophie17 (talk) Per proposal.
2. Altendo (talk) Per LadySophie in the edit and comments.
3. Polley001 (talk) Per proposal. As a wiki, any "archival" on our part should be that of information, not assets. If these sprites contained some kind of notable information things would be different, but that doesn't seem to be the case.
4. Camwoodstock (talk) Considering these "icons" seem to just be frame 1 of the video previews, we don't see why these should be kept. There's basically no reason to keep these over just... Ripping the full video previews, and uploading those.
5. Waluigi Time (talk) We're an encyclopedia, not an asset dump. If something doesn't serve any illustrative purpose I don't think we should have it just because it's there. We already have much higher quality images for these minigames that show the same thing, so we don't need these, especially if they're not even true icons.
6. OmegaRuby (talk) While I don't fully agree with the sentiment that we aren't an asset dump, I still believe the assets that we do collect and archive should have a true illustrative purpose unique from existing, higher-quality assets. While we should collect and showcase assets ripped from Mario games with a broad range, there's simply some assets that are unnecessary to collect and keep, especially in this case as Waluigi Time said. Having a full, extensive archive of assets is what the Spriters/Models/Sounds Resource is for.
7. Power Flotzo (talk) Per all.
8. Nintendo101 (talk) Per LadySophie17 and Waluigi Time.
9. Mario (talk) Screenshots exist.
10. Scrooge200 (talk) These are just low-res screenshots of minigames. (Mario Party 7 also has a bit too much of an asset dump problem, but that's for elsewhere.)
11. Xiahou Ba, The Nasty Warrior (talk) these aren't even screenshots, they're stills taken frome extremely compressed videos. there's no need to keep those.

#Colin's world 3 YT (talk) per all. these images aren't even USED ANYWHERE!

Place the icons in the pages

1. Hewer (talk) The icon for a minigame is exactly the kind of thing I'd expect to see in a gallery section on the minigame's page. If we're keeping the hundreds of screenshots used on Nintendo Music I think we can afford to keep these.
2. Doc von Schmeltwick (talk) - Unless I am mistaken, these are actual independent assets, rather than simply the first frame of a .wav-type video like some previously deleted "icons" were. If we're going to keep track icons for Mario Kart 64, it makes sense to do so here too. Also, the "we're not an asset repository" argument is something I have no sympathy for, so I'm not going to be swayed by that. If anything, these seem like a good thing for the minigame list IMO. If they are simply the first frame of a video asset, I will retract, as that is not the same thing as a full asset (and in such case we would be better to do a thing like the Mario Kart Wii track previews).
3. Colin's world 3 YT (talk) Per Doc von shmeltwick

#Altendo (talk) I don't see an issue with keeping lower quality versions of an image, especially if it can show readers the internal quality of Mario Party sprites compared to the native gameplay that is at much higher resolution. I do believe that they deserve a lot more recognition, and they should be placed in the minigame pages even with similar higher quality screenshots.

Comments (Minigame icons)

@Hewer We don't usually keep Nintendo Music screenshots alongside identical, better in every way, copies of them. In fact, we tend to outright replace older screenshots with better Nintendo Music ones. See the history of File:KalimariDesertMK7.png. — Lady Sophie ^(T|C) 09:08, September 8, 2025 (EDT)

That doesn't seem like the right thing to do, particularly for older games, given aspect ratio and resolution differences. Doc von Schmeltwick (talk) 10:52, September 8, 2025 (EDT)

The comparisons in the proposal show that the images are not identical. They feature different characters in different positions. Hewer (talk · contributions · edit count) 11:46, September 8, 2025 (EDT)

Is a different cast of interchangeable playable characters with different scores in different positions instrumental in documenting the general appearance of a minigame? Sure, you can argue that we should keep those images simply because they are frames of official assets, but arguing that they serve any purpose beyond archival for the sake of archival seems a bit farfetched to me. — Lady Sophie ^(T|C) 11:56, September 8, 2025 (EDT)

I just don't really see why "archival for the sake of archival" has to be a problem, or why we have to deem some assets too unimportant to cover. Putting these images in a gallery section is potentially helpful to someone who wants to see what they look like, and not harmful to anyone else. Hewer (talk · contributions · edit count) 14:22, September 8, 2025 (EDT)

@Doc von Schmeltwick In rebuttal to your argument about the track icons for Mario Kart 64, the reason those are presumably kept is because they are unique icons essentially illustrated to showcase them on the menu. Instead of low-res screenshots to represent the tracks, the icons were rendered/illustrated and converted into a texture, which you can see very clearly:

• 

  Note the lighting effects behind the snow particles in the Frappe Snowland icon.

• 

  There are beams of light on the trucks and a soft light effect from the streetlights for Toad's Turnpike.

• 

  See the cows pasted across Moo Moo Farm?

-- OmegaRuby [ Talk / Contribs ] 14:34, September 8, 2025 (EDT)

Technically:

• 

  Original art

• 

  Menu art

• 

  Website art

--Doc von Schmeltwick (talk)

Yes, this further clarifies the track icons are unique pieces of art for the courses and therefore actual icons as opposed to MP7's screenshot icons. Even if it's technically a lower-resolution version of existing artwork, it is unique artwork found in game which justifies the sprite's archival in game. The hi-res artwork is covered by the track name, too, so it's actually even more justified to archive the spriter as there's extra visual space covered up in the hi-res artwork. -- OmegaRuby [ Talk / Contribs ] 10:02, September 9, 2025 (EDT)

Okay, from what I can gather, these minigame preview icons stay static like this for one second before it becomes a looping animation. Both in the Free Play Sub menu and the minigame instructions. Because of this, I'm kind of torn whether we should keep them or delete them:

• Keeping them would make sense, considering we've kept preview icons of other levels, courses, and minigames from other games, particularly those from all the Mario Kart games, including the Extra courses from Super Circuit, which are in fact lighter-colored versions of the minimaps for those courses.
• However, given that they're only the first frame of an animated image, it would make more sense to replace these with animated versions of those icons, akin to the preview icons in Mario Kart Wii.
• HOWEVER however, if the first frame remains static for a second BEFORE it changes to a never-ending loop, THAT makes the first frame worth keeping again, as this is something the player would normally see anyway and appears to be the developers' intent.

rend (talk) (edits) 05:15, September 10, 2025 (EDT)

@Scrooge200 You accidentally left Mario's name in your vote instead of changing it to yours. Altendo 09:00, September 16, 2025 (EDT)

Appearance lists for all mainline games

canceled by proposer
A proposal that simplifies Super Mario Galaxy 1 + 2's appearance tables is looking to pass tonight. This got me thinking, why don't we do the same for other mainline games? Never mind... so Dry Bones and I'm guessing a few other articles do this already, but it's a column, not a table like the Galaxy games use. Now that there's a 99% chance that is being replaced by a bulleted list with no information on stars or missions, why can't we use it for other mainline games? I'm also confused why it's not automatically hidden like the Galaxy games, so my design, that is definitely not stolen from User:EvieMaybe (thanks for redesigning the appearances tables. I wish we used icons a little more, but that current, soon to be former one is a cluster) attempts to fix that: ㅤㅤㅤ

Dry Bones appear in nine levels:

• World 1-Fortress
• World 2-Fortress
• World 3-Fortress 1
• World 4-Fortress 1
• World 4-Fortress 2
• World 5-Fortress 2
• World 7-Fortress 2
• World 8-Fortress
• World 8-Bowser's Castle

Rework A, by me. I already went in detail on the specifics above, but basically, the main benefit is consistenty.

Dry Bones appear in nine levels:

• World 1-Fortress
• World 2-Fortress
• World 3-Fortress 1
• World 4-Fortress 1
• World 4-Fortress 2
• World 5-Fortress 2
• World 7-Fortress 2
• World 8-Fortress
• World 8-Bowser's Castle

Rework B, also by me. I don't support this design, as evident by this demonstration having an enemy that only appears once (Chargin' Chuck in Super Mario Advance 4: Super Mario Bros. 3) but it's more consistent with the enemy lists on level articles.

Levels	Count
Vegetable Volley	3 (regular) 3 (clappin)

Proposer: Sargent Deez (talk)
Deadline: October 3, 2025, 23:59 GMT

Support: Use Rework A

1. Sargent Deez (talk) Per proposal

Oppose: Keep current format

1. EvieMaybe (talk) per Waluigi Time in the comments. Template:Columns works for some lists and not for others. ultimately, it's just the same information presented in the same way, just arranged slightly different. setting a "we always/never use columns" rule feels like putting unnecessary limits.
2. Rykitu (talk) Per evie and Waluigi Time.
3. Camwoodstock (talk) Per Evie. Something like this should be flexible, and an "always columns" and "never columns" is not that.
4. Arend (talk) Per all, we shouldn't enforce users to never use columns just because it's consistent with the prior proposal (which, uh, never actually specified that columns should never be used for those? It only says that it was designed for compactness and avoids icons and hover text). Also, when I first viewed this proposal, I was using my phone in portrait mode, which makes the current-standard list that used columns look identical to your rework A that didn't use columns. How much is it going to matter if you can't tell the difference in mobile viewing?
5. Waluigi Time (talk) Per my comment.

Discussion

Speaking as the person who implemented the current lists on the Dry Bones page, my intention was never for columns to be the gold standard for these lists, just an option that users can employ if desired to make things more compact - some of these lists can get pretty long, especially when we get around to implementing them for more common enemies like Goombas. Even on Dry Bones, this isn't rigidly enforced - a few sections have levels listed in prose when there's not many of them. Most games are a lot less complicated than the Galaxy situation so I think as long as the info is there, we can worry a little less about exactly how it's presented. Basically, I'm for flexibility here. -- Too Bad! Waluigi Time! 20:05, September 19, 2025 (EDT)

User:EvieMaybe, User:Rykitu and User:Camwoodstock, you seem to have misunderstood. I'm not saying we can't use columns at all, but in this case, why would we when the Galaxy games use bulleted lists? Don't you think it'd be weird having two formats for the same type of information on the same article? If the Galaxy games used columns, I'd make the same point against bulleted lists.  — 13:11, September 20, 2025 (EDT)

so this proposal is meant to be "bullet point lists vs tables", then? i'm confused — eviemaybe (talk / contributions) 13:53, September 22, 2025 (EDT)

Only for appearance list on enemy articles. I'm not sure if it's been updated on all articles yet, but Galaxy now uses bulleted lists for its enemy articles, so I think all games should for consistently. Sorry for not explaining well.  — 20:10, September 22, 2025 (EDT)

if that's the case, there's already a proposal about that. i recommend you cancel this one — eviemaybe (talk / contributions) 20:30, September 23, 2025 (EDT)

HUH?! Wait, if the usage of columns wasn't even the point of the current standard in your example, then what IS the difference between it and your Rework A, then? They're BOTH bulleted lists that look IDENTICAL in portrait mode viewing!
Also, "I'm not saying we can't use columns at all, but in this case, why would we [use columns] when the Galaxy games use bulleted lists?" Huh? Are you saying to avoid using columns or not? Because to me it sounds like you're contradicting yourself? rend (talk) (edits) 19:55, September 24, 2025 (EDT)

I never said columns can't be used on the Mario Wiki in any capacity, this is only for lists of appearances on enemy articles. Nowhere else. The point was to make the templates for the same things consistent across an article. Also, I'm aware columns and bulleted lists are the same on mobile, but it's not the case for desktop which is how most people edit. I didn't expect such strong opposition to a minor proposal that would make things more consistent.  — 20:40, September 24, 2025 (EDT)

It's probably because the proposal itself is a bit confusing. Like yeah, I know already that this is specifically for lists of appearances on enemy articles, but that's not what I'm confused about. My confusion stems from why your Rework A is practically the same as what's already the current standard: a simple bulleted list. From what I can gather, Rework A is already the current standard, and as EvieMaybe already stated, that was already decided on through a previous proposal.
So in short, what I want to know is the following: Beyond the usage of columns (which apparently doesn't matter), What exactly is the difference between the current standard and your Rework A? I've asked this before but you still hadn't clarified that. And if there is no difference, then why is Rework A an additional option? rend (talk) (edits) 04:00, September 25, 2025 (EDT)

Old signatures

canceled by proposer
I have been noticing that some old users have signatures that violate the policies in Mariowiki:Signatures. However, these rules don't exist for nothing, and the signatures still contain problems, such as line breaks and distractions, despite the users being inactive, and because of that, we can't deliberately reach out to them, especially if they're banned. So, I propose that we modify rule-breaking signatures of inactive users, or outright replace them with {{user}}

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

Support

1. Colin's world 3 YT (talk) Per proposal. one time I actually tried warning users who hadn't been active for having sigs that were against the rules, but it backfired.

Oppose

1. Camwoodstock (talk) If someone's previous signature broke current rules, set before those rules were even in place, it makes absolutely no sense to punish them, especially since most of the examples we can think of would, by the nature of the signature rules (the last rewrite to the policy page that actually involved a substantial shift in rules was February 24th, 2024. the last time a full items on the list were shuffled enough to impact the number of rules was August 17th, 2011.), be several years old, and more than likely, over a decade old. It would be utter nonsense to actively warn a user for "doing something wrong", several years ago, when said thing they're "doing wrong" wasn't actually wrong at the time. If an old signature substantially breaks something on a modern browser, it will be dealt with on a case-by-case basis. A policy change like this, at best, is needless busywork for staff to sift through, and at worst, is unrelentingly punishing to veteran users for literally no benefit whatsoever.
2. Salmancer (talk) Per Camwoodstock
3. Arend (talk) Per Camwoodstock; this is like if we decided to automatically overturn thousand of our old proposals, PURELY because the way they've been settled do not match with our current standards. Also, I feel like this proposal purely exists because of what the proposer said in his support vote, about warning users for their sigs when they've been inactive for years, as if he decided to create this rule to avoid the embarrassment, when he could just look at... the timestamps of when those comments were made, and/or the user's list of contributions to see if they're still active?
4. Rykitu (talk) Per all.
5. Nelsonic (talk) Per all.
6. Altendo (talk) "If it's ancient history, don't bring it up again. The user has moved on, and so should you. While a user's record should not be forgotten, how they act now is more important than what they were like a few years ago, and focusing on problems they have since outgrown does no one any good."
7. Dominoes (talk) Per all. I don't think that such a hostile action needs to be taken.
8. YoYo (talk) 🤦 per all
9. 1468z (talk) Per all.
10. Hewer (talk) No need to waste time telling off inactive users.
11. DryBonesBandit (talk) How does this benefit the wiki…? Per all.

Comments

@Colin's world 3 YT Please don't forget to add the deadline to your proposal, as well as to add a # in front of your support vote to start a numbered list, as per the required formatting for basic proposals. This isn't the first time I had to add these in post. rend (talk) (edits) 20:08, September 24, 2025 (EDT)

Lets talk about LINE

Do nothing 1-4-1
So currently, if you go to a character gallery, you will see line stickers related to a game in the game installments area. However, as this is not technically accurate, I think they should be moved over to the misc. section.

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

Support (line ain't Yoshi's Wooly World)

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

Oppose (line is Yoshi's Wooly World)

1. Altendo (talk) These artworks are still official artworks for specific game installments. I wouldn't be opposed to making a new "LINE" section in gallery pages, but because these artworks are meant for specific game installments, I wouldn't call them "miscellaneous".
2. Rykitu (talk) Per Altendo.
3. YoYo (talk) by this logic let's exclude every image that is not directly from the game it represents in said game's gallery: no more artwork, no more logos, no more renders, no more promotional material, only sprites and models from the game
4. 1468z (talk) Per all.

create new line sections in galleries

1. Altendo (talk) Second choice.

Comments

@Rykitu please remember to be civil and courteous when voicing opposition to a proposal, there's no place for a remark like this in our pages. Xiahou Ba^{(the Nasty Warrior)} 21:13, September 16, 2025 (EDT)

Sorry. I was having a bad day and I guess this wasn't the best way to cope. Rykitu

Does this need to be a proposal? Seems like a simple enough thing that you can just be BOLD and do it... Shadow2 (talk) 22:46, September 16, 2025 (EDT)

If there's disagreement (i.e. people are opposing), that probably means it should be a proposal. Hewer (talk · contributions · edit count) 05:36, September 17, 2025 (EDT)

@YoYo line could be considered a separate installment from the game its stickers are based on. Conkdor! (T|C)

A rule on the use of straight and curly quotation marks

Use straight quotation marks 11-1-0
This came to my attention when I realized there were no rules at all regarding whether straight quotation marks "..." should be used over curly quotation marks “...” (there were none either on apostrophes until this proposal came to be) when I thought it's there all along, which I then gave it more thought when I also realized the English Wikipedia's Manual of Style has a rule on this (same argument is brought up by the aforementioned proposal). I'm pretty sure everyone is using straight quotation marks on MarioWiki, as it's easier to type, so I don't think I need to explain this further so far as usage in English is concerned.

What is probably more divisive would be the use of curly quotation marks for other languages that are exactly in this form “...”, i.e. the same form as the curly quotations used in English (Other forms like German „...“, Hungarian „...” and guillemets «...» are different, and they are out of the focus of this discussion), for the purpose of citing materials of other languages (example). This style of quotation marks is the preferred form in some languages and, in some cases, is even prescribed by the government (e.g. simplified Chinese, Korean). Upon consulting others regarding this topic, this is what I can conclude: On one hand, one may argue that we should keep curly quotations for these cases because it respects the languages' features more, and in some cases, curly quotation marks are what many people using the language use. On the other hand, it may also be argued that the rule to use curly over straight quotations is not that deeply enforced to make a difference, and that given this is an English wiki, we may apply a similar logic on quotation marks in English to identical quotation marks in other languages prescribing "European" quotation marks.

Hence, I would give the following options: Mandate the use of "..." over “...” in English and other languages, mandate the use of "..." over “...” in English only while mandating “...” in other languages that use it, or keep the status quo of not defining a rule and leaving it up to the editor's discretion.

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

Mandate the use of "..." over “...” in English and other languages

1. "Dominoes" (talk) Per proposal, option 1. As said above, I thought there was a rule on this all along.
2. "Altendo" (talk) I prefer straight quotation marks. That is what my computer does, so I prefer it this way. However, I am unsure how this will affect other systems with quotation marks. I might change my vote if I find other devices with different quotation marks.
3. Maw-Ray Master (talk) Per all.
4. The Dab Master (talk) Per proposal.
5. LadySophie17 (talk) Per proposal. straight quotation marks are already largely the standard across the wiki, this is mostly a formality.
6. Camwoodstock (talk) This is basically already an unspoken agreement for the actual article's text, and to be frank, unless there's some odd Play Nintendo Video that uses curly brackets instead of normal ones in its title, we can't even really imagine this having any further unforeseen consequences--and even then, on the off-chance a curly bracket managed to smuggle its way into a page title, that's a job for Template:Title.
7. EvieMaybe (talk) per all. curly vs straight quotation marks are basically an Unicode artifact.
8. "Colin" (talk) Per all.
9. 1468z (talk) Per all.
10. Arend (talk) Per'all.
11. Pseudo (talk) Absolutely something I already presumed to be the standard.

Mandate "..." for English, mandate “...” for other languages that use it

1. « Dominos » (talk) Per proposal, option 2.

Remove Fairy Fountain images

Remove 8-0
This is pretty straightforward. There are two files, File:NM TLOZALinktothePast Player Select.png and File:NM TLOZALinktothePast Fairy Fountain.png, which exist solely because we used to cover appearances of the "Fairy Fountain" motif from The Legend of Zelda under the pretense that it was based on World 3 Map (Water Land).

It's not.

And so now, these two image files have been left to rot. The odds of these ever being relevant to Mario-related affairs are slim to none, and on the off-chance they are important in the future, re-uploading them is trivial. For now, though, it'd be nice to not have them clog up the Unused Files list when the odds of them being used is... slim-to-none, frankly.

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

Support/Delete (turn off the faucet!)

1. Camwoodstock (talk) Per proposal.
2. Arend (talk) Per Camwoodstock (btw I'm quite baffled that these images weren't deleted (or tagged for deletion) sooner, or even immediately, given they've been uploaded on March 4, 2025, nine months AFTER it was decided to cull the Fairy Fountain appearances)
3. Altendo (talk) Per.
4. The Dab Master (talk) Per proposal.
5. Dominoes (talk) I don't see why not if they no longer serve a purpose.
6. Colin's world 3 YT (talk) heck yeah (BTW I don't think this requires a proposal; you could just delete them)
7. Power Flotzo (talk) Per proposal (does this even need one?).
8. 1468z (talk) Per proposal.

Comments ([some kind of peter pan reference])

I feel like this is a rule 20 violation. Deleting two unused images should not need a proposal, especially not when it's this much of a no-brainer. I fully expected them to be deleted after my proposal a couple months back (my bad for not tagging them at the time), hence why I tagged the third one as a personal image. Hewer (talk · contributions · edit count) 14:03, September 25, 2025 (EDT)

Admittedly, making this a proposal was kind of a sanity check, just to make sure we weren't missing any obvious use-case, since we aren't familiar enough with the Zelda franchise to know if we were missing something. ;P ~Camwoodstock ( talk ☯ contribs ) 16:10, September 25, 2025 (EDT)

I think looking at the file usage of the images would've been a better sanity check than starting a full-on proposal. Conkdor! (T|C) 19:53, September 29, 2025 (EDT)

...We can't use "What links here" to determine if there's some Fairy Fountain reference in the Mario franchise we're missing out on? ~Camwoodstock ( talk ☯ contribs ) 20:36, September 29, 2025 (EDT)

I find it's usually better to ask on a talk page or in the Discord if there's a small thing like this that you're unsure about, rather than jumping straight into a proposal. Then if it turns out to be completely uncontroversial (like this), you can just go ahead with the change. Hewer (talk · contributions · edit count) 06:03, September 30, 2025 (EDT)

Add an interwiki link to some Final Fantasy wiki

failed to reach consensus 8-0-6
This is my first time making a Proposal here so apologies if this is a little wonky or in the wrong section. Currently the Mario franchise has two games that have notable content from the Final Fantasy series; Mario Hoops 3-on-3 and Mario Sports Mix, including several characters from them; most notably Black Mage, White Mage, Ninja, Cactuar and Moogle. You may notice that every link related to Final Fantasy in those and other pages either links to the Fandom Final Fantasy wiki using the fandom template or instead links to some Wikipedia page. This also happens regarding Smash stuff like Sephiroth and his stage.

The thing is that there exist an independent Final Fantast wiki which we could say is indirectly linked to this wiki. That wiki is part of SEIWA which in turn is affiliated with NIWA to which SMW is a part of. And, in the interwiki links listing for this wiki that wiki is not covered. However that wiki is also affiliated with the Gaming Wiki Network which you may or not like.

That is notable because, for other two Square Enix franchises, there is an interwiki link here. There is one for the Kingdom Hearts wiki which is also a part of SEIWA, used in stuff like Sora and his stage, although that wiki is part of NIWA too. And for some reason there is one for the Dragon Quest wiki which is not allied with anyone (it is not part of SEIWA and its main page doesn't list any affiliate), used in stuff like Slime, and the other two Square Enix Mario spinoffs, Itadaki Street DS and Fortune Street.

You might as well be like me and recoil when you see a Fandom link, even more knowing that an indie alternative exists, and even more if it is an (indirect) affiliate, so part of this proposal is for there to be an interwiki link to them. However, there may be arguments to instead keep linking the Fandom wiki. For one I don't really know the status of the indie one; I don't know if it is a fork of the Fandom one, if it came to exist independently, and if so if it is "better" in content or support than the other one. I do know however that that wiki seems to be relatively new, which may explain why SMW here is not linking to it at all; at the time that those pages were written, that wiki didn't exist. Something that is notable to me is that, also for some reason, the Kingdom Hearts wiki in its interwiki listing currently has both a link to the Fandom and indie-affiliate wikis.

So, my point: I think that those links in the Final Fantasy related pages should properly link to a wiki, just like the Dragon Quest and Kingdom Hearts content do, but I am not sure in what way we should do that. We have these options:

• Add an interwiki link to the indie SEIWA one. Because it is an indie wiki and, as it is part of SEIWA which is affiliated with NIWA, you could say it is already indirectly affiliated with this wiki. That would also put it on part with how Kingdom Hearts content is linked here in a sense.
• Add an interwiki link to the Fandom one. This is ironic given the existence of the fandom template, but my point here is that this would set in stone for the foreseeable future that that wiki is the one that should be linked for FF content and not the indie one. Above you can see the Kingdom Hearts wiki has an interwiki link to the Fandom one too, so this option would do something like that. This is just to continue what is already being done but more formally and also replacing the Wikipedia links.
• Do nothing. Because everything may as well be fine as it is, and you could say that there is no reason to change it. The indie SEIWA wiki, by itself, isn't really affiliated to SMW. The Fandom wiki may possibly be better in content, and it has already been linked here for a good while, so it has legacy. You may prefer leaving that as the preferred wiki here, and with it not really think that an interwiki link is needed if the fandom template does the job. We could just leave stuff as it is, or also go and replace all the Wikipedia links to it.

To clarify, my point with this proposal is to ask two questions. One of them is which FF wiki should be linked here and the other being if an interwiki link should be created for the preferred wiki. It just so happens that, if the indie SEIWA wiki is chosen, that would also imply creating an interwiki link for it, but not necessarily if the Fandom one is chosen. I am clarifying this to make it clear to you that, with whatever you vote, you are also saying if you prefer linking the Fandom one, or the indie one. So, which one is it?

Proposer: ARCBXY (talk)
Deadline: September 12, 2025, 23:59 GMT Extended to September 19, 2025, 23:59 GMT Extended to September 26, 2025, 23:59 GMT Extended to October 3, 2025, 23:59 GMT

Link the indie SEIWA wiki: create an interwiki link to it and replace the Fandom and Wikipedia links

1. ARCBXY (talk) Me trying to do this in the album article, checking the interwiki prefix, and then realizing that there was none, is what pushed me to do this proposal. However, I don't know this community; I don't know if there is some obscure reason that the Fandom wiki is preferred and it turns out that everyone secretly loves it or something. So I might change my stance if someone brings up some important fact that I didn't know about. Give me your opinions!
2. Bro3256 (talk) Per proposal.
3. The Eggo55 (talk) Per proposal. I don't see any reason not to be able to link to the independent wiki, especially over a Fandom one.
4. Rykitu (talk) I refuse to support a Fandom wiki.
5. Colin's world 3 YT (talk) Fandom's fine, but only if there isn't any independent wiki equivalent.
6. LinkTheLefty (talk) I don't see why not. This proposal is just for establishing the interwiki link. We have interwiki links such as sonicretro that are often behind the fandom option, yet we'll still use the former when available. Content gaps can be resolved through the use of external links. (Too late to add it now, but maybe consider the Chrono Wiki while we're at it since it comes up sometimes.)
7. Nintendo101 (talk) per LinkTheLefty.
8. Altendo (talk) Per LTL.

#GuntherBayBeee (talk) Per all.

Do nothing: leave stuff as it is, maybe replacing the Wikipedia links or even leaving them too

1. SeanWheeler (talk) The Fandom Wiki is the better wiki to link to, but a link template isn't necessary when we already have {{Fandom}}.
2. SGoW (talk) Per Sean and the last proposal about this.
3. Power Flotzo (talk) Per the previous proposal.
4. Okapii (talk) the independent wiki doesn't seem to have improved much since the last proposal (still full of red links and stub pages), so unfortunately Fandom is still the better option.
5. PanchamBro (talk) I don't support Fandom, but I think the indie wiki is not a suitable replacement, especially when the article on its latest game is still a stub article, and activity on the wiki is still severely lacking. On the contrary, it shouldn't be a hassle to support an independent wiki through whatever means necessary, but I think that is a discussion for another day, and as it stands interwiki links to a wiki that isn't fully up to speed is not something I want to support, nor would it be for the wiki's benefits. imo I think it would be fine to just go with the Zelda wikis conundrum where multiple wikis are external links for now.
6. Sargent Deez (talk) Per Sean and the last proposal about this.

Comments (which wiki is preferred and why?)

The reason we don't link to the independent wiki is because this previous proposal about it failed (in future, I would recommend checking the proposal archives before starting a proposal so you can see if it has been attempted before and address any previous arguments against it). As for why we link to the independent Dragon Quest Wiki, I believe that's because it used to be a member of NIWA and SEIWA before being removed from both. Hewer (talk · contributions · edit count) 07:23, August 29, 2025 (EDT)

Oh I wasn't aware that said proposal happened. I jumped at making this one because I brought up this topic in the Discord and I was recommended to make a proposal about this, and the previous one wasn't pointed out to me, though still my bad for not checking. It may be that generally most users here aren't fully aware that that was settled? Still, I hold the notion that sometimes linking to Wikipedia instead of constantly the Fandom one is weird, but I guess that if one were to change all Wikipedia links no one would mind. And this proposal could be hold up if there was a big interest in making an interwiki link for the Fandom one, but again that may be unnecessary. If there isn't really any big sentiment about making some sort of decision here, and the general consensus is that everything should still be as it is, like that past proposal settled, then I guess this one could be cancelled. I will still keep it up for a little while more though, in case someone brings up something notable. - ARCBXY (talk) 17:13, August 29, 2025 (EDT)

A prior proposal can actually be overturned by another proposal if it has been more than 28 days after said prior proposal has ended, so a previous proposal's outcome is not eternal. We've had tons of succeeded and failed proposals in the past which outcome is no longer enforced due to other proposals' outcomes. If the SEIWA Final Fantasy Wiki has improved a lot since the last time a proposal brought it up, then it could be worth revisiting the subject.
Regarding to add an interwiki link for the Fandom-hosted wiki, however... that is not necessary at all. The {{fandom}} template already lets people link easily to any Fandom wiki they want. rend (talk) (edits) 18:46, August 30, 2025 (EDT)

Not sure how to feel about the whole "and also never talk about the indie one again" thing, as, nevermind how unenforcable "don't discuss the independent Final Fantasy wiki" is as a rule, considering that it's not like the independent Final Fantasy wiki is just, destined to always be behind the Fandom one. If it caught back up, it'd presumably be fine to discuss it again. It feels a lot like loaded language. ~Camwoodstock ( talk ☯ contribs ) 19:38, September 1, 2025 (EDT)

Yes when I wrote that I did it with the intention of "setting in stone" the decision. At the time I wasn't aware that there was a previous proposal about the same topic, that a proposal can be overturned by another one after at least 28 days, and that this proposal itself is already doing that to the previous one. I agree that, if the Fandom one is decided but the independent one can be preferred later, it can be changed. I'll remove that now, it doesn't really apply. The heart of the proposal stays the same though. - ARCBXY (talk) 20:32, September 1, 2025 (EDT)

Gourmandise

Create page for Gourmandise 9-0
I was looking over the iOS article, and it got me thinking. Are there any official Mario phone accessories? I dug around on Google and found Gourmandise (I have no ides who they are either) who sold Super Mario Bros 3-themed phone cases at Nintendo Tokyo. They also released a Super Mario Bros-themed phone cover, but I'm not sure where it was sold. Both these products seem to be discontinued, as they're not on Gourmandise's website.

My question? Should we make an article for Gourmandise, or put this information on the iOS article? I can't find any details on the products past these two listings, which I've archived, as I plan to get them a home on the Wiki, regardless.

Proposer: Sargent Deez (talk)
Deadline: October 11, 2025, 23:59 GMT Closed early on October 4, 2025, 23:59 GMT

Support (Gourmandise is an article nominee)

1. Sargent Deez (talk) Per proposal.
2. 1468z (talk) iOS is an operating system, gourmandise is a phone accessory company. Also gourmandise's phone covers and accessories in particular appear to be compatible with not just iPhones judging from descriptions and listings.
3. Camwoodstock (talk) Even if the phone cases were somehow made only for iPhones, a merge to ;iOS wouldn't make sense, as iOS is. the iPhone's Operating System. You can't put a physical case on something digital, and Gourmandise also didn't make iOS by any stretch of the imagination. Giving them their own page is in-line with how we handle these companies for other pieces of merchandise, like San-ei Co., Ltd. or Sunshine Biscuits.
4. Rykitu (talk) Per Camwoodstock. We give the companies seperate articles from their creations.
5. The new, official, Colin-branded screen protecter! (talk) Per Cam.
6. EvieMaybe (talk) per all.
7. AltendOS (talk) Per.
8. DominOS (talk) Per all.
9. stacheOS (talk) iOS article is more specifically about the operating system as well stuff released for it, and less about the devices running it.

Thai romanization

Use Paiboon 1-9-0-0-0-0
To decide on which romanization system to be used for Thai, since Thai support for Donkey Kong Bananza will lead to an upsurge in Thai NiOL. So, you know the drill.

Problem is, there's not really a "great" Thai romanization system out there. Each one has its own problems and quirks, and because of this, Thai speakers often encourage skipping the Latin-script conversion and just learn the native script. But this is a wiki, and we have to include romanizations, so we have to pick our poison.

The Royal Thai General System of Transcription (RTGS transcription)

The "official" method of rendering Thai language in Latin script, used in road signs and governmental papers. It has the most reach (and is thus used in other sites such as Bulbapedia), but has also recieved a lot of criticisms, as it completely omits tones (Thai is a tonal language, so tones should ideally be reflected) and the distinction of vowel openness and length (short and long, as well as open and close vowels, contrast with their counterparts), and also has inconsistencies in spelling even from the government itself. In other words, it's not really helpful for learning as it does not convey pronunciation unambiguously (similar case as the romanization system the Hong Kong government similarly uses for place and person names, which I talked about in my Cantonese proposal).

You may observe in the examples below that the spelling is largely similar to the International Phonetic Alphabet (IPA) transcription, but with all the details trimmed out. But these details are important, and should ideally be kept for a functioning romanization.

Paiboon romanization

One alternative way of romanizing Thai script, which is used by Paiboon for their own dictionary. It seems to have a decent reach among other romanization systems, and Wiktionary uses it for citation of Thai words in running text (example). It does not have the problem of ambiguity and reflects Thai phonology quite well, but uses IPA symbols combined with diacritics which are difficult to type without an external website or specialized wiki template. It should also be noted that the IPA symbols used for vowels are not exactly how they are represented in IPA, but are chosen due to higher similarity with the familiar Latin vowel letters (e.g. IPA /ɤ/ = Paiboon ə), as well as a "less messy" spelling orthography (e.g. IPA /ɯː/ = Paiboon ʉʉ instead of ɯɯ).

Wiktionary gives the details on how Paiboon differs with the RTGS transcription on this page.

ISO 11940

A lossless and reversible transliteration of Thai script into Latin script, where each Thai letter and diacritic is given a unique equivalent using the Latin alphabet and diacritic regardless of its function. The extensive use of stacking diacritics makes it even more difficult to type. Seems to have some degree of academic usage, but in public is pretty much never seen outside of Google Translate - it represents the script but not the phonology, so it is difficult to sometimes decipher what the sequence of letters is supposed to be pronounced (even more so considering that Thai script is an abugida).

Example	กรุงเทพมหานคร	ไหมใหม่ไหม้มั้ย	ดองกี้คอง บานันซ่า	เดอะ ซูเปอร์มาริโอบราเธอร์ส มูฟวี่
IPA	/krūŋ tʰêːp̚ má.hǎː ná.kʰɔ̄ːn/	/mǎj màj mâj máj/	/dɔ̄ːŋ.kîː kʰɔ̄ːŋ bāː.nān.sâː/	/dɤ̀ʔ sūː.pɤ̂ː māː.rí.ʔōː brāː.tʰɤ̂ːs mūː.fwîː/
RTGS	Krung Thep Maha Nakhon	Mai mai mai mai	Dongki Khong Banansa	Doe Supoe Mari'o Brathoes Mufwi
Paiboon	Grung Têep Máhǎa Nákɔɔn	Mǎi mài mâi mái	Dɔɔnggîi Kɔɔng Baanansâa	Də̀ Suubpə̂ə Maarí'oo Braatə̂əs Muufwîi
ISO 11940	Krung Theph Mh̄ā Nkhr	H̄ịm h̄ım̀ h̄ịm̂ mậy	Dxngkī̂ Khxng Bānạns̀ā	Dexa Sūpexr̒ Mārixo Brāṭhexr̒s̄ Mūfwī̀

For more clarity, compound words are grouped together without spaces or hyphens, while vowels in the middle of a compound word starting with a silent initial "อ" are marked with an apostrophe ⟨'⟩.

There should be more romanization systems that are less known, which I'm even less familiar with as a non-Thai speaker. If there are any that would be feasible, feel free to mention them in the comments section.

Proposer: Dominoes (talk)
Deadline: October 14, 2025, 23:59 GMT Closed early on October 7, 2025, 23:59 GMT

Use the RTGS transcription system

1. Shadow2 (talk) My response here is the same as all the previous romanization proposals. The main purpose of a romanization system should be to allow a majority of unfamiliar readers to be able to approximate as closely as possible to how the words are spoken. They need to be approachable and understandable to the layman. The layman will not be able to make any sense of "tʰêːp̚", "Nákɔɔn" or "Nkhr", so they would be functionally useless to the majority of readers. A minor amount of inaccuracy is acceptable if the text is readable and understandable.

Use the Paiboon romanization system

1. โดมิโน (Dominoes) (talk) Like I said above, this one has the problem of being a pain to type, but I think it does the job the best at reflecting the phonology intuitively to readers who aren't accustomed to the language. I don't think it would be that difficult for a reader to look at ⟨ʉ⟩ and think "that's a vowel similar to a 'u' but is different", and likewise with ⟨ɛ⟩ ⟨ə⟩ ⟨ɔ⟩.
2. Reese Rivers (talk) Being a useful romanisation system seems like more of a benefit than being easy to type, so this seems to me the preferable option.
3. Jdtendo (talk) It's the system that best transcribes Thai pronunciation.
4. EvieMaybe (talk) for our wiki's purposes, this seems the most reasonable. it's not like we're going to typing that much Thai text, so being "hard to type" isn't that big an issue.
5. อัลเทนโด (Altendo) Per EvieMaybe.
6. ริกิตู (talk) ต่อทั้งหมด!
7. ปรมาจารย์ปลาไหลมอเรย์ (talk) Per all. This system most accurately represents Thai phonology.
8. ณ หนวด (talk)คิดว่าน่าจะเป็นตัวเลือกที่ดีที่สุดนะ เพราะสามารถแยกเสียงวรรณยุกต์และเสียงสระสั้น-ยาวได้ แต่พิมพ์ได้ไม่ยากจนเกินไป
9. 1468z (talk) Per all.

Comments and suggestions

Would it be possible for two systems (with RTGS and Paiboon as my preferences) to be used at the same time? Or is it preferred to have only one standard?
— Stache (talk) 00:37, October 2, 2025 (EDT)

If there is a template that automatically converts romanization from Paiboon to RTGS (like how Wiktionary does it), it would be nice; otherwise, it would be a mess to manage, and I doubt we could put the effort into making a specialized module-driven template just for this anyways. In addition, we have always stuck to the policy of "one romanization per language variety" (hence the Jyutping-Yale decision from my Cantonese proposal), so it's better to make a choice. Dominoes (talk) 01:29, October 2, 2025 (EDT)

That would likely require a complex module implementation, which I'm not opposed to but wouldn't be ideal to others, so I guess I'll go with one system.
— Stache (talk) 03:23, October 2, 2025 (EDT)

@Dominoes I can tell you right now that I was looking at this and I had no idea what "ɔ" was supposed to be...and I even already knew what the Thai text was saying. I think it's disingenuous to say that "most readers will figure these out on their own"... How is your average reader, someone who doesn't speak Thai, supposed to know what ə means, how it's different from ə̂, and how THAT's different from ə̀? People who only speak English generally don't have a preexisting notion as to what accents mean, even though they often share a meaning across languages. I must disagree with the notion that this method is "intuitive" and counter that the system that solely uses plain Latin characters is much more intuitive to the average reader. Shadow2 (talk) 07:17, October 7, 2025 (EDT)

This is also why at the start I mentioned "there is not a 'great' romanization system". The constraints within the language that makes it difficult to transpose crucial features of the language to Latin. However, to me, the difficulty of transposing such features does not mean that we should omit them, but to find solutions.

For the problem of vowels, one could represent the 4 "weird" vowels as digraphs, at the compromise of either messing with diphthongs and excluding vowel lengths (e.g. แ◌ว /ɛːo/ = aeo despite the long vowel), or just resulting in visual clutter (aeaeo). Then that leaves symbol extension as the "less bad" option (ɛɛo). As for what ⟨ɔ⟩ means, it may be difficult to imagine the meaning when isolated out of context, but in practice, the character being positioned as the vowel makes it more easily understood that it is supposed to be... a vowel, and its closeness to ⟨o⟩ means that it's something similar but not exactly the same. RTGS transcribes both vowels /ɔ/ /o/, as well as their long counterparts /ɔː/ /oː/, as o - that's four contrasting vowels with different pronunciations represented by the same thing, which never occurs in romanization systems for other languages such as Hepburn, Hanyu Pinyin, and Revised Romanization.

As for accents, it has been well-established that romanizations we use for other tonal languages use accents for tones (in fact, a romanization using accents to represent tones was favored last time over another one using numbers instead, because that's "more intuitive"). I do not think it would be that much work to infer that here they would also represent tones of some sort, and how different accents mean different tones. The more interested would then go to search further about Thai language to learn what they truly mean, while for the average that are not curious, it just exists and do not interfere with reading - ⟨ə̂⟩ and ⟨ə̀⟩ would then be understood to be different tones for a vowel similar to ⟨e⟩, and that's already better than to pretend they are all the same thing. In fact, when we look back on the ⟨ɔ⟩ / ⟨o⟩ example from the previous paragraph, if we take account for the five tones for each vowel, that's twenty distinct vowels treated as the same thing. Keep in mind that the same problem occurs for every set of short/long vowels and diphthongs, and vowels alone comprise a significant portion of the romanization script. To dismiss this as merely a minor inaccuracy would be at best an understatement, and at worst, ignorance.

The purpose of having a romanization system be included is to let average readers be able to "read" while reflecting all necessary features of the language (a case in point is List of Mario names in other languages, in which a previous revision failed to address how the addition of a tone mark is reflected in pronunciation). They also help as a stepping stone for curious readers to learn the language, and for an ineffective system, it would hamper their ability to learn as they progress, having to somehow work through how the language is not reflected as it is in the romanization script. Even if extended IPA symbols are not the "most intuitive" solution to everyone, they exist to counter the shortcomings that would otherwise make it inefficient. Withholding information can maybe make it more "easily accessible", but cutting that much also defeats the point of including a romanization in the first place. Keep in mind that that is also why Thai speakers advocate against using romanization for learning, because the most common one is RTGS. For me, I would rather have a system with a slightly steeper learning curve than one that does not give sufficient information to help - all romanization systems needed to be learned in the first place anyways, and it is the first step that is important. Dominoes (talk) 08:30, October 7, 2025 (EDT)

The question you need to ask is, "Do we want our average readers to need to do work/research in order to understand the romanization?" A reader can work to try and figure out what ɔ or ɛ means, or they may be required to look it up...Or they can see an "O" or an "E", know already what that letter means, and get a very close, albeit not perfect representation of what sound is being made. This is my issue with striving for "perfection" when it comes to representing the language...Do we want perfection, or accessibility? If you use funky symbols, then you lose accessibility because the average reader won't know what they are and will need to make an extra effort to learn what they mean. Or they can just use the "O" sound. Is it a perfect representation of what's being said in Thai? No, it's not, but it's close enough for them to get a basic understanding. Remember, we're not teaching a class on the Thai language, we're just helping average, uninformed readers to understand what something says.

"It just exists and do not interfere with reading" is, I feel, another disingenuous statement. If they don't know what it means and have to do searching or research to figure it out, then yes it will interfere with reading. It's the same thing with the numbers in that Cantonese romanization system we opted not to use.

"They also help as a stepping stone for curious readers to learn the language" is another statement I disagree with. This is the Mario wiki, not "Learn Thai 101". Readers are not coming here to learn Thai, they're here to learn about Mario. If someone does want to learn Thai, then they can use the provided raw Thai text and convert it to whatever other romanization system they want to use to learn the language. "all romanization systems needed to be learned in the first place anyways", no they don't, not if they use basic Latin letters, as I was saying. Readers will not have to learn RTGS because they can view it with their eyes and read it fine without external help.

We already elected to use the romanization system for Russian that translates "Пич" into "Pich" instead of "Pič" for the very reasons I outlined. I don't see why it should be a different, more complex system, for Thai. Shadow2 (talk)

Replace images in Mario Discovery character infoboxes

Do not replace images 1-11
The Mario Discovery Series contains some characters that exist in real life, such as Charles Dickens. Right now, we have low-res screenshots of the people from the actual games. However, I find the infobox images low quality and have more than just the person, but also Luigi and tables and other stuff. That's why I propose that we instead put paintings or photographs of the people, probably lifted from Wikipedia. Note that when I say "Low quality" or "Low res", I don't mean they should be marked with {{Image-quality}}, I just mean paintings or photos would be better.

Proposer: Colin's world 3 YT (talk)
Deadline: October 14, 2025, 23:59 GMT Closed early on October 7, 2025, 23:59 GMT

Support

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

Oppose

1. Nelsonic (talk) The screenshots currently used are the only way that these people - for the most part, minus a select few that have appeared elsewhere - have appeared in official Super Mario media. Using the paintings would be using material that represents the people, but not specifically their game appearances.
2. Rykitu (talk) Per Nelsonic.
3. Ahemtoday (talk) Per Nelsonic.
4. Hewer (talk) No reason to use an image that doesn't pertain to the Super Mario franchise over one that does. It's the same reason crossover characters such as Link are only allowed to use artwork from the relevant crossover appearances and not their original franchises.
5. DryBonesBandit (talk) Said images from Wikipedia don’t pertain to the Mario franchise. Per all.
6. Camwoodstock (talk) Per Nelsonic. For whatever it's worth, with what little toes we've dipped into the Library executable from Mario's Time Machine Deluxe, there are some actual portraits or photographs of some stuff that appear... But even then, those are technically from paratext, and would go in the gallery anyways. And also, like heck we're touching that thing anytime soon, we're saving that for a rainy day. (note: "we're" as in, us a system, obviously if someone else on-wiki gets to it before us, we wouldn't mind)
7. YoYo (talk) per Nelsonic.
8. EvieMaybe (talk) per all
9. Arend (talk) I don't think historical figures should be treated the same way as Nintendo staffmembers and spokespeople. The historical figures appear directly within a Mario title, but are NOT directly involved with the development of a Mario title. So, in essence, we should treat them as character in a video game or TV series, meaning we also should use images that pertain closest to the Mario franchise... like with any other character that appears in the franchise.
10. Polley001 (talk) Per Nelsonic, and the old adage about history inevitably repeating itself.
11. Altendo (talk) These Wikipedia images aren't used in any kind of Mario or Mario-affiliated media.

Determining music terminology

Adopt as specified 8-0
This is originally part of a proposal by Evie, which seeks to overhaul the music coverage in this wiki as well as redefining music terminology used to describe elements of music. I have more ideas regarding the latter that it is split into this proposal, so this is to determine the music terminology that we use for our music coverage.

As a musician, I have noticed that our music terminologies used in articles is not consistent. For example, in the sound test pages, the entries in a game's soundtrack are named "songs", while elsewhere it's a "track" instead. The usage of "song" for this is also arguable - I have no problem with calling any musical work a "song" in daily speech, because that's just how language works; rather, it's important to note that this is an encyclopedia where our wording should be professional, and using "song" in such a context makes the article feel less credible. ("Song" for instrumental tracks is also avoided in recent Mario games as well. For example, the website for SMG1+2 uses the term "tracks".) In addition, sometimes "motif" is used in place of "leitmotif" when they are not exactly the same thing, while sometimes a use of a leitmotif is instead written as if the incorporation of elements in an otherwise original piece is equal to the arrangement of the entire theme.

Hence, I would like to propose this set of terminology which we would use to describe elements of music.

Terminology	Examples
Musical theme (or theme) A complete, large musical idea that may or may not recur as a whole in several musical works. "Theme" is synonymous, but "musical theme" prevents confusion with the usage of "theme" in other contexts, thus is preferred unless the context is unambiguous (see comments below). Motif A characteristic, short musical fragment that can reoccur or be expanded within a theme. See Wikipedia definition. Leitmotif A distinctive motif associated with a person, place, or other non-musical ideas that reoccurs in several related themes to evoke the idea. See Wikipedia definition.	"Wild Woods" is a musical theme. "Overworld Theme" from New Super Mario Bros. is a recurring musical theme. The theme features a motif of a scalar walk upwards (initially in the form 3̂-4̂-5̂-6̂), which is repeated throughout the theme. "An Awfully Long Time Ago..." introduces a leitmotif that features a perfect 5th leap upwards. The leitmotif appears in other themes such as "Koops" and "Vivian."
Piece A musical work created for any purpose. Equivalent to "song" colloquially. Track A non-standalone musical piece that plays in a video game, movie, or other media. This sense is borrowed from "track" as in a recorded album entry. Use "track" over "piece" if applicable, especially in sound test or album pages. Song A piece that features lyrics to be sung, or a rhythm game track (where "song" is indeed the preferred term). Use "song" over "track" and "piece" if applicable.	"Le Galop infernal d'Orphée aux Enfers" is a piece. The Super Mario Bros., Super Mario World and Paper Mario: The Origami King renditions of "Invincibility BGM" are three tracks (also pieces) of the same theme. "Kong Bananza" and "Happy & Sappy" are songs (also tracks and pieces). "Yo-Ho, Bro!" and the Mario Day song are songs (also pieces, but not tracks). "Ms. Mowz's Song" from Dance Dance Revolution: Mario Mix is a song (also a track and a piece).
Composition A piece that establishes a musical theme. May or may not include leitmotifs that have already been established. Arrangement A new piece that uses an existing musical theme. Equivalent to "remix" colloquially. Remix A modification on a piece, such as by altering the pitch and by adding or re-recording certain parts. Same definition as discussed in the MarioWiki:Good writing article.	The Super Mario Bros., rendition of "Invincibility BGM" is a composition, while the Super Mario World and Paper Mario: The Origami King renditions are arrangements. The Mario Kart 8 rendition of "Donut Plains" is an arrangement on the theme from Super Mario Kart. The arrangement has 3 remixes that plays while frontrunning, during the final lap, and during the final lap while frontrunning.

Proposer: Dominoes (talk)
Deadline: October 9, 2025, 23:59 GMT

Support: Adopt as specified

1. Dominoes (talk) As proposer.
2. EvieMaybe (talk) seems very solid.
3. Hewer (talk) Per proposal, might as well have some more consistency. (Funny that you use Wild Woods as the first example, that theme's been stuck in my head all day.)
4. Nintendo101 (talk) great idea.
5. Scrooge200 (talk) As a pretty frequent music contributor, I agree with this. Always helps to be more accurate with our terminology. (Also, since reading "remix" vs. "arrangement" in the frequently misused terms section, improper use of "remix" has become a pet peeve.)
6. Polley001 (talk) Per this proposal's purpose's potential positive impact on properly presenting a piece's position in the musical spectrum (in other words, sounds good).
7. Altendo (talk) As someone who studies music in other forms of entertainment, I agree with this!
8. ThePowerPlayer (talk) Per all.

Comments

what would we call a piece that happens to arrange another, but partially? (see Starview Peak from MKWorld, which quotes the Observatory theme but the bulk of the song is original) — eviemaybe (talk / contributions) 14:14, September 25, 2025 (EDT)

If a melody fragment exists for the purpose of evoking one particular idea, I think it would be appropriate to analyze the usage of the melody as a leitmotif (then the "Rosalina in the Observatory" melody is incorporated in Starview Peak's theme as a "Rosalina" leitmotif). Dominoes (talk) 19:10, September 25, 2025 (EDT)

I don't agree with "theme" being used, it should be changed to "theme song" or "theme music", this can easily be confused with the nonmusical definition of theme such as "a dark theme" in relation to say, UI or such. Xiahou Ba^{(the Nasty Warrior)} 21:44, September 25, 2025 (EDT)

This is a very great point, I haven't thought of that. Though what I'm talking about is the abstract idea of a complete theme (where anything counts, whether big or small), rather than a specific instance of such a theme that is particularly important, so I think "musical theme" would be good for disambiguation. Dominoes (talk) 22:15, September 25, 2025 (EDT)

Stop using icon-based level names for Super Mario Bros. 3

Stop using icon level names 13-0
Where does the name "World 1-Airship" come from? "World One Dash Picture-of-an-Airship". After all, SMB3 doesn't directly state level IDs in a way that'd display like this, and the icons we're using are sometimes cobbled together, like which is an edit of the credits sprite to use the World 8 map color palette. Surely if these names are stated officially, they have official icons used in them, right? I asked this question a few days ago on the discord server. The answer? No one knows.

What!? I was actually so baffled by this possibility, but as far as we could find, across Nintendo Power guides for SMB3, SMAS, and SMA4, SMA4's save file select screen, even the Encyclopedia, None of them rendered any SMB3 levels with an icon. Just written names like "World 1-Fortress" and "World 2-Pyramid". So what are we doing here!?

The wiki has, for years, been rendering SMB3 level names with icons, seemingly just because the NSMB games do so, even though they released almost a decade after this game. In order to facilitate these arbitrary icon names, sprites from the world maps were plucked and tweaked to be forced into being level ID icons. Then the names were never considered conjectural, not even "World 5-Fortress 2" which has formatting based on absolutely nothing. Thus, no one questioned these names that seem to violently violate naming policy by being conjectural names that use images in them. I want to stop this.

Supporting this proposal would be to support removing all use of the Template:world and Template:World link templates in regards to Super Mario Bros. 3. A small handful of pages would also be moved to follow the names used in the Nintendo Power Super Mario All-Stars guide. Those being the duplicate Fortresses and Piranha Plants per world, which will use parenthetical (first) and (second) rather than the arbitrary extra numbers, and World 8-Bowser's Castle (Super Mario Bros. 3) being renamed to "World 8-The Castle of Koopa".

Proposer: PopitTart (talk)
Deadline: October 28, 2025, 23:59 GMT Closed early on October 21, 2025, 23:59 GMT

World Support-Remove Icons

1. PopitTart (talk) Per proposal.
2. Camwoodstock (talk) Per proposal. If the game (and its rereleases) doesn't use these icon names, why the heck should we?
3. SolemnStormcloud (talk) Per proposal.
4. World 4-🁾 (Dominoes) I don't see why not, if the icon names we've been using have never appeared in official sources.
5. World 7-Lakitu (talk) Per all.
6. World H- (talk) Per all.
7. Jdtendo (talk) Per-.
8. Arend (talk) Huh, looks like it's really only the e-Reader levels that use specific icons for their levels. Per all.
9. World A-10 (Altendo) Huh, always wondered why we did this. I always assumed that the icons were in the level names for every game, but it seems like that's only the case for the NSMB games.
10. Evie-Maybe (talk) per proposal
11. World -SSM (talk) per proposal
12. Martendo (talk) Per all.
13. World 3-🪿 (talk) per all.

World Comments

Would the passing of this proposal have deleterious impacts on older versions of these articles that do call these templates? - Nintendo101 (talk) 00:36, October 14, 2025 (EDT)

From what I can tell, I don't think it should. If you use the templates to call for an image that doesn't exist in the template, it simply displays the text instead, like so: World 1-Popit or World 5-Fortymcfortface 1. Once SMB3 is removed from the template, calls for its icons will just display like this. --PopitTart (talk) 00:43, October 14, 2025 (EDT)

Why specifically the Mario All-Stars guide for the new course names? Doesn't the original SMB3 guide and the SMA4 one provide the same information for those titles? rend (talk) (edits) 12:54, October 14, 2025 (EDT)

Technically yes, but I chose the All Stars guide because it explicitly displays the names as "World 1-Airship" with the dash and all. The original game's guide has the level name in a seperate box from the world number, which is a bit more ambiguous.--PopitTart (talk) 13:37, October 14, 2025 (EDT)

I think this is generally a good idea, but I do not like some of the suggested alternate names, in particular the suggestion to use "(first)" and "(second)" as identifiers. I don't think there's any precedent for using an ordinal number like that to distinguish between two subjects with the same name, and surely a more descriptive option exists, right? One idea that could work is to use the "subtitles" from the Nintendo Power guide for stages that have the same name, such as "World 5-Fortress (Three-Up Fortress)" and "World 5-Fortress (Hot Lava Fortress)". jan Misali (talk · contributions) 12:52, October 15, 2025 (EDT)

Per MarioWiki:Naming#Determining the identifier, this is one of the uncommon cases that falls under the final point in the list, where two subjects that appear in the same game and are the same type of thing have the same name. In these cases, we resort to custom identifiers the likes of (green), (bird), and (sandwich). So I don't think we have to worry about whether there's precedent for using numerical identifiers. I don't like the idea of using Nintendo Power subtitles as much because I think it does a worse job at clarifying what the article is about, which is the point of an identifier. Hewer (talk · contributions · edit count) 14:11, October 15, 2025 (EDT)

I don't see the issue? It's basically the same principle as, say, World 6-Tower, but now the number isn't part of the course's name. We're practically doing the same thing Nintendo did. rend (talk) (edits) 01:25, October 17, 2025 (EDT)

(Side note, why does the "2" in World 6-Tower need to be an image icon too? We don't do icons for every other world code, and not even the current way we enforce the SMB3 world codes.) rend (talk) (edits) 06:50, October 18, 2025 (EDT)