HRWiki talk:Standards

From Homestar Runner Wiki

Current revision as of 20:27, 10 January 2025

[edit] Tradition is not necessarily policy

After a bit of confusion recently, i wanted to flesh out a certain topic a bit more. That topic is the issue of people assuming that tradition is policy, and favoring tradition where something else makes sense. I probose a new heading under General that will hopefully describe some of this. Here's what i have so far:

Sometimes, traditions will develop and people will tend to always do something in a certain way. However, if there is a reason why doing it differently is better, there is no reason to stick with tradition merely for the sake of tradition. For example, if there is an external link that goes to Wikipedia, but a distinctly more informative article on the topic is available elsewhere, there is no reason to favor Wikipedia's.

I can also think of another example which is the tradition of piping links to avoid redirects, where in most cases, it makes sense to just let the redirect handle the link. If anyone has any thoughts on this, or more examples of this type of thing, or ways to reword this to make it better or make it include more examples, i'm all ears. — Defender1031*Talk 19:09, 2 July 2008 (UTC)

I agree wholeheartedly that tradition and consistency should not trump functionality or reasonable sense. That being said, perhaps in some cases where there's ambiguity, we should set a hard standard one way or the other. The pipe vs. redirect thing which has recently reemerged, is one of those cases, IMO. I, for one, support piping in the case of a redirect. The reason: The pipe only adds extra text to the edit page, which the casual reader will never see, whereas a redirect adds a very obvious "redirected from X" to the actual article. Thoughts? -132.183.138.199 20:33, 21 January 2009 (UTC)

I think that pipes are ugly, whereas "redirected from x" can be helpful. Personally, i think it makes sense for most cases that if i click on a link that says one thing and i get a page with a different title, that the page explains why. — Defender1031*Talk 21:48, 21 January 2009 (UTC)

Personally, I feel that redirects are mostly useful for searches, rather than links on a page. If you know what the correct link is, why not use it? More over, there are a number cases where pipes are preferred method of linking Homestar Runner (body of work) comes to mind, since it's necessary to have the distinction on the page title, but it'd never appear that way in the article. Cool Shades is another one that gets linked by pipes since the article now encompasses all eyewear. Perhaps pipes should be minimized (especially when there are capitalization differences), but they can not be removed all together. wbwolf (t | ed) 22:10, 21 January 2009 (UTC)

See also (Don't Fear) The Redirect above.

[edit] Glitches

I hope I wasn't too bold by changing the definition of Glitches. I think that the wording of the previous definition really did not include the majority of things that actually get listed under that heading. It used to be

Similar to Goofs, but limited to mistakes in the Flash software.

And I changed it to

Similar to Goofs, but limited to mistakes made by the Brothers Chaps in the usage of the Flash software or shortcomings of the Flash software itself.

The former definition made it sound as if the mistake had to be in the Flash software itself to fit the category of Glitch, which is obviously not the way it's used around here.  Green Helmet 04:38, 14 July 2008 (UTC)

[edit] May I copy these Standards to another wiki?

Hi guys, remember me? :) I've started a new wiki that I'm loosely modeling after the structure of this one, and I'd like to adopt these standards and just direct copy/paste them into a similar Manual of Style or Standards page on that wiki. This will save me a lot of time and make it easier for me to start getting more people involved. I will, of course, remove references to HRWiki and adapt the standards to my wiki as appropriate (removing sections that don't apply, etc.).

If you're interested, the wiki I'm working on (just created yesterday and still very much under construction) is The Red Green Wiki. If you're a fan of that show, I invite you to drop by and help out! :)

Thanks guys. —  KieferSkunk (talk) — 01:38, 6 December 2008 (UTC)

Hey, KieferSkunk, how ya been? I don't think you need to ask, but thanks for doing so anyway. Feel free to rip us off! (I mean, we totally didn't rip off Wikipedia when we first set up this site.) I think under our Creative Commons license, you're supposed to give us credit or something, but who's gonna know if you ignore that part. Keep on tranglin'! — It's dot com 01:52, 6 December 2008 (UTC)

