MarioWiki:Proposals/Archive/83

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

What is a Game? IV: A New Scope

As Eminem once said:

(Guess who's back... back again...)

Anyway, let's begin.

We've made a split page for physical games and given that variety of merchandise a location to be covered. However, there are still select varieties of merchandise that could qualify as physical games that currently aren't on the list. This proposal aims to add said games to the list, as most of them are divorced enough from the variety of games currently on the list that there could potentially be discourse on whether to add them or not. These game varieties will be listed below, followed by options on whether to add them or not.

LEGOs / BYGGIS / K'NEX / Dot-S

If this were to be added to the list, each set would be listed under a new section for three-dimensional puzzles (akin to the currently-listed Kumukumu Puzzle) under the section for jigsaw puzzles. These brands are technically puzzles, as the user has to put them together the same way they'd put together a jigsaw puzzle, just in a three-dimensional space. Each set article would presumably be akin to a jigsaw puzzle article (with slightly more content due to LEGO Super Mario's timer / scannable objects, K'NEX's motorized sets, and BYGGIS's cutouts). [On a separate note, I may make a proposal determining what content can be added to pre-existing jigsaw articles to improve their depth, such as - as another editor suggested - making graphics showing what kind of pieces appear in a given puzzle.) In short, I believe these three brands should be added, as they are each at least akin to a jigsaw puzzle, while LEGO Super Mario also features various scannable elements and a timer, and K'NEX features the aforementioned motorized sets.

As for Dot-S, I could honestly go either way on this one. The puzzles don't really have much in the way of names, unlike most of the other sets listed. I would still like these to be added to the list, though I'd understand if they can't warrant their own articles (and thus would be okay with the brand itself being added instead).

Playsets

If these were to be added to the list, they would most likely be put in the miscellaneous section (or a new section, depending on how many varieties of these there are). I believe these should be added to the list, as a playset is intended to bring the world of any given game to life in a physical sense, as each playset depicts either a real in-game location or a unique location fitting with in-game settings (such as underwater playsets, etcetera). A playset is meant to give the user the feeling that they are playing the game, and, while many playsets don't have a goal in that of themselves, this is due to playsets being intended for players to make their own rules. I believe these could comfortably warrant their own articles between the setting, the pieces, the setup, and other miscellaneous information.

Activity books

This one wouldn't change what is currently covered or result in additional articles (as activity books already all receive their own articles), though if these were to be added to the list, they would most likely be placed either in a new section that also includes the Twinkl activities, or in the miscellaneous section. Activity books usually feature various mazes and games, with some (such as The Super Mario Galaxy Movie Activity Kit) featuring full-blown games that the user has to physically print out and cut out to play. Because of this, I think activity books should be added to the list.

Art tools

If these were to be added to the list (depending on how many of them I can find), they would either be categorized under a new section or in the miscellaneous section. These tools include stuff like the Ravensburger-produced Mario-themed "Xoomy" (I believe that's how the toy's name is spelled) drawing toy, which is intended to aid users in learning to draw. I believe these should be added to the list, as - though most of these would comfortably warrant their own articles as merchandise as well - they could be categorized as the physical game answer to Mario Paint and the Mario Artist series.

Magic 8 Balls

These would probably go in the miscellaneous section, as there's most likely not that many of them. These could comfortably warrant their own article(s) once all of their individual answers have been found, as they're sort of like the physical game answer to the online browser games in the vein of Ask Wario or the Ask Dan-style message board-mail bag-things from the early 2000s. In short, I believe these should be considered physical games, as there is a level of interactivity to them, they have unique names, they can fill out their own articles, and they have video game parallels.

To note, some of these could be considered more on the "utility" side as opposed to the "game" side. However, as with the list of games, I believe that it'd be better to group the physical utilities with the physical games, as I don't think there's enough [known] distinct physical utilities to warrant a separate list.

Note: this proposal is sheerly intended to add these things to the list, and ensure that they will eventually get articles. I am not making writing the articles part of the proposal itself, as... well... then it probably wouldn't be implemented for a very long time due to the amount of these things.

Now let's-a vote!

Proposer: Nelsonic (talk)

(How) do we add LEGOs, BYGGIS, K'NEX, and Dot-S?

LEGO, BYGGIS, K'NEX, and Dot-S are not games 2-1-1-5
Deadline: April 25, 2026, 23:59 (UTC) Extended to May 2, 2026, 23:59 (UTC)

Add individually

1. Nelsonic (talk) Per proposal.
2. Rykitu (talk) I agree with adding the LEGO Super Mario sets, but only LEGO Mario as they made those sets act like a game. The other sets are just toys.

Add individually, but add Dot-S as a brand

1. Nelsonic (talk) Per proposal.

Add to the list, but only as brands

1. Camwoodstock (talk) We'd prefer each of them get listed with the brand in lieu of individual sets; there are many expansions to LEGO Super Mario that just, don't function as they're intended to unless you have the main LEGO Super Mario.

Don't add

1. Nintendo101 (talk) Per my comment below.
2. LadySophie17 (talk) Per Nintendo101.
3. Mario4Ever (talk) Per Nintendo101.
4. Jdtendo (talk) They're more like toys than games. I wouldn't consider them "three-dimensional puzzles" since the user has to follow instructions to assemble them, whereas the core gameplay of jigsaw puzzles is having to guess which piece goes where.
5. Okapii (talk) Per Jdtendo, these are toys; toys are merchandise.

Do we add playsets?

Playsets are not games 1-7
Deadline: April 25, 2026, 23:59 (UTC)

Yes

1. Nelsonic (talk) Per proposal.

No

1. Rykitu (talk) Playsets may be interactive, but they don't have any rules to classify them as games.
2. Power Flotzo (talk) Per Rykitu.
3. Camwoodstock (talk) Unless it's got a specific rules for play, like a board game, a playset is probably better categorized alongside toys than as a "game".
4. Nintendo101 (talk) Per my comment below.
5. LadySophie17 (talk) Per Nintendo101.
6. Mario4Ever (talk) Per Nintendo101.
7. EvieMaybe (talk) per Nintendo101.

Do we add activity books?

failed to reach consensus 6-8
Deadline: April 25, 2026, 23:59 (UTC) Extended to May 2, 2026, 23:59 (UTC) Extended to May 9, 2026, 23:59 (UTC) Extended to May 16, 2026, 23:59 (UTC)

Yes

1. Nelsonic (talk) Per proposal.
2. Rykitu (talk) Per proposal. I was actually considering making a proposal to split all the physical games found in activity books. While this isn't exactly what I had in mind, sure. If the My Very First Nintendo Game Boy books have a spot in the physical games list because of their water games, so can these activity books for their games.
3. Camwoodstock (talk) A game book is literally a game in a book! It's in the title. It makes sense to denote these in the physical games list, as an overlap between publications and physical games.
4. EvieMaybe (talk) per Camwoodstock.
5. Okapii (talk) Ehhhh.. yeah, per Camwoodstock.
6. Yoshi18 (talk) I mean, this maybe shouldn't count for all activity books, but some of those books are called game books for a reason.

No

1. Nintendo101 (talk) Per my comment below.
2. LadySophie17 (talk) Per Nintendo101.
3. Mario4Ever (talk) Per Nintendo101.
4. Jdtendo (talk) They're better categorized as books rather than games, and I don't see the value in having an overlap between the two categories.
5. WACCA Lily R (talk) Per Nintendo101. I believe we are too liberal with coverage of non-video game "games", and would prefer to reduce coverage then add even more.
6. Power Flotzo (talk) Per N101.
7. TheCatLover738 (talk) Per Jdtendo.
8. Kong (talk) Per Jdtendo.

Do we add art tools?

Art tools are not games 1-7
Deadline: April 25, 2026, 23:59 (UTC)

Yes

1. Nelsonic (talk) Per proposal.

No

1. Rykitu (talk) Adding physical versions of games that are just tools is a bit too far in my opinion.
2. Power Flotzo (talk) Per Rykitu.
3. Camwoodstock (talk) In our opinion, these make more sense to categorize alongside merchandise. It definitely falls under our coverage, but it'd be a little silly to call a stationary set a game on the grounds of "It has Mario, and you interact with it, and can draw like Mario Paint". Just say who made it, explain it, give it an image, and explain any extra bits-and-baubles on the publisher's page; we don't need to try to force the game page format onto a paintbrush with Mario on it, that's a little silly.
4. Nintendo101 (talk) Per my comment below.
5. LadySophie17 (talk) Per Nintendo101.
6. Mario4Ever (talk) Per Nintendo101.
7. EvieMaybe (talk) per Nintendo101.

Do we add Magic 8 Balls?

Magic 8 Balls are not games 1-7
Deadline: April 25, 2026, 23:59 (UTC)

Yes

1. Nelsonic (talk) Per proposal.

No

1. Rykitu (talk) *shakes Magic 8 Ball* "DON'T COUNT ON IT" (that joke I just made, in all seriousness, is the amount of "gameplay" this thing has.)
2. Power Flotzo (talk) Per Rykitu.
3. Camwoodstock (talk) ...Are there even any Super Mario-branded Magic 8 Balls? We feel like categorizing these amongst merchandise makes more sense, at any rate.
4. Nintendo101 (talk) Per my comment below.
5. LadySophie17 (talk) Per Nintendo101.
6. Mario4Ever (talk) Per Nintendo101.
7. EvieMaybe (talk) per Nintendo101.

The Comment Games III: Mockingjay

I think if we broaden the concept of "game" to include interactive toys, "game" becomes so broad of a concept on a site ostensibly about a video game franchise that it loses meaning and utility. An instruction manual is not served well being classified as a book. - Nintendo101 (talk) 22:57, April 15, 2026 (UTC)

To those who oppose on the activity books, some activity books feature actual board games (such as "Super Mario Bros." from Super Mario Bros.: A Big Color/Activity Book and "Board Game" from Super Mario: Mario Time!). The proposal implies that all activity books will be placed regardless if there isn't any multiplayer games in them, which I disagree with. I suggest that we only add the board and card games found in these books by themselves rather than linking the entire book. Rykitu 7:31 PM (UTC) April 26, 2026

@WACCA Lily R I hear your point, though I feel I should note that the alternative for physical game coverage isn't really all that preferable either; currently, the two options I can see are either splitting games off as they are (setting the stuff I'm mentioning in this proposal aside) or merging them all back into merchandise galleries, which... isn't really the best course of action in my opinion, as merchandise galleries don't provide any context as to what X game is and what it does. Certain things that can be done to improve physical game coverage (such as making graphics to indicate certain types of jigsaw puzzle pieces, as mentioned in a previous proposal) simply have not yet been put into place, and these may help improve the coverage of these games. I don't wish to spark any controversy as to what is notable and what isn't, as this was recently the subject of a Mario Boards thread that appears to have (albeit internally) come to a conclusion, though, in short, there's not really anywhere to merge these to in the aim of reducing coverage that doesn't reduce coverage too much, in my opinion. It is my personal opinion that covering these doesn't hurt anything, as they are all (for the most part, barring a couple of distinguish templates) rather self-contained in their own pocket of the wiki. Most of them have been migrated out of mainstream game categories into their own sub-categories (sans a couple of pinball games and a handful of others), so there's not much of the overlap that was a concern initially when these were on the main list of games. Nelsonic (talk edits) 03:22, May 6, 2026 (UTC)

I feel like we need a separate poll proposal for game books. Yoshi18 (talk/contribs) 16:45, May 14, 2026 (UTC)

@Yoshi18 I can do that (after the 30-day proposal-on-a-similar-subject-timer-thing is up). I didn't expect activity books to be super divisive, but a second proposal for them makes sense. Nelsonic (talk edits) 17:25, May 14, 2026 (UTC)

Delete the individual Yoshi's Island enemy class pages

Delete individual pages 15-0
This concerns the following category, and each of its pages, listed below for convenience:

• Category:Yoshi's Island enemy classes
  • Dudim Phreykunoutonthis
  • Edibilis Boringus
  • Harrassimentia Phlyoverus
  • Mostosti Vomitonus
  • Projectilia Ritebakatchia
  • Ucantia Defeatus

...In short, these are not anything specified by the game whatsoever. These are strictly sourced from the Nintendo Power Player's Guide for Yoshi's Island: Super Mario Advance 3, said "enemy classes" are strictly used as section headers rather than taken as being definitively about specific enemies, and even within the guide itself, it doesn't list a faux species for every enemy in the game. Pikmin, this certainly isn't; this is just kind of a joke that spans two pages, and yet somehow has six pages and a category. Imagine if every nickname Nintendo or affiliated sources have used for Shy Guys to promote the enemy-naming feature of Yoshi and the Mysterious Book, from "LL Shy G", to "Hanks", got their own not-redirect, fully-featured pages. That's roughly the level we're operating on here!

Obviously, this is kind of an absurd way to handle this, and giving this the scope we have is bordering on a nonsensical Lore™-brained extrapolation. This is the sort of thing we list as a note, or maybe at the end of the game's section on the enemy's page, not given its whole bespoke page... And if this passes, we'll see to it that that's what we do. Just mention these enemy classes on the enemies' pages, either in the section for Yoshi's Island, or in a Notes section if the enemy lacks a history section for one reason or another.

Proposer: Camwoodstock (talk)
Deadline: May 29, 2026, 23:59 (UTC) Closed early on May 22, 2026, 23:59 (UTC)

