explain xkcd:Community portal/Technical

 Create a new topic!        Refresh

Technical Technical issues about the explain xkcd wiki, including bug reports, site stability, or requests for new gadgets or features. Create a new topic!

This page has archives. Discussions are usually archived after they have remained inactive for a long time or they are no longer relevant. Archive 1 Archive 2 Archive 3 Archive 4

Blue on blue links

RationalWiki links have a light blue background for some reason. Example: xkcd Artem (talk) 16:34, 7 September 2026 (UTC)

That's to distinguish them from non–RationalWiki links. FaviFake (talk) 16:35, 7 September 2026 (UTC)

Does anyone know why RationalWiki (and TvTrope, apparently) need a separate background to distinguish them? Celene (talk) 04:47, 19 September 2026 (UTC)

When it comes to TVTropes, I believe that it's supposed to be a little extra precaution to warn the unsuspecting impending clickee that TVTropes Will Ruin Your Life. (Right now, I can see four TVTropes tabs showing upon my browser's header, in amongst other things, and I now there are more of them if I scroll the tab-bar sideways.) It's a particularly strong generator of extended (and branching!) wikiwalking sessions.

I'll have to admit that I'm not quite so familiar with RationalWiki, but I could imagine a similar feeling about that. 78.151.45.228 19:11, 19 September 2026 (UTC)

Another option would be to use favicons next to the links – I've contacted the staff of both websites to get permission to use their logos for their links, as TVTropes's logo is under the same license as the rest of the site, and RationalWiki's logo isn't licensed at all. Chaotic Enby (talk) 19:46, 21 September 2026 (UTC)

I sort of get the "use an icon marker" idea for various external sites. But text-based icons embedded in text can cause their own potential confusion, as can be currently seen in a link to C which could arguably be mixed up with a link to something like The CW. Except that "CW", itself, will now look like "CW^W", of course!

The request to get the "W-letter in a jigsaw piece" picture rendered as the 'hint' might be better but... consider how small the icon is, and thus how few pixels you have available.

I presume the TVTropes logo will be just the "TV-letters with a lampshade hanging", if you go ahead with that. Maybe slightly easier to rough out a version of. I'm not sure that the "Brain within doubled square brackets. The brain is difficult enough, even if the four distinct brackets can be reduced to the minimum pixels.

• Edge (zero pixels padding?),
• Just 1 pixel for first riser,
• 1 more pixel for the 'hooks',
• 1 more pixel for gap between brackets,
• 1 pixel for next riser,
• 1 pixel for hooks,
• 1 pixel for space (if not kerned away thanks to the curved Brain edge?),
• enough pixels for a brain (less overlap as immediately above/below),
• (Maybe) 1 more pixel each for space,
• Then 1 more pixel each for closing hooks/riser/space/hooks/riser.

That's a minimum of 10 pixels. As rendered on this particular machine (YMMV), the current "W" for Wikipedia takes up 14 pixels (antialiased, but a viable non-antialiased version may be no different, to get the same look just rougher looking). To look a similar size, the [[Brain]] would have room for no more than four pixels of width for the 'Brain matter', I expect, even with the kerning in mind.

Of course, the true icon being used is likely not 14 pixels wide. In fact, as I easily discovered, it's non-raster .svg image that is apparently being officially rendered as 12px wide. Despite how it appears to be 14 for my default view (which I screenshotted and examined in detail within an image editor). Automatic antialiasing as well as designed-in shading/colouring in strategic edges can probably create a better image than a harsh monochrome image with a single bitplane of display depth. But it's not exactly going to be easy to artfully create a comprehensible glyph that represents a W-JigsawPiece, the lampshaded-TV or the brain-in-the-[[]]s. The best you can probably hope for is a half-decent clump of pixels that mark out something special in a vaguely recognisable way, and that people will learn to recognise as "Oh, that's a <foo>-type link!" from sufficient hovering/following and discovering the details. And I'm not sure it's worth all that bother to try to do that for every possible example, or even every well-used destination.

(For starters, archive.org might deserve its own, due to the number of times old and dead (or older versions of live) pages are now linked to through that. A four-columned Greek acropolis-like frontage... actually far easier to artify, I think, just had a private go at a 12px-wide conversion (of the logo without its lettering) and I think it's recognisable. At least once you know it's supposed to be archive.org in some other way.)

But, despite having found you a better example to try for, I'm still not sure it's a necessary development. Anybody who cares about where they're going are going to keep an eye on the bit of the browser where the link you're about to go to pops up (as defined by the particular browser). Any random link like http://www.example.com (or as alternate embedded text) gives a generic "this is going off this wiki page" glyph. Cross-wikiproject links have generally been treated the same as links internal to the wiki and so have been unglyphed (perhaps depending upon how linked!), while those wiki-style places like 'tvtropes' and RationalWiki that have honorary wiki status have been made marginally different looking in an unglyphed way.

