From Nookipedia, the Animal Crossing wiki
This project page is fully-protected to prevent editing by non-administrator users
Wendell NH Character Icon.png
This page is an archive.
Only Administrators may edit the contents of this page. Please direct any additional comments to the current talk page.
Wendell NH Character Icon.png
This page is an archive.
Only Administrators may edit the contents of this page. Please direct any additional comments to the current talk page.

The following is an archive of past proposals, ordered from newest to oldest.


[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) Drago PC Villager Icon.png 14:02, August 15, 2023 (EDT)

  • Something that is troubling with this proposal is that with WebP images we don't know if the image was originally a PNG or JPG file, so we'd need to decide very carefully what format to choose when converting these images. Now this can be simple for sites like Fandom, whose CDN will display a WebP for anonymous users but the real image for users, but press release images by Nintendo or any other official sources are more hasty. In my opinion, any image with transparency should be a PNG, while others should be JPG. -- PanchamBro (talkcontributions) 01:12, August 16, 2023 (EDT)
  • Personally, I would support this proposal if WebP is the only one that gets disabled, but I think WebM, as a video container format (which is not meant to replace PNG and JPG files), might be more useful just in case. Starry Windy 10:52, August 17, 2023 (EDT)
    • WEBM has more suitable replacements such as MP4, OGV, MKV, or even APNG. I wouldn't allow them for the same reasons, just with different, more supported formats to go to. Trig - 15:44, March 29, 2024 (EDT)
  • Support Support -- PanchamBro (talkcontributions) 01:12, August 16, 2023 (EDT)
  • Support Support-- I think this maybe a good idea as then people don't have to add a higher qualiy one after SunsetBay 10:26, August 17, 2023 (EDT)
  • Oppose Oppose-- Per my comments above. Starry Windy 10:52, August 17, 2023 (EDT)
  • Support Support—Usually just an indicator of content taken elsewhere. Poorly supported format. Trig Jegman - 15:44, March 29, 2024 (EDT)
  • Support Support ~ AlexBot2004 (Talk) 15:52, March 29, 2024 (EDT)
Result: (80%) Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 10:05, April 11, 2024 (EDT).

Voting on this proposal has ended. (refresh)


[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 (talkcontribs)
  • I don't want to be biased, because I helped my sister write this one, but I think it is pretty good! I understand both sides-- but I'm conflicted. On one hand- I get why staff can't be on at all times. But on the other- I think that situations would be attended to faster. So, yeah, I'll think about it. Thanks, --SunsetBay (Talk) Margie NL Villager Icon.png 09:56, September 5, 2023 (EDT)
  • I agree that it's ideal to have staff around and to cover all time zones, but an idea like this would just not work. Real-life always comes first, and editing Nookipedia is more of a fun hobby, even for staff. Several of the staff do check in daily, and if something urgent comes up, you can ping them on Discord, so you don't need to worry too much. Drago (talk) Drago PC Villager Icon.png 10:39, September 5, 2023 (EDT)
  • Little reply, Drago, but what if no-one online has Discord? Unusual, but possible? Not that I don't partly oppose too, per my above comment, but just questions that pop into one's mind. Thanks, --SunsetBay (Talk) Margie NL Villager Icon.png 14:20, September 5, 2023 (EDT)
  • Nearly all the staff (including patrollers) are on Discord. I think it's very unlikely that a major incident would remain unnoticed for long. Drago (talk) Drago PC Villager Icon.png 10:37, September 6, 2023 (EDT)
  • Oppose Oppose Drago (talk) Drago PC Villager Icon.png 10:39, September 5, 2023 (EDT)
  • Oppose Oppose Sorry, sis, but there are more cons than pros here. Thanks, --SunsetBay (Talk) Margie NL Villager Icon.png 14:25, September 5, 2023 (EDT)
  • Oppose Oppose Not only is this something that isn't deserving to be under the proposal system, but the fact that your sister is replying with an opposition under your account is making this process as confusing as possible. My bad, I'm the one who got confused. Regardless though, this isn't a thing that should be proposed under this system. -- PanchamBro (talkcontributions) 16:27, September 5, 2023 (EDT)
  • Oppose Oppose Unfortunately, there is no way we could realistically ensure that a member of staff is online at all times. Even if there were, there are no significant benefits to this, as staff and other community members have swiftly and effectively responded to prior incidents of mass vandalism, harassment etc., without the mandation of frequent online activity. The sentiment is noble, but the reality is that such a policy could not be effectively maintained, and its potential benefits are not sufficient enough to compensate for this. ZCJigglypuff(Talk) 00:30, September 6, 2023 (EDT)
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 (talkcontribs)

About the proposal's suggestion involving picture quotes:
I don't think including picture quotes at the top of each villager page will be useful, because picture quotes are already located in the villager infobox, which is on the top-right corner of the page in the "Favorite saying" section.

About the proposal's suggestion involving villager-exclusive dialogue:
There are actually already 14 pages that include villager-exclusive dialogue as a quote at the top of the page. These are the crossover villagers in Welcome amiibo, such as Chelsea, Epona, and Viché.
In New Horizons, along with Muffy's Valentine's Day-birthday-exclusive dialogue, there are a few other pieces of dialogue that are completely unique to specific villagers on New Year's Day. These villagers are of the species mouse, bull, cow, tiger, rabbit, horse, sheep, monkey, bird, dog, and pig, as these are the species that are represented by one of the 12 Chinese zodiacs. No villager species were selected to represent "snake" or "dragon," so strangely, Drago seems to be omitted. Additionally, the villager must be the only species of that personality type present in New Horizons. For example, Wendy is a sheep villager, and she is the only peppy sheep villager present in New Horizons, so she has unique dialogue related to Year of the Sheep on New Year's Day. This combination amounts to 30 unique New Year's Day villagers. These quotes should definitely be included as prose or trivia on each of these 30 exclusive villagers. I wouldn't be against including these holiday-related quotes at the top of the page, but my fear is the quote feels more holiday-centric rather than villager-identity-centric, if that makes sense, which makes me wonder if it would be a good way to represent the villager's identity. HylianAngel (talk) 21:36, March 11, 2023 (EST)

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)


Oppose Oppose HylianAngel (talk) 21:36, March 11, 2023 (EST)
Oppose Oppose ~SuperHamster Talk Contribs 14:24, March 12, 2023 (EDT)

Result: (0%) Opposed.

Voting on this proposal has ended. (refresh)


[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 (talkcontributions) 17:00, December 1, 2022 (EST)

  • I think the notices are helpful for players (they are at least helpful to me). I encourage combining everything into a single, smaller banner to limit intrusiveness. Mobile users can dismiss site notices on mobile...we're not using MobileFrontend anymore. The current limitation is that anon users cannot dismiss notices, but we can remedy that by setting $wgDismissableSiteNoticeForAnons to true. I would only support axing it all if we have evidence that our readers find it annoying (e.g. a poll on the Discord server), after we've implemented changes (making notices smaller + letting anons dismiss them). If, say, readers find it useful but editors find it annoying, we could implement a gadget that lets editors toggle event banners. I could maybe support removing the event notices on the premise that it has been several years since NH came out, but I would not want to ax the whole system, and I would want the notices to resume whenever the next game came out. ~SuperHamster Talk Contribs 17:26, December 1, 2022 (EST)
  • I agree with SuperHamster, and I think we should implement some of his solutions first (allowing anons to dismiss notices, making the banner smaller, adding a gadget to let editors hide the banners), and see how that goes before giving up on event notices altogether. If problems persist, we can reconsider. Drago (talk) Drago PC Villager Icon.png 12:53, December 2, 2022 (EST)
  • Could we not just get rid of notices for the less important events (e.g. "first day of DIY recipes", or whatever), but keep it for major ones (e.g. Toy Day)? I feel like the Main Page covers all those minor ones pretty well now. The banner was never terribly intrusive when it simply informed of a major holiday. I'm inclined to agree that its usage has become excessive in its current form. --Shark HHD Icon.png Dorsal Axe (talk) 13:06, December 3, 2022 (EST)
  • I think that's a good compromise. I'm not sure if I can change the proposal a bit to reword it, but if we can trim out the Schedule namespace to only feature major events, I think that would be better. -- PanchamBro (talkcontributions) 14:49, December 3, 2022 (EST)

Oppose Oppose ~SuperHamster Talk Contribs 17:26, December 1, 2022 (EST)
Oppose Oppose Drago (talk) Drago PC Villager Icon.png 12:53, December 2, 2022 (EST)
Support Support for reduced scope version of this proposal, as per my comment (may be best to raise as a new proposal?). --Shark HHD Icon.png Dorsal Axe (talk) 13:29, December 8, 2022 (EST)

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:
History of our item capitalization policy

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.

Why we should change 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:

  1. Today we have spreadsheets for every game in the series that use datamined names, so those would be our sources if this policy were to be enacted.
  2. The most common way items are mentioned in articles is through tables or other similar templates which isolate the name from any other text, making it clear to the reader that these aren't generic terms. Also, items should always be linked to their respective item pages, which would make it clear even in the prose that a term is not generic.

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.

Other item-related terms

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.

How we would implement this policy

This is the format I am proposing we use going forward:

  • In the prose of an article: write item names exactly as they are in-game, except for (obviously) capitalizing the first letter if it is at the beginning of a sentence.
  • In tables and templates like {{House Info}}: capitalize the first letter; these will be essentially treated as sentences.
  • In item page infoboxes:
  • In the "name" parameter of the template, capitalize the first letter; these will be essentially treated as sentences. This will be what is displayed in the infobox and what is queried in Cargo for item tables.
  • In the "en-name" parameter of the template, write item names exactly as they are in-game. This will be stored to Cargo and can be queried if needed.

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)


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 name to en_name, and with how slow some of these pages are, I feel like the worst cargo tables will just break again. If we want to assure we actually abide by the in-game names, I think we need to look into how the item names are being used at a technical point, and see if it'll be able to run without issues. -- PanchamBro (talkcontributions) 00:42, November 19, 2022 (EST)

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)