Support (It's no Mr. E!)

1. Camwoodstock (talk) Per our Democratius Websitius (own proposal).
2. TheCatLover738 (talk) Per proposal.
3. Rykitu (talk) Per proposal. It is worth mentioning on the enemy's pages and the game's page, but it doesn't deserve an entire article.
4. Robipedia (Japannica) Let's get rid of these wastes of pages and either use them to save the Amazon company rainforest or put actually important stuff in there.
5. Wanderia Florius (talk) Didn't we already decide this sometime ago? I thought the issue was just that nobody had gotten around to it yet. Regardless, per all.
6. Sorbetti (talk) Per proposal.
7. Arend (talk) As the guy who started the whole discussion Camwoodstock mentioned in the comments , per all and per what I said back then (even if it would be pretty funny if we had a Mysterious Book article on Dave). None of these classes warrant an article, especially if the guide they're from don't have complete enemy lists that lead to a lot of speculation and even incorrect information (e.g. listing Lakitu under Projectilia Ritebakatchia instead of under Harrassimentia Phlyoverus (and Projectilia Ritebakatchia lists Wall Lakitu instead), listing Piranha Plant instead of Spear Guy under Ucantia Defeatus, listing all the games's bosses under Ucantia Defeatus when the guide never specified that, etc).
8. Yoshi18 (talk) Per all.
9. Hewbert P. Edia (talk) It's funny that these articles have been questioned on at least five occasions over 16 years and are only now being dealt with. Anyway, better late than never.
10. EvieMaybe (talk) FINALLY! per all.
11. Dominoes (talk) Per all.
12. ThePowerPlayer (talk) Per all.
13. FanOfYoshi (talk) The fact they had articles never sit well with me; I'd say turn it into a redirect.
14. FluffyGuardian70 (talk) Per all.
15. Xiahou Ba, The Nasty Warrior (talk) "Hmm, this is stupid!"

Comments (Joke about "taxonomy" and "Yoshi's tax fraud" here)

@Wandering Poplin - There was a discussion on the category talk page, but it still needed to be outright proposed before we could delete the pages and move the remaining information over to the enemies' pages. This is us making that outright proposal. ~Camwoodstock ( talk ☯ contribs ) 01:17, May 15, 2026 (UTC)

Decide how to handle reissues in the History sections of musical theme articles

Combine all reissues with the original game 5-1-3
5 out of 6 voters (83.3%) approve the first place option.

A while back, I edited the "Forest of Illusion (Map Screen)" article so that the original theme from the SNES version of Super Mario World and the arrangement from the Game Boy Advance remake were combined into one section, but it was reverted, as I was told on my User talk page that reissues with unique arrangements from the original theme should be separated. So with that mind, I went ahead and edited the "Crocodile Cacophony (K. Rool's Theme)" article so that the original theme from the SNES version of Donkey Kong Country 2: Diddy's Kong Quest and the arrangement from the Game Boy Advance remake were separated into their own sections, but it was later reverted, which I assume is because nearly every musical theme article pertaining to the Donkey Kong Country series has their reissues combined with the original game, regardless if the reissue has a unique arrangement or not. This leads me to believe that the way we currently handle reissues in musical theme articles is not very consistent.

To fix this, I propose two options (EDIT: I added a third option based on B700465189a9's comment):

• Option A: All reissues will be combined with the original game in the History section, regardless if the reissue has a unique arrangement or not.
• Option B: Only reissues with their own unique arrangements will be separated from the original game.
• Option C: Only reissues with distinct soundtracks (as in, most if not every musical theme is rearranged for the reissue) will be separated from the original game.

If Option A passes, all arrangements of musical themes from reissues shall be merged with the original game in the History sections. This means that all of the Super Mario All-Stars and Game Boy Advance arrangements of musical themes from Super Mario Bros., Super Mario Bros. 2, Super Mario Bros. 3, Super Mario World, and Super Mario World 2: Yoshi's Island, the Nintendo 3DS arrangements of musical themes from the Mario & Luigi series, and the Nintendo Switch arrangements of musical themes from Super Mario RPG: Legend of the Seven Stars, will all be merged with their original games in their History sections.

If Option B passes, all reissues with their own exclusive arrangements of musical themes from the original games shall be separated in the History sections. This means that all of the Game Boy Color and Game Boy Advance arrangements of musical themes from Donkey Kong Country, Donkey Kong Country 2: Diddy's Kong Quest, and Donkey Kong Country 3: Dixie Kong's Double Trouble!, will be separated from their original games in their History sections. This also means that the arrangements of "Sweet Sweet Canyon" and "Dragon Driftway" from Mario Kart 8 Deluxe will incidentally be separated from the original Wii U version of Mario Kart 8 in their respective History sections.

If Option C passes, only reissues with completely distinct soundtracks from the original game shall be separated in the History sections. This means that everything that was said about Option B passing will apply, except for the arrangements of "Sweet Sweet Canyon" and "Dragon Driftway" from Mario Kart 8 Deluxe being separated, as Mario Kart 8 Deluxe's soundtrack is not completely distinct from the original Wii U version of Mario Kart 8.

Personally, I prefer Option A, as I think it would make musical theme articles in the future more neatly organized, but I also wouldn't be upset if Option B or C passes, as it would still make it so there will be consistency with how reissues in musical theme articles should be organized going forward, which is what I'm aiming for with this article, so it's a win-win.

Proposer: Wilben (talk)
Deadline: May 22, 2026, 23:59 (UTC)

Option A

1. Wilben (talk) My preferred choice.
2. Ahemtoday (talk) I strongly believe these sections should be combined in all scenarios, as any other type of article's history section would do. The only reason they're not is because of the old "arrangements" structure.
3. Yoshi18 (talk) Primary choice; per all.
4. LadySophie17 (talk) Consistency between types of articles is a helpful tool for readers. Those who are familiar with the wiki expect reissues/remakes to be covered under the original games already.
5. Mario4Ever (talk) Per all.

Option B

1. The Dab Master (Nintendo Switch) Primary choice; this is how we used to do this when a reissue featured at least one other arrangement or remix, and I never really saw a problem with this.

Option C

1. Wilben (talk) My secondary choice, though I still prefer Option A.
2. Yoshi18 (talk) Secondary choice; per all.
3. The Dab Master / The Dab Master Deluxe + Expert in Mewing Secondary choice; per all.

Comments

I personally would separate reissues from their original games in these history sections if the reissues feature distinct soundtracks. After all, articles like that of Koopa the Quick do separate reissues when the reissues can be analyzed separately from their original games. The distinction between the soundtracks of Super Mario Bros. and Super Mario All-Stars should not be handled in the same way as the distinction between the soundtracks of Mario Kart 8 and Mario Kart 8 Deluxe. B700465189a9 (talk) 04:04, May 8, 2026 (UTC)

Could this proposal also account for merged series sections such as Dragon Coin (sound effect) § New Super Mario Bros. series or Fortress BGM § Super Mario Maker series? The Dab Master 16:32, May 9, 2026 (UTC)

Probably not, as I'm simply proposing for how to handle reissues in musical theme articles, not series or sequels. Wilben (talk) 23:13, May 9, 2026 (UTC)

Stop requiring editors to count enemies/intractable elements in platformer level articles (unless part of a crucial objective)

canceled by proposer
Okay this thing has been bugging me since the very start, and it has been brought to my attention that there had been a past proposal about this that standardizing this, ever since I had attempted to edit various Yoshi's New Island level articles like Hop 'n' Pop Till You Drop. Over the recent times, I've found the requirement to count enemies in these articles an increasingly cumbersome task, simply because it's unimportant information, useless padding that falls astray to our good writing guideline: everything but the kitchen sink. The detail on how many Goombas appear in World 1-1 is a context-less frivolity that tells readers absolutely nothing about the level, how the enemies are placed (which is already indicated by our level layout descriptions) and gives editors extra busywork to document something most of our audience won't even notice, especially when many of the 2D platformer articles already have a map that readers can look at to get an idea of how many Goombas there are. Editors should not be expected to play Roll Call while documenting level layouts and important collectibles a level has, things that our readers actually come to our level articles for. The idea that World 1-1 also documents the number of coins there are horrifies me on a visceral level on the implications of how much improvement tags we need for the rest of the level articles on MarioWiki, and I'd rather not do this at all than require our editors to count the coins and blocks, especially in games like New Super Mario Bros. 2 that literally has hundreds of coins per level.

I understand in some cases, enemy counts are important. In turn-based RPGs such as Paper Mario and Mario + Rabbids games (the former, I understand, already has various enemy formation articles for locales), the numbers of enemies indicate how many turns the enemy has, and they play a much greater role in how RPGs fundamentally function. In Mario Party game boards, space count is crucial due to the nature of the game requiring dice rolls to move around and indicates overall board size. In platformers, enemies have the same goal as other obstacles and blocks do to a player, impede a player's progress through a level, yet the guideline imposed ignores counting obstacles like the amount of thorns a Yoshi level has, even if some levels have obstacles or features as their main selling point such as the bubbles in World 7-2 in favor of counting how many Chain Chomps the level has, and this rings true for uncountable obstacles which also can be critical to a level's design such as lava, wind, water, etc (plus how many times do we have to point out some enemy and obstacle are infinitely spawned as part of an added note simply because that's just part of the enemy behavior, Bullet Bills especially). This also ignores the case that 3D platformers are far more complex in terms of level design than 2D games and I absolutely balk at the idea of having to count how many individual Urchins there are in Drip Drop Galaxy or how many Dry Bones there are in Sunbaked Sand Castle in Dusty Dune Galaxy; even worse is requiring editors to count how many Gnawties there are in any given level such as Jungle Japes in Donkey Kong 64. We also don't document how many enemies there are in Mario Kart tracks, and miss me of having to count the total amount of Goombas or Oil Spills or even Item Boxes there are in the various Mario Circuits across the series.

Note: This proposal excludes levels where enemy count is crucial to the objective such as defeating all enemies, like those in Battle Belt Galaxy or Mystery House Melee

Proposer: Xiahou Ba, The Nasty Warrior (talk)
Deadline: June 6, 2026, 23:59 (UTC) Cancelled on May 23, 2026

Support

1. Xiahou Ba, The Nasty Warrior (talk) Per proposal.
2. LadySophie17 (talk) Per proposal.

#The Dab Master (5) Per proposal.

Oppose

1. EvieMaybe (talk) I hate to be mean, but this proposal sounds to me like "I don't want to do this, therefore it shouldn't be done". Back when I was making Virtual Boy Wario Land level articles, I had no issue counting how many of each enemy there are, and I consider it reasonable information to include in an article. While I do think we could reexamine how we count enemies for stuff like 3D games where it is harder/less informative to count them, dismissing the entire concept as "busywork" feels like three bridges too far. If you do not want to do it, not a single editor is forcing you to.
2. Doc von Schmeltwick (talk) - Per Evie.
3. Illuminoid (talk) While counting every individual coin in a course that does not involve anything interesting with them might be too much, enemies, obstacles, and some objects have a noteworthy presence in courses, and should be counted. Finding files for each thing can be annoying sometimes. Maybe a dictionary (the data type) could be added to my module, or another place, of all the files to use? That is what the original version used.
4. Sorbetti (talk) per all.
5. The Dab Master (5) Per all.
6. Camwoodstock (talk) We emphatically agree with Evie. This feels a lot like "Well, I personally don't care to maintain this, so we should just cut it altogether for everyone." Nevermind how helpful these enemy/item counts can be if you're up against a game that, say, ends up accidentally fluctuating these constantly due to a bug that plagues the entire game and causes enemies, items, and even entire platforms to disappear in extreme cases, so it's nice to have an upper bound for what is meant to be there, Super Mario Bros. Special. If you, personally, cannot be bothered to do something, it's a good thing that a wiki is something anyone can edit. We should probably be leaning into that, rather than throwing our hands up and saying "Well, one guy left this unfinished, we must cull it all because of this, Such Is The Way Of Things!"
7. Wilben (talk) Per all. I don't really see what this is supposed to accomplish.
8. Rykitu (talk) Per all. This information could also be useful for some people. Why remove useful information?
9. Nelsonic (talk) Per all. I mean, I could see why it doesn't have to be required in certain cases (as in, meriting a to-do if it isn't completed), but I'd say that outright discouraging it is a step too far. We've got plenty of editors, so if anybody wants to add this, they can. If they don't want to, they don't have to. I don't think there's any harm in having more information in articles, but I do think that there is harm in removing large amounts of information from articles.

Comments

I was actually going to create a PipeProject on getting enemy counts. For this, I made a partial draft of a module. I think this proposal should also mention this proposal by Doc von Schmeltwick to allow including a list of intractable objects in level articles. And should we still list enemies when relevant? Many courses require players to defeat every enemy or collect every coin. I assume that we do since this proposal only concerns the requirement. Also, the deadline was set wrong on this proposal. It should be June 6th, 2026. --Illuminoid (talk) 12:35, May 23, 2026 (UTC)

I can get behind listing enemies when they are crucial to an objective, such as Battle Belt Galaxy or Mystery House Melee. It's just that in general, when they are not, is when I think they are a frivolity. I should probably add this to my proposed text. Xiahou Ba^{(the Nasty Warrior)} 12:42, May 23, 2026 (UTC)

Would this proposal "discourage" counting enemies? I understand not wanting to require enemies to be counted for an article to be considered good, but discouraging it would create countless edits to existing articles that would remove factual information from existing pages. Axii (talk) 13:53, May 23, 2026 (UTC)

Restore PipeProjects

Restore PipeProjects and make a PipeProject for music 26-9

This image is clearly a remnant from 2009. I would love to see it be updated to represent the multitude of PipeProjects that I hope will arise from this proposal.

PipeProjects are portals for major projects that often branch out into multiple articles. With the Super Mario Wiki growing day by day, the need for a system that allows like-minded editors to effectively cover select parts of a franchise that spans decades of history and a variety of mediums is clear.

However, PipeProjects were abandoned fourteen years ago. As such, this proposal aims to restore PipeProjects as a wiki-centered space for collaboration. I will also propose the creation of a new PipeProject, which will serve as an inaugural example of how PipeProjects will benefit the wiki.

PipeProjects will serve as spaces to host discussions, communal drafts, resources, and links to relevant discussions and proposals. Rather than scattering this information around various talk pages and user pages, PipeProjects will work as a centralized hub where interested editors can reasonably keep up to date with the project's latest developments. Specifically, PipeProject pages will provide the following sections in order:

• an introduction providing an overview of the project and its goals;
• a curated list of links to relevant proposals, talk page proposals, and unimplemented proposals;
• a curated list of links to relevant talk page discussions;
• an overview of the resources provided by the project, including subpages and passed proposals; and
• a non-signature list of editors who actively affiliate themselves with the project.

While PipeProject pages will generally follow this structure, they may also feature images and other elements as personal touches from the projects' contributors.

Project subpages will be encouraged to host specific project resources as an indication that the pages serve the project and are free to edit. Many valuable pages hosted by other editors already are open to edits, but I believe that moving these pages to common ground would provide even more benefit to editors.

PipeProjects will be created by proposal rather than the supporter-based process currently indicated by the PipeProjects page. Proposals should focus on whether projects will be worked on by many editors and have lasting utility outside of changes to a select number of articles. Most unimplemented proposals will not result in the creation of PipeProjects.

Of course, no project is guaranteed to last forever. Starting a year after the creation of a project, if editors determine that the project is not active enough to continue, the project may be considered closed for inactivity. The year-long delay is intentionally set as a barrier to discourage the creation of projects that may not have sufficient evidence that they would last beyond that year. Subpages for closed projects will remain editable, but the project page will generally be considered archived, and the proposals and discussions lists will not be kept up to date. The existing projects from the previous iteration of PipeProjects will additionally be considered closed. Contributors to a project may close the project earlier than a year via proposal, assuming that the project's goals have been met. Contributors are permitted to reasonably expand a project's scope via consensus, allowing projects to focus on one priority (for example, documenting a portion of the mainline Super Mario series) before continuing with another (doing the same for the broader Super Mario franchise).

As an optional addendum to the restoration of PipeProjects, I recommend that a forum channel be created in the affiliated Discord server, where each post in the channel corresponds to an open PipeProject. I have observed that a system of project-focused channels works well in other wiki communities such as WiKirby, and I believe that implementing these channels would not detract from the ideal of discussions taking place primarily on the wiki.

---

Now that I have introduced my thoughts for PipeProjects as a whole, I would like the propose the creation of PipeProject Music. Over the past few years, a variety of editors including myself have developed the wiki's coverage of music. This progress shows no signs of slowing down, and the resources available and discussions needed would serve well under the structure of a PipeProject.

Specifically, I would like to nominate the following editors who I have seen work on music coverage and the relevant resources that they have contributed:

• Myself (harmonization)
• @Bel2004
• @Conradd (Eligible themes, jingles and sound effects)
• @Dominoes
• @EvieMaybe (draft proposal)
• @MarioMaker99
• @OngoingTalent13
• @Polley001 (Nintendo Music spreadsheets)
• @The Dab Master (Mario Kart World soundtrack, Mario Kart World multimedia)
• @The Eggo55
• @Vivavivi004
• @Wilben

If created, the project's scope would cover articles, sections, templates, and categories for musical themes, sound effects, soundtracks, sheet music, live performances, streaming services such as Nintendo Music, composers and other sound artists, and references to these topics in media, as well as any other music-related topics covered by the wiki.

---

Finally, I would like call out @Nintendo101's work on citations and mainline subjects. While I will not propose for those projects to become PipeProjects on Nintendo101's behalf, I believe both stand out today as incredible examples of the wiki's collaboration that PipeProjects could further enrich.

Proposer: B700465189a9 (talk)
Deadline: May 30, 2026, 23:59 (UTC)

Support: Restore PipeProjects

1. B700465189a9 (talk) Per proposal.
2. SuperGamer18 (talk) I was NOT around when this was a thing, but we should absolutely bring this back. I even have an idea for a new banner if the PipeProjects name is kept.
3. Camwoodstock (talk) Pardon our excitement, but... WE'VE BEEN SAYING THIS FOR YEARS!!! While the Discord and the Boards are adequate for organized efforts, having something on the wiki itself to coordinate these things would go a long way, both for accessibility and making sure those efforts don't get easily lost in the flotsam and jetsam of Actual Conversation. It clearly spells out what is actively being organized, who is working on it, lets people better determine who's handling what, and most of all, puts it in a very obvious space for it that editors are likely to actually see. We could even bolster it with our more recent infrastructure; something like a widget on the main page to show ongoing Pipe Projects to editors akin to the To-Do Bar (and maybe even listing a count of active Pipe Projects on the To-Do Bar itself for good measure), or using a variant of the {{todo}} templates to show that a page is being handled by a specific Pipe Project. We have a lot of options to bring Pipe Projects up to more modern standards, is what we're getting at! (A bit more pragmatically, this will also hopefully offload some of the long-standing "proposals to implement" from that list, by opening them up to more editors willing to pitch in. If this passes, we definitely plan to turn our "reused assets" section proposal in particular into a Pipe Project.)
4. PopitTartProjects (talk) Yes, please. I can't even count the discussions on the Discord server that have culminated in "It sure would be nice if we had the infrastructure to do a big project like this." It has reached the point of being a sarcastic in-joke.
5. Spencer PK (talk) The wiki really needs some way for large projects to be managed so stuff can get done. I left a talk page topic at the main page detailing how the wiki's current documentation of locations in RPGs are poor, but without the ability to orchestrate a project, I could only really just say "there is a problem with the wiki" and leave it at that. The ability to make a project for that would lead to that discussion getting resolved, begin discussion for how RPG location articles should be improved, and would be a natural place for discussion on handling issues as they come up.
6. Aomaf (talk) Per proposal.
7. PipeProject:Nelsonic (talk) Per proposal. I was actually considering proposing this myself at some point.
8. Reese Rivers (talk) Per all. I especially like the idea of the Discord forum channel to go alongside the projects, which I think would be very helpful for realtime collaboration.
9. PipeProject:Rykitu (talk) Per all. I always wondered why a perfectly good idea like that was deprecated, and I'm glad it's returning. My only complaint is Discord, which I don't have (and I don't want one after recent events), but I have a Boards account so that could be a good substitute if I ever decide to start one.
10. EvieMaybe (talk) It's nice to see this finally happen.
11. Sorbetti (talk) Per proposal and Rykitu.
12. TheDabProject (talk) PER ALL!!!
13. DominoProjects (talk) If this gives a good way to organize large-scale projects, I don't see why not.
14. PaperSplash (talk) Per all.
15. ThePowerProjects (talk) Per all. About time.
16. SONIC123CDMANIA+&K(B&ATSA) (talk) Per all.
17. Polley001 (Nintendo Music spreadsheets) (talk) Sounds good to me. I recently brought up a certain grievance with music coverage on Discord, but have not pursued doing something about it largely because bringing attention to it at scale would pretty much require jumping into a massive proposal, which is... not fun. Having a dedicated space to discuss music coverage as a whole would definitely help there.
18. Brett (talk) Per all.
19. Dive Rocket Launcher (talk) Would love to have a way to coordinate with other wiki editors without having to join the Discord server or forum.
20. Illuminoid (talk) Per all.
21. Nintendo101 (talk) I respect the long-term concerns of our compatriots in the opposition, but, TBH, I have long been a bit wary of the community divide between wikispaces, Mario Boards, and Discord. I think PipeProjects can be a potential supplemental for coordinating general wiki-wide projects. I do know a few excellent users of the wiki who I would like to collaborate with that are not interested in Discord or Mario Boards. I can see the infrastructure of PipeProjects being a potentially good avenue for things like that. And even if it does not work out in the long-term, I don't think there's any harm in trying.
22. TT9200 (talk) Per all.
23. YoshiProjects (talk) Per all.
24. Roserade (talk) Although I do understand having concerns overall, I'm a bit confused by the staunchness of the opposition. From how I read this proposal, I imagine the goal is about organization and coordination, and ensuring that all relevant information is in one place. If a helpful conversation is had over Discord, I imagine logs or a summary would be provided on the relevant PipeProject page. This sounds like a huge boon to me and bridges the gap between venues well. As someone who edits this wiki once every two years, I would feel much more compelled to participate if I saw an identified project I cared about, with all of the relevant information in one place so I'm not scratching my head trying to figure out where to "begin". And if this doesn't have a decade of longevity? I mean, that's fine? I'd rather see this approach be given a shot on the chance that it does maintain interest and engagement moving forward. I don't think we're going to be causing a future dumpster fire by giving it a go now.
25. Shoey (talk) Per all. I mean what's the worst that happens? It flops and gets shut down again no harm no foul!
26. Ninja Squid (talk) Per all.

Oppose: Flush PipeProjects

1. Stache (talk) Honestly, I don't really get the hype for this (not that I was active when it was still a thing). I understand that some people are not keen on having a Discord and/or forum accounts, but wouldn't having another place to coordinate on wiki subjects makes the situation on its fragmentation worse, unless we choose to deprecate the use of Discord server and Mario Boards for that?
2. Xiahou Ba, The Nasty Warrior (talk) Per Stache, but I'll further elaborate his points because, as very long-time, old user with much experience who has been here for a decade and a half, who has seen what happened when stuff like this happened (PipeProjects died, moved to the Wiki Collaborations forum with its threads, which had plenty of steam at first, and then also ended up dying over time as interest faded out), this is a vote that voices criticism and concern of this idea, with hints of cynicism (pardon me for that) with the long term prospects of trying to revitalize such a thing that died, without really knowing why it died to begin with than it really is amount to changing anything or persuading anyone to stop despite the surrounding hype I observe, but I honestly don't think this will take off in the long term (and I'm talking many years long term, not months, most voters who voted support here have only been around for a few years), once the initial steam dies off. None of us are paid editors who are under any obligation to do something like this, we are all drive-by using our free time to edit as we see fit, and I think attempting to organize editors something with a cool fancy sounding name and all of this oh my god, cool official sounding organization shit and all, notwithstanding that all of us with schedules and off-site responsibilities to focus on something particular is wasted effort for little gains other than the illusion to make people believe they actually are doing something. People who have the skills and goals to coordinate are already talking to other editors in other venues, such as the Discord channel, which is honestly a better outlet at promoting fast, quick chats with active editors than here. Look at the PipeProject page itself, there are only a few "completed" PipeProjects, take a look at the PipeProject:Super Smash Bros. one, how many editors signed up with the promise of completing these pages, and how many of them you think actually did anything substantial other than a few handful of them, who are likely were already improving these pages before the PipeProject got organized. On the flipside of the "completed" ones, the vast majority of earlier PipeProjects are incomplete, and they languished like this for most of the PipeProject's history, and some got migrated to MarioBoards before also being abandoned (like PipeProject:Unstubify, a problem we still have of this wiki to this day and frankly, we will still have long after we have exhausted our interest editing here). I'm not saying that any of this is a bad idea, and yes, I do see there is interest in this organization...initially, because PipeProjects was also proposed with initial interest and passion, but where will this end up in, say 5 years, when many editors who wanted this moved on and new editors come in and not really know about this or how to deal with this, which is unnecessary convoluted for the sake of it? It is also concerning to me that zero of the concerns that Glowsquid and other voters who had voiced support and their reasons had written up in the initial scrapping the PipeProjects are completely unaddressed, and they are criticisms that I think are still extremely relevant to this day, there is a history of this being attempted many times already. Another massive concern of mine is a heavily reliance on Discord, which is a massive issue in of itself, such as being unsearchable and relatively inaccessible for some users (imagine there being a Discord outage or Discord did something that is extremely cancelable and a chunk of the enraged userbase migrates to another platform out of protest, further splintering collab between communities, now what?)
3. LadySophie17 (talk) Honestly I wasn't gonna vote so I wouldn't be raining on anyone's parades, but since others have voiced their concerns, I'll share mine. From my personal experience in trying to coordinate effort between people (specifically for bringing our Mario Tennis Fever coverage up to snuff), I can barely get people to cooperate by directly asking for help. I don't think creating a dedicated space where I can post my requests and passively wait for people to come by would yield better results, or any results at all. Maybe I'm wrong. I hope I am wrong. But I don't think I will be using this feature in my future projects in lieu of directly getting in contact with people I know would be interested (if there are any).
4. Mario4Ever (talk) Per Xiahou Ba.
5. Hewer (talk) Personally I don't think I fully understand what the benefit of this is meant to be. If you want to improve a particular area of the wiki, you can go and do that. If you want to coordinate with other editors (or even just point out that a certain area of the wiki needs improvement), you can use talk pages or the Discord server. I don't see how adding an extra namespace requiring extra maintenance and providing extra complications is supposed to help in getting anything done. I also don't understand why this is being presented as some sort of way to unite the whole community in one place with even those who aren't on the Discord...when the proposal itself says that PipeProjects would be coordinated on Discord. And coordinating with other editors on Discord is something you can already do. So what is this actually achieving?
6. Wandering Poplin (talk) Per all.
7. Sargent Deez (talk) It's a cute idea, but on top of concerns other editors have already raised, is this really necessary? Many users already allow others to work on their sandboxes and drafts. Only those have an owner to settle disagreements, whereas this may lead to free-for-alls.
8. Ahemtoday (talk) My biggest concern is that I don't like stuff being organized offsite. I don't have an account on the Boards, and I'm not in the Discord server, and even if I did have the inclination to change that, I think I would stop being able to keep up with them fairly quickly. Currently, the only real ways to organize with other users are talk pages (which do not always lead to results) and proposals (and jumping into a major proposal with no discussion beforehand can be a high-stress affair). Theoretically, PipeProjects counteract this, being a focused discussion space where you don't have the pressure to get everything right immediately when you post it. But as proposed here, I worry that it will not counteract that. In fact, I worry it will be quite the opposite when the proposal ends on the note of PipeProjects possibly having associated Discord channels. I'm sure that's useful in a very front-facing way if you're in the Discord, but I'm not, so from my perspective it sounds a bit like it defeats the entire point. Why would I join or make a PipeProject if I'm not in the Discord and am therefore not able to participate in an unknown percentage of the discussion of it, a percentage which for all I know could be the vast majority of it? I'm just worried that this proposal isn't pushing hard enough for having discussions on the site itself and might wind up incentivizing the opposite instead.
9. Salmancer (talk) This is going to sound crazy. But I think in the quest to make PipeProjects v2 a guaranteed success, we've put in so much bureaucracy that while it won't fail, I think it's success would be meaningless. Worse than meaningless actually, but we'll get there. A PipeProject can only exist if enough people are already working on the manner for a sustained period of time, granting those people a dedicated hub space on the wiki and a discord thread/channel/whatever. But... the primary stopping points for anything is the starting gate and the first few hurdles. Essentially, this creates a system which empowers established editors who already have friend groups and already know how to coordinate without the advantages of PipeProjects with additional structure. Structure that those people likely don't need because they've already been coordinating for a sustained period of time anyhow. Sure, it'll help, but only in a "rich get richer" sense. And thus, everything that becomes a PipeProject will succeed, not because of the additional strength of PipeProjects, but because the requirements select for the best editors already. Meanwhile, editors who aren't as good look at PipeProjects and either A) balk at the requirements or B) try to reach the requirements but come up short. B) could happen for many reasons. Maybe they just can't drum up support, or they're not great at parsing and applying all of the rules for PipeProjects, or maybe they just aren't the best at editing. Heck, maybe the problem isn't even " drum up support", it's "attempting to drum up support and get consistent enough edits requires a higher time commitment than they have, mobile game style". Because of A) or B), projects which could really benefit from a discord thread or a dedicated wiki page from the jump, because the jump is the hardest point of any project, won't get those things. And if people don't even attempt to start because they do not see or cannot attain a route that leads to a PipeProject, while established collaborators keep doing what they already did without the advantages of PipeProjects by using PipeProjects, then we're worse off with PipeProjects than we are without them. I'm not going to "Per everyone", since I've typed for long enough but I think the opposition is pretty solid here.