Cool! Thanks. :) —  KieferSkunk (talk) — 02:10, 6 December 2008 (UTC)

[edit] Raw characters vs HTML entities

Based on a discussion on Talk:Compé, I think we need to bring this up again. Our current policy of using HTML entities for everything outside ASCII is basically just tradition at this point... there's not really any actual reason to keep it that I can see. It only came about because twice the wiki's had problems during upgrades that broke on Unicode characters... once when we moved from WikkiTikkiTavi to MediaWiki, and once on one of the earlier upgrades (I think 1.5, when UTF-8 support became mandatory... the wiki was already being served as UTF-8, but something backend thought it was still Latin-1, so all the pages got mis-read as Latin-1 during the upgrade, and double-encoded as UTF-8). Both of which wouldn't have happened if we were using only HTML entities at the time. Also, there was the occasional edit that would convert non-ASCII or non-Latin-1 characters to something else... from browsers where simply clicking "edit" and then "save" without changing anything would still mess up on those characters. So HTML entities became the Standard™... and I think I was one of the people pushing for it to stay that way.

But all those pitfalls have long gone away... MediaWiki has gone through 10 major versions since the mixup, and we've never had an encoding problem during an upgrade since... it's stable now. And I can't remember the last time I saw an edit that accidentally broke a Unicode character, it'd have to be years ago. I can't think of a single browser in current use which has problems with UTF-8 (noone's going to be reading "Compé" as "Compé", which is the usual fate for non-UTF-8-comprehending programs)... and while I can think of one browser that has troubles with characters outside Latin-1, which would automatically convert them if you tried to edit a page... it's not in any way in common use. And even if an editor does come along and break all the Unicode characters on a page, it happens few and far between enough that it would be less effort to just fix it when it happens, rather than trying to prevent it from happening.

And really, the only place where raw characters and HTML entities differ is on the "edit" page... everywhere else, they behave the same... so that's the only place we need to look at. And in that edit page, the entities are ugly and hard to read... and raw characters can potentially cause problems in very rare situations that are getting rarer as time goes on. And I really do think the latter is rare enough that the former outweighs it. And I think that's been the case for some time, we just never noticed, because of the inertia of tradition.