About the only good reason to insist upon glyphing each and every link is to make a sea of blue text a bit more obvious as not one long link that's a sea of blue text. But, as just discovered, perhaps you need a suitably-simplified Wiktionary logo too, if you're going down that route?

Just pondering aloud, though. I'm not particularly arty myself (I'm not particularly skilled in creating it, I just more know it when I see it), and perhaps have too much of a technical approach to this issue to be taken seriously in this regard. But the few immediate thoughts I had, unfortunately not easy for me to express succinctly in word, seemed perhaps worth mentioning? Maybe not, in which case ignore me. 81.179.193.245 13:40, 22 September 2026 (UTC)

Are there too many W symbols? Now it looks like hiccup when reading articles 799571388 (talk) 07:59, 23 September 2026 (UTC)

Agree. Can we please get rid of it again? It disturbs the reading flow massively. Elektrizikekswerk (talk) 07:59, 25 September 2026 (UTC)

@Elektrizikekswerk We are planning to replace it with a better icon developed by @AltaKarl, which you can view in User talk:AltaKarl. It should disrupt the flow of the text less as it's not just a "W" letter. FaviFake (talk) 13:34, 25 September 2026 (UTC)

Just replaced the icons! Of course I'm ready to remove them entirely if consensus goes that way, by the way. Chaotic Enby (talk) 21:43, 26 September 2026 (UTC)

Yes, this looks much better and isn't as disruptive as a letter. Thanks! Personally I'd prefer having no icon at all but I can understand the demand to see where a link leads to at a glimpse. Elektrizikekswerk (talk) 09:00, 28 September 2026 (UTC)

Mobile version of this website

This site does not appear to have a mobile version when I access it on my phone, so I have to zoom in to see text. Is this something others experience the same? And if so, has there been discussion around introducing support for mobile browsing (which is likely nearly half of visitors at this point)? Sdkb (talk) 18:59, 14 September 2026 (UTC)

I agree, I think we should try to improve the mobile experience, similar to Wikipedia's mobile skin. FaviFake (talk) 09:40, 15 September 2026 (UTC)

