Wikipedia talk:Wikipedia Signpost/Technical

Add topic
Active discussions

Spelunk '22!Edit

@Headbomb, HaeB, JPxG, Bluerasberry, Bri, Smallbones, and FeRDNYC: (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×g 21:51, 6 November 2022 (UTC)

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)
Adding to my watchlist too. ☆ Bri (talk) 18:49, 4 December 2022 (UTC)
  • 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.

Template-driven tracking categoriesEdit

FYI, I've started wrapping {{Template other}} around tracking categories added by Signpost templates, to keep the templates themselves from being included in the category. So far I've hit Template:Signpost/Deadline and Template: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 the negative 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)


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×g 04:03, 7 November 2022 (UTC)

Structured data in drafts and pages -- where does the blurb go? -- additional fieldsEdit

Wondering what's going on in this process -- we have this diff, which is SPS converting a draft to an article, and this 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×g 20:52, 10 November 2022 (UTC)

Draft template redone, draft categories now existEdit

Check it out at Template: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 to Category:Signpost drafts. Subcategories are added based on the following parameter values:

Subcategorization works like this:

Ready-for-copyedit Copyedit-done Final-approval Category
(any) (any) (any) Signpost drafts
old (any) (any) Signpost drafts, inactive
no no no Signpost drafts, not ready for copyedit
yes no no Signpost drafts, ready for copyedit
yes yes no Signpost drafts, ready for final check
yes yes yes Signpost drafts, ready for publication

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

Module indexEdit

I have come up with a mechanism for creating automatic discussion-board pages for Signpost issues, like this one: Wikipedia talk:Wikipedia_Signpost/Single/2022-11-28. The way this works is by invoking Module: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 (like Module: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 at Module 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×g 23:54, 1 December 2022 (UTC)

Template unearthedEdit

Check this out: Wikipedia:Wikipedia Signpost/Templates/Signpost edition pageviews. I found this in use at Wikipedia talk:Wikipedia Signpost/Archives/2016 and Wikipedia talk:Wikipedia Signpost/Archives/2017. Apparently this has been sitting around for some time! jp×g 01:14, 4 December 2022 (UTC)

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 gives wrong 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 had 1493 views on January 3. But Wikipedia_talk:Wikipedia_Signpost/Single/2023-01-01 shows 90, while the old template shows the correct graph.

Andreas JN466 12:42, 15 January 2023 (UTC)

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 the next 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. --Andreas JN466 13:42, 15 January 2023 (UTC)
Both of these are in the process of being deprecated, actually -- you can see a mockup of what's being set up at User: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×g 09:05, 16 January 2023 (UTC)

Automated graphs of view counts for all articles in an issueEdit

Again with the magical help of Module: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×g 03:07, 5 November 2022 (UTC)

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×g 03:12, 5 November 2022 (UTC) S
@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 view rate (per... day? hour?) more than count, 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 away most 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 to those articles... well, somehow seems even harder to discern, actually. At least for me.)
I don't mean to knock your effort at all, the graphs look very good and the effort is impressive. Perhaps the information is just presented in a form that isn't meant for me, 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)
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 whole Signpost, 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 somehow queries the external URL. I tried to figure this out for a couple hours last night and got mad and did something else. jp×g 12:44, 6 November 2022 (UTC)
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 at Template: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×g 00:09, 7 November 2022 (UTC)
@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 the Vega project's rather clever online 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 loading Signpost pageview datasets manually from API request URLs (which I generated in the API 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 in this 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 thing directly in Vega's online editor if you're curious.
The data currently 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's wikirest:// URLs as the data source, with article names automatically selected rather than having to be individually added to the graph, is the least 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 the Template: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)

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×g 02:12, 4 December 2022 (UTC)

Omni-index, to monitor ALL edits in signpost space using RelatedChangesEdit

I have created Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia talk:Wikipedia Signpost/Omni-index; I used Quarry SQL to come up with a list of every Signpost article in both namespaces. This is complete for now; you can click the RC links at the top of these pages to see all edits in Signpost 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×g 10:24, 13 December 2022 (UTC)

misc SPS.JS sundriesEdit


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

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)

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×g 19:36, 22 December 2022 (UTC)

Redirects, indices, etcEdit

I am currently in the process of writing a big-ass script (which I'm calling "Wegweiser") to better integrate Module: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 reading this Vox article, you can click on the author's name in the byline to get this 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×g 23:48, 6 January 2023 (UTC)

WTF momentsEdit

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×g 01:00, 7 January 2023 (UTC)

And Wikipedia: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)