Now, I will make one exception to this... and that's dashes. It's much easier to tell the difference between — and – than — and – (especially in the fixed-width font used in the textarea in the edit screen, where they're more like — and –), so it's easier to keep them standardised as entities. Other symbols, like ™ and ½ I'm on the fence about. But letters, especially in the middle of words, like Compé, I definitely think are better as raw Unicode characters.

Note that I'm not recommending that we go through all the pages and replace the entities with actual characters... I don't think it matters that much. Just that we go from "HTML Entities Forever!" to "whatever's there is good"... if something's already there with entities, that's fine, if it's with raw characters, that's fine too... neither case really warrants zealously changing from one to the other. But if someone wants to go through a page and replace all the entities with characters for some reason, then that's their time to waste, and I've got no problem with letting them do it. But I do think we should at least lean towards raw characters over entities for new pages.

But that's my two cents... in as much as that phrase can be applied to 5 paragraphs of rambling... Who else has an opinion? --phlip ^T_C 10:28, 5 August 2009 (UTC)

Phlip and I discussed this yesterday. When I brought it up, I said, "Compé is really no better than straight-up Compé. Yes, back in the day it might have been a problem, but browsers almost uniformly get it right these days. Even when they don't, there are technical safeguards to prevent problems. The best proof I have of this is that there are never any problems with using {{User:Heimstern Läufer/sig}}." I strongly support the exception for dashes. I also don't mind entities for non-alphabetic characters, because it's often easier to enter them that way than to find the actual character, but whatever works is fine with me. — It's dot com 15:53, 5 August 2009 (UTC)

I was going to bring up that I did find an instance of a unicode character being accidentally broken... but, now that you mention it, it was four years ago, from a user that hasn't been seen in over a year, and it was a rarer character than "é". I will say that I'm likely to have trouble remembering how to type the "é" character without copy/pasting or using the HTML entity (I know what an acute accent is, so remembering "é" is a lot easier for me.) It's quicker for me to just use the form I know over something I'd constantly have to look up, even if it is five keystrokes more in practice. --Jay (Gobble) 18:40, 5 August 2009 (UTC)

As long as the database for this wiki is in UTF-8, I'm sure we're good with using é. In fact, if we use "é" more often, we'll probably save some kilobytes by the time the Compé is obsolete. We can always put a notice on the talk page listing the key combinations for various operating systems to insert "é". I also agree with continuing the use of —, as Courier/Courier New makes it hard to tell the difference between an em dash, en dash, and just a plain dash. Using entities for other special characters we might want to keep strict, as some of the characters might not be supported in UTF-8, but UTF-16, and could result in bugs. But I'm not too sure what I'm talking about when I say that. I'm still a little confused with how UTF-8 handles UTF-16 attempted characters and whatnot. Oh, I'm just going to far.:P --76.224.216.122 18:07, 7 August 2009 (UTC)

It seems that that the page is still "pro-entity" for non-Latin-1 characters. Should this be changed? I'm can't confidently determine the conclusion of this conversation. —Soiled Bargains ^(talk|ctrb) 00:21, 30 September 2011 (UTC)

[edit] mdash vs. ndash

I would like to revisit this topic, specifically regarding — and –. I understand the difficulty in telling these apart in text: I often run into that problem myself. And in many cases, — is readable by itself on lists. However, I find that in some cases, particularly those where the dash is attached to one or two words, it is harder to parse the source code. To resolve that I came up with a compromise: I created an — template {{-}} that should be easy to type, distinguishable from the regular dash, and still easy to read in text. Click here for a sandbox test. Opinions are most welcome! If this is acceptable, perhaps we could unleash a bot or two on the main namespace? --Stux 13:44, 6 April 2013 (UTC)

I don't actually find the entity style hard to read, though I have no problem with using {{-}} instead for lists. Still covers all the basic requirements discussed above. — Defender1031*Talk 17:36, 25 February 2017 (UTC)

I, personally, find it a little bit easier to read the list code (or the code in general) when using the template. HTML escape codes seem to blend into the word for me. In any case, a better system just occurred to me (especially after learning from you that ndashes and hyphen-minuses are different things!). Instead of just using {{-}}, we could create 3 or 4 templates (I checked wikipedia and they do something similar):

• {{-}}: this template would be repurposed to place an – in text. Oddly enough wikipedia uses it as shorthand for the {{clear}} template.
• {{--}}: this would be the new — in text. This is the same as in wikipedia.
• {{---}}: this could be used for wider dashes. Wikipedia does something similar. However, there likely won't be a use for it here.
• {{----}}: This is actually used by wikipedia to insert four consecutive hyphen-minuses since the wiki code uses that for horizonal bars iirc. Using <nowiki> tags would do the same thing but with more typing. I haven't seen a need for that template here.

The template is only used in two main space pages, so it would be easy to switch over (unless people really, really, really want to use straight up — tags in the code and scrap the template.) --Stux 18:52, 25 February 2017 (UTC)

Hi all, I finally went ahead with the plan I outlined above and created a {{--}} template (for —) and updated the {{-}} template to yield an –. I also updated all existing articles that used the original template ({{-}}) so they would use the new one ({{--}}). I'm hoping these templates will find more use on the wiki. Please let me know if there are any issues or questions. —Stux 03:07, 8 April 2018 (UTC)

I don't understand the purpose of these templates. For one thing, we almost never use – on this wiki, so I don't think we need a template for it. It would be like creating a template exclusively for the £ symbol. That symbol may be used once or twice on the wiki, but not enough for its own template. Secondly, {{--}} is only one character less than —, so there's not much of a difference there. Not to mention, many of the users here (as far as I'm aware) are more used to typing —. It's muscle memory to me at this point, so changing it would likely cause more problems than it solves. Also, nearly all of the pages use —, so we would likely have to get a bot to change almost every article on the wiki, and I don't exactly see why that's preferrable. Gfdgsgxgzgdrc 22:19, 27 October 2018 (UTC)

