Nookipedia:Proposals/Archive
The following is an archive of past proposals, ordered from newest to oldest.
2024
[Passed] Disable WebP and WebM uploads
| Proposal: | Disable WebP and WebM uploads |
| Recently there's been some discussion among staff about disabling WebP and WebM uploads. As this is a content-related issue, though, I thought voting on it here would be the fairest way of deciding.
Although it's relatively rare that editors upload this type of file, they're usually low-quality and there's no advantages to them over the preferred PNG or JPG formats. If this proposal passes, existing WebP and WebM files will be converted to another, compatible format. Drago (talk) | |
| Comments: |
|
| Votes: |
|
| Result: (80%) | Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 10:05, April 11, 2024 (EDT). |
Support -- 
Oppose-- Per my comments above. Voting on this proposal has ended. (refresh)
2023
[Failed] There should be one member of staff online at all times.
| Proposal: | There should be one member of staff online at all times. |
| I think that there should be one member of staff on all times. There could be a serious incident and with no staff online, no action except telling off could be made against the offending user. - unsigned comment from FroggyPotter (talk • contribs) | |
| Comments: |
|
| Votes: |
|
| Result: (0%) | Opposed. |
Voting on this proposal has ended. (refresh)
[Failed] Villager Quotes
| Proposal: | Villager Quotes |
| Nookipedia should go back to having villager quotes at the top of the villager pages. I've started editing a few pages with quotes, but I wanted to get some support before I continue. I know some quotes, like dialogue, are the same within a personality, but picture quotes aren't. It would be useful to the readers to have the quote at the top of the page, and it would be a nice surprise to the readers to see the pages change for the better. Also, we could include villager-exclusive dialogue, such as Muffy's dialogue on her birthday (She's the only villager with a birthday on Valentine's Day.) Opinions? - unsigned comment from Omigpine11 (talk • contribs) | |
| Comments: |
About the proposal's suggestion involving picture quotes: About the proposal's suggestion involving villager-exclusive dialogue: Hatnotes are typically used to help disambiguate pages (e.g. Apple), or point readers to villagers who share the same name in a different language (e.g. Penelope). As fun as quotes at the top would be, I think we should avoid adding additional hatnotes to avoid distracting from the main content, and I think we shouldn't mix fun and utility. My other concern is SEO -- the sooner the actual prose of the article starts, the easier it is for search engines to identify what the article is about. I could maybe support quotes in the infobox, where it would be off to the side. ~SuperHamster Talk Contribs 14:24, March 12, 2023 (EDT) |
| Votes: |
|
| Result: (0%) | Opposed. |
Voting on this proposal has ended. (refresh)
2022
[Failed] Axe using event notices at Mediawiki:Sitenotice; delete all pages under Schedule:Months
| Proposal: | Axe using event notices at Mediawiki:Sitenotice; delete all pages under Schedule:Months |
| This is starting to become a problem, especially for me as an editor. We generally have left our site notice around to alert users about events ongoing in the Animal Crossing games, with the latest pages centered being New Horizons. But, on the premise of how it operate, the system now just feels intrusive that it gets in the way not only for editors, but for readers, who cannot remove those site notices on mobile.
You might be inclined to propose several solutions, like combining certain events into one template so it outputs events, or make these notices invisible on mobile, but even with those solutions, we might end up having a site notice that still acts intrusive. Whenever there's a very important site notice, such as announcing that NIWA's Cross-Wiki Week has started, or if there are multiple events happening (see Schedule:Months/May/31), all of that crams the actual wiki content down significantly, something that will annoy readers even if solutions like combining these templates into one. Coupled with the fact that this system is basically useless since event info is displayed on the Main Page anyways, this system is overall functionally annoying and outdated. With this proposal, I want the site notices to display these events gone. Period. The Schedule:Months pages will be deleted following the proposal's success, and Mediawiki:Sitenotice will be reserved for Nookipedia-related events, like our birthday, or as I mentioned Cross-Wiki Week. Note that I do not want the entire Schedule namespace removed; the Schedule namespace has birthday pages used on our Main Page and Schedule:New Horizons is being used for cargo purposes. -- PanchamBro (talk • contributions) 17:00, December 1, 2022 (EST) | |
| Comments: |
|
| Votes: |
|
| Result: (33%) | Opposed. |
Voting on this proposal has ended. (refresh)
[Passed] Change item capitalization policy to match in-game capitalization
| Proposal: | Change item capitalization policy to match in-game capitalization |
I am proposing that we change our policy and item capitalization to use the in-game capitalization—which is generally all lowercase except for proper nouns—for all item names. This proposal has been divided into sections for ease of reading:
Right now, our policy for the capitalization of item names defined on our general policy page and in our Manual of Style is to use title case, regardless of the in-game capitalization, as enacted by a 2014 poll. The reasoning behind the decision to make a policy regarding item names was brought forth by the staff largely due to the wiki at the time having inconsistent standards between pages (some pages used in-game capitalization, some used title case), but it was left to a poll because there was no consensus on which system to use. Since the policy's enactment, two discussions (one in 2015 and one in 2020) were started in opposition of the policy and how it was decided. In both discussions, the consensus was that a poll was not a great way to gather the opinions of readers and editors, though neither discussion led to any changes in the policy.
I am proposing to use in-game capitalization for one main reason: it would be the most official way to present these names. We use official terms as they are in the games for all other subjects, so why should items be any different? I feel that capitalization is just as much a part of a subject's official name as anything else. The capitalization of item names is not just aesthetic; it has practical effects. There are plenty of items that do use proper nouns in-game, and with our system of making everything a proper noun, the actual proper nouns in the original names are lost. Another issue with our current policy is shown with the "Snowman vanity" (uppercase "S") in the North American version of City Folk, which was changed to "snowman vanity" (lowercase "s") in the European version. With our current system, there is no way to convey to the reader that the name was changed without either breaking our policy or having an awkward note. One point that was brought up in the 2015 discussion is that it would be hard to enact such a policy of using in-game capitalization since there was no accurate master item list for all games. Another point brought up in the 2020 discussion is that having item names in title case has stylistic value because makes it clear to the reader that these are actual in-game items and not generic terms. To respond to these two counter-arguments:
As a wiki that covers content from the Animal Crossing series objectively and strives to be as accurate as possible, I believe there isn't a place on Nookipedia for a policy that makes us write item names contrary to how they appear in the games, especially for stylistic reasons.
There are also several non-item—but still item-related—terms that are not defined in our MoS, but still follow our item name policy on the wiki; namely HHA genres/themes and variant/pattern names. Any terms like these should be changed to in-game case just like the items themselves, for the same reasons stated above. That being said, I am not proposing any changes to our furniture collection (series/set/theme) terminology in this proposal. Their full names aren't clearly defined via in-game strings like the other terms; the first part (e.g. "blue", "lovely", "modern") is defined, but the "series"/"set"/"theme" part, as far as I can tell, is just an internal property and is never appended to the name in-game. I think these warrant their own proposal to determine what we call them going forward, but at the moment, they can stay at their current names. I also want to make it clear that this policy would not affect item image filenames; the standard for all filenames is title case and I see no need to change that.
This is the format I am proposing we use going forward:
With thousands of item pages and even more mentions of items across the wiki, it will take a while for everything to be fully updated, but it will certainly be possible. Item pages would be automatically moved and their prose would be updated via text replacements, as would standardized templates such as the villager housing templates. Updating the item pages would in turn automatically update every Cargo item table; for non-Cargo tables, those will be replaced in due course with Cargo tables as item pages for all the games are created. The only thing that I don't think can be updated automatically would be mentions of items in the prose of mainspace articles; however, these take up such a small amount of the mentions of items across the wiki relative to the others I've listed that it could be done manually. This was a long proposal, but for a change as large as this I feel I needed to go into as much detail as possible. Thank you for your time and consideration. ~ AlexBot2004 (Talk) 00:00, November 19, 2022 (EST) | |
| Comments: |
I'm kinda conflicted with this notion. On one hand, I think this is accurate, and I'm certain of using the in-game names as best as possible, I understand why this is necessary for us, and if anything it'll probably be better off to use the actual in-game names. On the other hand, I'm not very confident that things will remain functional as it is. I'd have to go through some of the worst cargo tables and change Everything makes sense to me, 100%. Another thing to note that sucks about the current capitalize-everything item policy is that certain items are difficult to discern if they really needed to be capitalized. (For example, we don't capitalize umbrella/gyroid/fossil as a category of item, but some items like "shovel" and "turnip" are both a category of item and an actual item, so they have inconsistent casing throughout the entire wiki, especially on the handheld items page.) And also, it's very difficult when it comes to real-life bugs, fish, and sea creatures, because they are items, so per item policy, they should be capitalized, but there are instances where pages switch between the animal as a concept and the animal as an item, so you have pages like Pascal that go back and forth between capitalizing "scallop." Plus a lot of pages aren't even following the capitalization rule in the first place and have lowercase bugs/fish/sea creatures. I agree with everything stated in Alex's proposal, including the part involving capitalizing the first letter of items in lists/tables/templates/infoboxes, but I just wanted to mention one other thing that needs to be fixed that sort of breaks this mold. A couple of years ago, I capitalized all of the clothing in the {{E-card}} templates, because if I remember correctly, some of it was inconsistent (might be wrong there), and also because item policy states items should be capitalized. But in reality, the transcriptions of these clothings should match what is written on the cards (star signs are capitalized and should remain capitalized, catchphrases are lowercase and should remain lowercase, so the clothing which is lowercase should also be lowercase). This is like a sort of special exception to the lists/tables/templates/infoboxes rule. HylianAngel (talk) 21:18, November 19, 2022 (EST) |
| Votes: |
As long as there are no significant technical issues, I wholeheartedly I also think it's worth noting that New Horizons uses sentence case in all cases (e.g. in the catalogue or inventory); while earlier games don't, it obviously makes sense to keep this consistent, and I think using sentence case outside of prose (i.e. in lists, tables, etc.) makes more sense as a universal guideline. Chubby Bub (talk) 03:08, November 19, 2022 (EST)
I've taken my time to go ahead and implement several key modules that will be helpful for us for when we move every name to their proper in-game counterpart. The first module I developed was Module:CapitalizationCheck, which should be implemented in the {{I}} template and be used to check if the item name is improperly capitalized. I know it might sound redundant, many tables won't be affected by this change, but this is going off the template's usage in other instances, such as within proses and stuff. Coupled with the fact that I assured that the item name is marked to give attention, and this should help us find all item names without having to resort to a lot of bots to manually figure out what item names need to be changed (and I definitely do not want to continue to use the pywikibot feature and continue to run into more CSRF errors. The second is currently available at Module:Sandbox (though by the time some historical reader might be seeing this, it should be moved to its own module). This will automatically proper case names. Now why do we need this? Since we're also going to change the capitalization of in-game names, it's important that this module is properly implemented to display images. Otherwise, we'd run into issues. I'm sure we could just also remove the need for having a separate parameter for images too, but I'll have to check if the change will impact item pages in the long run. There's still the fear of cargo tables breaking, but if I don't have to change many parameters around, I think it should be good. With that being said, I
|
| Result: (100%) | Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 00:00, November 26, 2022 (EST). |
Voting on this proposal has ended. (refresh)
[Passed] Implement new Nookipedia:Polls policy
| Proposal: | Implement new Nookipedia:Polls policy |
A couple of months ago, I suggested reviving the idea of polls on the wiki, and a majority were in support of the idea. As such, I've devised a new policy in regards how the main page polls will work from now on here. To summarize:
That's a lot to take in, but hopefully if this system is implemented, our main page poll system would work. -- PanchamBro (talk • contributions) 21:38, September 20, 2022 (EDT) | |
| Comments: | |
| Votes: |
|
| Result: (100%) | Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 18:08, September 28, 2022 (EDT). |
Voting on this proposal has ended. (refresh)
[Passed] (Re)separate Doubutsu no Mori+ and Dòngwù Sēnlín
| Proposal: | (Re)separate Doubutsu no Mori+ and Dòngwù Sēnlín |
| Yeah, it's this discussion again. This (well, the first part) was discussed on Talk:Doubutsu no Mori+ since 2018, and the page was merged with Animal Crossing in 2020. However, the wiki has evolved since then, recent as it may seem, and I strongly believe it would be beneficial to have these pages separate again.
Though I suspect everyone who will participate in this proposal knows this, a brief overview:
So first: currently Doubutsu no Mori+ and Animal Crossing are at the same page, the former a redirect to the latter. (This makes sense as this is an English wiki, I can only assume if this were a Japanese wiki we'd do the opposite.) It is correct that Doubutsu no Mori+ and Animal Crossing are two regional versions of the same game. Nintendo has made it clear when they overview the series in Japan that the first three games are Doubutsu no Mori, Doubutsu no Mori+ and Doubutsu no Mori e+. Also, DnM+'s game ID is GAFJ and AC's is GAFE in America. The first letter indicates the system (G - GameCube), the second and third the game (AF/AE - Animal Forest/Animal Forest e+, I assume), the last the region (J- Japan, E - North America). (For reference, DnM's ID is NAFJ (N - N64) and AC in Europe/Australia is GAFP (P - PAL); the iQue Player uses a different system.) So, to be very clear, I am not contending that Doubutsu no Mori+ and Animal Crossing are two different versions of the same game; rather, I accept this and still believe they should have separate pages. Here's why: Nookipedia is an encyclopedia about a video game series. We cover the contents of the games and gameplay. As such, gameplay differences are an important aspect to cover. More recently, through datamining and the creation of the AC Spreadsheets and Item pages, many more differences beyond "they added a couple characters and events" have come to light. This includes, but is not limited to: the way items are obtained, many items being removed and added, most events being changed, the way passwords work, the way e-Reader cards work, songs being added or replaced, character/item appearance changes, and villager house interiors. These may be two different versions of the same game, but major aspects of the gameplay differ significantly. The premise for merging the pages was that they have "relatively few differences" or "minor differences", which is simply untrue. Furthermore, people looking for information on Doubutsu no Mori+ are generally not looking for info on Animal Crossing, and vice versa. The only reason for Template:DnM+ to be used is in comparison to other games with gameplay differences– yet the link redirects you to one of those pages. If a casual reader reads "in Doubutsu no Mori+ x, but in Animal Crossing y" yet both link to Animal Crossing, this serves as a point of confusion. Then, it isn't immediately apparent by looking at that page that the two are regional versions of the same game. Also, I've on occasion seen Doubutsu no Mori+ replaced with something like "the Japanese version of Animal Crossing" or "Animal Crossing (Japan)", which again, while technically true, paints a picture that is not exactly true. Regardless of the outcome of this proposal, I would discourage this type of language. So all of that is why I think the games should be not be not be on the same page. But neither should they be considered separate games, just acknowledged as separate versions. Since this is an English wiki, most users will likely be looking for information on Animal Crossing, and that should still be our primary page for the two, especially where things are the same in-game. But Doubutsu no Mori+ should be its own page detailing its release and gameplay, what it added, etc. As for the Version differences sections on game pages, they should detail the differences added compared to the prior version. This reasoning is also why the PAL version of Animal Crossing does not need to be split; there are no significant gameplay differences, just minor model changes and at most moving the date of a couple holidays. (Well, that we know of...) All of the above is also why I think Dòngwù Sēnlín should also have a separate page. While we know a lot less about it, we do know that it is significantly different from Doubutsu no Mori, and that includes item differences. I also think it should get its own linking template (even if we don't split the pages)– Dòngwù Sēnlín is a pain to type out, and again, I think things like "the iQue Player version of Doubutsu no Mori" should be avoided. The short version should probably be "iQue", since "DS" could cause confusion with the handheld console, and also just seems kind of silly to me. The last part of this proposal is clarifying that this shouldn't only split the game pages, but related pages such as Furniture/Animal Crossing, where there are differences. The way those pages are currently handled is another point of confusion. Dòngwù Sēnlín items should also get their own pages in the Item namespace. I know this was a long post, but well, proposals tend to be, and there was a lot to cover, so thanks for reading it. (Well, I hope you did.) Chubby Bub (talk) 04:51, August 10, 2022 (EDT) | |
| Comments: |
|
| Votes: |
|
| Result: (100%) | Passed. The proposal was enacted by ~SuperHamster Talk Contribs 01:13, August 18, 2022 (EDT). |
Voting on this proposal has ended. (refresh)
[Failed] Namespace for e-Reader and amiibo cards
| Proposal: | Namespace for e-Reader and amiibo cards |
| Nearly a year ago, AlexBot proposed the creation of e-Reader card pages, and many ideas came forward, including the creation of a Card namespace particularly to also add amiibo cards. However, 4 months later, I later proposed that both e-Reader and amiibo pages get separate namespaces for e-Reader cards and amiibo, as the Card namespace would leave out amiibo figurines. Therefore, this proposal will come down to two options: Either we create the Card namespace, or we create the E-Reader Card and Amiibo namespaces. -- PanchamBro (talk • contributions) 07:45, May 19, 2022 (EDT) | |
| Comments: |
|
| Votes: | |
| Result: (??%) | The proposal received 3 out of 3 support votes, as users generally agree that some namespace(s) should be created to document e-Reader cards, amiibo cards, and amiibo figurines. However, there are multiple suggestions about which namespaces, and multiple suggestions involving their names.
Jake has advised against separating them as "Amiibo" and E-Reader Card" due to MediaWiki standards. But the majority community consensus seems to be using these 2 namespaces, in order to avoid excluding amiibo figurines. While I personally that using these 2 namespaces makes sense, given that amiibo cards shares much more functionality with amiibo figures compared to e-Reader cards, Jake's opinion is more important in this matter, as he is the one who is well-versed with MediaWiki docs. 1 namespace involving all 3 types of merchandise has been suggested; this would be the best solution, so that amiibo cards, amiibo figurines, and e-Reader cards can all be documented. In the Nookipedia Discord, Jake has also agreed that this would be an ideal solution. Unfortunately, there are no official names that are inclusive for all 3 types, and users are divided on which one to choose. (Merchandise? Very broad and may be misleading as other types of merchandise may not be documented. Interactive? Scannable? Collectible?) While the initial proposal was very clear with a binary choice, the community is still divisive on certain specifics. Jake has (semi-vetoed) the option that has had the most votes (Amiibo and E-Reader namespaces). So although the proposal "passed" with a 100% vote, the choice with the most votes does not pass. This is a unique situation, as the complexity of this topic has resulted in a slight contradiction of the rule that states the components of the proposal should not be vague. I apologize for denying a proposal that has technically passed, but this may require more discussion in Nookipedia talk:The Roost before it should be proposed again. Due to the (semi-)veto of the most popular choice, consensus seems to be leaning towards choosing 1 namespace that includes all 3 types of merchandise. My suggestion for the next discussion point is a poll involving multiple options on the potential name for the single namespace (Merchandise, Interactive, Scannable, Collectible, Other (specify)) Denying the proposal until a new namespace name is submitted. HylianAngel (talk) 05:53, July 4, 2022 (EDT). |
Voting on this proposal has ended. (refresh)
2021
[Passed] New block policy
| Proposal: | New block policy |
It's time for our first Nookipedia Proposal! To kick things off, I'm going to re-propose a new block policy I wrote a few months ago. Only two votes were cast before the discussion became inactive, so I thought it would make sense to revive it as our first official Proposal (the original discussion is here.) I've made a couple of changes since then (relating to partial blocks and talk page editing), so I'm pretty sure that the policy is complete now. As before, please review it and let me know what you think. Thank you! Drago (talk)  13:24, December 9, 2021 (EST)
| |
| Comments: |
|
| Votes: |
|
| Result: (100%) | Passed. The proposal was enacted by Drago (talk) 11:28, December 17, 2021 (EST).
|
Voting on this proposal has ended. (refresh)
