Wikipedia talk:Wikipedia Signpost/Technical

Spelunk '22!

@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)[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

Template-driven tracking categories

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)[reply]

Templates

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)[reply]

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

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)[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]

Draft template redone, draft categories now exist

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)[reply]

Module index

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)[reply]

@JPxG: Did you go with one of the two alternatives bulleted immediately above? I noticed some oddities like 2024-03-29 News and notes is untagged, but the preceding and following 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]

Template unearthed

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)[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 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 JN 466 12: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 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 JN 466 13: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 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)[reply]

Automated graphs of view counts for all articles in an issue

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

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

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)[reply]

RC · Talk RC

misc SPS.JS sundries

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

Redirects, indices, etc

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)[reply]

WTF moments

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

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)[reply]

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)[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×g 05: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×g 23:03, 27 January 2023 (UTC)[reply]

More ghosts, some of which I moved to drafts:

Redirects

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)[reply]

Mass of cats

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)[reply]

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)[reply]

Done.

Wegweiser progress

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

Lint errors

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

Missing end tag: 3,721 Partly done, waiting for JWB run to add article-end templates (see below)
Obsolete tag: 2,679 Done
Stripped tag: 317 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)[reply]

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)[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 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)[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]

Signpost series template on standalone pages

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)[reply]

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

Missing and stripped closing div tags in articles

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)[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 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)[reply]

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)[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]

Draft helper links moved to edit notice

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)[reply]

Database reports

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}} (5610) and {{Signpost/Number of issues}} (702). jp×g 00:35, 13 January 2023 (UTC)[reply]

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

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

Signpost search

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)[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 like this. jp×g 10:20, 15 January 2023 (UTC)[reply]

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)[reply]

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)[reply]

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

Series templates fixed

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)[reply]

Byline pages

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)[reply]

Recent page move without redirect broke transclusion

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)[reply]

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

Question about author name change

@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)[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 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)[reply]

Technical issues

"Next issue" links don't work from issue 5 to issue 6. For example Wikipedia:Wikipedia Signpost/2023-03-09/In the media does not have a "next" link displayed, even though it was added by the script.
We probably should straighten out http vs https issues -- see this
A reader reported 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 is Wikipedia: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. Example here and here. I think I might have cracked the code. Note the comment in the second one:

Message sent by User:JPxG@metawiki using the list at https://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×g 19: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 the bottom:

Message sent by User:JPxG@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Signpost&oldid=24726786

. The second one has this editnote at the top:

Message sent by User:JPxG@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Signpost&oldid=24726786

. Huh??? jp×g 19: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 in Special: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 and Jonesey95: 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 like Wikipedia:Wikipedia Signpost/Next issue/News and notes, and the script automatically moves them to Wikipedia: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 at Wikipedia: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's extra 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×g 12: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×g 12:38, 21 March 2023 (UTC)[reply]

For what it's worth, I have made a documentation 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×g 12:03, 21 March 2023 (UTC)[reply]

Double sending

Per above. Phab ticket is T93049.

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

Doubles
User talk:AshokChakra hist User talk:AwfulReader hist User talk:BabbaQ hist User talk:Curtiskwong8 hist User talk:DePiep/news hist User talk:Donald Trung hist User talk:Hans5958 hist User talk:Haoreima hist User talk:Jakesyl hist User talk:Mega-buses hist User talk:MJL hist User talk:Rachmat04 hist User talk:Tahmid hist

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

Doubles from local delivery

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

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

Another triple is User 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×g 20:49, 20 March 2023 (UTC)[reply]

Okay, all of them are done. This MMS bug needs to be fixed, because this sucks. jp×g 21: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 the https://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. Andreas JN 466 18:20, 22 March 2023 (UTC)[reply]

Pageview test

Let's see... jp×g 23: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:

Date	Subpage	Title	7-day	15-day	30-day	60-day	90-day	120-day	180-day
2023-02-04	WikiProject report	WikiProject Organized Labour	792	1509	2072	2672	2672	2672	2672
2023-02-04	Traffic report	Films, deaths and ChatGPT	938	1525	1822	2057	2057	2057	2057
2023-02-04	Tips and tricks	XTools: Data analytics for your list of created articles	1320	1861	2153	2383	2383	2383	2383
2023-02-04	Special report	Legal status of Wikimedia projects "unclear" under potential European legislation	1436	2055	2345	2609	2609	2609	2609
2023-02-04	Section 230	Twenty-six words that created the internet, and the future of an encyclopedia	1821	2448	2742	2982	2982	2982	2982
2023-02-04	Recent research	Wikipedia's "moderate yet systematic" liberal citation bias	3246	7916	8283	8635	8635	8635	8635
2023-02-04	Opinion	Study examines cultural leanings of Wikimedia projects' visual art coverage	1006	1583	1833	2080	2080	2080	2080
2023-02-04	Op-Ed	Estonian businessman and political donor brings lawsuit against head of national Wikimedia chapter	836	1331	1580	1814	1814	1814	1814
2023-02-04	News and notes	Foundation update on fundraising, new page patrol, Tides, and Wikipedia blocked in Pakistan	1733	2417	2972	3431	3431	3431	3431
2023-02-04	In the media	Furor over new Wikipedia skin, followup on Saudi bans, and legislative debate	1375	2065	2360	2603	2603	2603	2603
2023-02-04	From the editor	New for the Signpost: Author pages, tag pages, and a decent article search function	1219	1842	2118	2312	2312	2312	2312
2023-02-04	Featured content	20,000 Featureds under the Sea	680	1163	1427	1657	1657	1657	1657
2023-02-04	Disinformation report	Wikipedia on Santos	3745	4413	4816	5104	5104	5104	5104

Date	Subpage	Title	7-day	15-day	30-day	60-day	90-day	120-day	180-day
.
2023-02-04	WikiProject report	WikiProject Organized Labour	271	356	405	501	515	544	612	{{{views360}}}	{{{views999999}}}.
2023-02-04	Traffic report	Films, deaths and ChatGPT	467	650	724	779	792	820	886	{{{views360}}}	{{{views999999}}}.
2023-02-04	Tips and tricks	XTools: Data analytics for your list of created articles	479	613	659	692	716	758	828	{{{views360}}}	{{{views999999}}}.
2023-02-04	Special report	Legal status of Wikimedia projects "unclear" under potential European legislation	770	980	1044	1087	1106	1130	1216	{{{views360}}}	{{{views999999}}}.
2023-02-04	Section 230	Twenty-six words that created the internet, and the future of an encyclopedia	988	1202	1274	1332	1345	1385	1476	{{{views360}}}	{{{views999999}}}.
2023-02-04	Recent research	Wikipedia's "moderate yet systematic" liberal citation bias	2359	4872	4990	5096	5142	5172	5268	{{{views360}}}	{{{views999999}}}.
2023-02-04	Opinion	Study examines cultural leanings of Wikimedia projects' visual art coverage	439	599	629	666	678	709	782	{{{views360}}}	{{{views999999}}}.
2023-02-04	Op-Ed	Estonian businessman and political donor brings lawsuit against head of national Wikimedia chapter	442	546	595	627	639	669	729	{{{views360}}}	{{{views999999}}}.
2023-02-04	News and notes	Foundation update on fundraising, new page patrol, Tides, and Wikipedia blocked in Pakistan	985	1235	1378	1491	1533	1575	1696	{{{views360}}}	{{{views999999}}}.
2023-02-04	In the media	Furor over new Wikipedia skin, followup on Saudi bans, and legislative debate	956	1202	1292	1342	1364	1397	1523	{{{views360}}}	{{{views999999}}}.
2023-02-04	From the editor	New for the Signpost: Author pages, tag pages, and a decent article search function	770	990	1055	1082	1087	1116	1167	{{{views360}}}	{{{views999999}}}.
2023-02-04	Featured content	20,000 Featureds under the Sea	324	432	477	499	512	538	599	{{{views360}}}	{{{views999999}}}.
2023-02-04	Disinformation report	Wikipedia on Santos	2451	2691	2857	2940	3012	3077	3275	{{{views360}}}	{{{views999999}}}

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×g 01:52, 29 June 2023 (UTC)[reply]

