MarioWiki:Proposals

From the Super Mario Wiki, the Mario encyclopedia
Jump to navigationJump to search
Image used as a banner for the Proposals page

Current time:
Tuesday, July 16th, 23:30 GMT

Proposals can be new features (such as an extension), the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken.
  • "Vote" periods last for one week.
  • Any user can support or oppose, but must have a strong reason for doing so (not, e.g., "I like this idea!").
  • 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.

A proposal section works like a discussion page: comments are brought up and replied to using indents (colons, such as : or ::::) and all edits are signed using the code {{User|User name}}.

How to

Rules

  1. If users have 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 the other users, who will then vote about whether or not they think the idea should be used. 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}}.
  2. Only registered, autoconfirmed users can create, comment in, or vote on proposals and talk page proposals. Users may vote for more than one option, but they may not vote for every option available.
  3. Proposals end at the end of the day (23:59) one week after voting starts, except for writing guidelines and talk page proposals, which run for two weeks (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 one week later on Monday, August 8, at 23:59 GMT.
  4. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is accepted (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
  5. 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 at any time, but the final decision to remove another user's vote lies solely with the administrators.
    • 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.
  6. 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 "(banned)" 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.
  7. No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
  8. 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.
  9. All proposals that end up in a tie will be extended for another week. Proposals with more than two options must also be extended another week if any single option does not have a majority support: i.e. more than half of the total number of voters must appear in a single voting option, rather than one option simply having more votes than the other options.
  10. If a proposal with only two voting options has more than ten votes, it can only pass or fail with a margin of at least three votes, otherwise the deadline will be extended for another week as if no majority was reached at all.
  11. Proposals can only be extended up to three times. If a consensus has not been reached by the fourth deadline, the proposal fails and can only be re-proposed after four weeks, at the earliest.
  12. 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.
  13. If the administrators deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to remove it at any time.
  14. Proposals can only be rewritten or deleted by their proposer within the first three days of their creation (six days for talk page proposals). However, proposers can request that their proposal be deleted by an administrator at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
  15. 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.
  16. Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
  17. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
  18. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal and support/oppose format

This is an example of what your proposal must look like, if you want it to be acknowledged. If you are inexperienced or unsure how to set up this format, simply copy the following and paste it into the fitting section. Then replace the [subject] - variables with information to customize your proposal, so it says what you wish. If you insert the information, be sure to replace the whole variable including the squared brackets, so "[insert info here]" becomes "This is the inserted information", not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but what each voting section is supporting 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|[enter your username here]}}<br>
'''Deadline''': [insert a deadline here, 7 days after the proposal was created (14 for writing guidelines and talk page proposals), at 23:59 GMT, in the format: "July 16, 2024, 23:59 GMT"]

====Support====
#{{User|[enter your username here]}} [make a statement indicating that you support your proposal]

====Oppose====

====Comments====


Users will now be able to vote on your proposal, until the set deadline is reached. Remember, you are a user as well, so you can vote on your own proposal just like the others.

To support, or oppose, just insert "#{{User|[add 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 just say "Per my proposal".

Talk page proposals

All proposals dealing with a single article or a specific group of articles are held on the talk page of one of the articles in question. Proposals dealing with massive amounts of splits, merges or deletions across the wiki should still be held on this page.

For a list of all settled talk page proposals, see MarioWiki:Proposals/TPP archive and Category:Settled talk page proposals.

Rules

  1. All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{TPP discuss}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, 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. Place {{TPP}} under the section's header, and once the proposal is over, replace the template with {{settled TPP}}.
  2. All rules for talk page proposals are the same as mainspace proposals (see the "How to" section above), with the exceptions made by Rules 3 and 4 as follows:
  3. Voting in talk page proposals will be open for two weeks, not one (all times GMT).
    • For example, if a proposal is added at any time on Monday, August 1, 2011, it ends two weeks later on Monday, August 15, 2011, at 23:59 GMT.
  4. The talk page proposal must pertain to the article it is posted on.
  5. When a talk page proposal passes, it should be removed from this list and included in the list under the "Unimplemented proposals" section until the proposed changes have been enacted.

List of ongoing talk page proposals

Unimplemented proposals

Proposals

