|
Current time:
September 22, 2026, 08:38 (UTC)
|
|
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 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.
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 standard 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.
Relevant discussions
- ^ Proposal "Allow co-authorship of proposals" (passed on January 24, 2025)
- ^ Proposal "Allow unregistered users to comment under talk page proposals" (passed on November 14, 2024)
- ^ Proposal "Proposals Should End At The end of the day one week after voting starts (In UTC)" (passed on March 3, 2010)
- ^ Proposal "Revise how long proposals take: "IT'S ABOUT (how much) TIME (they take)"" (passed on October 16, 2024)
- ^ Proposal "Vote For More Than One Option On Proposals With More Than Two Choices" (passed on May 10, 2016)
- ^ Proposal "Delete Links to Passed Talk Page Proposals ONLY Until Action Has Been Taken" (passed on May 2, 2013)
- ^ Proposal "Cite relevant proposals and discussions on policy pages and guidelines" (passed on October 17, 2024)
- ^ Proposal "Include the date a proposal was withdrawn within the proposal (when applicable)" (passed on September 9, 2017)
- ^ Proposal "Allow users to put a reason for canceling proposals" (passed on May 8, 2026)
- ^ Proposal "Introduce a new type of proposal" (passed on February 14, 2025)
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.
Talk page proposal formatting
==[insert a title for your proposal here]==
{{TPP}}
[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])===
==[insert a title for your proposal here]==
{{TPP}}
[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])===
List of ongoing talk page proposals
Deletions
Moves
Merges
Splits
Miscellaneous
Unimplemented proposals
Proposals
Note: Implemented for all except Bowser's Inside Story's Bowser's Castle and Kingdom Battle's Peach's Castle
Note: Article for "Battle Without Honor or Humanity" has not been created yet
Talk page proposals
Note: Missing Rainbow Bridge, Blue Bonus Game House, and Yellow Bonus Game House articles.
Note: Currently split clothing should be merged back
Writing guidelines
Introduce update history guidelines
As early as the Family Computer, game developers were able to make changes to their games after release. Historically, these changes came in the form of revisions made to cartridges between different print runs. However, game developers were often opaque about the mere existence of revisions, leaving fans to discover the differences between two revisions of the same game themselves.
Eventually, consoles gained the ability to download game updates from the Internet. For Nintendo games, these downloadable updates became easier to document because they came accompanied with release notes. Unfortunately, some articles on the Super Mario Wiki have become too reliant on these release notes and, as a result, often fail to mention unlisted changes. These articles simply note that "several issues have been addressed to improve the gameplay experience."
Additionally, outside of these lists of rehashed release notes that are confined to game articles, articles on the wiki often do not adequately take game updates into account. Some articles might describe a mechanic only in the context of a game's initial version or its last. Other articles might indicate that a mechanic was changed in some update but not specify which update. If an update is specified, the relevant update history section might not even be linked. Finally, the ways that we refer to updates by name are incredibly inconsistent. All of the following examples are currently used on the wiki:
- "1.2.3 update"
- "an update"
- "Ver 1.2.3 update"
- "Ver 1.2.3"
- "1.2.3 patch"
- "Ver. 1.2.3 patch"
- "Ver. 1.2.3 update"
- "Ver. 1.2.3"
- "version 1.2.3 update"
- "version 1.2.3"
- "Version 1.2.3"
These issues are gradually improving across the wiki. I would say that our coverage of the update history of Mario Kart World excels at accurately providing both official context into updates and analysis down to statistic changes and changes to names in other languages.
In light of these aspects, I've written guidelines that formalize the current framework used to document update histories while also clarifying related terms and specifying how this documentation should be referenced. I propose turning these guidelines, included below, into a policy for the wiki.
This page provides an overview of how updates and revisions for games can be described and organized on the Super Mario Wiki.
In the early days of gaming, once a physical game is sold, its data could not be changed. If a game-breaking glitch were to be discovered in a game, for example, players who had already bought that game would have to suffer the glitch indefinitely. To combat this limitation, publishers would print new runs of a game, known as revisions, with updated data to fix glitches and make other changes.
Modern consoles support Internet connectivity, and game data on these consoles can be stored digitally. Every Nintendo console since the Nintendo 3DS supports some form of updates. Internet connectivity is also used to implement features such as downloadable content and other new content for existing copies of games through updates. Like revisions, updates may be distributed as part of later print runs of a game.
Revisions and updates are distinct from reissues, which encompass ports, remakes, and other versions of a game that are typically sold under a different title or for a different console. Changes made in the context of emulators such as Virtual Console are also not considered revisions or updates.
While Nintendo historically did not provide information about revisions, it provides support articles that document each game's update history. However, the wiki strives to provide complete, detailed information about both revisions and updates under the frameworks detailed below.
Revision differences
Game articles can describe a game's revision differences in a section titled "Revision differences".
As revisions are not typically identified in an official capacity, their information does not need to be organized in a particular manner. Unless an official name of a revision can be found, it should be referred to simply as the "first revision", "second revision", or so on. Distinct cartridge identifiers do not count as revision names, but they should be mentioned as an aid to identify a cartridge's revision.
Update history
Game articles can describe a game's update history in a section titled "Update history".
The start of the section should provide a brief introduction to the game's updates and how they are treated. If a support article exists, it should be cited in this introduction. The following template serves as an example, though statements can be removed or modified to fit the game being discussed.
This is a detailed list of updates that Game has received since launch. To play online, players must use the latest version of the game.
If an update has been applied, the game's current version is shown on the game's title screen.
This overview should be followed by individual sections for each update. The heading of each section should be the update's official title. If multiple titles have been used to refer to the same version, the title from the cited support article (typically in the format "Ver. 1.2.3") should be prioritized. If a version has received a unique name (such as version 2.0.0 of Super Mario Maker 2 being dubbed "A Legendary Update"), that name can be mentioned within the section and even serve as a redirect to the section. Some games, like Mario Kart 8, format version titles within the game differently compared to the relevant support article; in this scenario, the formatting difference can simply be explained once within the update history section's introduction.
Each section should describe the circumstances of the update, such as when, why, and how the update released. If the update released prior to the game's release (in what is often referred to as a "day-one patch"), that information should be noted. If the update was announced in a Nintendo Direct, that detail should also be explained. Trailers and articles for the update should be cited.
Each section should attempt to summarize notable features added by the update. Then, if official release notes are available, the section should specify that "the following release notes were provided" and include those notes within <blockquote>. The formatting of these release notes should match their source as much as possible, and like other quotes on the wiki, the contents of these notes should not be modified other than to point out mistakes with {{sic}} or provide links to relevant articles. Finally, any unlisted minor changes can be noted at the end of the update's section.
If an update history section becomes sufficiently long, it can be split to a different article titled "Game update history". The remaining section in the game article should give a brief overview of the nature of the content added across all updates while using {{main}} to link to the full article. On the split article, the introduction should contain the date that the game was released; this date serves as context to the timing of the game's updates. Additionally, all update sections should be moved under a single "Versions" heading. The split article can be categorized into the update history pages category.
Any changes not tied to a version number but still relevant to the game's update history can be listed in a final "Other changes" section.
When referring to updates in other articles, the standard wording "version 1.2.3" should be used and link to the relevant update section. Depending on the context, specifying "version 1.2.3 of Game" or simply "version 1.2.3 of the game" is more clear. Alternate terms like "patch" should be avoided.
Proposer: B700465189a9 (talk)
Deadline: September 24, 2026, 23:59 (UTC)
Support: Introduce update history guidelines
- B700465189a9 (talk) Per proposal.
- Iand255 (talk) This all seems fairly reasonable. I personally see no reason to not standardize the coverage of update history.
- SuperGamer18 (version 1.8) We DESPERATELY need this. Per proposal.
- The Dab Master (Ver. 2.8.7) Per proposal.
- Yoshi18 (Ver. 10.0.0) I'm in for this, as long as "Ver. [number]" becomes the (main) way we refer to updates by name.
Oppose: Reject update history guidelines
In your proposed page, you're missing examples of what features internet connectivity can implement ("Internet connectivity is also used to implement features such as and other new content[sic] [...]"). Additionally, what if a game only gets a single revision? How would that be worded in the Revision differences section? SuperGamer18 (talk) 17:39, September 10, 2026 (UTC)
- That sentence has been corrected. If a game only has a single revision, then the relevant section would simply list all of the differences of that single revision. B700465189a9 (talk) 20:56, September 18, 2026 (UTC)
Removals
3DS Mario & Luigi duplicate file removal
If you look in multi-game galleries, such as Gallery:Koopa Troopa, you begin to notice something odd: many of the sprites for the Mario & Luigi Nintendo 3DS games have identical appearances. Of course, this is likely due to AlphaDream's budget-saving measures incentivizing them to reuse sprites between the four 3DS games. But the really odd thing for wiki purposes is, these reused sprites are uploaded as separate files despite being completely identical. I think these images need some cleanup to condense them to one file that has multiple game categories. Of course, the exception is if the images are of certain unique, game-specific poses of that character or enemy that are unique to only one game, which can still maintain their separate file status and separate gallery entry. It is also likely that some sprites received minor revisions between games, and so it is fine for such sprites to be split into multiple files to illustrate the differences.
Proposer: P-Tux7 (talk)
Deadline: October 1, 2026, 23:59 (UTC)
Agree: Reduce identical appearances across games to only one file
- P-Tux7 (talk) Per proposal.
- Yoshi & Paper (talk) Per proposal. We also do this for things like render and model reuse, so I don't see why we shouldn't do it here.
- Brett (talk) Per proposal.
- Iand255 (talk) Per all.
- Tails777 (talk) Per proposal. I've seen this and always disagreed with it. There's no reason we can't just state the sprite comes from multiple games and use only one. Unless it has noticeable differences (with something like appearance or animation), we don't need five uploads of the same Goomba sprite from five games.
- Doc von Schmeltwick (talk) - While obviously specific to when they are outright reused (occasional tweaks do happen uncommonly), just take a look at Big Tail Goomba's page. There's four games using the same sprite covered there, which is four of five of the enemy's total appearances!
Disagree: Keep appearances from separate games as separate files even if they are identical
Additions
Identity file category
Based on the vote so far, this proposal may be eligible to close one week early. Please use {{proposal check|early=yes}} on September 23, 2026 at 23:59 (UTC) and close the proposal if applicable.
As of now, several files are in the personal files that I do not think should be in there. These files include various identity markers, such as 
and 
. (
is marked as a Shroom file, and thus gets around the issue in a way that cannot be repeated for other pride flags.) I consider this to be a problem for several reasons:
- Making such "identity files" count against one of a user's personal files disincentivizes them to be proud of their identity.
- A limit of five personal files is intended to cut down on images that can only be used by one user; identity files, by definition, are something that can apply and be useful to more than one user.
- Identity files being tagged as a personal file by one user can make them feel possessive of that file. If someone wants to have their own version of the cross file, they ideally should be able to.
I propose that we have a heavily-monitored "identity file" tag for such files. This would allow for freer uploading and usage of such identity files without there being any negative incentives for users to upload files to express their identity. Such identity files should ideally express a sincerely-held religious, gender, sexual, locational, etc. identity (so this means that you can't upload something like ThisUserIsASpongeBobFan.png as an identity file).
Proposer: P-Tux7 (talk)
Deadline: September 30, 2026, 23:59 (UTC)
Support: Add the identity file category
- P-Tux7 (talk) Per proposal.
- Iand255 (talk) Per proposal. These symbols and flags should be considered integral to all user pages, and have no reason to continue clogging up people's personal files, especially in 2026, a time when people are arguably the most open with their identities they've been in all of recorded human history.
- Camwoodstock (talk) We can get behind having a category of images like this. We did feel kinda weird hijacking an image from a random 'Shroom issue for our own userbox, and we imagine many people have come across similar issues with having to effectively leech off another user's "personal image" like this.
- SuperGamer18 (talk) Per all, particularly Iand255.
Also I didn't expect one of my personal files here and I don't know what to say about that
- Illuminoid (talk) Per all. This would make finding these files easier, preventing duplicate uploads.
- The Real Color Splash Fan (talk) Per all.
- Maw-Ray Master (talk) Per all.
- The Garlic Bread Master (talk) Per all.
- Yoshi2026 (talk) Per all, especially Iand255.
- Aomaf (talk) Also Per all
Oppose: Do not add the identity file category
If we're going to use that particular cross image for identity instead of for personal use, I do feel like it needs to be reuploaded to not only be bigger, but also be transparent (it sticks out like a sore thumb in Dark mode), and I'm not sure if we can find an exact replica with those two conditions. Though, making it a public file does have the benefit of finding a better cross symbol to upload over it, I guess. 
rend (talk) (edits) 10:22, September 16, 2026 (UTC)
- The transgender flag colors are ever so slightly off in the 'Shroom image and it's been bothering us we can't fix it because, well, that's a 'Shroom image. Having a version that's de-coupled from that baggage would be very nice to have, is all we're saying. ;P
~Camwoodstock ( talk ☯ contribs ) 
15:53, September 16, 2026 (UTC)
- Yeah, I noticed that as well. The trans pride flag's light blue is supposed to be close to baby blue, but the image on our wiki is closer to the Luxembourg flag's sky blue. rend (talk) (edits) 18:01, September 16, 2026 (UTC)
Also, I think creating a file notice template such as {{personal-file}} for these kind of images would be useful as well. It could say something along the lines of "This file is in use as an indicator for a user's personal identity, and can be used by any user for their user page. It is not being counted as a personal file; please do not delete this." rend (talk) (edits) 15:33, September 16, 2026 (UTC)
Don't we have a flag category used for, like, national flags? Most of these are still flag-ish, so don't they kinda qualify? Doc von Schmeltwick (talk) 17:42, September 16, 2026 (UTC)
So this gives such images {{template-image}} (Category:Template ima
and 
. (
is marked as a Shroom file, and thus gets around the issue in a way that cannot be repeated for other pride flags.) I consider this to be a problem for several reasons:
