HRWiki talk:Standards

From Homestar Runner Wiki

(Difference between revisions)
Jump to: navigation, search
(Raw characters vs HTML entities)
(Raw characters vs HTML entities: Reply.)
Line 353: Line 353:
: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)
: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)
::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)

Revision as of 18:07, 7 August 2009

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


Contents

Suggestion for transcripts

How about in transcripts Homestar Runner is just referred to as Homestar after the first mention like so:

HOMESTAR RUNNER: I wike mushmallows.

STRONG BAD: I like Cold Ones.

HOMESTAR: Yeah, dat's weawwy gweat.

Darth Katana X (discussionitem_icon.gif user.gif mail_icon.gif) 14:24, 26 April 2007 (UTC)

Hm, that's not a bad suggestion. It's probably okay either way — just depends on whether people prefer the historical, slightly bulkier way of doing it. I don't really have a preference, personally. Trey56 14:28, 26 April 2007 (UTC)
Sounds good to me. —BazookaJoe 18:31, 26 April 2007 (UTC)
I like the idea! Of course I'd like to also hear it from Dot com's publishing perspective. --Stux 18:34, 26 April 2007 (UTC)
Maybe we should see a few representative test pages. Given how many pages would need to be edited, we need to figure out how much of a benefit it would provide, if any. — It's dot com 18:08, 29 October 2007 (UTC)

I see this working best on origins (Don't ask my why, pumpernickel and wye), Decemberween Short Shorts (If you lewn to say wouds wide!), and Marshie vs. Little Girl (Wait a minute you'we a little giwl! I thought you was a little ghoul.). My spelling of impediments could probably be better. Bad Bad Guy 14:53, 28 October 2007 (UTC)

I'm strongly opposed. It's very hard to read for non-native speakers. Depending on their skill level, it can be impossible. It would also make it much harder to search for a certain phrase. "That's very great" is easy to search for, while "Dat's weawwy gweat" is hard to search for because there is no set spelling and it depends on how the individual person actually hears him say it. Loafing 19:20, 29 October 2007 (UTC)
Hold on, here. I don't think this thread is even talking about the same thing anymore. Unless I'm reading it wrong, Darth did not suggest writing Homestar's words as they're pronounced; rather, he suggested we not write HOMESTAR RUNNER each time he appears in a transcript. Heimstern Läufer 19:26, 29 October 2007 (UTC)
Yep, you're correct. Trey56 19:29, 29 October 2007 (UTC)
Oops! That's actually a good idea, I think ;-) Loafing 19:28, 29 October 2007 (UTC)

Hmm, either way we decide, I don't think it's worth the effort of going through every single past transcript and changing them. I'd be okay if we decide to switch for future articles though (and I don't think the inconsistency would be problematic). Trey56 19:39, 29 October 2007 (UTC)

Well, I could always have The Cheatbot do it. Still, I'm not sure it would be enough of an improvement to change our standards over, which it why I'd want to see some samples first. — It's dot com 19:45, 29 October 2007 (UTC)

Standards for Real-World References

Recently, there have been removals of Real-World References because the reference in question was not made by TBC, but instead the sender of a Strong Bad Email. This has been done with island ([1]), extra plug, and underlings ([2]). Currently, there are no official standards regarding this issue.

I believe that references such as these should be noted in the Fun Facts. I'm not saying they must be in Real-World References (although it wouldn't hurt). They could just as easily fit in Trivia or even Remarks. They should be included somewhere, because they point out things that the viewer may not be aware of, which is the entire purpose of all Fun Facts. I was not aware that Yami Yugi was an allusion to Yu-Gi-Oh until I read it on the Wiki, and I didn't know the significance of PlasticDiverGuy's name until I did some serious Googling. Why should we keep a reference from being on the page just because TBC didn't think it up? Has Matt? (talk) 23:24, 9 May 2007 (UTC)

Yes, It makes sense that such references be explained as well. We must keep in mind that even though TBC didn't think it up, they did choose the email out of hundreds maybe even thousands they receive. And more often than not, there is a purpose behind that choice and so background information would be necessary. --Stux 23:57, 9 May 2007 (UTC)
I'm all for including them if they are cryptic and relevant (such as explaining the sender's name). I'm strongly against listing them as RWRs. Only references by TBC should be listed as such. These facts should be added under "Remarks". Loafing 02:18, 10 May 2007 (UTC)
I agree with Loafing. While they are not TBC's references, they could be included in Remarks if they require explanation. As I'm probably the user who removed those facts, my reasoning is that we are documenting TBC's work, not the work of the contributors. However, I can see a purpose in explaining thru a Remark the relevance of a particular sender's name or other allusion within the body of the email. I'd like to see RWR and the like reserved to references made by TBC. Qermaq - (T/C) Image:Qermaqsigpic.png 02:37, 10 May 2007 (UTC)
I felt I should bring up one of the older, yet more extreme cases of this. This one wasn't as direct a reference, but eventually went to STUFF (the old STUFF), and the discussion was revived a year later. It might be worth looking into. Talk:monster truck#Get Back Loretta! (DECLINED) is the section to look at. --DorianGray 18:24, 17 May 2007 (UTC)
I realize that it's a bit late to be adding to this discussion, but it seemed like the best place to do it. Directly relating to the line of conversation, I'd argue that TBC do sometimes edit emails, and not use them verbatim. As Stux pointed out, they do also choose to use the email, and are thus making a decision to present its contents to their viewership. As a result, it is not generally possible to distinguish exactly what content is written by TBC, and what is contributed from other sources. Therefore, the line is a bit fuzzy, and even if the rule is that references made by the sender should not be listed under real-world references, it's difficult to determine which category any particular reference falls under. In this case, my personal opinion is that we should be lenient in excluding RWRs on the basis that they were from the sender, and not TBC.
As for my tangential discussion: Considering all the furor over RWRs in recent emails, most particularly web comics, I think we need a more formal definition of what a "reference" is. Going off just the word alone, I would think that the referrer would have to indicate in some way what it was referring to. Similarity isn't enough. An instance of something can be exactly like something that previously existed, and yet not be a reference. To put it simply, what is the difference between a reference and a coincidence? TTATOT helps, but doesn't address the fundamental difference. TTATOT just distinguishes between a specific reference and an abstract reference. I think a formal definition, or at least discussion, would help clarify things for users of the wiki, and reduce the number of invalid real-world references proposed. It might help resolve some of the long-standing STUFF debates too. -- LGC&CS 23:42, 10 October 2007 (UTC)
I think it would probably be more useful and more accurate to say that TTATOT distinguishes between a specific reference and a general reference, rather than an abstract one. -invisible_map