Split Mario Kart Tour character variants into list articles, Tails777 (ended May 4, 2022)
Establish a standard for long course listings in articles for characters/enemies/items/etc., Koopa con Carne (ended June 8, 2023)
Remove profiles and certain other content related to the Super Mario Bros. Encyclopedia from the wiki, Koopa con Carne (ended April 30, 2024)
Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024)
Split Wario Land: Shake It! boss levels, GuntherBayBeee (ended July 2, 2024)
Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024)
^ NOTE: Not yet integrated for the New Super Mario Bros. games, the Super Mario Maker games, Super Mario Run, or Super Mario Bros. Wonder
Allow colorful tables, Scrooge200 (ended July 9, 2024)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)
^ NOTE: Currently the subject of an active proposal.
Split machine parts, Robo-Rabbit, and flag from Super Duel Mode, Doc von Schmeltwick (ended September 30, 2022)
Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)
Merge Golf (series) with Mario Golf (series), Hewer (ended July 15, 2024)

Writing guidelines

None at the moment.

New features

Expand use of "rawsize" gallery class

So Porple helped me with creating a method to keep sprites at their raw size in galleries (yay!), which replaces the somewhat awkward way I previously did it for mostly-consistently-sized sprites (see the page history for Gallery:Golf (Game Boy), which is what I specifically directed him towards while doing it), and it's also highly useful for icons (especially when we don't have the raw parameters already, like the car icons for Mario Kart Wii), and cases where a size comparison is useful (like Bigger Boo's growth). In general, it's a good way to keep them from looking bloated and crusty with inconsistently-sized pixels, which I feel looks bad and degrades their quality, while keeping an upper limit on size so "huge" sprites don't take up all the space (and shrunken large sprites are preferable to bloated small sprites, in my opinion).

Now what I want to see consensus on, is whether this concept should be expanded to more common usage for sprite galleries, so that people can actually see the size difference between these entities. For example:

compared to

or

compared to

Now, you'll notice, that on ones where there is difference in size, the smaller ones will appear just that: small, but their bounding boxes are the same as the others (which is an issue my old "give separate galleries with different widths and heights as well as inline-block display" strategy didn't have, but costed a lot more HTML data). I can see how some people may have issues with that, though speaking as a spriter, I find it preferable to blown up pixels. Also, you may notice some stretched captions there, that of course won't be much of an issue with the usually short captions sprites in galleries have.

Proposer: Doc von Schmeltwick (talk)
Deadline: July 19, 2024, 23:59 GMT

Support - allow it for general use in sprite galleries

  1. Doc von Schmeltwick (talk) - Per proposal (and the crusty crab)
  2. Super Mario RPG (talk) - I don't like the argument of "it doesn't look good." This provides the immediate benefit of showing the reader the original sizes of the sprites without having to click on each and every file link. Per proposer.
  3. LinkTheLefty (talk) I always found the size discrepancy to be an eyesore.
  4. Ahemtoday (talk) The inconsistent pixel sizes on the SMB2 examples are very apparent to me — you highlight Clawgrip, but I think Tryclyde has it the worst, personally. Now that we have the ability to upscale these by consistent amounts to keep them at reasonable sizes while not introducing nearest-neighbor weirdness, that takes me off the fence in voting for it provided we do that. I still don't really see the issue with the MP6 renders, though. Ahemtoday (talk) 22:23, July 14, 2024 (EDT)

Oppose - leave it exclusive to consistent sized icons and other special cases

  1. LadySophie17 (talk) None of the pixels look blurry or blown out to me, they're just larger, which is generally how they would appear on any modern screen displaying them anyway. Displaying them in their original size makes details harder to see (important!), and the empty space around the boxes is just unappealing. As long as the wiki has these images saved at their true resolution, I see no issue in displaying them at a larger scale for clarity and convenience.
  2. Waluigi Time (talk) Per Lady Sophie. I'd rather sacrifice a little bit of quality than have these be too tiny to tell what anything is.
  3. Sparks (talk) Per all.
  4. Technetium (talk) Per all.
  5. Pseudo (talk) Per Lady Sophie. The point of a gallery is to allow wiki visitors to look at the images therein, and leaving them too tiny to inspect closely feels counterintuitive, even if it’s not the original state of the images.
  6. Sdman213 (talk) Per all.
  7. Nintendo101 (talk) I think a nice benefit in supporting reference material or an encyclopedia is in allowing readers to view subjects in contexts otherwise tough to see, especially for galleries that are intended to support visual material. I have a number of books on small artefacts or organisms (insects, microbes, etc.) where they are not displayed to scale. I know and have seen users change the scaling of individual subcategories on galleries, but I'd rather that was up to their discretion rather than blanket policy. As long as the true dimensions of the uploaded files have not been messed with, I do not think there is much harm in allowing users to scale assets on the gallery pages.
  8. FanOfYoshi (talk) NO!!! THIS IS PATRICK!!! Per all.
  9. Murphmario (talk) Per all.