Comments (PipeProjects)

I am very interested in this, but I want to ask: is the name "PipeProjects" an integral part of the proposal? I think it could be a good idea to come up with a new name, both to make it more obvious what its role is, and to avoid having to reuse the now-deprecated PipeProject: namespace. — eviemaybe (talk) 16:49, May 16, 2026 (UTC)

We personally like the "PipeProjects" name, but we can understand the concerns of rebooting an archived namespace like that. Maybe everything currently on it could be moved to some bespoke archival namespace? OldPipeProject or something, though we're open to pitches on that. ~Camwoodstock ( talk ☯ contribs ) 18:13, May 16, 2026 (UTC)

A new name to not touch the old deprecated PipeProject namespace sounds like a really good idea, but I don't have any name ideas. Camwoodstock's idea of just moving the old namespace seems like a solution that could work, but I'm not sure if that is the best idea. --Spencer PK (talk) 18:48, May 16, 2026 (UTC)

I didn't have any specific alternatives in mind, but I do like the alliteration aspect of the current name. There aren't many pages in the namespace to begin with, which is why I think reusing the namespace would be alright. B700465189a9 (talk) 20:57, May 16, 2026 (UTC)

Regarding the creation by proposal, would a new header be placed on this page for these PipeProject creation proposals? --Illuminoid (talk) 17:31, May 16, 2026 (UTC)

In general, I think that the current sectioning of proposals is more confusing than helpful, but under the current structure, I would say that the project creation proposals should be organized under "Additions." B700465189a9 (talk) 20:57, May 16, 2026 (UTC)

Since they can go under Additions, can large proposals incorporate a PipeProject if needed? --Illuminoid (talk) 21:48, May 16, 2026 (UTC)

I would recommend that dedicated proposals to create projects for existing efforts are given, but if needed, other proposals under the section would be able to include the creation of a project. B700465189a9 (talk) 12:51, May 18, 2026 (UTC)