Linking titles of toons only once

So, right now our policy is to link to any other article only once within a given page. However, this creates the question, "How do we make toons and emails stand out from the surrounding text when they have already been linked to once?" There are a few options:

  1. Link the name of a toon every time it appears (e.g., "Strong Bad appeared in the email underlings. underlings was also the first email to...")
  2. Underline the name of a toon after it has been linked once (e.g., "Strong Bad appeared in the email underlings. underlings was also the first email to...")
  3. Italicize the name of a toon after it has been linked once (e.g., "Strong Bad appeared in the email underlings. underlings was also the first email to...")
  4. Leave the name of a toon unformatted after it has been linked once (e.g., "Strong Bad appeared in the email underlings. underlings was also the first email to...")

Although I think #4 is our default option, I think it is the worst one. Especially for the titles of SBEmails, the title doesn't stand out from the text very well. My top choice is #1: with this option, the title of a sbemail looks exactly the same every time, and if a person is reading the second appearance of that title, they don't have to search for the first appearance to find the link to go to that page.

Do other people agree with this? If so, we would need to adjust our linking once policy and update some articles accordingly. Also, I imagine that this principle would apply to the titles of games, etc. Trey56 16:42, 5 June 2007 (UTC)

I kinda like Wikipedia's policy on the matter:
An article may be considered overlinked if any of the following is true:
...
  • A link for any single term is excessively repeated in the same article, as in the example of overlinking which follows: "Excessive" is more than once for the same term, in a line or a paragraph, because in this case one or more duplicate links will almost certainly then appear needlessly on the viewer's screen. Remember, the purpose of links is to direct the reader to a new spot at the point(s) where the reader is most likely to take a temporary detour due to needing more information;
  • However, note that duplicating an important link distant from a previous occurrence in an article, may well be appropriate ... Good places for link duplication are often the first time the term occurs in each article subsection.
I think linking every single time would be too much. It would probably be too distracting for the reader. But I think linking once in each section of the article is a good compromise. That way, the screen wouldn't be cluttered with a bunch of unnecessary links, and people wouldn't have to search very far to find a link. And about making the title stand out, there's another possibility you haven't thought of: quotation marks. I know we've been avoiding them for a while, but they aren't that bad, really:
Strong Bad appeared in the email "underlings". "underlings" was also the first email to...
It's more subtle than a link, but it still makes it stand out from the text. Has Matt? (talk) 17:18, 5 June 2007 (UTC)
That's a helpful page you linked to. Unlike WP, we use links to make the titles stand out in addition to provide a route to their articles. But you bring up a good point about excessive linking nonetheless.
If we didn't link a toon title every time, I would be a proponent of underlining rather than using quotation marks. Underlining makes the titles look consistent to their linked appearance (the only difference being the color). Also, TBC do this (see for example here). Finally, on a very subjective level, quotes look a little less professional to me. Trey56 17:37, 5 June 2007 (UTC)
Links are underlined for you here? Not for me. That would seem awkward. I propose using context to solve this issue - if the name of the link alone yields unclear context, then use a qualifying term, such as in "There are several instances of fire in the email pom pom." But I don't see why any adornement is necessary. Qermaq - (T/C) Image:Qermaqsigpic.png 00:10, 8 June 2007 (UTC)
I don't think the example above is a fair one, because the sentence could easily be recast to avoid the double link (and in the process would read better, too): "Strong Bad appeared in the email underlings, which was also the first email to..." Aside from that, I don't have a problem with linking every toon title. In a sense, the link is the punctuation. I strongly disagree with putting quotation marks around them, simply because we've made it this far with relatively no confusion, so there's no need to fix something that isn't broken. On a related note, I think the line where it reads "duplicating an important link distant from a previous occurrence in an article, may well be appropriate" is something we should practice for non-toon links (for example, links to characters), unless there is an established and consistent place where the reader can learn to find them (like the cast and places lists on toon articles). — It's dot com 16:52, 8 June 2007 (UTC)

Gags section

This discussion was originally located at Talk:Single Episode Running Gags. See this sample of what a gags section could look like within in an article.

{after some discussion of a page documenting running gags within single toons}

I have an idea! I think we should do something totally different, we should put a new categorie in the toon that has the gag and call it Gags. :It could be placed right above fast forward and it would make everybody happy! We would just put what ever gag that the toon has under there, and we could put whatever running gag it has there. I hope this works, because i'm out of ideas. --Kanjiro talk 22:54, 23 July 2007 (UTC)
When someone gives me the okay, i'm going to start work on it.--Kanjiro talk 23:16, 23 July 2007 (UTC)
It's a wiki, you can edit any article always. If you can make it work, then by all means, do. --TotalSpaceshipGirl3 01:03, 24 July 2007 (UTC)

