@Headbomb,HaeB,JPxG,Bluerasberry,Bri,Smallbones, andFeRDNYC: (and anyone else)... I have made this "technical" page so that we can at least have some shot at documenting what the hell is going on in the code here. It is in pretty rough shape right now, but it's a start. Whenever I find myself spelunking through some old template, I try to take a few seconds and write something down on there. Maybe, if we are just writing random notes, we could do it here on the talk page, and try to keep the main technical page condensed. Who knows. Anyway, regardless, I think this is a good central zone to keep track of what all is going on.jp×g21:51, 6 November 2022 (UTC)[reply]

Okay, this page is on my watchlist and I am aware of it for when it is needed. Bluerasberry(talk)22:18, 6 November 2022 (UTC)[reply]

Adding to my watchlist too. ☆Bri (talk)18:49, 4 December 2022 (UTC)[reply]

• User:Headbomb/New at the Signpost -- here is a summary of all the new changes for the Signpost... from 2019. Given the way that I have to piece all this stuff together, it is a useful link to have around.
• Wikipedia:Wikipedia Signpost/2015-06-24/From the editor

FYI, I've started wrapping{{Template other}} around tracking categories added by Signpost templates, to keep the templatesthemselves from being included in the category. So far I've hitTemplate:Signpost/Deadline andTemplate:Signpost draft. The invocation is,

{{Template other| |<something something Category: something>}}

wrapped around whatever[[Category:foo]] or even{{decision template|cat=Category:foo}} the template is using to apply tracking categories to transcluders. (Double pipe because the first argument is empty. That restricts the code to apply categories to thenegative branch of the template. It does nothing if the result is true => the transclusion is in the Template namespace.)FeRDNYC (talk)00:30, 7 November 2022 (UTC)[reply]

Check this crap out:Wikipedia:Wikipedia Signpost/Templates. While the list is daunting, the majority of them are either deprecated or weird one-off things that weren't used for much. It would probably be wise to go through these and make the list a little more useful (for one, separate out the active from deprecated templates), then document what's left...jp×g04:03, 7 November 2022 (UTC)[reply]

Wondering what's going on in this process -- we havethis diff, which is SPS converting a draft to an article, andthis diff, which is SPS publishing the new edition on the main page. What's strange to me is that there doesn't seem to be much structured data here: the title is provided as a template parameter in the published article, but the subheading, author information, etc is not. Am I correct in surmising that the subheading is just being scraped from the draft template by SPS and then added to the new-issue text by SPS (i.e. there is no MediaWiki going on there)?jp×g20:52, 10 November 2022 (UTC)[reply]

You're an idiot, read the documentation I wrote.jp×g🗯️03:33, 23 December 2023 (UTC)[reply]

No personal attacks please, especially self-inflicted ones. –Jonesey95 (talk)01:45, 24 December 2023 (UTC)[reply]

Check it out atTemplate:Signpost draft. Here is the basic deal, from the documentation page there.

The following feature was added by Adam Cuerden and JPxG in November 2022.

All articles with this template are added toCategory:Signpost drafts. Subcategories are added based on the following parameter values:

Subcategorization works like this:

I will be refactoring the newsroom to use these categories in the draft lists and et cetera.jp×g18:09, 11 November 2022 (UTC)[reply]

I have come up with a mechanism for creating automatic discussion-board pages forSignpost issues, like this one:Wikipedia talk:Wikipedia_Signpost/Single/2022-11-28. The way this works is by invokingModule:Signpost to transclude all of the month's articles, like this:

{{Wikipedia:Wikipedia Signpost/Templates/Article list maker| date = {{#invoke:string|sub|{{PAGENAME}}|27|36}}| rowtemplate = Wikipedia:Wikipedia Signpost/Templates/Article list maker/Comment section| rowseparator = newline}}

So far, this seems to work pretty well, but it brings to light a larger issue with the Signpost module: articles aren't added to the index by default. Basically, we have these indices by year (likeModule:Signpost/index/2022), which are JSON files providing a structured index of the year's articles. Each looks like this:

{date = "2022-01-30",subpage = "Arbitration report",title = "New arbitrators look at new case and antediluvian sanctions",tags = {"arbitrationreport"},},

It isn't very complicated. My idea is that, per discussion atModule talk:Signpost, it could be possible to automatically populate these indices, with one of the following:

• Make the Signpost Publishing Script automatically generate JSON for an issue's articles, and add them to the appropriate module's index, upon publishing.
• Write a purpose-made script that populates index pages (and then just run this a few minutes after the publication of a new issue)

It seems to me like the second is smarter, since this allows us to do other stuff (like retroactively populating past indices with other metadata).jp×g23:54, 1 December 2022 (UTC)[reply]

@JPxG: Did you go with one of the two alternatives bulleted immediately above? I noticed some oddities like2024-03-29 News and notes is untagged, but thepreceding andfollowing News and notes columns are. ☆Bri (talk)21:07, 5 July 2024 (UTC)[reply]

I took -- Jesus, this is from 2022? -- a third option, which was to incorporate this into Wegweiser, which I run from my computer every time I publish an issue. At some point I need to get it on Toolforge.jp×g🗯️03:17, 6 July 2024 (UTC)[reply]

Check this out:Wikipedia:Wikipedia Signpost/Templates/Signpost edition pageviews. I found this in use atWikipedia talk:Wikipedia Signpost/Archives/2016 andWikipedia talk:Wikipedia Signpost/Archives/2017. Apparently this has been sitting around for some time!jp×g01:14, 4 December 2022 (UTC)[reply]

This old template gives correct numbers and graphs (more precisely, they match what you get when you check pageviews on the relevant page itself), but it doesn't include all sections. The one you put on the Single-issue talk page,Wikipedia:Wikipedia Signpost/Templates/Issue pageviews, still needs sorting out. It giveswrong numbers and graphs at the moment (though it does include all sections). Compare the output of the two templates for the most recent issue below. For example, News and notes had1493 views on January 3. ButWikipedia_talk:Wikipedia_Signpost/Single/2023-01-01 shows 90, while the old template shows the correct graph.

AndreasJN46612:42, 15 January 2023 (UTC)[reply]

D'oh, it's a question of screen width. If you have a wide-enough window, the next graph's caption appears to the right of the graph you are looking at, making it appear as though it describes the graph next to which it is shown, when it actually relates to thenext graph shown further down.

Would it be possible to insert a hard paragraph break and a blank line after each graph? That will take care of any confusion as to which graph each caption refers to. --AndreasJN46613:42, 15 January 2023 (UTC)[reply]

Both of these are in the process of being deprecated, actually -- you can see a mockup of what's being set up atUser:JPxG/sandbox99. Note that the tables are sortable! It's also possible to get views other than 7-day (the module has 15, 30, 60, 90, 120 and 180 as parameters stored for articles as well).jp×g09:05, 16 January 2023 (UTC)[reply]

Again with the magical help ofModule:Signpost, I have written something that allows us to easily generate view count graphs for issues. There are still some issues to be worked out here, but you can see what they look like for the last few issues here:Wikipedia:Wikipedia Signpost/sandbox.jp×g03:07, 5 November 2022 (UTC)[reply]

To wit: the date ranges are hard to set, so I just have them going back 180 days for everything (although data exists further back) and can't do all of 2022. Also, the way I set up the template, the graphs top out at 2,000, so some articles that were total bangers are shown as more modest:Wikipedia:Wikipedia_Signpost/2022-10-31/News_and_notes, for example, is shown as having gotten 2,000 views a day, even though it actually got tens of thousands of views per day. This stuff can be fixed later, but for now, this is a workable proof of concept.jp×g03:12, 5 November 2022 (UTC) S[reply]

@JPxG: I admit that when I read "view count graphs", my expectation was that I'd find something like a bar graph for each issue, showing the view counts for the articles relative to each other. Graphs with total counts as data points, in other words. I'm not sure how much value there is in seeing the views graphed over _time_ for each article. But it's probably useful (or just interesting) to someone with more targeted information needs, beyond the mere idle curiosity that led me there.

AFAICT the graphs show viewrate (per... day? hour?) more thancount, though that's just semantics really. But I'm finding it difficult to determine, from the graphs as presented, where the articles stand in terms of those data points I initially envisioned: Total view count for a given article,relative view count for different articles, etc.

I mean, obviously you can get some vague sense, but trying to compare different graphs can be misleading due to the Y axis auto-ranging. (Like, "2022-08-01, From the editors:Rise of the machines, or something" looks kind of lower-average popularity... unless you catch that the baseline scaled up an order of magnitude to start at 10 instead of 1, so its view numbers actually blow awaymost of the other articles from that issue. But OTOH, a couple of the other graphs also got that same range bump, so how its viewership compares tothose articles... well, somehow seems even harder to discern, actually. At least for me.)

I don't mean to knock your effortat all, the graphs look very good and the effort is impressive. Perhaps the information is just presented in a form that isn't meant forme, but helps answer questions asked by those with data needs more evolved than my own ignorant curiosity. I'm perfectly willing to accept that.FeRDNYC (talk)10:07, 6 November 2022 (UTC)[reply]

Well, actually, you are right: presenting this information as a graph is kind of stupid and unnecessary. Like, maybe a graph is useful for the wholeSignpost, but for individual articles, it would just be more informative to give a single number (30-day view count) instead of half a megapixel of visual data.

Unfortunately, there seems to be some absolutely nonsensical situation with the graph module and the Scribunto module and the External Data module. I am still trying to figure it out, but I suspect that it might literally be impossible to just show a number and not a graph: the way it works for the graph is that the graph module takes input from the template to get a wikimedia API url, and then somehowqueries the external URL. I tried to figure this out for a couple hours last night and got mad and did something else.jp×g12:44, 6 November 2022 (UTC)[reply]

Update: I have spent nearly an entire day trying to read documentation and figure out how to make this thing -- trying to write an entire program in valid JSON in the outdated Vega release used in the Graph extension, having to save a page and reload it, and the only error message being "invalid JSON" may well be the most excruciating programming experience I have ever had, and this includes writing a 3D renderer in TI-BASIC on a 8x16 character screen without copy, paste or find. I officially give up on this. If anyone wants to figure out how to do this, feel free to pick up where I left off (essentially, take the radioactive debris atTemplate:Graph:PageViews and duct tape it together such that the Graph extension outputs a single number, which is the sum of the "views" fields in the Wikimedia API's JSON output -- let me know when you figure it out and I will reimburse you for the hard liquor.jp×g00:09, 7 November 2022 (UTC)[reply]

@JPxG: I also spent some time the other day playing with the graphing tools -- but I decided to try them out at the source, by making use of theVega project's rather cleveronline chart editing tool. (For anyone else playing along at home, Vega is the underlying library that powers the MediaWiki Graph extension.) With that tool, and by loadingSignpost pageview datasets manually from API request URLs (which I generated in theAPI explorer tool), I was actually able to construct a halfway-usable comparison graph for three random articles in a recent issue, showing relative view counts as bar graphs something not too far off from the original expectation I described above.

The JSON definition for whatever I managed to come up with before I ran out of time/steam is saved inthis GitHub Gist (the Vega editor can both save to and load from Gists, to preserve work done with it), but here's a URL to open the same thingdirectly in Vega's online editor if you're curious.

The datacurrently there is loaded manually, as I said, which doesn't scale well. But it's a start at the basic concept, and adapting it to use the MediaWiki implementation'swikirest:// URLs as the data source, with article names automatically selected rather than having to be individually added to the graph, is theleast of my concerns implementation-wise. The fact that my current graphs work off the monthly page view stats, and need a fixed date range that has to be selected by hand based on the article publication date, is a bit more unfortunate. (But it does allow me to get total view counts, because Vega itself can sum the monthly view counts to produce a total.) And thanks to theTemplate:Signpost/Deadline work, I've now got a good enough handle on date parsing using the{{#time:}} parser function that it at least doesn't feel impossible to overcome.

I don't know, take a look (if you have any interest) and see if you think there's a seed there of anything useful enough to be worth cultivating; if so I might fiddle a bit with some sort of on-wiki conversion/implementation over the coming weeks.FeRDNYC (talk)22:27, 9 November 2022 (UTC)[reply]

I'm moving this here from the Newsroom archive, because it has little to do with news, and much to do with technicals. Anyway, I have an update as well:Wikipedia:Wikipedia Signpost/Templates/Issue pageviews now exists, which can be transcluded onto the single-issue talk pages, like such:Wikipedia talk:Wikipedia Signpost/Single/2022-11-28. For right now I am just putting it below the single-talk template. This isn't great, but it is as least better than nothing.jp×g02:12, 4 December 2022 (UTC)[reply]

I have createdWikipedia:Wikipedia Signpost/Omni-index andWikipedia talk:Wikipedia Signpost/Omni-index; I used Quarry SQL to come up with a list of everySignpost article in both namespaces. This is complete for now; you can click the RC links at the top of these pages to seeall edits inSignpost space (WP or WPT, respective). I am not fully done with this (contemplating writing a bot to automatically update them every so often, and some other improvements), so not posting it everywhere yet. Let me know what you all think.jp×g10:24, 13 December 2022 (UTC)[reply]

• RC ·Talk RC

User_talk:Evad37/SPS.js#Problem_if_the_page_includes_the_word_"null"

I guess we should update the style guide until this is fixed (by me,).jp×g11:53, 22 December 2022 (UTC)[reply]

Not to be a dunce, but does this mean publication will glitch if any page in the issue contains the word "null"? How bad is it? Will other pages get published? ☆Bri (talk)16:04, 22 December 2022 (UTC)[reply]

No, it will apparently publish the article properly, just with all instances of the string removed (?) so that i.e. "nullified" becomes "ified". In the meantime I guess we can just try to avoid saying "nullify", "null and void", "annulled", et cetera. Hopefully there is not a big article for December about jury ification.jp×g19:36, 22 December 2022 (UTC)[reply]

I am currently in the process of writing a big-ass script (which I'm calling "Wegweiser") to better integrateModule:Signpost indices into the publishing process and the architecture of the paper. Where I'm at right now:

• Using module indices (or API-obtained) article lists to get pageview counts for different intervals.

Right now I have it set to calculate 7-day, 15-day, 30-day, 60-day, 90-day, 120-day and 180-day pageviews, and can do this for arbitrary numbers of years by running a single command in the terminal.

• Pulling lists of Signpost articles from the PrefixIndex API and integrating them into the module indices.

Redirect issue solved below.

Today I will be working on some more stuff, like something to retroactively fill "author" fields, and also a Wegweiser module that actually edits the wiki to update the indices that it's processing.

Overall, I think that this will prove useful, and extensible, for management and navigation of the Signpost. Currently, there are a lot of modern features that we lack, which most other newspapers have. For example, if you are readingthisVox article, you can click on the author's name in the byline to getthis page of everything he's written for the site (as well as a more detailed bio). This is something we could do here, with the right scripts and modules -- and having it do itself automatically allows for more detailed functionality.jp×g23:48, 6 January 2023 (UTC)[reply]

Apparently there have been a few... drafts... which were moved into the space for the respective issue. What?

1. Wikipedia:Wikipedia Signpost/2011-03-14/Editcountitis
2. Wikipedia:Wikipedia Signpost/2015-10-28/Blog
3. Wikipedia:Wikipedia Signpost/2016-04-06/News and notes
4. Wikipedia:Wikipedia Signpost/2016-04-06/Wikipedia Weekly

The first of these seems to be a fully written article that was just never put into the issue. Jesus, what a mess.jp×g01:00, 7 January 2023 (UTC)[reply]

AndWikipedia:Wikipedia Signpost/2005-06-20/Tremendous excitement over admin nominations.

Too bad, the "Editcocuntitis" piece is thought provoking.Maybe we could still run it in a historical context. Unfortunately one of the contributors is banned and it's probably a no-go. ☆Bri (talk)21:40, 11 January 2023 (UTC)[reply]

• Wikipedia:Wikipedia Signpost/2008-08-11/WikiProject report/Rudget, which I guess was just kind of a crappy WikiProject report and didn't get listed in the main issue?jp×g05:13, 12 January 2023 (UTC)[reply]

• Wikipedia:Wikipedia Signpost/2011-12-26/In the news, never actually linked to from the article and I guess never published.jp×g23:03, 27 January 2023 (UTC)[reply]

More ghosts, some of which I moved to drafts:

• Wikipedia:Wikipedia Signpost/2006-09-12/News and Notes
• Wikipedia:Wikipedia Signpost/2008-08-11/WikiProject report/Rudget
• Wikipedia:Wikipedia Signpost/2010-06-07/Citations
• Wikipedia:Wikipedia Signpost/2010-07-19/Discussion report
• Wikipedia:Wikipedia Signpost/2010-07-26/Special story 1
• Wikipedia:Wikipedia Signpost/2010-08-16/Discussion report
• Wikipedia:Wikipedia Signpost/2010-10-25/Election report
• Wikipedia:Wikipedia Signpost/2010-12-06/Special story 2
• Wikipedia:Wikipedia Signpost/2011-01-31/Discussion report
• Wikipedia:Wikipedia Signpost/2011-03-14/Editcountitis
• Wikipedia:Wikipedia Signpost/2011-12-26/Discussion report
• Wikipedia:Wikipedia Signpost/2011-12-26/In the news
• Wikipedia:Wikipedia Signpost/2012-04-03/In the news

There were about 150 redirects in Signpost article space, all of which came from typos, article renames prior to publication, or weird situations like "the article was moved to YYYY-05-16 but the issue was published on the 18th so it got moved to the new date". I moved some of the very old ones to theSignpost Register of Historic Places and CSD'd the rest. There were only a few incoming links, so I just retargeted them to the destination pages with JWB before the deletion run. I do not think there's any need for us to have redirects in our article space, and it clogs up a bunch of scripts and tools and etc to have them there. In the future, I think we should have a policy of avoiding redirects in our article space (it is already extremely rare).jp×g04:27, 8 January 2023 (UTC)[reply]

What the hell is going on inSpecial:PrefixIndex/Category:Wikipedia Signpost? There used to be individual categories for each department, organized by year... until 2015, when they randomly stopped? Except for some that kept going to 2016? Every time I think I've finally got a list of all the random outdated forgotten stuff in this project, I find another 300 pages of crap that somehow interacts with everything but isn't documented anywhere and hasn't been touched in a decade. I'm going to have a conniption. Look at this:Special:WhatLinksHere/Category:Wikipedia_Signpost_Book_review_archives! These aren't even linked to from anywhere. I am pretty sure that all of this (except the monthly archive cats) is now completely redundant toModule:Signpost and the article list maker. What is to be done about this?jp×g01:08, 7 January 2023 (UTC)[reply]

I have written a massive Wegweiser script that's capable of integrating these categories' contents into the Signpost module (i.e. everything inCategory:Wikipedia_Signpost_Book_review_archives would be tagged withbookreview), which I did manually for the arb report archives. This still took forever (i.e. I had to manually copy-and-paste the modified Lua table into 11 pages) -- and there are about 40 of these department categories, so I have submitted a BRFA. This should take a few minutes to run when it's approved, and then the module can be the single authoritative index of articles, and there will be no more random stuff that's out of sync with other random stuff.jp×g04:25, 8 January 2023 (UTC)[reply]

Done.

SeeModule talk:Signpost. I have completed integration of tags from categories, as well as title/author autofill from 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 and 2023. Pages prior to 2009 require modern headers to be placed on them in order for the script to work properly (which should have been done anyway a while ago but never was).jp×g08:34, 9 January 2023 (UTC)[reply]

2005 has been updated to the modern headers, and module indices have been filled in. 2006 is scheduled for tomorrow, because all the pages have to be done individually (they used a completely fucked up random combination of header content for basically every article).jp×g08:37, 9 January 2023 (UTC)[reply]

What the hell is going onhere?jp×g08:38, 9 January 2023 (UTC)[reply]

• Missing end tag: 3,721Partly done, waiting for JWB run to add article-end templates (see below)
• Obsolete tag: 2,679 Done
• Stripped tag: 317Partly done – all except for div tags caused by:
  • The Newsroom pages, which are a hot mess
  • Template:Signpost series (see below),
  • formatting that changed at the beginning of 2017 (see below for JWB request),
  • and one mystery code tag
• HTML5 misnesting: 115 Done

I recall trying to fix these div errors some years back and finding that if I fixed it for one batch of issues (either older or newer, I forget which), it introduced new errors in the other batch of issues (either newer or older, respectively [edited to add: I think the problem is actually that the errors appear in the individual article pages but not in the /Single pages, but when they are fixed in the individual article pages, the /Single pages blow up with new errors]). I have fixed tens of thousands of Linter errors since 2018, and I can assure you that they are not urgent. That said, I will take a look and see if I can puzzle out and fix some of the errors above. I fixed maybe 100 yesterday when I was working on the inline/block quote template confusion. –Jonesey95 (talk)01:41, 28 January 2023 (UTC)[reply]

Many of the (obsolete tag) font errors, and many of the other errors are in editors' signatures onSignpost comment pages in Wikipedia Talk space (about 2,400 errors[edited to add: these are all fixed now]). Those pages are transcluded on the Signpost article pages, which means two things: (1) there are not as many errors in the actual articles as you think there are, and (2) fixing one error on a comment page reduces the total Wikipedia-wide error count by two. –Jonesey95 (talk)01:44, 28 January 2023 (UTC)[reply]

JPxG, I don't know how many of these there are, but in the "obsolete tag" list, when you see "center", there appear to be a lot ofthese patterns, which should be easily fixable with an AWB run. Search for the "{{noprint|1=<center>...</center>}}" pattern and replace the center tags with "{{center|1=...}}". Note that this isnot a valid fix for all center tags, but for this pattern, it works. –Jonesey95 (talk)02:03, 28 January 2023 (UTC)[reply]

The above center tags have been fixed by a bot. –Jonesey95 (talk)21:04, 31 January 2023 (UTC)[reply]

More tags:misnested tags(78 errors)(1 error); all other Linter error categories aside from this one and the ones listed above yield zero errors at this time. –Jonesey95 (talk)02:05, 29 January 2023 (UTC)[reply]

Bad news:this series of edits left an unclosed template, removed an opening small tag, added a template parameter, and added a stripped div tag at the end. Don't worry about the stripped div tag, because I think there will be a more systemic fix. –Jonesey95 (talk)06:29, 28 January 2023 (UTC)[reply]

When{{Signpost series}} is used as a sidebar on a standalone page, it causes a stripped</div> tag at the beginning and an unclosed<div> tag at the end. This appears to happen because the template is normally transcluded on single-page Signpost pages, where it is inserted such that it closes one block and starts a new block. The dumb fix issomething like this on each of the Series pageslisted here, but that fix would have to be applied to every new Series page, if there are any. A more elegant fix would be a template parameter that inserted appropriate div tags before and after the template, but only on the standalone pages. Thoughts? –Jonesey95 (talk)20:32, 29 January 2023 (UTC)[reply]

This has been fixed byJPxG by changing the way these are transcluded and displayed. –Jonesey95 (talk)17:15, 1 February 2023 (UTC)[reply]

As far as I can tell, every article page until December 2016 that is showing on the "missing end tag" report linked above is missing a closing</div> tag. Each of those pages has some sort of "article-start" template that opens a div tag at the top of the article, but no corresponding closing tag.A closing</div> tag needs to be inserted within the<noinclude>...</noinclude> section at the bottom of the page,like this. It is important that the tag be placed within the noinclude section, because when the pages are transcluded into the /Single or /SPV pages, the "reader comments" link in the /Single page contains a closing</div> tag that balances the tags on those transcluded article pages.

The January 2017 and later pages have a similar problem that needs a different resolution. With those pages, the individual pages have balanced div tags, with the closing tag provided by the "article-end-v2" template. When the article is included in the /Single page, however, that page ends up with an extra closing div tag for each article. The resolution for those pages, I think, is to move the "article-end-v2" template inside the<noinclude>...</noinclude> tags so that the individual article pages continue to have balanced tags, but the /Single pages are not unbalanced.

I can probably do this work with AutoEd, but it is very tedious. IfJPxG is able to do it with JWB, that would be helpful. If you want to start with a batch of 100 pages from each date range, I'll be happy to check your work. The only pages that should be modified are (1) pre-2017 pages that show up onthis report with missing div end tags and (2) all article pages transcluded in 2017 and later /Single pages. –Jonesey95 (talk)01:16, 30 January 2023 (UTC)[reply]

A resolution that may be more elegant in the long run is to add the "article-end" template to the pre-2017 articles (outside of the noinclude tags) and remove the closing div tag from the "reader comments" link in the /Single page. –Jonesey95 (talk)16:21, 31 January 2023 (UTC)[reply]

I haveremoved the closing div tag from after the "reader comments" text that appears in the /Single pages. This means thatthese pages will need "article-end" templates added,like this. I hope thatJPxG is available to run JWB on those couple thousand pages. –Jonesey95 (talk)16:32, 31 January 2023 (UTC)[reply]

Oh, jeez. Well: I believe that these are all the articles usingWikipedia:Signpost/Template:Signpost-article-start and not the v2 version. I was thinking that it might be nice to switch these over anyway, so I guess this gives me an excuse to do that, although I have a couple other things going on right now. I shan't forget!jp×g20:05, 31 January 2023 (UTC)[reply]

Feel free to ping me when you do a batch of two or three complete issues (maybe 15–20 article pages), and I'll check them for new or remaining syntax errors. I do not advise doing all 2,000 of them at once unless you feel very comfortable with checking for Linter errors in the edited pages and the pages that transclude them. –Jonesey95 (talk)21:02, 31 January 2023 (UTC)[reply]

I have reworkedTemplate:Signpost draft helper intoTemplate:Editnotices/Group/Wikipedia:Wikipedia Signpost/Next issue, which is now set up to automatically display as an editnotice when you are editing any page that begins withWikipedia:Wikipedia Signpost/Next issue. This should make it easier to write articles: you don't have to save/preview to get the copypasta for Signpost templates out of the draft helper, and you also don't have to remove the draft helper template to prepare for publication. I will be going through the preload templates to remove it (it will still work in userspace drafts, and it will stay preloaded for those).jp×g23:25, 12 January 2023 (UTC)[reply]

I have finally figured out that{{Database report}} exists, which means thatWikipedia:Wikipedia Signpost/Omni-index andWikipedia talk:Wikipedia Signpost/Omni-index can now be automatically updated, giving us a live recent-changes feed for both our main and talk spaces.

Also, just for shits, I made{{Signpost/Number of articles}} (5812) and{{Signpost/Number of issues}} (723).jp×g00:35, 13 January 2023 (UTC)[reply]

While spelunking, I foundthis page, where apparently Pete Forsyth tried to do this exact same thing in 2016.jp×g11:18, 13 January 2023 (UTC)[reply]

They used slack then?? I feel like we've slid back a bit... ☆Bri (talk)04:20, 14 January 2023 (UTC)[reply]

Yeah, the poor schlep who they have as the EiC now can't even get all the editors to join a [zW9JVvVwFR freakin' Discord channel].jp×g11:31, 14 January 2023 (UTC)[reply]

Two acts:Wikipedia talk:Wikipedia Signpost/Archive 7#Some_ideas, where ResMar attempts to clean out some of the messed-up unused templates that I am currently going through.jp×g03:06, 17 January 2023 (UTC)[reply]

For articles, here is some regex to a search to fitler out all the other crap. For example, "Citizendium":

intitle:/Signpost\/[0-9]{4}-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"

Basically, it will restrict your search to titles that contain "Signpost/____-__-__/", and not return any title with "SPV" in it.

One that can be more easily customized for years is this:

intitle:/Signpost\/20[0-9][0-9]-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"

like such:

Citizendium in 2008intitle:/Signpost\/20[0-9]8-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"

Citizendium in 2013intitle:/Signpost\/2013-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"

Citizendium in 2010 to 2014intitle:/Signpost\/201[0-4]-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"

Citizendium before 2010intitle:/Signpost\/200[0-9]-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"

Maybe this is wishful thinking, but it might be possible to make search bars that do this automatically. I don't think it would be that hard.jp×g10:17, 15 January 2023 (UTC)[reply]

The URL to do this search the proper way -- so that it sorts all results with creation date at top, only searches the WP space, etc -- is such:

https://en.wikipedia.org/w/index.php?sort=create_timestamp_desc&search=intitle%3A%2FSignpost%5C%2F%5B0-9%5D%7B4%7D-%5B0-9%5D%7B2%7D-%5B0-9%5D%7B2%7D%5C%2F.%2A%2F+-intitle%3A%22%2FSPV%22+%22Citizendium%22&title=Special:Search&profile=advanced&fulltext=1&ns4=1

which looks likethis.jp×g10:20, 15 January 2023 (UTC)[reply]

Got it: seeTemplate:Signpost/Search andTemplate:Signpost/Search/URL. Like this:

Does that default to searching in article space for everyone, or just me? ☆Bri (talk)14:31, 31 January 2023 (UTC)[reply]

Yeah, the input box thing is kind of half-assed. I looked through thedocumentation and tried a few different parameters, and there doesn't seem to be any way to force it to search specific namespaces (the closest you get is an option to add a little row of checkboxes for namespaces below the search bar). The URL template is able to encode that, although it is much more of a pain in the ass to use:

[{{Signpost/Search/URL|dogs}} Search it!!! Ohh yeah]

Search it!!! Ohh yeah

Who knows, maybe there is something I didn't figure out.jp×g11:24, 1 February 2023 (UTC)[reply]

I think I fixed it byadding "prefix=WP:" to the template. ☆Bri (talk)15:59, 1 February 2023 (UTC)[reply]

I have mostly finished my spelunk of theomni-index, and cleared out the remaining gunk (redirects, abandoned drafts, random blank pages, etc). Anyway, what I got out of it was this:

Series templates now work. That is, all of them (from the 2006 ArbCom elections to the present) are now formatted using the module, and listed atWikipedia:Wikipedia Signpost/Series. Right now, if you go to the individual series pages, it will just show them in the sidebar view (alongside the old versions, so I can review them for omissions). Eventually, I plan to have these look better, kind of the way that Signpost main issue pages work: the idea here being that readers can simply go to a tag that they want to learn more about, and have it formatted in a way that is useful and pleasant.

I have also taken some statistics about the tags, atWikipedia:Wikipedia_Signpost/Statistics/Tags. They probably need some winnowing out (and perWikipedia:Wikipedia_Signpost/Technical/Index_validation there are still many untagged articles), but the general distribution is like this: there is one tag with 700+ articles in it, 29 tags with 100+ articles in them, 55 tags with 50+ articles, down to 189 tags with at least ten articles in them. I'm not sure what the implications are for making auto-generated tag pages: making 189 separate tags would be possible, and not that difficult, but some more kinks should be ironed out before this is done.jp×g08:41, 28 January 2023 (UTC)[reply]

Just as for the tag pages, I did someanalysis of author data, using the Wegweiser-augmented module data with author fields for every article. The data still needs to be cleaned (there are a lot of author tags like "none" or "91 editors" or "Germany)" or "Cwmhiraeth (text) 18 June 2017"). However, some similar insights to the tags: there is one author with 300+ articles (Ral315), 18 authors with 100+ articles, 34 with 50+, 121 with 10+. More detailed information is in the tables atWikipedia:Wikipedia_Signpost/Statistics/Authors. Anyway, I was able to use this to make a few author byline pages, which are linked to fromWikipedia:Wikipedia Signpost/Author. I only did the first ten, because I wanted to see how it worked first. These pages kind of look like ass, because I haven't bothered to format the module output, but it is at least a proof of concept to myself that I can get it to work. See, for example:Wikipedia:Wikipedia Signpost/Author/Michael Snow.jp×g08:45, 28 January 2023 (UTC)[reply]

This recent page move broke Signpost 2011-08-09. There was a transcluded red link in the /Single page. Ifixed it, but if there are more of these moves out there, there will be red links in /Single editions. –Jonesey95 (talk)21:11, 29 January 2023 (UTC)[reply]

A similar move appears to have brokenWikipedia:Wikipedia Signpost/Single/2014-02-19. –Jonesey95 (talk)21:24, 29 January 2023 (UTC)[reply]

@JPxG, I assume thatthis edit is part of the work you and @Jonesey95 are doing, but I don't understand how having only part of my username is supposed to help.Whatamidoing (WMF) (talk)18:07, 30 January 2023 (UTC)[reply]

Well, ResMar and a few other people wrote this beautiful module that can return all sorts of indexed information about Signpost articles, and me and Mr. Stradivarius augmented it to handle author data... and then I discovered that the author data is a gigantic mess.

Ideally, the author fields of the header templates should be a uniform metadata field, which contain the names of the authors, like in{{cite web}}, so that they can be indexed and retrieved properly (i.e.Wikipedia:Wikipedia Signpost/Author/Sage Ross). Sadly, this has not been the case over the last 20 years, and nobody has ever tried to systematically index them, so there have been lots of weird things.

What we had (apart from hundreds of just straight-up typographical errors) was a bunch of stuff like like HaeB being credited sometimes as "HaeB", sometimes as "Tbayer", sometimes as "Tbayer (WMF)", and sometimes as "Tilman Bayer". What I eventually settled on was this:

1) One person should be credited with one name, under one byline, with one string of text for their name, i.e. there should not be "K. Trout65" and "Ktrout65".

2) If someone has written for theSignpost under their IRL name, their byline should be that, i.e. there should not be "Kilgore Trout"and "Ktrout".

2a) If not, their byline should be their username.

3) No parentheticals, comma phrases or anything besides their name: "Kilgore Trout" and not "Kilgore Trout, Executive Coordination Liaison, Department of Situations and Circumstances".

4) No user links, i.e. the link text must be "Kilgore Trout" and not "User:Kilgore Trout".

5) There should only be one variant of the capitalization. This does nothave to be the same as the username (i.e. many people stylize their usernames as all-lowercase), but there can only be one of them.

Essentially, I have credited WMF employees by their names, because they are the same human being (and should have the same author metadata) regardless of their place of employment. For example, User:HaeB is Tilman Bayer, and User:Tbayer (WMF) is also Tilman Bayer.jp×g18:42, 30 January 2023 (UTC)[reply]

1. "Next issue" links don't work from issue 5 to issue 6. For exampleWikipedia:Wikipedia Signpost/2023-03-09/In the media does not have a "next" link displayed, even though itwas added by the script.
2. We probably should straighten out http vs https issues -- seethis
3. A readerreported that issue 6 was double posted to their talkpage via Massmessage. This seems to be a known issue and has a Phabricator ticket opened years ago. Probably not much for us to do about it.

Just thought I'd post this here. ☆Bri (talk)18:27, 20 March 2023 (UTC)[reply]

1) No idea what is going on here. The template in question isWikipedia:Signpost/Template:Signpost-article-comments-end: it might be the case that it was put together on the assumption that there would only be one issue per month.