Weird archive thing

Noting that this happened: ClueBot III moving a bunch of shit to Archive 4 even though we have an Archive 5 and Archive 6. Huh? jp×g 03: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]

SPV display bugs

Not sure what is going on with some of the old SPVs and singles, like Wikipedia: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×g 20: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 like Wikipedia: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. See the 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 have some 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×g 04:55, 29 July 2023 (UTC)[reply]

More spelunking

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 style="clear:both; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif; text-align:center; font-size:100%; line-height:120%; margin-top:30px;">

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×g 20:31, 22 July 2023 (UTC)[reply]

Signpost pageviews messed up

See this. @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×g 09:04, 23 July 2023 (UTC)[reply]

Fixing the root issue would be ideal, but how the table appears matters a lot more than Lint 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.

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 in Module:Signpost's index entries. Like this, from Module: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 on User: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 modifying the Wegweiser scripts (and probably some other stuff too). jp×g 17: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 in User:WegweiserBot/Last-run which could then be used to date the data? Headbomb {t · c · p · b} 17:51, 23 July 2023 (UTC)[reply]

Pageviews for 2023-07-17 (V)
Subpage	Title	7-day	15-day	30-day	60-day	90-day	120-day	180-day
Traffic report	The Idol becomes the Master	364	531	583	657	690	712	742
Tips and tricks	What automation can do for you (and your WikiProject)	1072	1213	1320	1461	1540	1585	1655
Recent research	Wikipedia-grounded chatbot "outperforms all baselines" on factual accuracy	46363	46818	47047	47232	47336	47426	47539
Obituary	David Thomsen (Dthomsen8) and Ingo Koll (Kipala)	496	620	695	1382	1454	1488	1543
News from the WMF	ABC for Fundraising: Advancing Banner Collaboration for fundraising campaigns	331	435	470	538	565	587	613
News and notes	Big bux hidden beneath wine-dark sea as we wait for the Tides to go out?	827	1175	1300	1376	1417	1445	1487
In the media	Tentacles of Emirates plot attempt to ensnare Wikipedia	2216	2561	2817	2949	2989	3022	3072
In focus	Are the children of celebrities over-represented in French cinema?	428	576	634	692	726	750	788
Humour	New fringe theories to be introduced	580	808	926	1024	1069	1105	1147
Featured content	Scrollin', scrollin', scrollin', keep those readers scrollin', got to keep on scrollin', Rawhide!	379	515	583	669	706	723	748
Cobwebs	If you're reading this, you're probably on a desktop	647	844	895	983	1014	1035	1068

Fake news! FAKE NEWS!!!!!

Avatar of Donald J. Trump

Donald J. Trump
@realDonaldTrump

The LYING, FAILING Signpost has done it again! Many Signpost issues DON'T EXIST- issue page is listed in index, but it's a REDIRECT! No Actual Issue there... Fake News!

July 31, 2023^[1]

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

I noticed this when I created a list 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 the boneyard and be done with it. jp×g 23:47, 1 August 2023 (UTC)[reply]

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

Handy list of whatlinksheres:

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

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

References

^ I made it up.

What? Are there issue pages with NO article subpages?

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 (at Wikipedia: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.

All of the parent pages that ought to be associated with every article

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 there 678 issue pages with subpages? What??? This implies we have two issues that... didn't have... any articles. What the fuck. jp×g 05: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 too binary 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 is Wikipedia: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 is Wikipedia:Wikipedia Signpost/2016-03-30 (PrefixIndex). Bingo! Another damn template issue with no actual articles.

To the boneyard with them. jp×g 06: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]

Omni-index subpage for old articles

Crossposting from Wikipedia 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 made Wikipedia:Wikipedia_Signpost/Omni-index/Old_pages. RelatedChanges for that is here; 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 of Wikipedia: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×g 22:27, 3 August 2023 (UTC)[reply]

great sadness and despair in the module

I was going to post about something at the Newsroom talkpage, but in order to illustrate the point I wanted to use Wikipedia: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×g 08:11, 6 August 2023 (UTC)[reply]

Automating the publication deadline updates and Newroom page resets

See Wikipedia_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]

All redirects

All redirects in Signpost space

For extremely esoteric webshit reasons... jp×g 23: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×g 00: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 to Wikipedia talk:Wikipedia Signpost/2005-07-11/Features and admins, and there were just no comments on Wikipedia: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...

All redirects in Signpost space, after little cleanup

jp×g 00:58, 23 August 2023 (UTC)[reply]

Of these 169, basically all of them seem to be useful and formatted normally. The exception is Wikipedia talk:Wikipedia Signpost/Newsroom/Suggestions/Archive 1 through Wikipedia talk:Wikipedia Signpost/Newsroom/Suggestions/Archive 25, which just redirect to the non talk versions of these pages and don't seem to have any real purpose, but I do not have time right now to go through and CSD these all for being useless, since they do not really interfere with much. jp×g 01:01, 23 August 2023 (UTC)[reply]

Nineteen Years Of CSSitude

Where are all the styles? What a question. They seem to be... everywhere. But maybe we can this shit out straightforwardly... starting with Wikipedia:Wikipedia Signpost.