(Noting just for the record that discussion about this has continued in the #technical channel of the Discord server.) Sdkb (talk) 15:21, 7 October 2026 (UTC)

... which is at explain xkcd:Discord. FaviFake (talk) 22:07, 7 October 2026 (UTC)

Random button broken?

last year, i pressed "Random" on ExplainXKCD, and got 3105: Interoperability 3 times in a row. this year it seems to only show me comics i have already seen.
i think it should be an RNG 1 to <insert current highest comic number here>. would that be too complicated? 2605:59C0:450B:3410:CD7A:EFE8:A9E1:E727 16:47, 29 September 2026 (UTC)

'𝘞𝘩𝘢𝘵 𝘐𝘧?'

Moved from EX:CPP#'𝘞𝘩𝘢𝘵 𝘐𝘧?'

Why does the sidebar's What If? link use the mathematical sans-serif unicode characters, instead of just italicising the normal ascii letters? 2A00:23EE:1070:279D:F5E4:A5AF:8839:E006 11:14, 1 October 2026 (UTC)

Because Waldir, the editor who tried to make it italicised, was unable to do it using standard wikiformatting. Maybe @Chaotic Enby will be able to save us??? FaviFake (talk) 21:51, 1 October 2026 (UTC)

 ✓ Resolved : we now use the site's CSS after Special:Diff/419652/419638 FaviFake (talk) 14:25, 10 October 2026 (UTC)

Auto-purge comic's explanation page when discussion page updated

When I edit the discussion for a comic, the change isn't immediately reflected in the comic's explanation page. If this will take awhile to implement, consider adding a manual purge button to the explanation pages, something like https://www.explainxkcd.com/w/index.php?title=3312:_Momentum_Demonstration&action=purge. 64.201.132.210 16:33, 16 October 2026 (UTC)

Weird - there used to be a 'Refresh' option at the top of the comments until quite recently - hadn't noticed it had gone til now. 86.22.132.121 16:45, 16 October 2026 (UTC)

Very recently I did discover that a Talk-reply of mine hadn't popped up yet. I did something to make sure that it was actually there, but I forget what.

Yes, there used to be a "Refresh"-style link, in alongside the "Add comment" above the Talk-inclusion of each main comic-page, but not sure if that survived the transition to the new server, a few months back, or if it then got lost due to other Executive Redesigning decisions done after that point. However, I think I might have just "Shift-Refresh"ed at the browser level to kick-start the appropriate level of page-caching into recognising the updated nature of the transclusion.

Though I can probably count on the fingers of half a hand when I ever needed to use the embedded cache-refresher, during the old server's era. Probably used it more to debug various oddnesses (like when image-thumbnails started glitching and giving only red-text links on an on-and-off basis, which was a major issue at one point). Never really noted any amount of the Talk-transclusion ever being tardy, like above. And can only guess how it has become something now happening to not just me. 78.151.45.31 18:34, 16 October 2026 (UTC)

Yes, I recently removed that button because having three buttons there broke the display on the new mobile skin we're developing, Minerva Neue. Didn't think anyone would notice.

• You can just open the talk page to see the newer comments.
• If you want the button back, you can simply enable it in your preferences. Go to Special:Preferences#mw-prefsection-gadgets, enable the "Purge" option, and click save. There'll be a fancy new asterisk button on the tools section of your sidebar.

FaviFake (talk) 01:03, 17 October 2026 (UTC)

Allow non-logged in users to create user talk pages

I tried to put something on a user's non-existent talk page but couldn't. I would up putting it on a relevant comic's talk page. 2603:8081:9700:1224:0:0:0:1 06:19, 22 October 2026 (UTC)

I don't think that would be possible, or necessarily desirable. It would mean giving possibly global page-creation rights to everyone, and swing the door right open to potentially unlimited page-creation-spam. Even if it's somehow restricted to "User Talk: <registered user>" pages, which I'm not sure is viable, I can still see several problems. It is something I know I have had to deal with, but I'd rather not have this ability than risk everyone having it.

The standard response is very probably "get an account" (and then get to autoconfirmed status for that account). And, I think totally without hypocrisy, it would be my suggestion too if this page is something you really want to create.

But I'm wondering how much it'll help to talk to a user who hasn't bothered to create a User Talk page, or even the User page that it goes with. Or have asked for it/them to be created, before their own autoconfirmed status. They may or not be keeping an eye on this site, or have manage to arrange to be notified by email that your message has appeared on 'their' page. It's a tricky situation, and I don't think there's a good universal solution of any kind. 92.23.2.123 19:03, 22 October 2026 (UTC)

Consider the status of the line-feed from the inline "Reply" option.

When replying to Talk-type pages, or indeed in here, the 'old way', you would typically put your response on the very next editing-line within the source editor. And manually add the colon (or one more than above) to indent it.

The behaviour of the "Reply" tag, made available just beyond the signature of a prior contributor will deal with the indents for you, without any need to make it consistent, and even tends to place it in the right place where you're not the first reply at 'the next level' from something. But it's also liable to save it 'to source' with an extra linefeed.

This extra linefeed is not in itself a problem. With non-coloned prior-and-next line combo, you need the extra linefeed gap to make it not run straight on from the prior to the next, but it does not really matter when it goes from a ":" to a "::" (or a "" to a ":"), or even becomes a further ":::" beyond a prior "::" to ":::" response. But I've noticed that there have been a number of edits that just remove the empty line before a Reply-tagged response. Why not? But also... why? Perhaps time and edits could be saved if the server-defaut inline Replying behaviour did not add the superfluous linefeed. And I can't think of any times they 'aren't superfluous, but I'm sure someone will pipe up if they think there's a good technical reason.

(I note with amusement, that using the Add Topic option at the top of the page also now does an 'inline' edit. And of course means I need to put in the inter-paragraph gaps. Or another method, like a br-tag. Like I'd have to have done in the edit-page version, or else just get a long run-on paragraph. But it's even more obvious as it appears dynamically below this edit-window, but also now less instinctive to do so by myself until I notice.)

Either way, it's hard to deal with the 'unnecessary' linefeed-removing edits, as it seems they're often done by IPs. (Not me.) Trying to tidy things up, I presume. Not sure what message could stay their trying-to-be-helpful hands and save them the time. Unless they're just trying to bump a Talk page, for some reason. 92.23.2.123 19:28, 22 October 2026 (UTC)

That is part of the DiscussionTools extension, for which the behavior of the "Reply" function can't be configured on individual wikis beyond choosing between indents and list bullets. Surprisingly, it doesn't work with wikitext directly, but with the HTML output that is parsed back into wikitext, which might explain some of the edge case behaviors. Chaotic Enby (talk) 08:36, 23 October 2026 (UTC)

No way. Seriously? Why doesn't it work with wikitext directly? FaviFake (talk) 16:53, 23 October 2026 (UTC)

This page has some explanations, although I'm not fully convinced by the cost-to-benefit ratio. Chaotic Enby (talk) 18:23, 26 October 2026 (UTC)