{after more discussion of the original topic}

So should i do the gag thing or not?--Kanjiro talk 03:26, 24 July 2007 (UTC)
Use your judgement. Qermaq - (T/C) Image:Qermaqsigpic.png 03:36, 24 July 2007 (UTC)
It is done. I'm not sure if you guys want to keep it or not, maybe STUFF it, i dunnno. Check out this.--Kanjiro talk 04:11, 24 July 2007 (UTC)
Do you guys likes it? I haven't gotten any feedback yet, so I'm going to start putting it on more pages.--Kanjiro talk 19:14, 24 July 2007 (UTC)
Yes, I LOVE IT! I knew there was some kind of a compromise. I'ma join in.Super!SantanaDuper!
I think "Gags" should be just before "Inside References", though. DEI DAT VMdatvm center\super contra 20:08, 24 July 2007 (UTC)
Ok, were going to do it, but i need some help, we are going to have to do every toon, email, and anything with gags in it, i'll take emails, santanahomerunner, you take toons, and get more people to help, this is going to be big.--Kanjiro talk 20:14, 24 July 2007 (UTC)
Ready? BREAK! Super!SantanaDuper!

SantanaHomerunner 20:24, 24 July 2007 (UTC)

Halt production on gags, we must discuss it more.--Kanjiro talk 20:40, 24 July 2007 (UTC)
I Have an Idea, lets ask joey day if he likes the idea, i mean he created the wiki, so he should know whats best.--Kanjiro talk 20:56, 24 July 2007 (UTC)
Joey would be the first to tell you that, in cases like this, the consensus of all the editors is what counts, not one person's opinion. — It's dot com 21:01, 24 July 2007 (UTC)
A "Gags" section would be highly unnecessary. Why have a whole section for something that's A) obvious while you watch it, and 2) would only have one item underneath it? --DorianGray 21:06, 24 July 2007 (UTC)
It woulden't have one item underneath it, it would have all of the running gags the toon has in it, it might have one if the toon has one running gag in it.--Kanjiro talk 21:09, 24 July 2007 (UTC)
Which would more than likely be only one, given how the "Single Toon Gags" page was set up. Unless you're proposing to break up what we already have established as Inside References. --DorianGray 21:31, 24 July 2007 (UTC)

Personally, I think that the section would be against our policy of not explaining the joke to an extent.--Mario2.PNG Super Martyo boing! 21:26, 24 July 2007 (UTC)

I'm not entirely sold on the idea yet, but I can see the advantage: it provides a standardized way of listing the running gags which we list anyway but are somewhat inconsistent about. That is, sometimes we hang a link in the transcript or in another fun fact, sometimes we have a separate fact of the form, "This is another appearance of X", and so on. Trey56 21:41, 24 July 2007 (UTC)

Also, the inside references do not show running gags hidden inisde the toon. Look! They're different! Super!SantanaDuper!
Hmm... I don't think that those single-episode running gags should be included. I definitely agree with DorianGray and Super Martyo Brother that that explains the joke. Trey56 21:49, 24 July 2007 (UTC)
And if not including them (which is a good idea), it's just unnecessarily breaking up Inside Refs. --DorianGray 21:55, 24 July 2007 (UTC)
I dunno, I've often thought there should be a separate section for things that are mentioned but aren't really references. A list of "Callbacks" or "See Also" or something might work. As for "Gags", I'm against anything that would unnecessarily explain jokes within a toon. — It's dot com 23:23, 24 July 2007 (UTC)
But otherwise running gags are not mentioned. Lookie! Lookie! Neither of them mention the running gag of being "on point", said by Marzipan in the dating sim, relating to the on point kings. Super!SantanaDuper!
Oh! And we have forgotten that inside references don't mention something like Toga-yoga from DNA Evidence. And I feel like if it's mentioned three times it's should be like a regular running gag and be mentioned. I mean, it's not like we are giving them their own pages. Super!SantanaDuper!
Ditto for secret identity not mentioning Strong Sad hyper due to caffeine.(easter egg) Inside references refers to charactes, other toons etc. Gags would refer to running gags in the toon and gags throughout the toon.Super!SantanaDuper!
I've been gone for awile, so like what happened? I vote for gags. Oh, and i noticed something that should be placed in single episode running gags: In theme song, strong bad makes shaheen's name sparkle whenever he types it.--Kanjiro talk 01:42, 25 July 2007 (UTC)
I've tried to remain open-minded about this, but it keeps coming back to this essential question for me: is it necessary to list the gags that occur within a toon? Really, that'd be the only added feature of a Gags section. We can already note running gags in Inside References, or Fast Forward if it's the first instance. But is it really something we need to do? To me, it feels like we are insulting the intelligence of the reader: "Ok, here's what's the funny stuff is in this toon." If you can watch thewhole toon and have the attention span of a four-year-old, you'll know all of this already. The Fun Facts regarding cross-toon gags is important as we cannot assume the reader has seen everything, or indeed anything but this one toon. But we can assume, and I feel must assume, the reader can and probably has seen the toon in question from start to finish, or is at least capable of it, and as such doesn't need the gags which appear spelled out. Mind you, it's not an especially bad idea. But that's not the test, for me anyway. i'm looking at the benefit vs the cost, and the potential insult to the viewer more than offsets the benefit of noting these few extra gags. Qermaq - (T/C) Image:Qermaqsigpic.png 02:18, 25 July 2007 (UTC)
I know the running gags are already listed under inside references, but what i did is put all of those gags under gags--Kanjiro talk 02:40, 25 July 2007 (UTC)

