MarioWiki:Proposals/Archive/55

All past proposals are archived here. This page is protected to preserve the discussions as they were.

OK Boomer (Move Boomer (Super Paper Mario) to Boomer (Pixl)?)

withdrawn by the proprietor (see comment)
Interestingly, there are two different identifiers for these two Super Paper Mario pixls: Boomer (Super Paper Mario) and Slim (Pixl). Since there is an inconsistency, it would make sense for both pixls to share the same identifier. Since Slim (Flopside) prevents the use of using (Super Paper Mario), it would make sense to move Boomer (Super Paper Mario) to Boomer (Pixl). This further makes more sense as naming policy suggests using a "Thing" identifier (pixl) over a game identifier. Such a page move would be fairly innocuous.

However, this would create a minor secondary discrepancy with the other two Boomer pages, both of which are using game identifiers. Should both of these pages be moved to be more specific to their pages, such as Boomer (boss) and Boomer (bear), as well as Boomer (Pixl)?

Proposer: Trig Jegman (talk)
Deadline: Jan 6, 2020; 23:59 (UTC)
Date withdrawn: December 31, 2019, 01:56 UTC

Move Boomer (Super Paper Mario) to Boomer (Pixl) only

1. Trig Jegman (talk) - Well I made it, but I don't necessarily think it would be a big deal if the other two variants remained the same. - 23:01, December 29, 2019 (EST)

Move all three Boomer pages to be more specific

While I suggest Boomer (boss) and Boomer (bear), these could be discussed further

Do nothing

1. Toadette the Achiever (talk) See here, here, and here for a full explanation.

Comments

This further makes more sense as naming policy suggests using a "Thing" identifier (pixl) over a game identifier.

The "thing" in this case is character. If character can't be used, then you move to #2, which is game. Slim is forced to go to #4 since game can't be used, while Boomer can safely stay at #2 and use game. That the two Pixls end up in different places is simply a result of them needing to differentiate from different things (Slim (Flopside) forces it). I understand it can be considered annoying, but whether or not they match is really neither here nor there - they are each a different case with different needs. As you said, if you do the move then these three links are inconsistent since one wouldn't use game (and there is no reason for it not to use game since they are all from different games). So basically you want to open up the character identifier to get more specific before moving to game (naming&diff=2493125&oldid=2445836 as it used to be). This gets into its own weird problems of what should be used, and having some awkward identifiers. I think going to the game name sooner avoids that awkwardness in the most objective way possible. If you tally up the amount of "problems" with each system, I'll take the current Pixl "mismatch" and a bunch of objective game identifiers versus a ton of human/flower/whatever identifiers. The Slim (Pixl) case is a direct result of Nintendo using the same character name twice within one game and rightfully should be the one awkward situation because that is a confusing thing to do. Opening up custom character identifiers before moving to game creates awkward cases which are completely the wiki's doing, and we should try keep our hands clean and minimize any impact. No matter what system we land on there will be weird cases to deal with. I think the current system minimizes the damage and is the "least bad" option, and I don't want to keep changing things around. So I'll veto --Steve (talk) 20:56, December 30, 2019 (EST)

Compile Play Nintendo puzzle activities in a single page

MERGE PUZZLES 7-0
I don't think the Play Nintendo jigsaw puzzles, such as this one, this one and this one, deserve their own pages as much as the other Play Nintendo activities do. The reason skill quizzes and personality quizzes need their own pages is to neatly list all the correct answers for each, in a similar fashion to how we handle the quizzes from the Paper Mario games. However, those jigsaw puzzles all have the exact same "gameplay" where you choose a difficulty of 8, 18 or 50 pieces and then use them to build the base picture; the only difference is the picture you have to build, but this isn't a strong enough reason to keep these puzzles on separate pages. This can be easily managed in a table that contains the preview and description used on the website, what the completed puzzle looks like, and a link to the actual puzzle.

I therefore propose that we make a list of Play Nintendo puzzles where we compile every single one of them, with the following layout for the table:

Preview	Completed puzzle	Play Nintendo description	Web page name	Link
	[pic]	A (puzzle) piece of art Put together the puzzle pieces to get a closer look at the Mushroom Kingdom. You can choose between Easy (8 pieces), Medium (18 pieces), or Hard (50 pieces!). Good luck!	Nintendo Online Jigsaw Puzzle Game	[1]

A few notes:

1. The website description takes priority over the tab title of the puzzle because the words used in it also serve as search keys on Play Nintendo, whereas the tab title seems more like a simple placeholder typed out by the publisher (and cannot be used to search the puzzle). We'll offer a direct link anyways, so the reader won't have to personally go type it out in the search bar, but this decision is taken to more or less highlight the importance of the description on the website.
2. That one Mario jigsaw puzzle on the Nintendo Kids Club website (Play Nintendo's European counterpart) won't be affected by the proposal, as it is considered in relation to other games on the website (Luigi's Word Jumble, Captain Toad's Dungeon Dash! etc.)

If the proposal passes, any puzzles that already have their own pages will be merged in a List of Play Nintendo puzzles. I was planning on organizing the other activities similarly, since the current list on the Play Nintendo page doesn't have much of a rhyme or reason. If the proposal is unsuccessful, then the jigsaw puzzles will continue to have their own pages like the rest of the Play Nintendo activities.

Proposer: Bye Guy (talk)
Deadline: January 16, 2020, 05:27 UTC

Support

1. Bye Guy (talk) per proposal
2. Obsessive Mario Fan (talk) - Since all the puzzles are the same but with different pictures and text, this works best. Also, each puzzle has a unique message when completed, so that should be included too.
3. Power Flotzo (talk) Per Obsessive Mario Fan.
4. TheDarkStar (talk) - Per all.
5. Waluigi Time (talk) Per all.
6. Mister Wu (talk) Agreed - I support the idea of using less space and simplifying navigation without losing the actually relevant information
7. Jazama (talk) Per all.

Remove tense

DELETE TEMPLATE 17-0
The Template:Tense has been around for almost 10 years, and despite this, it is almost never used. Tense is so infrequently used that while discussing it with long time wiki editors, they didn't believe it was a thing. Tense serves virtually no purpose anymore, as changing word tense is generally very easy to do, especially with tools like Find/Find Next being commonplace. If a situation is truly dire, it doesn't make sense to not simply use {{Rewrite}} over Tense, since a majority of people don't either know it exists and cannot find the section in which it is documented, or people don't suspect a tense issue because they are so infrequent. Because of this, I propose that the tense template is deleted.

Proposer: Trig Jegman (talk)

Deadline: Feb 18, 2020, 23:59 (UTC)

Support (Delete the template)

1. Trig Jegman (talk) per proposal.
2. Doc von Schmeltwick (talk) Ye I had no idea it was a thing, but it's pretty much pointless. Per proposal.
3. Alex95 (talk) - Yeah, that makes sense to me.
4. TheDarkStar (talk) - It's only used on one page, and it doesn't even have a dedicated subcategory, so I'm for deleting this.
5. 7feetunder (talk) We don't need sub-templates for every specific way an article can be badly written. Just use the "reason" parameter.
6. Scrooge200 (talk) Per all.
7. Mario jc (talk) Per proposal.
8. Sdman213 (talk) Per all.
9. Obsessive Mario Fan (talk) This template is redundant. Per all.
10. Niiue (talk) Per all.
11. Toadette the Achiever (talk) Practically useless. It's an issue that's extremely easy to fix.
12. TheFlameChomp (talk) Per all.
13. Yoshi the SSM (talk) Per all.
14. Mister Wu (talk) If it’s redundant and almost unused, we can get rid of it.
15. FanOfYoshi (talk) As another proposal by Super Radio (or is it Results May Vary), this is redundant.
16. Supermariofan67 (talk) Per all.
17. White Lightning (talk) If it is hardly used, it must be removed.

Comments

Actually, it's on Mario & Sonic at the Olympic Games Tokyo 2020, too. But I still don't see a use for it. Scrooge200 (talk) 00:31, February 12, 2020 (EST)

New Template:Gamma Image

create template 6-0
An interesting oddity that I and few other users have noticed while dealing with images is a very interesting type of metadata called Gamma Brightening. In short, what gamma brightening does is change the way the colors of an image are displayed. This is generally very rare, but it is important as the differences between images is severely drastic. After some internal discussion, most notably with Steve, the unspoken policy course of action is to not optimize images with gamma brightening, and leave that metadata on the image if it is the way the source image provides the picture.

The purpose of the proposal is to make this unspoken policy a spoken policy. People should know when an image has a special property and should be treated differently.

The following template, {{Gamma-Brightening}}, would be placed on the documented images with gamma brightening:

This image contains gamma brightening, and should not be optimized.

<div class="notice-template" style="display:flex;text-align:center;background:#BF5FFF;margin:0.675em 2% 1.75em;padding:0 1em;border:2px solid black;color:black"> '''This image contains ''[[User:Trig Jegman#What's Gamma Brightening?|gamma brightening]]'', and should not be optimized.''' </div><includeonly>[[Category:Gamma Image]]</includeonly><noinclude>

Such images seen thus far is:

• Hammer Bro-NSMBU.png
• File:MP8 Hammer Bro Artwork.png
• File:NSMBDS Goomba Artwork.png
• File:BulletBillWii.png
• File:NSMBDS Buzzy Beetle Artwork.png
• File:NSMBW Mario Holding Green Shell Artwork.png
• File:NSMBW Mario Jumping Artwork.png
• File:Blueboostblock.png

It would also be suggested, but not required, to create a MarioWiki page discussing gamma brightening over using a section on my user page.

Comparison image:

Proposer: Trig Jegman (talk)

Deadline: Feb 19, 2020, 23:59 (UTC)

Support (Create template)

1. Trig Jegman (talk) Per proposal
2. Bye Guy (talk) per proposal
3. TheDarkStar (talk) - Per proposal.
4. Results May Vary (talk) - It might be odd seeing this on many image pages, but otherwise it is a reasonable decision. We want to preserve the original nature of the image as much we can. Although personally I prefer the Gamma brightness removed for the Hammer Bro pic but just in this case, and it's only my opinion.
5. mister Wu (talk) I’m still wondering if removing metadata doesn’t create more problems than it solves (it’s often a few bytes of data where the IDAT chunk is orders of magnitude bigger), but since current optimization software removes them and since the gAMA chunk definitely must not be removed, it’s better to add this template.
6. FanOfYoshi (talk) Per all.

Comments

I mentioned you could simply say this information in the aboutfile template. Because of that, I don't see a need for this template, as it would only really apply to a handfull of images. But I'll remain neutral, as I'm not directly opposed to it, either. 11:21, February 12, 2020 (EST)

Not sure what to think of this yet, but I think the purple should be a lighter color to make the text more readable. --DeepFriedCabbage 14:46, February 13, 2020 (EST)

I can easily change the color to be more reader-friendly. I will hunt for a similar purple that's easier to read. Trig - 16:42, February 13, 2020 (EST)

Thanks! --DeepFriedCabbage 20:07, February 13, 2020 (EST)

is #cb7eff or #debffb more appropriate?

demonstration; original

demonstration; option 1

demonstration; option 2

I personally enjoy the original or lean towards the darker side of purple but it's up to the community. (I've never been great with color) Trig - 17:21, February 14, 2020 (EST)

