(07-17-2026, 02:31 PM)robkelk Wrote: Some of our work pages (for example, our page for Oliver Twist) have "Infobox book" on them, and some of those infoboxes have entries in the fields "wiki URL" and "wiki name". The new "Work" header has fields for "fanwiki" and "fanwikiname". We should move the data from the infobox to the header template... and I suspect that this is something that a bot could do.
No rush, even though this would show off some of the new header's functionality. We would have to identify which infoboxes have the data present before moving it from template to template, after all.
A bot could do it, but we could also be lazy and have have the Infobox template write the tabs to the Bucket, then at least the subpages would have the tabs.
In other news, I did some research on writing an extension to copy short descriptions into category display, and it seems pretty easy. I have a couple pages of untested code that I think will do most of the work, and I just have to write some boilerplate and test it. I'm sure I could harass someone to do security review for 70 lines pretty fast.
The main idea on all of that was going back to how TVT did categories in the old days. (I have no idea how they do it now; I have not been on their site in over a decade, and have thus never agreed to any new ToS there.) It used PmWiki traces, which is basically a template that added every link therein into a category in order. I suppose with things like Bucket and a bunch of time, I could reimplement precisely this, but it's not really in the thought model for MediaWiki itself. It's a little spooky-action-at-a-distance, and a little DB intensive. But a plain list of links in a category is also not informative. Say I'm looking for a trope in Category:Heroic Sacrifice Tropes and I'd like to know at a glance what is the difference between Stupid Sacrifice and Senseless Sacrifice?
Does the page popup help? Well, kinda, but not really. (I may also change the code to the page popups, but that's another thing.) But having summaries here would be great. For places where you don't need to explain why it's a member of a category, just what it is at all. Like, it's not useful to explain why Love Hina is in Category:Shonen Demographic -- the reason for genres is always "this work uses a set of tropes common to the genre, which are listed on its trope page, and the tropes themselves are probably enumerated on the [genre] tropes category". But it would be useful to describe the work itself here a little.
07-18-2026, 02:38 PM (This post was last modified: 07-18-2026, 02:50 PM by robkelk.)
I just made a small change to List of Works That Need Summary/Film.
Specifically, replacing the hardcoded "present this in three columns" code in the section "Film (Animated)" with the div col template set to present the content in columns that are 400px wide. The change lets the browser determine how many columns to use based on the width of the browser window, thus letting the page show with two columns on my cellphone and five columns on my desktop.
We've had "div col" on ATT for years, so this isn't new.
Should we use the template to present other lists, or is there something even better for browser compatibility that we should be looking at, or should we just continue with the status quo?
If we are going to use it, is the column width the one we should use?
-- Rob Kelk
Sticks and stones can break your bones, But words can break your heart. - unknown
At least on the ATT page for Gilligan's Island, the list of subpages has extra text, which means all of the page links are greyed out. Instead of "Gilligan's Island/SUBPAGENAME", it's showing "Gilligan's Island/and/SUBPAGENAME".
-- Rob Kelk
Sticks and stones can break your bones, But words can break your heart. - unknown
We've also got a DISPLAYNAME issue on Useful Notes pages -- I've spotted it several times today/this evening:
It looks like somehow, somewhere we have a default DISPLAYNAME set up for works that the {{Useful Notes}} template is trying to override?
-- Bob
I have been Roland, Beowulf, Achilles, Gilgamesh, Clark Kent, Mary Sue, DJ Croft, Skysaber. I have been
called a hundred names and will be called a thousand more before the sun grows dim and cold....
(07-18-2026, 10:30 PM)Bob Schroeck Wrote: We've also got a DISPLAYNAME issue on Useful Notes pages -- I've spotted it several times today/this evening:
It looks like somehow, somewhere we have a default DISPLAYNAME set up for works that the {{Useful Notes}} template is trying to override?
That was a problem with Useful Notes being work-like, but not needing italic titles... and me not realizing how to turn it off correctly. Fixed yesterday. I may do a less hacky solution later.
(07-18-2026, 08:37 PM)robkelk Wrote: I just noticed a bug in the new Work header.
At least on the ATT page for Gilligan's Island, the list of subpages has extra text, which means all of the page links are greyed out. Instead of "Gilligan's Island/SUBPAGENAME", it's showing "Gilligan's Island/and/SUBPAGENAME".
Ah, the apostrophe bug rears its head again. In this case I looked at the code of Extension:Subpage Fun and realized that all of the escaping gets disabled if I just have it wrap the pages in links instead. So now we just grab that, split our string by brackets instead of pipes, and away we go. I think it's a tiny bit faster this way which is funny.
(07-18-2026, 02:38 PM)robkelk Wrote: If we are going to use it, is the column width the one we should use?
In general, column-width is better for responsive design than column-count, though you can use both. column-width is a minimum width, so the each column will never get smaller than that on small screens. column-count is the number of columns -- or if you're using a width, the maximum number of columns. Categories pages use both (as they are now, my extension may disable this later...)
07-21-2026, 11:57 AM (This post was last modified: 07-21-2026, 07:05 PM by robkelk.)
Just found another bug(? feature?) with the new Work header.
The first episode of the original Thunderbirds series is sufficiently notable to have its own Wikipedia page. However, setting the header on "Thunderbirds (TV series)/Recap/S1/E01 Trapped in the Sky" to {{work|wikipedia=Trapped in the Sky}} (or using "wppage=" instead of "wikipedia=") doesn't override the Wikipedia link on the subpage to point at the specific Wikipedia page -- it still links to the more general page set on the parent ATT work page.
-- Rob Kelk
Sticks and stones can break your bones, But words can break your heart. - unknown
That's a feature, yep. Or: it's working as designed.
What would be the expected behavior here? Add a second Wikipedia tab, add a sub-menu, or replace the main wikipedia tab on this page only? Any tracking categories for this (just the ordinary one, or a special one for subpages?)
(07-21-2026, 06:55 PM)Labster Wrote: What would be the expected behavior here? Add a second Wikipedia tab, add a sub-menu, or replace the main wikipedia tab on this page only?
I would go with "replace the main wikipedia tab on this page only", but I'm willing to be outvoted on this one.
(07-21-2026, 06:55 PM)Labster Wrote: Any tracking categories for this (just the ordinary one, or a special one for subpages?)
Don't know whether there's any "business" value to tracking this sort of thing.
-- Rob Kelk
Sticks and stones can break your bones, But words can break your heart. - unknown
Looks like we've got another single-issue meme poster. Unlike the usual posters of this sort, the meme actually exists and has a Know Your Meme page: John Rod. However, it's less than two weeks old.
My research isn't stopping me from playing dumb and asking for more information, though. That's so I can take a few minutes to ask what if anything our policy is about adding brand-new memes to ATT. Do we have one?
Same. Compared to the times we had deranged spammers of nonsense and idiots trying to sneak Nazi apologia onto the wiki, that just looks like harmless memeposting.
Sometimes silly edits become active editors, if it's not active vandalism, it might be worth welcoming the user.
Rob threw me a technical issue on his talk page, which was that Doug (who is definitely no longer a global steward, btw) wanted us to turn on a variable related to Visual Editor, $wgVisualEditorEnableWikitext. What does it do, even? Well, if you look at the extension doc page, using it does the "wikitext mode". If you search the other end of the page, you find out that "wikitext mode" enables 'the so-called "2017 wikitext editor".' Now, you have to resort to a site search to find out what this 'so-called' feature is... okay it's on a page called 2017 wikitext editor which basically a new frontend for wikitext. There's a way to hook in a syntax highlighter. Some gadgets don't work with this, but they probably do by now if they were developed for wikipedia.
So like, when is VE going to be ready for production? There are two answers to that that come to me right away, the first is that it's been in prod at Wikipedia for years now. The second is that there's a big "page under construction" banner at the top of the documentation page for how to configure the thing, that's been there like 5 years (or, more, that's when I got bored of looking at page history). The banner seems justified.
So, Doug mentioned this to us because it's his default editor in global settings, and because we don't have his default editor loaded, it breaks for him.
Also, Discussion Tools is the thing that most folks are substituting for Flow, even though they're rather different in page model and so on. They're kinda cool. You can see them in action over here, you get the Reply button and the Subscribe button and all. This requires Visual Editor. But right now, we only have that enabled in User talk NS.
Also, I honestly have no idea what you guys were complaining about when you wanted to disable VisualEditor. It didn't affect me, so I didn't say much. I can't find any edits that were screwed up by this, though I did find this old thing in the Moderation log... was that normal? What was normal. Could things be fixed now? I honestly couldn't say.
I think we could get away with disabling VE entirely from our last namespaces. Or we could try DiscussionTools on the talk namespaces, and re-enable VE there. Or we could try VE in general again? Or we could use their wikicode source editor like Doug wanted... or not. So I actually do not know what to do here, or even what to complain about, so I'm throwing this back to Rob to decide.
Mostly unrelated: I made a ticket to delete the Topic namespace, because Flow is never coming back, and unlike other NSes the delete button is conspicuously missing. There's no content remaining there, and if there was, the software wouldn't let us read it anyway.