As long as there are no significant technical issues, I wholeheartedly Support Support this proposal for all the reasons AlexBot2004 has outlined. Although it may take some getting used to, I think that the reasons we have the capitalization policy are not very good ones anymore, and that there are only benefits to this (again, as long as cargo, API and other technical things are taken care of).

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)

Support Support HylianAngel (talk) 04:00, November 19, 2022 (EST)

Support Support Drago (talk) Drago PC Villager Icon.png 11:09, 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 Support Support this proposal for the purpose of making our coverage of these games more accurate. -- PanchamBro (talkcontributions) 15:54, November 20, 2022 (EST)

Support Support CompuGenetics (talk)

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:
  • This policy will call for the switching of the poll every 1st and 15th of every month.
  • A poll committee will be established, tasked with selecting the new poll for the main page. They will start a session to discuss what poll to use a week before the poll is switched out.
  • Guidelines on what a poll should be (poll related to the Animal Crossing series; minimum of three choices, maximum of ten; question are straightforward, simple; lighthearted poll only, no controversial ones; users have the option to display their username for suggesting the poll).
  • Guidelines on how to start a poll and how to archive a poll.

That's a lot to take in, but hopefully if this system is implemented, our main page poll system would work. -- PanchamBro (talkcontributions) 21:38, September 20, 2022 (EDT)

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:

  • Doubutsu no Mori was released for the Nintendo 64 on April 14, 2001, in Japan only.
  • Doubutsu no Mori+ was released for the Nintendo GameCube on December 14, 2001, a port of Doubutsu no Mori with many more features added, again in Japan only.
  • Animal Crossing was released for the GameCube in 2002 in North America, and in 2003 and 2004 in other regions. Although it is the international version of Doubutsu no Mori+, it added new events, characters, and other features.
  • Doubutsu no Mori e+ was released for the GameCube in 2003 in Japan only, giving Japan the new features introduced in Animal Crossing and other new, exclusive features.
  • Dòngwù Sēnlín was released for the iQue Player, a console that ported N64 games– in this instance Doubutsu no Mori– to China, in 2006. Though not much is known about this version due to its obscurity and technical difficulties, we know items were changed/added as well as events and villager houses, at the very least.

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)

  • Great proposal! Both Doubutsu no Mori+ and Dòngwù Sēnlín have enough differences from Animal Crossing and Doubutsu no Mori, respectively (enough that the regional differences sections take up a large chunk of both pages), to warrant having their own pages to cover said differences (as well as separate item lists and terminology when referring to the games in articles). I also agree with having {{iQue}} as a shorthand for Dòngwù Sēnlín and creating pages for that game's exclusive items (if/when that data is datamined). ~ AlexBot2004 (Talk) 21:48, August 10, 2022 (EDT)