Also, everyone should see above, where this idea was already discussed and declined. --Mario2.PNG Super Martyo boing! 18:03, 25 July 2007 (UTC)

Maybe we should just put the thing that talks about an instance of a single toon running gag in inside references?--Kanjiro talk 18:15, 25 July 2007 (UTC)
I really, really don't think we should do inside-a-toon gags. 1. They explain the joke. 2. They insult the reader. And for reasons already stated in this and the discussion my last post linked to, we don't need a separate gag section for running gags. It was a good idea, but it (the single toon running gags) makes us seem like know-it-all's and makes the reader think that we think they didn't get the joke because they're stupid or something so we have to spell it out for them. This may cause the reader to vandalize pages or ridicule people on the talk page and, most likely, make it so that every single page that there's a gag section, a message on the talk page, saying "Hey, I'm smart enough to know that the toga-yoga class gag was a joke continued throughout the 'toon, and I don't need it explained to me by some geeks who think they're smarter than everyone else. --65.834.771" --Mario2.PNG Super Martyo boing! 18:36, 25 July 2007 (UTC) (P.S. I don't think that's a real IP address)
Ok, if you guys don't want it I'm fine either way.--Kanjiro talk 18:41, 25 July 2007 (UTC)
I thought Inside References was a fine place to put instances of running gags until someone tried to count "This is the 1st mention of DNA Evidence" as one of strong badathlon's inside references. (I already moved it to trivia) I do not think gags that ran in one toon are worth mentioning. Bad Bad Guy 23:30, 6 August 2007 (UTC)
To me, the gags section creates feelings of, "Oh, I like (insert multi-toon gag here), it's nice to see it's still alive. Oh, well if Toga-Yoga only lasted 1 toon why should you put it there? I already know they talk about it too much in that toon." Bad Bad Guy 01:18, 26 October 2007 (UTC)

Filmography Pages

I'm just asking, in mini-golf, a lot of characters made appearances, and most of those characters don't have their own filmography pages. The filmographies on their character pages have 5 to 6 appearances listed. I agreed that the Drive-Thru Whale's two appearances don't warrant their own page yet, but the question is, how many appearances does a character need to have their own filmography page? — SamSF%20sig.jpgFisher (Come in, Lambert.) 12:15, 13 August 2007 (UTC)

Pseudocharacters never deserve filmography pages (at least that's what I assumed after noticing there was none for The Paper, the Bear Holding a Shark, The Geddup Noise, the Tire, or The Stick). Bad Bad Guy 22:17, 3 September 2007 (UTC)
Strong Bad's computers actually have some but that's just because we wouldn't have the 178 Strong Bad Emails without them. And theirs aren't even complete because no loafing and candy product are missing from the Tandy's category because it only played small parts in those 2 emails. Bad Bad Guy 02:36, 21 September 2007 (UTC)

Cast list formatting 2

Should we change "Cast (in order of appearance)" to just "Cast", seeing that things like the Main Page aren't really in a fixed order? --Trogga 01:31, 7 October 2007 (UTC)

I think they ARE in an order, if you start with "Toons", and go straight down. --DorianGray 01:35, 7 October 2007 (UTC)
Yes, but they don't make you do it in that order. --Trogga 02:39, 8 October 2007 (UTC)

Time Difference Between Official and Actual

Occasionally, there is a difference between the time stated on the TV Time Toons Menu and actual running time. Two good examples would be Cheat Commandos (toon) and business trip. Before adding the note, I want to confirm that the format of

xx:xx [[TV Time Toons Menu|official]], xx:xx actual

should be used and that special case be noted in HRWiki: Standards. If not here, where should it be placed? wbwolf (t | ed) 05:29, 17 October 2007 (UTC)

That seems to be what we use. I say go for it. — It's dot com 14:21, 17 October 2007 (UTC)

Cultural References

Should we follow Wikipedia's lead and start adding "cultural reference" sections to Fun Facts sections instead of "Real-World Reference" sections? Bad Bad Guy 02:47, 9 November 2007 (UTC)

Nah, cause they're not all cultural... Some are historical, etc. — Defender1031*Talk 02:50, 9 November 2007 (UTC)

Strong Bad's Replies

When transcribing the scenes in Sbemails where Strong Bad types replies to the emails, would it be better to transcribe what he says or what he types? The transcripts for crazy cartoon, pom pom, and bike thief are modeled after the things he says, but the transcripts for island, do over, and isp transcribe what he types. (I already edited island and do over to what he says) I am not asking about those scenes where Strong Bad reads the email and changes a little part, I am talking about the scenes where he types his replies. Bad Bad Guy 22:19, 15 November 2007 (UTC)

The reason I find it necessary to ask is because after a edited island some people who misunderstood my reason asked me to change it back. Bad Bad Guy 22:42, 15 November 2007 (UTC)
  • do over: No. Hold on. No, no dying. {He only types one "no."}
  • island: I'm sure in real life it would be much more annoying and painful with Homestar involved. {he types "Dumpface" instead of "Homestar"}
  • crazy cartoon: In fact, I'm not even gonna call you monkeydude {he types "******" instead of "monkeydude"} again. I'ma call you Josh.
  • pom pom: All right. I'm ready to go. {Types as "aligrt u.ln reay tui gi"}
  • bike thief: {During the next part, Strong Bad types "Your bike should be totally safe if you listen to me. I am a good person that gives sound advice. Bike on, my friend, bike on!" while he says his other lines.}
  • isp: How else could I download this awesome animated gif/gif {Pronounced as /gif/, /jif/} of a cute breakdancing rodent?
This is what we're talking about, right? (I wasn't sure about isp.) — It's dot com 22:46, 15 November 2007 (UTC)
That's correct except I was thinking of a different do over scene:
Whoa. Coach Zed. That's way cooler. I'm gonna start calling him that too and maybe he won't suck so bad! Thanks, Richie! Your pal, Sed Bed {Types as SB, clears screen}
But that's a little picky and you got the main point of my post. Bad Bad Guy 02:28, 16 November 2007 (UTC)
I tend to agree. I think it reads better if for the most part you can hear in your head what Strong Bad is saying out loud, and I think it's easiest to do that when we transcribe what he says and then note the difference between what he types. Seems logical to me, especially in those examples. (The standing exception, of course, is that we display the email itself exactly as shown and note SB's variations below it.) — It's dot com 03:29, 16 November 2007 (UTC)
By the way, the line I was first thinking for isp ("gif/gif") is not affected by this standard. /gif/ and /jif/ are both ways of pronouncing the word, but it's still spelled "gif" in both cases. Thus, we have indeed typed what he says, and the note just clarifies it. — It's dot com 16:21, 16 November 2007 (UTC)