2) Looks like Jonesey95 fixed this on the 15th in the cover-item template, so I guess happily resolved.

3) Some sleuthing here shows that quite a lot of people got the Signpost twice this issue. Examplehere andhere. I think I might have cracked the code. Note the comment in the second one:Message sent by User:JPxG@metawiki using the list athttps://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Signpost&oldid=24726786. I think what might be going on here is that people who have themselves listed on the local enwiki subscription page and also the global subscription page on Meta are... getting both. Not sure how to fix this (the obvious solution would be to identify all these people and remove them from the local list, but who knows).jp×g19:47, 20 March 2023 (UTC)[reply]

Note on 3: they were both sent from the global list, I guess. The first one has this editnote at thebottom:Message sent by User:JPxG@metawiki using the list athttps://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Signpost&oldid=24726786. The second one has this editnote at thetop:Message sent by User:JPxG@metawiki using the list athttps://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Signpost&oldid=24726786. Huh???jp×g19:51, 20 March 2023 (UTC)[reply]

Re item #1, the comments-end template says{{#ifeq: {{{3}}} | {{#time: Y-m-d|-{{#time:N|-1 days}} days + 7 days}} | |{{#ifexist:, and when I evaluate the #time statement, I get 2023-03-20, which is the same as|3= as of today. It appears to me that since those values are equal, nothing is displayed, but tomorrow, i.e. in less than two hours, the "Next" link should appear. I don't know if I am correct, and if I am, I don't know why it is set up like that. I wouldn't monkey with it unless I knew why that calculation was being performed. –Jonesey95 (talk)22:52, 20 March 2023 (UTC)[reply]