Support Support TimeSword3D (talk) 09:32, August 10, 2022 (EDT)
Support Support Senor Mexicano (talk) 16:16, August 10, 2022 (EDT)
Support Support Dr. Peach (talk) 18:02, August 10, 2022 (EDT)
Support Support ~ AlexBot2004 (Talk) 21:48, August 10, 2022 (EDT)
Support Support -- PanchamBro (talkcontributions) 08:45, August 11, 2022 (EDT)
Support Support Kalina (talk) Pikachu Sig Icon.png 15:40, August 11, 2022 (CET)
Support Support The Messenger(talk) 18:19, August 14, 2022 (EDT)
Support Support 🤓🌸ToadetteFan007 (Talk) 🌸🤓 12:19, August 15, 2022 (EDT)

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 (talkcontributions) 07:45, May 19, 2022 (EDT)
  • I think it would be better to create Amiibo and E-Reader Card namespaces. Because it will be easier to tell the cards apart and it will be more convenient than creating a Card namespace. Kalina (talk) Pikachu Sig Icon.png 20:12, May 21, 2022 (CET)
  • I haven’t had time to review this proposal in enough detail to render a vote yet, but if we did do a namespace for cards, it would likely need to just be one for both card types. Per MediaWiki docs, namespaces are intended to differentiate pages at a “very high level”, and also require additional backend work to maintain. The scope of a namespace is far too large to be narrowed to just a single type of card, that kind of differentiation would be better handled through the title (as is done with item pages across games) and with categories. -Jake (talk) 20:17, May 21, 2022 (EDT)
  • As a collector of both types of cards, I've been adding some information on them, so I really like this idea for individual pages. On the namespace issue, I recall someone suggested a Merchandise namespace. Examples for such page titles in my mind, similar to what I said on the last proposal:
  • The problem with this is we wouldn’t necessarily want individual pages for all types of merchandise as the name implies. While more obscure collectibles like Mori o Tsukurou! figurines and Millefeui Cards could theoretically have their own pages, unlike the interactive e-Reader cards and amiibo they don't really have anything to be documented on pages of their own. I feel like "Merchandise" and "Collectible" are thus misleadingly broad namespace titles. If we document amiibo cards, figures definitely need to be documented too though, because they have unique functionality compared to cards. So personally, I like the idea of two separate namespaces but if this is too difficult or tedious to maintain technically, there could be a single namespace, but it must have a clear and better name. Chubby Bub (talk) 02:59, May 22, 2022 (EDT)
    • Unless I'm mistaken, I don't think having a new namespace would force the general merchandise pages to be split into individual ones, would it? I feel like there wouldn't be much issue with general and individual merchandise articles co-existing under one namespace. Though if that wouldn't work, I was also thinking the new namespace could just be titled "Interactive". Senor Mexicano (talk) 13:59, May 24, 2022 (EDT)
    • I didn't mean it would force other merchandise to have individual pages, just that the name Merchandise would imply that such pages might exist when they wouldn't. In fact, I'd say Merchandise is not a good name because the majority of merchandise is fine being covered in the Main namespace. Unless there are significant downsides to having two more namespaces, I am actually strongly in favor of an e-Reader one and an amiibo one. The way the two work and the data they carry is not all that similar. Chubby Bub (talk) 18:22, May 25, 2022 (EDT)
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)


[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) Drago PC Villager Icon.png 13:24, December 9, 2021 (EST)
  • Great work putting this together, Drago! I've given it a final read and everything looks tip-top. Smily.png Sunmarshsignature.png (talk) 21:06, December 10, 2021 (EST)
  • This proposal is well written and certainly more comprehensive than our current policy. There are a few very minor changes I wish to make to the Username and Director Block sections, but those changes do not stand in the way of this proposal in its current form. -Jake (talk) 17:07, December 13, 2021 (EST)
Result: (100%) Passed. The proposal was enacted by Drago (talk) Drago PC Villager Icon.png 11:28, December 17, 2021 (EST).

Voting on this proposal has ended. (refresh)