Comments

Regarding "detail," when it's all the same pixels anyway with no "zoom and enhance" going on, making them larger doesn't add any detail. That's why we upload sprites in their native res to begin with. The only "detail" you're going to see is how any dithering looks when it's not blending as intended, which is what "crusty" generally means in this case. Doc von Schmeltwick (talk) 12:46, July 13, 2024 (EDT)

I am perfectly aware that making an image larger does not create pixels out of nowhere, thank you very much. What it does is make small pixels (and therefore details) larger and easier to see.— Lady Sophie Wiggler Sophie.png (T|C) 13:11, July 13, 2024 (EDT)
Problem is that the ruined dithering actually makes detail harder to see. Doc von Schmeltwick (talk) 13:38, July 13, 2024 (EDT)

I'm not opposed to its implementation entirely; I think you can have a case for it. For instance Gallery:Mario Kart Wii#Mugshots already uses a version of it to scale all those 64x64 sprites consistently. Gallery:Super_Smash_Bros.#Icons can also use a more consistent scaling scheme, but using class="rawsize" in the Smash Bros. example is not the solution, as it makes the icons much more difficult to ascertain especially on desktop monitors where zooming is not as easy vs a touchscreen finger swipe.

The reasoning for the proposal I also do not agree with and I believe it's based off trying to preserve how an asset to the perceived display from a game, which I argue is flawed reasoning as we are a wiki with different set of ideal ways and constrictions in how we can display information. This is not to mention that these sprites are often scaled in the games themselves and display differently based on the monitors. Paper Mario sprites for instance, are likely not even intended to be viewed at the resolution they're in; they're scaled up from camera, the game itself, and TV displays (CRT TVs are much less lower-resolution than the monitors we have today, so the original experience on these older games tend to show very blown-up scales), so sometimes details and text screenshots using the native resolution actually appear quite difficult to ascertain, see File:PM Koopa Bros Introducing Themselves Screenshot.png. The games themselves also scale these sprites often; using Smash Bros. 64 again as an example, the stock icon scales from an emulator screenshot in File:SSBStockmatch.png are increased and are filtered applied to blur out the pixels.

Finally, the examples used are flawed. At least from my display, Triclyde and Wart appear to be slightly scaled down, which undermines the point that not not applying scales to sprites maintains the desired factor of 2 that galleries autoscales fail to do (which perhaps the proposal can resolve and should address right away). The solution for this is either applying a consistent scale factor to all sprites, which means scaling them up, increasing the field size that the sprites occupy themselves in, or just going in one-by-one to maintain a consistent look (is this even feasible?). I do recommend trying to apply a scale factor to some low-resolution sprites including the NES/SNES era ones so the pixels display properly. I also recommend the terminologies, for clarity, is resolution (which is referred to as "raw size") vs scale.

