MarioWiki:Proposals: Difference between revisions

From the Super Mario Wiki, the Mario encyclopedia
Jump to navigationJump to search
Line 68: Line 68:
====Comments====
====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. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 12:46, July 13, 2024 (EDT)
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. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk: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.{{User:LadySophie17/sig}} 13:11, 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 <code><nowiki>class="noresize"</nowiki></code> 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.
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 <code><nowiki>class="noresize"</nowiki></code> 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.



Revision as of 13:11, July 13, 2024

Image used as a banner for the Proposals page

Current time:
Sunday, September 8th, 04:59 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(s) 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. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
  10. 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% support to win. If the margin is only one or two votes, then the first place option must have at least 60% support to win. If the required support threshold is not met, then the proposal is extended for another week.
    • Use the {{proposal check}} tool to automate this calculation; see the template page for usage instructions and examples.
  11. Proposals can only be extended up to three times. If a consensus has not been reached by the fourth deadline, then 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 canceled 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 canceled 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: "September 8, 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

Proposals concerning a single page or a limited group of pages are held on the most relevant talk page regarding the matter. Proposals dealing with a large amount 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 subject page of the talk page 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)
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
Expand use of "rawsize" gallery class, Doc von Schmeltwick (ended July 19, 2024)
Remove excessive Pokémon lists and images, Super Mario RPG (ended August 28, 2024)
^ NOTE: Proposal is requesting image deletions, which require admins
Do not use t-posing models as infobox images, Nightwicked Bowser (ended September 1, 2024)
Create new sections for gallery pages to cover "unused/pre-release/prototype/etc." graphics separate from the ones that appear in the finalized games, Doc von Schmeltwick (ended September 2, 2024)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)
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)
Allow separate articles for Diddy Kong Pilot (2003)'s subjects, Doc von Schmeltwick (ended August 3, 2024)

Writing guidelines

None at the moment.

New features

Expand use of "noresize" 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.

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. Mario (talk) See comment

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)

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="noresize" 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)

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.

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.

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)

Miscellaneous

Decide how to handle identifiers for non-Mario characters

Some subjects that pertain to the Mario series share names with characters from outside franchises that have articles here. The wiki's had a bit of an inconsistency in how these characters are identified in article titles, signalled as far back as when Steve Minecraft was added to Smash Ultimate: on the one hand, the character Big from the Sonic series uses the "character" identifier, whereas the obstacle from Wario Land named "Big" lacks any identifier whatsoever, reason being that the latter pertains to the Mario series (specifically, the Wario branch) and should consequently be prioritized on a wiki titled after Mario; on the other hand, you have the case of Steve from NES Open Tournament Golf (a game billed as part of the Mario franchise) using an identifier to separate himself from Steve the Minecraft avatar, who punches Mario in Super Smash Bros. Ultimate. Let's make up our mind on one universal course for all such instances.

This proposal concerns two parties:

  • one subject that is considered a part of Super Mario or any other franchise that receives full coverage according to the MarioWiki:Coverage policy; hereafter called "Mario-adjacent";
  • any subjects considered a part of franchises outside of the wiki's scope, who share the same name as the aforementioned Mario-adjacent subject and, for one reason or another, have an article or redirect on this wiki.

I chose to consider only one subject on the Mario side because, given two or more Mario-adjacent subjects of the same name, these would already require identifiers as dictated by current policy and thus shouldn't be affected by this proposal's outcome.

With these parties so delineated, I propose three options:

  • Option 1: Both parties, including the Mario-adjacent party, use an identifier.
    • Example: Steve (NES Open Tournament Golf) and Steve (Minecraft) retain this naming scheme.
  • Option 2: Identifiers are added or omitted depending on how prominent a subject is deemed to be. Use identifier(s) only for the less culturally-prominent subject(s), prioritize the most prominent one.*
    • Example: Knuckles (Saturday Supercade) is an obscure character from one episode in a very early Donkey Kong show that is currently in large part considered what kids today call "lost media". Contrarily, Knuckles (Sonic the Hedgehog) is a significant character from one of the biggest video game franchises on the planet for the past 3 decades. It doesn't matter who is Mario-adjacent or not; the Sonic character is more prominent and would be prioritized by dropping his identifier, while the Saturday Supercade character retains his. The Sonic character will contain an {{about}} tag linking to the Mario-adjacent Knuckles, and if an additional three or more non-prominent things named "Knuckles" surface on the wiki, that "about" tag is superseded by a "Knuckles (disambiguation)" page.**
  • Option 3: Do not use an identifier for the Mario-adjacent party, but use identifier(s) for the outside parties, without respect to how prominent one is over the other.
    • Example: Ike (The Super Mario Bros. Super Show!) drops the identifier and takes over the current Ike disambiguation page because the character comes from a Mario cartoon, while Ike (Fire Emblem) retains his identifier due to pertaining to the Fire Emblem games. The Mario-adjacent Ike will contain an "about" tag linking to the Fire Emblem character, and if an additional three or more non-Mario things named "Ike" surface on the wiki, that "about" tag is superseded by an "Ike (disambiguation)" page.**

