HRWiki talk:Standards

From Homestar Runner Wiki

(Difference between revisions)

Current revision as of 04:16, 6 November 2022

Current | Archive 1 (1-20) | Archive 2 (21-40) | Archive 3 (41-60)

[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 (Talk) 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.

Gfdgsgxg zgdrc 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.

Gfdgsgxg zgdrc 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!

Gfdgsgxg zgdrc 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] `id`s

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"). Gfdgsgxg zgdrc 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. Gfdgsgxg zgdrc 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. Rick Tommy (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?

Gfdgsgxg zgdrc 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? Gfdgsgxg zgdrc 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. Gfdgsgxg zgdrc 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.

Gfdgsgxg zgdrc 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).

Gfdgsgxg zgdrc 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:

There was no discussion, even though that isn't necessary for a simple addition to the page.
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? Gfdgsgxg zgdrc 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. Rick Tommy (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.

Gfdgsgxg zgdrc 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? Rick Tommy (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? Gfdgsgxg zgdrc 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)? Gfdgsgxg zgdrc 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.

Gfdgsgxg zgdrc 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)

[edit] Interviews on defunct sites

As I clean up various pages on the site I'm finding that many cited interviews and links are dead and gone (especially since many are over a decade old now). For instance, the Strong Bad Email page prominently cites an OMG Nintendo blog interview - a site that went under in 2011, with none of its content currently hosted anywhere on the 'net. Typically with interview pages it seems that the wiki's practice is to only summarize the interview and link to it, unless express permission is granted from the original host/author. However it obviously becomes much harder to contact relevant parties if the site is dead as a doornail, and any contemporaneous info is often nonexistent or irrelevant.

Would it be considered kosher to mirror the text of an interview onto the wiki? Perhaps a rule of thumb (e.g. "if the site has been down for more than X years and there is no mirror") for archiving content? Or should it be left at linking to the archive.org version of the page? — Bleu Ninja 21:34, 27 September 2019 (UTC)

I think if it really is nowhere else (except archive.org, is that what you're saying?), then there's really no problem putting it here. Nobody involved in those old sites is likely to object, and if they did, we'd simply take it down. — It's dot com 22:14, 27 September 2019 (UTC)

Makes sense to me. (and yes, archive.org is the only remainder of that post) -- Bleu Ninja

22:26, 27 September 2019 (UTC)

[edit] Interview transcripts - should we correct spelling?

As I'm cleaning up older interview pages, I noticed inconsistent correction of interviewer's spelling, capitalization, grammar, etc.

For example, the wtfiml33t interview content warning on the original site read like this:

Stephan: State your name for the record please
Mike Chapman: Mike Chapman!!
Stephan: how long has homestarrunner.com been up
Mike Chapman: since January of 2000. A nice clean starting point.

In the l33t Interview article, the wiki cleans up punctuation and capitalization:

STEPHAN: State your name for the record, please.
MIKE CHAPMAN: Mike Chapman!
STEPHAN: How long has homestarrunner.com been up?
MIKE CHAPMAN: Since January of 2000. A nice clean starting point.

The Run Devil Run interview has a few typos (notably "Strongbad", but "cartoon network" is not capitalized elsewhere):

C>_Did you ever have any idea Strongbad would receive the level of popularity that he has?

In the article, only the "speaker's name in all-caps, bolded, followed by a colon" formatting is changed, the actual content is unedited:

NEUTRON: Did you ever have any idea Strongbad would receive the level of popularity that he has?

So which is correct? Perhaps we ought to add a disclaimer "the following interview has been edited for clarity" or "spelling and punctuation are presented as-is from the original article"/"[sic]". -- Bleu Ninja 16:27, 30 July 2021 (UTC)

Generally speaking, I think it's fine to edit interviews for clarity, especially if the original was a transcription of speech and the transcriber was sloppy about it. If the original was more written than spoken (I'm not sure how to describe this, or whether it even applies to any of these articles), then I would tend to leave those articles as is. I'm not a big fan of visible sics. — It's dot com 02:09, 31 July 2021 (UTC)

That makes sense. Generally I can't infer from a transcript if an interview was over phone/voice or text/email unless there are "(laughs)" or things like that. I tend to agree on [sic]s, they're best for comments rather than visible on the page. I think leaving them as-is is fine, then; unless it's becoming unreadable. -- Bleu Ninja

03:17, 31 July 2021 (UTC)

[edit] Standards for birth/death dates in costume explanations

A lot of the characters' Halloween Costumes are real people, and it can be a bit tricky determining what information is relevant enough to fit on the explainer pages. I've noticed inconsistency on whether or not birth and/or death dates and years are included when discussing real-life figures. For example:

Homestarloween Party Costumes

Flavor Flav: no dates (alive)
Kurt Cobain: no dates (deceased)
Carmen Miranda: birth and death years only
Gorbachev: birth date (alive)

Happy Hallow-day Costumes

Mario Batali: no dates (alive)
Frida Kahlo: birth and death dates
Queen Latifah: birth date (alive)

The House That Gave Sucky Tricks Costumes

David Lee Roth: no dates (alive)
André 3000: no dates (alive)
Chuck Barris: birth and death years only

There's not a noticeable trend to how these are treated, though it is somewhat more common for a person's description to include dates if they are deceased. In my opinion, for the purposes of this wiki it's better to simply reference the years/decades/era they were most well-known (e.g. Miranda performing from 1930s-50s, Gorbachev as head of state 1988-1991, Cobain as lead singer and guitarist of Nirvana 1987-1994) and simply indicate that a person is deceased by using past tense to describe them. -- Bleu Ninja 19:58, 2 March 2022 (UTC)

