Super Mario Wiki

MarioWiki:Proposals

Project page Discussion
(Redirected from MarioWiki:Proposal)
Image used as a banner for the proposals page
Current time:
Saturday, September 20th, 00:39 GMT
Proposals can be new features, the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken.
  • Voting periods last for two weeks, but can close early or be extended (see below).
  • Any autoconfirmed user can support or oppose, but must have a strong reason for doing so.
  • All proposals must be approved by a majority of voters, including proposals with more than two options.
  • For past proposals, see the proposal archive and the talk page proposal archive.

If you would like to get feedback on an idea before formally proposing it here, you may do so on the proposals talk. For talk page proposals, you can discuss the changes on the talk page itself before creating the TPP there.

How to

If someone has an idea about improving the wiki or managing its community, but feel that they need community approval before acting upon that idea, they may make a proposal about it. They must have a strong argument supporting their idea and be willing to discuss it in detail with other users, who will then vote on whether or not they think the idea should be implemented. Proposals should include links to all relevant pages and writing guidelines. Proposals must include a link to the draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.

Rules

  1. Only autoconfirmed users may create or vote on proposals. Proposals can be created by one user or co-authored by two users.
  2. A given user may author/co-author a maximum of five total ongoing/unimplemented proposals. Any new proposals over this limit will be immediately canceled.
  3. Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).
  4. Proposals conclude at the end of the day (23:59) two weeks after voting starts (all times GMT).
    • For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is two weeks later on Monday, August 15, at 23:59 GMT.
  5. Users may vote for more than one option, but they may not vote for every option available. Keep in mind that we use approval voting, so all of your votes count equally regardless of preferred order.
  6. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is acceptable (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
  7. Users who feel that certain votes were cast in bad faith or which truly have no merit can address the votes in the comments section. Users can ask a voter to clarify their position, point out mistakes or flaws in their arguments, or call for the outright removal of the vote if it lacks sufficient reasoning. Users may not remove or alter the content of anyone else's votes. Voters can remove or rewrite their own vote(s) at any time, but the final decision to remove another user's vote lies solely with the wiki staff.
    • Users can also use the comments section to bring up any concerns or mistakes in regards to the proposal itself. In such cases, it's important the proposer addresses any concerns raised as soon as possible. Even if the supporting side might be winning by a wide margin, that should be no reason for such questions to be left unanswered. They may point out any missing details that might have been overlooked by the proposer, so it's a good idea as the proposer to check them frequently to achieve the most accurate outcome possible.
  8. If a user makes a vote and is subsequently blocked for any amount of time, their vote is removed. However, if the block ends before the proposal ends, then the user in question holds the right to re-cast their vote. If a proposer is blocked, their vote is removed and "(blocked)" is added next to their name in the "Proposer:" line of the proposal, which runs until its deadline as normal. If the proposal passes, it falls to the supporters of the idea to enact any changes in a timely manner.
  9. Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
  10. If one week before a proposal's initial deadline, the first place option is ahead of the second place option by eight or more votes and the first place option has at least 80% approval, then the proposal concludes early. Wiki staff may tag a proposal with "Do not close early" at any time to prevent an early close, if needed.
    • Tag the proposal with {{early notice}} if it is on track for an early close. Use {{proposal check|early=yes}} to perform the check.
  11. Any proposal where none of the options have at least four votes will be extended for another week. If after three extensions, no options have at least four votes, the proposal will be listed as "NO QUORUM." The original proposer then has the option to relist said proposal to generate more discussion.
  12. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
  13. If a proposal reaches its deadline and the first place option is ahead of the second place option by three or more votes, then the first place option must have over 50% approval to win. If the margin is only one or two votes, then the first place option must have at least 60% approval to win. If the required approval threshold is not met, then the proposal is extended for another week.
    • Use {{proposal check}} to automate this calculation; see the template page for usage instructions and examples.
  14. Proposals can be extended a maximum of three times. If a consensus has not been reached by the fourth deadline, then the proposal fails and cannot be re-proposed until at least four weeks after the last deadline.
  15. All proposals are archived. The original proposer must take action accordingly if the outcome of the proposal dictates it. If it requires the help of an administrator, the proposer can ask for that help.
  16. After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
  17. For sizeable projects, a proposal author or wiki staff member may create a PipeProject page to serve as a portal for an unimplemented proposal. This is linked from the unimplemented proposals list and can contain progress tracking, implementation guidelines, resource links, a list of users working on the project, etc.
  18. If the wiki staff deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to cancel it at any time.
  19. Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. However, proposers can request that their proposal be canceled by a staff member at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
  20. Unless there is major disagreement about whether certain content should be included, there should not be proposals about creating, expanding, rewriting, or otherwise fixing up pages. To organize efforts about improving articles on neglected or completely missing subjects, try setting up a collaboration thread on the forums.
  21. Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and handled by the bureaucrats.
  22. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
  23. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal formatting

Copy and paste the formatting below to get started; your username and the proposal deadline will automatically be substituted when you save the page. Update the bracketed variables with actual information, and be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but the objective(s) of each voting option must be clearly defined. Such options should also be kept to a minimum, and if something comes up in the comments, the proposal can be amended as necessary. 

===[insert a title for your proposal here]===
[describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]

'''Proposer''': {{User|{{subst:REVISIONUSER}}}}<br>
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 GMT

====[option title (e.g. Support, Option 1)]: [brief summary of option]====
#{{User|{{subst:REVISIONUSER}}}} Per proposal.

====[option title (e.g. Oppose, Option 2)]: [brief summary of option]====

====Comments ([brief proposal title])====

Autoconfirmed users will now be able to vote on your proposal. Remember that you can vote on your own proposal just like the others.

To vote for an option, just insert #{{User|[your username here]}} at the bottom of the section of your choice. Just don't forget to add a valid reason for your vote behind that tag if you are voting on another user's proposal. If you are voting on your own proposal, you can simply say "Per proposal."

Poll proposal formatting

As an alternative to the basic proposal format, users may choose to create a poll proposal when one larger issue can be broken down into multiple subissues that can be resolved independently of each other. Poll proposals concerning multiple pages must have good justification for using the poll proposal format rather than individual talk page proposals or else will be canceled (for example, in the case of the princesses poll proposal, there are valid consistency concerns which make it worthwhile to consider these three articles simultaneously, but for routine article size splits, there is no need to abandon using standard TPPs for each).

In a poll proposal, each option is essentially its own mini-proposal with a deadline and suboption headings. A poll proposal can have a maximum of 20 options, and the rules above apply to each option as if it were its own proposal: users may vote on any number of options they wish, and individual options may close early or be extended separately from the rest. If an option fails to achieve quorum or reach a consensus after three extensions, then the status quo wins for that option by default. If all options fail, then nothing will be done.

To create a poll proposal, copy and paste the formatting below to get started; your username and the option deadlines will automatically be substituted when you save the page. Update the bracketed variables with actual information, and be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]". 

