explain xkcd:Community portal/Coordination

Explain xkcd: It's 'cause you're dumb.
Revision as of 15:21, 25 November 2012 by Lcarsos (Talk | contribs)

Jump to: navigation, search

Welcome to the Community Portal. This set of pages is used to discuss how Explain xkcd works, and is divided into five sections. Please use the table below to find the most appropriate section to post in, or post in the miscellaneous section. You can view all community portal sections at once here.

Community portal sections
Crystal Clear app ktip.png

Proposals (post)
Ideas to improve the wiki's design and organization.

Crystal Clear app package settings blue.png

Technical (post)
To discuss technical issues.

Crystal Clear teamwork.png

Coordination (post)
To coordinate content editing and maintenance tasks.

Mop.svg

Admin requests (post)
User problems, changes to protected pages, etc.

Internet-group-chat.svg

Miscellaneous (post)
Messages that do not fit into any other category.

Contents

Issue dates

Hi Jeff,

As i'm creating pages I struggle with the issue dates of comics. I've added a comment to all pages that contain the (unknown/incorrect) dates. Is there a way to research those dates? --Rikthoff (talk)

[1] if you mouse over the comic name, it will have the date. --Jeff (talk) 18:26, 3 August 2012 (EDT)

- if you mouse over comic name in "Archive" section of xkcd.com. Older comics(1-44 or so) might be found in livejournal archiveB. P. (talk) 18:35, 3 August 2012 (EDT)

Should we consider using "2012-08-03" style dates and letting localization "do the right thing"? Most pages so far use "August 3, 2012" style dates, with a few incorrectly doing "August 3rd, 2012"... Presumably the template could do the localizing/localising...--B. P. (talk) 18:39, 3 August 2012 (EDT)

The date is also available with the JSON API, which I'm going to use for the import. I use {{#dateformat: year-month-day}}, MediaWiki should figure out the correct way to display it based on your preferences. --SlashMe (talk) 18:47, 3 August 2012 (EDT)

Moved from User talk:Jeff. --Philosopher Let us reason together. 00:15, 4 August 2012 (EDT)

Date?

How do I find the date a comic was first posted (to put in the comic header here?) TheHYPO (talk) 12:26, 3 August 2012 (EDT)

Moved from Talk:Main Page. --Philosopher Let us reason together. 00:43, 4 August 2012 (EDT)

Original posting date is listed on xkcd's [archive page] as hover-text for each post. The first 44 comics are all listed as 2006-01-01. Many of these were previously posted on the [livejournal site], and some dates can be found/inferred by checking there.--B. P. (talk) 17:49, 7 August 2012 (UTC)

To do list

I suggest a todo list to be added here so newcomers will have an idea of concrete things they can do to help. I'll start by moving some items I've been collecting on my user page. Feel free to add more :)

Things to do

  • Complete all entries from the List of all comics
  • Special:WantedPages lists pages that have links to them but haven't been created yet.
  • More topics that could be covered here besides the comics themselves:
    • our twitter account
    • the xkcd irc channel (and its wiki)
    • the xkcd blag
    • the xkcd forum
    • other sites explaining xkcd ([2], [3], [4], [5], maybe invite members+content of the other wikis in once we're established?)

Maintenance

There are more maintenance reports at Special:SpecialPages, for inspiration :) --Waldir (talk) 06:45, 6 August 2012 (EDT)

I'd love one of these "To Do" lists for admins as well! :) I'm always forgetting what I need to do! --Jeff (talk) 02:35, 12 August 2012 (UTC)
There actually isn't much to do that needs admin permissions around here. Right I can think of only a handful of admin-specific tasks:
Maybe others will have other items to add to the list, but for the most part, the things that need to be done are available to all editors: adding the missing comic explanations, describing characters, categorizing, etc. --Waldir (talk) 19:13, 12 August 2012 (UTC)

Date categories

I'm not sure the "Comics by month", by weekday, etc. Will be much useful, unless for those interested in running some stats. It might be more interesting to have specific months, such as Category:Comics from May 2011 and so on. What do you think? --Waldir (talk) 06:45, 6 August 2012 (EDT)

That was actually next for me: #time:year-month, but I wanted to study the globalization implications. I prefer over-categorizing rather than under-categorizing, since it's comparatively cheap. The assumption is that categories are the same as tags on the old site, and that mediawiki affords us some extra ways to automatically categorize pages in addition to the manual forms starting to emerge (by character, by subject, etc.) To paraphrase an old prof: you can't study what you don't measure; I've been wanting to see if, for example, Monday comics deal certain subjects, while Friday comics deal with another, etc. Not everybody's cup of tea, but of value perhaps to some, and insanely cheap to support both mentally and for the software. -- IronyChef (talk) 13:51, 7 August 2012 (UTC)

I also used it to find some date typos for Saturday/Sunday/Tuesday/Thursday comics, which should usually be empty - except for some early entries from livejournal... --B. P. (talk) 21:50, 17 August 2012 (UTC)

