Please remember that WiKirby contains spoilers, which you read at your own risk! See our general disclaimer for details.

WiKirby:Proposals/Archive

From WiKirby, your independent source of Kirby knowledge.
Jump to navigationJump to search
Successful proposals archives
Proposals passed in 2023
Proposals passed in 2022
Proposals passed in 2021
Proposals passed in 2020

The following proposals have been successfully passed by WiKirby's community. For older proposals, check the box to the right:

Proposals[edit]

Standardizing Discussion of Regional Differences (April 17, 2024 - May 1, 2024)[edit]

This is a problem I've had for a while now; I feel like the way we discuss regional differences is really unclear because it's focused on being too precise to the point of pedantic. Other wikis handle this in a more clear manner, so I feel like we should have a clear set of guidelines when discussing regional differences. These can probably go in the WiKirby:Localization policy.

  1. Prioritize American English in any instance where one language is required. Plain and simple; WiKirby is based in the US, so our articles use American English (the same reason why we voted to remove the LangSwitch template, as nobody was actively switching into British English). In this case, this would be related to page quotes and such where there are differences between the American English and British English versions. While we can list both in other sections, in places like page quotes where it's preferable to only have one, it would be best to prioritize the American version (see old versions of Landia for example, where it was cluttered by listing both versions of the quotes even though they only have minor differences).
  2. When discussing regional differences, discuss only the versions that are pertinent. For example, on Parallel Meta Knight, we have this: "The English, French, Italian, German, Spanish and Dutch localizations of Parallel Meta Knight's pause flavor text misinterpret his origin. As the original Japanese and localized Chinese and Korean texts describe:" That just leads to a signal-to-noise trainwreck; the pertinent versions to discuss here are the Japanese version (the original text) and the English version (the language the wiki uses). Mentioning the others is putting undue weight on a minor note. We can note somewhere that the Korean and Chinese versions generally follow the Japanese version while all other languages follow the English version. In cases where certain languages have peculiar differences, it's fine to mention them; for example, that Whispy Woods is localized as female in the Brazilian Portuguese version, or that the Mint Leaf is not a Sweet Potato in the Korean and Chinese versions. But if they follow the Japanese version or the English version identically or near-identically, it isn't worth noting. (Obviously, this wouldn't apply to the "names in other languages" section.)
  3. Using the terms "PAL" or "NTSC" to describe regional versions is fine. Nintendo officially used the term PAL to describe regional versions of their home consoles and games from the NES all the way up to the Wii, as they were designed to be used for PAL televisions. I can understand not wanting to use it for handhelds or for the Wii U or Switch, as this terminology is based on analog signals that are no longer used, but at least for the NES through the Wii, it is not only valid but official and commonly used terminology. Right now it's commonly switched to "British English", which is not accurate, or "European", which is fine but lacks coverage for Oceania. The same can also apply to NTSC being used for the North American and Japanese versions.
  4. Avoid the constructs "in American languages", "in European languages", etc. when referring to regional versions. For example, on Kirby Super Star or Kirby and the Rainbow Curse. In the former case "NTSC" and "PAL" would be fine, while if we want to avoid using "NTSC" and "PAL" in the latter case, then I think it would be better to just say the regions they were designed for and sold in; in the Americas, in Europe and Oceania. It can lead to confusion; for example, French comes from Europe, but Canada is part of America, so is Canadian French a European or an American language? It's not worth dealing with that question when we can just say "in the Americas".

That's my basic thoughts, anyway. I'm sure things can be ironed out more, but I want to standardize this so we avoid conflict and unnecessary confusion. StarPunch (talk) 23:42, 17 April 2024 (UTC)

1. Prioritize American English in any instance where one language is required.[edit]

Support
  1. No hesitation here. It’s so annoying to see two painfully similar versions of the same quote side by side. Even when we use tabs to show only one at a time, it doesn’t work right on mobile. It’s just like the userlang templates: more trouble than it’s worth. -YFJ (talk · edits) 00:17, 18 April 2024 (UTC)
  2. We are an American English-based wiki after all, so it only makes sense to go in this route. – Owencrazyboy17 (talk) 00:24, 18 April 2024 (UTC)
  3. I agree, pages listing both English versions can get really cluttered and often the differences are minimal and not really worth listing. If we really wanted to document them just for completion's sake, we could do elsewhere, but this is outside the scope of this proposal I feel. - Gigi (talk • edits) 00:36, 18 April 2024 (UTC)
  4. Details in discussion below, but 100% supported. ~ by Waddlez! 00:56, 18 April 2024 (UTC)
  5. We use one version of the language for article text, it makes sense to have that one version used for quotes in article bodies. ---PinkYoshiFan 01:02, 18 April 2024 (UTC)
  6. Supporting. I think clarity for the reader should be prioritized over "technical accuracy" of terms or trying to meticulously cover all regional differences even where it's just a difference in punctuation, regional spelling, or capitalization. --Samwell (talk) 04:30, 18 April 2024 (UTC)
  7. Agreed, for consistency sake and to avoid clutter. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 05:34, 18 April 2024 (UTC)
Oppose
Neutral

Discussion[edit]

I agree that choosing a localization is the best call. However, I think sometimes there are some times where it's at least worthwhile to highlight some differences, even if it only happens very rarely. In the cases where British English or another language has meaningful differences, I think that has potential value - again, it is rare. I also think that considering how rarely the Japanese, Chinese, and Korean releases deviate from one another, it would be useful to establish some kind of name for that. Personally, the term I use when discussing them is "East Asian versions", but I understand that might have some minor confusion. Perhaps "source release" or something else? ~ by Waddlez! 00:56, 18 April 2024 (UTC)

From what I'm understanding, what you are discussing covers more point 2, I think? These are addressed there (at least partly). - Gigi (talk • edits) 01:18, 18 April 2024 (UTC)

2. When discussing regional differences, discuss only the versions that are pertinent.[edit]

Support
  1. Probably best for simplicity. Of course, we should definitely mention somewhere which of the two other languages tend to follow, and perhaps point out when games deviate from this. -YFJ (talk · edits) 00:17, 18 April 2024 (UTC)
  2. In hindsight, stuff like the aforementioned Parallel Meta Knight example would clutter some stuff up, especially if we're usually only dealing with differences between the original source language (usually Japanese) and the primary English translations spun off of that. Makes sense to keep it simple, instead of overcomplicating things. – Owencrazyboy17 (talk) 00:24, 18 April 2024 (UTC)
  3. I agree, in particular when the games keep getting translated to more and more languages, who knows who many languages we will have to list in the future. I do want to point out we should mention somewhere that most languages translate from English, and Korean and Chinese are closer to Japanese, but unsure where at this point. - Gigi (talk • edits) 00:36, 18 April 2024 (UTC)
  4. Agreed, no need for mentioning every language individually for how things are localized. ---PinkYoshiFan 01:02, 18 April 2024 (UTC)
  5. Agreed, for the reasons I stated in the first point. --Samwell (talk) 04:31, 18 April 2024 (UTC)
  6. When it's relevenat? Yeah, absolutely mention versions. When it's not a distinction unique to a specific language then no one cares, and it's just bothersome to fill in. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 05:34, 18 April 2024 (UTC)
Oppose
Neutral

Discussion[edit]

3. Using the terms "PAL" or "NTSC" to describe regional versions is fine.[edit]

Support
  1. As long as they see official usage, I see no reason why we can’t use them. But they are outdated standards and I’d avoid them for newer games where this official distinction is not present. -YFJ (talk · edits) 00:17, 18 April 2024 (UTC)
  2. I think we've discussed this enough to the point where it's pretty aparent that NTSC and PAL are widely understood by the gaming community even today, and was how most games were classified when consoles were region locked. It's true, nowadays not so much, in particular since most games now have only one version and just various languages, but when I had to buy Wii games, I always asked for NTSC versions. Owen failed to mention, but South America also is NTSC when it comes to games, even though it's a split between the countries. In Brazil we had PAL TVs but played NTSC games in them. In short, this is a system that isn't directly tied to TVs but that is still widely understood and not exclusinary. If we say "European", we exclude Australia, but if we say "PAL", we do not. If we say "NA", we exclude all of South America, but if we say "NTSC" we do not. For simplicity sake, and with inclusion in mind, I see only reasons in favor of this. - Gigi (talk • edits) 00:36, 18 April 2024 (UTC)
  3. If they're officially used, no reason not to use them ourselves. ---PinkYoshiFan 01:02, 18 April 2024 (UTC)
  4. Soft support on this one, as long as it's being used in the proper context, and isn't being used to describe regional differences in modern hardware or software. All in all, I think hyperfixating on whether this term is "technically" correct or not is unimportant as long as it's clear from the context. --Samwell (talk) 04:44, 18 April 2024 (UTC)
Oppose
  1. Heavy, heavy, heavy, heavy, HEAVY oppose across the board for super, duper, ultra, hyper, mega, ultimate, super-deluxe, big, giant, massive, perfectly-explainable reasons!
    Now, yes, StarPunch is correct when stating that Japanese, North American and South Korean releases of games were primarily designed with the NTSC standard in mind, with European and Australian releases designed with the PAL standard. She's also correct when saying that people still use such terminology for video games. But various game developers and publishers would not agree with such statements. In the past, anytime such mentions were present on game box art or in promotional materials, it's literally there to mention the video standard the game cartridge or disc was developed in and nothing else, like on various VHS tapes, Laserdiscs and DVDs. That's not covering the fact that some 50Hz video games can actually be made to run at 60Hz on a game-by-game basis, which further muddles the waters. Not to mention, if a kid goes on an article and reads up about a certain 'NTSC version,' they'll probably think 'What the heck is an NTSC?!' But that was "then." This is "now." And "now," at least in reference to said older video games, such releases are no longer referred to as such.
    1) Most of the various N64, Game Boy and GBA titles on Nintendo Switch Online feature both NA and EU versions of their games appropriately labelled "NA and EU versions" (short for North American and European versions) in the Settings menu.
    2) Some titles like Super Smash Bros. Ultimate may make reference to certain other game titles and/or release dates. In circumstances where they differ in European materials, it's always stated to be "in Europe" not "in PAL", even for older software on the applicable hardware at the time of its original release (e.g. "Kirby Super Star on the SNES (originally known as Kirby's Fun Pak in Europe) was the first Kirby game where two players could team up.", "Luigi's first break as a main protagonist was in Luigi's Mansion, released in Europe in 2002.", "Ness debuted in EarthBound, a game that never made it to Europe on the SNES, but finally came over on the Wii U Virtual Console in 2013.", "Jigglypuff's debut was in the very first Pokémon games, released in Europe in 1999.", "Villager's European debut was in 2004 in Animal Crossing, a game about enjoying a peaceful village life with a variety of animal neighbors.", etc., etc.).
    I can further make arguments in the comments section if need-be, but for now, this wall of text should suffice as to why we shouldn't keep using such outdated terms on a wiki like this, even for older titles and their ancillary materials. – Owencrazyboy17 (talk) 00:24, 18 April 2024 (UTC)