"Proposals should focus on whether projects will be worked on by many editors". If you need people to already want to make edits relating to the project in order to propose the project, then you already have supporters for the proposal. I feel like this will cause the proposal establishing a Pipe Project to just be a formality, and then we're wasting time waiting for proposals to pass. Time where the idea driving the PipeProject is losing momentum as it waits for approval. I really don't think a PipeProject should require a proposal short of it guaranteeing a corresponding discord thread/channel. Salmancer (talk) 21:05, May 22, 2026 (UTC)

Projects don't need approval to exist, as indicated by the several successful projects that already exist on the wiki. The kind of project that would lose momentum as a result of PipeProject approval being sought is not the kind of project covered by the scope of this proposal. B700465189a9 (talk) 20:12, May 23, 2026 (UTC)

Not in love with this proposal

Okay, so the reason I didn't comment earlier was that I didn't want to be the mean old editor who shoots down ideas and wants to stick with status quo as much as possible and I was like, okay, I don't support this really but then again, maybe give it a chance. But then I actually read the proposal and the more I see these provisions the more I dislike them.

Some of these particularly stand out

• Specifically, PipeProject pages will provide the following sections in order: [list]

This is already a bad sign. This puts up a significant barrier of entry that shouldn't have to be there. The requirement that editors comb through proposals and keep up with the current ones, decide which proposals are relevant to the PipeProject, which ones are no longer needed because it was overturned, needs active engaged editors which most will not do or want to bother doing. It's not sustainable. One can say it's not necessarily the responsibility of the PipeProject creator to keep up and others can fill in, but this is the expectation being put in place for possibly interested editors and it can and it will repel newer editors. In most cases, new editors that do want to join will simply leave their name there. The final part requiring a list of editors will either have a lot of no longer active editors or will also have to be actively kept up to date on who's still there on a project which further compounds the issues of long term prospects of PipeProjects. Either way, since anyone can simply leave their name there without significantly contributing to the pages, and most will, the amount of editors between 4 and 40 editors is practically meaningless IMO.

• PipeProjects will be created by proposal rather than the supporter-based process currently indicated by the PipeProjects page.

Very bad idea. There shouldn't be a weekslong process to vet a PipeProject. Users should be able to create PipeProject pages and then editors should be able to judge if this sort of thing is worth following or not. If one thinks this will lead to abuse of the namespace, I will point to Marioboards[1] Wiki Collaborations where anyone can create an account and basically create a new thread on whatever Wiki project needs to be brought attention to. This lower barrier of entry has not led to low quality threads. Also see point above, where there is a remarkable contrast in requirements of creating a PipeProject versus creating a thread in the forums. I am not advocating users create a Marioboards account. Most newer edits have signaled no interest in creating new accounts, much less posting in a largely deprecated community space. However, I just am illustrating this contrast.

• Starting a year after the creation of a project, if editors determine that the project is not active enough to continue, the project may be considered closed for inactivity.

How is this determined? Are users in Project Music editing a couple sentences in Slow and Steady considered active members or not? Should something like Project Music ever be retired because this project is effectively going to be unfinished for decades? This is another layer of maintenance that's practically avoided when it used to be Wiki Collaborations from Marioboards handling all these projects. When projects fall inactive, they sink to the bottom. If there is renewed interest, new posts will pop up. There doesn't need to be community vetting whenever something is worth maintaining or not.

• As an optional addendum to the restoration of PipeProjects, I recommend that a forum channel be created in the affiliated Discord server

MarioWiki Discord is straightforward to navigate and its sort of minimalistic channel count is a design I do enjoy over other servers that have 20 different channels for me to forget where a discussion has taken place. I'm not saying PipeProjects will lead to a lot of channels being created but I also do not want to invite the possibility there will be a maze of threads and channels from creation of a PipeProject. The provisions are not clear if that'll be the case, but even in the best case scenario where only one will be created, why is this different from #mariowiki or #wiki-editing (the second channel is already fairly redundant)? This looks just more like #mariowiki-2. "where each post in the channel corresponds to an open PipeProject" -> What does this even mean? Do you have to be a PipeProject member to partake in this? If not, what's the point?

I don't think PipeProjects will take off with this sort of design. There will be certainly interest when it's new, but once the novelty wears off, I don't see how the trajectory will change. The most successful ones are going to be far and few in between. The proposal does not seem to address reasons for PipeProjects getting mothballed, maybe there was an assumption that with a bigger editor base today there will be renewed activity feasible for PipeProjects; nor are there design choices being made to alleviate the original problems. Another reason for my skepticism is that we can't even coordinate users to expand parts of the wiki that needs expansion such as with Mario Strikers Battle League costume pictures that STILL don't have basic images or Mario + Rabbids (for the longest time, it didn't even have a basic gameplay section). If we can't even coordinate on basic aspects of a wiki, what will a PipeProject do? Be a name in a long list? Have a userbox in a userpage?

I'd like to be proven wrong, maybe this will take off. But some of these provisions are very unwelcome to me and I'd at least rather trim some of these, which will probably require another proposal, probably (to add to the ballooning amounts of proposals over the years which I think has led to the notion that these PipeProjects require literal wiki historians to assist in their creation and maintenance), and I believe will detract from the aims of PipeProjects. I really want to see how this thing will pan out 5 years from now but I have a strong suspicion most of the ~20 (if not more after the time of this post) support voters won't be active and won't see these cumbersome PipeProject pages risking falling to the wayside again. It's me, Mario! (Talk / Stalk) 21:20, May 22, 2026 (UTC)