It does make it look a bit messy down by the categories... maybe we can skip one or two of these date categories, if people don't still find them useful? St.nerol (talk) 21:22, 23 November 2012 (UTC)

Page names

I think we should use the comic number and the title as the page name. Like so: "112: Baring My Heart". This would allow comics to be sorted by order in categories, but the pages would still have human-readable names for those of us who don't memorize all xkcd comic numbers ;) Thoughts? --Waldir (talk) 07:23, 6 August 2012 (EDT)

I agree, for another reason: for instance YouTube could be either the title of a page explaining how YouTube is referenced in xkcd, or the title of the explanation for comic #202 (titled "YouTube"). I don't know if I'm being clear here, but as we do not control the titles of the comics, that could create confusion with other pages. So using something like 202: YouTube would ensure disambiguation without being really complicated or awkward... And actually prefixing the comic title with its number seems quite relevant to me.
Additionally, that would solve potential problems such as Exoplanets: comic 786 or 1071?
Cos (talk) 14:33, 6 August 2012 (UTC)
Beat me to the punch; agreed. Numbers are unique and sequential, but not altogether that meaningful. Names are meaningful but (as we've seen) not unique. Some combination of both would be called for. We'd need to have the plain numbers redirect to the new topic (some double-redirects would need to be fixed up?) and the names would too (with at least one disambiguation page for now, and who knows: maybe more to come?) -- IronyChef (talk) 13:55, 7 August 2012 (UTC)
Following up on the YouTube discussion above, I'm wondering if we should leverage namespaces more: main:topic is implicitly xkcd:topic (ie main:YouTube discusses the xkcd comic, while ref:YouTube is the place where the pop-culture reference of YouTube is discussed.) Either that, or some other name decoration, such as YouTube Explained, or ... -- IronyChef (talk) 13:59, 7 August 2012 (UTC)
Agreed. Number and the name together. --Jeff (talk) 16:08, 7 August 2012 (UTC)
Looks like we have consensus. I'll move the pages (I've been meaning to learn how to use mwclient anyway :D) --Waldir (talk) 18:01, 7 August 2012 (UTC)
 Done, all current pages have been moved. However, I am not sure whether we should keep a space after the colon. What do you guys think? Should it be "112: Baring My Heart" or "112:Baring My Heart"? --Waldir (talk) 18:20, 7 August 2012 (UTC)