===[insert a title for your proposal here]===
[describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]

'''Proposer''': {{User|{{subst:REVISIONUSER}}}}

====[option title (e.g. Option 1)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 GMT

;Support
#{{User|{{subst:REVISIONUSER}}}} Per proposal.

;Oppose

====[option title (e.g. Option 2)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 GMT

;Support
#{{User|{{subst:REVISIONUSER}}}} Per proposal.

;Oppose

====[option title (e.g. Option 3)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 GMT

;Support
#{{User|{{subst:REVISIONUSER}}}} Per proposal.

;Oppose

====Comments ([brief proposal title])====

For the purposes of the ongoing proposals list, a poll proposal's deadline is the latest deadline of any ongoing option(s). A poll proposal is archived after all of its options have settled, and it is listed as one single proposal in the archive. It is considered to have "passed" if one or more options were approved by voters (resulting in a change from the status quo), and it is considered to have "failed" if all options were rejected by voters and no change in the status quo was made.

Talk page proposals

Proposals concerning a single page or a limited group of pages are held on the most relevant talk page regarding the matter. All of the above proposal rules also apply to talk page proposals. Place {{TPP}} under the section's heading, and once the proposal is over, replace the template with {{settled TPP}}. Proposals dealing with a large amount of splits, merges, or deletions across the wiki should still be held on this page.

All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{ongoing TPP}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, the proposal author(s), and the deadline. If the proposal involves a page that is not yet made, use {{fake link}} to communicate its title in the description. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links.

List of ongoing talk page proposals

Deletions

None at the moment.

Moves

Merges

Splits

Miscellaneous

Unimplemented proposals

Proposals

Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024)
Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024)
Note: Not yet integrated for the Super Mario Maker titles and Super Mario Run.
Use the classic and classic link templates when discussing classic courses in Mario Kart Tour, YoYo (ended October 2, 2024)
Split major RPG appearances of recurring locations, EvieMaybe (ended December 16, 2024)
Split Mario & Luigi badges and remaining accessories, Camwoodstock (ended February 1, 2025)
Merge intro/outro sections, rename Gameplay section to "Overview" for Mario Party minigame articles, ToxBoxity64 (ended March 1, 2025)
Allow English Super Mario Bros. Encyclopedia names to be mentioned on articles where they are not the title, Hewer (ended March 27, 2025)
Split every song from the "List of (show) songs" articles, Kaptain Skurvy (ended May 31, 2025)
Overhaul sponsor pages, Seandwalsh (ended June 26, 2025)
Reorganize recurring theme articles to use history sections, Ahemtoday (ended July 2, 2025)
Stop linking to other wikis for the first usage of a title on an article, Kaptain Skurvy (ended July 12, 2025)
Decide how to handle images on Mario Party board pages, Altendo (ended July 24, 2025)
Permit creation of categories based on microgame themes, PawPatroler (ended August 3, 2025)
Revamp colorful tables, Camwoodstock (ended August 14, 2025)
Make articles for the licensed songs in The Super Mario Bros. Movie, Sargent Deez (ended September 17, 2025)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)
Note: Not yet split for Partners in Time, Bowser's Inside Story, Dream Team, Paper Jam, or Brothership
Split machine parts, Robo-Rabbit, and flag from Super Duel Mode, Doc von Schmeltwick (ended September 30, 2022)
Note: Missing Robo-Rabbit and flag articles.
Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)
Allow separate articles for Diddy Kong Pilot (2003)'s subjects, Doc von Schmeltwick (ended August 3, 2024)
Create articles for specified special buildings in Super Mario Run, Salmancer (ended November 15, 2024)
Give the Cluck-A-Pop Prizes articles, Camwoodstock (ended January 31, 2025)
Split the Animal Crossing series (now Crossovers with Animal Crossing), Kaptain Skurvy (ended February 12, 2025)
Split Super Luigi subjects into a dedicated list article (Draft page), EvieMaybe (ended April 3, 2025)
Restore general coverage for Pyramid, Doc von Schmeltwick (ended May 9, 2025)
Clean up Prohibited Command, PrincessPeachFan (ended May 13, 2025)
Split text changes in Paper Mario: The Thousand-Year Door (Nintendo Switch) (Draft page), Technetium (ended May 29, 2025)
Determine which subjects belong in Category:Aliens, Technetium (ended June 14, 2025)
Note: Not yet implemented for Super Mario Galaxy and Super Mario Galaxy 2 subjects.
Split A Magical Tour of Yoshi's Island from Super Mario World 2: Yoshi's Island, Rykitu (ended July 9, 2025)
Decide how to handle hammer-based moves in Category:Hammers, SolemnStormcloud (ended July 21, 2025)
Retire SSB fighter infobox, Salmancer (ended August 11, 2025)
Split Jed Junior from Cowboy Jed, Rykitu (ended August 20, 2025)
Delete Template:NSMBU challenge and instate template NSMBU challenge infobox, Salmancer (ended August 26, 2025)
Treat Pyoro as a series, janMisali (ended September 1, 2025)
Determine whether a Final Smash is one of a fighter's special moves, Salmancer (ended September 13, 2025)
Split the Shield Guy article, PrincessPeachFan (ended September 18, 2025)