In my opinion, we should either use — or just plain —. Preferably the former, since it doesn't require any copy/pasting or fancy typing. Gfdgsgxgzgdrc 06:25, 18 May 2019 (UTC)

Ooops! Sorry I never got around to answering your questions. I probably stashed this page in a TODO list somewhere and forgot about it! Anyway, in no specific order, here are the reasons I have for preferring to use these templates (that is, if you don't want to or for some strange reason can't use the Unicode text directly):

• Memorization: which is easier to remember? — or {{--}}? For those who are used to wiki syntax I say that the template format is a lot easier to remember!
• Readability of source: (This is more subjective) In my personal opinion the wiki source is easier to read when you have something that looks like dashes instead of a whole bunch of escape codes. If you look at this diff you'll see what I'm talking about.
• Organization: This refers more to the mdash vs ndash thing, but I think, the wider the dash, the more hyphens should be used to represent it. So the mdash uses more hyphens than the ndash. And why do we even have an ndash template? Sure, ndash is less widely used, but as this discussion established, it's a different character from the hyphen-minus. And if memory serves me correctly, I *think* it's being used somewhere in this wiki. So if it's needed the template is available for use.

Anyway, that is my rationale for creating and using the templates (primarily the "Memorization" and "Readability" arguments). In general, I don't think there is any detriment to having the templates even if they're not used, and their use, to me, can only be beneficial. --Stux 15:52, 18 May 2019 (UTC)

Okay, that makes sense. I didn't really think about the memorization or readability aspects of the templates. Thanks! Gfdgsgxgzgdrc 18:52, 18 May 2019 (UTC)

[edit] Policy regarding Poker Night at the Inventory

Telltale's yet-to-be-released game, Poker Night at the Inventory, is unique in the fact that it takes four characters from different worlds and puts them in the same room. This could pose a problem for our wiki, however. As the game isn't in the HR universe and includes characters from other games, there are some aspects of the game that need not be mentioned on the site. As it stands right now, however, our policy on what should be mentioned about this game is rather vague. I can see this becoming a problem down the road when the game is released; some users might find content HRWiki-worthy, while others might not. For instance: Should Max have his own article? Should his dialogue be listed here? It might start a few edit wars. In my opinion, a line should be drawn that clearly defines what should and should not be included on the wiki in instances like this game, before the game comes out. Does anybody else share my opinion, or am I making a mountain out of a molehill? --DENNIS ^T/_C 00:55, 4 September 2010 (UTC)

[edit] Spaces

It's been a while since I've done work with transcripts, but I feel like I've come across a lot of description/action statements that use formal two space sentence spacing, whereas I've seen many others that only use one space. I don't know whether or not this is something the transcribers are doing, or whether or not it's an unmentioned part of our standards. I can see why double spacing is being applied, as the text is displayed in italics and in some cases could be hard to follow. However, I don't really see that much of a difference, and I'd like to know whether this is something that could become a standard, if something needs to get set straight, or if I'm just being too picky, haha. —Soiled Bargains ^(talk|ctrb) 23:09, 16 December 2010 (UTC)

It doesn't matter how many spaces you put in the edit window, it always displays as just one space. (Click edit to see what I mean.) The only way to get it to display more than one space is to use a nonbreaking space (like   this) or CSS styles, which we only do in rare cases. Most of the time it makes no difference how many spaces you enter, and whether you should enter one or two after a sentence depends largely on your own preference. Some people find it easier to read the text when there's two spaces after a sentence in a fixed-width font (as in the edit window). I personally always just use one. — It's dot com 00:18, 17 December 2010 (UTC)

Ah, you see, I forgot that about MediaWiki. Looks like I'm still not reacquainted with this place yet, haha. Thanks! —Soiled Bargains ^(talk|ctrb) 00:28, 17 December 2010 (UTC)

To clarify, it's not MediaWiki per se but rather how your browser interprets HTML. If you view the HTML source you'd see those spaces are still in there. It's your browser that doesn't display them in the final text. — It's dot com 00:33, 17 December 2010 (UTC)

See what I mean? —Soiled Bargains ^(talk|ctrb) 01:09, 17 December 2010 (UTC)