HRWiki talk:Standards

From Homestar Runner Wiki

Current revision as of 04:16, 6 November 2022

Contents

[edit] Tradition is not necessarily policy

[edit] Glitches

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

[edit] Raw characters vs HTML entities

[edit] mdash vs. ndash

[edit] Policy regarding Poker Night at the Inventory

[edit] Spaces

[edit] Tables

[edit] `id`s

[edit] Styles

[edit] Standards for gags/jokes

[edit] Running time standard wording

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

[edit] Retroactive names in transcripts

[edit] @StrongBadActual Dates

[edit] Basic Articles

[edit] Linking to disambiguations

[edit] Disambiguation Links on Toon Pages

[edit] Interviews on defunct sites

[edit] Interview transcripts - should we correct spelling?

[edit] Standards for birth/death dates in costume explanations

Views

Personal tools

Navigation

Search

Toolbox

External Links

@@ Line 1: / Line 1: @@
-== REALLY External Links? ==
+{{Standards Talk Archive}}
-I can't find anything about this in the user guide.. but you know in the external links section of writeups, and in other places, how it puts that icon after the link (a blue box with an arow coming out)? To me, that essentially says "The link will open up in a new window" as well as "The link goes offsite". I've seen many websites (including every website I've built.. [http://www.lightsecond.com lightsecond.com], [http://www.bend.com bend.com]) that have the convention that if the link goes offsite, it should do so in a new window. Can/should we do the same here?<BR>
-[[User:MetaStar|MetaStar]] 20:47, 25 Sep 2004 (MST)
-:I'm voting against it. Opening a link in a new window is almost pretentious, as if the site you are on should have the power to not let you leave. Modern browsers like Firefox will let you open a link in a new tab when you want to go elsewhere by middle-clicking your mouse, and users are used to doing that when they want to stay on the current site. Furthermore, Firefox by default doesn't open new window links in new tabs, which annoys me to no end.  I would say that an offsite link should behave like a normal link, so as not to confuse the user, and that opening a link in a new window should be a perogative of a web application that has a good reason for not taking you offsite.  An example of this would be Hotmail, which opens links in a new window to keep you logged in unless you explicity log out.  Most users of this site won't be logged in, and they'll be expecting the wiki to behave like like a normal website.  So I saw leave it the way it is, and let the user control where his links pop up.  If the icon is confusing, change the icon. [[User:Render|Render]]
+== Tradition is not necessarily policy ==
-What about if it's a logged-in-user user preference?  And of course this all pre-supposes that such fancies are possible in MediaWiki, which I dunno :)  Anyway I have yet to understand tabs since they always open underneath the current page.. they make me think of icky popunders. (Do you know of any good tabbed-browsing-for-dummies like faq on the 'net? I'd read that ;)<BR>
-[[User:MetaStar|MetaStar]] 22:21, 25 Sep 2004 (MST)
-:User-configurable preferences are always good. Any admins know if this is possible in MediaWiki without a major overhaul? (As for tabs, I suppose it's just one of those things that just sort of grows on you. I like the pop-under effect because it lets me open interesting links for deferred viewing while I continue reading the page I'm on.) [[User:Render|Render]]
-== Bold Punctuation? ==
+After a [http://www.hrwiki.org/index.php?title=fan_club&diff=573498&oldid=573494&rcid=531292 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:
-I like how this is coming along, Jones. One question, though: haven't we always placed the colon outside the bold tags, as in "'''THE CHEAT''':"? I guess I don't mind it either way, as long as we are adhering to a standard, but are there rules to this sort of thing? I remember being taught in school that punctuation should never be bold. --[[User:JoeyDay|JoeyDay]] 09:43, 21 Sep 2004 (MST)
+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.
-:Er, I thought we did it the other way around. And since the colon is part of the character "declaration" (rather than part of the dialogue), it seems more natural to have it bold as well. -- [[User:InterruptorJones|InterruptorJones]] 10:00, 21 Sep 2004 (MST)
+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. {{User:DeFender1031/sig}} 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? -[[Special:Contributions/132.183.138.199|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. {{User:DeFender1031/sig}} 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 [[Street Fighter|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. {{User:Wbwolf/sig}} 22:10, 21 January 2009 (UTC)
+::::''See also [[HRWiki talk:Standards/Archive 3#(Don't Fear) The Redirect|(Don't Fear) The Redirect]] above.''
-::Okay, I've been looking around the web (but [[User:Tom|Tom]] is better at Googling than I am) and I can't find anything about whether or not punctuation should be bold. I think it looks more consistent to have the colon in bold. I just wanted to be sure that was the right thing. Carry on. --[[User:JoeyDay|JoeyDay]] 10:26, 21 Sep 2004 (MST)
+== Glitches ==
-:::I've always bolded the colon. [[User:Hobophobic|<nowiki>~</nowiki>Hobo]]
-:Think about it the inverse way. What if you were being asked to bold the dialog instead of the character name? Would you then bold the colon as well? The colon would still have a space before the dialog started so that would look pretty silly: "THE CHEAT''': Meh!'''". so I think you should do with the colon what you do with the character name, not what you do with the dialog. :)
-:[[User:MetaStar|MetaStar]] 20:19, 25 Sep 2004 (MST)
-== Cast (in order of appearance) vs Featuring/Features ==
+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
+<blockquote>Similar to Goofs, but limited to mistakes in the Flash software.</blockquote>
+And I changed it to
+<blockquote>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.</blockquote>
+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. {{User:GreenHelmet/sig}} 04:38, 14 July 2008 (UTC)
-I was thinking, for pages for things like early Strong Bad Emails and anything else where only one character appears, it seems kind of redundant to add the "in order of appearance" part since only one character appears. For SBemail#1, I just put "Cast" but even this seems a bit improper as a cast is generally referring to "The actors in a play, movie, or other theatrical presentation," not just one actor. I thought "Featuring" or something like that would be more appropriate... I feel like I'm rambling. [[User:Hobophobic|<nowiki>~</nowiki>Hobo]]
+== May I copy these Standards to another wiki? ==
-:I guess I don't have an opinion on this one. Certainly "(in order of appearance) is superflouous for one-character toons, but beyond that I don't much care. Anybody else? -- [[User:InterruptorJones|InterruptorJones]] 11:41, 21 Sep 2004 (MST)
+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.).
-::To me, "Featuring" would make the most sense for one-character toons [[User:Hobophobic|<nowiki>~</nowiki>Hobo]]
+If you're interested, the wiki I'm working on (just created yesterday and still very much under construction) is [http://redgreen.wikia.com The Red Green Wiki].  If you're a fan of that show, I invite you to drop by and help out! :)
-:::Yeah, for a one character toon I like the word "Featuring". --[[User:JoeyDay|JoeyDay]] 12:55, 21 Sep 2004 (MST)
+Thanks guys. {{User:KieferSkunk/sig}} 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'! &mdash; [[User:It's dot com|It's dot com]] 01:52, 6 December 2008 (UTC)
-::::But what about the meaning of the word "featuring"?  Didn't [[cheatday]] feature The Cheat?  I'd think using that word for some emails and "cast" for others would be misleading.  Or at the very least, confusing.  I'm thinking that leaving off the "in order of appearance" for toons with only one character would work well enough.  --  [[User:Tom|Tom]] 14:24, 21 Sep 2004 (MST)
+::Cool!  Thanks. :) {{User:KieferSkunk/sig}} 02:10, 6 December 2008 (UTC)
-:I'm with Tom on this. Brevity good, "featuring" bad ;)  I know on albums and song titles they say "song, by Rapper, feat. other guys".. but it isn't feat. Rapper. I'm also selfishly hoping the word "featuring" can be ostricised for long enough to easily convert things.
-:A quick look at a thesaurus suggests to me we could say "Starring: Strong Bad" but I'd also listen to other bright idears
-:[[User:MetaStar|MetaStar]] 20:28, 25 Sep 2004 (MST)
-== SB email reference. ==
+== Raw characters vs HTML entities ==
-I have been using the following styles when referencing a Strong Bad Email depending on the context.
+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 [http://www.mediawiki.org/wiki/Release_notes/1.5 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&trade;... and I think I was one of the people pushing for it to stay that way.
-<pre>in the email "[[the facts]]"</pre>
+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&Atilde;&copy;", which is the usual fate for non-UTF-8-comprehending programs)... and while I can think of [[Wikipedia:Lynx (web browser)|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.
-<pre> in the Strong Bad Email: [[the facts]] </pre>
+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.
-<pre>==Complete Filmography==
+Now, I will make one exception to this... and that's dashes. It's much easier to tell the difference between <code>&amp;mdash;</code> and <code>&amp;ndash;</code> than &mdash; and &ndash; (especially in the fixed-width font used in the textarea in the edit screen, where they're more like <code>&mdash;</code> and <code>&ndash;</code>), so it's easier to keep them standardised as entities. Other symbols, like <code>&amp;trade;</code> and <code>&amp;frac12;</code> I'm on the fence about. But letters, especially in the middle of words, like <code>Comp&amp;eacute;</code>, I definitely think are better as raw Unicode characters.
-* Email: [[duck pond]]</pre>
-My goal is to make it clear that we are refering to the title of something.
+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.
-Otherwise one could get a sentance like,
-[[Pom Pom]] kicked [[Strong Bad]] in the head in [[pom pom (email) | Pom Pom]].
+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? {{User:Phlip/sig}} 10:28, 5 August 2009 (UTC)
+:Phlip and I discussed this yesterday. When I brought it up, I said, "<code>Comp&amp;eacute;</code> is really no better than straight-up <code>Compé</code>. 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 <code><nowiki>{{User:Heimstern Läufer/sig}}</nowiki></code>." 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. &mdash; [[User:It's dot com|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 "&eacute;". I will say that I'm likely to have trouble ''remembering'' how to type the "&eacute;" character without copy/pasting or using the HTML entity (I know what an acute accent is, so remembering "<code>&amp;eacute;</code>" 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. --{{User:Jay/sig}} 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 <code>&mdash;</code>, 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 --[[Special:Contributions/76.224.216.122|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. {{User:Soiled Bargains/sig}} 00:21, 30 September 2011 (UTC)
+===mdash vs. ndash===
+I would like to revisit this topic, specifically regarding <code>&amp;mdash;</code> and <code>&amp;ndash;</code>.  I understand the difficulty in telling these apart in text: I often run into that problem myself. And in many cases, <code>&amp;mdash;</code> 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 <code>&amp;mdash;</code> template {{t|-}} that should be easy to type, distinguishable from the regular dash, and still easy to read in text.  {{p|l=http://www.hrwiki.org/w/index.php?title=HRWiki:Sandbox&diff=735970&oldid=735489&rcid=698527 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? --[[User:Stux|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 {{t|-}} instead for lists. Still covers all the basic requirements discussed above. {{User:DeFender1031/sig}} 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 {{tl|-}}, we could create 3 or 4 templates (I checked wikipedia and they do something similar):
+::*<code>{{tl|-}}</code>: this template would be repurposed to place an <code>&amp;ndash;</code> in text.  Oddly enough wikipedia [[Wikipedia:Template:-|uses it]] as shorthand for the {{tl|clear}} template.
+::*<code>{{tl|--}}</code>: this would be the new <code>&amp;mdash;</code> in text.  This is the same as [[Wikipedia:Template:--|in wikipedia]].
+::*<code><nowiki>{{---}}</nowiki></code>: this could be used for wider dashes.  Wikipedia [[Wikipedia:Template:---|does something similar]].  However, there likely won't be a use for it here.
+::*<code><nowiki>{{----}}</nowiki></code>: This is actually used by [[Wikipedia:Template:----|wikipedia]] to insert four consecutive hyphen-minuses since the wiki code uses that for horizonal bars iirc.  Using <code><nowiki><</nowiki>nowiki<nowiki>></nowiki></code> 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 <code>&amp;mdash;</code> tags in the code and scrap the template.) --[[User:Stux|Stux]] 18:52, 25 February 2017 (UTC)
+:::Hi all, I finally went ahead with the plan I outlined above and created a {{tl|--}} template (for <code>&amp;mdash;</code>) and updated the {{tl|-}} template to yield an <code>&amp;ndash;</code>. I also updated all existing articles that used the original template ({{tl|-}}) so they would use the new one ({{tl|--}}).  I'm hoping these templates will find more use on the wiki.  Please let me know if there are any issues or questions. {{--}}[[User:Stux|Stux]] 03:07, 8 April 2018 (UTC)
+::::I don't understand the purpose of these templates. For one thing, we almost never use <code>&amp;ndash;</code> 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, {{t|--}} is only one character less than <code>&amp;mdash;</code>, 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 <code>&amp;mdash;</code>. 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 <code>&amp;mdash;</code>, 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. {{User:Gfdgsgxgzgdrc/sig‎}} 22:19, 27 October 2018 (UTC)
+:::::In my opinion, we should either use <code>&amp;mdash;</code> or just plain <code>—</code>. Preferably the former, since it doesn't require any copy/pasting or fancy typing. {{User:Gfdgsgxgzgdrc/sig‎}} 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? <code>&amp;mdash;</code> or <code>{{tl|--}}</code>? 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 {{p|l=http://hrwiki.org/w/index.php?title=Michael_Jackson&diff=776877&oldid=776876 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.  --[[User:Stux|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! {{User:Gfdgsgxgzgdrc/sig‎}} 18:52, 18 May 2019 (UTC)
-Not clear at all. Should this reference be standardized?
+== Policy regarding Poker Night at the Inventory ==
--[[User:Drhaggis|Drhaggis]] 11:47, 21 Sep 2004 (MST)
-:It wouldn't hurt to standardize it since I see all sorts of different usages all over. However, I tend to put the quotation marks inside the link like this: <nowiki>[[the facts|"the facts"]]</nowiki>, which yields [[the facts|"the facts"]]. Looks better to me, but I'd like to hear others' opinions. -- [[User:InterruptorJones|InterruptorJones]] 11:54, 21 Sep 2004 (MST)
+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? --{{User:DENNIS/sig}} 00:55, 4 September 2010 (UTC)
-::I don't think  having the leading "Strong Bad Email" is needed.  But that's me.  What about readers who don't know the emails?  But then, if we started putting "in the email, [[sibbie]]", would we also need to start using that for toons and shorts as well, as in "in the toon, [[Where's The Cheat?]]" and "in the short [[Experimental Film]]"?  Hmm.  I'd also like to hear some other' input.
+== Spaces ==
-::Though I do like having the Filmography listings standardized. Very good.  --  [[User:Tom|Tom]] 12:34, 21 Sep 2004 (MST)
-:::I will third the opinion that quotes should be around the title of a toon or email when it is being used in a sentence (as opposed to a bulleted list of related items such as that found on the SBEmail page). I'm not sure which I like better. Putting them outside the link would be easier on my poor typing finders, but putting them inside the link does look nicer. Just my two cents for what it's worth. Should we start a decision poll on the Forum? Not sure we need the leading "in the email, 'whatever'". I think we can just say, "in [[the facts|'the facts']]." As long as it's in quotes you know it's a toon or an email as opposed to it being a character as in Drhaggis' example. --[[User:JoeyDay|JoeyDay]] 12:41, 21 Sep 2004 (MST)
+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. {{User:Soiled Bargains/sig}} 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 &nbsp; 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. &mdash; [[User:It's dot com|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! {{User:Soiled Bargains/sig}} 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. &mdash; [[User:It's dot com|It's dot com]] 00:33, 17 December 2010 (UTC)
+::::See what I mean? {{User:Soiled Bargains/sig}} 01:09, 17 December 2010 (UTC)
-::For me, having the quotes in the brackets is unnecessary piping. We should also be adding quotes around unlinked toon titles. -[[User:Drhaggis|Drhaggis]] 15:02, 21 Sep 2004 (MST)
+== Tables ==
+=== <code>id</code>s ===
+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 <code>id</code> attributes all over the place. I decided to take it upon myself to create a format <code>id</code>s so that future table-based articles would validate and be less likely to conflict with other <code>id</code>s 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? {{User:Soiled Bargains/sig}} 19:58, 20 December 2010 (UTC)
+:It's dot com said we should just handle table <code>id</code>s 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 <code>.</code>, which will make it illegal anyway (like the section on [[Thorax Corporation]] [http://validator.w3.org/check?uri=http://www.hrwiki.org/w/index.php%3Ftitle%3DThorax_Corporation%26oldid%3D716746&charset=(detect+automatically)&doctype=Inline&group=0 that starts with 'Juwanna Mann']). {{User:Soiled Bargains/sig}} 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. &mdash; [[User:It's dot com|It's dot com]] 22:26, 23 January 2011 (UTC)
-== Since when do we not transcribe easter eggs? ==
+=== Styles ===
-I personally think easter eggs ''should'' be transcribed. We can't hardly bill ourselves as a definitive knowledge-base of all things Homestar if we don't have transcripts of the easter eggs. Yes, it would ruin the surprise, but so does everything else on our site! The whole reason for a transcript is for people to understand what the characters are saying. If I can't make out what Strong Sad is saying in some-such easter egg, I'd like to be able to find it on the site and read what other people think/know he's saying. --[[User:JoeyDay|JoeyDay]] 13:37, 22 Sep 2004 (MST)
+While I've said that tables are an inconsistent mess, they're also a stylistic inconsistent mess. I've given tables the <code>wikitable</code> 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 <code>hrwikitable</code> class instead? I'm just downright unsure. {{User:Soiled Bargains/sig}} 21:49, 23 January 2011 (UTC)
+:I don't think this is a pressing issue given the current rate of updates. &mdash; [[User:It's dot com|It's dot com]] 22:26, 23 January 2011 (UTC)
-:Okay, fair enough. So we need a standard for transcribing them. Any ideas? -- [[User:InterruptorJones|InterruptorJones]] 13:50, 22 Sep 2004 (MST)
+== 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? {{User:Soiled Bargains/sig}} 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? &mdash; [[User:It's dot com|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 {{p|l={{fullurl:Dan|diff=prev&oldid=602817}} Dan}}, {{p|l={{fullurl:Toilets|diff=prev&oldid=683823}} Toilets}}, and more recently {{p|l={{fullurl:Greg|diff=prev&oldid=634666}} 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 {{p|l={{fullurl:Greg|oldid=717246}} few}} (the show) {{p|l={{fullurl:Wrestleman|oldid=714414}} different}} (TGS10) {{p|l={{fullurl:Wrestleman|oldid=717167}} 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?
+::{{User:Soiled Bargains/sig}} 23:38, 23 January 2011 (UTC)
-::I liked having the short transcript under the bulleted item, but that does get bulky. Let me play around with some ideas and get back to you. --[[User:JoeyDay|JoeyDay]] 14:24, 22 Sep 2004 (MST)
+== Running time standard wording ==
-:::I took this claim against transcription of EE, was for cases when the egg would be detailed on another page. Such as in the case of a game, or the introduction of another characeter. -[[User:Drhaggis|Drhaggis]] 19:02, 22 Sep 2004 (MST)
+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? - {{User:Catjaz63/sig}} 23:14, 3 December 2015 (UTC)
+:There seem to be a few precedents, based on [[Special:Whatlinkshere/TV Time Toons Menu]]:
+:*[[Cheat Commandos (toon)]], [[Trogdor Con '97|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 "#:## [[TV Time Toons Menu|official]], #:## actual", as did [[Which Ween Costumes?]] before it was edited yesterday.
+:*The [[The House that Gave Sucky Treats|three]] [[3 Times Halloween Funjob|Halloween]] [[Halloween Potion-ma-jig|toons]] with [[:Category:Toons with Dialogue Alternatives|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 "[[TV Time Toons Menu|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. {{User:Mee/sig}} 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 "[[TV Time Toons Menu|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* --[[User:Stux|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. {{User:Mee/sig}} 21:48, 4 December 2015 (UTC)
-::::I thought we always did transcribe them.  And the unwritten rule has always been this: If the egg is "clickable", that is, the user has to do something to cause the egg, it goes in the "Easter Egg" section.  If the egg does not require any action on the part of the user, besides them just sitting in front of their computer a little longer, it goes in the Transcript.  I'm pretty sure that's what everybody does anyway, but I just want to make it clear.  --  [[User:Tom|Tom]] 19:08, 22 Sep 2004 (MST)
+== Linking to articles with disambiguation in the page title ==
-::What about creating subheadings (i.e. <tt><nowiki>===cheatsa===</nowiki></tt>) before each easter egg transcript in the Easter Eggs section? That would make things clearer. (I'm thinking something like:)
+{{p|l=http://hrwiki.org/w/index.php?title=Jurvy-Skat&curid=18745&diff=777714&oldid=777337&rcid=740575 This edit}} raises a question: How should "Toon Name (video)" pages (like [[Sketchbook (video)]] and [[Trogdor!! The Board Game (video)]]) be listed in pages? "[[Toons|Toon Name (video)]]", or "[[Toons|Toon Name]] Video"?
-<pre>
+I don't really have an opinion (possibly leaning ''slightly'' toward "[[Toons|Toon Name]] Video"). {{User:Gfdgsgxgzgdrc/sig‎}} 07:04, 17 August 2018 (UTC)
-===Homestar===
+:I kind of agree.  The parens are just internal to the wiki to distinguish pages. -[[Special:Contributions/174.62.238.201|174.62.238.201]] 12:53, 17 August 2018 (UTC)
-'''Click on the word "Homestar" to see Homestar crying.'''
+::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. &mdash; [[User:It's dot com|It's dot com]] 14:43, 17 August 2018 (UTC)
-''{Homestar is still bawling.}''
+== Retroactive names in transcripts ==
+{{p|l=http://hrwiki.org/w/index.php?title=Peasant%27s_Quest_Preview&curid=890&diff=777715&oldid=777710&rcid=740576 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?
-'''HOMESTAR''': Ohh, Tenderfoot! Can you tell me what to do
+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. {{User:Gfdgsgxgzgdrc/sig‎}} 07:04, 17 August 2018 (UTC)
-with myself? I feel like I'm at a crossroads, and there's like,
+:Note that [that edit] was reverted. -[[Special:Contributions/174.62.238.201|174.62.238.201]] 12:53, 17 August 2018 (UTC)
-a Denny's on one corner, and an IHOP on the other!
+::By an Anonny whose only edit has been that revert, no less. {{User:RickTommy/sig}} 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. &mdash; [[User:It's dot com|It's dot com]] 14:45, 17 August 2018 (UTC)
+::::{{p|l={{FULLURL:bottom 10|diff=788636&oldid=788633}} Another edit was made}} regarding retroactive names. Does anyone else have an opinion? {{User:Gfdgsgxgzgdrc/sig‎}} 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. &mdash; [[User:It's dot com|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. {{User:DeFender1031/sig}} 01:30, 1 January 2020 (UTC)
-''{Homestar is kneeling over the Tenderfoot drawing.}''
+== @StrongBadActual Dates ==
-'''HOMESTAR''': Can you give me some sound financial advice?
+Long ago, it was [[HRWiki:Main Page Talk Archive 46#Dating @Strongbadactual references|decided]] that the format of Tweets in lists should be "[[@StrongBadActual]] &mdash; January 1, 1970". {{p|l=http://hrwiki.org/w/index.php?title=Trains&curid=58342&diff=779281&oldid=779197&rcid=742149 Recently}}, {{p|l=http://hrwiki.org/w/index.php?title=Gumption&curid=58349&diff=779284&oldid=779267&rcid=742152 however}}, it seems to no longer be the case. So, how should Tweets be listed? {{User:Gfdgsgxgzgdrc/sig‎}} 19:55, 5 October 2018 (UTC)
+:What all are the choices and what would be your preference? &mdash; [[User:It's dot com|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.<br>
+Also, the old version lacked a link to the Tweet's wiki section, so I added them in each choice.
+*[[@StrongBadActual]] &mdash; [[@StrongBadActual Tweets 2018#949767712670089217|January 6, 2018]] &mdash; The old version.
+*[[@StrongBadActual]] Tweet from [[@StrongBadActual Tweets 2018#949767712670089217|January 6, 2018]] &mdash; A sentence.
+*Tweet from [[@StrongBadActual]] on [[@StrongBadActual Tweets 2018#949767712670089217|January 6, 2018]] &mdash; A longer sentence.
+*[[@StrongBadActual]] ([[@StrongBadActual Tweets 2018#949767712670089217|6 January 2018]]) &mdash; With parentheses instead of an em dash.
+*[[@StrongBadActual]] &#91;[[@StrongBadActual Tweets 2018#949767712670089217|6 January 2018]]&#93; &mdash; With brackets instead of an em dash.
+*[[@StrongBadActual]]: [[@StrongBadActual Tweets 2018#949767712670089217|6 Jan 2018]] &mdash; 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. {{User:Gfdgsgxgzgdrc/sig‎}} 22:38, 5 October 2018 (UTC)
+:I support the parentheses format, with <s>either</s> 6 Jan 2018 <s>or Jan 6 2018</s>. {{User:SRMX12/sig}} 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. &mdash; [[User:It's dot com|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. {{User:Gfdgsgxgzgdrc/sig‎}} 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)|@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. --[[User:Stux|Stux]] 21:50, 6 October 2018 (UTC)
+:::::Changing my vote again. [[@StrongBadActual]] Tweet ([[@StrongBadActual Tweets 2018#949767712670089217|6 Jan 2018]]) and [[@strongbadactual (Instagram)|@strongbadactual]] Instagram post ([[@StrongBadActual Tweets 2018#949767712670089217|6 Jan 2018]]). {{User:Gfdgsgxgzgdrc/sig‎}} 22:18, 6 October 2018 (UTC)
-''{Homestar is laying on the ground again.}''
+== Basic Articles ==
-'''HOMESTAR''': Tenderfoot, can you help advise me on my future?
+This helpful section was added to the page, and reverted twice (by the same user) because:
-</pre>
+#{{p|l=http://hrwiki.org/w/index.php?title=HRWiki:Standards&curid=1892&diff=779794&oldid=779793&rcid=742661 There was no discussion}}, even though that isn't necessary for a simple addition to the page.
+#{{p|l=http://hrwiki.org/w/index.php?title=HRWiki:Standards&curid=1892&diff=779799&oldid=779798&rcid=742666 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? {{User:Gfdgsgxgzgdrc/sig‎}} 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. {{User:RickTommy/sig}} 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. {{User:Gfdgsgxgzgdrc/sig‎}} 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. {{User:DeFender1031/sig}} 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? {{User:RickTommy/sig}} 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. &mdash; [[User:It's dot com|It's dot com]] 20:29, 6 November 2018 (UTC)
-Anybody with me? --[[User:oddtodd|oddtodd]] 11:17, 20 Nov 2004 (MST)
+== Linking to disambiguations ==
-== Format for Lyrics ==
+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? {{User:Gfdgsgxgzgdrc/sig‎}} 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. &mdash; [[User:It's dot com|It's dot com]] 03:00, 22 January 2019 (UTC)
-Song lyrics are inconsistently styled throughout the site.  I propose that we embed lyrics in &lt;pre&gt; tags, so that they show up inside of a box the same way that the transcribed text of the Strong Bad emails do. Thoughts? [[User:Render|Render]]
+== Disambiguation Links on Toon Pages ==
-:Seconded. --[[User:Upsilon|Upsilon]]
-== Forward references ==
+Should the {{t|about}} and {{t|for}} templates go below the toon category ([[Rap Song]]) or above it ([[Crazy Cartoon]] and [[Everybody to the Limit]])? {{User:Gfdgsgxgzgdrc/sig‎}} 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. --[[User:Stux|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. -- [[Special:Contributions/68.37.43.131|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. {{User:Gfdgsgxgzgdrc/sig‎}} 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. {{User:DeFender1031/sig}} 22:21, 5 August 2019 (UTC)
-[[dragon]] has a link to [[guitar]].  Should [[guitar]] have a link to [[dragon]]?
+== Interviews on defunct sites ==
-:Chronology on the official site shouldn't affect what can link to what in the wiki.  If a link to a future email is interesting and relevant, I don't see why it shouldn't be included. [[User:Render|Render]]
-== Category pages ==
+As I [[HRWiki:WikiGnome|clean up]] various pages on the site I'm finding that many cited interviews and links are dead and gone (especially since many are over a decade old now). For instance, the [[Strong Bad Email]] page prominently cites [https://web.archive.org/web/20090517084725/http://omgnintendo.blogfaction.com/article/108144/one-year-of-wiiware-matt-and-mike-chapman-on-strong-bads-cool-game-for-attractive-people/ an OMG Nintendo blog interview] - a site that went under in 2011, with none of its content currently hosted anywhere on the 'net. Typically with [[Interviews and Public Appearances|interview pages]] it seems that the wiki's practice is to only summarize the interview and link to it, unless express permission is granted from the original host/author. However it obviously becomes much harder to contact relevant parties if the site is dead as a doornail, and any contemporaneous info is often nonexistent or irrelevant.
-Currently Category pages, such as [[:Category:Strong Bad Email]] or [[:Category:1936]] only contain text such as "These articles are all Strong Bad Emails.", and all the substance on that topic is contained in a separate page.  Would it make more sense to move all of the substance to the Category page, and turn the actual [[Strong Bad Email]] or [[1936]] page into a mere redirect to the Category?  Once and Only Once etc, since it would also provide the listing of everything in the Category underneath. -- [[User:thejesterx|thejesterx]] 21:47, 6 Oct 2004 (MST)
+Would it be considered kosher to mirror the text of an interview onto the wiki? Perhaps a rule of thumb (e.g. "if the site has been down for more than X years ''and'' there is no mirror") for archiving content? Or should it be left at linking to the archive.org version of the page? —{{User:Bleu Ninja/sig}} 21:34, 27 September 2019 (UTC)
+:I think if it really is ''nowhere'' else (except archive.org, is that what you're saying?), then there's really no problem putting it here. Nobody involved in those old sites is likely to object, and if they did, we'd simply take it down. &mdash; [[User:It's dot com|It's dot com]] 22:14, 27 September 2019 (UTC)
+::Makes sense to me. (and yes, archive.org is the only remainder of that post) --{{User:Bleu Ninja/sig}} 22:26, 27 September 2019 (UTC)
-:No, I don't think so. The Strong Bad Email page has a lot of information that wouldn't fit in the category page, and it's a lot easier to link to a regular page (<nowiki>[[Strong Bad Email]] vs. [[:Category:Strong Bad Email|Strong Bad Email]]) than a category. Categories should just be categories, not articles. ~~~
+== Interview transcripts - should we correct spelling? ==
-</nowiki>
+As I'm cleaning up older interview pages, I noticed inconsistent correction of interviewer's spelling, capitalization, grammar, etc.
-== Character pictures ==
+For example, [https://web.archive.org/web/20020623163502/http://www.wtfiml33t.com/viewarticle.php?artid=59&page=1 the wtfiml33t interview] {{inlinecontentwarning}} on the original site read like this:
-Now we use thumbnails for toon screenshots - should we do the same for character images? I assume we should, but I thought I'd better verify since it's not made clear anywhere. --[[User:Upsilon|Upsilon]]
+<blockquote>'''Stephan:''' State your name for the record please<br>
-:'''EDIT:''' According to the projects page (drawn to my attention by [[User:spblat|spblat]]), "we need to comb the entire wiki changing full-sized images to thumbnails". This pretty much answers my question. --[[User:Upsilon|Upsilon]]
+'''Mike Chapman:''' Mike Chapman!!<br>
+'''Stephan:''' how long has homestarrunner.com been up<br>
+'''Mike Chapman:''' since January of 2000. A nice clean starting point.</blockquote>
-== Easter Egg Transcribing Part 2 ==
+In the [[l33t Interview]] article, the wiki cleans up punctuation and capitalization:
-OK, since I've heard conflicting ideas on the wiki on whether or not Easter Eggs should be transcribed or not, can we finally get some sort of official, definitive yes/no on this? There's both the discussion on this page, the actual Standards page itself, and the discussion page for [[extra plug]] to take into consideration as to my confusion concerning it. I'm asking about this since, while I took the conversation on this page and in [[extra plug]] to mean Easter Eggs are expected to be transcribed now, some Easter Egg transcriptions are now being removed (see, for example, [[Where the Crap Are We?]].) --[[User:TheNintenGenius|TheNintenGenius]] 12:00, 18 Oct 2004 (MST)
+<blockquote>'''STEPHAN:''' State your name for the record, please.<br>
-:This site aims to preserve so much other minutiae about Homestar Runner that I can’t imagine where the policy to not transcribe easter eggs came from.  Are we trying to reduce spoilers?  In that case, all of the transcripts are also inappropriate.  I say we transcribe eggs in the easter eggs section where they are clearly marked and can be skipped by those who want to discover them on their own. [[User:Render|Render]]
+'''MIKE CHAPMAN:''' Mike Chapman!<br>
+'''STEPHAN:''' How long has homestarrunner.com been up?<br>
+'''MIKE CHAPMAN:''' Since January of 2000. A nice clean starting point.</blockquote>
-:I was the one who deleted the Where the Crap Are We? egg transcript. I've probably removed a couple of others as well, because I wasn't aware that we ''should'' be transcribing eggs. Sorry about that. (I assume we ''are'' now giving egg transcripts?) --[[User:Upsilon|Upsilon]]
+The [https://web.archive.org/web/20030130071113/http://rundevilrun.com/ezine/interviews/hsrunner/ Run Devil Run] interview has a few typos (notably "Strongbad", but "cartoon network" is not capitalized elsewhere):
-::Yes, we are now transcribing easter eggs. I believe I caused the confusion. Sorry 'bout that. [[User:InterruptorJones|<nowiki></nowiki>]]<small>&mdash;&nbsp;[[User:InterruptorJones|InterruptorJones]]</small>[[<nowiki></nowiki>]]
+<blockquote>C>_Did you ever have any idea Strongbad would receive the level of popularity that he has?</blockquote>
-::FYI: In the other "Easter Egg Transcribing" section, I proposed a format to transcribe easter eggs with in order to reduce clutter. --[[User:oddtodd|oddtodd]] 11:21, 20 Nov 2004 (MST)
+In [[Run Devil Run Interview|the article]], only the "speaker's name in all-caps, bolded, followed by a colon" formatting is changed, the actual content is unedited:
-== Thumbnails vs full-size images? ==
+<blockquote>'''NEUTRON:''' Did you ever have any idea Strongbad would receive the level of popularity that he has?</blockquote>
-I read [[HRWiki:Projects|here]] that we should be focused on using thumbnails instead of full size images.  I've been doing this on some, but I don't want to go nuts before I know I'm not messing things up.  Are there any cases where full size screenshots [[Homsar Main Page|(like this)]] should be preserved?  -- [[User:spblat|spblat]] 7:13 PM 23 Oct 2004 (later) foo. Answered my own question. looks like full speed ahead--the standards page is quite clear on this.
+So which is correct? Perhaps we ought to add a disclaimer "the following interview has been edited for clarity" or "spelling and punctuation are presented as-is from the original article"/"[sic]". --{{User:Bleu Ninja/sig}} 16:27, 30 July 2021 (UTC)
+:Generally speaking, I think it's fine to {{p|l=http://www.hrwiki.org/w/index.php?title=Stinkoman_20X6_Level_10&diff=prev&oldid=792027 edit interviews for clarity}}, especially if the original was a transcription of speech and the transcriber was sloppy about it. If the original was more written than spoken (I'm not sure how to describe this, or whether it even applies to any of these articles), then I would tend to leave those articles as is. I'm not a big fan of visible ''sic''s. &mdash; [[User:It's dot com|It's dot com]] 02:09, 31 July 2021 (UTC)
+::That makes sense. Generally I can't infer from a transcript if an interview was over phone/voice or text/email unless there are "(laughs)" or things like that. I tend to agree on [sic]s, they're best for comments<!-- like this --> rather than visible on the page. I think leaving them as-is is fine, then; unless it's becoming unreadable. --{{User:Bleu Ninja/sig}} 03:17, 31 July 2021 (UTC)
+== Standards for birth/death dates in costume explanations ==
+A lot of the characters' [[Halloween Costumes]] are real people, and it can be a bit tricky determining what information is relevant enough to fit on the explainer pages. I've noticed inconsistency on whether or not birth and/or death dates and years are included when discussing real-life figures. For example:
+[[Homestarloween Party Costumes]]
+* Flavor Flav: no dates (alive)
+* Kurt Cobain: no dates (deceased)
+* Carmen Miranda: birth and death years only
+* Gorbachev: birth date (alive)
+[[Happy Hallow-day Costumes]]
+* Mario Batali: no dates (alive)
+* Frida Kahlo: birth and death dates
+* Queen Latifah: birth date (alive)
+[[The House That Gave Sucky Tricks Costumes]]
+* David Lee Roth: no dates (alive)
+* André 3000: no dates (alive)
+* Chuck Barris: birth and death years only
+There's not a noticeable trend to how these are treated, though it is somewhat more common for a person's description to include dates if they are deceased. In my opinion, for the purposes of this wiki it's better to simply reference the years/decades/era they were most well-known (e.g. Miranda performing from 1930s-50s, Gorbachev as head of state 1988-1991, Cobain as lead singer and guitarist of Nirvana 1987-1994) and simply indicate that a person is deceased by using past tense to describe them. --{{User:Bleu Ninja/sig}} 19:58, 2 March 2022 (UTC)

HRWiki talk:Standards

From Homestar Runner Wiki

Current revision as of 04:16, 6 November 2022

Contents

[edit] Tradition is not necessarily policy

[edit] Glitches

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

[edit] Raw characters vs HTML entities

[edit] mdash vs. ndash

[edit] Policy regarding Poker Night at the Inventory

[edit] Spaces

[edit] Tables

[edit] ids

[edit] Styles

[edit] Standards for gags/jokes

[edit] Running time standard wording

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

[edit] Retroactive names in transcripts

[edit] @StrongBadActual Dates

[edit] Basic Articles

[edit] Linking to disambiguations

[edit] Disambiguation Links on Toon Pages

[edit] Interviews on defunct sites

[edit] Interview transcripts - should we correct spelling?

[edit] Standards for birth/death dates in costume explanations

Views

Personal tools

Navigation

Search

Toolbox

External Links

[edit] `id`s