Writing guidelines

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

Based on the vote so far, this proposal may be eligible to close one week early. Please use {{proposal check|early=yes}} on September 19, 2025 at 23:59 GMT and close the proposal if applicable.

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

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

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

Examples:

  • Print/promotional art (default backdrop)

  • In-game graphics (colored backdrop)

  • Screenshot (default backdrop)

  • Sprite/model (colored backdrop)

  • Sprite (colored backdrop)

  • In-game render (colored backdrop)

  • Model (colored backdrop)

  • Sprite (game with black backdrop; colored backdrop)

Proposer: Bro Hammer (talk)
Deadline: September 26, 2025, 23:59 GMT

Support: create a guideline for gallery backdrops

  1. Bro Hammer (talk) Per proposal.

Oppose: do not include guidelines for gallery background colors

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

Comments (Create a guideline for gallery backdrops)

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

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

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

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

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

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

This would ensure that it makes an image clearly visible in, say, Dark Mode, without it making it stand out in Light Mode (due to the image already being visible), and vice versa; and I think that whole "standing out" thing is how this proposal came into fruition into the first place, as Bro Hammer appears to be under the impression that bg colors are sometimes being used haphazardly, when most of the time, they're not.  rend (talk) (edits) 15:03, September 14, 2025 (EDT)
Out of curiosity, are there any specific use-cases you have in mind for the suggested lightmodebg over the pre-existing whitebg? Since, at least off the cuff, most of the use cases (read: most of what we're thinking of are Game Boy game sprites) would be largely redundant to just straight up white, and it's not like whitebg just fails to load based on light/dark modes.
(as an aside, we kinda wish we could indent galleries, it's making this a bit annoying to follow ^^;)  ~Camwoodstock ( talk ☯ contribs )   15:13, September 14, 2025 (EDT)
whitebg is slightly different, as it is PURE white (#FFF), whereas the lightmodebg (#f8f9fa) is not. And there have been artworks (and logos) that blend too much with the default darkmodebg.

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

  • But in dark mode, it's barely visible.

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

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

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

New features

Appearance lists for all mainline games

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

Dry Bones appear in nine levels:

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

Dry Bones appear in nine levels:

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

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

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

Support: Use Rework A

  1. Sargent Deez (talk) Per proposal

Support: Use Rework B

Oppose: Keep current format

Discussion

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

Removals

Delete Mario Party 7's minigame icons

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

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

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

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

Delete the icons

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

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

Place the icons in the pages

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

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

Keep them unused

Comments (Minigame icons)

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

That doesn't seem like the right thing to do, particularly for older games, given aspect ratio and resolution differences. Doc von Schmeltwick (talk) 10:52, September 8, 2025 (EDT)
The comparisons in the proposal show that the images are not identical. They feature different characters in different positions. Hewer (talk · contributions · edit count) 11:46, September 8, 2025 (EDT)
Is a different cast of interchangeable playable characters with different scores in different positions instrumental in documenting the general appearance of a minigame? Sure, you can argue that we should keep those images simply because they are frames of official assets, but arguing that they serve any purpose beyond archival for the sake of archival seems a bit farfetched to me. — Lady Sophie   (T|C) 11:56, September 8, 2025 (EDT)
I just don't really see why "archival for the sake of archival" has to be a problem, or why we have to deem some assets too unimportant to cover. Putting these images in a gallery section is potentially helpful to someone who wants to see what they look like, and not harmful to anyone else. Hewer (talk · contributions · edit count) 14:22, September 8, 2025 (EDT)

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

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

Technically:

  • Original art

  • Menu art

  • Website art

--Doc von Schmeltwick (talk)

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

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

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

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

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

Changes

Add an interwiki link to some Final Fantasy wiki

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

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

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

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

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

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

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

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

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

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

#GuntherBayBeee (talk) Per all.

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

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

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

Comments (which wiki is preferred and why?)

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

Oh I wasn't aware that said proposal happened. I jumped at making this one because I brought up this topic in the Discord and I was recommended to make a proposal about this, and the previous one wasn't pointed out to me, though still my bad for not checking. It may be that generally most users here aren't fully aware that that was settled? Still, I hold the notion that sometimes linking to Wikipedia instead of constantly the Fandom one is weird, but I guess that if one were to change all Wikipedia links no one would mind. And this proposal could be hold up if there was a big interest in making an interwiki link for the Fandom one, but again that may be unnecessary. If there isn't really any big sentiment about making some sort of decision here, and the general consensus is that everything should still be as it is, like that past proposal settled, then I guess this one could be cancelled. I will still keep it up for a little while more though, in case someone brings up something notable. - ARCBXY (talk) 17:13, August 29, 2025 (EDT)
A prior proposal can actually be overturned by another proposal if it has been more than 28 days after said prior proposal has ended, so a previous proposal's outcome is not eternal. We've had tons of succeeded and failed proposals in the past which outcome is no longer enforced due to other proposals' outcomes. If the SEIWA Final Fantasy Wiki has improved a lot since the last time a proposal brought it up, then it could be worth revisiting the subject.
Regarding to add an interwiki link for the Fandom-hosted wiki, however... that is not necessary at all. The {{fandom}} template already lets people link easily to any Fandom wiki they want.  rend (talk) (edits) 18:46, August 30, 2025 (EDT)

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

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

Rework Super Mario Galaxy and Super Mario Galaxy 2 appearance tables

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

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

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

  • Goomba's Super Mario Galaxy appearance list at the time of writing, for comparison and posterity. As Goombas are the most common enemies in the game, it serves as a good benchmark for how large each format can get.
  •   marks missions where they are completely absent.
  •   marks missions where they are loaded and may be visible, but cannot be encountered directly.
Domes Galaxies Missions
Gate Gateway Galaxy    
Terrace Good Egg Galaxy            
Fountain Space Junk Galaxy            
Rolling Green Galaxy  
Battlerock Galaxy              
Hurry-Scurry Galaxy  
Kitchen Beach Bowl Galaxy            
Buoy Base Galaxy    
Bowser Jr.'s Airship Armada  
Bedroom Gusty Garden Galaxy            
Freezeflame Galaxy            
Dusty Dune Galaxy              
Bowser's Dark Matter Plant  
Engine Room Gold Leaf Galaxy            
Bowser Jr.'s Lava Reactor  
Garden Deep Dark Galaxy            
Dreadnought Galaxy            
Comet Observatory Rolling Gizmo Galaxy  
  • Rework A, by EvieMaybe: Focusing on compactness, it exclusively represents information through text, avoiding the usage of icons or hover text. However, it sacrifices displaying mission types, mission numbers, and domes.

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

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

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

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

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

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

Support: Use Rework A

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

Support: Use Rework B

  1. Doc von Schmeltwick (talk) - Per proposal

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

Support: Use Rework C

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

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

Oppose: Keep current format

Super Comment Galaxy

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

the plan is to have lists of appearances for every enemy in every mainline game, i think. i'm for it, and pretty much everyone else i've talked to is for it too. —  eviemaybe (talk / contributions) 23:45, September 4, 2025 (EDT)
See Dry Bones for a page that currently does have them for most every game. Doc von Schmeltwick (talk) 01:12, September 5, 2025 (EDT)

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

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

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

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

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

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

Change game quote lists to game scripts

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

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

(Mario and Luigi walk towards a gate with "Mushroom Kingdom" written on it. Bowser looks out from behind the bushes.)
Bowser: (evil laugh)
Mario: Nice of the princess to invite us over for a picnic, eh, Luigi?
Luigi: I hope she made lots of spaghetti!
Mario: Luigi, look!
(Mario points off-screen, and Luigi turns to look. Wooden boards with "Klub Koopa Resort" have been nailed over a gate, and a letter is taped to the door. Mario takes the letter down.)
Mario: It's from Bowser! (reading the letter) "Dear pesky plumbers: The Koopalings and I have taken over the Mushroom Kingdom! The princess is now a permanent guest at one of my seven Koopa hotels! I dare you to find her if you can!" (stops reading, to Luigi) We gotta find the princess!
Luigi: (pointing to the camera) And you gotta help us!
Mario: If you need instructions on how to get through the hotels, check out the enclosed instruction book.
(Fade to black. Gameplay begins.)

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

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

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

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

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

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

Support (All-Star Scripters)

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

Oppose (It's Not 2007 Anymore)

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

Comments (Needs Revisions)

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

Honestly, transcripts for TV shows, and maybe even movies, feels like a very nice addition to have, though it's definitely a lot more involved. We don't see why it'd count as copyright infringement--we have seen multiple cartoons' wikis feature transcripts, and have never heard of a legal case over them--our concern is moreso in how, inherently, transcribing a whole movie is very time-consuming.  ~Camwoodstock ( talk ☯ contribs )   20:01, September 14, 2025 (EDT)
Well, so is maintaining a wiki on the world's biggest video game franchise. Hewer (talk · contributions · edit count) 20:10, September 14, 2025 (EDT)
Oh, make no mistake, we weren't saying that as a "oh, it's too much effort, so Why Bother?"--we were around for the Great Aboutfile Rush of Late 2024, so we know how this community can lock in. We're just saying that implementing this proposal would very much be a coordinated effort.  ~Camwoodstock ( talk ☯ contribs )   22:23, September 14, 2025 (EDT)
This proposal itself wouldn't affect anything from the shows, but I agree that having actual transcripts for those would be a big help -- especially for shows like Saturday Supercade where information is sparse and we should capture as much of it as we can. It could also cut down on how bloated and detailed some of the plot summaries are. The cartoons have been legally available for free on YouTube for over a decade now, so I can't imagine copyright takedowns would be too much of a problem. Mario show transcripts have also been put up on Lemmy's Land and Forever Dreaming, for reference, and those have been around for a while. I would personally wait on the movies, though, since they're very recent and part of a film franchise, with Nintendo and Universal being strict on copyright. Scrooge200 (talk)   20:59, September 14, 2025 (EDT)

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

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

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

Lets talk about LINE

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

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

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

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

Oppose (line is Yoshi's Wooly World)

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

create new line sections in galleries

  1. Altendo (talk) Second choice.

Comments

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

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

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

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

@YoYo line could be considered a separate installment from the game its stickers are based on. COLIN WAS HERE  edit a page!

Miscellaneous

None at the moment.

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