I'd go with option 1. --DeepFriedCabbage 15:05, February 19, 2020 (EST)

It seems that "original" does not necessarily equal "accurate" in all cases. Take File:NSMBU Luigi Jumping Artwork.png for example. Note that the optimized version contains a darker green and the gamma ("original") version contains a lighter green. Then look at File:NSMBU FourCharacters.png from the same game, where the opposite is true. Therefore, it seems that there are some images where gamma correction produces an accurate image, and other images where gamma correction produces an inaccurate image. Given this, I think we can't say that gamma should always or never be removed, since it depends on the image. How do we determine when the original is accurate, and when the optimized version is accurate? A side note: it is possible to keep certain metadata, such as the gamma chunk or embedded ICC profiles, while still optimizing the image, such as by passing the --keepchunks=iCCP,gAMA,cHRM option to zopflipng or the -kiCCP,gAMA,cHRM option to pngout. See this page for further explanation. I tested it on File:NSMBDS Goomba Artwork.png. Note: preserving only the iCCP chunk has worked for every image I've tested so far, but theoretically there may be older images that rely on the gAMA or cHRM chunks. Since these legacy chunks are very small, it's probably worth preserving them also. Maybe we could include this information in the policy, so that we can optimize the images without removing gamma.--Super Mario Fan ⁶⁷ (T•C•S) 00:01, February 16, 2020 (EST)

We could modify the template/proposed policy to consider this. Maybe something like:

This image contains gamma brightening, and should not be optimized without preserving iCCP metadata.

--Super Mario Fan ⁶⁷ (T•C•S) 14:31, February 16, 2020 (EST)

The image-critical ancillary chunks are tRNS (used on Captain Toad: Treasure Tracker ripped textures by APNG Optimizer to greatly reduce file size), sBIT, pHYs, and the color space chunks, sRGB (when it specifies a different rendering intent than the default one), gAMA, cHRM and iCCP. So far only the tRNS, sRGB and gAMA/iCCP have been spotted, but I’m not sure if the others are featured as well, press release material might be the most at risk, if it was generated using the AdobeRGB color space.