Confirmed using sandbox –Special:Diff/1145778445/1145779299 – error "AAAAAAAAAAAAA" gets triggered.

Reference documentation for #time:mw:Help:Extension:ParserFunctions##time. "N" is for "ISO 8601 day of the week (Monday = 1, Sunday = 7)."

This #ifeq was added inSpecial:Diff/376614225 in 2010 with edit summary "Hide link until publication". It might have outlived its usefulness with all the changes to the publication process since then. —⁠andrybak (talk)23:26, 20 March 2023 (UTC)[reply]

I just refreshed the page, and "Next issue" shows, presumably because it is currently 2023-03-21 UTC time, which makes the ifeq fail and display the link. FWIW. –Jonesey95 (talk)05:23, 21 March 2023 (UTC)[reply]

@Andrybak andJonesey95: I think I may have cracked the code here, having remembered something from my cleanup of the project space. Back in the day, the publishing process worked differently. Today, we use subpages likeWikipedia:Wikipedia Signpost/Next issue/News and notes, and the script automatically moves them toWikipedia:Wikipedia Signpost/2023-03-20/News and notes when we hit "publish". However, before this was set up, people used to just write articles at the date of the planned publication (i.e. we would just start writing it atWikipedia:Wikipedia Signpost/2023-03-20/News and notes hoping that publication actually happened on that day, and if it didn't, we would create a dog's breakfast of inane redirects). Because of this, automatically linking to the next article if it existed was a liability, because there was a significant likelihood of it being a half-finished draft article. However, this is no longer possible, because drafts aren't in main issue space anymore. In fact, it'sextra impossible, because articles are not given end templates with pre-filled "next" parameters at publication, they're retroactively given "next" links by the publication script. Ergo, this code can (and should) be deleted completely.jp×g12:26, 21 March 2023 (UTC)[reply]

