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

WiKirby:Proposals/Archive-2021

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 are proposals which were passed in 2021:

Proposals

Source status of press kit images: do they need a link or not? (December 15th, 2021 - December 29th, 2021)

Greetings. Over the course of implementing the new aboutfile template across all of WiKirby's files, we have discovered several large pieces of artwork which do not have a source link, instead often saying something like "Image was directly retrieved from Nintendo of Australia". This implies that it was taken from a press kit that cannot be linked to directly. As such, it is not possible under the current system to consider these images to be properly sourced. Problem is, there have been several such images that were marked as Good or even featured (like this one) despite technically no longer qualifying. There has been some call to treat these images as properly sourced as long as the uploader can be trusted, but I think we ought to have a community decision on this.

If you are of the opinion that images received from unlinkable press kits should count as being sourced, granted the uploader can be trusted, vote under "Support".
If you want the rules to stay as they currently are (resulting in all such images being ineligible for Good or Featured status and any such statuses already given be revoked), vote under "Oppose".
I can see genuine arguments for either side, so don't be afraid to be honest with your opinion. --Samwell (talk) 21:53, 15 December 2021 (UTC)

Support
  1. In the internal data proposal discussion it was pointed out that for ROMs and obscure sources, we don't neccesarily need to link the source if we trust the user adding it and linking sources is an issue, and I think that that same logic would apply here. ---PinkYoshiFan 00:43, 16 December 2021 (UTC)
  2. When they come from a press access that is often sent to registered individuals, they obviously cannot be linked. Only the original uploader can do us a favor and pinpoint which exact press site (or an archive of e.g. Internet Archive) the image came from. I managed to rescue this featured image by finding its press kit's archive, but same cannot be guaranteed for a lot of other cases. ⁠–⁠Wiz (talk · edits) 01:30, 16 December 2021 (UTC)
  3. If the uploader is generally considered trustworthy I see no reason why the images should not count as sourced, granted that that trust isn't handled to lightly. Infinite Possibilities (talk) 19:24, 19 December 2021 (UTC)
  4. Yeah, I agree with most everyone above. It's probably pretty unlikely for us to find a decent amount of linkable press kits out there, for one. I have a feeling that putting more trust in, well, already trustworthy editors in this case is perfectly fine, and will reasonably save a lot of images worthy of being Good or even Featured on the wiki. -- Jellytost♡ (talk) 02:44, 30 December 2021 (UTC)
Oppose
Neutral
  1. Would rather strive to find publicly hosted press kits that we can in fact link to. Given that I have found and uploaded over 10 different sources for images that relate to the site, I think versions with links should take priority over unlinked ones, but realize that linking every single one out there may be impossible to do. Trig - 17:36, 28 December 2021 (UTC)
  2. I don't think that it is impossible to find the link of a press kit from an image that lacks a link currently, as various users have found links of press kits, though I get that that may not be always possible. It is very possible that some random user of the internet finds and uploads the press kit from which that Robobot Wheel Mode artwork comes from, but it is also very possible that no one will never find/upload that press kit, thus having that image without a source forever until the internet collapses.
    I support that an image without a press kit link should still be eligible for the Good and Featured statuses, but I kind-off disagree that it should be completely counted as being sourced.
    As I said, it is possible that a source could be found, so I'd say that the ideal option would be a mid-point between both options, like creating a template as "Press Kit-sourced images" in which it will be stated that there isn't an actual source link to the image, but that it will still be eligible for the Good and Featured statuses.
    Both available options have good reasoning behind them, but as I can't decide which to choose, and as my ideal option isn't available to be chose, I will go neutral. -Zolerian (talk | contribs) 03:05, 30 December 2021 (UTC)

Discussion

The only question I have is how we would define a "trusted" uploader. Would it be anyone under autopatrol, any staff member, or what? - Gigi (talk • edits) 16:57, 17 December 2021 (UTC)

Well that's a more abstract question, and not one that I would necessarily think would be possible to define concretely in policy. I suspect it would be along the same wavelength as, say, trusting that someone who uploads a screenshot claiming they took it themselves is telling the truth. If that person has a good track record of producing these screenshots, and hasn't been shown to lie about it, then we can generally trust them. In terms of Results May Vary and the artworks he uploaded, I generally trust that he did get those from press kits, instead of, say, just lifting them from the Kirby FANDOM. --Samwell (talk) 17:03, 17 December 2021 (UTC)
If we were to assume the worst case, the first indicator that this wasn't easily lifted off another wiki is the fact we cannot find them anywhere. Onwards, we shouldn't have any unsourced press uploads because our policies are now much stricter, and we'll be able to inquiry their uploaders right away. I fully trust RMV after conversating about this. ⁠–⁠Wiz (talk · edits) 20:50, 17 December 2021 (UTC)

Files with Template:Link needed should be ineligible for Good status (112821–121221)

NOTE:This proposal has been deemed redundant, since what it proposed is already de-facto policy. It has been placed here for reference purposes.

Currently as set in the WiKirby:Featured content policy, the parameters for a Good image are the following conditions:

  • a high quality image with no significant aberrations OR a high-quality audio file with no significant distortion.
  • sound of format (no improvement notice templates are present).
  • has complete documentation with source (where applicable).
  • properly licensed.
  • properly categorized.
  • used in at least one article.

While {{Link needed}} primarily focuses on files that do not have links to listed source files. This proposal sets to claim that any file that uses Link needed is ineligible for Good status, and any files currently utilizing sourced but unlinked files immediately enter into the revoke good process. The reason is primarily in the following terms:

  • sound of format (no improvement notice templates are present).
  • has complete documentation with source (where applicable).
  • properly licensed.

Licensing is the least likely, but there is a very rare chance a linked file may NOT be used without permission or that it is released under an alternate license that is incorrectly registered on this site. The larger two issues revolve around sound of format; That the file has no notice templates whereas Link needed qualifies as a notice template, and Complete documentation with source. Because there is not a link to the source so that readers may track to the original source, it would stand to say that this does not qualify as complete documentation, and should therefore fail Good qualifications.
An alternate way to describe this scenario is that an ordinary "Good" file has no more reasonable edits to make on it while on-site. This is not the case for Link needed files, as they should feature links to the sources which would require an edit to correct.

Thank you for your time. Trig - 05:41, 28 November 2021 (UTC)

Support
Oppose
Neutral

Discussion

Just out of curiosity, how would this proposal affect images whose sources cannot be directly linked to, such as a press kit release? --Samwell (talk) 11:51, 28 November 2021 (UTC)