In any case, this specific proposal deals with the gAMA chunk and possibly the iCCP chunk.—Mister Wu (talk) 18:55, February 16, 2020 (EST)

I'm not sure we should mention performing image optimization on the template at all given that it's now heavily discouraged at best by the image use policy. -- Too Bad! Waluigi Time! 19:24, February 16, 2020 (EST)

The Image Use Policy only discourages "Re-uploading existing images solely to optimize file size," not optimizing images you are planning to upload anyway. There could be other reasons (such as cropping) that one may modify an existing image, and many people such as myself optimize all pngs uploaded, including images to reupload. --Super Mario Fan ⁶⁷ (T•C•S) 19:30, February 16, 2020 (EST)

I would suggest writing a specific new page about Gamma Brightening, and having two sections to the page. One, very general in description, explaining what it is as simply as possible (metadata is a thing and while usually ok is not here and therefore needs to be kept, here's why we keep it), and the second half getting into the really technical stuff involved. While I like the detail that SMF67 and Wu are providing, I have absolutely no idea what just about any of that means. On the second point, I usually optimize uploads that are new nowadays, but I am duplicating them to compare them, just in case. Also, input on the color would be nice. Trig - 20:50, February 16, 2020 (EST)

I like color option 2 the most. --Super Mario Fan ⁶⁷ (T•C•S) 17:58, February 17, 2020 (EST)

@Trig Jegman, @Mister Wu, I made a quick (still incomplete) draft of a page that could describe the technical parts of color-correction metadata and how to safely optimize these images in my sandbox. There are still a few missing details I haven't figured out yet, and anyone is encouraged to add to it or take details from it to make something else (we don't have to use it of course, I don't know if all of the information is relevant/important to include). Additionally, while it might be nitpicky, I think it might be a good idea to refer to the metadata as "color-correction metadata" rather than "gamma brightening," since technically gamma is only one type of color-correction metadata and iCCP seems to be the most common from the images I've tested. --Super Mario Fan ⁶⁷ (T•C•S) 18:24, February 19, 2020 (EST)

Perhaps it would be more appropriate then to use {{color-corrected}}, with the following? The link would be a new page that explains color correction in a much more broad sense with a section on how to properly optimize the images. Trig - 19:00, February 19, 2020 (EST)

This image has color changing metadata and should not be optimized.

Delete Template:No license

DELETE 7-0
Images should have licenses. That's how copyright law works! It's critically important that if we have an image on the site, then we use some form of copyright with it.

Sometimes, the uploader doesn't know how to tag it. If they don't they can use {{don't know}} and Category:Uploader unsure of copyright status (which has a fairly large number of items in it, by the way) and request another user that knows how to categorize the image to indicate it.

This template, however, does not make sense to have. Simply put, if we the collective don't know the copyright status of an image, we do not keep that image. Its so rare that one cannot be categorized anyway, but should an image be so uncertain that multiple people cannot determine its status, it will err towards safety and not use said image.

In short, delete this template and its category because the image that would be tagged with this would be deleted anyway.

Proposer: Trig Jegman (talk)

Deadline: March 1, 2020, 23:59 (UTC)

Support (delete it)

1. Trig Jegman (talk) Per proposal
2. TheDarkStar (talk) - Per proposal.
3. Supermariofan67 (talk) - Per proposal.
4. FanOfYoshi (talk) Per proposal.
5. Toadette the Achiever (talk) Agreed.
6. Obsessive Mario Fan (talk) Per all.
7. Niiue (talk) Per all.

Delete Category:User eo

DELETE 5-0
The language of Esperanto is not a real language. The auxiliary language was initially created by some linguists to attempt to be universal in application, but nobody really picked it up. As a result, it is not even a secondary language for any country in the world, and has fewer than 10000 'native' speakers (about 5000). Henceforth, it's application in the real world is virtually non-existant. As I like to joke, since we keep this around, why not add Klingon?

Nobody speaks this language. Nobody utilizes the category to speak this language. Nintendo does not even sponsor or support it as a language. It's unnecessary and (frankly somewhat appalling) that we continue to support a language that does not exist, and therefore this category should be removed.

Proposer: Trig Jegman (talk)

Deadline: March 5, 2020, 23:59 (UTC)

Support (delete category and esperanto support)

1. Trig Jegman (talk) Per proposal
2. Doc von Schmeltwick (talk) Laŭ propono
3. TheDarkStar (talk) - Per proposal.
4. Alex95 (talk) - Per proposal (I'm all for a Klingon template, though).
5. Waluigi Time (talk) Per proposal.

Add categories to the MarioWiki babel for Bengali, Urdu, and Hindi-speaking users

cancelled by the administrators
A proposal is not necessary for creating categories for languages, especially such common ones as these. As MarioWiki:Babel already says, if you speak the language, you're free to just create one.

I look at the MarioWiki babel and see three languages missing: Bengali (also known as Bangla in Bangladesh), Urdu, and Hindi. As a user of Bangladeshi descent, I'm quite surprised to see that Bengali isn't included in the babel; I'm also surprised that Urdu and Hindi haven't made it into the babel yet, either. It's proven that 425 MILLION people worldwide speak Hindi, another 300 mil speak Bengali, and another 100,000,000 speak Urdu. We're talking close to 850M speakers of these 3 languages; that's a rather large portion of the world's population! Don't ya guys think it's time we update the babel?

Proposer: MarioManiac1981 (talk)
Deadline: March 23, 2020, 23:29 UTC

Support

1. MarioManiac1981 (talk) Per proposal.
2. FanOfYoshi (talk) Per proposal.

Delete Category:User ka

keep 1-10

The Georgian language is esoteric to say the least. With just under four million native speakers, it's not a common language to come across. Simply put, it does not have a common application. Nintendo does not support Kartuli Ena (the language) on it's consoles or releases either. It is unlikely that there is ever a need for this language to be spoken, but should it be desired later that someone wants to show they speak the language, it could just be represented by the direct code. It does not make sense to support something that has been unused (and is unlikely to be used).

Proposer: Trig Jegman (talk) (Blocked)

Deadline: March 22, 2020, 23:59 (UTC)

Support

1. TheDarkStar (talk) - Per proposal.

Oppose

1. MarioManiac1981 (talk) The thing is, this wiki should be a place pertaining to everyone. So what if Georgian is a less commonly spoken language? Does that mean we're gonna exclude the Georgian-speaking minority by removing their language?
2. FanOfYoshi (talk) Per MarioManiac1981.
3. Lord Grammaticus (talk) Per all. I understood the Esperanto one somewhat, but I personally feel trying to prune every single instance of an "unpopular" language is a bit above and beyond the call. I feel like the "not an officially supported language" reasoning is flawed, since that shouldn't and doesn't necessarily stop a fandom developing among those speakers - fan translation communities do exist for the "bigger" languages after all, and the Babel doesn't exactly have any entry barriers to those wishing to utilize it, as JC indicated.
4. Alex95 (talk) - Per all.
5. Waluigi Time (talk) Per all, Lord Grammaticus in particular. Also, you say this could be represented through code if needed in the future, but if the category's deleted there's no substitute for it. Whether or not a language is supported by Nintendo is a moot point as you can speak that language while still enjoying their games (i.e. fan translations, knowing a secondary language that is supported, or just ignoring text entirely if you want to go about it that way). Trimming language support here down to what's "official" because Nintendo supports it is going a little off the deep end in my opinion.
6. Supermariofan67 (talk) - I don't really see the disadvantage of keeping it around, considering that it actually has native speakers (unlike Esperanto).
7. JoeRunner (talk) Per all. The fact that it's not on Nintendo systems doesn't disclude it from here, and "because it isn't spoken much" isn't a great reason either.
8. RickTommy (talk) Per all.
9. Niiue (talk) Per all.
10. PowerKamek (talk) Per all.

Create a "character/species" infobox

create 11-0
So as time has gone on, we've gotten to where entities can be interchangeably considered characters and species. Some of these, like Yoshi, Toad, and Kamek/Magikoopa, have enough respective information they can stay split relatively soundly. Others, like Draggadon, Dorrie, Koopa Kid, and Wiggler (to an extent) are not split, and doing so would be inconvenient both to read and to write and would more than likely require fancrufting to decide where the distinction lays. Others, like Birdo, Boom Boom, Krusha, and Klump probably should be merged due to how their creators treat them wholly interchangeably as a character or species, but are still split nonetheless. The main reason I see preventing that (as well as making the already-merged ones a bit awkward) is having to decide which infobox to use: character or species?

My proposed solution is simple: just have a combined infobox for wider-interpreted entities. This way, we can say other members of a species and their relatives while still acknowledging the "character" aspect exists to whatever extent it does in that particular case. I have code below, view page source to see. It includes all the main important facets (including the "relatives" parameter I didn't realize we'd implemented...) without any redundant parameters like "species."

Proposals/Archive/55

Proposer: Doc von Schmeltwick (talk)
Deadline: April 16, 2020, 23:59 (UTC)

Support

1. Doc von Schmeltwick (talk) Per proposal
2. Results May Vary (talk) Per Doc's reasons, he's already done something similar on a wiki we've been working on. This isn't completely related, but one reason I'd support is because the current species infobox have parameters like parent_species which displays "Variant of"--this makes the source name inconsistent with the displayed name. It would be great if we could change these parameters, which I've been wanting for a while.
3. Mister Wu (talk) Well, I think having a unified template can help as an initial step in trying to approach this character/species oddity, even though at the beginning it might be used just for a few cases like Draggadon and Dorrie
4. Baby Luigi (talk) Sounds like a good idea, and honestly, Boom Boom should have just been merged a long time ago as the two separate articles are pretty much duped: we can easily make a general Boom Boom article and note discrepancies in their general information section surrounding the inconsistency.
5. JoeRunner (talk) Per proposal.
6. Waluigi Time (talk) I don't really want to go down the "merging characters and species" rabbit hole, but admittedly that's just me clinging to nostalgia and this would probably be better for organization.
7. MarioManiac1981 (talk) Per all.
8. FanOfYoshi (talk) Per all.
9. Lord Grammaticus (talk) Doc's got the right idea, it's a small step at the moment but it'll be something.
10. Duckfan77 (talk) Per all.
11. Toadette the Achiever (talk) As they say, "why can't we do both"?

Comments

Not sure how I feel about this right now, but this got me thinking - why don't species infoboxes already have a section for portrayals? Shy Guy and Wiggler come to mind as enemies that could benefit from it, and it's a lot neater than just throwing it in the opening somewhere, or worse, neglecting to mention it at all. -- Too Bad! Waluigi Time! 12:03, April 9, 2020 (EDT)

Create a template for citations

Do not create template 5-9
BEFORE YOU READ, KEEP IN MIND THAT I'M NOT PUSHING ANY POLICY. I AM ONLY PROPOSING AN ADDITION THAT WOULD ENCOURAGE CERTAIN FORMATTING CONVENTIONS, BUT IT WOULD BE UP TO EDITORS TO UTILISE.

Go to the list of Yoshi's Island glitches page and scroll down to the bottom. See those huge blue stacks of undefined links? They make me a little uneasy to be honest. Not a great issue, but they certainly would look better if they were formatted more like this, tidy and comprehensive.

When citing a source, some users are careful to note the author, website of origin, and date of retrieval, while others are content with just putting a link forefront. The way citations are currently formatted on the wiki is, therefore, quite arbitrary and unprofessional. Wikipedia has a template specially created to make citing sources tidy and consistent, and I think we should follow their model for the mere sake of professionalism. This also has the advantage of not having to type in every single character and risk omitting a period or a bracket, at least for me, as they would already be a part of the template.

The template can be used to cite virtually anything, from books, magazines and guides to websites, and have their publication date, publisher and other details mentioned as well, provided their corresponding parameters in the code are filled in. If the proposal passes, the following code, which is similar to what Wikipedia has, will be used:

{{ref
| name       =
| date       =
| url        =
| title      =
| page       =
| source     =
| accessdate =
}}

which, when incorporated, should produce the following line:

Name (Date). [URL Title]. Page. Source. Retrieved Accessdate.

Previously proposed code, modified to the above for brevity:

{{Citation
| last       =
| first      =
| year       =
| url        =
| title      =
| page       =
| publisher  =
| accessdate =
}}

which, when incorporated, should produce the following line:

last, first (Year). [url Title]. Page. Publisher. Retrieved Accessdate.

where the last and first parameters correspond to the author's last and first name respectively. If the author uses a username instead of their real name, then only the first parameter should be filled in; if neither of those parameters are filled in, the brackets around the publication date are removed.

Proposer: Bye Guy (talk)
Deadline: May 1, 2020, 14:54 UTC

Support

1. Bye Guy (talk) per proposal.
2. Waluigi Time (talk) This would make references look a lot more professional and consistent, I see no reason not to do this.
3. Duckfan77 (talk)Per all.
4. FanOfYoshi (talk) Per all.
5. Supermariofan67 (talk) Per all.

Oppose

1. Lord Grammaticus (talk) - I understand and agree that reference formatting is something of an issue, but the use of a template to solve the problem strikes me as dubious, especially when numerous resources that show and teach how to use MLA-style citations already exist. It's still on editors to put those resources and knowledge to use, and I feel like this is misguided in that specific sense of providing yet another something that might not be paid attention to.
2. Doc von Schmeltwick (talk) - First off, the "last" and "first" are automatically flawed since a grand majority of YT videos and the like run on screen names. Furthermore, many of these could be misinterpreted regardless, and this is far less user-friendly than say, our aboutfile template. Furthermore, between MLA and APA, there is no "right" way, and a shocking amount of the resources for those are becoming subscription-only for some bizarre reason. On another note, just having "year" is additionally flawed for video-type sources, and "publisher" is extremely esoteric for a subject like this. We aren't writing scientific journals here.
3. LinkTheLefty (talk) - We haven't even fully sorted through the wiki's former use of contractions, and that was years ago. It would be a waste of time to expect us to go back to each and every citation and ensure they're all updated to a template standard. As noted, Wikipedia's reference style is more academic, while this is decidedly not, and thus not all of those are going to be applicable and many are going to have incomplete information. If you don't like informal citations, you're free to update them yourself on your own time, but please don't force other users to stop what they're doing and implement a rigid system that'll be more trouble than it's worth.
4. TheDarkStar (talk) - per all
5. Yoshi the SSM (talk) - per all especially LinkTheLefty.
6. Goombuigi (talk) - Per all.
7. Niiue (talk) Per all.
8. JoeRunner (talk) Per all.
9. PinkYoshiFan (talk) Per all.

Comments

@Lord Grammaticus: The same argument can be made against the analogous template used on Wikipedia, as well as all the formatting templates currently in use on this wiki ({{sic}}, {{wp}} etc.) The fact that someone may not be aware of such template doesn't make it less practical. -- KOOPA CON CARNE 14:10, April 24, 2020 (EDT)

Mm, fair enough. I'll mull over the vote later today when I have obligations out of the way. -- Lord G. matters. 14:16, April 24, 2020 (EDT)

@Doc von Schmeltwick: I already addressed the potential issue with run-on names in the proposal:

If the author uses a username instead of their real name, then only the first parameter should be filled in

But I agree that using "last" and "first" parameters is not very user-friendly; however, it can be simplified with ease to something like "name". The "year" parameter can be changed to "date" very easily also, and "publisher" can be changed likewise to something more general like "source" (since YouTube can't be cited as a publisher). A large part of your argument seems to be fixated on easily modifiable details that I didn't bother to adapt here, which I admit is a mistake on my part. The rest, regarding "we're not writing scientific journals"--I'm sorry but it doesn't make sense to me. Does that mean that we shouldn't establish some professional conventions? While we're at it, let's scrap the entirety of our writing guidelines and disregard any past proposals. -- KOOPA CON CARNE 15:13, April 24, 2020 (EDT)

When I said that I meant, like, why cite things like we're citing a textbook? Additionally, your "Wikipedia uses it" argument is also flawed in that manner, as they have lengthy articles over nuclear physics and paleobiology that actually would warrant a citation in that manner. On another note, if a video is taken down and needs replaced, it'd be much easier to change the url and leave the "video showing glich" text alone rather than alter every bloody parameter. The convention you are attempting to establish is honestly little more than a burden considering the limited scope of what we cover. Doc von Schmeltwick (talk) 15:21, April 24, 2020 (EDT)

On another note, if a video is taken down and needs replaced, it'd be much easier to change the url and leave the "video showing glitch" text alone rather than alter every bloody parameter.

Doesn't that mean basically changing the entire source? That kinda has to be done regardless if a template is used or not. And the fact that Wikipedia has a different / much larger scope than us has no relevance to the matter. -- KOOPA CON CARNE 15:34, April 24, 2020 (EDT)

How? Changing a link is much simpler than changing the entire specific and quite frankly irrelevant extra information about a hobbyist posting a video. And again, the fact that what we cover isn't going to be sourced from things like scientific journals or textbooks has entirely to do with how this is unnecessary. Posting a quick link to Youtube or TCRF with a quick descriptor rather than filling out information that 70% of the time won't even exist offhand is much more efficient. Doc von Schmeltwick (talk) 15:46, April 24, 2020 (EDT)

Wait, sorry, now I understand what you are saying. You are against writing citations as per MLA conventions as a whole, and support something simpler instead, like just putting a link. I'm afraid I cannot agree with that; we should strive to look as professional as possible. -- KOOPA CON CARNE 15:42, April 24, 2020 (EDT)

...No? I'm against unnecessary fluff, which this is. Doc von Schmeltwick (talk) 15:46, April 24, 2020 (EDT)

YouTube and Twitter hobbyists have the same weight as an officially-endorsed/published author in this case if the source is relevant to our interests. They all produce or reveal information, and I have a feeling that this is what Wikipedia uses as a basis for citing all of their sources in the way they do. -- KOOPA CON CARNE 15:52, April 24, 2020 (EDT)

I think "source for official terminology" is a different thing than "verification that something that's not supposed to happen can happen." Attempting to force a style for majority incompatible sources isn't professional and it isn't proficient. What it is is profoundly prolonging profuse peripherals. Doc von Schmeltwick (talk) 16:07, April 24, 2020 (EDT)

If a convention is set in a particular area, then everything in there should follow it, even if it sacrifices "efficiency" in some cases. Context is key: it's not efficient to use academic lingo when you communicate with your peers, but it is going to be needed when you write a research paper, with no exceptions. Same here: if particular sources are cited in a way, the others should be cited in the same manner as well with no exceptions. -- KOOPA CON CARNE 16:19, April 24, 2020 (EDT)

"If a convention is set in a particular area, then everything in there should follow it, even if it sacrifices "efficiency" in some cases." ....you realize that's inherently a bad thing, right? Being inefficient at the "boon" of considering yourself professional in a needless manner is not a good trade-off. I don't intend to be rude, but I can't see this as anything but that. Doc von Schmeltwick (talk) 16:24, April 24, 2020 (EDT)

You certainly could have worded that remark a little differently but I digress. Let's agree to disagree. Either way this goes, I'll still format YouTube links like how I proposed. -- KOOPA CON CARNE 16:30, April 24, 2020 (EDT)

...you literally said that you want to encourage the creation of inefficient incompatible rules, while admitting they are as such. Doc von Schmeltwick (talk) 16:33, April 24, 2020 (EDT)

Yes, I understood that. My issue was with your tone, but what you said now is perfectly fine. -- KOOPA CON CARNE 16:40, April 24, 2020 (EDT)

I'm wondering what your motivation for this is? What benefit does it have? "Looking professional" is entirely subjective. ZeldaWiki's source template makes me want to dry heave. A needless obfuscation of a task we want to encourage people to do discourages sourcing or even editing in general. Also, given current social circumstances, my mere bluntness is really acting as nice as feasible. Doc von Schmeltwick (talk) 16:46, April 24, 2020 (EDT)

At its core, it's mere preference, backed up by the fact that it's a practice a very regulated place like Wikipedia carries out. What makes me "dry-heave" is the opposite: lack of organisation, just seeing a url slapped under a headline. This template would not be "discouraging other people or forcing it onto them". If someone includes only a link as a source, someone else can format it later in the right way, which is--and excuse my use of italics, but I feel it's warranted here--a thing that is happening currently. A template would make that easier for people like me who want citations to look a certain way, but then I suppose this does not motivate an entire template be put in place as it's subjective. That is why I tried to look up to a website like Wikipedia and try to model my preference after certain criteria. The reason they made this formatting decision is precisely because it looks more organised, which is a sign of professionalism. -- KOOPA CON CARNE 17:01, April 24, 2020 (EDT)

What that ergo entails is that like aboutfile, it's merely a suggestion. Therefore, the only people who will use/fix them anyways are the ones who specifically like it in spite of its user-unfriendliness (as unlike aboutfile, which shows up every time an image upload is prepared, people would have to go out of their way to remember the specific names for each parameter, itself already a major pain for less-used templates like multiframe and multiple-images). If you want to change how they looks, that's fine, but trying to force it (a template regarding this implies it is intended to be used in a policy-driven manner, and you yourself advocated it should be rigidly followed in a preceding comment) the when so many cases are incompatible isn't "professional." I was gonna append a contextually appropriate snarky comment relating to one of the only good remaining newspaper comments, but decided against it Doc von Schmeltwick (talk) 17:09, April 24, 2020 (EDT)

I would like to back-paddle to the comment you mentioned and withdraw that argument, as the existence of the "aboutfile" example (and to a lesser extent, {{ref quote}}) actually makes my point stronger now. If the template is optional, but some people want to use it, then let it be. Like Waluigi Time said in a comment below, the template wouldn't be forced on anyone. People who won't use it are free to not use it. I'm merely stating arguments to support my proposal, not pushing an addition down people's gastrointestinal tract from the entrance down. --