More ghosts, some of which I moved to drafts:


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 the Signpost 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×g 04:27, 8 January 2023 (UTC)

Mass of catsEdit

What the hell is going on in Special: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 to Module:Signpost and the article list maker. What is to be done about this? jp×g 01:08, 7 January 2023 (UTC)

I have written a massive Wegweiser script that's capable of integrating these categories' contents into the Signpost module (i.e. everything in Category:Wikipedia_Signpost_Book_review_archives would be tagged with bookreview), 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×g 04:25, 8 January 2023 (UTC)

Wegweiser progressEdit

See Module 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×g 08:34, 9 January 2023 (UTC)

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×g 08:37, 9 January 2023 (UTC)

Lint errorsEdit

What the hell is going on here? jp×g 08:38, 9 January 2023 (UTC)

  • Missing end tag: 3,721  Y Partly done, waiting for JWB run to add article-end templates (see below)
  • Obsolete tag: 2,679   Done
  • Stripped tag: 317  Y Partly 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)
Many of the (obsolete tag) font errors, and many of the other errors are in editors' signatures on Signpost 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)
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 of these 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 is not a valid fix for all center tags, but for this pattern, it works. – Jonesey95 (talk) 02:03, 28 January 2023 (UTC)
The above center tags have been fixed by a bot. – Jonesey95 (talk) 21:04, 31 January 2023 (UTC)
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)

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)

Signpost series template on standalone pagesEdit

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 is something like this on each of the Series pages listed 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)

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

Missing and stripped closing div tags in articlesEdit

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. If JPxG 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 on this 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)

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)
I have removed the closing div tag from after the "reader comments" text that appears in the /Single pages. This means that these pages will need "article-end" templates added, like this. I hope that JPxG is available to run JWB on those couple thousand pages. – Jonesey95 (talk) 16:32, 31 January 2023 (UTC)
Oh, jeez. Well: I believe that these are all the articles using Wikipedia: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×g 20:05, 31 January 2023 (UTC)
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)

Draft helper links moved to edit noticeEdit

I have reworked Template:Signpost draft helper into Template: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 with Wikipedia: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×g 23:25, 12 January 2023 (UTC)

Database reportsEdit

I have finally figured out that {{Database report}} exists, which means that Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia 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}} (5288) and {{Signpost/Number of issues}} (677). jp×g 00:35, 13 January 2023 (UTC)

A tragedy in one act: the skulls beside the road from last timeEdit

While spelunking, I found this page, where apparently Pete Forsyth tried to do this exact same thing in 2016. jp×g 11:18, 13 January 2023 (UTC)

They used slack then?? I feel like we've slid back a bit... ☆ Bri (talk) 04:20, 14 January 2023 (UTC)
Yeah, the poor schlep who they have as the EiC now can't even get all the editors to join a freakin' Discord channel. jp×g 11:31, 14 January 2023 (UTC)

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×g 03:06, 17 January 2023 (UTC)

Signpost searchEdit

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 2008
intitle:/Signpost\/20[0-9]8-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"
Citizendium in 2013
intitle:/Signpost\/2013-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"
Citizendium in 2010 to 2014
intitle:/Signpost\/201[0-4]-[0-9]{2}-[0-9]{2}\/.*/ -intitle:"/SPV" "Citizendium"
Citizendium before 2010
intitle:/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×g 10:17, 15 January 2023 (UTC)

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:

which looks like this. jp×g 10:20, 15 January 2023 (UTC)

Got it: see Template:Signpost/Search and Template: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)
Yeah, the input box thing is kind of half-assed. I looked through the documentation 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×g 11:24, 1 February 2023 (UTC)
I think I fixed it by adding "prefix=WP:" to the template. ☆ Bri (talk) 15:59, 1 February 2023 (UTC)

Series templates fixedEdit

I have mostly finished my spelunk of the omni-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 at Wikipedia: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, at Wikipedia:Wikipedia_Signpost/Statistics/Tags. They probably need some winnowing out (and per Wikipedia: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×g 08:41, 28 January 2023 (UTC)

Byline pagesEdit

Just as for the tag pages, I did some analysis 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 at Wikipedia:Wikipedia_Signpost/Statistics/Authors. Anyway, I was able to use this to make a few author byline pages, which are linked to from Wikipedia: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×g 08:45, 28 January 2023 (UTC)

Recent page move without redirect broke transclusionEdit

This recent page move broke Signpost 2011-08-09. There was a transcluded red link in the /Single page. I fixed 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)

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

Question about author name changeEdit

@JPxG, I assume that this 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)

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 the Signpost 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 not have 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×g 18:42, 30 January 2023 (UTC)