[edit] Tables

[edit] ids

As some of you may have noticed, yesterday I began work on a new standard for tables. My experience with editing this wiki has led me to the conclusion that a lot of them were hastily made back in the early MediaWiki days, and that possibly newer tables have been based on these. My number one complaint however is that we have inconsistent id attributes all over the place. I decided to take it upon myself to create a format ids so that future table-based articles would validate and be less likely to conflict with other ids across the wiki. But now I've realized that this is probably something we should discuss, as I've realized that my proposal needs improvement that I myself am not confident of making. I'd like others opinions on what the format should be. Fortunately, I've discovered that spaces and other characters are escaped automatically in ways that comply with the W3C's standards. Umm, I need to get this posted, so I'll just stop here. Your thoughts? —Soiled Bargains ^(talk|ctrb) 19:58, 20 December 2010 (UTC)

It's dot com said we should just handle table ids as we do for links to sections. This makes sense seeing that illegal characters are escaped by MediaWiki. My only thing to add is that any if an anchor starts with an illegal character, its escaped anchor name will start with a ., which will make it illegal anyway (like the section on Thorax Corporation that starts with 'Juwanna Mann'). —Soiled Bargains ^(talk|ctrb) 21:49, 23 January 2011 (UTC)

What I said was that the IDs should exactly match the content of the most important column in a table (Xeriouxly Forxe Character Variations is a good example), which makes pretty and intuitive links. We don't need to worry about special characters and the like, because MediaWiki handles them automatically. The exception would be for things like the weeklies, which use numbers, but we already have a consistent style for those. — It's dot com 22:26, 23 January 2011 (UTC)

[edit] Styles

While I've said that tables are an inconsistent mess, they're also a stylistic inconsistent mess. I've given tables the wikitable class occasionally, and the only reason I do that is so that we can have the styles for all of the tables in one place: the CSS for the site. However, are there any changes to the styles we should do now? Should we make the table width 100%? Make table headers darker? Should we create some sort of hrwikitable class instead? I'm just downright unsure. —Soiled Bargains ^(talk|ctrb) 21:49, 23 January 2011 (UTC)

I don't think this is a pressing issue given the current rate of updates. — It's dot com 22:26, 23 January 2011 (UTC)

[edit] Standards for gags/jokes

Should we create standards for the appearance for articles about inside jokes/running gags, or should we still handle them de facto style? —Soiled Bargains ^(talk|ctrb) 21:49, 23 January 2011 (UTC)

Is this broken? (If you say yes please give examples.) Would the pages actually benefit from some kind of standardization, or do we have different styles simply because not all running gags are the same? — It's dot com 22:26, 23 January 2011 (UTC)

Um... I'm not too sure. Maybe, maybe not. But here are a few things that I think are worth considering:

• Some articles have the appearances section written incorrectly compared to our currently de facto. I've seen (and corrected) this with Dan, Toilets, and more recently Greg. New articles concerning gags/jokes (unless written in haste/based off of a badly written article) aren't really a problem nowadays.
• When a reference is in an Easter egg, it will either be labeled in parenthesis before the em dash ("(Easter egg)"), or put after the em dash ("In an easter egg..."). I'm going to be lazy and pass on giving examples, but my next point is similar and has a few. I assume we put "(Easter Egg)" before the em dash.
• When a reference is in the DVD commentary, well... I've seen that done a few (the show) different (TGS10) ways (narrator). I assume we put "(DVD Commentary)" without linking it before the em dash.
• There have been recent articles like Stanley Kubrick that use "References" instead of "Appearances", and then there are articles like Monkey Island that use both, using Appearances for physical appearances of the work in question, and References for just mentions. Should it work like this?

—Soiled Bargains ^(talk|ctrb) 23:38, 23 January 2011 (UTC)

[edit] Running time standard wording

