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.
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.
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 detailed description of the proposed changes and may link to a draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.
Rules
Only autoconfirmed users may create or vote on proposals. Proposals can be created by one user or co-authored by two users.[Proposal 1]
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.
Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).[Proposal 2]
Proposals conclude at the end of the day (23:59) two weeks after voting starts (all times UTC).[Proposal 3][Proposal 4]
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 (UTC).
Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
Proposals must have a status quo option (e.g. "Oppose", "Do nothing") unless the status quo itself violates policy.
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.[Proposal 5]
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.
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.
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.
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.
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.
If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
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.
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.
After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.[Proposal 6]
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 should ask for that help. Proposals that result in changes to policy pages or general guidelines must be cited accordingly.[Proposal 7]
All proposals are archived. Please note that canceled proposals must also be archived, including their date of cancellation.[Proposal 8]
Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. If a proposer cancels their own proposal, they must provide a reason and wait three days before submitting any new proposal.[Proposal 9]
A proposer cannot cancel their proposal and then implement it anyway. Only wiki staff can cancel a proposal and immediately put it into effect.
Proposers can request their proposal be canceled by a wiki staff member after the self-cancellation cutoff, but they must provide a valid reason for doing so. In most cases, the proposal should simply run its course.
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.
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.
Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and carried out by the bureaucrats.
No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
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 (UTC)
====[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.[Proposal 10] 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 15 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 (UTC)
;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 (UTC)
;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 (UTC)
;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.
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
Remove the non-Super Mario games' rows from the Trophy Decorations table on Trophy Creator (discuss) by Camwoodstock; Deadline: June 19, 2026, 23:59 (UTC)
Settle how to convey shared names across dialects in "Names in other languages" tables
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)";
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:
The name hails from a work that does not have separate Latin American and European Spanish versions;
The name hails from a work that does have separate Latin American and European Spanish versions, but the name is shared between them;
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)
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.
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.
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.
Obligatory status quo option
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)
Removals
None at the moment.
Additions
Create a template and PipeProject for enemy, obstacle, and item lists in courses
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.
|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 thesecategories.
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
Mr. Sorbetti (talk) Per proposal or project? Either way, I support this.
Partial Support: Template (and its associated pages) only
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
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.
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.
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.
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.
EvieMaybe (talk) per Camwoodstock. better to do this all together properly.
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.
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. TheDabMaster 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.
<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)
Update the Template:Star ranking
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)
Support 1: Use image-based stars instead
Support 2: Use image-based stars, circles, and thumb icons
Support but better 2: Use Power Stars, circles, and thumb icons
Stargent Deez (talk) As proposer. May cancel my above vote depending on which option is more popular.
Oppose: Do not change the template
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 Bananzalayer 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.
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.
Nevermind. TheDabMaster 18:49, June 12, 2026 (UTC)
Create a "NIOL missing" template
I've already been thinking about this for a while, but why has the wiki never had a template for missing NIOLs?[A] 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:
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.
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.
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)
Changes
Move "Haunted House Course" and "Inside Wario's Castle" to "Ghost House Course" and "Captured Mario's Castle Course" respectively
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 Musicsoundtrack 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.
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).
09:47, June 12, 2026 (UTC)
~Camwoodstock ( talk ☯ contribs ) 
04:41, June 6, 2026 (UTC)
~Camwoodstock ( talk ☯ contribs ) 
06:23, June 6, 2026 (UTC)
rend (talk) (edits) 07:13, June 6, 2026 (UTC)
Yoshi18 (talk/contribs) 13:26, June 6, 2026 (UTC)
It's me, Mario! (Talk / Stalk) 23:57, June 8, 2026 (UTC)