So anyway, this proposal I understand where it's coming from but there are better solutions to address scale factor in galleries, and the practice appears to have already been employed in some galleries, particularly concerning higher resolution UI elements from games that maintain consistent aspect ratios like Mario Kart Wii's 64x64 sprites; these are high enough resolution that displaying them at no scale shows enough detail, but not high enough to occupy too much space for galleries. There might be more cases where this noscale parameter applies well, but I think we have to comb through them due to the amount of specifications Mario Kart Wii had going for it, which likely many galleries won't. Scale differences may be useful, such as in Big Boo's case and perhaps in the Super Mario Bros. 2 case but there is a downside of shrinking sprites too much, especially for variable games like Super Mario RPG that has zoomed out Luigi and big monsters like (??? i haven't played that game lol), which leaves behind empty space in galleries Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 12:52, July 13, 2024 (EDT)

I put the wrong parameters for the SMB2 one when I made the proposal, it's fixed now. Doc von Schmeltwick (talk) 12:58, July 13, 2024 (EDT)
Ok. Struck out that part. Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 12:59, July 13, 2024 (EDT)

@FOY Oi, don't use a proposer's own joke against them. That's rude. :( Doc von Schmeltwick (talk) 11:30, July 14, 2024 (EDT)

Is there possibly a way to have scale factors for the galleries? Such as the ability to increase these by 200%. It could be a way to display more easily viewed sprites while maintain relative sizes of sprites. I need to see if it'll work for larger sprites. Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk) 12:43, July 14, 2024 (EDT)

As it is, we can't even do that with normal images, unfortunately, I've tried for tables many times for 200% or 50%, depending on the type, doesn't work for either. Guess that's a thing we can ask Porple. Doc von Schmeltwick (talk) 13:41, July 14, 2024 (EDT)
Okay, using a parameter Steve has put in your talk page[1], I've previewed the Super Mario Bros. 2 sprite array with a x2 scale factor. I like it more (not going to show it here; might be subject to change). I wonder what other people think of it. Icon showing how many lives Mario has left. From Super Mario 64 DS. It's me, Mario! (Talk / Stalk)
Well, as that is an update to the rawsize amount, it works about the same for the purposes of this proposal. So long as there's a consistent scale, it's better than what we've had historically. Doc von Schmeltwick (talk) 22:18, July 14, 2024 (EDT)
I was actually thinking to myself "I might back this proposal if we scaled up the sprites by consistent round-number amounts". Ahemtoday (talk) 22:23, July 14, 2024 (EDT)

Removals

None at the moment.

Changes

Rename Luigi's Mansion: Dark Moon article

Luigi's Mansion 2 was renamed as Luigi's Mansion: Dark Moon in the North American version. However, Luigi's Mansion 3 was not renamed into subtitle and numbered "3" internationally. Accordingly, the number was maintained in Luigi's Mansion 2 HD.

From King Boo article, the section is named as "Luigi's Mansion: Dark Moon / Luigi's Mansion 2 HD". The HD version and the name are different, adding to the complexity and confusion. Now that HD is out, the article name must be unified into one name.

Should the names in the articles be unified by number "2"?

Category:Luigi's Mansion: Dark Moon locations → Category:Luigi's Mansion 2 locations

Proposer: Windy (talk)
Deadline: July 17, 2024, 23:59 GMT

Support 1: Rename everything

  1. LinkTheLefty (talk) I was actually going to bring up this idea as possibly being supported by this proposal, but the HD release date slipped my mind. I'm all for keeping them consistent, especially since most players will know the game as Luigi's Mansion 2 now.

Support 2: Rename if have two names in the article

  1. Windy (talk) Semi-support. Category won't be renamed, but I want to unified into "Luigi's Mansion 2" in each articles if listed as "Luigi's Mansion: Dark Moon / Luigi's Mansion 2 HD".
  2. LinkTheLefty (talk) Personally, I think this is better for a broader discussion since it would be nice to have it streamlined in general, but I'll take it.
  3. Blinker (talk) Per proposal

Oppose: Do nothing

  1. Nightwicked Bowser (talk) North American names often take priority for subjects.
  2. Hewer (talk) Per MarioWiki:Naming, we always prioritise the North American names for games. While that does cause some inconsistencies in this case, it's simply a reflection of the official naming inconsistency, so by all means it should be inconsistent. It's our job to report the facts, not to "fix" the official naming. In fact, the Nintendo Direct that announced Luigi's Mansion 2 HD called it "a visually enhanced version of Luigi's Mansion: Dark Moon", so it's not like they've erased the "Dark Moon" name. Also, what about this is different to Super Mario RPG: Legend of the Seven Stars, which is called just "Super Mario RPG" in Japan and was then named as such worldwide with the remake?
  3. Doc von Schmeltwick (talk) - Per Hewer
  4. Sparks (talk) Per all.
  5. Sdman213 (talk) Per all.
  6. Shadow2 (talk) The 3DS version is entitled "Dark Moon"
  7. SeanWheeler (talk) If we do this, would we have to rename Super Mario Bros.: The Lost Levels as Super Mario Bros. 2? We already got a Super Mario Bros. 2, the one called "Super Mario Bros. USA" that Mariofied the Yume Kōjō: Doki Doki Panic game. I don't want to cause confusion over Super Mario Bros. 2 or any games that were retitled outside of Japan just because of a proposal changing Dark Moon to Luigi's Mansion 2. It's good to prioritize names from this website's home country.
  8. Technetium (talk) Per all.
  9. Nintendo101 (talk) Per Hewer.
  10. TheUndescribableGhost (talk) Per all.

Comments

Shouldn't the proposer weigh in? LinkTheLefty (talk) 06:42, July 10, 2024 (EDT)

Slightly off-topic, but I've been thinking about making a proposal for changing the (Luigi's Mansion: Dark Moon) disambiguation identifier to (Luigi's Mansion 2), in lieu to previous proposals about shortening identifiers, now that Luigi's Mansion 2 HD is out. The problem, however, that the American name does not contain a single 2 in the title, unlike its name in most other regions, and it's the American names that must be prioritized according to MarioWiki:Naming. Should I still make a proposal about this or just drop it? ArendLogoTransparent.pngrend (talk) (edits) 07:46, July 10, 2024 (EDT)

I'm pretty sure this proposal passing would achieve that anyway, so you should probably at least wait until this one's over before making that proposal. I'd likely oppose it for the reasons you mentioned, though. Hewer (talk · contributions · edit count) 07:52, July 10, 2024 (EDT)

@Hewer: Super Mario RPG has a different precedent that would have to be set by a separate proposal - the Japanese title is the one favored by the reissue worldwide (there's no telling if the PAL version would've kept the North American subtitle since it was canceled). In contrast, most of the world knows Luigi's Mansion: Dark Moon as Luigi/Luigi's Mansion 2, and it's an existing title for English audiences. LinkTheLefty (talk) 10:07, July 10, 2024 (EDT)

But it's not the one used in the part of the world prioritised by this wiki's naming policy (and often by Nintendo), and I'd rather stay consistent with that preference. This isn't the only time the American name is the odd one out - DK Summit, for example, is "DK Snowboard Cross" in Japan and "DK's Snowboard Cross" in Europe. Hewer (talk · contributions · edit count) 10:41, July 10, 2024 (EDT)
Yes, we know things can differ for different English audiences (although I don't know enough about Mario Kart courses to say if your example is a consistent difference between the American and British English versions in each game or if the latter localization eventually got discontinued later on). The part I want to underline is "most commonly used English name". Historically, Nintendo generally prefers North America for reissues for brand unification when the British English material differs; for example, Star Fox 64's reissue is Star Fox 64 3D instead of Lylat Wars 3D in terrorities where the original sold as Lylat Wars; Fire Emblem titles after Shadow Dragon for DS use American English localization terms where the British English versions differed; etc. What happened with Luigi's Mansion 2 is a deviation from expected norms, and so, it makes sense to respect that deviation. Yes, a preview called it Luigi's Mansion: Dark Moon in the North American version of the Direct before the final title was revealed at a later point, but I don't think there were any more references to that subtitle. It was, effectively, cleaned up by Nintendo themselves, likely so there was no casual mistaking that it was 3's predecessor in a Switch collection. LinkTheLefty (talk) 12:24, July 10, 2024 (EDT)
DK Summit's regional naming difference remains in the Booster Course Pass, released only last year (there are a few other courses with similar regional naming differences, but usually the American name is the one that matches the Japanese more closely while the European name deviates, whereas it's the other way round for DK Summit). Anyway, the "most commonly used English name" bit in the naming policy is in the same sentence as the stipulation that we must use North American names, that's what it refers to. We are respecting Nintendo's deviation by calling Luigi's Mansion 2 HD as such, not by retroactively changing the name of the original 3DS version, which matches neither Nintendo's handling nor our own naming policy. Hewer (talk · contributions · edit count) 12:40, July 10, 2024 (EDT)
A recent blurb from NoA (the only Nintendo apparently) for the launch trailer states the following: "You may notice that the Luigi’s Mansion™ 2 HD game looks a bit familiar. That’s because this classic adventure from the Nintendo 3DS™ system is returning in style!" No, it doesn't explicitly refer to the original as such, but it is strongly implicit in the wording as a returning classic. I don't see anything wrong with this; it makes things easier to follow for everyone, and makes identifiers and categories more navigatable. We're not removing the old name; it will just be acknowledged as the North American name of the original. There was probably an expectation that the final NA title might've been along the lines of Luigi's Mansion: Dark Moon HD, but that didn't happen. LinkTheLefty (talk) 13:04, July 10, 2024 (EDT)
I'm not denying that the game is a re-release, that doesn't have anything to do with its different title. As much as I'm glad Nintendo removed this regional difference for the re-release, I think us retroactively applying that to the original game is the wrong move. It only makes things more confusing for every game covered on the wiki that was released in North America to use its name from that region except for this particular one, and due only to a re-release of it from years later. While I don't normally like using examples from different series, Kirby's Return to Dream Land feels like a similar enough case here: it was called "Kirby's Adventure Wii" in Europe, then the remake had its English name standardised to "Kirby's Return to Dream Land Deluxe" worldwide, yet European promotional material refers to a game titled "Kirby's Return to Dream Land Deluxe" as "a deluxe version of Kirby's Adventure Wii", showing that Nintendo doesn't necessarily consider a changed name for a re-release to mean that the original game's name for that region has changed as well, so we can follow suit here. Also, a bit of an aside, but what box art do we prioritise for the game's article if this proposal passes? Hewer (talk · contributions · edit count) 13:30, July 10, 2024 (EDT)
I'd look to Kirby's Fun Pak (EU), which has been re-released as Kirby Super Star Ultra on DS and then as Kirby Super Star (NA) ever since the Super NES Classic Mini in 2017 (I think Star Fox, too, which was Starwing in the same territories). It seems like Nintendo of Europe is intent on using those releases going forward, and yes, this is relevant as it's the same publisher and we can see a break of pattern. I think we can throw a bone when the tables have turned. (As for box art: does that even need to change when Super Mario Bros.: The Lost Levels's article captions the original unaltered title screen showing Super Mario Bros. 2 as Super Mario Bros.: The Lost Levels? Clean key artwork might be best, but I guess you can make it the European or Australian one.) LinkTheLefty (talk) 20:45, July 10, 2024 (EDT)
Super Star is simply a different case to Return to Dream Land, which still shows that they can give a game's re-release a different name without retroactively changing the name of the original too (my European version of Kirby Star Allies demonstrates this - in the pause screen text that references previous games, Kirby Super Star is named as such, but Squeak Squad and Return to Dream Land still use their European names of Mouse Attack and Adventure Wii respectively). Therefore, a differently named re-release isn't grounds to assume that the original got renamed too (since that did happen with Super Star but didn't with Return to Dream Land). In this case, I don't know of any North American sources about Luigi's Mansion 2 HD that directly refer to the original as "Luigi's Mansion 2", with the only source I know of relating to the game that does refer to original by name still calling it "Dark Moon", so there isn't enough evidence here that the original game also got renamed (though to be honest even if there were American sources for "Luigi's Mansion 2" I'm still not sure if that should override the name that the game was actually released under). Hewer (talk · contributions · edit count) 04:02, July 11, 2024 (EDT)
Star Allies released before Return to Dream Land Deluxe, though, so it's not really a good indicator. LinkTheLefty (talk) 04:14, July 11, 2024 (EDT)
Right, but like I mentioned before, European promotional material says that Kirby's Return to Dream Land Deluxe is "a deluxe version of Kirby's Adventure Wii" (quoted from its page on Nintendo eShop). Hewer (talk · contributions · edit count) 04:17, July 11, 2024 (EDT)