Neutral
I have no strong opinion on the subject. It's simpler to use 3-4 letters, but not everyone might know what they mean, and I don't know where it's correct to use. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 05:34, 18 April 2024 (UTC)

Discussion[edit]

4. Avoid the constructs "in American languages", "in European languages", etc. when referring to regional versions.[edit]

Support
  1. English is a European language, so this distinction is functionally useless anyway. -YFJ (talk · edits) 00:17, 18 April 2024 (UTC)
  2. Support, but maybe change the constructs into "in the North American translations" and/or "in the European translations" where applicable. Just a thought. – Owencrazyboy17 (talk) 00:24, 18 April 2024 (UTC)
  3. Agreed, language isn't really tied to continent. ---PinkYoshiFan 01:02, 18 April 2024 (UTC)
  4. Agreed. I think this is how it was done originally, but for whatever reason, the focus was changed to the "languages". I think that was a misstep on our part that we allowed that to happen. --Samwell (talk) 04:46, 18 April 2024 (UTC)
  5. Agreed, per YFJ's statement above. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 05:34, 18 April 2024 (UTC)
Oppose
Neutral

Discussion[edit]

I think simply replacing "languages" with "versions" would ease this element of the proposal. ~ by Waddlez! 01:00, 18 April 2024 (UTC)