I am not 100% clear how those are formatted. If there aren't direct links available or they aren't say legal to share elsewhere, then press kit should just be listed as the source and Link needed template should just be removed. Trig - 17:34, 28 November 2021 (UTC)
In that case, I'm not entirely sure what the key change you want to make is, aside from using the link needed template in place of the file source template. As far as I was concerned, both templates cover the same ground. Only reason any file with the file source template on it might still be listed as Good would be because we hadn't gotten around to revoking it yet. --Samwell (talk) 21:24, 28 November 2021 (UTC)
Well, the difference is that while something that would have used File source has no listed source, a Link needed file has a listed source--just not with a link to it. Some may justify that with a listed source but no link, that a source is complete. I serve to argue that it is not. Trig - 21:31, 28 November 2021 (UTC)
Yeah, file source is meant to cover situations like that. Might reword existing policy to make that clearer, but it sounds like a proposal isn't needed for this. --Samwell (talk) 22:28, 28 November 2021 (UTC)
For clarity's sake, files without listed sources, those that would use File source or with empty source parameters in Aboutfile 2 are already ineligible for good. The fork from File source template into no listed source in Aboufile or link needed template complicated this however, because instead of a general "Help needed" template, I split them into two specific categories of no link and link needed did not fully specify how the conditions of Good would work. This sets to resolve that. Trig - 14:38, 29 November 2021 (UTC)
Do files have to go through {{Revoke Good}}, because neither policies nor the template mentions files? I agree with Samwell here, this is de-facto already in practice but should be clarified on the policy page, including exceptions (e.g. non-own book scans from an unimportant imageboard I don't want to link). ⁠–⁠Wiz (talk · edits) 22:33, 1 December 2021 (UTC)

(Separate from current discussion) Wouldn't link needed already cause files to be not good due to the no improvement notice templates condition? ---PinkYoshiFan 14:44, 29 November 2021 (UTC)

Yes, it does. This redundancy is further reason I would like to make it absolutely clear this qualifies. Trig - 17:28, 29 November 2021 (UTC)
So what's the point of making link needed make files ineligible for good if it already effectively does that? ---PinkYoshiFan 22:12, 29 November 2021 (UTC)

Coverage of non-Kirby content in NES Remix 2 & Ultimate NES Remix (November 16th 2021 - November 30th 2021)

Inspired by the recent debate around Smash Bros. coverage since that is a similar topic I'm comming forth with a few options regarding the non-Kirby games featured in NES Remix 2 and Ultimate NES Remix. Here's a little layout for a better understanding:

  • Kirby's Adventure is the only Kirby game featured in these titles
  • The non-Kirby regular stages don't feature anything related to the series
  • In Remix and Bonus stages the challenges sometimes run through multiple games
  • Remix and Bonus stages also feature other characters in the Kirby's Adventure environment while Kirby is sometimes put into another gane himself.

As far as I'm concerned there are three options.

1. Mention which games are featured and include stage parts from other games in the tables given a Kirby challenge also is in the pack

Basically, the games get a mention with respective links to their respective wikis and are featured in stage tables if a Kirby challenge is in the same stage. This would make all stage tables complete for their respective stages, at the cost of talking about a game unrelated to the Kirby series.

2. Only mention the games featured

The games are all listed with respective links while the stage tables exclusively go over those that have a direct Kirby connection. For example, in Ultimate NES Remix's 25th Bonus stage the table would only feature 25-2 and 25-7. This option is also the closest to what the Super Mario Wiki does.

3. Don't mention them at all outside of when they're remixed with Kirby's Adventure

The only mention the games would get is in Remix/Bonus stages where Kirby's Adventure elements collide with them. For example in Ultimate NES Remix's 10th Bonus stage Super Mario Bros. The Lost Levels would be mentioned as Bullet Bills from that game appear in a Kirby challenge.

I'm sorry if something confuses you. Writing stuff like this isn't my strong suit. If any of you have other suggestions, please post them in the "Discussion" section. Infinite Possibilities (talk) 19:40, 16 November 2021 (UTC)

Voting

Support
  1. I would prefer to see option 3; Only cover external elements when absolutely necessary and focus on covering Kirby content. Trig - 20:05, 16 November 2021 (UTC)
  2. Listing the non-Kirby stages with interwikis and going more in-depth on Kirby content sounds good, so I support option 2. ---PinkYoshiFan 23:05, 16 November 2021 (UTC)
  3. Seeing more in depth everything, I vote for option 2. With option 1, every stage would be covered fully even if it does not have any Kirby thing in it. But this is WiKirby, not NintendoWiki, covering the NES Remixes completely is up to them, so just listing the other games suffices.
    With option 3, every game that doesn't have something with Kirby's Adventure would be deleted from the matrix, not even mentioned, and I think that at least mentioning each game featured in the NES Remixes would be good. So option 2 seems to be the more balanced to me. -Zolerian (talk | contribs) 05:27, 18 November 2021 (UTC)
  4. I am precisely in agreement with the above message. I'll go with option 2 due it its reasonable balance. -- Jellytost♡ (talk) 03:02, 22 November 2021 (UTC)

#I vote on option 1, if I understood correctly the options. If there is a Kirby related thing, it should be covered here. Like, If Kirby, the character, appears in a stage of another game, it should be covered here.
I don't vote on 2 because I understand that with that option, if Kirby appears on Super Mario Bros., it wouldn't be covered. But I think that that case should be covered, so 2 is out for me.
And with 3 it would be the same thing, as I get that in a non-remix stage Kirby and Mario content clash, it wouldn't be covered, but to me that, well, should be covered here. So in short, I want that every thing in which a Kirby related thing appears is covered here.
I'm in disagreement if something like, a stage where there is just Bomberman gameplay with the Bomberman characters, without Kirby at all, is covered. Though I think none of the options support that anyways.
(If I didn't understood something correctly, an clarification at the Discussion section would be appreciated to formulate my vote better, but for now I will go with 1.) -Zolerian (talk | contribs) 22:21, 16 November 2021 (UTC)

Oppose
Neutral

Discussion

Infinite Possibilities (talk) 19:40, 16 November 2021 (UTC)

Since it seems like clarification is needed, here are hopefully clearer explanations:

  • Option 1. Coverage would include non-Kirby content if it appears in the same stage as Kirby content. All games would be listed fairly early in the page.
  • Option 2. Coverage would be limited to stages where Kirby content makes direct appearances. The games would be listed.
  • Option 3. Coverage would be limited to where Kirby is the main focus of the challenge. Other games are only mentioned if their elements appear in Kirby stages.

Infinite Possibilities (talk) 08:58, 17 November 2021 (UTC)

Result

Option 2 is the winner, with three votes.

Change the way featured content queue works (November 14, 2021 - November 28, 2021)

Right now, whenever an article or a picture gets featured, it appears on the front page as soon as the nomination passes, overtaking whatever is in there at the moment. While I'm not opposed to favoring the newest articles or pictures, I don't like how it happens at the cost of other featured content. Hence, I'm proposing for most recently featured articles/pictures to appear the next Sunday after their nomination passes,. Note that this has been the case for a really long time unofficially ([1] [2] [3] [4] [5] [6] [7]), however, there was no formal discussion or decision about it according to Gigi. Thoughts on this? Superbound (talk) 14:29, 14 November 2021 (UTC)

Support
  1. Completely agree, it is way cleaner that way. In the actual state of things, if a page/picture gets featured a day before the next rotation begins, it will either be featured by 1 day, or by 8 days, which messes up the things quite a bit. And if a page/picture is featured a day after the rotation begins, it will be featured by 6 days, but the previous one will be there just 1 day, which isn't fair. So in this way everything gets a pair and fair time on display, and if it has been like that before, it is for something. (Unrelated note and recommendation, there is a cleaner way to link to differences. See this [1] for example.) -Zolerian (talk | contribs) 15:26, 16 November 2021 (UTC)
  2. I prefer consistency here. Changing between articles randomly could confuse some people. This will be much more simple and fair--as long as we remember to update the articles in the first place when the time comes, of course. :P -- Jellytost♡ (talk) 03:02, 22 November 2021 (UTC)
  3. Consistiency is good, and it's not really that important to put something on the main page immediately. ---PinkYoshiFan 13:16, 28 November 2021 (UTC)
Oppose
Neutral
  1. I really do not think the length of Featured Content matters. If something passes, then it can change. At worst, more variety the better. This isn't to necessarily say I want no minimum time, as though we could switch it every 8 hours or something ridiculous like that, but I don't think worrying about the difference between 1 to 8 days matters significantly enough in order to warrant this policy being instilled. Trig - 20:05, 16 November 2021 (UTC)
  2. Maybe it's just me but I do believe that the current way doesn't need to be changed. I'm not paticulary against this suggestion, just don't think it's necessary. Infinite Possibilities (talk) 20:45, 27 November 2021 (UTC)

Discussion

Archive all significant discussion pages for deleted articles and files (11/12/2021 - 11/26/2021)

So, looking at the long discussion that has ballooned in Talk:List of composers, and seeing what the likely fate of its parent article will be, I think it would be a shame for such a talk page to be deleted just as a matter or course. My proposal is simply that if there is any significant content (especially if there are debates regarding the wiki and its mission) in a discussion page of an article or file that gets deleted, that discussion page should be archived rather than deleted. Vote now with your phones. --Samwell (talk) 14:24, 12 November 2021 (UTC)

Support
  1. History shouldn't be deleted, especially if that history is why something else was deleted. ---PinkYoshiFan 14:31, 12 November 2021 (UTC)
  2. ^What he said. Without the conversation leading to the deletion, we might forget why we deleted it in the first place. :P --kirb 15:36, 12 November 2021 (UTC)
  3. ^^What they said + if we don't know why something got deleted it'll likely come to a repeat discussion. It could also help with deciding the fates of other pages where similar arguments could accour. Infinite Possibilities (talk) 15:51, 12 November 2021 (UTC)
  4. I was under the impression that those were always meant to be archived rather than straight up deleted. So you have my support for archiving, as talk pages should be preserved in case the discussion needs to be checked again after it's over for any reason. - Gigi (talk • edits) 15:54, 12 November 2021 (UTC)
  5. Huge fan of preserving, so support. I don't see a reason why it's a bad thing that a talk page exist without its core page; moving discussion to a single page would also probably be more work in exchange for minimal benefit. Perhaps a special, separate category or a navigation page could compromise. Superbound (talk) 14:29, 14 November 2021 (UTC)
  6. What everyone said :P If a discussion is significant, it should be preserved somehow. I agree that it is better having just one "Talk/Disussion Page archive" (because in this wiki it isn't so clear which of the two names is the "correct" one) instead of putting each archive on several pages. For example, if the list of composers is deleted, and a "Music" page borns, the archive of that long discussion should be on the "Talk/Disussion Page archive" instead on somewhere on the Music page. -Zolerian (talk | contribs) 14:59, 16 November 2021 (UTC)
  7. I am of the firm belief that history should be preserved whenever possible, and doing this in addition would save us a lot of trouble in the future I believe. Deleting it feels like a hurtful waste, but keeping it around seems only to result in positives, so why not? -- Jellytost♡ (talk) 03:02, 22 November 2021 (UTC)
Oppose
  1. I am of the belief that if the page does not exist, the talk page does not need to either. If it is too significant an issue that it needs to remain in conversation, at worst it should be moved to one single page of talk page archives similar to the passed/failed proposals page. It is extraordinarily unlikely people will be finding talk pages for archives unless specific people remember the conversation and can route the reasoning. If a page is deleted, a reason in the deletion page description should be sufficient for the reason a page was deleted. Firm oppose, but suggest a single page for archives if absolutely needed. Trig - 16:01, 12 November 2021 (UTC)
Neutral
  1. I agree about archiving them, but in a single page archive like Trig suggests. In such case, to easily traverse through long discussions, I would also make their sections auto-collapsed (like you see with tables). ⁠–⁠Wiz (talk · edits) 01:27, 14 November 2021 (UTC)

Discussion

Smash Bros. Coverage 110221–111621 EXT: 112521

This is a proposal relating to several conversations on Discord about how WiKirby should be moving forward in Smash Bros. content moving forward. Currently, most pages are set up in the following structure:

  • About the game
  • All Characters in a list
  • Kirby's moveset
  • King Dedede's moveset
  • Meta Knight's moveset
  • All stages in the game
  • Specifically only Kirby Stages
  • "Story Mode" or main non-Smash game mode
  • Items
  • Trophies
  • Gallery
  • Trivia/References/Footers

There have been several vocalized concerns about the types of content being covered on these pages, as they are generally long in vertical length and not always being directly related to Kirby. The following are some suggested paths to move forward on covering content, listed in a form of most change to least change:

1-Completely redirect all Smash Bros. Content to SmashWiki, the Smash NIWA affiliate

The most extreme choice. If game pages remain, they mostly serve to just send people to SmashWiki after a short explanation of the game.

2-Reduce covered content to explicitly only cover Kirby content

Remove information about various game modes, non-kirby characters, and non-kirby stages.

3-Only remove character images on Brawl, 4, and Ultimate pages

One of the chief complaints is that having character images lengthens pages too much and therefore should be deleted, and move character lists back to single line text. This option would only seek to delete character pictures and no other change

4-No Changes

Current coverage is just fine the way that it is. No changes are necessary.

5-Increase Smash Bros. Coverage

This option is for arguing that Wikirby does not cover enough Smash content, and should work on developing more, even if it isn't directly Kirby related.
Please discuss heavily! As for myself, I would prefer options 3 and 2 in order. Trig - 14:30, 2 November 2021 (UTC)

Voting

Support
  1. 3 sounds like the best option. ---PinkYoshiFan 23:49, 3 November 2021 (UTC)
  2. The Super Smash Bros. game pages are a bit anomalous at this point when it comes to pages that cover Smash Bros. content on WiKirby, since all other pages that deal with Smash Bros. content tend to only focus on the stuff that directly links to the Kirby series. At this point, I'm almost convinced that the pages on Super Smash Bros. games themselves should be removed entirely from WiKirby in favor of links to SmashWiki, and any relevant information on those pages be dispersed to the most appropriate pages (for instance, moving details on Kirby as a Smash Bros. fighter to the main Kirby page). For now though, just to make sure nothing moves too fast, I will vote for option 2. --Samwell (talk) 20:48, 7 November 2021 (UTC)
  3. I vote for option 2.
    Although there is a "joke" of Kirby sites covering Smash, because both were created by the same person and company, I doubt that there is any reason to cover non-Kirby content here with the existence of Smash Wiki. Pikipedia's and Inkipedia's articles of Ultimate jumps directly to the content of their respective franchises evading any external content, and I think that WiKirby should do the same in every Smash page; not cover non-Kirby scenarios, nor the game modes if they don't have relation to Kirby. Having a list of all the characters is useful because, as Gigi said here, Kirby copies them, so they are relevant in the Kirby side. But having images of them is not necessary, a text listing like the ones in 64 and Melee pages suffices.
    In short: 64, Melee, Brawl and For lists non-Kirby stages. Brawl, For and Ultimate have images of non-Kirby characters. Ultimate lists the game modes even if they have nothing to do with Kirby. I think that those things shouldn't be in WiKirby, and option 2 aims to do delete them, so there I go. -Zolerian (talk | contribs) 02:46, 8 November 2021 (UTC)
  4. Covering the content that specifically has nothing to do with the Kirby series doesn't really serve a purpose as there already is a NIWA wiki for that. Though I personally disagree with getting rid of all game modes since Ultimate's Classic Mode specifically makes use of the Kirby characters in other routes which reference stuff, so I vote for option 3 as it gets rid of the stuff most unneeded while keeping what I consider to be relevant enough. Infinite Possibilities (talk) 17:44, 11 November 2021 (UTC)
  5. 3 It seems to me that covering Smash elements that don't relate to Kirby isn't very useful when SmashWiki is so extensive. I think we should keep around the pages, since the Smash series is technically a game in which Kirby appears as a playable character. We don't really need images of other fighters. --kirb 15:34, 12 November 2021 (UTC)
  6. Voting for 3 because 2 looks very extreme and 3 would solve the biggest problem we have right now. I would base them the other pages around Super Smash Bros. Ultimate minus the character images, as I believe it strikes a good balance of content about these games. - Gigi (talk • edits) 16:00, 12 November 2021 (UTC)
  7. This was certainly a tough decision... Both parties have good points. For a while now, I've been iffy about having the Smash Bros. pages on WiKirby at all, but their existence doesn't hurt much as-is, especially since Kirby characters are playable. There's a chance they'll be wiped from the wiki eventually though, which is something I'm half-and-half on.
    As for the content on the pages, I really don't see the need to cover non-Kirby content, though a very basic summary of some stuff is fine. We need a bit of general context here and there for the Kirby content itself, but not much at all. I don't believe that it will be misleading, since we can, for instance, title the Game Modes section as something like "Game Modes involving Kirby content". Stripping content away won't be a totally strict process. There's always room for suggestions in the future if things are going downhill or if anyone changes their mind.
    With all of that said, I was originally going to play it safe with option 3, but after thinking about it for a few days, I'll be going with option 2. -- Jellytost♡ (talk) 03:02, 22 November 2021 (UTC)
Oppose
Neutral

Discussion

  • Here is my proposed outline of what should be covered in each Smash page, taking inspiration of the current state of Super Smash Bros. Ultimate:
    • Fighters - fighters *should* be listed because Kirby copies them, but without images, and in a collapsible table. Kirby series fighters get explanation of their movesets in separate sections;
    • Stages - much like the page right now, an overview of the number of available stages, and any relevant info that relates to the Kirby in general (such as the stage forms). Then a list of Kirby stages, and their music;
    • Items - similarly to the Stages, an overview, any relevant info, all Kirby items with info about them;
    • Game Modes - at least general information about them. Cutting some of them would make no sense for me as some modes such as Classic Mode have their variations per character, and they would they get listed while others would not? It would be misleading to the reader. So just listing all modes is fine, while detailing Kirby content of modes as needed;
    • Trivia/Gallery - as long as these are only about Kirby content it should be fine.
  • Again, just my two cents. I think a format like this strikes a good balance between the two worlds. - Gigi (talk • edits) 16:09, 12 November 2021 (UTC)

Result

Option 3 is the winner, with four votes. Option 2 comes in second, with three votes.

Overhaul Template:Aboutfile 101621-103021

I've come to make an announcement in regards to the project that I am leading regarding adding Template:Aboutfile to every image that lacks it currently. In short, I want to make changes to the currently existing template to be more like the Template:File on Wars Wiki and StrategyWiki (see here).

Simply put, I think that this template is not only objectively better but also extremely easy to implement. Here is a list of reasons in a relative order of importance:

  • This would be a non-destructive change. This is only changing the components of Aboutfile, which means that that the old styling and the suggested new changes can be together without conflict. This is simply just trying to add to the existing template, not make a new one.
  • It's drastically easier for new users to use. People that don't have much experience uploading files will find exactly everything they need to enter directly where it needs to be, most likely without having to open up other pages or categories to see exactly what needs written for that file, and don't need to memorize certain aspects of uploading.
  • It's drastically easier for you, yes YOU to use. The primary benefit to Wars' Template:File is that a lot of components don't need to be manually written. If a game is entered into the |game= slot, the game not only has a link to it, but is automatically categorized for that game. Wars' |type= section not only categorizes the file to the "type" conditional's category (like Category:Screenshots) but also automatically generates the file license which means...
  • No more licensing templates needed. Everything will automatically be fed through the template and generate exactly what is needed! No need to write out categories or licenses. This is a fantastic way to reduce potential errors, as typos can always exist on the categorization meaning people looking for images cannot find them as easily.
  • Sourcing becomes a lot better managed. Currently for Wars, if a section is left blank, the file will automatically be added to a category for unsourced files. What could occur is the current file needs sourcing template is integrated into the new Aboutfile template so that there is a bright, contrasting warning inside the box indicating the file has no source and one needs located. This can be taken a step further by having a second warning specifically for any files sourced through Kirby FANDOM or FANDOM overall.
  • Finding errors and improvements when changing the template. I have seen a significant as in over 200 files that need image-quality templates, header fixes, or other types of fixes while compiling the list. This is a fantastic way to address these types of problems when making changes to files anyway.
  • Saves space on new uploads. This is pretty minor. But it's cool and notable.

The only current either downside or hinderances in my way for fully integrating this today right now are the following: Your collective support for the idea, making the template still look as pretty as it does now, and how exactly we would approach other media like the anime or books or something. I would personally suggest just dropping it in |game= but there might be a few lingustic rivals amongst us that disagree with using game for not-games.

TL;DR:

  • Aboutfile is converted to include the automatics involved in Wars Wiki's Template:File through additional parameters.
  • Template:File source is converted to File source link (or something similar) to specifically notate files that have a written source, but no link to it (such as many of RMV's uploads). File source needed and Not-using-FANDOM conditionals are built into Aboutfile.
  • Trig posts his big freaky list and people start chipping away at it.
--Trig Jegman - 03:05, 16 October 2021 (UTC)

For an example of a file change, please click "Expand" on the right.

Consult File:KMA Tortletummy Thorn sprite.png 

<nowiki>
== Summary ==
{{aboutfile
|description=In-game sprite of [[Tortletummy Thorn]] from ''[[Kirby Mass Attack]]''
|game=''[[Kirby Mass Attack]]''
|source=[https://www.spriters-resource.com/ds_dsi/kirbymassattack/sheet/8487/ Spriters Resource]
}}

== License ==
{{Game sprite}}
[[Category:Kirby Mass Attack images]]
[[Category:Sprites]]

would move to 

==Summary==
{{aboutfile
|description=In-game sprite of [[Tortletummy Thorn]] from ''[[Kirby Mass Attack]]''
|game=Kirby Mass Attack
|type=sprite
|source=[https://www.spriters-resource.com/ds_dsi/kirbymassattack/sheet/8487/ Spriters Resource]
}}
</nowiki>

in order to provide the same exact results.


Support
  1. Sounds good to me. Any changes that make the process of proper file uploading easier for new users in particular gets a thumbs up from me. --Samwell (talk) 03:07, 16 October 2021 (UTC)
  2. Complete support. This is very beneficial, and what catches my eye more is both the auto placement of unsourced files and, on top of everything, the auto Categorization in general. -Zolerian (talk | contribs) 04:35, 16 October 2021 (UTC)
  3. Simpler is better, especially for new users. ---PinkYoshiFan 10:59, 16 October 2021 (UTC)
  4. Not having to manually add game categories and license types is a good idea. --kirb 18:12, 25 October 2021 (UTC)
Oppose
Neutral

Discussion

Vipz

A couple of issues I'm foreseeing:

  • Automization with "|game=Kirby's Game" doing ''[[Kirby's Game]]'' [[Category:Kirby's Game images]] will work only for games, so aside from linguistics, this is why I think "|media=" should be a separate field. Not all media will have pages and categories (that work the same way).
  • Pipe links are impossible.
  • When an image comes from multiple games (e.g. KNiDL, KaTAM and KSqS) - although additional categories can be added manually.
  • License parameters (e.g. {{Game screenshot|official}}) and multiple licenses (e.g. {{WikimediaImage}} + {{PD}}).

There might be more, so clean automization is hard, unless we introduce more parameters. ⁠–⁠Wiz (talk · edits) 11:58, 16 October 2021 (UTC)

Back from my trip. I agree that perhaps having a secondary |media= that does not cause an automatic link may be useful, but would suggest we emphasize using |game= when most possible. Secondarily, I cannot necessarily think of an appropriate reason to have a piped link for a game title. Anything that is a deviation from a full game name seems like it would qualify as an inaccuracy. At the absolute worst, |media= would solve that. If an image comes from multiple games, I would suggest simply using |description= to list other included games and writing in more categories. I think that multi-game files would be exceedingly rare. Licensing parameters would be able to be changed to be their own separate variable switch. The way the template works is by using a different, all-encompassing switch template to change the file license instead of having several dozen templates so one parameter could just become |type=Screenshotofficial or something similar. As for multiple licenses, I do not forsee {{WikimediaImage}} being necessary if we are specifically listing the source out, though once again another parameter could be added for a Wikimedia+PD parameter if absolutely needed. Trig - 00:29, 18 October 2021 (UTC)

Template WIP

While not fully complete, User talk:Trig Jegman/Sandbox here is a rough draft of how the template will function including the requests made above/on Shiver Star. Trig - 21:07, 19 October 2021 (UTC)

Gigi

About licenses, are you proposing that [[:Category:Image templates|these]] [[:Category:Audio templates|templates]] are to be removed from all current files currently using it if this change rolls out in favor of a more general one for just "files" as shown in your sandbox? Because as of right now, there is a dropbox in the upload form for choose a template, and I'm wondering if that is supposed to eventually be gone too. I would just like to understand more and what kinda of backwards work would need to be done if this rolls out. - Gigi (talk • edits) 01:12, 26 October 2021 (UTC)

Long story short, yes, the drop box would go. As we have on StrategyWiki, the list of possible file types is up front and center first thing on the upload screen (although it could be prettier). These templates all roughly contain the same message only inter-changable by the type, which is being designated its own parameter as opposed to a template name. It is unlikely that a different license will need to be used for an overwhelming majority of images, and although yes technically possible to continue generating different licenses for different types, it does not do much except waste space. I would intend to look at fixing every file anyway, due to the amount of sourcing and quality flagging that can be addressed (hundreds to thousand files probably need some form of extra management). Trig - 01:48, 26 October 2021 (UTC)

Favor adapted Japanese names and terms over literal translations whenever possible (July 28th - August 11th)

Currently, the naming policy says the following when it comes to Japanese names:

  • Any non-English official name, following the three above priorities as with English names. Translated Japanese names take priority here.

The part I bolded is what I want to specify better. My proposal is to change that point to the following:

  • Any non-English official name, following the three above priorities as with English names. Translated Japanese names take priority here, using adapted names and terms whenever possible.

In short, when we use Japanese names, we should try to use officially localized names and terms whenever possible, to make the names as close to English as possible, and to avoid inconsistencies. Here are some examples to illustrate:

  • Four-Headed Guardian Angel: Landia: the Japanese title 4つ首の守り神：ランディア directly translates to Four-Headed Guardian Deity: Landia. However, 守り神 has been localized in the games as "Guardian Angel", so we instead use that term for the page.
  • Air Ride: Sky Sands: the Japanese title エアライド:サンドーラ directly translates to Air Ride: Sandoola. However, "Sandoola" is the Japanese name for "Sky Sands", so instead we use that name for the page.
  • True Arena Showdown: the Japanese title 真 コロシアムの戦い directly translates to True Colosseum Battle. コロシアムの戦い is the Japanese name of Arena Showdown, that has an official English name. 真 コロシアムの戦い is basically "真" plus コロシアムの戦い, and "真" is the prefix added to "The Arena" to make it "The True Arena" in Japanese. So, it's safe to do something similar in English. "True" plus "Arena Showdown", resulting in "True Arena Showdown".

Of course, by allowing this, these names aren't translated names anymore, but instead derived, so marking them with the Template:ForeignTitle makes it misleading. So I also propose the creation of a "Derived from Japanese" template, to mark articles with names that aren't direct translations, but rather use the Japanese name as a guide of sorts for the article's title. These would still put pages in the Category:Articles with titles from non-English languages regardless, as the source of the name is Japanese. Finally, while it could be argued that these titles could end up being speculative, I believe that as long as there are basis to go with (such as in the examples I gave), adapting names like that should be fine. And, of course, if there is ever diverging opinions about what to name a page, that could be discussed on its talk page.

Thoughts? - Gigi (talk • edits) 00:55, 28 July 2021 (UTC)

Support
  1. I'm in support of this: I realize we don't have a consistent solution for this, so it'd be best to stick with the direction we're already going and make it formal. I think that'd also mean articles like Hoshi no Kirby Yume no Izumi no Monogatari (soundtrack) and Hoshi no Kirby 64 Original Soundtrack would have to be moved, but I'm fine with that. (I assume Kirby Wii Music Selection would stay the same since it's already in English? I suppose we can discuss that later...) StrawberryChan (talk) 01:07, 28 July 2021 (UTC)
  2. Gigi and I spent a lot of ASCII hammering out the finer details of this idea, and I am pleased with the result, so I support. --Samwell (talk) 01:08, 28 July 2021 (UTC)
  3. Direct translations, while technically more true to the source material, can be flawed, misleading, or contradicting localization sometimes and can require interpretation, which is what this proposal aims to allow (if I'm understanding it correctly). Support. ---PinkYoshiFan 16:13, 28 July 2021 (UTC)
  4. Another example I can thing of is Big Metalun, and since we had an IP user got confused by this recently, it should definitely be clarified. Superbound (talk) 21:46, 2 August 2021 (UTC)
  5. Definitely seems like a good idea. This should lessen confusion and having a solid solution for going about Japanese names will be good, as said by the other supporters. -- Jellytost♡ (talk) 02:26, 3 August 2021 (UTC)
Oppose
Neutral

Discussion

To answer StrawberryChan, this would only apply to names written in Japanese, so Kirby Wii Music Selection wouldn't need to be moved since it's written in English. As for Kirby's Adventure and Hoshi no Kirby 64 Original Soundtrack we could discuss them further later. I wouldn't be against making an exception for album titles since they aren't often translated and aren't many articles anyway. - Gigi (talk • edits) 01:22, 28 July 2021 (UTC)

Overhaul to writing standards regarding humor (July 5th, 2021 - July 19th, 2021)

Hey, everyone. It's come to attention recently that the writing standards may be a bit too lenient in allowing for non-encyclopedic jokes in articles. While it's important that WiKirby doesn't take itself too seriously, it's also important that it doesn't become overridden with writers focusing on comedy over quality. The important bits from the previously linked article and the writing specifics are outlined below:

  • WiKirby serves to display a certain sense of whimsy and humor when describing subjects. However, WiKirby does not intend to have subjective opinions on these subjects which may color the reader's judgments, especially if those opinions are comparison-based.
  • WiKirby likes a bit of joviality, especially when it comes to clever use of wording and creative ways to spell out summaries. However, humor should not take precedence over the essential information of the article. Generally speaking, jokes should be confined to captions for images that do not require an explanation, if they appear in article text at all.

It should be emphasized that WiKirby focuses on information first, and this is outlined in both of these statements. They are otherwise rather vague, however, which can lead to some misunderstanding regarding what kind of humor is appropriate and inappropriate for each article. The general idea is that overt jokes should not be allowed in articles—the comedy generally comes from a sense of tongue-in-cheek humor, describing a fanciful series in a serious and practical manner. In other words, a more casual manner of describing information than most wikis is fine for our tastes, but not to a point where it becomes unprofessional. The above statements could be rewritten as such to reflect this:

  • WiKirby has a casual style of writing that suits the whimsical nature of the Kirby series. However, WiKirby does not intend to have subjective opinions on these subjects which may color the reader's judgments, especially if those opinions are comparison-based.
  • WiKirby aims to be informative, but also to avoid being dry and authoritative. A matter-of-fact tone is encouraged; a sense of wit is also welcome, but should not take precedence over the essential information of an article. This includes things that are otherwise self-evident, such as image captions. We're not looking to make the reader laugh.

This has been discussed on the Discord server already, but further discussion can take place here, as well. What are your thoughts? StrawberryChan (talk) 00:26, 5 July 2021 (UTC)

Support
  1. I support this clarification. Should hopefully cut down on any confusion about what is and is not allowed in article text. --Samwell (talk) 00:32, 5 July 2021 (UTC)
  2. Support because I agree that clarification is needed, and we shouldn't be making image captions with humor as the main goal. - Gigi (talk • edits) 00:44, 5 July 2021 (UTC)
  3. Humor is a good side effect, but yeah, this should be clarified to note that the main intent shouldn't be jokes. ---PinkYoshiFan 01:08, 5 July 2021 (UTC)
  4. Sounds like a good idea to me. Clarification on this would be nice and would make things less confusing. -- Jellytost♡ (talk) 05:30, 5 July 2021 (UTC)
  5. These two guidelines have confused me since I joined, so making them less confusing would be nice. Hewer (talk · contributions) 14:22, 6 July 2021 (UTC)
  6. Being more clear is always nice. Superbound (talk) 14:47, 6 July 2021 (UTC)
Oppose
Neutral
  1. Personally I wouldn't mind non-encyclopedic jokes on image captions but I guess it would be better not to have them.--kirb 14:40, 6 July 2021 (UTC)

Discussion

Allow Autopatrol users to mark files as Good (July 1st, 2021 - July 15th, 2021)

Greetings. It has come to my attention that a lot of file uploading has been undertaken by some of our more active users in Autopatrol rank. Due to the sheer quantity of them, I think it is impractical for Patrollers+ to be chasing all these files and marking them as Good, especially since the users in question uploading the files have already taken care to ensure they meet the qualifications. As such I propose that Autopatrol users be allowed to mark these files Good themselves. Note that this does not extend to articles, as those are subject to a stricter standard and ideally should still be looked over by a Patroller+. What do you all say? --Samwell (talk) 18:58, 1 July 2021 (UTC)

Support
  1. I was thinking of proposing the same but also including articles, although now that you point it out, I agree that files in particular are less of an issue, plus there are way more of them. So, since Autopatrol users are trusted and manually selected for the rank, I don't see why not. - Gigi (talk • edits) 19:07, 1 July 2021 (UTC)
  2. Autopatrol users have already demonstrated that they can be trusted, and trusting them with marking files as Good seems like it makes sense, especially since some users mark things as Good, only to have the edit undone since they aren't wiki staff. ---PinkYoshiFan 20:19, 1 July 2021 (UTC)
  3. I don't see why not. As said by Gigi and PYF, autopatrol users are trusted users who deserve to at least mark files as Good and giving them this permission would make things much easier, but I agree that marking articles as Good be left up to Patrollers+, especially because doing otherwise would leave Patrollers with little to no special permissions in their rank. :P -- Jellytost♡ (talk) 06:07, 4 July 2021 (UTC)
  4. Yes, this is a good idea. Uploading images is something that the wiki needs a lot of, and something new users are often willing to do.--kirb 14:37, 6 July 2021 (UTC)
Oppose
Neutral

Discussion

Tweak various policies regarding files (May 14th, 2021 - May 27th, 2021)

Something I've noticed every since I started editing here on WiKirby was how we had no written guidelines about various things about files. We have policies like WiKirby:Image standards, WiKirby:Audio standards, WiKirby:File use policy, which are all great, but they don't cover everything about files. In fact, we have various unwritten rules already been enforced here that aren't written anywhere. I'm going to list all these and propose what to change to make them clearer.

No file redirects

It is written nowhere in the pages Help:Redirects and WiKirby:Deletion policy that file redirects aren't allowed, and should be removed from pages and marked for deletion. It is not mentioned either in WiKirby:File use policy. Help:Moving pages is focused on pages, it encourages users to leave redirects, which could lead new users into thinking the same applies to files. In short, it's not mentioned anywhere.

My idea is to mention in Help:Redirects that file redirects should not exist under any circumstance. WiKirby:Deletion policy should list file redirects as candidates for deletion. Help:Moving pages should have a section explaining that an editor not on Autopatrol+ should, after moving a file, change all uses of the file to the new name and mark the file redirect for deletion. Users on Autopatrol+ should move files without leaving a redirect.

Cropping transparent images and optimizing files

These two trends, mainly optimizing files, started with WiKirby:Project Clean-Up. I see them as productive, and I would like to have them listed as recommendations in some policy pages. I don't believe we need to enforce them formally, but saying that it is preferred to do so would be nice.

Cropping transparent images basically means removing empty space from them. Many times files from official sites are transparent, but they have lots of empty space. The extra space makes the image appear smaller on the wiki, since it's accounting for all that empty space. My idea is to add a small note on WiKirby:Image standards to do that with any transparent image.

Optimizing files means running them through some image optimizer program to make them as small in file size as possible without losing quality. I would like to mention it also in WiKirby:Image standards, with a note that it's optional, and an editor looking into optimize images needs to do it loselessly.

File naming guidelines

WiKirby:Naming policy right now only lists guidelines for naming pages, which makes sense. WiKirby:Image standards#Other image procedures and details has a general "give a good name to the file, or it will be moved or deleted". However I believe we need at least some basic rules so that we can consider a name file good enough, without small disagreements on if it could have a better name. Ever since WiKirby:Project Clean-Up started, different users have inforced different rules for naming. At core they all have the same principles, and so I'm going to list those here. My idea isn't to make very specific guidelines like the regular naming policy, but I believe we still need some small guidance. The basic rules I propose are:

  • The file name must have the subject (eg. Kirby), the game or media it's from (eg. KSSU), and if it's an image the type of image (eg. Artwork). Order doesn't matter. So "Kirby KSSU Artwork", "KSSU Kirby Artwork", "KSSU Artwork Kirby" and "Kirby Artwork KSSU" are all acceptable;
    • However, the beginning of the file name should give enough information about the file itself. In other words, the subject must be in the beginning of the file name if it's very long (this is specifically to prevent issues such as this whole category page being impossible to navigate);
    • The game should use the abbreviation from WiKirby:Abbreviations.
  • Proper nouns in the file name should be capitalized, other words are up to the file uploader;
  • No restrictions about using special characters, as long as the file name is readable, with the exception of periods, that should be avoided to not mess up with the definition of the file type. So no file names with Japanese characters, but characters such as ' and & are acceptable for example.

And as the final guideline:

  • Files should not be moved unless it's to fix an issue with these guidelines.

That way we don't have "move wars". With the example I used, if there is a file named "Kirby KSSU Artwork" it's acceptable. It shouldn't be moved to "KSSU Kirby artwork". This is equivalent to editing a page and changing certain words but still keeping the same meaning, which isn't productive at all.

All that should then be listed in WiKirby:Naming policy, and WiKirby:Image standards and WiKirby:Audio standards should list them and link back to the naming policy. Help:Moving pages should mention files and explain when they should and shouldn't be moved.


What do you all think? - Gigi (talk • edits) 20:17, 14 May 2021 (UTC)

Support
  1. I find no problem with any of these changes, with the no file redirects rule being especially helpful and the rule regarding all filenames having certain parts certainly helping out with being consistent, even if just a small bit. ---PinkYoshiFan 22:19, 14 May 2021 (UTC)
  2. Per my comment down below. Superbound (talk) 06:01, 15 May 2021 (UTC)
  3. General support for this. See my input down below for details. --Samwell (talk) 16:59, 17 May 2021 (UTC)
  4. I've been thinking and I now agree with almost all of the proposals. The file redirects could be used for something and only should be disabled for most purposes. We should be cropping transparent files to make them look at their best. I realize that having one specific way to name files is too strict and new contributors might break the rules immediately if stricter file naming rules are applied. - GameDoor64 (talk) (edits) 22:07, 17 May 2021 (UTC)
  5. I haven't really considered before the reasons found below in the discussion panel as to why preventing the creation and existence of file redirects may cause some problems. I'm largely neutral either way regarding this. If we do end up keeping certain file redirects, as long as we diligently keep them off articles, I've nothing against it. As for recommending images to be cropped and optimized on some policy pages, I entirely agree with it. As for file naming guidelines... I really don't think we need any strict guidelines as Gigi said. A lot of moves I've seen have seemed unnecessary. Renaming "KSSU Birdon Artwork.png" to "KSSU Birdon artwork.png" is very unnecessary, for example, so I generally agree that we should only move files if there is a problem in which the file needs to be moved, not just because of personal preference. Some sort of ordering for the respective subjects in file names could possibly be positive, especially in "sets" of similar files and to avoid a situation where "KSSU Birdon Artwork", "KSSU Birdon artwork", and "Birdon Artwork KSSU" all exist for example, but renaming many if not all files to a set order does largely seem like an unachievable task that's not really worth the effort in all, and I could definitely see said "sets" being defined differently between editors and becoming controversial, as Gigi said. Sorting through these different definitions and picking out one and strictly using it honestly seems like more work than it's worth to me, especially since again, as Gigi said, we're a Kirby wiki, and having extremely strict guidelines just doesn't seem fitting for us. As long as the file tells me simply what I want to know about it, I'm satisfied.
To summarize, I generally agree with this proposal and support it. -- Jellytost♡ (talk) 06:31, 27 May 2021 (UTC)
Oppose
  1. I agree mostly, but disagree on a few minor points such as putting the game abbreviation first and allowing special characters. --kirb 09:37, 27 May 2021 (UTC)
Neutral
  1. Point 1 and 2 go without a say, but I disagree with third's subpoint 1 and subsequently 4. Policy is supposed to guideline editors into naming new files well in the first place, so 4th doesn't need to happen (and instead say to not capitalize "Artwork / Sprite / Screenshot"). Order doesn't matter because they only affect categories really (they're findable by searching too), so sure there, but I'd prefer type on last place. If someone is willing to make a small set of consistency moves at a time, that's fine. (Again, regardless of actual vote outcome, please regard the discussion made below, so multi-point proposals don't end up 100% yes or 100% no). ⁠–⁠Wiz (talk · edits) 08:29, 15 May 2021 (UTC)

Discussion

I fully agree with points one and two.

Point 1: File redirects are not necessary, and only take up space. As the proposal states, they only exist to help new users not accidentally move a file and break many pages. Adding a note in the policy stating that file redirects are discouraged will not only let new users know, but also remind them to properly change the links on images they moved.

Point 2: Both optimizing and cropping are two helpful tactics to reduce file space and size, especially when loaded on pages. It is a very good idea to encourage these. (It should be noted that it actually increases the total space used up as MediaWiki keeps all versions of a file unless they are specifically deleted, and even then the file exists only visible to admins+.)

Point 3: The third point is one where I partially disagree. I do agree that all filenames should contain the subject, WiKirby game abbreviation, and image type unless not needed. The parts I don't completely agree with are that the order does not matter, non-proper noun capitalization is up to the uploader, and files should not be moved unless necessary.

Subpoint 1: I think that the order of the words of the filename can be important in situations where multiple files exist, all with the same name but different order. I have moved many files and seen many situations where "KSSU Kirby Artwork", "KSSU Kirby artwork", and "Kirby Artwork KSSU" all exist as an example. This is why I personally always put the game abbreviation at the beginning, so when I scan through the image category, all of the similar files are grouped together. In regards to the Commemorative Illustration category, it is a very rare occurrence. In it's case the subject should go at the beginning of the name because of how long "Twitter Commemorative Illustration" is. For nearly every other category, the game abbreviation is 2-5 characters long, and does not take up a lot of space (KA, KSS, KRtDL, KPR, KF2), and the image type (sprite, artwork, screenshot) is at the end of the filename usually. Putting the game abbreviation is my personal preference, because if every image starts with the abbreviation, none of them do in regards to alphabetical order.

Subpoint 2: Proper nouns should always be capitalized in filenames, but other words probably shouldn't. I'm not sure if it should be a rule, but it should be suggested that words such as "concept artwork", "screenshot", "and", and "scene" don't really have to be capitalized. (They nearly always aren't right now.) I would ask that we suggest uploaders to not put any words in FULL CAPS that aren't supposed to be, as this is not useful and kind of annoying.

Subpoint 3: Special characters can be allowed in filenames, with the exception of non-readable characters (Japanese, Arabic, Russian) and periods (which can mess with the filetype). We should probably also ban emojis from filenames although nobody has attempted uploading emoji names yet as far as I know. While special characters are allowed, they should only exist if they are part of the name, such as allowing "KSSU Daroach's Airship screenshot.png", but not allow adding extra characters that don't need to be there. In general, there shouldn't be extra words/characters added to filenames. ("KA Kirby sprite.png" vs "Awesome Kirby picture (Adventure) image ~ sprite.png")

Subpoint 4: I think that files should be moved to match with similar files. If there are a lot of files like "KSS Stone artwork.png", than if one file is "Spark Artwork KSS.png" it should be changed to fit in with the rest. It doesn't need to be required or top-priority that filenames be similar to others in their group, but it shouldn't be a bad thing to make one file fit in with the rest. --kirb 20:37, 14 May 2021 (UTC)

For reference, I don't want to make extremely strict rules to naming files. Most of your counterarguments seem to favor that.
Subpoint 1: I will be honest, I fail to see the point you're making here. Can you explain better?
Subpoint 2: Again, it doesn't really matter if they aren't capitalized or not unless it's proper nouns. Moving a file just to change that isn't necessary. If you think it is, could you please elaborate?
Subpoint 3: Fair enough. That is what I was going with that.
Subpoint 4: The issue with this is where you draw the line. What are "similar files"? How do we define that? Do all artwork files need to follow the same pattern? Or just files from a certain game? Or just copy ability files? It starts to become extremely arbitrary.
Again, I just want a simple set of guidelines just to make sure people aren't naming a file like "poppy bros. jr. kssu.png". I really don't want us to make very specific guidelines to files because they are mostly hidden to editors. And I keep seeing unnecessary edits to files that I would really rather see stop. That is all. - Gigi (talk • edits) 20:47, 14 May 2021 (UTC)
I agree that it can be difficult to determine what makes files "similar", but I mainly didn't want to be prohibited from moving a few files to match with closely-related files. I think all files in a "set" should follow the same format. A "set" being very specific, such as all copy ability sprites from a certain game, or every screenshot from a certain stage. Most images are not like this, but many are. If all of the Super Star Copy Ability sprites follow a format except one, I would want to rename that one. I can however see that many of the moves I have done were not necessary, and I will try not to move files that already have acceptable names. --kirb 21:05, 14 May 2021 (UTC)
The issue happens when someone else considers a "set" different from someone else, or really when different "sets" are used on pages of the same subject. An example: ability icons are usually grouped together in galleries, but some copy ability pages don't do that and icons are between various kinds of files. Compare for example Beam#Gallery and Archer#Gallery, they are very different. Again, it is really arbitrary, and if we made rules for each case we would be here all day making rules and, frankly, we're a wiki about Kirby. We don't need a million rules. Which is again why I think we should have some basic ones and leave the rest for the uploader. - Gigi (talk • edits) 21:27, 14 May 2021 (UTC)
When you say "special characters", which ones do you mean? I don't think we should allow any characters that aren't on a standard QWERTY keyboard. --kirb 01:07, 18 May 2021 (UTC)

I do agree on the first proposal that file redirects shouldn't be allowed and that we should optimize images. I however don't agree on the third proposal. I have renamed over 100 files just to name them like this: KSSU Plasma Wisp artwork. I believe that we should name files like what I mentioned before. - GameDoor64 (talk) (edits) 21:00, 14 May 2021 (UTC)

Your personal guidelines are basically the same as mine. I'm confused as to what you go against my proposed guidelines for files. Care to elaborate? - Gigi (talk • edits) 21:27, 14 May 2021 (UTC)
I just believe that we should have the files named in a certain way for organization. I can see the reason that you're behind with having the files named in any order of abbreviation, subject, type of image. But it'll make finding images easier provided we don't have file redirects. - GameDoor64 (talk) (edits)
I just don't believe we need extremely strict guidelines for file naming when we have categories and galleries and the search function. For me as long as the file name gives me enough information about the file it should be good. Moreover, I would rather to see energy spent on actual bad file names than perfectly fine ones. Not to mention that every user has their personal way to name files, and I fail to see a good reason to move good file names that doesn't have any problems. I personally have my own issues with files starting with the game abbreviations, but I won't go on my way to rename files like that because, honestly, it's not my place, even as the editor-in-chief, to impose my personal opinion on a small thing such as a file name. And frankly, the effort it would be to make all files follow some extremely specific guidelines is too much more work than it's worth. - Gigi (talk • edits) 21:54, 14 May 2021 (UTC)

Why I don't like "strict file name format":

  1. Causes a lot shenanigans. "KSA Susie Artwork.png" is bad, but "KSA Susie artwork.png" is better? Or "Archer KSSU sprite.png" versus "KSSU Archer Sprite.png"? Like why, they basically the same.
  2. As Gigi mentioned above, there is no way we ever agree on what format should be used, as any variation has their own pros and cons. Starting with subject helps navigating game categories, but starting with abbrevs helps in character images. And there's nothing to stop us from just accepting both, so why bother?

I mentioned this some time ago (in abbreviations proposal), and brought it up on Discord few days ago - the descriptiveness matters the most. I strongly support moving files only if there is an actual problem with them. Pointless moves are pointless, bring little to no improvement (or sometimes do the reverse) and clog recent changes.

Points 1 and 2 are just writing already widely accepted unwritten rules, so no problem from me there too. Superbound (talk) 06:01, 15 May 2021 (UTC)

Update: I'm not opposed to allowing file redirect as panda said below me if we decide to do so. Superbound (talk) 10:51, 20 May 2021 (UTC)

To be honest I disagree that file redirects are unnecessary and shouldn't exist. Those who say that probably don't care about external sites linking to our wiki. By not redirecting old filenames to their new names, you break every single link to that old name. And even worse, we don't know how many times that old name is linked to in other sites we don't control.

See Cool URIs don't change by the W3C on why old links shouldn't break.

Now I'm not saying we should allow internal linking to redirects. They should be relinked to the new name. Preventing the creation of redirects is still okay, as long as the old name is not more than two days old, or the old name was blatantly inappropriate and offensive.

A common argument by those who want to exterminate ala Dalek the file redirects is that they cost space. But the thing is, the moment you rename a file, you already took up some space. The moment the redirect was created, you can't take that space back by "deleting" it. In fact "deletions" in MediaWiki are more of just archivals and hiding of content from non-admins. They don't free any space, and will only waste even more space because every "deletion" is logged. pandakekok9 (poyo) 13:56, 15 May 2021 (UTC)

I'll assume this doesn't refer to external sites using up WiKirby's bandwidth with their src attribute, but the ability to find moved files after redirect's deletion. There are 2 ways to delete a file redirect - one is by auto-deleting it when moving it (which tells where the file got moved to), and another is by tagging it for deletion, and the delete tag expects a reason for that. When deleted, all actions with the file or last content when manually deleted is always visible in the reference. ⁠–⁠Wiz (talk · edits) 01:29, 16 May 2021 (UTC)
Nope, I'm not referring to those sites who eat up WiKirby's bandwidth via the img src attribute, but rather those who link via the anchor tag.

Of course you can still find the new name after deleting or preventing the creation of the redirect. It's always logged in the deletion log. But you forgot one thing: the old name can be recreated, thus hiding the new name in obscurity. Of course such thing is very rare, but it can happen. And besides, the average user most likely would be annoyed of not being automatically redirected to the new name.

So with that in mind, what's the point of deleting such file redirects then? None. pandakekok9 (poyo) 02:09, 16 May 2021 (UTC)

Now that you bring this up, I am unsure myself why this wiki has always deleted file redirects. It has been an unwritten rule for as long as I've been in this wiki. We even recently added the permission for any user on Autopatrol+ to move files without a redirect exactly because we deemed them unnecessary.
I am honestly neutral on this subject: as long as pages don't use file redirects I'm okay with that, and I could instead just mention that in the policies and we could start allowing file redirects, and we would need to revert back that permission and only allow Admins+ to move files without redirects.
I do have a question, however: what if a file is, say, named "Kirby KSSU.png" and it is moved to "Kirby KSSU artwork.png". Would a file redirect make sense here? A file named "Kirby KSSU" could be any file of Kirby from KSSU, a sprite, artwork, screenshot etc. In short, generally on WiKirby we move files because of bad or not specific names, would you still argue that these file redirects should exist? - Gigi (talk • edits) 23:02, 16 May 2021 (UTC)
Good question. I think it depends on the age of the old name, and as well as the knowledge on how many times it was linked to. If the old name is relatively new, maybe preventing the creation of a redirect is okay. If a redirect already exists though, they shouldn't be deleted, even if it was a mistake, or the old name is relatively new. Redirects should only be deleted when its name is obviously inappropriate or offensive. A good rule of thumb would be, "if in doubt, don't delete or prevent the creation of a redirect." pandakekok9 (poyo) 04:23, 17 May 2021 (UTC)
And by the way, I won't go as far as removing the privilege of moving files without a redirect for Autopatrol+. They are trusted, established users of the community, and our community is relatively small, so I trust they will do good judgment on whether to create a redirect or not. pandakekok9 (poyo) 04:25, 17 May 2021 (UTC)

Samwell's input

So, let me try to give my thoughts on all the points made here as succinctly as I can so as to avoid this discussion panel getting too much longer than it already is.

  • File redirects: I don't remember when the precedent started to delete all file redirects, but the reasoning that I held for the practice was specifically to prevent situations where redirect links were used in articles and gallery pages. I've personally had to chase after quite a lot of image links that weren't properly changed after a move and were creating viewing issues on pages, and it's easier to find those discrepancies when they are red links via the special pages. However, I don't have anything against file redirects existing so long as we are diligent in keeping such links off articles.
  • I've nothing to add regarding cropping transparent images or optimizing files, since I basically agree with the original proposal.
  • File naming guidelines: This one's a bit tricky, since a great deal of unwritten precedent was established by Trig Jegman when he started Project Clean-Up. In doing so, he set up what was for him a standardized policy that he personally used across the dozen or so wikis he was working on simultaneously, which paid little regard to whatever file naming policies may have existed beforehand (which admittedly for us was not substantial at the time). Personally, I still think it's a good idea to standardize file names to follow one rule set consistently (such as game abbreviation always appearing at the beginning, or always at the end, whichever one we'd decide on), but at the same time, I understand that there's already been so much file moving based on changing standards over the years. The prospect of having to do it all again feels like a Sisyphean task, and it may not ultimately be worth the effort. Also, for lack of a better term, a lot of Trig's name change fixation was fairly petty, as can still be seen on the Project Clean-Up page, and I've felt like tossing out entire sections of the file renaming columns as not worth the trouble. In short, I generally agree with Gigi's sentiment on this last point, that file moves should only be done when the name is not fit for purpose, not just because the capitalization is slightly off.

In summary, I support the proposal generally, but remain neutral on the matter of file redirects existing or not. I will leave that one to Gigi and the rest of the community to decide on. --Samwell (talk) 16:59, 17 May 2021 (UTC)

Small adjustments to Good page criteria (March 15th, 2021 - March 29th, 2021)

So, it was briefly discussed on the Discord that some adjustments should be made to the criteria for deeming an article Good in order to accommodate pages covering entities that only appear once in the series and/or have little to be said about them. On behalf of those in that discussion channel, I propose the following changes to the Good articles criteria on the Featured content policy as follows:

  • Minimum number of bytes for a page to be Good to be reduced from 2,000 to 1,000 (assuming the page is otherwise complete).
  • Status of subpages to no longer be a factor in determining whether the main article is deemed Good or not.

This will be a relatively minor change to the policy, but it should allow many short but complete pages on our wiki to receive the Good mark, as well as sparing the blushes of many of our larger complete pages that have incomplete gallery sub-pages. What say you all? --Samwell (talk) 01:49, 15 March 2021 (UTC)

Support
  1. Definite support. The main thing about a good article is that it should only have to be the best it can feasibly be. If the article's about a minor subject that can't reach 2,000 bytes, but it's still otherwise a fully fleshed-out article, that shouldn't have to hold it back. We definitely want as much detail as possible, but we don't want to encourage padding, either. StrawberryChan (talk) 01:53, 15 March 2021 (UTC)
  2. I agree. Some pages are fully completed but still under 2000 bytes. And a page can be good without it's subpages being so. --kirb 01:56, 15 March 2021 (UTC)
  3. Agreed, not all short pages are necessarily bad (an example that comes to mind is most of the K&TAM rooms). Removing the subpage requirement doesn't hurt either. ---PinkYoshiFan 11:18, 15 March 2021 (UTC)
  4. Actually I think we should remove the bytes requirement, which seems unnecessary IMO and can be an inaccurate metric for completeness (who knows, maybe someone suddenly knew of a way to abstract the content of a 1000-byte good article to a template, shrinking the article down to like 900 bytes. Should we demote the article just because someone knew of a better way to encode an article?), and let the patroller+ judge whether an article is complete enough and of good quality. But this is a good start. As said by others already, there are articles that are short but can't be expanded because it's already complete. --pandakekok9 (poyo) 15:34, 16 March 2021 (UTC)
  5. I support. This sounds like a reasonable idea. Pages can be complete and be worthy of being marked as 'Good' and be under 2000 bytes. They can also be 'Good' even if their subpages are not. -- Jellytost♡ (talk) 02:55, 18 March 2021 (UTC)
  6. As said by others above, if an article covers all information that can be added without question it deserves to be granted good status. Unnecesarily bloating pages with half-correct information to reach 2000 bytes only hurts the credibility of the wiki. For subpages, those often are only relatively minor in general and don't need to affect the main pages in a negative way. Support all the way. Infinite Possibilities (talk) 08:54, 18 March 2021 (UTC)
  7. The Good status is just for pages that are complete. The 2,000 byte limit just encouraged padding for small pages. --DeepFriedCabbage 17:54, 29 March 2021 (UTC)
Oppose
Neutral

Discussion

Revise image standards (sprite-based images, Virtual Console, etc.) (February 25th, 2021 - March 11th, 2021)

Greetings, puffballs and others. In the past, we've had a number of discussions about what constitutes a Good game screenshot on WiKirby, and going by "native resolution" as a default rule has been the de-facto standard for some time now. However, recently, a few hiccups here and there have led me to realize that the current standards are a little too tight in places, and a little too ill-defined in others. As such, I'd like to propose an amendment to the image standards by making the following the new guidelines for what constitutes a Good game screenshot:

Sprite-based games

Screenshots of sprite-based games are Good if and only if they are "pixel perfect"; meaning the pixels are rendered at a 1 to 1 ratio from game to screenshot. It does not matter what is used to capture the screenshot (native console, Virtual Console, emulation, etc.), as long as this is the case. In addition, these screenshots must be clean (no visual distortions and precisely cropped for full screenshots) and originally rendered in lossless format (PNG in our case).

Sprite-based games (along with full screenshot resolution in parentheses) consist of the following:

Non-sprite-based games, native or unofficially emulated

Screenshots of non-sprite-based games that are not being played on Virtual Console are Good if they match the native resolution of the console they were originally made for. In addition, they can be in a file format other than PNG as long as they are clean with no significant distortion.

Non-sprite-based game screenshots should follow the standard resolution of their home consoles, as follows:

Virtual Console games

Screenshots of games emulated using Virtual Console or any other official Nintendo emulation method can be marked as Good if and only if they match the native resolution of the console they are being played on, are clean, and are not sprite-based. They must also all be marked with the {{VC}} template (a file template marking an image as coming from Virtual Console that will be made if this proposal passes). For the sake of clarity, games that are being played on backwards-compatible devices with higher resolution (such as Wii games on Wii U) will also be treated as Virtual Console.

That should about do it. Let me know if there are any concerns with this proposal, and I will seek to make further amendments where applicable. --Samwell (talk) 21:04, 25 February 2021 (UTC)

Support
  1. Support; the image standards definitely need more consistency, and this seems like a good solution. The Virtual Console template, in particular, feels like it will be incredibly useful in the long run, as we may want to provide VC screenshots later on for comparison (for example, Zero's arena in Boss Butch). StrawberryChan (talk) 21:13, 25 February 2021 (UTC)
  2. These changes definitely look like they would help the clarity of our policies, and a VC template is definitely a good idea to differentiate them from native shots while still being allowed on articles. --YFJ (talk · edits) 22:20, 25 February 2021 (UTC)
  3. Clarity is good, especially with how to deal with official upscales. ---PinkYoshiFan 22:24, 25 February 2021 (UTC)
  4. This is a good compromise for everything we have available. Keeps things consistent, while still allowing screenshots from every console that can run each game when applicable. - Gigi (talk • edits) 22:33, 25 February 2021 (UTC)
  5. Not much new to say from me, I agree with all changes made by this proposal, especially VC template. Superbound (talk) 11:46, 26 February 2021 (UTC)
  6. I also don't have anything new to point out here. It sounds like a reasonable solution with consistency. This VC template also sounds like a good idea. -- Jellytost♡ (talk) 07:30, 28 February 2021 (UTC)
Oppose
Neutral

Discussion

I see that KDL2 has a specific rule about SGB. I think this one needs to be cleared up. Should we include the KDL2-specific border from SGB when making screenshots in SGB? Also note that a real Game Boy would only run KDL2 in monochrome, and without any border, therefore screenshots like this one are inaccurate, since it is colored and doesn't show any SGB border. So my point is, should we still allow SGB screenshots of KDL2 without the border? If so, then I don't see the point of allowing SNES resolution for KDL2. pandakekok9 (poyo) 14:52, 28 February 2021 (UTC)
Keep in mind that the stated resolution applies only to full screenshots, and that an image can still be marked as Good if it crops out unnecessary detail (as is often done to highlight specific characters or objects). So, for Super Game Boy screenshots, it is okay to crop out the border if there is no need to show it. --Samwell (talk) 16:01, 28 February 2021 (UTC)
Okay, that cleared that up for me, thanks. pandakekok9 (poyo) 02:36, 1 March 2021 (UTC)
Regarding SNES games, screenshots coming from Kirby's Toy Box were all 256×239 (which is one of valid resolutions, mind the odd number), and all screenshots on the 'net are this resolution too. I followed Pandakekok9's first upload and cropped all 8 currently uploaded screenshots to 256×224 manually since I couldn't find a way to emulate at this height. Should this be a valid alternative resolution? —Viperision (talk) 17:30, 2 March 2021 (UTC)
Kirby's Toy Box is a sprite-based game, so just use whatever resolution you need to keep a full screenshot pixel perfect. --Samwell (talk) 17:46, 2 March 2021 (UTC)

What to do with bigger but JPG images and smaller but PNG images (February 22, 2021 - March 8, 2021)

There are plenty of images on this wiki, which also includes artwork. As many may know, PNG is the best for artwork, however, sometimes it isn't the largest one available, like with Kirby 64 Cilly...

Chilly K64 artwork.jpg K64 Chilly Transparent Artwork.png
(left - JPG, right - PNG)

...or Air Ride Warpstar.
KAR Warp Star Artwork.jpg KAR Warpstar Small.png
(left - JPG, right - PNG)

Significant drop in resoltiuon. On the other hand, images aren't that often used to be this large, and most of them are in galleries in following size:

  • OH NO, COULD IT BE–

    OH NO, COULD IT BE–

  • WARPSTARS?!

    WARPSTARS?!

  • lmao they r scared of us

    lmao they r scared of us

  • ha ha silly snowguys

    ha ha silly snowguys

As you can see, it's hard to note a difference in quality, but transparency works better here.

So what do we do?

  • List both - In case something like this happens, both images will be displayed, with caption like "Smaller but transparent version od a previous artwork"
  • PNG > JPG - Favor smaller PNG over bigger JPG.
  • JPG > PNG - Inverted version of above.
  • Case-by-case basis (so nothing changes) - This is oversimplifaction of something complicated, and each case like that should be reviewed seperatly.

Superbound (talk) 18:56, 22 February 2021 (UTC)

List both

  1. This has been my de-facto way of handling this artwork, so I'll go with this option. --Samwell (talk) 19:45, 22 February 2021 (UTC)
  2. Listing both means keeping both. In the worst-case scenario, convert a JPG to PNG (and upload to same filepage) to preserve both versions. —Viperision (talk) 20:18, 22 February 2021 (UTC)
  3. Second choice. --DeepFriedCabbage 19:41, 27 February 2021 (UTC)

PNG > JPG

JPG > PNG

Case-by-case basis (so nothing changes)

  1. It is heavily redundant in my opinion to use the same image twice for things, but that said, I think that is truly situational about the image's quality overall. In more instances than not, a JPG is usually larger and cleaner, and despite having a background, is easier to make out. JPGs are also usually better to avoid situations Like this [dead link] where transparency in images doesn't always look good, especially for dark mode nerds like myself. In other circumstances, the PNG may be a higher quality despite being smaller, and would look better in both galleries AND infoboxes, where JPGs generally only look good in galleries. I would stress that both have their advantages and disadvantages, and if an editor isn't sure, they can either bring it up on discord or upload both and allow the community to decide. Trig - 22:04, 22 February 2021 (UTC)
  2. PNGs are only different enough than JPG (from a visual standpoint, at least) to where we should only replace JPG with PNG the PNGs have transparent backgrounds or if the JPG is smaller than or equal in size to the PNG. So basically, (in my opinion) if the JPG is bigger and the PNG isn't transparent, then use JPG. Otherwise, use PNG. ---PinkYoshiFan 22:09, 22 February 2021 (UTC)
  3. Agreed on case-by-case. PNG isn't always automatically better than JPG and vice-versa; it's ultimately down to the image itself. Generally a PNG with a transparent background is most preferable for an infobox, while a JPG can look fine if a transparent version of the image isn't available. Listing both seems redundant to me. StrawberryChan (talk) 03:40, 24 February 2021 (UTC)
  4. I've been thinking and I'm going to go with case-by-case here. These cases seem rare from what I've seen, and generally it's better to have both, but it really depends on the case. Rather than make a very black and white rule for a situation that doesn't happen that often, I would rather keep it case-by-case. - Gigi (talk • edits) 16:07, 24 February 2021 (UTC)
  5. As cases are not unified, neither should our solution. Enough said. --kirb 04:06, 25 February 2021 (UTC)
  6. I honestly can't add any more to what's already been said. PNG is not inherently superior to JPG or vice versa, and it really comes down to the individual quality of the images. --YFJ (talk · edits) 21:58, 25 February 2021 (UTC)
  7. I think PNGs are generally better than JPGs, but if we have a JPG that's tranparent, we should include both. --DeepFriedCabbage 19:41, 27 February 2021 (UTC)
  8. JPGs are usually inferior to PNGs, but it all comes down to the quality of the image itself since that isn't always the case. Having a hard rule for PNG over JPG or vice-versa would be a bit too tight and would likely do some damage to the overall quality of our images. Listing both is a better alternative to that, but as stated above, due to redundancy, that probably would not be the best option here. Therefore, in my opinion, this should be done case-by-case. -- Jellytost♡ (talk) 07:30, 28 February 2021 (UTC)

Neutral Comments

  1. Superbound your captions are funny :p. --kirb 22:13, 22 February 2021 (UTC)

Discussion

To respond to Viperision, I would intensely affirm that images should never ever not ever be converted from lossy to lossless or lossless to lossy, as it entirely butchers the quality of the image and is generally entirely ineffective at comparing multiple images. There is no harm to having two images and one being deleted, as mentioned in my vote. Trig - 22:04, 22 February 2021 (UTC)
JPG to PNG is this "worst-case scenario" in order to (if listing both is not a viable option, which I doubt) attempt to preserve two versions of same artwork. It's still valid to try conversion, investigate whether CMYK to RGB butchered anything, and decide to (not) upload. My "list both" vote regards cases where both (JPG and PNG) versions have valid advantages, in order to not have a perfectly fine transparent but smaller PNG version be deleted, and vice-versa for larger JPG versions. For wiki's display purposes it may not be all that important and most users will likely not notice another version preserved in file logs, so definitely list both and don't bother with conversion. —Viperision (talk) 20:17, 28 February 2021 (UTC)

Reform WiKirby: Abbreviations (January 23, 2021 - February 6, 2021)

Alright. You remember the Great Debate we had on WiKirby talk:Abbreviations? This is where we put that into effect.

Let me get this out of the way. The purpose of the abbreviation policy page is to standardize naming patterns for filenames. And that's where it miserably fails. More than one abbreviation per game? Abbreviations for consoles and Kirby Super Star subgames? Abbreviations for characters that no one will ever use? Yeah, let's fix that.

I propose we completely rewrite the abbreviations list and only use the following abbreviations:

Kirby's Dream Land - KDL
Kirby's Adventure - KA
Kirby's Pinball Land - KPL
Kirby's Dream Course - KDC
Kirby's Dream Land 2 - KDL2
Kirby's Avalanche - KAv
Kirby's Block Ball - KBBa
Kirby's Toy Box - KTB
Kirby Super Star - KSS (as determined by discussion)
Kirby's Star Stacker (Game Boy) - KSSGB
Kirby's Dream Land 3 - KDL3
Kirby's Star Stacker (Super Famicom) - KSSS
Kirby 64: The Crystal Shards - K64
Kirby Tilt 'n' Tumble - KTnT
Kirby: Nightmare in Dream Land - KNiDL
Kirby Air Ride - KAR
Kirby & The Amazing Mirror - KaTAM
Kirby: Canvas Curse - KCC
Kirby: Squeak Squad - KSqS
Kirby Super Star Ultra - KSSU
Kirby's Epic Yarn - KEY
Kirby Mass Attack - KMA
Kirby's Return to Dream Land - KRtDL
Kirby's Dream Collection Special Edition - KDCSE
Kirby: Triple Deluxe - KTD
Kirby Fighters Deluxe - KFD
Dedede's Drum Dash Deluxe - DDDD
Kirby and the Rainbow Curse - KatRC
Kirby: Planet Robobot - KPR
Team Kirby Clash Deluxe - TKCD
Kirby's Blowout Blast - KBBl
Kirby Battle Royale - KBR
Kirby Star Allies - KSA
Kirby's Extra Epic Yarn - KEEY
Super Kirby Clash - SKC
Kirby Fighters 2 - KF2

Super Smash Bros. series - SSB
Super Smash Bros. - SSB64
Super Smash Bros. Melee - SSBM
Super Smash Bros. Brawl - SSBB
Super Smash Bros. for Nintendo 3DS / Wii U - SSB4
Super Smash Bros. for Nintendo 3DS - SSB4-3DS
Super Smash Bros. for Wii U - SSB4-WiiU
Super Smash Bros. Ultimate - SSBU

Kirby: Right Back at Ya! - KRBaY

What say you all? Vote below or voice any suggestions you may have. --YFJ (talk · edits) 21:59, 23 January 2021 (UTC)

Support
  1. I say yes, as we need more consistent abbreviations.--kirb 22:01, 23 January 2021 (UTC)
  2. I've no issue with this set of abbreviations, as I believe we've done a more than adequate job of ironing them all out. I am looking forward to having a consistent set of abbreviations on the wiki for file naming purposes. --Samwell (talk) 22:02, 23 January 2021 (UTC)
  3. Abbreviations being inconsistent is a major problem that needs to be fixed. This fixes that, so support. ---PinkYoshiFan 22:03, 23 January 2021 (UTC)
  4. Support. I'm guilty of adding a lot of the superfluous abbreviations myself, and it's better to be concise and consistent. StrawberryChan (talk) 01:06, 24 January 2021 (UTC)
  5. The abbreviations chosen above should do well, and having consistency would be a good idea, so I support. -- Jellytost♡ (talk) 21:08, 24 January 2021 (UTC)
  6. Abbreviations are looking really simple and clean for file naming, so I'm on the support side. EleCyon (talk) 10:14, 25 January 2021 (UTC)
  7. Consitency is good and all that. Superbound (talk) 18:34, 25 January 2021 (UTC)
  8. Best to have only one abbreviation per game, and the choices are all good. - Gigi (talk • edits) 18:56, 27 January 2021 (UTC)
  9. Only having one abbreviation per game brings more consistency which is a good thing. And the choices are the most common abbreviations for their respective games.Infinite Possibilities (talk) 14:04, 30 January 2021 (UTC)
Oppose
Neutral

Discussion

Add Colored Titles to Dream Friend Pages (January 19th, 2021 - February 2nd, 2021)

The title of the Kirby page uses a custom color for the font, pink. As of Kirby Star Allies, each of the delineated Dream Friends were given a specific color for their name and two colors for the background of their summon screen. I propose that we add a custom color to the titles of the Dream Friend pages. While there could be some debate for which colors to use, I think the colors used specifically for the character's names makes the most sense. My logic is, we have specific colors associated with each of the Dream Friends, and a method of adding color to individual page titles. It would be a fun visual flair for characters highlighted as important to the series. The only drawback currently is that the special font that Kirby's page uses isn't currently on every Dream Friend's page, as the font is used exclusively for featured pages. That being said, we could vote to add the color once each character's page gets featured, and add color to the ones that are currently using the font. Either way, it would be a nice use of the (at the time of posting this proposal) new font's color feature, and exemplify a little bit of extra trivia from the Kirby series. LeoUnlimited (talk) 02:55, 20 January 2021 (UTC)

Support
  1. I support this; it'd be a cute detail. I could work out the colors for each of them once this passes and they're featured. StrawberryChan (talk) 02:58, 20 January 2021 (UTC)
  2. I concur, granted we can get all the Dream Friend articles featured. After all, would be a shame to add the color to a page that was not up to snuff. --Samwell (talk) 03:05, 20 January 2021 (UTC)
  3. Colors, colors, everywhere, I want them on the names all around. And that gives me a huge support, for they are super ultra astound! On a serious note, however, that's a nice little detail and I'd like that, especially if Kirby's title color is pink. EleCyon (talk) 03:07, 20 January 2021 (UTC)
  4. Yes. Color good. Much add.--kirb 03:08, 20 January 2021 (UTC)
  5. I feel that, since we do this for Kirby, it's only fair we do it on Dedede, Meta Knight, and Bandana Waddle Dee as well. And I'm certainly not opposed to doing it for the other Dream Friends, too. --YFJ (talk · edits) 03:18, 20 January 2021 (UTC)
  6. It would be a nice touch to the Dream Friend articles, and it will do no harm, so I support. -- Jellytost♡ (talk) 05:50, 20 January 2021 (UTC)
  7. It would be a nice touch, but we should only use the special font if it's already an FA, and instead just colorize the preexisting font if not. ---PinkYoshiFan 12:59, 20 January 2021 (UTC)
  8. I also support this, even if as of right now most Dream Friend articles aren't featured; the ones that are at least deserve some color. - Gigi (talk • edits) 17:32, 20 January 2021 (UTC)
  9. I support this; it would add more variety to the article titles. Hopefully we can get all the Dream Friend articles featured so they can all have colorful titles. --DeepFriedCabbage 18:58, 20 January 2021 (UTC)
  10. I don't see anything speaking against it. It would set them apart more from regular articles and is a cute asthetic. Infinite Possibilities (talk) 16:26, 23 January 2021 (UTC)
Oppose
  1. I would prefer plain white over other color, but that's not the main reason I'm opposing. I don't like how the proposal affects only Dream Friends. Other featured characters should be treated as equal, as they are (mostly) the same but still high quality. Superbound (talk) 18:34, 25 January 2021 (UTC)
  2. I doubt that this changes the end impact, but I want to emphasize that this creates an even larger inconsistency amongst page design and its one that I would drastically prefer to not exist. Trig Jegman - 14:47, 26 January 2021 (UTC)
  3. It works for Kirby since it's pinkish on pink background, however looking at most Dream Friends' main colors I'm can't imagine they would work as text color (except for Meta Knight and blue at some extent). Take King Dedede (blue, yellow, red) and Daroach (grey, red) for example. It would also create inconsistency and some people prefer less (clashing) colors. —Viperision (talk) 10:18, 2 February 2021 (UTC)
  4. Thinking about it, I'm more convinced by the opposition here, than the supporters above. Consistency is important. --pandakekok9 (poyo) 10:46, 2 February 2021 (UTC)
Neutral

Discussion

If the proposal passes, why don't we go full aetjic and color other things in the pages, like tables? Superbound (talk) 18:34, 25 January 2021 (UTC)

Perhaps a few colorful touches to the wiki could do nicely, but we mustn't make anything too colorful since I know there are plenty of users who wouldn't take very kindly to vivid colors. -- Jellytost♡ (talk) 04:58, 30 January 2021 (UTC)
I think it's important that this doesn't open the floodgate to full inconsistency for the sake of playful design. This is about the upper limit, in my opinion. I can definitely see the reasoning against doing so, and keeping it solely to Dream Friends is important with regards to establishing a boundary. StrawberryChan (talk) 12:22, 2 February 2021 (UTC)

Though the proposal has technically passed, I would like to show some examples of colored title text: King Dedede, Meta Knight, and Bandana Waddle Dee. These are based on the two-tone colors used by their Dream Friend icons. Any thoughts before the full go-ahead? StrawberryChan (talk) 22:31, 3 February 2021 (UTC)

Replacing the image-based title font (January 5th, 2021 - January 19th, 2021)

This has been a bit overdue, and I'm not really sure how detailed this needs to be, but I'll go ahead and do my best to explain it. Basically, the "title font" (currently used for the titles of featured articles, as well as a few odds and ends like the old home page) is based the font from Kirby's Dream Collection and works by using individual sprites of each letter, which are then converted from text to images. Aside from being somewhat slow and inefficient, this presents a major problem for those who use screen readers: since the title font is not an actual font, the screen reader will not read the title properly, thus resulting in missing information for people with blindness or visual disabilities. This isn't an insignificant portion of people, so it can't just be ignored.

The solution was to find a way to convert the title font to an actual font rather than images. While the actual font, Pop Happiness, is free to download for personal usage, using it in commercialized work requires an expensive license, and since the wiki has ads running, this is not feasible. We were able to find a workaround by using a free substitute, Delfino, which is based on the same font (it's traced from the dialogue in Super Mario Sunshine, hence the name). It's not a perfect recreation, but it gets the job done, and solves the above problem as well as looking cleaner in close-up. Delfino has been implemented on the wiki's server and is currently being used on the main page. There is already a template ready to go, so the final step is properly implementing it across the wiki.

Image-based title font:

{{title font (old)|cH|e|l|l|o}} {{title font (old)|w|o|r|l|d|exclamation}}

Text-based title font:

Hello world!

Above is a comparison between the two methods. A major benefit to the image-based title font are that it's more accurate to the games, but the cons are that it's screen-reader incompatible, blurry at higher resolutions, takes longer to load, and inflexible (new characters require new images). By contrast, the text-based title font is less accurate and a bit choppy at extremely high resolutions, but it being an actual font is a major boon; it can scale to any size, it's faster to load, compatible with screen readers, and can be formatted in any way as long as it's CSS compatible. Because of this, I believe it's the best approach to implement and switch to it. StrawberryChan (talk) 02:38, 6 January 2021 (UTC)

Support
  1. Of course. I think accessibility as well as infinite scalability (which the PNGs didn't have due to being bitmap) is a huge plus IMO. --pandakekok9 (poyo) 02:49, 6 January 2021 (UTC)
  2. This would make screen readers (and copy-paste, the thing that started this back in August) work, which is a big plus. Also would help simplify the template further. ---PinkYoshiFan 23:06, 9 January 2021 (UTC)
  3. While the text-based one's outline is a bit too thin, this improves accessibility and loading times. --DeepFriedCabbage 01:56, 10 January 2021 (UTC)
  4. Also agree! Never thought that added accessibility would be a key component in resorting to text instead of imagery. – Owencrazyboy17 (talk) 02:34, 10 January 2021 (UTC)
  5. It seems things will be more efficient this way, and I see no problems with making the change, so support. -- Jellytost♡ (talk) 06:03, 11 January 2021 (UTC)
  6. Looks like benefits outweigh the take backs by a lot. Supporting. Superbound (talk) 12:30, 16 January 2021 (UTC)
Oppose
Neutral
  1. I believe this was already going to happen regardless, we just had not gotten around to it yet, so I am not entirely sure a proposal is necessary. --Samwell (talk) 02:40, 6 January 2021 (UTC)
I thought the last step was to get final approval from the community before we went forward with it? Otherwise, I was just waiting for nothing. Which, I mean, I wouldn't put past myself. :p StrawberryChan (talk) 02:43, 6 January 2021 (UTC)

Discussion

Just one question, if the proposal passed, is Delfino font going to be implemented by changing {{Title font}} directly or totally new template will be created, while the image-based one will remain for archival/other purposes? Superbound (talk) 20:00, 9 January 2021 (UTC)

{{Title font}} will be changed and the image-based one will be moved to {{Title font (old)}} or something like that. StrawberryChan (talk) 13:39, 10 January 2021 (UTC)
Perhaps {{t|Title font image}} or {{t|Pop Happiness font}} would be a better name? Superbound (talk) 12:30, 16 January 2021 (UTC)

For a preview of what it will look like on a featured article, see this page (permalink). There's this annoying empty space though, and I'm not sure what's causing it. pandakekok9 (poyo) 10:57, 11 January 2021 (UTC)

I looked at it some and it looks like the empty space is caused by the line breaks between the featured template, title font template, and infobox template. ---PinkYoshiFan 15:31, 11 January 2021 (UTC)

Adjust naming policy to prioritize romanized Japanese names over internal data names (December 19th, 2020 - January 2nd, 2021)

Currently, in the Naming policy, it is stated that internal file names have priority over any non-English official title. The reasoning for this was that these internal names, however temporary they may have been to the developers, were often easier to understand. However, this priority comes with a few notable caveats, which can be summarized as follows:

  • It is hard to argue that internal names are really official, since they were not intended to be seen in-game or shown in promotional material.
  • Internal file names are typically difficult to source, and many of the ones we use here are not sourced properly for that reason.
  • For games like Kirby Mass Attack, Japanese names tend to be the only ones available, and tend to appear more frequently in-game, making them more legitimate than internal data titles.
  • Recently, it has become a trend for external sources like the Kirby JP Twitter to provide additional information about otherwise anonymous enemies and other entities that appear in recent Kirby titles. The policy I think should be changed to better recognize this feed as a legitimate source of information on the series, whether it be in English or not.

So, what this proposal seeks to do in short is to change the order of the Priority in Naming as follows:

  1. In-game names. Newer names have higher priority in most cases.
  2. Nintendo-published promotional material, including instruction manuals, website blurbs, and Nintendo-published strategy guides. If there are multiple names used among these sources, those that are most distinctive and commonly used take priority.
  3. Any officially licensed non-Nintendo-published strategy guide. If there are multiple names used among these sources, those that are most distinctive and commonly used take priority.
  4. Any non-English official name, following the three above priorities as with English names. Romanized Japanese names take priority here.
  5. Internal file names. Use only as a last priority, as these names tend to be either short-hands or early development names. However, these may be used as additional sources to back up names from point 3.
  6. Conjectural names. Use only if there is no official name of any kind to be found.

What say you all? --Samwell (talk) 16:47, 19 December 2020 (UTC)

Support
  1. Yes, in game names were not intended for use. Romanized Japanese names are not English, but still more official than dev names. --kirb 17:04, 19 December 2020 (UTC)
  2. I agree as well. These names were not intended for the public to see, only for those developing the game and those sneaky little people who look in the game files after release. Non-English names that are mentioned in-game or in strategy guides (or even Twitter) should be prioritized instead of internal names, not the other way around. – Owencrazyboy17 (talk) 17:16, 19 December 2020 (UTC)
  3. I was looking at the naming policy today and thought the same. Japanese names are usually (at least I think) more well-though, since as mentioned earlier are supposed to be seen as public, unlike data names (example: Haltworker). Kirby JP Twitter should also be acknowledged as a better source. Support. Superbound (talk) 17:22, 19 December 2020 (UTC)
  4. Agreed. Non-publicly released titles used in early development definitely should not have priority over any official non-English title. It makes sense to use non-English titles before internal file titles. -- Jellytost♡ (talk) 18:43, 19 December 2020 (UTC)
  5. Even if an official name is foreign, it's still official, and that's better than a placeholder we aren't supposed to see. ---PinkYoshiFan 19:31, 19 December 2020 (UTC)
  6. Let's be honest, most of the internal file names we use are just nicknames used in development, and oftentimes in Japanese to start with anyway. I think this makes sense--and if we want English names, digging through official strategy guides is still an option. --YFJ (talk · edits) 19:11, 21 December 2020 (UTC)
  7. Agreed here; Japanese names are still official and should be prioritized, even if they need to be translated. That being said, filenames should also be taken into account when it comes to how the Japanese names are romanized; for example, Grandy comes from the English filename, but matches the writing of the Japanese name. StrawberryChan (talk) 03:17, 22 December 2020 (UTC)
  8. I'm agreeing as well.This solution seems more logical. Official none English names are way more reliable than internal file names, as those could be missunderstood more easily. Infinite Possibilities (talk) 20:35, 25 December 2020 (UTC)
  9. Internal data names are starting to become really informal for me now that I think about it. I prefer Japanese or English names of various entities as they come from an official source, and internal data names may be a bit misleading, like with the case of Iron Ball, which could be easily confused by me for a wrecking ball. -- EleCyon (talk) 01:34, 26 December 2020 (UTC))
Oppose
Neutral

Discussion

Retrieved from "https://wikirby.com/w/index.php?title=WiKirby:Proposals/Archive-2021&oldid=465107"