Also, shouldn't this be a talk page proposal, not a "main" proposal? Doc von Schmeltwick (talk) 18:09, July 12, 2024 (EDT)

Because E. Gadd, King Boo and other articles have two names in a section. Windy (talk) 15:37, July 13, 2024 (EDT)

Miscellaneous

Create a list of official hashtags

This proposal targets the creation of an index for social media hashtags that:

  1. relate to the Mario series;
  2. were used or otherwise disseminated by Nintendo, a representative, or any other official partner in the context of a Mario product.

If a hashtag meets these two criteria, it's eligible for inclusion no matter which social media network it's used on. It could be YouTube, Twitter, Facebook, Instagram, TikTok, you name it.

These hashtags count as official content, so I figured what's not to gain from having them gathered up in a historical record? I haven't seen anyone complain about the current list of fonts, which has a similarly huge scope and I assume is currently inexhaustive.

You can see how I envision the list's appearance in my sandbox, but this aspect is not enforced by the proposal and I am open to feedback. As you can see here, the list explains the context of each hashtag, cites references, and includes imagery appended to the hashtags upon use when applicable.

Proposer: Koopa con Carne (talk)
Deadline: July 21, 2024, 23:59 GMT

Create a list of official hashtags, including those relate to both Mario (e.g. "#MarioParty", "#DonkeyKong") and Nintendo in general (e.g. "#NintendoSwitch")

Create a list of official hashtags that only relate to Mario specifically

  1. Koopa con Carne (talk) #perproposal
  2. Hewer (talk) anything to improve our Wiggler Wednesday coverage Sure, per proposal.

Oppose

Comments

I think we're underestimating just how often Play Nintendo uses hashtags. I wouldn't be surprised if a big portion of them are one-offs. Axis (talk) 08:38, July 14, 2024 (EDT)