I'm all for this type of change to the transcripts, excluding when Strong Bad is reading the original email differently than it appears. Like Bad Bad Guy said. OptimisticFool 23:45, 15 November 2007 (UTC)

On the one hand, I don't like the fact that we rely on what's on-screen for the original email, while relying on speech for SB's typing. Then again, I suppose a little double standard is OK in this case, especially since some of the things SB types are a bit too outlandish for a transcript (especially pom pom). Heimstern Läufer 17:06, 16 November 2007 (UTC)
It's not so much a double standard as a shortcut. We could type everything Strong Bad speaks as part of the transcript below the verbatim email (just like we do for subtitles), but I think it's unnecessary (and we'd lose some subtlety). But more than that, I think it makes sense from a logical standpoint: When Strong Bad pulls up the email, if you scan it quickly, you could read the whole thing yourself right then. As Strong Bad reads it, however, he amends it in notable ways. Thus, we display the email and then list his changes below it. It's different when he starts to reply: the screen is blank, and your eyes can't skip ahead; they can only read along as he types what he speaks. The focus of what's important has shifted to what you hear, and at this point it's become notable to point out where what's typed does not match what's spoken, rather than the other way around.
As a corollary to this discussion, I think it would be appropriate and useful to list the direction "{brings up the email and reads it aloud}" after each email song and before the quoted email, since we never really state that anywhere. — It's dot com 18:51, 16 November 2007 (UTC)

How "picky" (for lack of a better word) are we going to be? I just noticed in your friends that during the last scene, Strong Bad says, "...a bath or something but, uh... just the thought of that...", but does not type the "uh...". This filler has been transcripted when he's not typing (ghosts comes to mind), so I don't know what to think. I don't think it's that important; no meaning is lost. But if we don't do this type of thing, where do we draw the line? OptimisticFool 16:57, 17 November 2007 (UTC)

Late hit: Transcripts should always tell what what was said. Emails generally show what was typed, then modify to show what was said, but in general transcripts are what was said. Qermaq - (T/C) Image:Qermaqsigpic.png 16:02, 20 April 2008 (UTC)

Live action toon screenshots

JPEG format is generally only desirable for "live action" toons such as Puppet Stuff

I'm not sure I agree with this (or if for the most part our current practice did up until recently either). We're still taking screenshots of Flash toons, not photos. JPEG should just be used for photos. Thoughts? -- Tom

Given that JPEGs use lossy compression, when would it be appropriate to ever use a JPEG (assuming it's a situation where you have a choice and not, say, an original image that is already in the JPEG format)? — It's dot com 17:53, 26 November 2007 (UTC)
As I understand things, that's exactly right. JPEGs should only come from cameras. Things like Image:20070426 GA Tech event venue.jpg, Image:The Statue of Liberty and Ellis Island from Battery Park.jpg, and Image:craigzobel.jpg are good examples. -- Tom 18:01, 26 November 2007 (UTC)
Has it always said JPGs for live-action toons? That makes no sense... PNG unless no PNG exists, for sure. Homestar Coderhomestar-coder-sig.gif 18:05, 26 November 2007 (UTC)
I agree that we should use PNG unless the original image is a JPG. So, in my opinion, we should change the above standard and replace
with corresponding PNG images. Trey56 22:49, 3 December 2007 (UTC)
But PNGs get huge the more colors the picture has. For a cartoon screenshot, which will generally only have 10 or 20 different colors, they make sense, but for live action shots, which have each pixel is a different shade from the one next to it, you'd end up with huge filesizes. Lossy JPEG is the way to go for such photos. — Defender1031*Talk 23:20, 3 December 2007 (UTC)
My understanding is that their size is on the same order of magnitude — such PNGs are only about 5-6 times the size of JPGs. Bigger, yes, but not to the extent that it's going to dramatically affect the amount of data we're sending out, especially since most pages only require the small thumbnails to be downloaded. Trey56 23:40, 3 December 2007 (UTC)
2 points, first, does MW actually generate smaller thumbnails, or is it just scaled down? and even if so, there's also the issue of storage space. Also, i'm pretty sure that for multi-color photos, there's a better lossless option than png. I'll write back in a few minutes after doing some research. — Defender1031*Talk 23:45, 3 December 2007 (UTC)
Yup, MW actually creates smaller thumbnails. It does this once and then stores them as long as the original image lasts — that way it doesn't have to recreate the thumbnail every time somebody loads the page. Trey56 23:48, 3 December 2007 (UTC)
Trey56: Even if we change our policy, I don't see why we should replace the JPEGs above. The big images aren't being continually resaved (thus there is no data loss over time), and replacing them with PNGs would just inflate the filesizes without changing any of the pixels. — It's dot com 23:54, 3 December 2007 (UTC)
I wasn't advocating taking those images and converting them into PNGs, but rather taking fresh screenshots and saving them as PNGs. I believe that this would change the pixels, and remove the image loss from the JPG compression, right? Trey56 23:56, 3 December 2007 (UTC)
JPEGs saved on the highest quality are close enough to lossless that most of the time, if you save a bmp as one and then change it back to bmp the files will be identical, and the rest of the time, there is no way to tell without really going through and comparing every pixel. Conclusion: Highest quality JPEGs will look the same as PNGs with a sixth the size. I don't think there's really any reason to have the extra 500% space usage for a few pixels to be a more exact color. — Defender1031*Talk 23:59, 3 December 2007 (UTC)

Some file size comparisons

Image:Little Girl 2.jpg

75 KB — as is, at default jpeg compression factor 20.
332 KB — at jpeg compression factor 1.
488 KB — PNG format.

So, a lossless PNG and a nearly-lossless jpeg are both very large. Lossless beats nearly-lossless, IMO. Now, a non-live action example that should compare pretty well anyway. Image:Limozeen Advantage.jpg was replaced with Image:Limozeen Advantage.png. 87 KB to 421 KB. But the wiki physically resizes images for thumbnails, and the thumbnails went from 16 KB to 44 KB. A difference of 28 KB is no big deal. So, yeah, why not go lossless with live action screenshots? As for replacing those listed above, I'd do it if it was important. Otherwise, a "from here on out" policy seems practical. OptimisticFool 03:40, 4 December 2007 (UTC)

Fanstuff

"Teen mii squad" was deemed a notable reference to Nintendo, "whoa, that was fast!" was deemed a notable reference to what i want, and "awesome fanimation" was deemed a notable reference to yes, wrestling. However, "interchangable sb" was not considered a reference to Strong Bad Smiling. (Sorry, I always have trouble linking to sections of Weekly Fanstuff.) What are the standards to counting Fanstuff as references to toons and running gags? Bad Bad Guy 20:26, 3 December 2007

If the main theme of the fanstuff is referring to something, then we note it, but if it's just like "oh look, someone else in this fan costume is dressed like mario" then we don't. (Unless of course strong bad makes reference to eating luigi) — Defender1031*Talk 02:32, 4 December 2007 (UTC)
Should any of these go then? Should I return "Hot Homestar" to cross-dressing? Bad Bad Guy 02:35, 4 December 2007 (UTC)
i don't think so, as it's not really homestar doing the cross-dressing, and the gender difference isn't the main focus of the fanstuff. — Defender1031*Talk 02:38, 4 December 2007 (UTC)

Order of Fun Facts

You down with OCD? This article says, "When posting fun facts, [...] place all fun facts at the bottom of the list, please." I thought standard procedure was to order the facts under each heading according to the toon's chronology (when applicable). Did I imagine that? I would think it would make more sense than "first come, first served". --TheNicestGuy 18:02, 17 December 2007 (UTC)

I agree with the protests above. As currently stated, policy does not follow practice. When a toon article is first being created, this might be a good approach, but especially in the situation where the categories are split, we should begin reordering according to chronology within the toon. As this seems plain to me, I shall make edits, but feel free to disagree. Qermaq - (T/C) Image:Qermaqsigpic.png 15:23, 20 April 2008 (UTC)

(Don't Fear) The Redirect

Is [[Site Components#NavBar|navbar]] really better than [[navbar]]? (The latter of those links redirects to the former.) Somewhere along the line we got it in our heads that redirects are downright evil, but they can serve a valuable purpose (for more than just searches and typos), and it seems like we're needlessly avoiding using these tools, especially now that section linking works. What if, for example, we got enough information to create a whole article about the navbar. Because all the links are hard-coded to the Site Components page, they would all have to fixed. On the other hand, if the references were to the redirect page, no other pages would have to be edited. I personally think we should use fewer piped links (which is one of the reasons I developed the autopipe feature) and not be afraid to use redirects when doing so would make our lives easier. — It's dot com 18:25, 13 January 2008 (UTC)

This guy knows what he's talking aboot. —BazookaJoe 18:33, 13 January 2008 (UTC)
I agree. It seems that people started "removing redirect"s in cases where it was a similar name and whatnot, and that somehow expanded into removing all redirects. I'm all for the idea of linking to redirects when it makes sense. It seems to me that a few practices on the wiki sort of just evolved that way without any rhyme or reason, and that when looked at for what they really are, aren't really the best of ideas. — Defender1031*Talk 18:39, 13 January 2008 (UTC)
Sounds good. I don't think it would hurt to take it one leg at a time though. -- Tom 19:21, 13 January 2008 (UTC)
I was wondering about that myself the other week, when we adjusted links to H*R.com updates 2008 instead of H*R.com updates etc. I've got a fever, and the only cure is more redirects! (Well, no, not really, listen to what Tom said.) Loafing 19:36, 13 January 2008 (UTC)
Redirects should be avoided when practical, one should not link to a redirect when the original exists, but I see no issue with using a redirect in the above situation. We use TTATOT often without question. I type my redirects one character at a time, like anyone else; the difference is after I type a redirect, I make hit records. Qermaq - (T/C) Image:Qermaqsigpic.png 22:28, 13 January 2008 (UTC)
I think you should avoid redirects when the link text would change too... using eg Teen Girl Squad Issue 12 instead of Teen Girl Squad 12... simply because in most cases, the former is the more accurate thing to have as the link text anyways. For a similar reason, I'd prefer [[Teen Girl Squad Issue 12|whatever]] over [[Teen Girl Squad 12|whatever]] in most cases. However, if the redirect is to one part of a conglomerate page, like navbar, then the shorter name is better, even behind a pipe... and if the link text you want matches the redirect name anyway (like DC's original example) and avoiding the redirect would mean adding a pipe where you wouldn't otherwise need one... definitely go with the redirect. My two and a half cents --phlip TC 09:24, 14 January 2008 (UTC)
I also think using redirects judiciously (where it's entirely beneficial) is a good idea. To that end I've made a couple of edits in that direction. (Also based on this discussion). I'm just trying to sort of bring the two discussions together since they are related. --Stux 17:01, 14 January 2008 (UTC)
In late reply to Phlip: "even behind a pipe" - nah, a few extra characters of load on the download of a page is not equal to the load of requesting first a page, then the redirected page, upon clicking that "few extra characters" link. In a piped link situation, it's always better to link directly to the source, but for unpiped links, if an available redirect is more concise, use it. Qermaq - (T/C) Image:Qermaqsigpic.png 15:19, 20 April 2008 (UTC)

What about in the case of Donuts versus Donuts?

I prefer the second. -132.183.138.192 16:30, 28 July 2009 (UTC)

They're the same as far as appearance. {to Michael} And your point is...? Heimstern Läufer 16:59, 28 July 2009 (UTC)
My point is that DeFender said that pipes are ugly and clunky, and you said that they look exactly the same and both point to the same page. As far as this shows, they're almost exactly the same. MichaelXX2 mail_icon.gif link_icon.gif 17:06, 28 July 2009 (UTC)
That's true, they are. I think it's generally pointless to switch between redirects and pipes (and if either is clunky, I'd argue it's the redirect, since you get that "redirected from..." message when you get there). But neither one is a big deal. Heimstern Läufer 17:09, 28 July 2009 (UTC)
I admit: it used to be our policy to always use pipes, never redirects, so it still throws me a little from time to time. I must have missed the conversation when we reversed that decision, but as long as we're consistent, I don't mind either way. It's either slightly clunkier when you edit, or it's slightly clunkier when you see the "Redirected from" message. --Jay (Talk) 17:14, 28 July 2009 (UTC)
There wasn't much conversation, Defender basically decided to change the standard on his own, and the wiki apparently rolled with it. I still strongly feel that we should go back to pipes. -132.183.138.192 17:16, 28 July 2009 (UTC)
I really don't see any reason we have to be consistent; as long as the reader gets to the right place, we've done our job. At Wikipedia, there's no consistency in this area, and it makes few problems. (OK, there's the occasion when someone ends up linked incorrectly to a disambig page. Besides that.) Heimstern Läufer 17:18, 28 July 2009 (UTC)
My point in the original discussion above was that if B is a subset of A, it's better to put [[B]] rather than [[A#B|B]]. This has two advantages: it tidies up the code, and if we ever decide to make B a full article, we don't have to fix a bunch of links. On the other hand, if something is a mere variant, I still prefer pipes: [[Homestar Runner|Homestar]] as opposed to [[Homestar]], because the click-through is cleaner. Neither is really wrong per se, and in general I don't support editing an article solely for the purpose of changing an instance of one to the other, since all that's happening is adding revisions to the history without really changing anything. (Note, however, that I don't consider this a hard and fast rule.) Certainly there's no need for mini edit wars. — It's dot com 18:04, 28 July 2009 (UTC)
I should also point out that I developed the autopipe feature to simplify the code while still maintaining all the benefits of pipes (namely, avoiding the "Redirected from" message). In a sense, goat is still a piped link to Goats; the difference is that instead of having to explicitly declare the pipe, the software interprets [[goat]] as [[goat|Goats]]. The pipe is still there in theory; it's just handled automatically. Redirects simplify the code as well, but they have the drawbacks we've already mentioned. As such, they should be preferred only when the benefits outweigh the drawbacks. — It's dot com 18:52, 28 July 2009 (UTC)
In response to the anonny, i didn't "decide to change the standard on my own", it was based on a misinterpretation of this conversation, which i have since been disillusioned to, and am now no longer being a pipe nazi. I thought that the consensus reached here was "link to redirects whenever one is available" when in fact, it was "link to redirects whenever the link is a subset of a page". I apologize for being mistaken.
In response to everyone else, yes. — Defender1031*Talk 21:42, 28 July 2009 (UTC)

A little question about little questions

Is there a rule against including an Easter Egg in the main thumbnail like that? Bad Bad Guy 23:15, 21 January 2008 (UTC)

Plainlinks

I'm trying to use the plainlinks class (<span class="plainlinks"></span>) on another Wiki page.

However, I can still see the external link icon.

Do I need to install anything to make it work?

You want to go to the MediaWiki:Common.css page on your wiki, and add:
.plainlinks a
{
   padding: 0 !important;
   background: none !important;
}
Note that only sysops can edit that page, along with everything else in the MediaWiki: namespace. --phlip TC 09:02, 24 January 2008 (UTC)

Linking in spoken words

We state not to link in dialogue of toons, and to link in transcripts only in the comments and only when the transcript really is the best place for the link. I support that completely. I think, however, that we should consider whether to allow linking in the spoken words of DVD commentaries, perhaps at the very least to toon titles. Otherwise we have to have a "TBC mentioned X toon" fact in the fun facts section. I think moving the links to the fun facts section does not serve the reader in this case, and I think they're redundant because they don't give any new information. — It's dot com 00:44, 7 March 2008 (UTC)

Maybe just mentioning actual toons, but if they reference something from it without saying the toon that it came from, we should still have a fun fact explaining where they got the reference from instead of linking it. Homestar-Winner (talk) 00:53, 7 March 2008 (UTC)
Sounds reasonable so far. Explaining elements is appropriate, but in cases where we don't add anything, the "fact" isn't really "fun." -DAGRON 00:56, 7 March 2008 (UTC)
I would support allowing linking within transcripts of DVD commentaries or interviews. It should be held to a minimum (i.e. don't make every other word a link), though. In transcripts of toons, it's easy to move any links to a description, especially if the gag/reference is purely visual, but there are no such breaks in the audio only transcriptions. I can think of a couple cases off the top of my head where linking in the transcript helped clarify that it's a reference to a specific toon rather than "random words" (cf. Late Nite JengaJam Interview - 4 Oct 2007). Those are the cases where linking in the transcript is the most helpful. wbwolf (t | ed) 02:55, 7 March 2008 (UTC)
In general, I prefer the transcripts "clean" but occasional linking from within the transcript isn't bad IF the link is awkward any other way, or the average reader (read: already a fan) would not make the connection otherwise. Qermaq - (T/C) Image:Qermaqsigpic.png 03:23, 7 March 2008 (UTC)

Recurring Themes Category

There has been talk of moving the "X Character Smiling" pages and "Best/Worst X Ever" to a category of recurring theme articles. I think Pining and "Awesome" could fit in that category as well, but first we need to set a notability guideline for it. Bad Bad Guy 18:56, 7 March 2008 (UTC)

Summaries

If we feel strongly enough to include the language "always fill in the "Summary" box", perhaps there is a way to have the wiki developer-tweaked to set "Prompt me when entering a blank edit summary" to checked as default in "my preferences". In doing do, we are stating policy within the machina of the wiki, and constantly reinforcing it to users. Qermaq - (T/C) Image:Qermaqsigpic.png 15:05, 20 April 2008 (UTC)

I like it. Sometimes I forget. Can it be done? OptimisticFool 19:04, 4 May 2008 (UTC)

Second person

Here is the much-awanted discussion. Do we do totally away with 3rd person, and what to do with Easter eggs and commands and such? Here is a central place to which all the posters can gravitate, as there seems to be none on this topic. Qermaq - (T/C) Image:Qermaqsigpic.png 00:26, 4 May 2008 (UTC)

Qermaq, it's second person, not third person. Third person is "he, she, they, any noun, etc." and second person is "you, yours, yourself, etc." I have taken a break for about two hours and feel refreshed, so I think I have some ideas:
  • Do use second person when instructing the reader how to do something, such as DVD commentaries and games. I'm not sure about easter eggs.
  • Do not use second person when explaining a topic or stating a goof or remark on a cartoon.
  • Do not use the terms "you can see" or "we see" when explaining a topic or stating a goof or remark on a cartoon, and preferably not at all.
That's all I've got for now. -Brightstar Shiner 02:13, 4 May 2008 (UTC)
So the standard would be that articles must avoid 2nd person in all cases, except when the intent of that portion of the article is to instruct the individual reader to perform a specific task with their computer, game controller or DVD player. That worded right? Qermaq - (T/C) Image:Qermaqsigpic.png 06:03, 4 May 2008 (UTC)
Sounds fine to me. But don't revert any of the changes already made to those portions of the articles because they sound more professional without the "you"s anyway. I'm still wondering about easter eggs, though. -Brightstar Shiner 11:37, 4 May 2008 (UTC)
Certainly not, the standard is not meant to demand 2nd person in those cases, but to forbid it in all but. Qermaq - (T/C) Image:Qermaqsigpic.png 15:02, 4 May 2008 (UTC)
What? -Brightstar Shiner 17:19, 4 May 2008 (UTC)
He means that he doesn't plan on reverting your changes, because 2nd person is not required ... it's just allowed. And as far as Easter eggs go, I think that 2nd person ought to be allowed as well. OptimisticFool 17:31, 4 May 2008 (UTC)
<Ahem>I knew that... I like the Easter Eggs idea too, so if all is well, I'll just update the Manual of Style to fit this discussion. -Brightstar Shiner 17:42, 4 May 2008 (UTC)
I put back the more concise wording and added another example per this discussion. I moved it back to Miscellaneous from its own section because "we" is first person, not second. — It's dot com 23:39, 4 May 2008 (UTC)
Okay. I didn't really know how to word it right and I thought it sounded awkward, so thanks for fixing it. I have to admit though, it's a little embarrassing that you had to drastically edit what I originally wrote... -_-; -Brightstar Shiner 23:45, 4 May 2008 (UTC)

Additions to the summary?

Even though we already have it down in a separate article, should we include a "TV Time Toons Menu" description in the most recent toons' summaries? Not to mention moving the Podstar Runner Description out of the trivia and into the summary for Strong Bad emails and the toons that were once on there? --70.143.29.70 18:37, 18 May 2008 (UTC)

"Bump" and correction here, TV Time Toons Menu Description
Why do I keep forgetting to sign? Oh well, too lazy. --68.92.250.78 19:53, 8 September 2008 (UTC)

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.

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)

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. — Image:kskunk_fstandby.gif 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. :) — Image:kskunk_fstandby.gif KieferSkunk (talk) — 02:10, 6 December 2008 (UTC)

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 &mdash; and &ndash; 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 &trade; and &frac12; I'm on the fence about. But letters, especially in the middle of words, like Comp&eacute;, 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 TC 10:28, 5 August 2009 (UTC)

Phlip and I discussed this yesterday. When I brought it up, I said, "Comp&eacute; 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 "&eacute;" 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)
Personal tools