Also, I just realized MediaWiki doesn't allow colons in image Filenames. One solution could be using something like File:786. Exoplanets.png or File:786-Exoplanets.png, but then perhaps we'd have to change the pages name too, for consistency? I'll try to investigate what is the reasoning behind this restriction. --Waldir (talk) 18:50, 7 August 2012 (UTC)
Ok, it seems like it's a matter of setting $wgIllegalFileChars = ''; in LocalSettings.php (because it is set as $wgIllegalFileChars = ':'; in DefaultSettings.php). Jeff, could you do that please? --Waldir (talk) 19:13, 7 August 2012 (UTC)
Nevermind, we will probably use a different naming pattern instead. --Waldir (talk) 20:05, 9 August 2012 (UTC)
I guess this is my bad for not ciming in on this discussion earlier, but I frankly think that the #: Name is a worse way of doing it just for the reasons of system resources. #:Name is fine from a user standpoint with the caveat that # and Name both redirect to #:Name. The problem is that this requires 2 redirects minimum for every comic, and the redirect itself takes a bit more time for each article to load, and (as I understand from wikipedia and its dislike of double redirects), every redirect adds to the system load. So if every article lookup by users (who will undoubtedly type either the number or the name, but rarely both) is a redirect, the system load is going to go up.
As an aside, assuming Jeff is able to install the Cite Extension to add citation referencing (and even if he doesn't), I was expecting to try to create some sort of template in the concept of {{cite comic}} where you could basically pass a single variable (e.g. the comic number) and it would create a proper citation for that comic. Similarly, this naming format will perhaps require a template something like {{comicno}} with a comic number field just to create a quick link that is visibly appealing and links properly to the comic with that number. (ie: {comicno|18} would produce a link like "Snapple" or something). I'm wondering though if anyone has any coding ideas for how we might accomplish this other than the hardcode all the titles into a template. TheHYPO (talk) 19:26, 7 August 2012 (UTC)
PS: I did some mild digging on another wiki, Star Trek's Memory Alpha wiki, and although all of its episode articles are now titled "episode title (episode)" to avoid disambiguation, which allows you to an episode template by calling the title (which template appends "(episode)" to every entry), they DO have a title-display template: Template:Titles - with a template subpage for every single episode setting out how the mouseover text should be displayed. It would be possible to do such a template for xkcd just so that comic numbers can be crossreferenced to titles... TheHYPO (talk) 20:30, 7 August 2012 (UTC)
(Hoping this is the right number of colons for proper indentation... ;-) Redirects are one thing, and while probably resulting in possibly two page serves (isn't it really just two hits to the db?) they're natively supported by mediawiki. Even so, if performance is proven to be a real (not just conjectured) problem, can we do something clever, perhaps, with transclusion? Either the number transcludes the title, or vice versa? Might be a case of pre-optimization, though; in the back of my mind, it seems that the rendering engine puts as much effort into transcluding to expand templates as it would to expand a redirect in situ: either case is just a query to the DB to expand the contents of said item. (Enough rambling; anybody have any concrete metrics on this?) -- IronyChef (talk) 06:23, 9 August 2012 (UTC)
Hi folks. Just thought I'd state that redirects are completely safe. They don't add any noticeable loading time for the users and the extra resources used by the server are so minor that it's akin to the resources used to type a character in notepad. Pages are also aggressively cached (by default, anyway). If you're interested, the way redirects work in Mediawiki isn't like most other sites handle redirects. It's not loading a page that makes you load another page. Rather, all content is stored in an SQL database. The content is stored under a certain name (eg, "#: Hello World!"). A redirect simply tells Mediawiki to look for the content under a different name. Slightly more work for the server (don't worry, they can handle it), but the page is delivered to the user in roughly the same period of time (if we want to be technical, the page will be slightly larger, due to the "Redirected from whatever" line added to the page (which is mostly there for the purpose of making it easier to fix incorrect redirects). I don't have metrics, but can assure you that it's almost no difference in the end result. Omega TalkContribs 09:11, 9 August 2012 (UTC)

I've been thinking about this some more, and I believe we should choose a different pattern for the page names.

  • First, use another separator between comic number and name, since colon is forbidden in files. A simple alternative would be "Comic title (number)", as in Michael Phelps (1092). This would additionally allow us to use the pipe trick when linking to a comic, since content in parenthesis is automatically stripped out: [[Michael Phelps (1092)|]] results in Michael Phelps. Another effect of this is that by dropping the colon naming scheme we would remove ambiguity with the namespace system, which also uses colons to separate namespaces from pagenames.
  • Second, we should probably follow IronyChef's suggestion above and move them to a specific namespace, such as Comic:Michael Phelps (1092). Other namespaces could be added for more topics, such as Character:Cueball, xkcd:Randall (or Meta:Randall), Topic:Velociraptors, etc. Not only we would be able to generate lists of pages without resorting to categories (which have to be added manually), but we would get lot's of "Random X" for free (random comic, random character, random topic, etc.)

What do you guys think? --Waldir (talk) 14:29, 9 August 2012 (UTC)

P.s. - Proper category sorting of the comics would be dealt with by the {{comic}} template, which would also pad the numbers with zeroes to ensure 100 comes after 2, etc.
+1 on the parens... (but does that mean my recent double-redirect-fixups have been for naught? (grin)) ... I couldn't put my finger on it and didn't articulate it earlier, but the fact that colon needed special attention by the software left me a bit uneasy (there must be a reason for them doing that, like namespaces perhaps) so using parentheses-es-es (as long as we close them properly) seems more the mediawiki way. -- IronyChef (talk) 15:03, 9 August 2012 (UTC) (I know you folks don't like my propensity to (over?)categorize, but [[Category:Parentheses]] is just too irresistible... ;-)
I think, that all of this seem unnecessary complication to me. I don't see any problem with the current system. I think something like 1092: Michael Phelps flows well, is quite readable and easy to insert "as is" in the text (see the links to other comics in 1048: Emotion for instance). As I understand, we would want the image files to be titled exactly the same way as their corresponding article; why, where is the need for that? (to me the simplest way, and most relevant maybe, would be to name them exactly as they are on xkcd.com; maybe with a prefix, like "xkcd - ", so that it cannot mess with other existing images such as from Commons).
I don't see the point of creating namespaces such as "Character", "Topic", etc.; what is the problem with Beret Guy, Randall Munroe, Velociraptors, and such? with namespaces one will have to put each topic in one box (and one only), where will you put things like Stick figure or My Hobby or any other thing that will pop up without clearly belonging to one of these boxes? just give up! :-)
About the "Random X", I like the idea that on xkcd.com, you can get a random comic (because that's all what is there), but in here you can get a random whatever: you may get a comic explanation, a character, a topic or anything, because in here there is all that.
I don't think the colon in the comic page names will pose any problem, it cannot mess with anything as long as it is preceded by a number only.
In the end, I think that adding the number in the comic page names was a good choice, because there would have been real issues otherwise, but for now I would say : "don't fix what is not broken", KISS, and "just give up". :-)
Cos (talk) 16:14, 9 August 2012 (UTC)
I have to agree with this. The existing page names are fine in my book, and I don't see any benefits of renaming them all (again). Concerning the random, though, I mentioned an extension in proposals that would allow us to choose a "random page in a category". I don't really care one way or another about character topics. Seem like a lot of maintenance when we don't even have a quarter of the comics explained yet, but whatever. Concerning the image names, I think that simply using the same name as it appears on xkcd is fine. Images are a bit of a "backend", that people don't usually search for (rather, they'd search for the comic and find the image on that page). As well, since all images are hosted on xkcd, they won't be any file name conflicts amongst the comics. Omega TalkContribs 18:04, 9 August 2012 (UTC)
Good points (and puns!), all of you. I'd like to address a few specific points (I'll highlight the key takeaways for your convenience):
  • I still prefer parenthesis for the simple reason that colons mess with the concept of namespaces (not that it has any effect on the software, which can cope quite well; I'm speaking from a user point of view). Besides, one of the reasons I proposed for having the number first was automatic category sorting, but that backfired (cf. #2 vs. #100).
  • Re rationale for having image files titled like the comics is that it would allow automatic image inclusion via the {{comic}} template. However, having the prefix is not crucial for that (hadn't thought of this before), so I'll go ahead and remove my suggestion above to allow colons in filenames.
  • Note that there's no problem with "conflicts" with Commons images: an image uploaded here simply takes precedence regarding an image uploaded to commons under the same name (e.g. File:Irony.jpg vs. commons:File:Irony.jpg). That said, while external conflicts aren't a problem, internal ones are (e.g. Exoplanets). That, coupled with the "it's just a backend" point made by Omega, is a good argument to use the original filenames (also, less overhead when uploading a new comic)
  • I understand the argument against a single primary way to classify a page using namespaces. The category system is more flexible as it allows many-to-many relationships. However, I must point out that the examples you give are no problem at all: Meta:Stick figure and Topic:My Hobby ;) So I'm still not convinced that using custom namespaces is a bad idea or a lost cause or that it won't scale up well. Besides, it makes it very clear what a reader will find on that page (explainxkcd.com/wiki/Topic:Velociraptors is a pretty self-explanatory url). And again, it allows us to use the random feature that is natively implemented on mediawiki, rather than an extension. And "random whatever" is still available, of course :)
  • IronyChef, by all means, please create Category:Parentheses :D
--Waldir (talk) 20:05, 9 August 2012 (UTC)
If we're going to use the numbers in the titles, it seems logical to have the number come first so that comics are essentially sortable by number rather than alphabetically by title; although this probably can be taken care of by changing the sort title, thoug this could be tedious.
I don't support new namespaces for comics and characters and whatnot. I don't see what it adds to the wiki, and it just makes the links to each comic page even longer (no one will EVER correctly search for Comic:Snapple (18) on their first attempt).
I am not claiming to be an expert on redirects. My comment was based on wikipedia pages like Wikipedia:Double redirects where it clearly suggests in the lead that double redirects "waste server resources". I assume this applies (at to a lesser degree) to single redirects. They may not be needless waste like double redirects, but they they do use resources. Granted wikipedia has far larger servers and much more traffic, so it may be more relevant to them than here, but it still would appear to be a resource issue; Database queries are still resource hogs, even if they are simple ones. Not suggesting they aren't safe, but if every comic load is basically a redirect, that is still two queries every time instead of just the occasional one. I'm fine with it; I'm just pointing out the issue. TheHYPO (talk) 16:20, 10 August 2012 (UTC)
The reason that double redirects are bad is that linking a redirect to another redirect (a double redirect) causes the first redirect to simply display the content of the second redirect (rather than actually redirecting the page). This appears as simply an arrow and a link (a soft redirect). It uses more system resources because an actual page has to be loaded and displayed, forcing the user to manually click the link and display the proper page (whereas a single redirect would load the correct page and display it). So in other words, a double redirect forces two pages to be loaded, while a single redirect only loads one page, more or less the same as if you went to the actual page title. Omega TalkContribs 21:35, 10 August 2012 (UTC)
Also, regarding the sorting argument for using numbers first: I was the one who originally proposed that, but I overlooked the fact that sorting won't work unless we use padding (e.g. "0001: Comic title"), which is kind of a hack. MediaWiki supports category sort keys natively, so we should be taking advantage of them rather than relying on a specific page title format to achieve the same effect.
As for the namespaces, I think I've presented my arguments for that above; let me know if any of them are unclear. I accept that one may disagree with them, but not that there aren't any benefits. Note that nobody will correctly seach for whatever page title we use, unless we use only the numbers as the final title, which I think we all agree is not desirable. --Waldir (talk) 11:25, 11 August 2012 (UTC)
Thanks for the double-redirect explanation, Omega. To Waldir; I think people would also correctly search for Comic Titles, at times. Some more than others, for sure. But if you are on XKCD reading a comic that has a title printed, and you want to come here and read the explanation, You would most likely search for either the number or the title that is displayed at xkcd.com. That said, if it's not a resource hog, and we can find a GOOD way to create links to comics easily (ie: I can type in {explain|123} and actually get a proper looking link to that comic's page, I'm cool with that. I really think it will add a lot of time to the edit process to have to manually type in 123: Title for every link to another comic. TheHYPO (talk) 14:32, 13 August 2012 (UTC)

Comic Display - another new template

I see that the latest comics have changed over to {{comicbox}} from {{comic}}. This might be in response to today's tall narrow comic. I don't see any recent discussions about the {{comicbox}} template. We really need to come to some form of consensus on the comic display issue. I am really not a fan of the {{comicbox}} template, as I arrive at the homepage today and I don't understand what I'm seeing. There is no indication that the text on the right is the Explanation. I wasn't sure if part of it was title text or not. I figured it out, but it's not the easiest thing to see. I also don't think the navbuttons jutting right up against the top of the comic display box looks good.

Eithe way, where I'm going with this is that I think we need to come to a consensus on the form and template used for comic pages. If we choose comicbox, or comic or some other template, it's all good; but we should be editing ONE template to get it working and looking the way we want; rather than bouncing between many templates and creating new ones. TheHYPO (talk) 16:26, 10 August 2012 (UTC)

Yeah, I was really confused at first, and scrambled through the discussions trying to find what happened. To be honest, I'm more of a fan of the {{comic}} template, with the explanation under a header explaining so. Not to mention with {{comicbox}}, I'm suddenly unsure of what to do with the transcripts. For comparison, here is the {{comic}} template, while here is the {{comicbox}} template. At any rate, no matter what template we're using (I personally prefer {{comic}}, but don't really care that much provided all comics use the same template), I agree that we need some kind of consensus to determine how we're formatting the page. Omega TalkContribs 21:31, 10 August 2012 (UTC)
Ditto on the confusion (augmented by the confusion of finding where the pertinent discussion has gotten off to; they seem to slip from page to page between visits... ) Anyway, I'm guessing this is a de-gustibus matter, but regardless of the respective virtues of either template, to my eye the template today's comic was changed to has a couple cosmetic shortcomings:
  • The typeface is larger than normal. Just a personal preference, but it should be scaled 100% vs adjacent normal wiki text; readers can change the level of zoom if that's too small. Also,
  • the image is vertically centered, so in the case of a disproportionately long explanation (like today's) it appears too far down the page; it really needs to be top-aligned, with the title text close underneath it. Further,
  • for this vertical layout, there's a lot of wasted vertical space when the explanation is so much longer than the image. Rather than having two rigid columns, have we considered float:left or float:right style attributes on the image, so that whatever text is left flows to fill the entire space below the image?
Finally, to tie this all up with a bow, (and perhaps raising an issue that may have been raised before; I don't recall, because of the shifting locations of discussions hereabouts) ... Is there a need for images to always be shown at 100% size, especially for the more extremely sized ones? Seems to me that the images here really only need to fulfill a refresher role, and clicks through the image should take the reader to the full-sized image on xkcd.com. Legally, I know we have the right to host the images here. But morally, it seems like we shouldn't be taking too much traffic away from xkcd.com as it is RM's bread and butter. Our value-add is the in the form of explanations: long as we can visually tie these explanations with the comic (by having something bigger than a thumbnail, but somewhat smaller than full size, especially for odd-shaped ones) I think we're on the positive side. Thotz? -- IronyChef (talk) 05:23, 11 August 2012 (UTC)
I agree with you on all points, although I'm really not a fan of having the text either beside or under the comic. I'd rather it be the same in all cases. In which case, having the text beside the comic won't do, as wide comics wouldn't be very supportive of that. Also, if the explanation is considerably longer than the comic, it just looks a bit strange to me. Float left/right would fix that, but would be a bit harder to implement with the title text (eg, if the title text and image are inside a float left div, does that div have a fixed width or does a long title text push it over?). All in all, I'd rather the text always be below the comic. It's consistent and less problematic. Regarding the size of comics, I'd rather we use the full size in all cases except the "large" comics (defined as the comics that are shown at a reduced size on xkcd itself, such as 1079: United Shapes). Why? Because when I'm reading an explanation to a comic I don't understand, I'm constantly referencing the explanation with the comic itself. Having to open a new tab each time would make that a bit less convenient. Omega TalkContribs 06:38, 11 August 2012 (UTC)
For visual experimentation, I've made the theoretically uncontroversial changes of text size (it's now expressed as relative percentage rather than absolute px) and I made the image top-aligned, so comics like xkcd 1093 show the image near the top of the explanation, despite the explanation being many multiples of that image's height; we can change that back if we don't like them. There are other changes I'd like to make (see above) but I'll wait for general agreement on that (not to mention which template to use.) -- IronyChef (talk) 15:39, 12 August 2012 (UTC)
To respond to all of the previous comments; I echo IronyChef's thought - I built into {{comic}} an imagesize attribute because I believe that the comic should be a managable size on this site; generally not more than say 400px; this creates a "click to enlarge" link which takes the user to the imgae's page. Although I previously thought that a balance needs to be kept because people may start coming to the wiki to read xkcd in the first instance instead of xkcd.com, I also agree with Omega's point that it's potentially unfair to Randall to entice traffic away from xkcd.com. This strengthens my belief that larger comics should be kept to a reasonable size.
Not sure if I said it in this thread, I think we have to look at the purpose of the box itself. In my eyes, the box is designed (like an infobox) to basically show the user the basic facts. Not user-added material or encyclopedia text. The box, in my view, is there to present all of the info about the comic that actually comes from xkcd. The image, the alt text, the title, date and number. Adding the explanation in the box basically makes the explanation look official as part of the comic. The primary content of this site is the explanations. If anything should go under proper wiki-format headers, it's that (in my opinion). The transcript is technically official content, but as I've said elsewhere, in my view, the transcript is secondary info that the comic already contains; it doesn't need to be in the infobox. IronyChef has indentified and fixed a lot of my minor cosmetic issues with the comicbox template, and there are others I don't like either (the title font is a little too weak and the top of the box is touching the bottom of the nav buttons. Don't like those, but again, easily fixable).
I also think while there may be instances like the "Forget" comic which is a list-form comic where having a long vertical list explanation works, a long vertical list is often harder to read and follow than a full-page-width explanation. (even "Forget" has each line of explanation end up being several lines long in {{comicbox}} format.) Worse, the potential to want to fit in the box may limit users from adding to explanations which we shouldn't encourage. If the explanation is twice as long as the comic, there's nothing wrong with that, and it shouldn't look bad by going inside the template. I appreciate the attempt that the verticle comicbox makes to not waste space (using the two-column method) but I don't think this is the way to do it. I think shrinking the comic (and accepting that there will be space on either side) is the best way. As I say, 375px or 400px seem like logical limiters for most comics. This is explainxkcd, so you shouldn't have to scroll way down to get to the explanation. I too sometimes like to view the comic and explain at the same time to check notes as Omega suggests, but I can do that by control+click or shift+clicking the image to enlarge, and comparing in separate windows by tiling them or just switching back and forth - with a larger comic, you'd have to scroll up and down to read both the comic and the explanation anyway. I find I lose my place in the text when I do that. alt+Tabbing for me generally is easier to keep my place in both windows.
The one thing from {{comicbox}} that I do like is that the box is shaded slightly bluegray. I like the separation that creates; on the other hand, xkcd.com has comics posted on white; does it hurt the integrity of any comics to have them posted on blue-grey instead of white? I'd consider changing the background of {{comic}} to a blue-gray (though perhaps lighter than the one on comicbox) if people like that. That's my thoughtsTheHYPO (talk) 15:10, 13 August 2012 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── {{ComicBox}} just got a major redesign. It looks more like {{comic}}, but with the addition of a vertical comic mode. Also, bear in mind that {{comic}} doesn't use white for the background. For comics like "Forget", take a look at Forget comicbox. Looks ok? --Grep (talk) 15:27, 20 August 2012 (UTC)

As noted on explain xkcd:Community portal/Proposals#Comic Templates, there is no need to start a new thread there there there is already a thread on the topic here (which you've posted to). Also, if your post was "which template should we use when?" it's not really a "proposal" for the proposals page, and better fits here under coordination.
That said, I thought this topic was fairly well resolved. Jeff endorsed {{Comic}} in the #Header_template discussion on this page, and this subsequent discussion seemed to resolve as well with no real consensus that a change from {{comic}} was necessary or beneficial. I don't see the benefit of continuing to build new templates that basially duplicate existing templates with one extra function (vertical mode). That could have been built into the existing template, if it were deemed necessary.
I personally think there are still pluses and minuses to doing things vertically; It looks a little cluttered to have the comic up on one size and the explanation on the other. If you don't have a high-resolution desktop or you want a non-maximized window, there may not be much space for the explanation which may end up with two or three words per line and be hard to read and annoying. "Forget" was a comic featuring a long list; this made for a very long listed explanation. Most long comics will not have explanations longer than the comic, and we'll have a lot of whitespace to the right of the comic. It just looks cluttered to me. I like having the navbar centered above the comic, not the page (and also in the enclosed comic box). That's personal preference though. I think the better design for vertical comics (is just to reduce their size and put them in the standard box. They otherwise take up too much space. TheHYPO (talk) 16:48, 20 August 2012 (UTC)
  • I am not a fan of the discontinuity that comicbox creates as the explanation runs longer than the image. I also feel that we should focus on improving the existing {{comic}} instead of further developing new templates. - Shine (talk) 21:38, 20 August 2012 (UTC)

Template for New Comics

To clarify, I'm not talking about a template like {{comic}} or {{comicbox}}, but rather a form to cut/paste for new comics. I'm rather new to large editing of MediaWiki pages, so I'm interested in learning of better ways of doing things.

Recently, I've been copy/pasting User:Blaisepascal/newcomictemplate to set up the basic form of the page, then editing the various sections. This ensures I get the major bits. I still have to copy/paste the transcript from xkcd.com, fill in the {{comic}} template, and make the number and title redirects by hand.

Is there a better way? Is there anything my template is missing? Blaisepascal (talk) 14:06, 21 August 2012 (UTC)

I've created a ruby script that can be given a comic number and it will spit out a text file with the comic template filled out, the transcript, and the comic discussion template. I've finally gotten it to the point that it is usable, so that's why I'm talking about it. It still doesn't pull explanations from the blog, but that's a whole ball of wax in and of itself. I'm on Linux so it's easy to run it and have it spit out files, I assume on Windows if you have ruby installed there is a way to run ruby scripts from the command prompt. Can't tell you where things will pop out, probably in the directory you run it in, but I haven't tested it on Windows yet. I'm also continuing to work on it, so don't assume that any version you download is the final product. Oh, it also spits out the redirect line you put in the number and title pages so you can just copy/paste that.
I made it because I was going to drive myself insane making hundreds of pages without some kind of automation. lcarsos (talk) 07:24, 25 August 2012 (UTC)
{{create}} was created as a template for the comic list so that it could be autoloaded into comics by linking from List of all comics. That functionality doesn't seem to be working, unfortunately. For that reason, I added a "transcript" of the create text as documentation on that template. If you goto {{create}}, you will find a template for new comic creation. TheHYPO (talk) 20:20, 27 August 2012 (UTC)

The name of the ponytail character

I remember the community having a name for the female ponytail character (I don't recall if there is a male ponytail character, but in the interest of being complete). Was it simply Ponytail?

In any case, she seems to recur enough to deserve her own Category:Comics featuring ... page. But I don't want to go create it without knowing what we can agree on is her name. So, pony (wow, didn't intend that pun) up your 2 cents. lcarsos (talk) 17:28, 20 August 2012 (UTC)

This comic http://xkcd.com/322/ calls a ponytail'ed female Joanna. Is this the same character as ponytail? She might be different. Community input please. lcarsos (talk) 01:26, 23 August 2012 (UTC)
It sounds plausible. Few of the characters are named, and it looks like Ponytail (compare, for example, Elaine Roberts as an adult, who has light hair, but doesn't wear it in a ponytail). The one concern is that in 322, she is clearly acquainted with Black Hat, and in 405 she appears to be friends with Danish, yet Black Hat and Danish don't know each other -- unless he tracked her down via Joanna... Blaisepascal (talk) 04:41, 23 August 2012 (UTC)

The name of Black Hat's girlfriend

Black Hat has a girlfriend, introduced in 377: Journal 2. She has thicker hair than Megan, and is seen (in 405: Journal 3 to be friends with Ponytail. Is there community-accepted name for her?

No, not yet. She seems to have a personality similar to Black Hat himself --Jeff (talk) 15:48, 22 August 2012 (UTC)
I don't really want to create a "Category:Comics featuring Black Hat's girlfriend" if there is a better solution, that's all. Blaisepascal (talk) 15:57, 22 August 2012 (UTC)
In my own head I've been calling her Summer because she looks like how Randall draws Summer Glau (not a good argument, granted), and in some of the comics she shows up she reminds me of Summer's characters. lcarsos (talk) 17:41, 22 August 2012 (UTC)
Or we could call her Dearest or Darling or Danish http://xkcd.com/515/ lcarsos (talk) 20:32, 22 August 2012 (UTC)
OK, I've gone with Danish. Blaisepascal (talk) 22:18, 22 August 2012 (UTC)
P.S. I love you for that. You have my eternal respect. lcarsos (talk) 22:35, 22 August 2012 (UTC)

Also, now someone needs to update the Characters nav box to include Danish. lcarsos (talk) 22:51, 22 August 2012 (UTC)

I found the template on my own (aren't I a grown up professional?) and updated it. lcarsos (talk) 22:53, 22 August 2012 (UTC)

Can we turn off page creation for non-logged in users

I'm not very familiar with mediawiki, so I don't know if this would be hard or not. But, it would stop the drive-by spam attacks (the ones that don't create accounts anyway, such nice bots).

My secondary goal in doing this would be to get ‎72.252.145.183 and ‎207.204.86.3 to make accounts so that there is a way to get a hold of them, give them some feedback, and have them stop adding/spamming spurious categories. Both of them are creating pages with poor/non-existent explanations, sections for the transcript but missing the transcript, haphazardly adding pre-existing categories and adding tons of one-off categories which do nothing to enhance explain xkcd.

lcarsos (talk) 19:02, 13 September 2012 (UTC)

Tag any such comics with {{Comic-stub}} and you or someone else can fix it ^^--Relic (talk) 00:01, 24 September 2012 (UTC)

Tagline categories!

It finally struck me that there's that great line sitting top-right on the xkcd site. Yes the tagline. So, I've created pages for Language, Romance, Math already existed. But, I don't have time right now to go hunting down examples of Sarcasm. Can I enlist the help of all the beautiful editors here to go tagging crazy? (Ok, not crazy like insane, but please do comb through everything for these) lcarsos (talk) 19:47, 22 October 2012 (UTC)

Image updates on xkcd

Once in a while, Randall changes the image of a particular comic (usually after someone here spotted an error!); for instance, that is the case for xkcd 1122 on Electoral Precedents. It would be nice to still be able to see the original image(s) here as well as the updated version, as the discussion usually references the previous version(s) and therefore sometimes doesn't make sense without the original image in those cases. Also, consider this as a mild suggestion to update the mentioned image on its explanation page. Sorry if I've put this in the wrong place... --Jay (talk) 14:54, 29 October 2012 (UTC)

For these most recent comics, someone usually uploads the version that goes public at midnight, and then corrections are uploaded on top of that. As part of the MediaWiki software, you can click on the image, which will take you to its file page, which allows you to see all the versions of the image back to its first creation. I, personally, am not sure if it's possible to link directly to a previous version, but it is there at least.
Unfortunately, due to an image resizing bug, (that we all hope is being worked on, but it's been months with no progress and no word of work or progress, so hope is dwindling) for larger images you won't be able to see it, until you click on the broken file link which will just take you to the image.
Hope that helps some. --lcarsos (talk) 16:35, 29 October 2012 (UTC)

The Great Spam Attack Of Thanksgiving 2012

I believe I have now dealt with all the spam that has accumulated on the wiki. I've gone through Recent Changes and personally checked every anonymous edit since 5 this morning, and looked through every new page created. If I've missed something, please edit the page and put {{spam}} at the top. Thank you to all the new editors that stepped up and went to work in the trenches while the rest of us were off stuffing our faces. I think special thanks goes out to St.nerol and TheOriginalSoni. I believe what happened is, the first major attack was met with a tepid response of about a month's temp block for all the IPs. But this time, for the flagrant vandalizers they are now on an indefinite ban.

Please, as you continue to notice spam or vandalization, use the {{spam}} template, or add Category:Pages to delete to the page (in the event that it's a newly created page). Leave a comment in your edit summary about vandalization clean up and someone with the power to, will deal with it.

--lcarsos_a (talk) 06:38, 24 November 2012 (UTC)

Marked a wee bit that you missed. Typical, I take a day-long trip into China and an unholy mess of spam happens. May I suggest captchas for all anonymous edits for now? I would also like to get all the explanations done, or at least the ones from the blog, so that we can get the /wiki/ out of the URL to throw some of the spammers. The wall-of-text spammers all seem to include links to spam on other poor abused wikis, and I've noticed that all of those wikis also have a /wiki/ somewhere in there URL. It probably won't stop the new anon spammer, but we could probably restrict page creation to registered users only once we're done filling in all the old XKCD pages to cull those twats out too. Davidy22(talk) 09:27, 24 November 2012 (UTC)
I have again dealt with the second wave of spam this Thanksgiving holiday (in the U.S. It's the only thing I can think that would be the cause.) and protected a few pages that seem to be repeat targets. If this is any indication of what major US holidays are like we need to get the administration (*ahem* Jeff) to delegate more controls to more users, and more A.I. spam fighting than we currently have (none). There has to be tricks that Wikipedia is using to fight spam. If we get this much, I can't imagine what the wikipedia servers have to daily stand up against, they must have spam fighting tricks, and not just hordes of people that can delete new pages that anonymous spam bots create. lcarsos_a (talk) 07:13, 25 November 2012 (UTC)
Wikipedia has cluebot, which looks at page blanking and text insertion by anonymous users and reverts suspicious behavior automagically. I could ask cluebot's creator if we could lift the code for use here. It'll be like XERXES.ai, except it'll look for spam instead of spelling errors. Davidy22(talk) 07:16, 25 November 2012 (UTC)
Aight, so Cluebot runs off a core engine with a dataset of previous vandalism to work from. We can set the files up on a raspberry pi or something, leave it running and connected to the web and feed it a backlog of past spam to teach it what to look for. Gonna do it after this hellish pile of work is over, unless someone wants to ninja me again. Davidy22(talk) 07:50, 25 November 2012 (UTC)
Cluebot sounds like a wonderful thing to have around here. When I have free time I might try to develop a basic bot that catches the basic kinds of spam and vandals we see here. (Spammers create a user account, create a random page and link to a random page on the internet; Vandals almost always leave an 18 character mixed lower/upper alphanumeric comment and are anonymous, that's unique enough it should be easily catchable)

Personal tools

Variants
Actions
Navigation
Tools

It seems you are using noscript, which is stopping our project wonderful ads from working. Explain xkcd uses ads to pay for bandwidth, and we manually approve all our advertisers, and our ads are restricted to unobtrusive images and slow animated GIFs. If you found this site helpful, please consider whitelisting us.

Want to advertise with us, or donate to us with Paypal or Bitcoin?