Boom goes the dynamite. I have carved it out, and my tests indicate that nothing of value was lost (although some more poking around for edge cases may be warranted).jp×g12:38, 21 March 2023 (UTC)[reply]

• For what it's worth, I have made adocumentation page for that template. I think it may be useful to use that page to keep track of what we learn (or permalink back to the discussions where we do), so that when some poor bastards (indeed, quite possibly ourselves) have to slog through this in a few years' time they have something to go by...jp×g12:03, 21 March 2023 (UTC)[reply]

Per above. Phab ticket isT93049.

List of doubles that I found with a +1856 byte diff (i.e. from global delivery):

I also found a bunch of doubles (231 of them) with a +901 byte diff, which presumably is from local delivery:

Man, what a mess.jp×g20:25, 20 March 2023 (UTC)[1]] 20:25, 20 March 2023[reply]

Wow,this one has THREE COPIES, what the hell?jp×g20:28, 20 March 2023 (UTC)[reply]

Another triple isUser talk:Newyorkadam. He's been getting triples of a number of newsletters since November. ☆Bri (talk)20:42, 20 March 2023 (UTC)[reply]

I am manually reverting these, starting from the bottom. I have gotten a few dozen done. This is such a pain in the ass.jp×g20:49, 20 March 2023 (UTC)[reply]