In any case, the nature of the identifier(s) and the disambiguations that may result from these changes are subject to current naming policy.

* - Whether one subject is more prominent over another may be up to editors to decide on case-by-case basis, though the majority of the cases I've seen are pretty cut and dry, like the one related to the two Knuckles. Use common sense.
** - Per MarioWiki:Naming: "If there are five or more pages sharing the same name, a disambiguation page must be used, although it may be given a "(disambiguation)" qualifier if one of the articles has the plain title."

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

Option 1: Both Mario-adjacent and crossover subjects use identifiers

Option 2: Use identifier(s) only for the less culturally-prominent subject(s), prioritize the most prominent one

  1. Hewer (talk) Per naming policy, "if there is one subject that is clearly more popular than the others, the popular subject will keep the original title while the others use identifiers". I don't see much of a reason to make an exception for crossover characters. Sure, they're not from Mario originally, but they are related to Mario, otherwise they wouldn't be covered here. People who search "Knuckles" are extraordinarily more likely to be looking for the echidna, and they have every reason to be since we give full coverage to the Mario & Sonic series of six games (more if you count the paired releases individually) where he is a fully playable character in every installment, compared to a one-off supporting character in an ancient and highly obscure show that we only cover the DK and DK Jr. segments of. I don't really see why being a non-Mario character by origin is a reason to be excluded from the usual identifier rules, since it doesn't really correlate to the likelihood of them being searched for (which is what identifier rules are based on).
  2. SolemnStormcloud (talk) Per Hewer.
  3. JanMisali (talk) Per Hewer. If we were to make a ruling for which subject with a shared title has priority as the primary subject, prioritizing subjects based on how often they appear in Super Mario-related media makes more sense than prioritizing subjects based on how closely connected to the greater Super Mario franchise their origins are.
  4. Pseudo (talk) Per Hewer and JanMisali.
  5. Camwoodstock (talk) Per all.
  6. FanOfRosalina2007 (talk) Per Hewer and JanMisali.
  7. Mario jc (talk) Per Hewer and my comment here.
  8. Arend (talk) Personally, I think which subject gets prioritized should be based on in how many (relevant) Mario titles it has appeared (e.g. Knuckles the Echidna has appeared as a main playable character in a ton of Mario & Sonic titles, while Knuckles the gangster only appeared in a single Saturday Supercade episode), but this is close enough.

Option 3: Use identifiers only for the crossover subjects, prioritize the Mario-adjacent subject

  1. Koopa con Carne (talk) Per what I said here.
  2. LinkTheLefty (talk) I'm with Koopa con Carne. It makes sense to give priority to core-franchise characters over off-franchise ones, and I don't see this as anything that well-placed "about" templates can't solve.
  3. SeanWheeler (talk) I think this proposal that had use removing the crossover character's surnames was the reason that we're having this problem. And I would like that overturned, especially with other proposals shortening character names failing. And even for crossover characters with just one name that weren't shortened by that proposal, it would be good to have an identifier to distinguish them from Mario subjects. Popularity is subjective. People would come here for information about the Mario games, so Mario subjects should get the simplified names while the crossover subjects should have more specific titles. That way, people looking up obscure Mario characters won't be taken to a Sonic or Smash article.

It doesn't matter

Comments

For the record, if the "most prominent subject" option passes I'd be interested in generalizing that into a formal policy, replacing the "clearly more popular" clause in MarioWiki:NAME. "Popularity" is difficult to define and cases where it's "clear" which subject is more popular are somewhat rare, but prominence is a somewhat more straightforward concept. Neither the Super Paper Mario character named Red nor the WarioWare character named Red are "clearly more popular" than Red from Pokémon (who doesn't have a dedicated article, and when he did it wasn't at "Red"), but the WarioWare character is clearly the most "prominent" in Super Mario-related media of the subjects named "Red" that have dedicated articles. jan Misali (talk · contributions) 12:12, July 7, 2024 (EDT)