Some from Wikipedia's global CSS.
Some from my user CSS (and presumably yours, or Jimbo's, depending on who is reading it).
Some inline (<div style="clear:both; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif; text-align:center; font-size:100%; line-height:120%; margin-top:30px;"> for the footer).
Template:Signpost-main-page-body-begin/styles.css (note that this is done with templatestyles so the "Template:" does not appear. Also it doesnt transclude the template itself for some reason)
Wikipedia:Signpost/Template:Signpost-header redir to Wikipedia:Wikipedia Signpost/Templates/Signpost-header

None inline here.
Wikipedia:Wikipedia Signpost/Templates/Signpost-header/styles.css

Wikipedia:Signpost/Template:Signpost-snippet redir to Template:Signpost/snippet

None inline here.
Template:Signpost/snippet/styles.css

Wikipedia:Signpost/Template:Signpost-footer redir to Wikipedia:Wikipedia Signpost/Template:Signpost-footer

None inline here.
Wikipedia:Wikipedia Signpost/Template:Signpost-footer/styles.css

jp×g 18:03, 23 August 2023 (UTC)[reply]

A sleeker approach(?)

Search for all Signpost-titled pages that mention "css" gives 296... eliminating mentions of it in articles, talk pges, archives, etc:

css

Module:Signpost poll

legend :css('margin', '4px') :tag('span') :css('display', 'inline-block') :css('width', '1.5em') :css('height', '1.5em') :css('margin'...

Module:Signpost poll/config

the vote visualization. They can be in any -- format usable with inline CSS. colors = { '#006699', -- Foundation blue '#339966', -- Foundation red...

Wikipedia:Featured picture candidates/Götterdämmerung Also Let's See If The Signpost Fixes the Nom Names this Week.

don't think it's as big of a deal as it might be normally. Considered a CSS crop, but thought it would be hard to get the precise crop necessary, since...

Wikipedia:Wikipedia Signpost/Templates/Signpost-header/styles.css

.signpost-header { box-sizing: border-box; padding: 1em 2vw; border-bottom: 3px double #999; border-top: 3px double #bbb; background-color: #FFF;...

Wikipedia:Wikipedia Signpost/Templates/Signpost-article-comments-end/styles.css

.signpost-article-footer { clear: both; display: flex; flex-direction: row; flex-wrap: wrap; margin-top: 4em; } .signpost-succession { border-bottom:...

User:Mr. Stradivarius/gadgets/SignpostTagger.js

dateLabel = new OO.ui.LabelWidget( { $: this.$, label: $( '<span>' ).css( 'font-style', 'italic' ).text( currentPage.getDate() ) } ); this.subpageLabel...

Wikipedia:Wikipedia Signpost/Template:Signpost-footer/styles.css

.signpost-footer { padding-top: 2em; } .signpost-issue-navigation, .signpost-ticker, .signpost-linkbar { box-sizing: border-box; clear: both; font-family:...

Wikipedia talk:Wikipedia Signpost/Templates/Signpost-header/Normal

add a class to the font attributes to allow us to change them with custom CSS, like I did for a related page there? --Mahmudmasri (talk) 16:30, 4 December...

Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start-v2

This template uses TemplateStyles: Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start-v2/styles.css...

Wikipedia:Wikipedia Signpost/Templates

gnpost-article-header-v2/sandbox/styles.css Wikipedia Signpost/Templates/Signpost-article-header-v2/styles.css Wikipedia Signpost/Templates/Signpost-article-start-v2...

Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start

This template uses TemplateStyles: Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start/styles.css...

Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start/styles.css

/* {{pp-vandalism|small=yes}} */ .wp-signpost-block { max-width: 46em; line-height: 1.6em; font-size: 1em; font-family: 'Helvetica Neue', Helvetica...

Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start-v2/styles.css

/* {{pp-vandalism|small=yes}} */ .wp-signpost-block-2 { line-height: 1.6em; } .wp-signpost-block-2-full { font-size: 1em; font-family: 'Helvetica Neue'...

Wikipedia:Wikipedia Signpost/Templates/Signpost-article-header-v2/styles.css

/* {{pp-protected|small=yes}} */ .wp-signpost-article-header-2 { clear: both; padding: 0 2vw; max-width: 80em; margin: 2em auto 0; } .wp-signpost-article-header-2...

Wikipedia:Wikipedia Signpost/Templates/Signpost-article-header-v2/sandbox/styles.css

.wp-signpost-article-header-2 { clear: both; padding: 0 2vw; max-width: 80em; margin: 2em auto 0; } .wp-signpost-article-header-2 .signpost-segment...

User:Mr. Stradivarius/gadgets/SignpostTagger-test.js

dateLabel = new OO.ui.LabelWidget( { $: this.$, label: $( '<span>' ).css( 'font-style', 'italic' ).text( currentPage.getDate() ) } ); this.subpageLabel...

Wikipedia talk:Wikipedia Signpost/Technical

talk:Signpost/snippet/sandbox/styles.css Template talk:Signpost/snippet 232 Template talk:Signpost/snippet/styles.css Template talk:Signpost/snippet 233...

Wikipedia talk:Wikipedia Signpost/Images and logos

inline PNG, what I get is a "broken image" icon. It also doesn't support CSS for floating, what I get is the "broken image" icon in an empty lead section...

Template:Signpost/DateCountdown

labeling and the percentage display. |width=number or percentage Optional CSS width for the bar, defaults to 100%. Values followed by a percent sign are...

Template:Signpost/snippet/sandbox

the like). TemplateStyles are drawn from Template:Signpost/snippet/styles.css. With respect to HTML, it does this: It creates a <div> with the class signpost-snippet...

Template:Signpost/DateCountdown/doc

labeling and the percentage display. |width=number or percentage Optional CSS width for the bar, defaults to 100%. Values followed by a percent sign are...

Template:Signpost/snippet

the like). TemplateStyles are drawn from Template:Signpost/snippet/styles.css. With respect to HTML, it does this: It creates a <div> with the class signpost-snippet...

Template:Signpost/snippet/doc

the like). TemplateStyles are drawn from Template:Signpost/snippet/styles.css. With respect to HTML, it does this: It creates a <div> with the class signpost-snippet...

Template:Signpost/snippet/testcases

class="signpost"> <templatestyles src="Signpost-main-page-body-begin/styles.css"/><div class="signpost-main-page-body plainlinks"> {{Signpost/snippet|{{Wikipedia:Wikipedia...

Wikipedia talk:Wikipedia Signpost/Archive index

Consider CSS changes for better narrow viewport (e.g. mobile device in portrait mode) display 41 Wikipedia talk:Wikipedia Signpost/Archive 10#Consider CSS changes...

Wikipedia talk:Wikipedia Signpost/Omni-index

Template talk:Signpost/snippet/sandbox/styles.css Template talk:Signpost/snippet/styles.css Template talk:Signpost/snippet/testcases Template...

Wikipedia talk:Wikipedia Signpost/Newsroom/Archive 35

template that applies a specific CSS class, so anyone wanting to suppress the message can do so in their personal CSS file. isaacl (talk) 15:56, 26 June...

Template:Signpost/snippet/styles.css

/* {{pp|small=yes}} */ .signpost-snippet { page-break-inside: avoid; break-inside: avoid; clear: both; padding: 7px 0; } .signpost-snippet > div {...

Template:Signpost-main-page-body-begin/styles.css

.signpost-main-page-body { box-sizing: border-box; column-width: 15em; column-gap: 5em; max-width: 70em; margin: 15px auto; padding: 0 2vw; }...

Template:Signpost/snippet/sandbox/styles.css

.sandbox-signpost-snippet { page-break-inside: avoid; break-inside: avoid; clear: both; padding: 7px 0; } .sandbox-signpost-snippet > div, .sandb...

User:ClueBot III/Detailed Indices/Wikipedia:Wikipedia Signpost/Newsroom/Suggestions/Archive 23

Wikipedia:Wikipedia Signpost/Newsroom/Suggestions/Archive 23 75 Global JS and CSS 2014-08-25 20:14 2014-08-25 20:14 1 1544 Wikipedia:Wikipedia...

Template talk:Signpost/snippet

{{Edit protected}} __NOTOC__ __NOEDITSECTION__<div style="clear:both; padding:7px 0;"><h2 style="font-family:Georgia, Palatino, Palatino Linotype, Times...

Template talk:Signpost-subscription

it's more semantically correct and accessible to use the <div> tags and CSS. It's not a table of data; using HTML tables for layout purposes is bad practice...

Wikipedia:Wikipedia Signpost/Omni-index/Linkshere

Signpost/Rquote/doc 002 000 001 000 3 @ Wikipedia:Wikipedia Signpost/September 2022 header.css 001 000 000 000 1 @ Wikipedia:Wikipedia Signpost/Series 003 000 001 000 4...

User:ClueBot III/Master Detailed Indices/Wikipedia:Wikipedia Signpost/Newsroom/Suggestions

Wikipedia:Wikipedia Signpost/Newsroom/Suggestions/Archive 23 75 Global JS and CSS 2014-08-25 20:14 2014-08-25 20:14 1 1544 Wikipedia:Wikipedia...

Anyway, someone please correct me if I'm mistaken, but it doesn't seem like there is strictly speaking a need for toe current situation: Signpost pages are styled by a number of far-flung stylesheets that are called by templates within templates behind redirects etc etc, and then half the shit in a Signpost article is styled inline anyway, and etc etc.

As far as I can tell, none of the class names on different stylesheets overlap. That is to say, the class "signpost-header-subheadings" referenced in Wikipedia:Wikipedia Signpost/Templates/Signpost-header/styles.css is only ever styled by that sheet, there's no other sheet that styles it different on different pages, or some other type of content for which "signpost-header-subheadings" is used. That is to further say, the signpost-header styles.css does not conflict with the other .csses (in fact they're all invoked on the same page).

So what I propose is this:

All Signpost styles in a single css file. There aren't that many, so this shouldn't be too hard.

All references to stylesheets amended to go to that single css file.

All styled elements on Signpost pages, templates, etc are given distinct class names, which are reflected in the global stylesheet.

Inline styling = bad fail no.
This part will take 100 years

jp×g 18:49, 23 August 2023 (UTC)[reply]

Inline styles

Might as well just put them here.

Template:Signpost archive

cover item woes

Signpost/item is a circus
every signpost datepage from Wikipedia:Wikipedia Signpost/2019-04-30 onwards uses a format like
- {{Signpost/item|{{{1}}}|11|2023-08-15|Traffic report|'Cause today it just goes with the fashion|0.3 MB}}
why is there a useless sixth parameter for the article size? who knows lmao.
how far back do the blurbs for the rss feed go? who knows lmao.

jp×g 17:09, 25 August 2023 (UTC)[reply]

ruh-roh! Wikipedia:Wikipedia Signpost/2010-06-28/Public Policy Initiative has this in start:

<noinclude>{{Wikipedia:Signpost/Template:Signpost-header|||}}</noinclude>

{{Wikipedia:Signpost/Template:Signpost-article-start|Introducing the Public Policy Initiative|By [[User:Sross (Public Policy)|Sage Ross]]|June 28, 2010}}

i thought i modernized all the article headers. i guess tf not.

Wikipedia:Wikipedia Signpost/2015-05-20/Arbitration report also uses signpost-header

Wikipedia:Wikipedia Signpost/2018-02-20/Recent research:

<noinclude>{{Wikipedia:Wikipedia Signpost/Templates/RSS description|1=Politically diverse editors write better articles; Reddit and Stack Overflow benefit from Wikipedia but don't give back: There might be good things about an edit war.}}{{Wikipedia:Signpost/Template:Signpost-header|||}}</noinclude>

Wikipedia:Wikipedia Signpost/2018-10-28/In the media:

<noinclude>{{Wikipedia:Wikipedia Signpost/Templates/RSS description|1=Wikipedia in the news}}{{Wikipedia:Signpost/Template:Signpost-header|||}}</noinclude>

Wikipedia:Wikipedia Signpost/2019-03-31/In the media:

<noinclude>{{Wikipedia:Wikipedia Signpost/Templates/RSS description|1=Women's history month: An explosion of women's history coverage, continuing coverage.}}{{Wikipedia:Signpost/Template:Signpost-header|||}}</noinclude>

Wikipedia:Wikipedia Signpost/2018-12-24/Arbitration report:

<noinclude>{{Wikipedia:Wikipedia Signpost/Templates/RSS description|1=Year ends with one active case: GiantSnowman asked to chill, and other disputes addressed by Arbcom (or not).}}{{Wikipedia:Signpost/Template:Signpost-header|||}}</noinclude>

ugh. jp×g 17:30, 25 August 2023 (UTC)[reply]

trying to come up with some remotely plausible way of fixing this, and nothing is really coming to mind.

a) articles back to 2018 or so have subheadings embedded in the actual article, in the RSS description template, which can have the title trimmed from it and give a reasonable output

b) articles in old revisions of WP:POST have subheadings in the code of said page, but this is an absolute nightmare to try and deal with lol

ultimately there are only 679 issues so fixing them all manually would take, i dunno, a day or two? seems like a giant pain in the ass -- it would be quicker to automate something, but not if that meant writing 8 different edge-case handlers jp×g 17:50, 25 August 2023 (UTC)[reply]

did them manually for 23-08-15 and 23-08-01. the latter of which was 1:39 after the first, so maybe 1.5 to 2 minutes each: that gives about 16-22 hours for all 679 issues assuming constant time. sounds like a giant pain. also there needs to be some way of extracting these metadata (subheadings and images) regardless. so i think this is a task best addressed later... another thing that springs to mind is that the issue page when viewed directly should probably either display or redirect to the archive page (or vice versa). idk how onlyinclude works, have to sandbox it jp×g 18:05, 25 August 2023 (UTC)[reply]

I think the sixth parameter, the article size, was to provide a warning for people with slow network links. I'm not sure it was ever considered very helpful. ☆ Bri (talk) 18:16, 25 August 2023 (UTC)[reply]
Yeah, based on the innards of the template, it seems to not actually be used for anything. As in, there is no situation where {{{6}}} is displayed in the output... what a mess.
As I recall, it was one of the changes Headbomb implemented when Smallbones assumed the editor-in-chief position. Headbomb left after being asked to pause the deployment of new changes, and showing the size got rolled back at some later point. isaacl (talk) 00:02, 26 August 2023 (UTC)[reply]
Okay, my concrete accomplishment is that I have incorporated a {{{sub}}} param into display mode 2, so that for example, Wikipedia:Wikipedia Signpost/Archives/2023-08-01 will show the subheadings. Overall, it seems puzzling and bizarre to me that the archive issue view is so completely different from the current issue view (it doesn't have the same styling, it doesn't have the same content, etc). It's also bizarre that the intuitive way of finding the archive issue, which is to remove the article's title from the URL and go to Wikipedia:Wikipedia Signpost/2023-08-01, does not bring you to the actual archive issue, it brings you to this silly little minimal list of articles that has no formatting and no content beyond headlines. As far as I can tell this is because the individual issue pages are transcluded in 1293012390 different places, so we can never change anything ever for any reason. Reeeeeee jp×g 18:26, 25 August 2023 (UTC)[reply]
I have made a modification to User:JPxG/SPS.js that actually puts the sub parameter into the issue pages when it creates them. I'm going to try to go through and fix some of the old issues.

Old issues

- Blurbs don't seem to really consistently exist anywhere onwiki -- the publishing script puts them on Wikipedia:Wikipedia Signpost and removes them from the articles themselves, and the issue gets overwritten every publication. Currently they aren't stored anywhere, sometimes they're in RSS descriptions on the article pages but not always -- my SPS.js modification means they will be stored in the individual issue pages by date... for future issues, but past ones have to be backfilled.
- Back to 2020 or so in the revhist for Wikipedia:Wikipedia Signpost they are obtainable by getting the revision prior to the next publication (i.e. for 2022-03-27 the best revision to use is the one on 2022-04-23, the day before the next issue on 04-24; this incorporates any typo fixes or updates or whatever.
- I know that very old Signpost revisions just don't have the current layout at all. Check old revs -- Special:Permalink/9295135 is the 2005-01-10 edition which is totally ad-hoc formatting.
- LivingBot (2012-09-04 to 2016-03-13)
- KharBot 2016-04-01 to 2016-07-04
- Manual??? (2016-08-04 to 2017-02-06)
- SPS.JS (2017-06-08 to present)

- 2016: Special:Permalink/713073378 which looks parseable (has blurbs at least).
{{Wikipedia:Signpost/Template:Signpost-snippet|{{Wikipedia:Wikipedia Signpost/Issue|1}}|News and notes|Trump/Wales 2016|A surprise political announcement.}}

2015: Special:Permalink/658906608 curprev 2015-04-23T15:33:15‎ LivingBot talk contribs block‎ 5,635 bytes +2,838‎ (on behalf of User:The_ed17) bot creating basic main page ready for manual editing (Peachy 2.0 (alpha 8)) undo [restore this version] -- note that there is subsequent editing by Gamaliel in the next few minutes, this was just a template by which to work off. Final version is Special:Permalink/658911203;
{{Wikipedia:Signpost/Template:Signpost-snippet|2015-04-22|In focus|2015 Wikimedia Foundation election preparations underway|4=2015 will see through the biennial community election for the three community-elected seats on the Board of Trustees—the "ultimate corporate authority" of the Wikimedia Foundation and the level at which the strategic decisions regarding the Wikimedia movement are made.}}

2013: Special:Permalink/566795960, 2014-03-29T00:57:33‎ LivingBot talk contribs block‎ 5,709 bytes +1,934‎ (on behalf of User:The_ed17) bot creating basic main page ready for manual editing undo
{{Wikipedia:Signpost/Template:Signpost-snippet|2013-07-31|Traffic report|Bouncing Baby Brouhaha|4=Summary:'' Somewhat predictably, the birth of a new heir to the House of Windsor on 22 July led the English-speaking world to suddenly embrace Monarchism. In honour of this occasion, the Traffic report will be assiduously employing British spelling and dating conventions. Cheers.}}

2012: Special:Permalink/510231365
{{Wikipedia:Signpost/Template:Signpost-snippet|2012-08-27|News and notes|Tough journey for new travel guide|4=Wikimedia editors have been debating a community proposal for the adoption of a new project to host free travel-guide content. The debate reached a new stage when a three-month request for comment on Meta came to an end, with a decision to set up the first new type of Wikimedia project in half a decade. The original proposal for the travel guide unfolded during April on Meta and the Wikimedia-l mailing lists, centring around the wish of volunteer contributors to the WikiTravel project to work in a non-commercial environment.}}

2011: ?

There seem to only be a few edits in 2011. February, April, June, three in July, four in September. I guess there was some kind of different process going on to assemble the front page -- this looks like a gigantic PITA. It was just directly transcluding from the individual issue page like this:

{{Wikipedia:Wikipedia Signpost/{{Wikipedia:Wikipedia Signpost/Issue|1}}|2}}

curprev 2007-12-04T00:44:40‎ Ral315 talk contribs block‎ 1,907 bytes +1‎ Note that updating every week will no longer occur on this page, so you may wish to watchlist Wikipedia:Wikipedia Signpost/Issue. undothank [restore this version]

So yeah, this part is, uh -- I don't know if it's possible to extract blurbs from 2011 back. It might not be possible. There are 350 issues and 2808 articles from 2005-2011, though, so some way of automating this would be useful. Of course this is only if blurbs existed then, which they might nto have. IA snapshots from 2011, 2009, 2007 suggests there weren't any. So I guess whatever, on those ones.

I have a script for this now. See Wikipedia:Wikipedia Signpost/Technical/Silly bespoke scripts#Subtitler. jp×g 🗯️ 04:41, 3 December 2023 (UTC)[reply]
Everything back to 2015-01-07 is done (174/674, 500 remaining). jp×g 🗯️ 22:47, 7 December 2023 (UTC)[reply]
Everything back to mid-2012 is now done, where the subheadings started to be written. I am now going to try to write something to parse this into metadata. jp×g 🗯️ 00:22, 15 December 2023 (UTC)[reply]
To be more specific: back to 2012-07-09. Between then and now (2023-12-04) that is a total of 302 issues and 2,464 articles which have subheadings. jp×g 🗯️ 02:21, 15 December 2023 (UTC)[reply]
Out of 5462 articles, i.e. there are precisely 1,998 unsubheaded articles in 384 issues between 2005-01-10 and 2012-07-02. jp×g 🗯️ 02:24, 15 December 2023 (UTC)[reply]
Oldest article with RSS desc templates is 2017-02-27. jp×g 🗯️ 20:35, 20 December 2023 (UTC)[reply]
four missing them: 2014-12-03, 2014-12-10, 2014-12-17, and 2014-12-24 (?) jp×g 🗯️ 20:40, 20 December 2023 (UTC)[reply]

Last of the old fixes

Individual issue pages, and what they use:

Modern (2010 - current): Template:Signpost/item

{{Signpost/item|{{{1}}}|1|2010-03-01|Reference desk|Wikipedia Reference Desk quality analyzed}}

Old (probably to 2007-09-03 to 2009-02-08): Template:S-s

{{s-s|{{{1}}}|1|2007-09-03|From the editor|From the editor: Interview with Jimbo Wales}}

Very old (2005-01-10 up to 2007-08-27): nothing!

*[[Wikipedia:Wikipedia Signpost/2005-01-10/Portal|Wikipedia website changed to multilingual portal]]

S-s redirects to the cover-item thing, so that's fine. Whatever. Bigger issue is the lack of formatting in issue pages before 2007. I believe there are 138 of those. Regexable? Who knows.

The conversion would be from:

*[[Wikipedia:Wikipedia Signpost/2005-01-10/From the editor|From the editor: Welcome to the Signpost!]]
*[[Wikipedia:Wikipedia Signpost/2005-01-10/Portal|Wikipedia website changed to multilingual portal]]

to:

{{s-s|{{{1}}}|1|2005-01-10|From the editor|From the editor: Welcome to the Signpost!}}
{{s-s|{{{1}}}|2|2005-01-10|Portal|Wikipedia website changed to multilingual portal}}

That is:

*[[Wikipedia:Wikipedia Signpost/ -> {{s-s|{{{1}}}|x|
/ -> |1|
| ->|
]] ->}}

Only issue is getting those numbers to increment by one each time. Not quite sure how to deal with that in regex. Will have to contemplate. jp×g 🗯️ 02:12, 7 November 2023 (UTC)[reply]

I could do something very dumb but very smart at the same time: replace them all with a dummy string, i.e. "UNLIKELYSTRING", then run regex replacements over each series of articles but not globally. That is, run a JWB regex that converts "UNLIKELYSTRING" to "1", but with only one instance replaced, then a second that converts "UNLIKELYSTRING" to "2", etc etc etc. Kind of stupid, but at the same time, quite easy. jp×g 🗯️ 02:14, 7 November 2023 (UTC)[reply]

Against all odds, this somehow worked.

CSS Eye For The Signpost Guy

Okay, time to do this. Here is my general plan of attack:

Figure out what all the templatestylesed stylesheets are for Signpost pages. Should be simple.
Incorporate them into master.css.
Redirect original stylesheets.
(optional) modify their references in the templatestyles invocation to point to master.css.

This may also include the additional step of inventing unique class names for elements.

Another thing I want to do is get rid of all the spans and divs that don't have any class names. What's the point? They should be selectable by a stylesheet. Towards this end you can see e.g. some modifications I made to Template:Signpost/snippet; the class names are all stuff like "signpost-snippet-outer", "signpost-snippet-inner", "signpost-snippet-department" etc.

I am not a doctor of stylesheets but from what I've heard the generally accepted best practice is to separate presentation from content as much as possible, which means inline styles = puke. It should also be possible to, say, restyle something about the website without having to dick around in random obscure stylesheets or templates. One example you can see already is I got rid of the "continue" links on the main page and just made the subheading text link directly to the articles. With all the stuff in one stylesheet this is pretty straightforward. I will keep some notes here for what I do next. jp×g 🗯️ 03:33, 5 December 2023 (UTC)[reply]

Stylesheets I could find easily:

search for intitle:"Signpost" intitle:"css".

jp×g 🗯️ 03:35, 5 December 2023 (UTC)[reply]

Also there is a TON of crap that is made using px values instead of em due to being from like 2008, this should be fixed also. Everything should use em, it's 2023. Mixing sizes is what causes stuff to look like ass on mobile. jp×g 🗯️ 09:52, 10 December 2023 (UTC)[reply]

Snippet sandbox

Template:Signpost/snippet/sandbox

Progress is coming along nicely on a new ver of the snippet template that uses a piccy and then puts the snippet information over it. A number of fields are required for this. To make the template not be a giant pain, these all have to be separated:

Pic location i.e. file name
Pic author
Pic license (the template can then draw these from a subtemplate, i.e. CC4SA will summon a formatted link to the CC website with the license, GPLv3 will link to the GPL, PD doesn't need to link to anything etc -- no need to code all that dreck into the actual field we're calling the snippet template with esp bc itll be the same every taimu)
Pic crop points (not quite sure the best way to do these)

The actual levers we have are: <div style="width: 300px; height: 300px; overflow: hidden;"><div style="position: relative; top: -0px; left: -0px; width: 300px"> for the outer and inner containers respectively. So we can specify top/left offsets. Final computed width is 300. Need to figure out how to reasonable account for these cases:

1:1 aspect ratio picture, needs no processing at all.

1:2 aspect ratio portrait, crop to top - easy, just embed it in this with display size 300 - middle/bottom, slightly modify offsets.

2:1 aspect ratio landscape, have to figure this out

Large image that is being cropped to a small region - who knows.

jp×g 🗯️ 09:39, 10 December 2023 (UTC)[reply]

Wikipedia:Wikipedia Signpost/Technical/sandbox looks like ass right now, issue is that the items are almost-but-not-quite aligned between columns. If they were staggered by 50% it would look great, but being off by just a few pixels looks awful. Probably I should use flexbox or something and have them flow left-to-right top-to-bottom. Hmm but then wouldn't they be forced to all take a row height based on whatever the longest subheading was? Wouldn't there be like, mad dead space? And then if we push the items up to fill that space we end up with the same problem we started with. Much to think about... jp×g 🗯️ 09:42, 10 December 2023 (UTC)[reply]

Actually, no, there wouldn't be mad dead space, there would only be one or two blank rows of text beneath the heading, which isn't that big of a deal, and it looks weird not to do that. I should do this. jp×g 🗯️ 09:43, 10 December 2023 (UTC)[reply]

Metadata header templates

Looking through a bunch of stuff, I see that we have many many articles that transclude Wikipedia:Wikipedia Signpost/Templates/RSS description at the top. Essentially, this is where SPS.js puts the subheading/blurb/etc when it publishes the article (prior to that it's in the draft template). The whole source of that template is this:

<div style="display:none;" itemprop="description">{{Plain text|1={{{1|}}}}}</div>

This is about what I figured. This is good -- it puts the subheading somewhere that's easily accessible and machine-readable. There are currently 1,173 transclusions of this template.

What does this have to do with anything? Well, I am about to go through and process all of those individual issue pages -- the ones where I put subheadings in from the old revisions of the main Signpost page -- and move them from there to the articles themselves, in a metadata header, i.e. this. But I foresee there being other items of metadata to process. Most notably, adding images to articles in the draft template (which gets pulled out of them and put on the main Signpost page and the archive page) currently results in the image params being in the header template during the draft process, and then they stay there after publication. This is a dumb place to have them during the draft process; I incorporated them into the draft template a couple days ago so it's possible to see at a glance what the header image is (and what its crop params are) and what it looks like prior to publication.

Anyway, though, if the pics are in the draft template prior to publication, it may be just as well to put them into a metadata template at the top of the article rather than in the header template (which seems like kind of a weird place to store them anyway).

Factors in favor of putting them in the RSS template (and maybe renaming it to "metadata" if I'm going to be editing all the articles either way):

Easier to work with (whether Wegweiser uses from-scratch string parsing or actual wikitext parsing from a library) -- the header templates often have weird stuff in them, line breaks, templates, links, formatting, inconsistent spacing. The RSS description templates are much more regularly formatted, at least as far as I can tell.

Factors against:

Future design work may involve actually making articles' images display in their headers; this would require another gigantic pain-in-the-arse bot run to fix if i did it.
It doesn't really matter that much whether the params are stored in one template or the other, since both are (currently) configured to not give any output for them. An RSS desc template with an unused img, img-credit, img-license, img-scale, img-x, img-y param is the same deal as a header template with all those params, potential parsing issues aside (which I'm still not entirely sure of the scope of -- and frankly, Wegweiser should just suck it up and get some dependencies if it can't parse goofy stuff in templates).

Go figure. Anyway, I'm going to do some more analysis on the number of RSS desc templates that would need to be added to do a full run of this stuff. jp×g 🗯️ 01:28, 15 December 2023 (UTC)[reply]

A secret third thing would be just getting rid of the RSS-description template altogether and making the subheading be a param passed to the Signpost article header template (which would include the same deal with a non-printing display of the RSS-desc param). Now that I think about it, this seems like it would be pretty poggers; all of the reasoning that argues in favor of putting the pic metadata in the header template applies just as well to putting the subheading in the header template. And indeed, if I was going to make article headers display pictures, that would probably make them taller, and then there'd be a solid reason for wanting the subheading text in there too... jp×g 🗯️ 01:32, 15 December 2023 (UTC)[reply]

There is a slight issue with this, which is that as it stands, the RSS description template on the article page is noincluded. I don't know how this would gel with putting it into the header template; any page that transcluded the article pages would also get itemprops with the RSS description. What would happen for single-page issue pages? I guess it would be possible to put code in the header template to be like

{{#if:{{#titleparts:{{PAGENAME}}|1|2}}|Single|Wow! It's nothing!|stuff to put on the issue pages}}

. I guess that's not so bad. Well, whatever.

Technical jp×g 🗯️ 02:18, 15 December 2023 (UTC)[reply]

Okay, going through all of the transclusions and actually sorting them out, there are:

1084 from articles. The first are in 2017-02-27; the last are obviously the last issue, 2023-12-04.

This means that, out of the 2,464 articles which have subheadings, there are 1,380 (a majority by about 400) that aren't actually included anywhere in the articles themselves.

9 links and one redirect.
78 from drafts, mostly inactive but also including next-issue drafts (56 from userspace drafts, 22 from Signpost space drafts)
8 from single pages? That's very strange -- you'd think that they would either be included on every single-view page or on none of them. It doesn't make a lot of sense for them to only be on eight. Here they are:

Makes no sense to me what the deal is on that. Anyway: on to what they actually contain.

Header of Wikipedia:Wikipedia Signpost/2017-02-27/Blog

<noinclude>{{Wikipedia:Wikipedia Signpost/Templates/RSS description|1=WikiIndaba 2017: A continent gathers to chart a path forward: A report from the second WikiIndaba conference, with summaries of several presentations.}}{{Wikipedia:Signpost/Template:Signpost-header|||}}</noinclude>
{{Wikipedia:Wikipedia Signpost/Templates/Signpost-article-header-v2|{{{1|WikiIndaba 2017: A continent gathers to chart a path forward}}}|By [[User:Bobbyshabangu|Bobby Shabangu]]| 24 February 2017}}
{{Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start-v2|fullwidth}}

Header of Wikipedia:Wikipedia Signpost/2019-02-28/Featured content

<noinclude>{{Wikipedia:Wikipedia Signpost/Templates/RSS description|1=Conquest, War, Famine, Death, and more!: Horsemen of the apocalypse all represented in recently promoted content, alongside new life, pretty birds, great music, and other miscellaneous topics.}}{{Wikipedia:Signpost/Template:Signpost-header|||}}</noinclude>
{{Wikipedia:Wikipedia Signpost/Templates/Signpost-article-header-v2|{{{1|Conquest, War, Famine, Death, and more!}}}|By [[User:Evad37|Evad37]]| 9 February 2019}}
{{Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start-v2|fullwidth}}
{{Signpost inline image|image=File:Leicester Arch of Remembrance (rear, 10).jpg|caption=We will remember them: [[Arch of Remembrance]] promoted to featured article}}
----
{{center|'''''This ''Signpost'' "Featured content" report covers material promoted from 27 January through 23 February. For nominations and nominators, see the featured contents' talk pages.'''''}}
----
{{Wikipedia:Wikipedia Signpost/Templates/Signpost-block-end-v2}}
{{Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start-v2|fullwidth}}

jp×g 🗯️ 01:41, 15 December 2023 (UTC)[reply]

Minor note on the |by thing...

All Signpost articles: 5,471
~~has "|By": 5,428 (i.e. 43 missing?)~~

~~Doesn't have "|By": 43 (i.e. I can subtract correctly :D)~~ Fixed (except for a couple poll results pages and some board candidate interviews from 2k09)

has "|By:": 0
~~has "|By " with two spaces: 16~~ None.

One thing that seems like it'd be kind of good would be modifying this param to have a name (i.e. "|By John Smith" -> "|by=John Smith". I suspect this might help to make the header template more robust, although maybe it doesn't matter (there don't seem to be any instances of it failing in this way). Seems unlikely to be worth doing on its own, although if for example every single article needed to have an edit done to it anyway, it would be worth throwing in there.

One thing that would be nice to do is get rid of the random date params in the header templates (which are currently {{{3}}}, most of the time, except when they're not). Again, worth doing if every article's getting edited anyway, otherwise pointless. jp×g 🗯️ 01:53, 15 December 2023 (UTC)[reply]

After some reflection and searching and sorting: of the 2464 articles with subheadings, there are 1084 articles that have RSS templates, and 1380 that don't (making 1380 the absolute minimum number of edits necessary to format them all to have subheadings). That's a majority... it seems like it might be worthwhile to just say whatevs and reparsulate them all. What kinds of stuff ought to be done? 1) put subheading params in header template, 2) parameterize the |by=, 3) remove the dates, 4) dick with whitespace. Template should support all permutations of this because even after I do that there's still 5462 articles total (i.e. 1,998 from before the subheading era that would need to also have whatever modifications made to have it be consistent). jp×g 🗯️ 02:34, 15 December 2023 (UTC)[reply]
This is stupid and gets in the way of doing useful work because "what if bats fly out my ass and I want to change all the template params". If that happens I can just spend a day running the bot over the pages to change the params to whatever. Who cares. For now there is actual stuff backed up on not having the RSS descs in the pages so that should be fixed first. jp×g 🗯️ 06:43, 21 December 2023 (UTC)[reply]

mwparserfromhell

I've integrated this into Wegweiser's metadata_fetcher script (and also coded support for subhead module data in Wegweiser, module:signpost and the tagging script). It seems pretty broadly capable; I think it gives me a lot more ability to modify pages with bot edits without having to rely on piles of regex or brittle string-manipulation tricks. It may be possible to do a large comprehensive cleanup on article headers (remove spurious linebreaks and spaces and nonprinting characters... remove unnecessary ghost params like writing date... get rid of random whitespace etc). Also, at the same time, to incorporate the subheads into the RSS feed template.

Update: It's good as hell baybee. jp×g 🗯️ 06:42, 21 December 2023 (UTC)[reply]

We'll do it live!

Too much thinking not enough doing. Wrote the script today and sent Wegweiser to go hogwild. Well, no: I wrote the script to log console output and only proceed on user input, took sample pages from between 2012 and 2017, and manually verified a couple hundred, then I sent it to go hogwild. I am updating the indices with the new subheads. Currently up to the end of 2014. There are some long ones; I am trimming down some of those. A lot of the ones real far back are just, like, the entire first paragraph of the article. Oh well. Anyway, I will probably run the rest tomorrow and get up to 2017, then everything will be cool and good forever the end. I think then it will be possible to rework the archive pages to just display using the article list maker and the snippet template -- no more hardcoded stuff necessary. jp×g 🗯️ 06:41, 21 December 2023 (UTC)[reply]

Piccy preview

How hard would it be to get the piccy param to show up at Wikipedia:Wikipedia Signpost/Next issue? ☆ Bri (talk) 18:44, 21 December 2023 (UTC)[reply]

@Bri: This seems almost impossible given my understanding of how said templates work, but I'll take a look and see what I can do. jp×g 🗯️ 23:17, 22 December 2023 (UTC)[reply]

It turns out I'm an idiot and it was really easy. Implemented. jp×g 🗯️ 23:23, 22 December 2023 (UTC)[reply]

Images overlap with each other... looks pretty bad here. Any way to give them a 0.5 em margin maybe? Headbomb {t · c · p · b} 06:25, 24 December 2023 (UTC)[reply]

Here's what it looks like to me at 50% zoom level (https://i.gyazo.com/87d8ea4dd33319654816f1626e105974.png) Headbomb {t · c · p · b} 12:48, 24 December 2023 (UTC)[reply]

My Wikipedia:Wikipedia Signpost looks like that today as well. It's pretty unpleasant. At a minimum, there needs to be some sort of {{clear}} after a row of image captions so that the following row of images is aligned. More troublesome, the image captions overlap each other left-to-right. – Jonesey95 (talk) 13:05, 24 December 2023 (UTC)[reply]

looking forward to the arrival of our lord and savior flexbox and em piccy widths (stuck on a phone flr the next few days orz) jp×g 🗯️ 10:28, 26 December 2023 (UTC)[reply]

Also can we allow color contrast, either by adding background color, or using brighter colors like yellow? The black colors for explaining the type of report is really hard to read and ironically what I'm most likely to search for when skimming e.g where is the technology report, ah crap it's hidden in low-contrast light-black on background-image ~ 🦝 Shushugah (he/him • talk) 01:56, 8 January 2024 (UTC)[reply]

"Update page" link at Next issue mockup is broken

Wikipedia:Wikipedia_Signpost/Next issue has two modalities to update the page. The blue button works, but the text link Update the table now does not. ☆ Bri (talk) 22:15, 6 February 2024 (UTC)[reply]

Yeah, that one is transcluded from the database report template. I came up with some goofy hack to make that part go away for the "number of issues" and "number of articles" templates, which could probably be used on that next issue subpage. jp×g 🗯️ 22:50, 7 February 2024 (UTC)[reply]

It might not be so bad if we weren't explicitly telling people to use the link: Click the link below to update it if something looks sus. ☆ Bri (talk) 23:29, 7 February 2024 (UTC)[reply]

I fixed the text on the page although actually removing that text from the DBR output I think requires much more intricate attention and can only be done by asking SD0 about it. jp×g 🗯️ 05:19, 11 February 2024 (UTC)[reply]

pingaling

I thought people were getting pinged when we mentioned them in draft articles. Apparently no: just linking people's userpages does not work for this. It only works under a very limited set of circumstances that are a pain in the ass to do. I have found that per https://www.mediawiki.org/wiki/Manual:Echo this DOES work, and can be done procedurally, like such:

Copy entire source code of page (this is Text A). Blank it.
Take a copy of Text A, and:
- Find-replace out all section headings (second-level and third level and etc).
- Add a dummy level-2 heading to the top, e.g. == asdf ==.
- Add ~~~~ to the end.
- This is now Text B.
Save the page with Text B. This will ping everyone whose username is linked in the page.
Revert to Text A. This will unbork the page.

This can be done very easily by script -- I am considering something of that nature (either a script or a bot that can be triggered). jp×g 🗯️ 09:19, 10 June 2024 (UTC)[reply]

Before you pile on yet more kludgy scripts and bot tasks:

Why not simply mention people in an edit summary instead? See Help:Notifications#Mentions_in_edit_summaries. (By the way, https://www.mediawiki.org/wiki/Manual:Echo is outdated, see the notice on top of that page, and its talk page. The relevant documentation has long been at mw:Notifications instead.)

Regards, HaeB (talk) 02:05, 12 June 2024 (UTC)[reply]

Solutions that consist of one person obliged to manually reformat a dozen user links in every column every issue to ping the mentioned users are less solutions and more of bird excreta dropped on their head from altitude. If somebody else is willing to do this, it is really not my business and I will leave them to it, but if it is just going to be my job I will automate it.

That said, edit summaries sound way easier than in-text pings (which have to be rv'd after the fact). I think the easiest thing here would just be to scrape userlinks out of the body text and put them into the edit summary, then this could be a context menu caction or something (stretch goal: it could even be documented somewhere 😭) jp×g 🗯️ 09:09, 12 June 2024 (UTC)[reply]

I mean... a reverse-stalker mentioning service that scans the article draft space and drops a notice on mentioned users' talk pages sounds like a textbook bot function. In fact, I've always wondered why there aren't already bots for that. It's a bit surprising (and grows increasingly moreso over time) that WP:ANI, for example, continues to maintain its "YOU [the incident reporter] MUST NOTIFY THE INVOLVED PARTIES ON THEIR TALK PAGES" policy, instead of just having a bot assigned to do it. (Other than, presumably, the belief that having that extra step imposed in the process of opening an incident will deter, or make it easily to summarily reject, a certain number of frivolous reports.) FeRDNYC (talk) 15:35, 22 September 2024 (UTC)[reply]

Lost Technology again

There was an android app in 2012? What????? jp×g 🗯️ 08:36, 2 August 2024 (UTC)[reply]

I think it was less lost technology in the sense of "there was a [Signpost] Android app", than it was "abandoned vaporware" technology in the sense of (based on the project GitHub history), "someone worked a bunch for literally 3 weeks (2012-08-20 – 2012-09-11) on the start of what was intended to be a Signpost Android app, then lost interest, wandered back to it briefly a couple of times in the first half of 2013, and never looked at it again."

The GitHub project was finally archived in 2021, after over 7 years with no commits. I don't think it ever actually released anything at all, the single release candidate was as far as it was taken. Said candidate somehow lost the election despite running unopposed.

That was a time period when lots of people thought having a native app to provide a custom mobile interface for every website out there was "cool", or "useful", or "made any sense at all". All those people were, and the few stragglers who still believe that are, wrong.

Even the native Wikipedia app represents only 2-3% of monthly pageviews on enwiki. Because nobody cares about dedicated mobile apps for web content. And nobody cares about them because there are no native content presentations you can achieve in a phone app, that you can't achieve just as well — but more flexibly and manageably — using good ol' HTML5, CSS3, and ES6+ when your site is viewed with a mobile browser. So the app provides nothing but a higher-effort, less immediate (and probably, less performant and worse-maintained) path to viewing the same content. FeRDNYC (talk) 14:57, 22 September 2024 (UTC)[reply]

The Signpost front page snippets, and dark mode

The current issue's front page contains a particular article link that, in the dark mode palette, appears like so. (I've mocked it up using the power of Special:ExpandTemplates and a bunch of manual HTML diddling, so that light-mode and dark-mode users see the same thing.)

Neolux – PD

News from the WMF

Meet the 12 candidates running in the WMF Board of Trustees election

Who are they, why are they running and what are they bringing to the Board?

That box is created by this template transclusion:

{{Signpost/snippet|{{Wikipedia:Wikipedia Signpost/Templates/Issue|1}}|News from the WMF|Meet the 12 candidates running in the WMF Board of Trustees election|Who are they, why are they running and what are they bringing to the Board?|0.4 MB|sub=0.4 MB|by=[[User:MPossoupe (WMF)|Mahuton Possoupe]]|piccyfilename=File:Wikimedia-logo_black.svg|piccy-credits=Neolux|piccy-license=PD|piccy-scaling=300|piccy-xoffset=|piccy-yoffset=}}

So, there are a few possible solutions to this. By my count, at least...

Add a {{{piccy-invert}}} or {{{piccy-invertable}}} parameter to the template, that when set to a truthy value will add the recommended |class=skin-invert to the [[File:...]] tag for the image.
Add a {{{piccy-background}}} parameter to the template which inserts style="background-color: {{{piccy-background}}}" into the <div>...</div> that's wrapped around the image, then add |piccy-background=white to the template args.
Always insert an explicit white background into the aforementioned <div>...</div> tag, by default, so that all transparent images will always be shown against white. (Won't affect any full-frame images, since they'll cover the entire background.) This way, explicitly "fixing" dark transparent images for dark mode won't be something anyone has to worry about doing. (It'll also fix any older dark-mode image issues automatically, since it'd be done in the template.)

Unfortunately, although at least in this case a complementary File:Wikimedia logo white.svg does exist, I don't know of a way yet to specify wholly separate images for use in light and dark modes. (Normally in HTML an <img srcset=...> tag would be used, mapping the multiple images to different prefers-color-scheme contexts.) FeRDNYC (talk) 02:20, 23 September 2024 (UTC)[reply]

Nomination for deletion of Template:S-s

Template:S-s has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page.

Note that this template was discussed above. A redirect was attempted, but a pipe and a line break appear to be needed before each entry, so a bot or AWB editor may need to get involved before a redirect can happen. Comments are welcome at the TFD. – Jonesey95 (talk) 23:30, 30 September 2024 (UTC)[reply]

Humor header

I've created a Signpost header in my user space at User:Svampesky/Signpost-article-header-humour by copying the header and changing the color of the column name. I've temporarily implemented it in the current humor column, and makes it stand out more as a humor disclosure, per the 2013 RfC on the WP:HUMOR page. I chose purple because of the warning symbol for humor used on Wikipedia. The only challenging part is picking the right shade of purple. Svampesky (talk) 14:47, 20 October 2024 (UTC)[reply]

Pinging @JPxG into this because this talk page is not closely monitored. My header seems to be disrupting other coding, and now the piece is no longer appearing on my author page. Svampesky (talk) 19:17, 29 October 2024 (UTC)[reply]

[1] I made it up.

[1]