Oh, true! That... completely slipped my mind, LOL. StarPunch (talk) 01:04, 18 April 2024 (UTC)

Standardized Boss Moves Locations (April 6, 2024 - April 20, 2024)[edit]

Hi! We currently have boss moves put somewhat unevenly around the wiki, with some bosses having their moves recorded on their personal pages (King Dedede, Dark Matter Clone, etc.) and at least one boss I can't track down has them on their stage page. I think these should be standardized, and specifically I think they should go to the boss stage pages. This is because:

  1. Wiki-assisted players will have the convenience of the information being on the boss page, instead of having to go somewhere else to find the knowledge they need.
  2. This will put relevant information on boss stage pages, most of which aren't stubs, but still fairly short due to their nature of being mostly just an arena (except such as in Kirby Star Allies but it still won't hurt).
  3. This will mildly slim down several character pages, only having a major impact for the already lengthy pages of King Dedede and Meta Knight, and it doesn't much impact any other boss.

Thoughts? ~ by Waddlez! 23:02, 6 April 2024 (UTC)

Option 1: move to stage page[edit]

  1. My only preferred choice. ~ by Waddlez! 23:02, 6 April 2024 (UTC)
  2. Second choice. I can see the merit in having the info on the stage page, although ultimately we're not a strategy guide. Also any standardization is better than none. ---PinkYoshiFan 23:44, 6 April 2024 (UTC)

Option 2: move to boss's character/other page[edit]

  1. First choice. It's the moveset for the character, so it should go on their page. ---PinkYoshiFan 23:44, 6 April 2024 (UTC)
  2. Primary (and only) choice. Not just because the attack tables would be better off for the character but also because of a potential problem regarding bosses exclusive to circumstances like The Ultimate Choice. More details in the Discussion section. – Owencrazyboy17 (talk) 23:55, 6 April 2024 (UTC)
  3. Single choice here. As stated, this is the boss character we're talking about, so it wouldn't make as much sense to put the move-set where the boss appears when the boss has its own page.--Paistrie (talk) 16:00, 10 April 2024 (UTC)
  4. It makes far more sense to me to list all the moves on one page given that boss moves tend to evolve over time. We could easily use an {{main}} on stage pages to link to the move listing page wherever that is. --Basic Person (talk/contribs) 19:36, 11 April 2024 (UTC)
  5. I think having boss moves on their own makes the most sense for bosses and I think it'd be best to have these instead of putting them on location pages, mostly because it would be awkward for bosses that only appear in Arena modes. NVS Pixel (talk) 13:14, 12 April 2024 (UTC)
  6. First option, and this is already what we do. Stage pages don't make sense when Kirby has many bosses exclusive to game modes like arenas, and putting boss details there would make giant pages. A boss page should cover info about a boss, and a stage page info about the stage. - Gigi (talk • edits) 13:36, 12 April 2024 (UTC)

Option 3: make no changes[edit]

  1. Second option, although this is essentially the same as option 2, as we already only put boss moves in boss/character pages. For reasoning, same as option 2. - Gigi (talk • edits) 13:36, 12 April 2024 (UTC)

Discussion[edit]

I thought of a bit of a major issue when it comes to option 1. Say, for example, a boss was fought exclusively in The True Arena or another location or mode with no defined stage count. If option 1 passed with the majority of votes...then how on earth would an attack table for a boss like Chaos Elfilis even work?! Wonder if there's some sort of solution that I'm not seeing... – Owencrazyboy17 (talk) 23:55, 6 April 2024 (UTC)

I'd just put it on the Colosseum page under an exclusive boss heading, myself. They wouldn't be the only exclusive boss there... I get why that might not be appealing to some if the page is just intended to describe the mode but I think that's a good solution should option 1 be passed. Alternatively, special cases could be made for them, but that'd ruin the whole standardization idea.
I'm not fond of putting it under character pages because seeing what a boss uses in each fight over a vast number of games really isn't as useful as having info about the boss in the page about where you fight it, in my opinion. ~ by Waddlez! 00:04, 7 April 2024 (UTC)

Like I mentioned on Discord, I am a bit confused on this proposal's existence. As far as I know, where to put boss attacks is already standardized, and that is to say to put it in the character/boss page, which would make option 2 and 3 the same. - Gigi (talk • edits) 12:44, 10 April 2024 (UTC)

I can see the merit of moving it to the stage pages, as this would help somewhat with clogged character pages or pages for characters with multiple boss appearances where the moveset just gets listed over and over again (for example, King Dedede, Meta Knight, Kracko). I find those inconvenient. But I'm not sure if that's the proper solution to the problem, when it's probably a deeper underlying problem we can find a better way to handle. StarPunch (talk) 16:23, 10 April 2024 (UTC)
On Discord I proposed for recurring characters that are also bosses (mostly Dedede and Meta Knight) we should have separate boss pages for them, so that's another idea. That in general appears to be a problem for characters that appear in more than one game and aren't always bosses. - Gigi (talk • edits) 13:39, 12 April 2024 (UTC)

My only question is why not both, and for boss stages specifically. I know it'd be a huge clutter for Arena pages, but if we limit it to the stages (which describe hthe playthrough anyway), I could see having a more easily accessible table. Then again, the main template exists for a reason... ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 05:34, 18 April 2024 (UTC)

Add a guideline to discourage edits that don't correct or add any new information (April 10, 2024 - April 19, 2024)[edit]

Mentioned this a couple times in the past week or so about this, and finally it's time to make it a proper proposal.