Seems sensible to me. Pseudo (talk) (contributions) User:Pseudo 12:19, July 7, 2024 (EDT)
The proposal mentions the concept of prominence in a cultural sense, less so in reference to gameplay or story. Let's say Pokemon Trainer is renamed "Red" in future Smash Bros games and the wiki uses that name on List of fighters debuting in Super Smash Bros. Brawl; under option 2 of this proposal, the page Red (no identifier) would redirect to that character, because he is decidedly so much more culturally significant than anything else on the current disambig for Red (he was the playable avatar in the games that kicked off the biggest media franchise on the planet). -- KOOPA CON CARNE 12:22, July 7, 2024 (EDT)
To be clear, I do think relevance and significance to the Mario franchise should be considered, I just don't think that's as simple as everything that wasn't originally Mario automatically being less significant. Despite Supercade Knuckles being originally Mario, he's ended up less prominent in the franchise than the echidna. Hewer (talk · contributions · edit count) 12:31, July 7, 2024 (EDT)
Yeah, I suppose that isn't exactly what I would want, but I do think that's preferable to the alternatives given here at least. Prioritizing Super Mario-ness could run into a different hypothetical future where a Mario RPG has some key item called a "link" (as in part of a chain), which would mean moving Link to "Link (character)". Or, in a contrived more extreme example, if a new character named "Wart" is introduced in a Mario-branded game, that would take priority over Wart, a character from Doki Doki Panic (which the wiki covers but does not give complete coverage, as the proposal suggests). jan Misali (talk · contributions) 12:36, July 7, 2024 (EDT)
I've been interpreting "most prominent" here to be used with the same meaning as "most popular" in the naming policy. Regardless of what the literal definitions of the words may be, the point is that the subject without the identifier should be the one people who search the name are most likely to be looking for, hence the policy advises considering which page is more "likely to be linked to or searched for". Hewer (talk · contributions · edit count) 12:25, July 7, 2024 (EDT)

@Everyone: Would you consider it relevant if I split option 2 into an option that includes redirects (e.g. Ike (Fire Emblem)) and one that excludes them? I personally think this action would be more thorough, but I'd like to know your opinions first. -- KOOPA CON CARNE 12:39, July 7, 2024 (EDT)

I don't think we need to vote on making redirects, they feel like they should generally be a given. Hewer (talk · contributions · edit count) 13:01, July 7, 2024 (EDT)
I guess my question was poorly formulated. Should redirects to a non-Mario subject be prioritized if the corresponding subject is the most prominent, or not? For instance, the page "Ike", currently a disambig page, would be repurposed to redirect to the Fire Emblem fighter. -- KOOPA CON CARNE 13:05, July 7, 2024 (EDT)
Generally a subject not even significant enough to have its own page is unlikely to be the one without the identifier, but sure, I say we should continue handling that case-by-case in the same way as with articles. Hewer (talk · contributions · edit count) 13:15, July 7, 2024 (EDT)
What would be the point of a disambiguation page between two pages, one being a redirect to section on a list page? The dog would be better off as just Ike with a {{Distinguish}} template linking to List of fighters debuting in Super Smash Bros. Brawl#Ike. SeanWheeler (talk) 18:42, July 7, 2024 (EDT)
I guess the point would be if we really can't decide which subject should get the identifier, e.g. if they were roughly equal in likelihood of being searched for (but I'm not sure that applies to Ike). Hewer (talk · contributions · edit count) 18:48, July 7, 2024 (EDT)

@SeanWheeler: Popularity is how we determine what gets identifiers across the whole wiki, and that won't be changed by this proposal - option 2 passing would just make that consistent for crossover subjects as well. The idea that people are automatically less likely to be looking for something on this wiki because it didn't originate from Mario is simply incorrect - we're only covering crossover subjects because of their relevance to the Mario franchise, and I feel like barely anyone searching "Knuckles" is really looking for the Saturday Supercade character rather than the Sonic character. I also disagree that the proposal you link to is relevant to this one, especially since I specifically made it so that no crossover characters would take priority over Mario characters after being told to in the comments and not really thinking to question it at the time. Also, as an aside, I'm unsure what "other proposals shortening character names failing" you're referring to - I can only think of the Koopalings one from a couple years ago, which has since been outnumbered by successful shortenings like Professor E. Gadd, Baby DK, etc. Hewer (talk · contributions · edit count) 18:48, July 7, 2024 (EDT)