Okay, all of them are done. This MMS bug needs to be fixed, because this sucks.jp×g21:14, 20 March 2023 (UTC)[reply]

• Just leaving a note here, I thought this had been double-delivered to the mailing lists as well by@Jayen466: because I got two e-mails within days, but it turns out it was a previous issue that was delivered with some delay. I got the issue 5 e-mail on March 15th 10:08PM EDT (although when replying it says it was sent March 9th at 7:18AM EDT), and the issue 6 e-mail on March 20th 5:20PM EDT (although it says it was sent at 10:15AM EDT). My confusion stemmed from the fact I read both using single page view, and thehttps://enwp.org/WP:Signpost/Single page gets overwritten, so by the time I had time to try to read them this morning it was already overwritten, so I thought I had gotten a double-delivery too.Ben · Salvidrim! ✉16:55, 22 March 2023 (UTC)[reply]

  Thanks for your note,Salvidrim!. While Wikimedia-l deliveries are instant, I have never been a regular user of the Wikimediaannounce-l list and therefore am moderated on that list. As it's a low-traffic list, it often takes the moderators a few days to approve the post ... it seems they were slow on issue 5 and quick on issue 6.AndreasJN46618:20, 22 March 2023 (UTC)[reply]

Let's see...jp×g23:36, 4 April 2023 (UTC)[reply]

At some point (probably soon) I should make a template for these pageview tables that doesn't require me to transclude my userpage sandboxes, but whatever.

Before:

Trying to remember what the hell I was doing with this and not doing a great job. I think I was on to something here, though.jp×g01:52, 29 June 2023 (UTC)[reply]

Noting thatthis happened: ClueBot III moving a bunch of shit to Archive 4 even though we have an Archive 5 and Archive 6. Huh?jp×g03:17, 17 July 2023 (UTC)[reply]

I'm guessing since you removed content from Archive 4, it is now below the maximum archive size and so the bot used it as the first archive page it found with space. You can try setting|numberstart=6 in the ClueBot III configuration, so it will start searching for space from Archive 6.isaacl (talk)03:30, 17 July 2023 (UTC)[reply]

Not sure what is going on with some of the old SPVs and singles, likeWikipedia:Wikipedia_Signpost/2009-07-27/SPV. I updated all the articles to use the modern header and footer templates, but for some reason this is causing the SPV pages to behave weirdly. Note that when it indents the block for the "reader comments" bit at the end of each article, it never outdents, meaning that the next story is just indended by one tab. Of course, by the time you get to the end, it is about an inch wide. What is going on here?jp×g20:03, 20 July 2023 (UTC)[reply]