For context, while not that common, sometimes there are edits on WiKirby that simply change a part of the text to one thing or another and both the version before and after the edit are correct and not incomplete. Two major examples are adding or removing the Oxford comma, and adding or removing contractions to words (don't to do not, for example, and vice-versa): both are correct in English, so there is little to no point in changing from one way or another. In particular, due to both ways being correct, this can easily create a dispute between editors, and in the end there is no real resolution as there is no one way that is more correct or incorrect. So, in a similar vein to other past proposals (see here and here), my proposal is to add a new mantra to the writing specifics, that is something like:

Don't correct what is correct - Unless something is incorrect, don't correct it.

(The above can be reworded of course, this is just my first idea, feel free to suggest changes)

Also, for clarification, this is not to say that we shouldn't change European English spelling to American English, that is a guideline we have on WiKirby to prefer American English stuff so that is unrelated to this proposal, and any other specific rules we may have about how to write things is also unrelated to this proposal. To put it another way, if there is no specific guideline on WiKirby to say we should say one thing one way or another, an editor shouldn't come to a page to just change it because they prefer it another way. While this mostly applies to spelling, this could be expanded to for example to changing mentions of NTSC and PAL to North American and European: as there's no rule (at least right now) on WiKirby to prefer one way or the other, there shouldn't be edits to "correct" these one way or the other.

What do you all think? - Gigi (talk • edits) 16:13, 10 April 2024 (UTC)

Support
  1. Agreed, there's no real reason to change things that are correct. ---PinkYoshiFan 16:18, 10 April 2024 (UTC)
  2. Right, there's definitely a distinction to be had between fixing up writing to match the writing guidelines and just doing pointless style edits that don't add anything. A lot of wikis have a similar mantra, sometimes phrased as "first come, first served". If it's not incorrect, there's no need to do an edit solely to change it to your preferred style. Whatever is there first should stay there, as long as it's correct and consistent. StarPunch (talk) 16:23, 10 April 2024 (UTC)
  3. I also agree. As was previously stated, if the initial wording was perfectly fine...why bother changing it? The only exception for me is applying that train of thought to using outdated video signal terminology for regional video game releases (especially since modern sources like NSO go with the standard "NA and EU version" route), but I don't think it's that pressing a concern right now. – Owencrazyboy17 (talk) 16:48, 10 April 2024 (UTC)
  4. Supporting. Spelling is definitely something some people have strong opinions and preferences, even when both options are correct, so having a policy like that to prevent arguments is good. Superbound (talk) 19:18, 11 April 2024 (UTC)
  5. I think this is a good thing to clarify. That said, I should warn you now that this likely will not stop certain users from insisting that certain things (like the Oxford comma situation) are correct, so it probably won't stop most edit wars on these grounds. At the very least, it gives the admins firmer ground, so supporting regardless. --Samwell (talk) 19:26, 11 April 2024 (UTC)
  6. I concur with those above about this subject. However, I feel as though the current proposed message could be a bit more descriptive and outright include some along the lines of: "No minor wording changes" just to be more specific and clear. --Basic Person (talk/contribs) 19:36, 11 April 2024 (UTC)
  7. I support the proposal, however I do think that we need exact definitions of what is and what isn't correction-worthy. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 05:34, 18 April 2024 (UTC)
Oppose
Neutral

End deletion of permabanned users' talk pages (1\26\2024 - 2\9\2024)[edit]

As is stands currently, talk pages of permanently blocked users get deleted. However, sometimes the content on the user talk page is the reason they get permanently blocked, and even if not, they can still be a part of wiki history. As such, I'm proposing that we stop deleting talk pages of permanently blocked users (and undelete the talk pages of previously blocked users). However, since there can be cases where the talk page isn't important, there are options for only deleting them if the talk page is irrelevant to why they were blocked (e.g. they just started vandalizing pages) or only if it's empty (just the Kirbot message). In any case, kept talk pages of permanently blocked users would be protected to prevent editing, effectively archiving them. ---PinkYoshiFan 18:19, 26 January 2024 (UTC)

Option 1: Always keep
  1. Second choice, though I doubt there’d be much value in keeping pages with Kirbot only, everything else here is the same as option 3. -YFJ (talk · edits) 21:25, 26 January 2024 (UTC)
  2. Second choice. While I don't see a reason to keep empty talk pages around, there's not really any harm keeping them either. ---PinkYoshiFan 21:28, 26 January 2024 (UTC)
  3. Second choice, no harm in doing so but no use in it either. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:41, 27 January 2024 (UTC)
  4. Second choice, I don't see any downside with keeping these pages. NVS Pixel (talk) 16:56, 2 February 2024 (UTC)
  5. This is my second choice. I'll admit that keeping any talk pages that's just the bot-generated welcome message might be clogging things a bit, but working together with others is give-and-take, after all. – Owencrazyboy17 (talk) 17:41, 2 February 2024 (UTC)
  6. First choice. If we are going to stop deleting them, might as well keep it simpler and not delete any of them. I will admit I'm not a fan of deleting stuff so this is in part why I lean more to this. - Gigi (talk • edits) 22:10, 5 February 2024 (UTC)
  7. It always baffled me a little that we do this. Interaction on user talk pages are often a showcase of user's conduct, so deleting them feels like hiding evidence to me. Superbound (talk) 15:59, 8 February 2024 (UTC)
Option 2: Only delete if irrelevant to why they were blocked
  1. Third choice. It’s somewhat subjective as to what’s relevant and what isn’t, but at least this way we keep the important parts. -YFJ (talk · edits) 21:25, 26 January 2024 (UTC)
  2. Third choice. Reasonable if we want to be minimalistic, but everything can count, as long as the talk page isn't empty. If something exists on the talk page other than the welcome message, that is valuable by itself. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:41, 27 January 2024 (UTC)
  3. Third choice. I agree it is subjective on what is relevant and what isn't and I can see this sparking pointless debates over users who aren't here anymore. NVS Pixel (talk) 16:56, 2 February 2024 (UTC)
  4. This is my third choice. Other users have pointed out how it can be difficult to reasonably determine what counts as a "relevant" talk page, but I'm sure that can be sorted out on a case-by-case basis, whether on the Discord server on on other user talk pages. – Owencrazyboy17 (talk) 17:41, 2 February 2024 (UTC)
Option 3: Only delete if empty
  1. First choice. You know, I actually think that these pages should be kept. That way, they could be used as examples of what NOT to do (or how to respond to people) on this Wikipedia. If the pages don't have anything on them though, then they could be deleted. --Paistrie (talk) 18:35, 26 January 2024 (UTC)
  2. First choice. Seems like a given to delete pages that only have the welcome template, but otherwise there could be useful content on the talk page to keep. I’d also say this should apply retroactively—that is, while we’re not required to undelete every blocked user talk page in the wiki’s history, it should remain an option. -YFJ (talk · edits) 21:25, 26 January 2024 (UTC)
  3. First choice. I don't really see a reason to keep the talk page around if it's empty save for the default welcome message. ---PinkYoshiFan 21:28, 26 January 2024 (UTC)
  4. First choice, per the reasoning of others. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:41, 27 January 2024 (UTC)
  5. First choice. Makes the most sense and there's no reason to keep these pages if they're empty. NVS Pixel (talk) 16:56, 2 February 2024 (UTC)
  6. This is my first choice, for reasons already stated. If the reason a user got blocked happened solely on their talk page, for instance, and it's not there anymore...then how are people supposed to figure out from a glance what caused them to get banished to the shadow realm? On the other hand, if nothing of interest is on their talk page besides the bot-generated welcome message, then there's no harm in getting rid of it. Per all. – Owencrazyboy17 (talk) 17:41, 2 February 2024 (UTC)
  7. Second choice. I suppose that if we don't want to keep things super simple, this one makes the most sense, as option 2 could be a bit arbitrary in some cases, and this one is objective. - Gigi (talk • edits) 22:10, 5 February 2024 (UTC)
Option 4: Keep deleting (no change)
Neutral

Discussion[edit]

Would this apply retroactively or just for users blocked after the proposal passes, if it passes? - Gigi (talk • edits) 18:40, 26 January 2024 (UTC)

It's retroactive. ---PinkYoshiFan 21:28, 26 January 2024 (UTC)

Allow qualifiers in (music) redirects (Jan 25, 2024 - Feb 8, 2024)[edit]

I will keep this concise, since de facto what I am about to suggest is already done in practice despite its status in theory.

Per our Deletion policy, if "[pages] are redirects containing qualifiers in parentheses", they are the deemed "suitable for deletion". This rule has been ignored in a few cases for music pages, all of which I believe have a solid reasoning:

  1. A theme named after a subject with an existing article's name is a partial arrangement of something else (such as "Secret Island (theme)" for "Fountain Gardens (theme)", "Circuit Speedway (theme)" for "Welcome to Wondaria (theme)".
  2. The case above, but an official name of the base version or a direct remix exists but is not the name of the article (applies to "Goal Game (theme)" in the context of "Sparkling Stars (theme)", and the proposal was sparked for "Cookie Country (theme)", an early official name for "Four Adventurers: Cookie Country".

I think that if a redirect is an official title (which... it should be?), it doesn't actually matter if it has qualifiers or not. It's better to have a redirect with qualifiers than force the reader to figure it out by their own (such as guessing that "Four Adventurers" is a part of the name for Cookie Country's theme). I believe the same could be said for any case besides music as well, although I don't know any examples to go off of. In any case, I'm formalizing the discussion so we can settle it once and for all. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 22:57, 25 January 2024 (UTC)

Support
  1. Full support. I never understood why redirects with qualifiers are not allowed ever. The argument of "no one uses then" feels, really weird and makes me go "citation needed". I'm the believer that anything with an official name needs to be at least a redirect, since maybe someone will search that term and we can help them guide them. This is particularly useful for music pages, as explained, but also other cases exist (like Waddle Dee (novel character) also being named Bandana Waddle Dee). My only note is that we should clarify somewhere that we shouldn't create multiple redirects with qualifiers for the same name (ie. have stuff like "Cookie Country (theme)", "Cookie Country (music)" etc, or even things like "Kirby (character)" redirecting to Kirby). - Gigi (talk • edits) 11:22, 26 January 2024 (UTC)
  2. Support. I can easily see them getting used by people who are searching for old names or remixes, and there's no real downside to having more redirects if they help the reader. Also agree with the thing Gigi mentioned about not making multiple qualifiers. ---PinkYoshiFan 17:14, 26 January 2024 (UTC)
  3. Agreed. There's always gonna be at least one person who can't find what they're looking for, so qualifiers feel like a really good thing to have. ~☆Starvoid⁠☆ (t · c) 03:44, 27 January 2024 (UTC)
  4. Support. It feels important that we help readers find whatever they need and I think allowing qualifiers will help with that. NVS Pixel (talk) 17:06, 2 February 2024 (UTC)
Oppose
  1. I’m not so sure about this one. I honestly can’t see many people typing in a “theme” qualifier to find a stage theme. More likely, they’d go to the stage infobox and see the theme there. Furthermore, in one case you mentioned, Cookie Country already has a redirect template to direct people to the theme. If the qualifier were actually part of the song name, that’d be another story, but that’s almost never the case. What it all boils down to is that we don’t have identifier redirects because people don’t use them, and I fail to see how music pages are any different. -YFJ (talk · edits) 23:53, 25 January 2024 (UTC)
Neutral

Discussion[edit]

Expand trivia policy to better explain what can and can't be trivia (Jan 12, 2024 - Jan 26, 2024)[edit]

WiKirby's quality standards have always been high, and they keep going up, which I personally consider a good thing. However, sometimes we raise the standards without knowing and don't formalize it, which is what this proposal is about.

So, Wikirby has a very good trivia policy. In particular, we have limits to size of trivia to avoid what happens in many other wikis where the trivia section becomes so big it's sometimes even bigger than the article's main body. However, one issue that I still see happen is that many times trivia points are added, and then a more experienced editor comes and either removes the trivia point entirely, or moves it to the article's main body. There's nothing wrong with that, for the record, but I've realized lately that we have no formal guidelines that tell us to do that. We do have instead a lot of unwritten rules, that some more experienced editors appear to just know, but it feels unfair to newer editors.

With that in mind, and also with the hope to further increase WiKirby's high quality standards, I've put together a draft of a section I would like to add to the trivia policy, a section that defines what is and isn't trivia as best as possible. Sure, this is not a black and white thing, but this was my attempt to write those unwritten rules I talked about. I feel the way to summarize what I want is that I want trivia to be the last place we should put something. Really, only if it doesn't fit anywhere else. Trivia usually is like the default section to add something new when you don't know where to fit it, and while in a way that's good, in another that feels like not a good practice for people who want to learn of policies of the wiki. If that makes sense.

Also, just to be clear, the draft I linked is that, a draft. Feel free to suggest any changes, but that's the overall content I want in that section. If this passes, I likely won't just copy and paste that, I will do a revision with comments presented alongisde other admins.

What all that said, what do you all think? - Gigi (talk • edits) 12:26, 12 January 2024 (UTC)

Support
  1. Agreed, standardizing what qualifies as trivia seems good. ---PinkYoshiFan 12:40, 12 January 2024 (UTC)
  2. Agreed, the current trivia policy is too unspecific. I am never sure what is supposed to be in trivia. Expending the policy will lead to less confusion. SilvTheGrape (talk) 13:01, 12 January 2024 (UTC)
  3. Agree. The points made are common sense, formalizing unspoken rules will only benefit the system. In short, it'll be healthy for trivia sections. Music trivia begone! ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 21:03, 12 January 2024 (UTC)
  4. Sound good. I never realized the trivia guidelines were never formalized in a policy. Superbound (talk) 14:32, 15 January 2024 (UTC)
  5. This is pretty much what we’ve done all along anyway, and I’ve seen how long trivia sections on FANDOM can get. Setting this in stone can only help matters. -YFJ (talk · edits) 15:37, 17 January 2024 (UTC)
  6. Explicitly establishing what falls under trivia can only help the policy. —willidleaway [talk | edits] 23:15, 20 January 2024 (UTC)
  7. There's not much else for me to add other than what's already been said, but I can see how this would help make things more obvious for new users who happen to read our Trivia policy. Per all. – Owencrazyboy17 (talk) 17:28, 23 January 2024 (UTC)
Oppose
Neutral

Discussion[edit]

Using bold or italics for music names (December 18th, 2023 - January 1st, 2024)[edit]

The sister proposal for the above, for an individual aspect that is significantly more complex than the above. Bold text can be seen used:

  • In the infobox caption and opening abstract
  • For alternate names listed in the article
  • When listing medleys that a theme is a part of

Italics are typically used for translations of foreign titles.

They serve as a visual cue, preventing important information from going unnoticed, but between their interactions with links and/or quotation marks, they are used inconsistently, in particular as far as the latter two points are concerned. So, here come more subpoints to discuss. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 15:52, 18 December 2023 (UTC)

Formatting alternate names (English)[edit]

For example, "A Trip to Alivel Mall" is named "Love, Love, Alivel" in Kirby's Dream Buffet. Welcome to the New World! is "Kirby and the Forgotten Land: Bonus Song 3". So, how do we treat these? (Ranked voting highly recommended due to a large number of options)

Option 1: Only bold
Option 2: Only italics
  1. When writing/typing the name of a song, I'm pretty sure you're supposed to either italicize it or underline. This format would technically be the most correct one. --Paistrie (talk) 17:12, 18 December 2023 (UTC)
    #First choice. Italicizing music titles is the standard for main titles, I don't see a reason why that shouldn't apply to other titles. ---PinkYoshiFan 01:26, 20 December 2023 (UTC)
Option 3: Only quotation marks
  1. Second choice. Would want to avoid italics personally. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:38, 20 December 2023 (UTC)
  2. Second choice. Same reasoning as before with consistency, although it seems like the standard both here and in other places is actually quotes for single track titles (italics for albums).---PinkYoshiFan
  3. First choice. I think this keeps the best consistency with the formats of the sister proposal. Waddlez3121 (talk) 17:27, 30 December 2023 (UTC)
Option 4: Bold and italics
Option 5: Bold and quotation
  1. First choice. To highlight the important text and still be consistent with using quotation (per discussions way above) ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:38, 20 December 2023 (UTC)
  2. First choice. I can see this being helpful since that might be what brought people to an article. ---PinkYoshiFan 13:35, 20 December 2023 (UTC)
  3. First choice. Usually alternate name of articles are rendered in bold, and these are what they fundamentally are. And quotations makes it clear that they are song names. - Gigi (talk • edits) 14:55, 27 December 2023 (UTC)
  4. This one, as Gigi put it. Quotes for song names always, bold for alternate names of an article. StarPunch (talk) 11:53, 1 January 2024 (UTC)
Option 6: Italics and quotation
Option 7: All formatting
Neutral

Formatting (alternate) names (foreign)[edit]

This primarily applies to names from something like Kirby Star Allies, where we have an official Japanese title. This is more complex. Do we want to name only the English text and have Japanese in Names in other languages? Or name Japanese and English together in text? If the latter, then how? For the first case, formatting is established in the above proposals will be used. Foreign titles will not be within quotation marks or italics (unless someone in discussions shows up and disagrees) because they're clunky, and so is this proposal.

Option 1: Only English name in text
Option 2: Don't bold foreign, italics English

#Second choice. Italicizing the English name seems good to be consistent with native English names being italicized, but bolding the foreign name seems standard on other wikis and also to some extent here. ---PinkYoshiFan 01:26, 20 December 2023 (UTC)

  1. Second choice. Makes sense if there is no reason to bold the foreign text ig. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:38, 20 December 2023 (UTC)
Option 3: Bold foreign, italics English
  1. In many other wiki websites, many foreign names are bolded, while translations are italicized. This one should be used in order to be consistent with other wikis. --Paistrie (talk) 17:43, 19 December 2023 (UTC)
  2. First choice. This seems to be the current de facto standard, and avoiding names in other languages sections having several tables with one line seems good. ---PinkYoshiFan 01:26, 20 December 2023 (UTC)
  3. First choice. It's how we do it now in most cases. If the foreign name doesn't have quotations and translation is in paranthesis, quotation marks would only add to clutter, right? ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:38, 20 December 2023 (UTC)
  4. First choice. Bold because it's an alternate title, italics to render translations as we do most of the time. - Gigi (talk • edits) 14:57, 27 December 2023 (UTC)
  5. This is what I always go with. Bold for alternate title, italics for translations. If the title is in a Latin language, use quotes as well. StarPunch (talk) 11:53, 1 January 2024 (UTC)
Option 4: Don't bold foreign, quotation marks English
  1. Second choice. Again, same reasoning as before with consistency with native English names but now looking at the actual standard for those.
Option 5: Bold foreign, quotation marks English
  1. First choice. This one makes the most sense to me. Waddlez3121 (talk) 17:29, 30 December 2023 (UTC)
Option 6: Don't bold foreign, double format English
Option 7: Bold foreign, double format English
Neutral

Formatting medleys[edit]

This technically overlaps with the foreign names point half of the time, but it stands separate for something like... "Kirby's Triumphant Return". This overrides the bold rule for foreign titles above for medleys specifically. Aspects not mentioned here are covered above (this includes the use of quotation marks).

Option 1: Bold medleys
  1. First choice. In favour of bolding medleys as important info. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:38, 20 December 2023 (UTC)
Option 2: Don't bold medleys (includes foreign)
  1. Second choice, to not differentiate foreign from English going with this. In case it's suddenly considered not too important. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 06:38, 20 December 2023 (UTC)
  2. First choice. While it's most likely an edge case with this, Kirby's Triumphant Return does show one issue with bolding medleys in the KatFL section: bold stops looking important because there's so many things bolded ---PinkYoshiFan 13:35, 20 December 2023 (UTC)
  3. I prefer not to bold medleys since they aren't alternate titles but separate things entirely. StarPunch (talk) 11:53, 1 January 2024 (UTC)
Option 3: Don't bold medleys (doesn't include foreign)
Option 4: Italics for medleys (doesn't include foreign)
  1. Since these are still individual themes, italicizing these would also be grammatically correct. --Paistrie (talk) 17:50, 19 December 2023 (UTC)
    #First choice. Same reason for other votes, normal music tracks are italicized and I don't see why that shouldn't apply here. ---PinkYoshiFan 01:26, 20 December 2023 (UTC)
Neutral

Using quotation marks for music names (December 18th, 2023 - January 1st, 2024)[edit]

This will be the first of hopefully a full series of proposals concerning music and their dedicated pages. To start it simple, I would like to suggest making quotation marks for their titles consistent. The difference is essentially Green Greens vs Green Greens vs "Green Greens" (to name an example). As we have it now, the more common formatting (or what it should be) is:

  • Quotation marks:
    • Opening abstract
    • Infobox caption
    • Outside of links in composition and game appearances [edit that hopefully doesn't cause conflict: actually no, this is inconsistent, but it's due to bold text and italics, which will be a proposal for another time I suppose ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 14:59, 18 December 2023 (UTC)]
  • No quotation marks:
    • Music navboxes
    • Page title
    • Infobox title
    • Within names in other languages tables
    • Jukebox tables
  • Inconsistent usage:
    • Conjectural titles in various areas, in particular with "the" preceding the name
    • Headings for English names in other languages
    • Track names for stage/level infoboxes
    • Titles within links outside of templates

The inconsistencies are the more concerning part. I don't think any changes should be made to the currently consistent format, but that is open to discussion in the corresponding section. The four points of inconsistency will have separate votes, to make it easier. Votes in favor (where applicable) are for adding quotation marks, while voting against is for removing them. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 08:52, 18 December 2023 (UTC)

Update: I clarified what is what under each section with examples since there was confusion. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 13:23, 18 December 2023 (UTC)

Conjectural titles[edit]

Examples:

Option 1: Always use quotation marks
  1. Second choice. I'd rather have all of them be distinguished like that than not at all. Infinite Possibilities (talk) 19:52, 19 December 2023 (UTC)
  2. First choice. It looks more consistent this way, and it looks better to distinguish music names like this. --YFJ (talk · edits) 23:03, 19 December 2023 (UTC)
  3. First choice. While it may look a bit strange, it makes sense so that editors and viewers can tell if something is a song name or part of a song name. ~☆Starvoid⁠☆ (t · c) 23:20, 19 December 2023 (UTC)
  4. Second choice. If the wiki keeps using the phrase "the "name" theme", I would prefer if it kept quotations. - RHVGamer (talk · edits) 18:50, 30 December 2023 (UTC)
Option 2: Do not use quotation marks if "the" is present
  1. First choice. I can see the quotation marks being helpful for distinguishing conjectural titles, but it looks a bit off with The "name" theme. ---PinkYoshiFan 13:55, 18 December 2023 (UTC)
  2. First choice. When a "the" precedes the conjectural name adding quotation marks as well seems unnecessary to me. Infinite Possibilities (talk) 19:52, 19 December 2023 (UTC)
  3. Second choice, per above, but I feel like it’s better to avoid this use to whatever extent possible; just “Town” and “Ordeal” are sufficient. -YFJ (talk · edits) 23:03, 19 December 2023 (UTC)
  4. Second choice. Very similar to my first choice, but removing "the". ~☆Starvoid⁠☆ (t · c) 23:20, 19 December 2023 (UTC)
  5. First choice. If a name isn't official, I don't see much use to put quotations in a theme name when it has "the" before and "theme" after. Meanwhile, without the "the" and "theme" it can get confusing what is being talked about, and quotation marks can help clarify it's about a song, even if the name isn't official. - Gigi (talk • edits) 01:30, 20 December 2023 (UTC)
  6. I think this is the one I want??? Not sure how this rule applies to certain theme names ("The Skull Gang"?) but conjectural title are not actual titles and shouldn't be treated as such.Waddlez3121 (talk) 17:34, 30 December 2023 (UTC)
  7. First choice. Using "the _ theme" for conjectural names with or without quotations has always looked a bit odd to me, just using the conjectural title in quotations and nothing more makes the most sense to me. - RHVGamer (talk · edits) 18:50, 30 December 2023 (UTC)
  8. Getting my last minute votes in since I nearly forgot this was a thing. I would prefer not use the "the 'name' theme" construct, but also to be consistent on putting song titles in quotes unless they are descriptors rather than titles. In other words, official song names should always be like "Max Happy Town!!", and unofficial names should be like "Town" or the Town theme. StarPunch (talk) 11:47, 1 January 2024 (UTC)
Option 3: Do not use quotation marks
  1. Second choice. Having quotation marks to distinguish conjectural titles could be good but I'm fine with this one too. ---PinkYoshiFan 13:55, 18 December 2023 (UTC)
  2. Second choice. In a way, not using quotations for conjectural names makes it clearer in general that they aren't official names. - Gigi (talk • edits) 01:30, 20 December 2023 (UTC)
Neutral

Names in other languages headings[edit]

Compare Time for the Results#Names in other languages and Memories (I'll Never Forget You)#Names in other languages

Support
  1. Per my vote for the infoboxes. I don’t see any issue with using quote marks here, consistency is better, and we italicize game names in headings the same way. -YFJ (talk · edits) 23:10, 19 December 2023 (UTC)
Oppose
  1. When the track name is the only thing in the heading, the quotation marks just make it look more cluttered. ---PinkYoshiFan 13:44, 18 December 2023 (UTC)
  2. Similar to my vote above, I don't think adding quotation marks is necessary when it is already distinguished, in this case by being alone in the heading. Infinite Possibilities (talk) 19:52, 19 December 2023 (UTC)
  3. Just like with the title of a music page, I don't think using quotations in headings is necessary. - RHVGamer (talk · edits) 18:50, 30 December 2023 (UTC)
  4. I'm admittedly not consistent with this, as I do prefer consistency with always having music titles in quotes, but I do think it makes linking to certain sections more confusing, yeah. No quotation marks for section titles, for accessibility. StarPunch (talk) 11:47, 1 January 2024 (UTC)
Neutral

Music in stage/level infoboxes[edit]

Compare Butter Building - Stage 1 and Popstar

Support
  1. We italicize game names even if they’re the only thing in the infobox section, so I don’t see the issue with using quote marks here. Again, consistency is always better. -YFJ (talk · edits) 23:08, 19 December 2023 (UTC)
  2. It can get really confusing when songs named after stages/levels get linked in infoboxes. Without the quotation marks, a reader can be confused and wonder, for example, why there is "The Fountain of Dreams" in Nebula Belt: they could think of the location before the song. While, sure, you could argue they should know better because there is a description and music files above, it's important to consider. And since we often add game names to clarify where a song is from (like in Bubbly Clouds (Battle Stage)) I feel it makes sense to be consistent and, much how games are always italicized, we should have song names with quotation marks. - Gigi (talk • edits) 01:38, 20 December 2023 (UTC)
  3. I think it makes sense to use quotations in infoboxes, since they have more than just music in them. When I added a lot of music to infoboxes (including the Butter Building page you highlighted), I wasn't thinking about if there should be quotations, but looking back I would add them. - RHVGamer (talk · edits) 18:50, 30 December 2023 (UTC)
  4. Support. I much prefer consistency here as long as it doesn't affect usability, and I don't think it will be confusing or cluttered. StarPunch (talk) 11:47, 1 January 2024 (UTC)
Oppose
  1. Same as with names in other languages above, when the track name is the only thing there, the quotation marks just make it look more cluttered. ---PinkYoshiFan 13:44, 18 December 2023 (UTC)
  2. Also similar to my votes above, when the track name it is already distinguished in some way, in this case by being alone in the infobox, adding quotation marks doesn't really add anything. Infinite Possibilities (talk) 19:52, 19 December 2023 (UTC)
Neutral

Outside of square (link) brackets[edit]

Compare Inside the Castle#Composition and Coin Clash (theme)#Composition

Support
  1. Here having quotation marks appears as the logical throughline to me. Makes it easier to tell at a glance whether it refers to a track or something else. Infinite Possibilities (talk) 19:52, 19 December 2023 (UTC)
  2. Can’t really add too much to my vote comments above, but in addition to that, it makes it immediately obvious whether the link goes to Green Greens or "Green Greens". -YFJ (talk · edits) 23:14, 19 December 2023 (UTC)
  3. I don't see any reason for non-links to have different formatting than with links. ---PinkYoshiFan 12:42, 22 December 2023 (UTC)
  4. I agree with everyone else here, it makes sense to use quotations in normal text whether it's a link or not. - RHVGamer (talk · edits) 18:50, 30 December 2023 (UTC)
  5. Again, consistency whenever possible. StarPunch (talk) 11:47, 1 January 2024 (UTC)
Oppose

#I think it's better to just do what we do for other articles (e.g. Kirby) and just bold the first instance of the article title in the infobox as well as the main text. ---PinkYoshiFan 13:44, 18 December 2023 (UTC)

Neutral

Discussion[edit]

Regarding the comment for the vote for the fourth aspect (quotation marks paired with links), I would like to be clear that it does not affect bold text. It affects listing other themes as a part of the composition or a medley. For example, it's differentiating between <"Green Greens" can include Kirby's Triumphant Return> and <"Green Greens" can include "Kirby's Triumphant Return">. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 15:55, 18 December 2023 (UTC)
Retrieved from "https://wikirby.com/w/index.php?title=WiKirby:Proposals/Archive&oldid=473352"