When listing the official time (usually when it's wrong), it is more factual to use (actual) or (TV Time Toons Menu)? Or should you only use the latter when the menu is correct? - Catjaz63 23:14, 3 December 2015 (UTC)

There seem to be a few precedents, based on Special:Whatlinkshere/TV Time Toons Menu:

• Cheat Commandos (toon), TrogdorCon '97, Happy Hallow-day, business trip, fan club, shapeshifter, Fan Costumes '08, Dangeresque: Puppet Squad, 79 Seconds Left (with slight variation) and Halloween Safety all use "#:## official, #:## actual", as did Which Ween Costumes? before it was edited yesterday.
• The three Halloween toons with dialogue alternatives use "#:## (TV Time Toons Menu), #:## (Combined) (Actual)"
• I Killed Pom Pom uses "#:## (TV Time Toons Menu), #:## (YouTube)". The toons menu time seems correct or close enough so I think that qualifier should be removed.
• sbemail206 has "#:## (official), #:## (actual)".
• The House That Gave Sucky Tricks has "#:## (TV Time Toons Menu), #:## (Actual), #:## (YouTube)".

I'm not sure why some have parentheses and others don't. Or why some are capitalized. But I think "actual" should be used for the real running time only if the official time is noticeably off, with "official" alongside it for the running time that appears on the Toons menu. Otherwise the time for the main site's version of the toon doesn't need a qualifier. DEI DAT VM^┌_{datvm center}\^{super contra}_┘ 18:04, 4 December 2015 (UTC)

And by "only if the official time is noticeably off" hopefully you mean off by 1 second or more! ;) Btw, I think using "official" when referring to the TV Time Toons Menu itself is fine as a standard (notice that we still link to the toon menu itself. I like the parentheses too. Hmmmm. A formatting template could be built... *gears start spinning* --Stux 21:21, 4 December 2015 (UTC)

That seems like a good idea. The elements "combined", "official" and "actual" should probably be uncapitalized. Perhaps "official site" or "main site" as a contrast for "YouTube" could be used with cases like I Killed Pom Pom above. DEI DAT VM^┌_{datvm center}\^{super contra}_┘ 21:48, 4 December 2015 (UTC)

[edit] Linking to articles with disambiguation in the page title

This edit raises a question: How should "Toon Name (video)" pages (like Sketchbook (video) and Trogdor!! The Board Game (video)) be listed in pages? "Toon Name (video)", or "Toon Name Video"?

I don't really have an opinion (possibly leaning slightly toward "Toon Name Video"). Gfdgsgxgzgdrc 07:04, 17 August 2018 (UTC)

I kind of agree. The parens are just internal to the wiki to distinguish pages. -174.62.238.201 12:53, 17 August 2018 (UTC)

In running text the parenthetical material should be hidden (and referred to using additional words, or not, as the case may be). The part in parentheses is not part of the actual title; we include it only because we have to. In tables and lists, however, I'd favor listing the page title exactly as it is, since those sections are more for reference and less for reading. — It's dot com 14:43, 17 August 2018 (UTC)

[edit] Retroactive names in transcripts

This edit raises a question: Should retroactive names (using a character's name in an early transcript before their name is revealed) be allowed in transcripts?

I think retroactive names should be allowed. It makes things a lot more convenient for the reader, and it's not like anyone's going to be reading these transcripts in order. Plus, if the person is browsing the wiki, chances are they're aware of the character's name. If Baron Darin Diamonocle is the title of his wiki page, he should be called that in all his transcripts too. Gfdgsgxgzgdrc 07:04, 17 August 2018 (UTC)

Note that [that edit] was reverted. -174.62.238.201 12:53, 17 August 2018 (UTC)

By an Anonny whose only edit has been that revert, no less. RickTommy (edits) 13:00, 17 August 2018 (UTC)

That's beside the point. It could be an active user who just happened to make an edit from that IP. — It's dot com 14:45, 17 August 2018 (UTC)

Another edit was made regarding retroactive names. Does anyone else have an opinion? Gfdgsgxgzgdrc 23:27, 31 December 2019 (UTC)

I lean toward not using retroactive names. The events in each toon and from one toon to the next happen in an order, and I think it's fine to preserve that in the transcript. — It's dot com 23:38, 31 December 2019 (UTC)

I agree, the transcripts should reflect the progression of the homestar universe as it was created rather than applying later information retroactively. — Defender1031*Talk 01:30, 1 January 2020 (UTC)

[edit] @StrongBadActual Dates

Long ago, it was decided that the format of Tweets in lists should be "@StrongBadActual — January 1, 1970". Recently, however, it seems to no longer be the case. So, how should Tweets be listed? Gfdgsgxgzgdrc 19:55, 5 October 2018 (UTC)

What all are the choices and what would be your preference? — It's dot com 21:03, 5 October 2018 (UTC)

Here is a list of choices. Feel free to discuss other options, as there is probably a near-infinite number of possibilities. This list is mainly just for convenience.
Also, the old version lacked a link to the Tweet's wiki section, so I added them in each choice.

• @StrongBadActual — January 6, 2018 — The old version.
• @StrongBadActual Tweet from January 6, 2018 — A sentence.
• Tweet from @StrongBadActual on January 6, 2018 — A longer sentence.
• @StrongBadActual (6 January 2018) — With parentheses instead of an em dash.
• @StrongBadActual [6 January 2018] — With brackets instead of an em dash.
• @StrongBadActual: 6 Jan 2018 — With a colon instead of an em dash.

The date format can be changed as well. (Jan 6 2018, 6 Jan 2018, January 6th, 2018, etc.) Personally, I'm leaning toward the parentheses, with the Jan 6 2018 format. Gfdgsgxgzgdrc 22:38, 5 October 2018 (UTC)

I support the parentheses format, with either 6 Jan 2018 or Jan 6 2018. Lira (talk) 01:50, 6 October 2018 (UTC)

Jan 6 2018 is an improper format so it should not be on the table. If you want to go comma-less, either 6 Jan 2018 or 6 January 2018 is acceptable. An ordinal number (6th) is also not proper for tabular material and shouldn't be considered. For the listing, I support parentheses, brackets, or a colon. — It's dot com 02:09, 6 October 2018 (UTC)

All right, changing my vote to @StrongBadActual (6 Jan 2018). I still support parentheses, because that's also how we document DVD commentaries and Easter eggs. Brackets are hardly used on the wiki, and I guess a colon would be fine too. Gfdgsgxgzgdrc 21:27, 6 October 2018 (UTC)

I'm not sure which format I prefer but I wanted to point out that since we also have an @StrongBadActual Instagram Account we should always include the word "Tweet" in the entry. The format can then be adapted to say "Instagram" when such posts need to be referenced. --Stux 21:50, 6 October 2018 (UTC)

Changing my vote again. @StrongBadActual Tweet (6 Jan 2018) and @strongbadactual Instagram post (6 Jan 2018). Gfdgsgxgzgdrc 22:18, 6 October 2018 (UTC)

[edit] Basic Articles

This helpful section was added to the page, and reverted twice (by the same user) because:

1. There was no discussion, even though that isn't necessary for a simple addition to the page.
2. It was added by an anonny, which matters 0%.

These reasons don't really seem relevant, and I think the section should stay. But to avoid participating in an edit war, I decided to start up a discussion here. So, what do you guys think? Gfdgsgxgzgdrc 22:36, 27 October 2018 (UTC)

On most every Wiki, discussion is always required for major changes to these kinds of pages. I wouldn't call that change "simple" with a straight face. Also, since my edit summary got cut off, I should also mention that it was added - dare I say it? - well past the Wiki's height of activity. RickTommy (edits) 22:49, 27 October 2018 (UTC)

Considering how long the page is already, I wouldn't quite call it a major change. It only affects a small portion of the page. And yes, it was added past the wiki's height of activity. But - dare I say it? - why does that even matter? We can't just delete useful parts of the wiki just because it used to be more active. By that logic, we might as well delete the entire wiki. It still exists well past its height of activity. I still say we should keep that section. Gfdgsgxgzgdrc 04:12, 28 October 2018 (UTC)

This happened again, by the same user. I would advise that user to refrain from continuing the behavior. The section is 100% valid, 100% accurate, and 100% something that was missing from the page before now, and belongs there. Please, stop. — Defender1031*Talk 15:08, 6 November 2018 (UTC)

Again, do you guys agree of your own accord? Also, like I said, this is the kind of page that requires discussion for such additions. Besides, don't we already have something like that on another page? RickTommy (edits) 19:45, 6 November 2018 (UTC)

How are you confused on this point? Here is what has been said so far: "This helpful section" "should stay"; "the section is 100% valid" and "accurate"; it "was missing" and "belongs there." These are not ambiguous statements. There's no one-size-fits-all way to add content to a wiki. Sometimes it's good to have discussion; other times it's good to just be bold. Even in cases where it might have been better to discuss first, once the content is there, if it is judged to be good, there's no reason to remove it just because we didn't talk about it first, or just because it came from an anonymous source. Even if you think that's wrong and that a discussion is required, this thread has become a discussion after the fact, and the consensus is that it's good information. So stop removing it on procedural grounds. They have no merit.

As for your assertion that we might have something like this content elsewhere, that could be a discussion worth having. We don't want to duplicate information (or at the very least we want to have a good reason to do so), after all. But to have that discussion, you would actually need to link to where we already have it. Don't remove it outright from this page on some vague hunch. — It's dot com 20:29, 6 November 2018 (UTC)

[edit] Linking to disambiguations

The guideline is that disambiguations shouldn't be linked to, and for the most part, I agree. For example, Gary can refer to multiple characters, so the specific Gary should be linked to instead of the disambiguation. There are some disambiguations, however, that don't refer to separate things, but seperate versions of the same thing (mainly Homestar Runner 20th Anniversary Show). Some users, such as myself, think linking to this disambiguation is preferable to linking to both. Other users disagree, due to the reasoning that "disambiguations shouldn't be linked to", even though that rule doesn't make sense in this scenario. What should be the standard? Gfdgsgxgzgdrc 02:44, 22 January 2019 (UTC)

While I wouldn't say never, in general I think we should avoid linking to disambiguation pages if practical. The question whether your specific example should be an exception. I would lean toward no. That doesn't mean that there isn't a way to make this into one link. Perhaps the content could be combined into one page. Do we really need two? (I'm not intimately familiar with those pages so I'm actually asking.) If we really need two pages, perhaps a container article Homestar Runner 20th Anniversary Shows with a general write-up of the events could be made with links to the individual pages. Or we could just live with two links on whatever page is referring to this. — It's dot com 03:00, 22 January 2019 (UTC)

[edit] Disambiguation Links on Toon Pages

Should the {{about}} and {{for}} templates go below the toon category (Rap Song) or above it (Crazy Cartoon and Everybody to the Limit)? Gfdgsgxgzgdrc 03:21, 19 July 2019 (UTC)

Holy crap! That is a good question! This, I'm sure, is something that has not seriously been considered not the least because it should be fairly rare. Nevertheless, this is probably something that should go in the Standards once something has been decided. At least for the purpose of maintaining aesthetics. As for where it should go? I'm not sure, I have no clear preference. Both ways look fine to me. The only minor detail that might sway things one way or another might be that most users will expect the navigation buttons to remain near the top. Thus the Rap Song format might be preferable. --Stux 21:03, 1 August 2019 (UTC)

I personally prefer the disambiguation notice to be at the very top of the page. I like to see italics before bold, and I also like to check to make sure I'm looking at the right page before I dive in. But that's one anony's preference. -- 68.37.43.131 21:08, 1 August 2019 (UTC)

I slightly agree with one anonny's preference. For the reasons he stated, plus it's nice to have all the toon information together, and it doesn't break the spacing of image and navigation buttons. A disambiguation link seems like the sort of thing that should go at the very top of pages. Gfdgsgxgzgdrc 22:16, 5 August 2019 (UTC)

I too prefer to see it above. My reasons are similar, the wiki navigation is all before the toon info and navigation, and disambiguation is a form of wiki navigation (i.e. letting you know what page you're on in ambiguous cases and letting you navigate to the correct one if you're not). I think disambig absolutely belongs before toon nav. — Defender1031*Talk 22:21, 5 August 2019 (UTC)