Each block is currently missing a closing</div>. I haven't investigated why. –Jonesey95 (talk)21:22, 20 July 2023 (UTC)[reply]

I think it's because in something likeWikipedia:Wikipedia Signpost/2009-07-27/Board elections, you have {{Wikipedia:Signpost/Template:Signpost-article-start}}, which has a final noincluded div. In the article, that div is added by {{Wikipedia:Signpost/Template:Signpost-article-comments-end}}, but that template is noincluded. Therefore a final div is missing.

So the cleanup would be...<noinclude>{{Wikipedia:Signpost/Template:Signpost-article-comments-end...}}</noinclude> →<noinclude>{{Wikipedia:Signpost/Template:Signpost-article-comments-end...}}</noinclude><includeonly></div></includeonly>

And you might as well take the opportunity to shove any category in the noinclude section as well since you've got 10-20 sortkeys trying to override each other.Headbomb {t ·c ·p ·b}17:27, 23 July 2023 (UTC)[reply]

Be careful in trying the above approach. Seethe previous discussion above before embarking on a big fix; maybe try a proposed fix on one or two issues' worth of articles first, as I recommended above. –Jonesey95 (talk)18:10, 23 July 2023 (UTC)[reply]

• The more I think about this, the more stupid it seems that we havesome single-page-view issues at Signpost/YYYY-MM-DD/SPV, which use the old SPV templates, while we have all the rest at Signpost/Single/YYYY-MM-DD, which use Single templates. This doesn't seem very sustainable -- I think it may just be better to cut the Gordian knot and modify them all to use the modern formatting and live in /Single/.jp×g04:55, 29 July 2023 (UTC)[reply]

Template:Signpost-main-page-body-end-footer-begin was only linked to from about 50 pages overall; most of these were transclusions of the main Signpost page, so when you only counted direct transclusions it was about five or six. The entire contents of the template are:

</div><div>

This doesn't seem like it really warrants having its own template, especially if it is only being transcluded once or twice anywhere (mostly the Signpost main page and the next issue preview page; the other transclusions were from userspace). Accordingly, I've substed it into the zones where it goes, and am going to CSD it.jp×g20:31, 22 July 2023 (UTC)[reply]

Seethis.@Zinnober9:@Jonesey95:@Headbomb: Strange fostered content error happening here, it looks like -- I will confess to some ignorance of the internal workings of precisely how the modules generate and return rows. The blank row up at the top is fine (I didn't intend for it to be in there, but that's the way it shook out, and it doesn't actually cause any problems. I do intend to make more templates of this sort, though, so if we can figure out what's going on I think it will profit us. Thoughts?jp×g09:04, 23 July 2023 (UTC)[reply]

Fixing the root issue would be ideal, but how the table appears matters a lot more thanLint errors. Those are trivial things that can go take a hike, since no one but some obscure reports will ever notice.Headbomb {t ·c ·p ·b}12:55, 23 July 2023 (UTC)[reply]

After a lot of going down rabbit holes and finding nothing but rabbit droppings, I think I fixed the root issue by adding|rowseparator=newline to the template in the correct place. Please check my work to ensure that I didn't break anything. –Jonesey95 (talk)16:35, 23 July 2023 (UTC)[reply]

@Jonesey95: seems to work. I tried to extend the table to have 360 days and 999999 days (i.e. to-date total), but it's displaying weird things. This is what I did.

• [2]
• [3]
• [4]

AFAICT, this is exactly the same syntax as for the other things, which work. But mine don't...Headbomb {t ·c ·p ·b}17:11, 23 July 2023 (UTC)[reply]

@Headbomb: Oh dear. I suppose this means I've failed to document things sufficiently... what those pageview interval variables refer to is elements of dicts inModule:Signpost's index entries. Like this, fromModule:Signpost/index/2023:

{date = "2023-07-17",subpage = "Recent research",title = "Wikipedia-grounded chatbot \"outperforms all baselines\" on factual accuracy",authors = {"Nicolas Jullien", "Andreas Kolbe", "Tilman Bayer"},views = {d007 = 45980, d015 = 45980, d030 = 45980, d060 = 45980, d090 = 45980, d120 = 45980, d180 = 45980},},

These elements are put into the object by Python scripts that run onUser:WegweiserBot when it does the analysis for whatever month or year, and then uploaded to wiki. Why is this so strange and convoluted? I figured it would be simple, since we have a{{Pageviews}} template, to just get the number of pageviews on whatever interval into text, and then use the text on wiki. Apparently this is not the case, and there was literally no way whatsoever to make the graph extension output text data that could be parsed by anything on wiki -- so the only way was to use an external tool to get the numbers and then edit them into a page. It was absolute clown-shoes shit. (maybe not so clownish after all, now that graphs are broken and have no apparent return date). There's no way to add more columns (like 360 or 9999 or whatever) without actually modifyingthe Wegweiser scripts (and probably some other stuff too).jp×g17:45, 23 July 2023 (UTC)[reply]

Then... how hard would it be to update WegweiserBot to take those two additional data points? I noticed it's still in trial / runs ... very sporadically. Maybe automated to weekly run? And have the bot put an ISO date/timestamp inUser:WegweiserBot/Last-run which could then be used to date the data?Headbomb {t ·c ·p ·b}17:51, 23 July 2023 (UTC)[reply]

As Donald-kun points out so eloquently, there are several issues (seeSpecial:Permalink/1168295562) that don't actually exist; the main issue page is a redirect.

I noticed this when I created alist of all the issues so that I could copy/paste them more efficiently, and decided to separate them out and see how many issues each year had.... and 2013 had 58.

Well, turns out something goofy happened, repeatedly. I think what happened was that it was scheduled to be published on one day, and was then published on another, and they didn't use the /Next issue/ staging area back in the day, so there was a great clamor and now there are a bunch of stupid-ass redirects. I am going to try to deal with these: there isn't any real reason to have alternate date pages for Signpost issues, and the fact that there are only ten of them in 690 issues indicates that this is less a problem to be inevitably worked around and more an enemy facility that manufactures pain-in-the-ass edge cases, and moreover is easily bombed. For example,Template:Signpost/Number of issues is apparently off by ten (and always has been, I guess) so I think that what I'm oging to do is move these to theboneyard and be done with it.jp×g23:47, 1 August 2023 (UTC)[reply]

1. Wikipedia:Wikipedia Signpost/2005-04-28
2. Wikipedia:Wikipedia Signpost/2006-12-25
3. Wikipedia:Wikipedia Signpost/2013-06-03
4. Wikipedia:Wikipedia Signpost/2013-06-10
5. Wikipedia:Wikipedia Signpost/2013-06-17
6. Wikipedia:Wikipedia Signpost/2013-06-24
7. Wikipedia:Wikipedia Signpost/2013-07-29
8. Wikipedia:Wikipedia Signpost/2013-09-23
9. Wikipedia:Wikipedia Signpost/2013-11-04
10. Wikipedia:Wikipedia Signpost/2013-11-27

jp×g23:47, 1 August 2023 (UTC)[reply]

Handy list of whatlinksheres:

• WLHWikipedia:Wikipedia Signpost/2005-04-28 is not a redirect: 5/0
• WLHWikipedia:Wikipedia Signpost/2006-12-25 is not a redirect: 5/0
• WLHWikipedia:Wikipedia Signpost/2013-06-03 is not a redirect: 6/766
• WLHWikipedia:Wikipedia Signpost/2013-06-10 is not a redirect: 6/767
• WLHWikipedia:Wikipedia Signpost/2013-06-17 is not a redirect: 5/0
• WLHWikipedia:Wikipedia Signpost/2013-06-24 is not a redirect: 5/671
• WLHWikipedia:Wikipedia Signpost/2013-07-29 is not a redirect: 5/672
• WLHWikipedia:Wikipedia Signpost/2013-09-23 is not a redirect: 5/741
• WLHWikipedia:Wikipedia Signpost/2013-11-04 is not a redirect: 5/683
• WLHWikipedia:Wikipedia Signpost/2013-11-27 is not a redirect: 5/0

jp×g23:48, 1 August 2023 (UTC)[reply]

Okay, so I moved all ten of those to the boneyard. The updated count of all issues was then 680. Then I looked again, at the list of all issues, using{{Is redirect}} on each line to see if any remained. There were none; every issue page was a real issue page (or at least not a redirect). So then I made a list of all articles (atWikipedia:Wikipedia_Signpost/Technical/List_of_all_articles).

Then I copied that into my text editor, removed everything after the issue date's slash, and permuted by unique, to get every issue date that has subpages. I figure maybe something is messed up and there are orphaned articles (i.e. ones that have no date, and are thus not part of an issue). What I found is puzzling.

Okay, there are no redlinks (i.e. no orphaned articles), but I see something completely bizarre now.

There are 680 issue pages. I just checked. Why the hell are there678 issue pages with subpages? What??? This implies we have two issues that... didn't have... any articles. What the fuck.jp×g05:59, 2 August 2023 (UTC)[reply]

Okay, well, here is what I will do: I'll get the list of every issue page (680), and then I'll get this list of every issue page that has subpages (678), and put them side-by-side, and look at the line count: at some point they will diverge, and then I will be able to hunt down the two empty issues (?). Love toobinary search my pants.

* 340 (1  /  2): :^) (2011-08-29)→ 510 (3  /  4):>:( (2014-12-24 versus 2014-12-17)← 425 (5  /  8): :^) (2013-04-15)→ 467 (11 / 16):>:( (2014-02-19 versus 2014-02-12)← 446 (21 / 32): :^) (2013-09-11)→ 456 (43 / 64): :^) (2013-11-20)→ 462 (87 /128): :^) (2014-01-08)