@Ahemtoday While I understand your concerns, the entire reason for PipeProjects to exist is so projects DON'T have to be coordinated offsite. A Discord channel existing for it is for brief discussions that would be impractical to have in a talk page or a forum thread, as is the Discord's job already, and any information should be mirrored and logged onto the PipeProject itself (as per Roserade's comment). — eviemaybe (talk) 14:58, May 23, 2026 (UTC)

If the point is to not use Discord for the coordination, then Discord shouldn't be used in the coordination, lest the point be defeated. Logging the Discord conversations would help I guess but it's still excluding certain users from actually taking part in those discussions, which is the whole thing this is supposedly trying to avoid. And if you do want to use the Discord to collaborate, you can just do that already without the need for a PipeProject, as I said in my vote. Hewer (talk · contributions · edit count) 23:53, May 23, 2026 (UTC)

Standardize the timezone used for internationally-synchronized release dates

Use the earliest release instant regardless of region 13-0-9-0
As of publishing this proposal, it is about 2AM EST on March 20th, 2026, or 6AM UST on March 21st, 2026. Yoshi and the Mysterious Book has only just released in North America for 2 hours... But it has been out for several more hours in other parts of the world, namely Japan. And in some more western parts of North America, namely in Alaska, the game technically isn't even out! Late yesterday/earlier today, a bit of a conundrum happened on the pages for a few things featured in Yoshi and the Mysterious Book, where their infoboxes were updated to use that game as their "latest appearance" despite the game not being out in neither EST nor UTC... but, it was available in Japan at that point in time.

The original proposal that has been used as a precedent for this sort of thing from 2008 does not specify a timezone, only stating to use the "latest released appearance", putting the emphasis on when the game was released rather than announced, but not when in terms of timezones. We've seen this cause conundrums before; discounting the case with Yoshi and the Mysterious Book that incited this proposal, it's happened recently with The Super Mario Galaxy Movie, Donkey Kong Bananza, with Mario Kart World, with Super Mario Bros. Wonder... Really, any substantially large or dense game will inevitably see at least one over-zealous editor adding these games to infoboxes a few hours too soon, and people feel the need to either debate whether or not they should be reverted, or try to revert them themselves, all over the same lack of a "when" in terms of the timezone.

In this era where more and more Mario games are getting synchronized international releases for most of their release countries, we think it's high time to finally codify a timezone for these. Or in other words, when a game is set to release internationally at the same time for its first release, what time zone should we use? We've got three options here:

• JST (GMT+9): Japan's time zone. If we took that original 2008 proposal literally, this is what we would be doing as a technical status quo, even if, in practice, this usually isn't what we do by a magnitude of literally 13 entire hours.
• UTC (GMT±0): The gold standard for wiki affairs. Proposals use it, signatures use it, edit histories use it (by default, anyways), UTC has been a growing time standard on the wiki.
• EST (GMT-4): This is the de-facto status quo right now. As an American English wiki, it makes sense that the wiki would, on occasion, use the earliest timezone in North America for dates like this.

Edit: Per request, we've added Hewer's suggestion of "whatever country the game first releases in". We kind of don't like this, as it's... Not really a timezone? But, it was requested, and someone else said they would've voted for it if it was there, so, sure.

It was tempting to include NZST (GMT+12) as that is the earliest time zone in a country that sees frequent support from Nintendo (sorry, Kiribati), but we feel like the actual practicality of this is dubious, so we decided to relent. If this is somehow an unpopular stance (beyond just "it'd be fun to put it on the proposal" reasons), we could be swayed to add it as an option.

Proposer: Camwoodstock (talk)
Deadline: June 4, 2026, 23:59 (UTC) Extended to June 11, 2026, 23:59 (UTC)

Use Whatever Country The Game First Releases In

1. Hewer (talk) As argued in the comments, this is the option that allows for the most consistency and accuracy. If a game has been released in any region, then it has been released, and not considering it as such would just be incorrect.
2. Mr. Sorbetti (talk) Per Hewer.
3. Jdtendo (talk) Per Hewer.
4. WACCA Lily R (talk) Same reasons I voted for JST, also per Hewer.
5. Arend (talk) Makes sense (for the record, this seems about using the timezone of whichever region gets it first; e.g. JST is used if Japan gets it first, CET or EET if Europe gets it first, EST if the USA gets it first. For worldwide releases, we just use JST or AEST, since Japan and Australia move on to a new day first or I guess NZST, forgot about New Zealand)
6. Dive Rocket Launcher (talk) This makes the most sense to me. I like using UTC as the basis for internal wiki matters, but that doesn't mean it needs to apply to the entire wiki with articles included. We already use completely different writing and formatting from content articles for our behind-the-scenes matters, so there's no need to try to keep these consistent with each other. And as Hewer said, if a game released in any region, then treating it as if it has not yet released in our articles, just because it hasn't rolled out in one specific time zone, would be objectively inaccurate.
7. LinkTheLefty (talk) It always bothers me when other wikis arbitrarily list Japan first, even when it doesn't make sense to, and then I have to do a double-take when I get my date info wrong. It happens often enough that I'd rather we standardize a flat-first across the board. Hopefully it'll catch on.
8. Doc von Schmeltwick (talk) - Seems to be self-evidently the best option.
9. SuperGamer18 (talk) Honestly, this is just what makes the most sense out of everything discussed so far.
10. Camwoodstock (talk) We generally prefer the idea of parity with UTC, but this is at least a defensible deviation from UTC, favoring accuracy of "when the game literally releases globally" to "when the game releases to the day".
11. I... don't use U.T.C. (talk) Yeah, if a game releases in Japan two months before North America and FIVE before Europe... then yeah, this should be preferred. I actually brought something similar to this before and this should allow us to know if information is gained from a legitimate release copy or a broken street date.
12. EvieMaybe (talk) yeah sure
13. SeanWheeler (talk) If the earliest release date counts, the earliest time should too.

Use JST (technically the status quo)

#SeanWheeler (talk) If Japan-only games would count for latest appearances, I don't see why we'd have to wait when international worldwide releases would be Japan-exclusive for a couple hours. We covered games that came to Japan first and were scheduled with a different release date for America, right? If the "simultaneous" releases drops at each time zone at their respective midnight, I don't see how that's different.

#WACCA Lily R (talk) I think running with the earliest time here will just save any headaches with people who come along and change the template because it's out in another regions. No need for arguments or revert wars and telling people that they're technically wrong, the page just gets edited once because it's out in a region and is treated as such.

Use UTC

1. Illuminoid (talk) Since most things on the wiki use UTC time, it would seem really weird if this one thing did not.
2. Rykitu (talk) Per all.
3. LadySophie17 (talk) We've switched to UTC almost everywhere, makes no sense to stop now.
4. Nelsonic (talk) Per.
5. Yoshi18 (talk) If we use UTC, the game has released in at least half of the world and that this is arguably the best option. Also per Camwoodstock, Illuminoid and LadySophie17. I was about to give their exact reasoning as well.
6. Wilben (talk) Per all.
7. Lastro (talk) Per all.
8. PopitTart (talk) I certainly agree with the arguments that if a game is released, then it should count as being released, but I find the proposal option of "Use Whatever Country The Game First Releases In" unhelpfully vague. Is it even codifying anything if we don't have a concrete answer for what that is? Using UTC makes it extremely clear when articles should be edited. If the option were clarified to be "precisely midnight in New Zealand Standard Time, UTC+12" like Camwoodstock suggests in the proposal edit, or whatever else may actually determined to be the correct earliest release, then I'll change my vote.
9. FluffyGuardian70 (talk) Above all, this seems reasonable for the average wiki reader.

#Camwoodstock (talk) We've gone on record to be skeptical on UTC before, but as of recently, we've kind of changed our tune, especially after Porplemontage proved the transition from EST to UTC really wasn't that difficult to implement. UTC is late enough in the day for folks in North America that it doesn't really (even in Alaska, you'd only get it "early" insofar as we'd consider the game released at their 4PM), and above all else, UTC is consistent with so many other things on the wiki.
#EvieMaybe (talk) per Illuminoid.
#WACCA Lily R (talk) I have nothing against UTC either, while less practical in my books, I love the sound of consistency.

Comments (it's about time!) (...zones)

I'm confused. If a game has released in Japan (or any region), then it is a released game and should count for the "Latest appearance" in the infobox regardless of any other parts of the world, right? Not to mention that Japan-only games count for the latest appearance too (like in the months between the Japanese and international releases of Hello, Mario!). Hewer (talk · contributions · edit count) 16:21, May 21, 2026 (UTC)

The proposal already states that this applies to simultaneous worldwide releases only. If a Japanese release significantly predates the international one, then yes, we would go by it, but we can be a little patient and wait 9 hours for the release date to roll around in UTC. — eviemaybe (talk) 15:24, May 22, 2026 (UTC)

I don't understand the benefit of deliberately being inaccurate for those 9 hours. If a game has released, there's no reason for it to not count as a released game. I would support an option of "use whichever time zone has the earliest release". Hewer (talk · contributions · edit count) 18:55, May 22, 2026 (UTC)

UTC is arguably the best option here as well he game has released in at least half of the world by then and not just one country. If we're gonna look at it like it's inaccurate the moment we don't update the appearance tables when a game releases in Japan, then we might as well already change the appearance table when the game releases in New Zealand. Yoshi18 (talk/contribs) 09:53, May 23, 2026 (UTC)

I'm with Hewer on this one. If we already count Japan only games, and we don't even wait for a game to be released in America when it was released in Japan months prior, why should the time matter for these same day worldwide releases? If someone made an edit a couple minutes before it's time and the admins found it after it was time, there would be no point in reverting, so that rule would be difficult to enforce. SeanWheeler (talk) 21:28, May 23, 2026 (UTC)

As I said, I would support an option of "use whichever time zone has the earliest release", as anything else is just purposefully being inaccurate. So yes I do think it should be listed when it's out in New Zealand. Why shouldn't New Zealand count? Hewer (talk · contributions · edit count) 23:44, May 23, 2026 (UTC)

Because the game has been released in just one country. Only a handful of people can play it. In some countries it may even be a day (and 2 hours) before the release. The reason I think UTC is the best option is because the game has then released in at least half of the world, instead of solely one country. Also, the fact our wiki has been converting a lot to UTC lately. It would only make things more accurate. UTC is the standard timezone of the world. That one should count the most. Yoshi18 (talk/contribs) 08:45, May 25, 2026 (UTC)

As has already been discussed, games that aren't released worldwide (e.g. Japan-only games) do count, so being released in only one country doesn't (and shouldn't) disqualify a game from counting as released. Also, Japan has the world's 11th-largest population, so that's hardly "only a handful of people". Hewer (talk · contributions · edit count) 11:17, May 25, 2026 (UTC)

Games that aren't released worldwide (mainly Japan-exclusive) can have an exception, since they're only released in one country anyway. Yoshi18 (talk/contribs) 13:27, May 25, 2026 (UTC)

Why bother making an exception when you can just have a consistent rule that works in all cases? Hewer (talk · contributions · edit count) 14:31, May 25, 2026 (UTC)

UTC just feels like the perfect inbetween to me. It's not too late but also not too early. If we use UTC there would be at least a 12-13 hours between the earliest and the latest timezones. Also, we should ask ourselves the question: when was the last time there was a Japan-exclusive Mario related game. Besides, everything on the wiki uses UTC nowadays. Wouldn' Using a different timezone for game dates make sure his a bit inaccurate? Yoshi18 (talk/contribs) 08:48, May 27, 2026 (UTC)

As I mentioned earlier, Hello, Mario! is a recent game that was Japan-exclusive for six months, but was still counted for latest appearances as soon as it was out in Japan. Other things on the wiki that use UTC frankly aren't relevant, those aren't really about actual mainspace content. Hewer (talk · contributions · edit count) 11:23, May 27, 2026 (UTC)

Honestly, I gotta admit that that's fair point, but there’s still aren't that much games that are Japan-exclusive anymore. Also, the reason why I just don't see using the earliest timezone being a good idea and would rather be supporting UTC is because the whole wiki uses it right now. Just look at the signatures and proposal end times. Why would we be inaccurate by using another timezone for game release times? NZST just seems to far off for me. If we use that it still takes a total of 24-25 hours for the other side of the world to get the game. Contrary to UTC, which is pretty balanced. The game may have already been released for 13 hours in NZST, but it also takes 12 hours to release in the latest timezone (UTC-12). Yoshi18 (talk/contribs) 07:09, May 28, 2026 (UTC)

Hey @Camwoodstock, just to correct you, the earliest timezone of a country that sees active support from Nintendo (New Zealand) is technically NZDT (GMT+13). And the earliest timezone in North America is technically EDT (GMT-4). Yoshi18 (talk/contribs) 09:53, May 23, 2026 (UTC)

@SeanWheeler, could you explain your reasoning? Just wondering but what do Japan-exclusive games have to do with this? I mean, we can make exceptions for them since they’re only gonna be released in one country (Japan) anyway. Yoshi18 (talk/contribs) 08:45, May 25, 2026 (UTC)

@Camwoodstock I would like it if you added an option for "use whichever time zone has the earliest release", as I have been arguing in support of. Hewer (talk · contributions · edit count) 11:21, May 25, 2026 (UTC)

Shouldn't there then be a timezone for the latest release as well? As the game has then be released in the whole world and not just one country (New Zealand isn't that big of a country)? Yoshi18 (talk/contribs) 13:27, May 25, 2026 (UTC)

What do you mean? Hewer (talk · contributions · edit count) 14:31, May 25, 2026 (UTC)

Eh, it was just a thought for an option to only update the latest appearance table if the game has really released everywhere. Yoshi18 (talk/contribs) 08:55, May 27, 2026 (UTC)

I'd support Hewer's option too BTW. LinkTheLefty (talk) 14:05, May 25, 2026 (UTC)

Is there any way for it to use the timezone set in the user's preferences? --Illuminoid (talk) 18:41, May 25, 2026 (UTC)

What would the benefit of that be? It would just be giving some users less up-to-date information than others. I think the wiki should, as much as is possible, use an objective viewpoint not tied to a particular region (i.e. a game is released if it has been released anywhere), and showing different information to different users depending on region goes against that. Hewer (talk · contributions · edit count) 19:06, May 25, 2026 (UTC)

Ignoring the fact that we don't even know if it's possible, to what end would that even be for? From UTC+12 to UTC-12, we replace the "latest appearance" parameter with some dynamically-updating template that cross-references your own user preferences to determine what timezone to use, and then after UTC-12, we just change the recent release to just... The game itself? ~Camwoodstock ( talk ☯ contribs ) 22:15, May 25, 2026 (UTC)

I like the sound of that idea, @Camwoodstock! This could potentially overrule the timezone argument. Yoshi18 (talk/contribs) 08:57, May 27, 2026 (UTC)

I don't understand why time zones are being considered part of the discussion at all. A point in time has either passed or is in the future, regardless of time zone. From my understanding, this proposal focuses on the qualification for media listed in the "latest appearance" field of infoboxes rather than how dates are written out in fields such as the "release date" field of game infoboxes. As a result, I don't think time zones should be considered in this proposal.

That being said, games have multiple release dates because Nintendo operates in multiple regions, and different policies are used in each region. In the United States, for example, the specific time of a given release date is midnight in the Eastern Time Zone across the entire country, as confirmed by a support article. These policies apply to Nintendo eShop launches in addition to in-person launches, as those who were part of the Nintendo Switch 2 launch can attest to. Since these different policies are documented and consistent, I don't see any reason to invent a time zone-based approach rather than simply considering a game launched when it first launches in any region. B700465189a9 (talk) 21:22, May 25, 2026 (UTC)

We mean, time zones are a factor because the original debacle that caused this (when to update pages to say Yoshi and the Mysterious Book was the most recent appearance) was rooted entirely on editors disagreeing which time zone to use for counting the game as "released". Some argued that it being out in Japan meant it was fine, some argued it should wait until it released in UTC, some argued it should wait for midnight EST. This is kind of just already mentioned in the lead of the proposal, though. ~Camwoodstock ( talk ☯ contribs ) 22:15, May 25, 2026 (UTC)

I was part of those discussions, though, and I never thought that bringing time zones into the equation made sense at all. Simply put, games don't release "in" time zones. Since you've clarified that this proposal would only affect "latest appearance" fields, I would prefer if the proposal summary was updated from "Standardize the timezone used for internationally-synchronized release dates." I'd also like to see more complete explanations of how an editor could determine whether a game would qualify as released under each option, since "Use Whatever Country The Game First Releases In" and "Use UTC" aren't clear. B700465189a9 (talk) 04:29, May 26, 2026 (UTC)

Games with a synchronised international release date will release at different times throughout the world depending on when the date arrives in each time zone. Under the "Use Whatever Country The Game First Releases In" option, the game is considered released as soon it has released in any region, while under the "Use UTC" option, the game is not considered released until its release date has arrived in UTC. What's unclear about this? Hewer (talk · contributions · edit count) 11:13, May 26, 2026 (UTC)

I have attempted to explain that "Games with a synchronised international release date will release at different times throughout the world depending on when the date arrives in each time zone" is not correct. Suppose that Yoshi and the Mysterious Book released in only two regions. For Nintendo's operations in the United States, suppose the game released at 2026-05-21 04:00 UTC. For Nintendo in Japan, suppose the game released at 2026-05-20 15:00 UTC. Assuming the current time is 2026-05-21 00:01 UTC, how do you determine whether the game is released under each option? B700465189a9 (talk) 14:53, May 26, 2026 (UTC)

I think the "Use UTC" option implicitly assumes that the game in question getting a "synchronised international release" is released in a region that uses UTC as its time zone, which it isn't in this hypothetical. So I'm not sure if this scenario would count as a "synchronised international release date" for the purpose of this proposal. If not, the default would presumably be "it's considered released if it has been released in any region" like how non-internationally released games are handled (so, in this scenario, it is considered released as it's already out in Japan). If it does count as a "synchronised international release date" then I don't know how the "Use UTC" option would work, but it would at least still be considered released under the "Use Whatever Country The Game First Releases In" option. Hewer (talk · contributions · edit count) 15:17, May 26, 2026 (UTC)

I don't think that we have come any closer to defining a workable policy. If this proposal can't consistently apply to all games, then why define a policy at all? Suppose that Yoshi and the Mysterious Book released in a region that primarily uses UTC, the United Kingdom. Nintendo's equivalent support article explains that games release at 14:00 GMT. Since Yoshi in the Mysterious Book was released in a region that uses UTC, making the game have a "synchronised international release date" under your assumption, would you be able to determine whether the game is released? B700465189a9 (talk) 03:56, May 27, 2026 (UTC)

We're gonna be honest, we feel like this entire conversation has kind of been overthinking it. When we say a game with a "synchronised international release date" we're not like, trying to define backwards what a "synchronised international release date" counts as versus what is "just a game that releases at the same time in multiple, but not all, countries". You can very well simplify this to "anything that uses the world flag in its release date parameter on its own page" if you want, but like, for our purposes, The Super Mario Galaxy Movie released first on April 1st, because that's where it premiered for the majority of the world, and it was promoted as premiering for the majority of the world.
Furthermore, we feel like there's kind of been a growing misconception that people think this is about said Release Date field, when like... That was never our intention, we never brought it up in the proposal itself for a reason. This is exclusively for the purposes of updating the "Latest appearance" fields on various subject infoboxes, determining when something is "released" for the sake of updating that field.
And especially when the current option in the lead is the one that entirely forgoes this by straightforwardly saying "Just use the timezone of the first place it releases", implying we don't even need to care about the specific timezone at all and just need to ask, "okay, is it out in Japan, or some area even more eastward than it?", you don't even need to worry about the conundrum of "what about a country sitting along the lines of UTC, that is somehow de-synchronized from it?" at all. We're litigating an edge-case that doesn't even seem likely to be a case we need to care about unless this gets re-proposed. ~Camwoodstock ( talk ☯ contribs ) 04:15, May 27, 2026 (UTC)

This response doesn't really answer the questions raised in this conversation. The point is that it's unclear whether a game would be considered "released" in certain cases if the "Use UTC" option passed. Hewer (talk · contributions · edit count) 11:23, May 27, 2026 (UTC)

If the "use UTC option" passed, it would be considered released that day at midnight (0:00) UTC. Nintendo might specify they only list it digitally at 14:00 GMT, but for the sake of saying the game has released, it's midnight. The current de-facto status quo is to assume midnight EST, each of these (sans the "just use whenever the game first releases globally") option assume midnight, because there's been really no reason to assume it's not midnight outside of "how Nintendo handles digital releases in Europe", which... Again, wasn't really a thought in our mind, considering we only just learned about this "14:00 GMT" edge-case seven colons deep. ~Camwoodstock ( talk ☯ contribs ) 15:55, May 27, 2026 (UTC)

I'd like to understand whether this proposal applies only to games or to release dates for any kind of media. It has long annoyed me that Nintendo Music soundtracks are listed as having released on the American dates and not that of both Japan and UTC (which I believe have aligned universally aside from the service's launch), especially in cases where the date is relevant to what is being added such as upon a game's release. Polley001 (talk) 21:34, May 25, 2026 (UTC)

That feels a bit out-of-scope for what we're trying to do here. This is very specifically about when to count a game as "released" for the sake of the "latest appearance" parameter, not "should we list any date fluctuations caused by a unified global release in the release date parameter". ~Camwoodstock ( talk ☯ contribs ) 22:15, May 25, 2026 (UTC)

Fair enough I suppose, seems rather contradictory though if "latest appearance" relies on one timezone while "release date" relies on another. Especially if UTC wins out since that'd just make release dates focusing on Eastern Time even more bizarre. Polley001 (talk) 06:18, May 26, 2026 (UTC)

I'd rather see a more thorough proposal to handle defining how dates are written. The dates we use vary in precision, and I would want to take care of every case across the wiki. B700465189a9 (talk) 14:53, May 26, 2026 (UTC)

@PopitTart: The point of the first option is to not specify one consistent time zone for every case and to instead consider a game released if it has released anywhere. In most cases that does probably mean New Zealand, but specifying that as the explicit thing the option is for feels like it's asking for some edge case to come up that doesn't quite work with that (e.g. a game released in multiple regions but not New Zealand). Even if that's unlikely, it makes the most sense to have a rule that can cover any potential cases that might arise without needing to go back and fix it later. Better safe than sorry. Hewer (talk · contributions · edit count) 09:35, May 28, 2026 (UTC)

Honestly, the prospect of having to sus out whether a game is actually releasing in New Zealand every time one comes out is significantly less appealing to me than just letting the Latest Apperance parameter possibly be inaccurate for a couple of hours. The point of this proposal is to prevent edit wars in that single-day window of time over whether or not a game is out, and I'd rather have something concrete and simple to enforce.--PopitTart (talk) 11:27, May 28, 2026 (UTC)

To my knowledge, pretty much all games that Nintendo releases worldwide come out in New Zealand (and whether they do or not is technically already something we need to determine anyway, so we can list it as a region in the game infobox). Anyway, my stance is that, if someone can attest that a game has already released in a certain region, it would be silly to revert their edits to the infoboxes and tell them they need to wait for UTC. Obviously it's not the end of the world for a page to be out of date for a few hours (many are out of date for much longer), but it's also not something we should deliberately enforce. Hewer (talk · contributions · edit count) 13:43, May 28, 2026 (UTC)

Shouldn't we technically, by your standpoint, then use NZST for everything though? Just wondering. I guess I'm all in for your option as long as we at least keep things consistent (as I'm also all in for consistency). I feel like using NZST solely for game times and letting everything else on the wiki use UTC would be more inconsistent than using UTC for game times even though the game has already came out 13 hours ago in New Zealand. Yoshi18 (talk/contribs) 14:30, May 28, 2026 (UTC)

There's no reason to worry about "consistency" here. I genuinely don't understand why you think the matter of when to update latest appearances in infoboxes is related at all to stuff like proposal deadlines or signature timestamps on talk pages (which I assume you're referring to by "everything else on the wiki"). Hewer (talk · contributions · edit count) 15:09, May 28, 2026 (UTC)

Aren't game dates (and to an extend infoboxes) somewhat related to the wiki and most other things we do on it? Yoshi18 (talk/contribs) 17:14, May 28, 2026 (UTC)

Not in the way you've been suggesting. Using UTC for timestamps on talk page comments doesn't somehow prevent us from saying a game has been released after it's been released. There's no connection between the two. Hewer (talk · contributions · edit count) 18:47, May 28, 2026 (UTC)

That may be true, yeah, and while using the earliest timezone could be a consistent thing to do, I do agree with others that it could still very greatly between NZST (UTC+13) and later timezones. Yoshi18 (talk/contribs) 22:39, May 28, 2026 (UTC)

Update the Template:Star ranking

canceled by proposer
Redecided that the changes proposed are unnecessary
Reception sections have been a major focus of mine recently, so I have noticed that the template for star ratings is not only rarely used in tables for these sections but is also bare-bones. Compare that to Wikipedia, which uses images for stars instead of text-based ones. It also lets you replace stars with circles and thumbs-up or thumbs-down icons, and adjust the number of icons. If a game is rated 7 out of 10 stars, we could put that. We could either use generic star images or add some Mario flair by using Power Stars. As for whether we use pre-existing sprites for the latter or draw new ones, that is for the comments to decide. Here's a mock-up of what the template could look like.

Proposer: Sargent Deez (talk)
Deadline: June 26, 2026, 23:59 (UTC) Canceled on June 13, 2026, 18:07 (UTC)

Support 2: Use image-based stars, circles, and thumb icons

1. Stargent Deez (talk) As proposer.

Support but better 2: Use Power Stars, circles, and thumb icons

1. Stargent Deez (talk) As proposer. May cancel my above vote depending on which option is more popular.

Oppose: Do not change the template

1. Illuminoid (talk) I honestly do not see the issue with how the template works currently. "★" does not convey any less information than an image of a gold star. I never knew about the existence of the template until I read this proposal. The non–Super Mario design from Wikipedia does look appealing for media ratings. However, in other cases, it would look out-of-place; the terrain strengths and Emerald Rush difficulties on the Donkey Kong Bananza layer articles are an example of this. In terms of the design based on the Star icons from Super Mario Galaxy and its sequel, the Hidden Star icon being used in place of "☆" does not convey its use purpose. While unlikely, I do see the possible issue of confusion with the Star icons.
2. Ahemtoday (talk) Admittedly, I have been slacking on this, but I mostly interact with this template by way of the Donkey Konga difficulty ratings. Technically, they're supposed to be barrels anyway, but that's besides the point. Text-based stars fit better into dense tables and infoboxes better than images do.
3. Hewer (talk) Fixing what's unbroken.
4. Jdtendo (talk) For general usage, generic text icons work better than more specific images, per Illuminoid.

Comments: Insert title here

Shouldn't this go under § Changes? The Dab Master 18:48, June 12, 2026 (UTC)

Nevermind. The Dab Master 18:49, June 12, 2026 (UTC)

Move "Haunted House Course" and "Inside Wario's Castle" to "Ghost House Course" and "Captured Mario's Castle Course" respectively

move 8-0
This proposal aims to rename the Haunted House Course and Inside Wario's Castle articles Ghost House Course and Captured Mario's Castle Course, respectively. The current names of the articles—"Haunted House Course" and "Inside Wario's Castle"—are taken from the Super Mario Bros. Encyclopedia. However, there are higher-priority sources respectively named "Ghost House Course" and "Captured Mario's Castle Course", both which are taken from the Nintendo Music soundtrack for Super Mario Land 2 - 6 Golden Coins—released on February 23, 2026—although the only higher-priority source whose name matches that from Shogakukan is the Ghost House Course. I propose that we both rename the Haunted House Course article Ghost House Course and rename the Inside Wario's Castle article Captured Mario's Castle Course.

Proposer: GuntherBayBeee (talk)
Deadline: June 14, 2026, 23:59 (UTC)

Support Course

1. GuntherBayBeee (talk) Per proposal.
2. Doc von Schmeltwick (talk) - Makes sense to me. Reminds me of how the Link's Awakening Switch remake completely disregarded what Dark Horse's Zelda Encyclopedia had (which was an even worse case of plagiarism than the SMB one).
3. Wilben (talk) I don't see why not.
4. Illuminoid (talk) Per all.
5. Dive Rocket Launcher (talk) Sure, makes sense.
6. BMfan08 (talk) I'm not entirely sure that this needed a proposal, but, sure. Per all.
7. Polley001 (talk) Pretty natural decision really.
8. The Dab Master Course (talk) Per all.

Create a template and PipeProject for enemy, obstacle, and item lists in courses

Do not create the template or PipeProject 1-1-2-6
A little while ago, I proposed the idea of standardizing the format of enemy and obstacle lists. This proposal passed, but remains unimplemented. The proposal can viewed here. More recently, another proposal was made to stop making these lists a requirement. Within the first few hours of it being proposed, it had garnered a large opposition. The proposal was removed by its proposal soon after. The proposal can be viewed here. It is quite clear from that proposal that getting this information is important and needed, so I propose a PipeProject to organize the collection of this data. PipeProject:Entity lists, or PP:EL for short, will include check lists for which games' courses/levels/stages have been covered. Covering this data alone would obviously be difficult, and not everyone has every Super Mario (and Yoshi, Donkey Kong, and Wario) game or access to game internals, which seems very useful, especially for coin counts.

I am also proposing a template to assist with implementing the proposal that standardized using tables. While course articles have separate sections for enemies and obstacles, and item counts, this template will be used for both sections. I have created a Lua function that will make the template output when given parameters. The function is known as "createTable", and is currently found in Module:Sandbox. A key characteristic from the output of this function is a row that displays the total count. Preferably, this total is not used for item lists using |no_total=y. This template can be viewed on my userpage. Having such a template will allow for standardization of styles, and prevent meticulously going through each table to fix one little thing. Data for the template can be found here in JSON format. This JSON file contains a list of valid entities for each game (well, only Super Mario Bros. Wonder and its Nintendo Switch 2 edition at the moment), the links for each entity if it is not just [[<entity name>]], the files for each entity, the scale that files should be, the table colour, and the word used for the column displaying images. The template itself contains the following parameters:

• |entity1, |entity2, |entity3...: these specify the name of the entity for the row corresponding to the number at the end. If an entity is invalid, as determined by the JSON data, the module will return an error. These parameters are used to generate the file for the entity from the JSON data. If an entity has no associated file, {{no image}} is used.
• |count1, |count2, |count3...: these specify the count for the row corresponding to the number at the end. If a count is not specified for an entity that is, the count will display as an en dash (–). The sum of all the counts, minus the non-numbers, are used to calculate the total row. This total row does not display if there is only one number count.
• |countAlt1, |countAlt2, |countAlt3...: the count rows for Hard Mode and Easy Mode from Super Mario Land and Super Mario Land 2 - 6 Golden Coins, respectively.
• |countT1, |countT2, |countT3...: these are a variation of the "count" parameters above; if there is ever a scenario where the counts should not be used for the total, this parameter can be used to overide the number used for calculating the total. This should rarely be used.
• |countTAlt1, |countTAlt2, |countTAlt3...: the version of the parameters above for the "countAlt"s.
• |notes: using this parameter adds a notes column used for specifying any notes about the count, such as indefinite respawning.
• |note1, |note2, |note3...: these specify the notes for a count for the row corresponding to the number at the end.
• |game: this parameter must be set to the abbreviation of the game. Each game has its own data in the JSON data.
• |no_total: removes the total at the bottom regardless of other factors.
• |tableColor: this overrides the table colour used for a game. The only scenario where this would be used is to make New Super Luigi U's tables use the luigi table colours.

I have experimented with using simple parameters to generate enemy tables. It worked quite well. The results were used in the pages in these categories.

Conclusively, this wiki needs more data on how many enemies are in a given course, and now that PipeProjects have returned, they should be used to accomplish this large task.

Edit: An option has been added to keep the module for substitution only, meaning that the option is available for anyone if they wish. This will be enforced by returning an error if the module is invoked while not be substituted.

Proposer: Illuminoid (talk)
Deadline: June 20, 2026, 23:59 (UTC)

Support: Create them

1. Mr. Sorbetti (talk) Per proposal or project? Either way, I support this.

#Illuminoid (talk) As proposer.

Partial Support: Template (and its associated pages) only

1. Illuminoid (talk) Primary choice. With Camwoodstock's project being in the works, just having the template may be the better option. This PipeProject is definitely too small in scope, so having it exist separately probably would not go efficiently, especially with the lack of interest for this particular topic. While the template has its flaws, utilizing it should be easier than typing the whole table manually. Most of template's flaws would also appear when implementing the proposal without it. The focus remains on having an easier method to implement the proposal.

Partial Oppose: Do not create them, but keep the module

1. Illuminoid (talk) Secondary choice. Per proposal. Regardless of what option passes, I still plan to use a module to create these tables; may as well make it accessible to other users.
2. Yoshi18 (talk) Secondary choice.

Oppose: Do not create them

1. Salmancer (talk) I'm going to be the hard case here. This doesn't meet the as stated requirements for creating a PipeProject. This does not have a set of editors who are committed to making this a reality, which one needs before they start. (Just yourself probably doesn't pass the requirements) The structure seen in the proposal is relatively new and unproven save for Template:MKWorld missions and Template:SMO Power Moons, which has me worried about if there are enough people experienced enough with the matter to correctly use it. (If I count correctly, two editors established those, so adding you makes for three people.) Lastly, I object to having a count of things like lava pits. Most games implement lava as spanning the entire area, with muliple places where the player can fall into that vast lava pool. An example of such a course is Skeleton Goonies' Lava Lair. I think having articles for such areas say that "this course has one lava pit" when the lava is a threat for the entire course doesn't make a lot of sense. Since this system is being applied across the wiki as a standard, it should count up individual lava and similar obstacles where it makes sense to count them, and not count them in cases where it doesn't make sense to.
2. Camwoodstock (talk) We'll be a lot nicer, but we still don't want to support this for one key reason that we honestly feel eclipses "what if you're the only participant"... We're already planning on making a PipeProject for general Wikitable affairs, from implementing the proper series coloration to helping bring parity to enemy list tables, and this is the exact sort of thing we'd want as part of that! Rather than having two PipeProjects for more-or-less the same thing, but with one being more specific than the more broad one, and rather than having to figure out how the heck one would merge two ongoing PipeProjects (is that even a concept that makes sense?), we'd personally like to see this operation become a part of a greater push to improve tables that we've been working on.
3. YoshiProject (talk) Although I like and encourage new PipeProjects to be started, but I think this is too broad for just one sole PipeProject. All three of these are (or at least can be) different subjects.
4. EvieMaybe (talk) per Camwoodstock. better to do this all together properly.
5. Mario (talk) I disagree with the premise of the proposal. Enemy count in most levels are mostly irrelevant trivia points. Even in cases where it is important to know specifically how many obstacles are in a level, you don't need any special wiki formatting, much less a template with an array of parameters, much much less an entire PipeProject, to simply list a number. I advise that if this community insists on requiring users to count the enemies and coins and blocks in a level, they should keep that kind of information as simple as possible and list in parentheses in a gallery (or in a bullet list if a gallery is unavailable) with a short description that the number in parentheses is the quantity of doohingies in a level.
6. LadySophie17 (talk) Per all. Standardizing enemy tables doesn't mean we need to keep enemy count around.

Comments about enemy, obstacle, and item list tables

You have the notes parameter listed twice. The Dab Master 01:36, June 6, 2026 (UTC)

Removed. Thank you. --Illuminoid (talk) 01:39, June 6, 2026 (UTC)

Not sure if I like the idea of all listings being increasingly numbered like that. Doc von Schmeltwick (talk) 02:36, June 6, 2026 (UTC)

...Since we brought it up in our vote, you can find our draft for a Wikitables Pipe Project here. And, sorry for making this more-or-less a plug for our own draft, but we feel like it's best to break the news now rather than sit on it and let it grow more awkward. (Also, as someones who've spent a lot of time with tables, we will say, we were initially skeptical of the JSON tool thing, but are very pleasantly surprised by the tables we saw, since they have basically the exact syntax we were thinking of. Certainly beats the table generator in the "Advanced" bar, anyways!) ~Camwoodstock ( talk ☯ contribs ) 04:41, June 6, 2026 (UTC)

I was unaware that such a PipeProject was in consideration. I briefly mentioned this one in the comments of the proposal to stop counting entities in courses a little over a week prior. Considering how short the proposal was there, it is not surprising that the idea was not well-noticed. While having these be separate PipeProjects still has merit, I added an option for just the template. I definitely would not be opposed to having this be covered in your PipeProject. --Illuminoid (talk) 12:04, June 6, 2026 (UTC)

For those opposed to creating a PipeProject specifically to implement this template, do you support the template's creation? B700465189a9 (talk) 04:48, June 6, 2026 (UTC)

Admittedly, a lot of the technical on that template flew over our head, but that's mostly because we don't know much about modules or JSON--for as many weird, old, sometimes proprietary codes we can read, we only barely know Lua. For clarity's sake, and if you can explain it to us on layman's terms, was the table over at Iggy's Showdown!#Enemies created using the module, or the template? ~Camwoodstock ( talk ☯ contribs ) 06:23, June 6, 2026 (UTC)

The idea behind the template is fine. But as the end of my vote points out, corner cases lurk around every... corner. They need to be handled, or the template will become a roadblock in the future. Aside from my stated issue with the inaccuracies created by assigning counts to course spanning liquids, there's also a problem with unnamed behavior variants. The obvious example is another Yoshi enemy, Ukiki. Most of them are normal, some of them drop bombs, some of them spit watermelon seeds, and none are differentiated by name except for in the old Super Mario World 2: Yoshi's Island Player's Guide. And as a wiki, we decided somewhere down the line to not follow those splits. Should these kinds of variants get separate rows, or do they have to share one row? If the former, what are we going to call the rows for the unnamed variants? If the latter, how do we indicate the number of the variation in behavior? (We probably can't do the latter, as it breaks the "Total" row something fierce, but maybe the "Total" row is superfluous enough to cut in order to neatly handle unnamed variants. For another Yoshi example, Watermelon vs "Watermelon with a bite taken out of it". (In Yoshi's Woolly World, I recall the latter having less seeds in them. Really, I think a wiki wide template might end up trapping us in a corner due to different games having different corner cases which may or may not call for different resolutions, and we might be better off with wiki-wide guidelines and being allowed to make as many templates as we need to best handle the scenarios that rise. Salmancer (talk) 06:30, June 6, 2026 (UTC)

@Camwoodstock The table there was created using a different module that was not run here. I wrote a modified version that will be used for the new template. The template will function similar to {{SMO Power Moons}}, {{foreign names}}, or {{MKWorld missions}}, where the module is the template's code. --Illuminoid (talk) 12:04, June 6, 2026 (UTC)

@Salmancer The point of the PipeProject is to determine how to handle that stuff. Maybe PipeProject:Music will run into a classification hurdle. If something breaks the total row, the total row can be removed. --Illuminoid (talk) 12:04, June 6, 2026 (UTC)

@Yoshi18 I don't think the topic for a PipeProject being "too broad" is much of a good argument against it (in fact, if I'm reading this correctly, Camwoodstock want this topic as part of their drafted PipeProject about improving the wikitables in general, an even broader topic). Music is a pretty broad topic too, after all. I think the argument would have more validity if the topics covered were all completely different, but that's not the case, either. rend (talk) (edits) 07:13, June 6, 2026 (UTC)

Mmm, yeah you got a point there. I guess I just kind of misunderstood the proposal. Yoshi18 (talk/contribs) 13:26, June 6, 2026 (UTC)

@Camwoodstock @Yoshi18 Your issues with this appear to be entirely based on the PipeProject. I absolutely understand your criticisms here. However, you have made no arguments as for why creating a template as a simpler method to create the lists is something that should not be done. --Illuminoid (talk) 19:48, June 8, 2026 (UTC)

We kind of just don't like the form factor of the template, admittedly. {{media table}} does something similar with having you specify numbers to sort the rows of stuff, and we've always had an (admittedly petty) distaste for it. And unlike media table, there's no unique formatting to it for the rows themselves, so like, at that point... Just write a standard wikitable. It's cleaner on the syntax side of things, and it's easier to understand. ~Camwoodstock ( talk ☯ contribs ) 02:03, June 9, 2026 (UTC)

@Mario Using tables for such lists is mandatory. --Illuminoid (talk) 23:41, June 8, 2026 (UTC)

It might be but I still advise against this, even if people don't agree, because it's an unnecessary barrier of entry to expanding the pages. I highly recommend keeping your code as simple as possible, and if it's feasible to accomplish the same task with less code, you should go for less code.

Compare these two

{|class="wikitable sortable" style="text-align:center;border-collapse:separate"
!class=unsortable|Image
!Name
!Count
|-
|[[File:YNI Fly Guy.png]]
|[[Fly Guy]]
|3
|-
|[[File:YNI Gusty.png]]
|[[Gusty]]
|2
|}

<gallery>
File:YNI Fly Guy.png|Fly Guy (3)
File:YNI Gusty.png|Gusty (2)
</gallery>

These two code blocks accomplish practically the same thing. But you should go for the second one for being a lot more straightforward and you don't need to memorize or go through copying and pasting CSS blocks just to make a table display consistently. It's me, Mario! (Talk / Stalk) 23:57, June 8, 2026 (UTC)

What about {{Foreign names}}? Should that not use a table? Should that even be a template? The proposed template's syntax for the example given is not that complex:

{{Entity list
|entity1=Fly Guy
|count1=3
|entity2=Gust
|count2=2
}}

While it is more complex than the gallery, it has the advantages of a template. The issue without using a template is the lack of standardization. If galleries—or another format—do become the new standard, having a template would mean just updating the module and possibly running PorpleBot to remove unnecessary parameters. --Illuminoid (talk) 00:24, June 9, 2026 (UTC)

Foreign names use a table because tables accomplish their task at organizing blocks of information in a tabular format (especially useful for arrays of information that foreign names are), easily readable by columns and and rows. What these enemy counts are, are closer to lists, could be organized into a list without compromising readability and do not benefit from tabular format. As for the "standardization" argument, there's nothing inherent about the code block that would prevent it from being standardized. I still do not see the benefit of using a module (or trying to enforce a standard) into what amounts to adding a number next to an enemy's name. It's me, Mario! (Talk / Stalk) 00:33, June 9, 2026 (UTC)

Notes, alternative counts, images, and extras also comprise enemy counts, so it amounting to just a name and count is absolutely wrong. --Illuminoid (talk) 01:39, June 9, 2026 (UTC)

Yeah some games have differences in how they handle enemies. This doesn't mean you enforce a blanket standard for all these games as if they're designed the same way, especially if the standard is worse than the previous one in many cases? Refer to my example earlier. It's me, Mario! (Talk / Stalk) 03:32, June 10, 2026 (UTC)

We're gonna be honest here, the idea of conveying some enemy lists via gallery is... An idea that sounds good until you remember that some of these come with "Notes" columns, or don't have clean-cut totals in the first place. The mere existence of Donkey Kong 3: Dai Gyakushū alone kind of kills the idea of "we should replace all enemy lists with galleries and just merge the totals to that!" stone-cold dead in our eyes. Like... All? Even for the game where every level features an enemy that serves as a glorified second hit for another enemy, yet now can't share a row with it? The game where first ten levels would have to have a gallery item that has to spend time explaining it's infinite, but only after stage (20 + level count)? Sure, that's an extreme case of "oops! all edge-cases!", but like. It's not really too hard to find instances where a gallery would, in fact, be sub-optimal for this. ~Camwoodstock ( talk ☯ contribs ) 02:03, June 9, 2026 (UTC)

If that's the case, then make a table if you need to. There's no rule against it. You don't need to create a standard to do this. But why enforce this same rule across all games? Just because a table works better for these two games (although I think the Captain Toad example is still pretty dubious) doesn't mean the rest of the games require tables. It's me, Mario! (Talk / Stalk) 03:24, June 10, 2026 (UTC)

Settle how to convey shared names across dialects in "Names in other languages" tables

List shared names twice 10-3-0
Works in the Super Mario franchise are localized into a lot of languages. Some of those languages, such as Spanish, French or Portuguese, have major differences between dialects that warrant the creation of separate versions for their respective markets. Because of these different versions, the names of subjects such as characters, items and levels may vary between region, even if they are both Spanish or French names. As I am a Spanish speaker, I will use Spanish as my main example throughout this proposal, but rest assured that anything outlined here will also apply to French, Portuguese, Serbo-Croatian, and any future dialect variations we add.

Take for example, Mario Kart World's Cute Scoot, which is named "Cuquimoto" in European Spanish, but "Motoneta Coqueta" in Latin American Spanish. This situation is well-trodden ground, and our {{Foreign names}} template gives the option of treating "Spanish (Latin American)" and "Spanish (European)" as if they were separate languages, allowing us to list the names separately. Conversely, not every work has separate localizations for each region, instead producing a single region-agnostic "Spanish" version for both. The template, in turn, also has the option of listing names merely under "Spanish", to properly reflect the source material.

The issue comes, however, in an edge case that has been treated inconsistently. For work that have separate dialect versions, what do we do if a subject has the same name in both of them? The two most common options here are:

• List the name twice, once under "Spanish (Latin American)" and once under "Spanish (European)";
• List the name once under "Spanish" (Mach Rocket).

While this proposal merely intends to raise a vote to select one option over the other as our new standard, I would like to go ahead and express my reasons for preferring the first option:

Under the second standard, there are three possible cases it could be representing:

1. The name hails from a work that does not have separate Latin American and European Spanish versions;
2. The name hails from a work that does have separate Latin American and European Spanish versions, but the name is shared between them;
3. The name hails from a work that does have separate Latin American and European Spanish versions, and the editor who added it neglected to clarify which version they took it from, perhaps under the assumption that both versions only have minor formatting differences, and the names are all the same.

I, as a reader, have no way of knowing which of the three cases I am looking at when reading the table. While listing the same name twice might be a tad clunky, it is unambiguous, and I would rather choose "clunky but clear" over "smooth yet ambiguous". We are a wiki, after all, and our purpose is to convey information, not to look pretty.

If this proposal passes, the winning option will be codified in the documentation for {{Foreign names}}, along with an explanation of why the choice was made.

Proposer: EvieMaybe (talk)
Deadline: June 21, 2026, 23:59 (UTC)

List shared names twice

1. EvieMaybe (talk) Per EvieMaybe.
2. Mario4Ever (talk) "Clunky but clear" works for me.
3. Illuminoid (talk) By wiki classification, dialects are essentially different languages. In the situation where both dialects share a single name, it seems logical to use rowspans to convey that.
4. Mr. Sorbetti (talk) yeah, please.
5. PopitTart (talk) It would be ridiculous to put Mario's foreign language names under one big "Latin script" box just because they're written the same way. The same stands to reason here.
6. Hewer (talk) More clarity.
7. Maw-Ray Master (talk) Per all.
8. LadySophie17 (talk) Per Evie.
9. Yoshi18 (talk) Per all.
10. The Eggo55 (talk) Per all. While I do prefer having them look clean and concise whenever possible, I have had multiple times where a game listed a simple "Spanish" name, only for me later to find out that it's specifically from the European dialect and said game never received a Latin American locale, or it did have one and the LatAM name was never even documented!

List shared names once

1. SuperGamer18 (talk) Call me crazy, but in order to verify whether a name is the same between dialects, I'd say it's as simple as providing one source per dialect, or, in cases like the aforementioned Mach Rocket, one source with different available languages. Where's the crazy part, you may ask? The way I'd handle the third case would be 1) adding a todo in the naming section asking whether the names are truly the same in both dialects and wait for someone to confirm or deny it or 2) verify that yourself and if applicable, add the missing source.
2. PaperSplash (talk) Per SuperGamer18.
3. PhGuy12 (talk) Per SuperGamer18. Since references are required for each name listed, it would be enough to add two references for the same name - each specifying the dialect (e.g.Taggit, whose Spanish name is the same in both regions).

Comments (Simplified)

What would someone do if they didn't know what dialect a name came from, or whether the game had differences in dialects between regions (i.e. a separate American and British English translation)? Scrooge200 (talk) 09:47, June 12, 2026 (UTC)

They'd check? Hewer (talk · contributions · edit count) 11:46, June 13, 2026 (UTC)

Being rude and sarcastic isn't an answer. Scrooge200 (talk) 22:14, June 15, 2026 (UTC)

My reply was not intended to be either of those things, it was a genuine answer. Sorry if the tone was unclear, I probably shouldn't have included the question mark (it was supposed to indicate my confusion at the question in case I'd misunderstood it). Hewer (talk · contributions · edit count) 22:50, June 15, 2026 (UTC)

I should probably elaborate on my original scenario, too. It can be hard to tell which dialect of a language a game uses, especially if you can't find footage of the other version. Dream Team doesn't have any online footage of its Canadian French translation. My copy of Color Splash only had American dialects of English, Spanish, and French, so I didn't know if the European versions had the same names. A lot of the times regional differences can be undocumented too, Super Paper Mario, Sticker Star, and the 3DS Mario & Luigis had a ton that I actually had to dig up myself. Things like the Mini Pi'illoid X situation. Scrooge200 (talk) 23:08, June 15, 2026 (UTC)

i have to say that i agree with Hewer here. verifying exactly what version a name comes from should be required to submit it to the wiki. — eviemaybe (talk) 23:59, June 15, 2026 (UTC)

The question here is if you know what one version says but do not know if the other version shares it. I presume one would simply write down that it was in that version and leave it to someone who can check the other one to determine what the other one says? Doc von Schmeltwick (talk) 12:33, June 16, 2026 (UTC)

Assuming Option A goes through, how would we handle scenarios where only a single Spanish/French/etc. name is listed? Would it be best to assume that it's defaulted to the European dialect- as it's more likely to be from that one specifically due to there being a period of time where Europe recieved Spanish localizations while the Americas did not (namely the mid-late Game Boy Advance/GameCube/Nintendo DS era: such as Mario & Luigi: Superstar Saga, Mario Kart: Double Dash!!, or Super Mario 64 DS) while adding a notice to request someone to check, or just the notice and keep the singular entries as-is? --The Eggo55 (talk) 02:30, June 16, 2026 (UTC)

this proposal is just for selecting a standard, not for organizing an endeavor to change things. if you see a sourced-yet-unspecified name in a NIOL table, you can just change it, the same way we've been changing definitions formatted as ["foreign word" (meaning)] to [foreign word ("meaning")]. — eviemaybe (talk) 18:59, June 16, 2026 (UTC)

Overturn the "Game Scripts" format proposal

overturn 10-0
The following proposal concerns this proposal from September 21st, 2025. The proposal was created to change the format of media-specific "List of quotes" pages to take the form of transcripts. Since then, after almost 9 months... Uh, literally only one page of progress has been made for implementing this? ...at all? And it's the one that was given as an example in the proposal itself.

Admittedly, it isn't remotely hard to see why; this is a huge change to make! However, additional problems have sprung up since the proposal that makes implementing it even more difficult. Since then, we have implemented a "Not an archive" policy against excessive over-documentation of things that are either better suited for another kind of database, are self-evident from the media itself, are overall insignificant to illustrating a given work, or some combination therein. A full transcript of every last action and every last line of dialogue would, indeed, be a bit excessive. The proposal is a PipeProject-scale endeavor that is presently entirely without a PipeProject, and one of those would likely have to be created with yet another proposal (as, right now, nobody is around to spearhead said operation.)

The smoking gun, however, we feel, comes in the form of, of all things, the List of The Super Mario Galaxy Movie quotes page. That page features two sections, one for individual character quotes (much like the current format), and a second section for "Dialogue", which are transcripts of significant exchanges between characters that would otherwise be difficult to illustrate as individual quotes. This more-or-less solves the same problem the "game scripts" format does, but also entirely avoids each of its caveats; it allows for individualized exchanges to be present when it illustrates a quote better, while not requiring excessive information on the part of the userbase, nor a concerted effort that the userbase is presently uninterested in. Quite literally, it is the best of both worlds.

So... If game script pages are largely obsoleted by both changes to policy, and to developments to quote pages themselves that have happened more-or-less organically... Why should we continue listing this as a proposal to be implemented, when, evidently, nobody actually wants to do that? This proposal is more-or-less just us asking if we actually want to still do this or not.

If we overturn the game scripts proposal, what will happen in practice is relatively straightforward. Hotel Mario script gets merged to List of Hotel Mario quotes as a "Dialogue" section, and we consider the "Dialogue" format to be a valid format on the quotes pages from now on. Should the proposal resolve in the favor of the technical status quo, and we decide to continue with the game script format, we would like to state in advance: we do not wish to, nor intend to, claim responsibility for implementing Game Script pages. We have enough to do ourselves that we cannot take this task on ourselves. This proposal is to re-affirm if this is something we actually want to do, not for us to add onto it in some way.

Proposer: Camwoodstock (talk)
Deadline: July 2, 2026, 23:59 (UTC) Closed early on June 25, 2026, 23:59 (UTC)

Overturn the Game Scripts proposal

1. Camwoodstock (talk) Per proposal.
2. Mario (talk) Even without the copyright concerns, I think it's a good thing there's one less obscure practically nonexistent proposal to keep track of when it comes to expanding pages on the wiki. Most people who edit these pages won't know this proposal existed to begin with. The quality of these quote pages are another matter, but it's clear the proposal didn't fix any of the issues.
3. Rykitu (talk) Per all. I forgot this proposal even existed!
4. Nelsonic (talk) I think this could've helped at one point, but it isn't helping much in its current state. Per.
5. List of Maw-Ray Master quotes (talk) Per all.
6. Dive Rocket Launcher (talk) Per all. Though I do think there should be guidelines about what dialogue is significant enough. I'm mainly concerned about RPGs, since even optional conversations in those can be good demonstrations of character personalities and relationships.
7. LadySophie17 (talk) Per proposal. I was not aware of this "Dialogue" section and I feel like it perfectly fixes most of the issues I have with our current quote pages. I am fully in favor of expanding their use to games!
8. Yoshi18 (talk) Per all.
9. EvieMaybe (talk) Per all.
10. I... am R.O.B. (talk) sure.

Comments (EXIT, PURSUED BY BEAR)

By the way (and not that it changes much), the "Dialogue format" was already in use on quotes pages for films since 2023, long before that proposal, as seen here and here. Though I think using it on game quotes pages might be a new idea (and one I support, since it can help to convey the dialogue better than just a list of lines removed from their context). Hewer (talk · contributions · edit count) 14:29, June 18, 2026 (UTC)

I'll add to this even further: dialogues have been featured alongside quotes as early as 2007, as evidenced by this revision on the Cranky Kong page, which remained there until these and other Cranky quotes were split off into its own page since 2014, and are still listed there to this very day. Unsurprisingly, these dialogues are from the cartoon series, which are also dialogue-heavy. rend (talk) (edits) 05:16, June 22, 2026 (UTC)

Create a "NIOL missing" template

do not create template 2-6
I've already been thinking about this for a while, but why has the wiki never had a template for missing NIOLs? When {{todo}} got added, I thought that could solve the problem, but as some have pointed out: that template doesn't really fit for {{todo}}s. If we're gonna tag every article with missing NIOLs as {{todo|section=yes|list=*More languages}}, then half of the articles that use {{todo}} would just be that. That's why I think a NIOL template would be a useful addition. I even made a test template for it (with the source code already built in) to show off my vision here:

This article does not yet have a "Names in other languages" section.

Please help improve this article by adding a "Names in other languages" section with at least one or more of the missing languages with citations from reliable sources.

In case anyone is wondering, I made this test template using {{unreferenced}} as basis, edited it, and mixed it with the "list" parameter from {{todo}} so users have the ability to display exactly which languages are missing. Also, a citation for the name is of course mandatory.

Footnote

Proposer: Yoshi18 (talk)
Deadline: June 26, 2026, 23:59 (UTC)

Support in other languages

1. Yoshi18 (talk) Per proposal.
2. PaperSplash (talk) I'm willing to support this after the updates made to the proposed template.

Oppose in other languages

1. Camwoodstock (talk) We're primarily an English wiki, for one thing, so while foreign language names are nice to have, we don't personally view them as being necessary... In addition to that, sometimes, those foreign languages just have the same name as English which we don't track (hi, Diddy Kong Racing DS), and sometimes, there just. Aren't foreign language names, for one reason or another. Above all else, we're a little worried this will get mis-used a lot to basically mean "I'm curious what this is called in another language!" and not the actual use-case of "we know there is a foreign language version of this thing, but we don't know what it's called in that thing", and there isn't really anything to actively dis-incentivize that.
2. LadySophie17 (talk) Per Camwoodstock. I am strongly against the inclusion of NIOLs in the to-do system, and if there were an option to outright ban that practice I'd whole-heartedly support it. But if you simply must start tagging every article under the sun with this new template, it should at the very least have very clear and strict requirements, which this proposal does not. it should be a non-negotiable requirement that the editor who placed the template must give exactly which languages they want names added from, and where said names can be found. "Add more names from other languages" is not good enough, "Add French and Dutch names" is not good enough either. "Add French name used in the Super Mario Odyssey French strategy guide, and the Dutch name used in the Dutch localization for Super Mario Run" sounds about good enough for me. To put it simply, if you cannot prove a name for that language exists in the first place, don't ask for it.
3. EvieMaybe (talk) per Camwoodstock and Sophie.
4. Wandering Poplin (talk) Per all.
5. Mario4Ever (talk) I feel like anyone who's aware that NIOLs exist for a game is better off just adding them to the extent they're able rather than applying a template in the hope someone else comes along. If the existence of NIOLs is not apparent, I don't believe a specialized template would incentivize people to check, not to mention that factors beyond their familiarity with a language itself could prevent them from doing so in the first place.
6. I, Robot (2004 film) Per Camwoodstock.

Comments in other languages

Where does this template get placed on an article? Some articles contain multiple names in other languages sections. Also, you forgot to modify the text for hide parameter taken from {{todo}}. I am against category titles using the abbreviation. While "NiOL" is quick to type, the full form communicates the purpose better. --Illuminoid (talk) 00:11, June 13, 2026 (UTC)

Changed the category so it would no longer be an abbreviation. I think this template should be placed in a NIOL section or at the top of the article (if the article doesn't yet have a NIOL section but does need one). Yoshi18 (talk/contribs) 12:10, June 13, 2026 (UTC)

@Camwoodstock, I get that this may not be useful for game articles but what about things like minigame articles? The minigame articles for Super Mario Party Jamboree – Nintendo Switch 2 Edition + Jamboree TV could definitely use this template. Yoshi18 (talk/contribs) 12:10, June 13, 2026 (UTC)

@LadySophie17, That's a good point (I probably forgot to add that into my proposal, but having good proof of a language that needs to be added is of course mandatory and I gotta admit it was kinda dumb to forget to add that). Though I think you can already know if a name for, say, minigames exist by looking at the languages a game (I'm taking Super Mario Party Jamboree as example here because its Switch 2 Edition minigames miss a lot of languages) available on. Also, just wondering but: imagine if I went to the Nintendo Switch 2 Experience (I actually did in real life, that's where I got the Dutch name of some of Jamboree TV's minigames from (I wrote them up in my Notes app so I wouldn't forget to add them to the wiki some day)) and saw the Dutch names of some minigames but forgot about some of them (I actually did with some like Toad-ally Electric Escape). How (or where) could I find solid proof that these names do exist (if there's for example no video of it on YouTube and Nintendo (of the Netherlands) doesn't list it anywhere)? Yoshi18 (talk/contribs) 14:00, June 14, 2026 (UTC)

@Yoshi18 It's not too late for you to rewrite this proposal if you wish to. I actually agree with the underlying idea, but Sophie does make some counterpoints I think are valid as well, and I would be more comfortable supporting this proposal if they were addressed. In addition, I personally think "please improve this by adding at least one language" is the wrong message we should be sending. While I believe I understand the idea behind it (even one additional language would indeed go a long way, and a lot of people have knowledge of only one language at most besides English, after all) it comes off more like giving out an arbitrary quota for names in other languages rather than actually acknowledging the names in other languages that are missing. Of course, this wouldn't be as much of an issue if the actual missing language names were required to be disclosed (preferably along with where they can be found) as you've discussed with Sophie. PaperSplash (talk) 18:30, June 14, 2026 (UTC)

Just wondering but what would you think would be a better message? I thought of something like "adding and sourcing [insert language]" or if there's two "adding and sourcing [insert language], [insert another language] and [insert another language]" (of course with "and" between the first and second language if there's only two). Yoshi18 (talk/contribs) 21:48, June 14, 2026 (UTC)

@Yoshi18 I think just "adding the missing languages" is actually fine as long as the languages themselves are specified somewhere (this is what Bulbapedia's existing template for this does, at least). And I agree that mentioning something about sourcing the missing names would go a long way in discouraging people from just adding unsourced NIOLs. Maybe you could borrow further from {{unreferenced}} and just say "with citations from reliable sources"? As for when a NIOL section is missing entirely, perhaps it could say "adding a "Names in other languages" section with one or more of the missing languages" (the key word here is "missing", I think, and the missing languages in question should again be specified), and again, you could put "with citations from reliable sources" after that? PaperSplash (talk) 05:53, June 15, 2026 (UTC)

To the opposition (@Camwoodstock, @LadySophie17, @EvieMaybe and @Wandering Poplin) and @PaperSplash, I updated the template (sorry I didn't do it sooner, I've been very busy the past couple of days). The small template note now notes that you need to have a reliable source to add missing languages. Though I still wonder if "in-game name" counts as this when there is no other source than just looking at it in the game itself. Yoshi18 (talk/contribs) 22:28, June 17, 2026 (UTC)

I honestly still don't get the dislike of a NIOL template. Mainly for articles that only have like 2 of the 12 available languages in their NIOL section. I know we're an English wiki and shouldn’t really care that much about other languages (even though the Manual of Style says otherwise) but I mean; the least we could do is at least completing as much articles as we can with complete NIOL sections. Yoshi18 (talk/contribs) 14:23, June 25, 2026 (UTC)

Treat series and franchise names with no source for the name as conjectural

treat as conjectural 6-0
For context, almost every page on the wiki whose title is extrapolated (like Craw) or derived from established naming conventions, rather than being explicitly stated, is treated as conjectural. This holds true even cases where the title is following a very simple and obvious naming convention and the lack of an official name seems to be the result of a simple editing error. Series and franchise names are an odd exception to this. The titles of many of the series pages on this wiki seem to be extrapolated from the games having some shared text (Famicom Grand Prix is derived from Famicom Grand Prix: F1 Race and Famicom Grand Prix II: 3D Hot Rally, for example), but that doesn't make those official names per se. Keep in mind that titles in the same series don't always incorporate the series' name (see Nintendo treating Golf: Japan Course, Golf: US Course, and NES Open Tournament Golf as part of the Mario Golf series), and games can incorporate the name of a series in their title despite generally being excluded from it by official sources (see Wario Land: Super Mario Land 3 and Super Mario World 2: Yoshi's Island).

The most egregious examples of extrapolated names are "Super Mario Stadium", which is derived from the Japanese names of Mario Superstar Baseball and Mario Super Sluggers due to their English names not sharing anything other than "Mario" and "Super"; and "DK (series)", which is extrapolated from both games being titled "DK: [something]" in American English specifically (DK: Jungle Climber is called "Donkey Kong: Jungle Climber" in European English). Honestly, I wouldn't mind if we stopped treating DK as a series and simply classified them as DKC spin-offs, since their status as a series is iffy at best, but that's a proposal for another day. If this proposal passes, any series and franchise pages that do not have a source for their title will be tagged as {{conjectural}}.

Proposer: Dive Rocket Launcher (talk)
Deadline: June 27, 2026, 23:59 (UTC)

Support (series)

1. Dive Rocket Launcher (talk) Per proposal.
2. Wilben (talk) I don't see why not.
3. Jdtendo (talk) Per proposal.
4. Polley001 (talk) Per proposal.
5. Yoshi18 (talk) I don't see why not either.
6. Robot toy for the first Nintendo... VCR player? (or game console? I don't know) Yeah. If the name isn't official, then the name isn't official.

Comments (series)

I'm pretty sure this isn't the correct usage of "derived", which is about combining bits of a name from different sources. "Conjectural" would be fine. Hewer (talk · contributions · edit count) 11:36, June 13, 2026 (UTC)

Fine. Dive Rocket Launcher 12:24, June 13, 2026 (UTC)

Create a PipeProject for foreign media and subjects

Create the PipeProject 9-0

The image that will be used to represent this PipeProject. (If you have a better one that could be used, please let me know!)

Can you believe this is the third PipeProject creation proposal already? Anyways, this is something I've been thinking about recently. As can be seen in various places, such as to-do lists, red links in nav/infoboxes, etc., I believe we have lackluster coverage of non-English media and subjects on this wiki, especially those that are only officially available in Japanese. What does this PipeProject entail? It includes, but is not limited to:

• Creating articles for media and subjects originating outside of English-speaking countries
• Improving articles about non-English media and subjects with improvement templates (eg {{todo}}, {{image}}, etc.)
• Translating non-English sources into English wherever needed
• Finding non-English sources for articles that need them

Relevant guidelines and other pages

• MarioWiki:Article naming (English and non-English sources section)
• MarioWiki:Japanese
• MarioWiki:Manual of Style (Romanization systems section)
• MarioWiki:Lists of citations (courtesy of Nintendo101)

COVERAGE CLARIFICATIONS: if a piece of media was originally released in a language other than English and then gets an English translation after its original release, it does NOT disqualify it from this PipeProject. However, if the English translation of such media appears before or at the same time as the original, non-English version, then it will not be counted for this PipeProject. Obviously, translations of English media into non-English languages are also out of scope, unless they have significant differences in content. Due to controversies regarding this aspect of coverage, Names in other languages are not in scope for this PipeProject.

With that clarified, I believe this PipeProject will encourage people to cover and improve coverage of international Super Mario media, showing the worldwide nature of its appeal. And finally, here's a list of people who I think can help me with this project (if you would like to contribute to this PipeProject, you are more than welcome to do so!):

• @Mariuigi Khed (manga and Italian media/subjects coverage)
• @EvieMaybe (Spanish media coverage)
• @Mosgis (Japanese media translaton)
• @Maw-Ray Master (obscure non-English media coverage)

Proposer: SuperGamer18 (talk)
Deadline: July 5, 2026, 23:59 (UTC) Closed early on June 28, 2026, 23:59 (UTC)

Support: create the PipeProject

1. SuperGamer18 (talk) Per proposal.
2. Yoshi18 (talk) I guess that, with my NIOL template proposal, I'm already kind of supporting this PipeProject. I also do my best with adding or correcting Dutch translations on the wiki, so I'm all in for a PipeProject like this!
3. Camwoodstock (talk) This one, we can get behind. While we don't particularly care as much for Names in Other Languages, documenting the stuff that's exclusive to those Other Languages (even stuff just like the various Manga) is something far more pressing, and also far more deserving of a concerted effort. We figure this aligns with our plans to some day help give the rest of the Japanese home computer games the same treatment we've given Super Mario Bros. Special and Donkey Kong 3: Dai Gyakushū, too. No promises we'll be too active, but pencil us in for keeping tabs on this thing until we can finally swing around to Punch Ball Mario Bros.!
4. Maw-Ray Master (talk) Per all. I do think English media translated into non-English languages should be included if the translation contains things that are not present in the original version, such as the Korean dub of The Super Mario Bros. Super Show! replacing the original live-action segments with locally-produced segments and airings of the Danish dub of The Adventures of Super Mario Bros. 3 featuring live-action segments reminiscent of that of The Super Mario Bros. Super Show!. I don't think translations of games should be included the PipeProject, primarily due to them largely being the same across different languages.
5. Wilben (talk) Per all.
6. 初音ミク (talk) Also Per Proposal.
7. I... am R.O.B. (talk) Per proposal.
8. نيلسونيك (talk) 제안에 따름.
9. Rykitu (talk) Per proposal. I plan to be more active in this subject on the wiki once I'm finished with TPNS coverage, so maybe I could join this too.

International comments

I think English media translated into non-English languages should be included if the translation contains signifcant differences from the original version, such as the Korean dub of The Super Mario Bros. Super Show! replacing the original live-action segments with locally-produced segments and airings of the Danish dub of The Adventures of Super Mario Bros. 3 featuring live-action segments reminiscent of that of The Super Mario Bros. Super Show!. I don't think translations of English media such as games should be included the PipeProject, primarily due to them largely being the same across different languages.

Something else that should be included in the PipeProject are people and companies associated with creating the non-English media, such as Kazuki Motoyama (who wrote and illustrated Kodansha's Super Mario manga) and Atlantic Förlags AB (known for publishing the Nintendo-Magasinet, one of Nintendo's official magazines in Denmark, Norway, and Sweden). Many people and companies associated with creating this media lack articles, and it would be appreciated if articles were written for them. Maw-Ray Master (talk) 23:57, June 21, 2026 (UTC)

Regarding your first concern, I hadn't considered such cases since they were very rare. But yeah, those examples you mentioned should feel right at home with my intended scope.

As for your other concern, things like those are why I put both "media" and "subjects" as opposed to just the former. Those examples are also absolutely within the scope of this PipeProject. SuperGamer18 (talk) 00:23, June 22, 2026 (UTC)