Difference between revisions of "Nookipedia:Proposals"

From Nookipedia, the Animal Crossing wiki
(→‎Current proposals: reply to Dorsal Axe)
(11 intermediate revisions by 7 users not shown)
Line 28: Line 28:
 
==Current proposals==
 
==Current proposals==
 
{{proposal
 
{{proposal
| title = Change item capitalization policy to match in-game capitalization
+
| title       = Axe using event notices at [[Mediawiki:Sitenotice]]; delete all pages under [[Schedule:Months]]
| description = 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:
+
| description = 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.
  
;History of our item capitalization policy
+
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 [[Nookipedia:Cross-Wiki Week|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.
Right now, our [[Nookipedia:Manual of Style#Capitalization|policy for the capitalization of item names]] defined on our general [[Nookipedia:Policy|policy page]] and in our [[Nookipedia:Manual of Style|Manual of Style]] is to use title case, regardless of the in-game capitalization, as enacted by a [[Nookipedia:Polls#Ninth poll (August 13, 2014 - August 18, 2014)|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 ([[Nookipedia_talk:Policy#Not_exactly_agreeing_with_capitalization_policy|one in 2015]] and [[Nookipedia_talk:The_Roost/2020#Regarding_the_capitalization_of_item_names|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
+
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. -- [[User:PanchamBro|PanchamBro]] ([[User talk:PanchamBro|talk]] • [[Special:Contributions/PanchamBro|contributions]]) 17:00, December 1, 2022 (EST)
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.
+
| comments    = * 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 <code>$wgDismissableSiteNoticeForAnons</code> 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. '''~[[User:SuperHamster|''<span style="color:#07517C;">Super</span>''<span style="color:#6FA23B;">Hamster</span>]]''' <small>[[User talk:SuperHamster|Talk]] [[Special:Contribs/SuperHamster|Contribs]]</small> 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. [[User:Drago|<span style="font-family:Coustard;color:green">Drago</span>]] [[User talk:Drago|<span style="font-family:Coustard;color:purple">(talk)</span>]]   [[File:Drago PC Villager Icon.png|20px]] 12:53, December 2, 2022 (EST)
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 {{CF|short|nolink}}, 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.
+
* 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. --[[File:Shark HHD Icon.png|20px]] [[User:Dorsal Axe|<span style="color:#0B3E57; font-family: Coustard">Dorsal Axe</span>]] <span style="font-family: Coustard"><small>([[User talk:Dorsal Axe|talk]])</small></span> 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. -- [[User:PanchamBro|PanchamBro]] ([[User talk:PanchamBro|talk]] • [[Special:Contributions/PanchamBro|contributions]]) 14:49, December 3, 2022 (EST)
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:
+
| votes      = {{Oppose}} '''~[[User:SuperHamster|''<span style="color:#07517C;">Super</span>''<span style="color:#6FA23B;">Hamster</span>]]''' <small>[[User talk:SuperHamster|Talk]] [[Special:Contribs/SuperHamster|Contribs]]</small> 17:26, December 1, 2022 (EST)<br>{{Oppose}} [[User:Drago|<span style="font-family:Coustard;color:green">Drago</span>]] [[User talk:Drago|<span style="font-family:Coustard;color:purple">(talk)</span>]]    [[File:Drago PC Villager Icon.png|20px]] 12:53, December 2, 2022 (EST)
#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.
+
| year       = 2022
#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.
+
| month       = 12
 
+
| day         = 08
As a wiki that covers content from the {{SER|nolink}} 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.
+
| hour       = 17
 
+
| minute     = 00
;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 {{t|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. '''~'''&nbsp;[[User:AlexBot2004|<span style="font-family:Coustard;color:#1C662A">'''AlexBot2004'''</span>]]&nbsp;([[User talk:AlexBot2004|<span style="font-family:Coustard;color:black">Talk</span>]]) 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 <code>name</code> to  <code>en_name</code>, 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. -- [[User:PanchamBro|PanchamBro]] ([[User talk:PanchamBro|talk]] [[Special:Contributions/PanchamBro|contributions]]) 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 item]]s 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/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 {{T|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 tables/lists/infoboxes rule. [[User:HylianAngel|HylianAngel]] ([[User talk:HylianAngel|talk]]) 21:18, November 19, 2022 (EST)
 
| votes =
 
 
 
As long as there are no significant technical issues, I wholeheartedly {{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 {{NH|short}} 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. [[User:Chubby Bub|Chubby Bub]] ([[User talk:Chubby Bub|talk]]) 03:08, November 19, 2022 (EST)
 
 
 
{{Support}} [[User:HylianAngel|HylianAngel]] ([[User talk:HylianAngel|talk]]) 04:00, November 19, 2022 (EST)
 
 
 
{{Support}} [[User:Drago|<span style="font-family:Coustard;color:green">Drago</span>]] [[User talk:Drago|<span style="font-family:Coustard;color:purple">(talk)</span>]]    [[File:Drago PC Villager Icon.png|20px]] 11:09, November 19, 2022 (EST)
 
 
 
| year = 2022
 
| month = 11
 
| day = 26
 
| hour = 00
 
| minute = 00
 
 
| percent = <!--Staff use only.-->
 
| percent = <!--Staff use only.-->
 
| result = <!--Staff use only.-->
 
| result = <!--Staff use only.-->

Revision as of 15:49, December 3, 2022

Nookipedia Proposals allow the community to vote on sitewide changes that would affect a large number of pages or users. This process is not a replacement for community-wide input (see:The Roost) or talk page discussion. Rather, it takes the final product of those discussions (in the form of a proposal) and puts them to a vote.

Rules

  • Proposals are only necessary for changes that would affect a large number of pages or users. Some examples: rules/policy changes, adding/removing namespaces, making major modifications to/replacing templates that affect 1000+ pages.
  • Proposals are for voting on fully worked out ideas. They should not have any yet-to-be-determined components: no 'option a, b, or c'. Proposals may be submitted without prior public comment or feedback, but should not receive major edits or changes once voting has started.
  • Proposals can only be submitted and voted upon by registered users. Comments or votes from unregistered users will be removed immediately. Furthermore, all votes or comments must have a signature attached (~~~~). Users are not allowed to vote on their own proposal, but may respond to comments.
  • Proposals will be open for seven days. This voting deadline can be extended upon request, at the discretion of a Bureaucrat.
  • At the end of the voting period, if the proposal has at least a 2/3 majority (66%) it will be considered successful. A Bureaucrat will then officially close the proposal, and either enact it themselves, or coordinate with other staff members to make sure the proposal is completed.
  • Once a proposal has been enacted, the staff member responsible will make a note here and move the proposal to the Archives.

How to make a proposal

All proposals must be made using the template provided below, posted under the "Current Proposals" heading:

{{proposal
| title       = A short, one-sentence description of the proposal.
| description = Additional proposal details/explanation.
| comments    = User commentary on proposal.
| votes       = User votes on proposal: {{Support}} or {{Oppose}} + signature (~~~~).
}}

Current proposals

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)

Comments:
  • 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)
Votes:

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)

Result: (??%) To be determined.

Voting on this proposal has ended. (refresh)