Okay, well, at this point I can just do it manually. The naughty boy isWikipedia:Wikipedia Signpost/2014-02-05, which has no subpages. Let's check:Special:PrefixIndex/Wikipedia:Wikipedia Signpost/2014-02-05. Oh, yes, you are a devious little bastard. What are you? YOU'RE A TEMPLATE FILLED WITH REDLINKS!

But there were supposed to be two, right? Okay, well, doing a precise binary search was a fun gimmick to show off but I am just going to do what I always do and go with rounder numbers.

* 500: :^) (2014-10-08)→ 628>:( (2019-10-31 versus 2019-09-30)← 564: :^) (2016-01-06)→ 596:>:( (2017-02-27 versus 2017-02-06)← 580:>:( (2016-05-17 versus 2016-05-02)← 572: :^) (2016-03-02)→ 576:>:( (2016-04-01 versus 2016-03-30)← 574: :^) (2016-03-16)→ 575: :^) (2016-03-23)

This leaves one with an extra 576, which isWikipedia:Wikipedia Signpost/2016-03-30 (PrefixIndex). Bingo! Another damn template issue with no actual articles.

To the boneyard with them.jp×g06:20, 2 August 2023 (UTC)[reply]

At least that one (2016-03-30) was meant to be an issue. It became 2016-04-01.

I wonder about 2014-02-05 if there's something near it.Headbomb {t ·c ·p ·b}07:07, 2 August 2023 (UTC)[reply]

Crossposting fromWikipedia talk:Wikipedia Signpost/Newsroom:

After finding some bizarre vandalism from June on an old article, that was messing up the Module:Signpost indices, I realized that we probably ought to have some way of tracking edits on old Signpost articles, so I madeWikipedia:Wikipedia_Signpost/Omni-index/Old_pages. RelatedChanges for that ishere; this should give you every most-recent edit that's been made to every old article (i.e. prior to the current year), that match the masks ofWikipedia:Wikipedia Signpost/____-__-__*. I can't make it cover more than thirty days, so probably there ought to be an alarm every 29 days to go check this lol.jp×g22:27, 3 August 2023 (UTC)[reply]

I was going to post about something at the Newsroom talkpage, but in order to illustrate the point I wanted to useWikipedia:Wikipedia Signpost/Templates/Article list maker, whose documentation indicates that you can use it with a "subpage" parameter... so I tried to... and it did nothing. Who wrote the damn documentation anyway? Me? Who knows.

Anyway, so I guess this needs to be fixed.jp×g08:11, 6 August 2023 (UTC)[reply]

SeeWikipedia_talk:Wikipedia_Signpost/Newsroom#Automating_the_updating_of_the_deadline_template - advice from fluent scripters welcome. Regards,HaeB (talk)02:12, 7 August 2023 (UTC)[reply]

Updating the link now that that thread has been archived, as the first issue is still unresolved:Wikipedia_talk:Wikipedia_Signpost/Newsroom/Archive_36#Automating_the_updating_of_the_deadline_template.

Regards,HaeB (talk)07:20, 9 June 2024 (UTC)[reply]

For extremely esoteric webshit reasons...jp×g23:36, 22 August 2023 (UTC)[reply]

Most of these redirects are in Talk spaces and are fine. You don't want someone posting to the talk page of a template /doc page, for example. –Jonesey95 (talk)00:24, 23 August 2023 (UTC)[reply]

Indeed. I mostly made this because I was curious to see how many redirects we had... it turns out the answer is about 200 (and the majority are in talkspace). This is manageable.jp×g00:49, 23 August 2023 (UTC)[reply]

Notes: the overwhelming majority of these are useful and ought to stay. The only things of concern here were the couple weird fucksie-foosies that made no sense.Wikipedia talk:Wikipedia Signpost/2005-08-01/Featured content redirected toWikipedia talk:Wikipedia Signpost/2005-07-11/Features and admins, and there were just no comments onWikipedia:Wikipedia Signpost/2005-08-01/Featured content. And the talk page it redirects to, for the July 11 issue, has one comment on it... from July 4... and the page was created on June 20. God only knows what was going on there, but there were only eleven of these weird article comment page redirects, so whatever. A couple drafts that got published and the "leave redirect" option was still enabled... a couple fake single-page editions for issues that never existed... twenty-four of these were trash, leaving us with...