Re "always update both": Why do we even need two completely separate sets of deadlines (draft/non-draft)?
Also, while we are at it, why does it require us to specify the date of the previous issue? (twice, and separately from Wikipedia:Wikipedia Signpost/Templates/Issue which already contains that date)
This template quite complicated and confusing, not to speak of bugs. (The other day I spent some time trying to find out why its external link to worldtimeserver.com was always pointing to the wrong time, and ended up removing it until someone can fix it.) It also lacks any documentation. So we should embrace opportunities to simplify it.
Regards, HaeB (talk) 02:53, 2 August 2022 (UTC)
((#time: Y: ((Wikipedia:Wikipedia Signpost/Templates/Issue|1))))((#time: m: ((Wikipedia:Wikipedia Signpost/Templates/Issue|1))))((#time: d: ((Wikipedia:Wikipedia Signpost/Templates/Issue|1))))So, I have a version of this template in the sandbox that requires only one set of date/time parameters, and eliminates the "always update both" issue mentioned above. My sandbox version passes all of the testcases.
Here's how it works (and I suppose this also constitutes a caveat): A single ((Signpost/Deadline/core)) transclusion is created, with all of its parameters set, and that transclusion is used as the unnamed argument to another template. (I've already created that as ((Signpost/Deadline/draftwrap)).) The wrapper is also passed the value of (({draft))}, and uses it to decide whether or not to wrap a ((notice)) box around the ((Signpost/Deadline/core)) transclusion passed to it.
If (({draft))} is set to something (anything), it just outputs (({1))} directly. But with no (({draft))} value, it instead forwards (({1))} to a ((notice|1= transclusion. It therefore does add an extra transclusion to every use of (({1))}))((Signpost/Deadline)). Actually, two extra transclusions, since I use ((ifnotempty)) to evaluate (({draft))}.
Personally I think it's more than worth the extra transclusions, if it will let us avoid the double-parameter "always update both" tedium. But I'll let the community decide if you agree. FeRDNYC (talk) 14:49, 6 November 2022 (UTC)
((Signpost/Deadline)) with the source of ((Signpost/Deadline/sandbox)). Both achieve the same output in all testcases, but I know which one I'd rather have to keep updating. (However, also note the caveat about increased transclusion count, above.) FeRDNYC (talk) 14:59, 6 November 2022 (UTC)Good enough for me! Sandbox code applied to live ((Signpost/Deadline)). Let me know if you spot any issues with transclusions of the new code. FeRDNYC (talk) 17:35, 6 November 2022 (UTC)
My basic assumption is that all Signpost templates are a total mess because they weren't designed so much as they were accumulated over the course of seventeen years whenever somebody wanted a new feature. Accordingly, we end up with stuff like this. I haven't familiarized myself with the whole ecosystem of how the hell this specific template interacts with everything else, but if you have, then please go HAM with this because the new source code looks far better than the old. jp×g 21:47, 6 November 2022 (UTC)
((Signpost/Deadline/core)) works, in the collapsed details block at the end of the proposal immediately below here. Serendipity! FeRDNYC (talk) 23:04, 6 November 2022 (UTC)
Things that may seem useless now may come in handy in the future. That kind of logic can become dangerous, but for now I followed this advice and marked the template as deprecated.
Another question unrelated to the previous code change, for anyone who has to update this template and has an opinion. Currently, the interior transclusion (the one that has to be updated) looks like this:
((Signpost/Deadline/core|draft=(({draft|))}|short=(({short|))}
<!-- Previous issue--> |previous-year=2022 |previous-month=10 |previous-day=30
<!-- Next issue --> |next-year =2022 |next-month =11 |next-day =27
<!-- Deadline time --> |next-hour=23 |next-minute=00 ))
I realized that, with some fairly simple code changes to ((Signpost/Deadline/core)), I can make it cleanly support full-date parameters instead, so that the transclusion would instead look like this:
((Signpost/Deadline/core|draft=(({draft|))}|short=(({short|))}
|previous-issue=2022-10-30
| next-issue=2022-11-27
<!-- Deadline time --> |next-hour=23 |next-minute=00 ))
(I might even be able to do something with the time, so that it can be simply |deadline-time=23:00. I have to look into that a bit more, so no promises.)
To me, the second option seems infinitely preferable, it's not even a contest which one I'd rather have to use. Even if the format were so fragile that it would break unless I typed exactly YYYY-MM-DD, I would rather always make sure to do that, than have to deal with the separate arguments.[a]
But ultimately, I'm not the one who has to maintain the template arguments, so my preferences are completely irrelevant. So, for those who do have to maintain the template arguments: Would supporting single-parameter date arguments, instead of the separated components, improve things for you? Or, do you think-it's-fine/actually-prefer the way things currently work?
Notes
|next-issue=2022-4-1 should be handled just fine. (In fact it would probably work even if you passed it |next-issue=1 April 2023, though I would still encourage not doing that all the same.)
Expand for detail on how I'd propose to achieve this
(I should give fair warning to the curious: This is rather long, and a bit stream-of-consciousness. Ideas for further improvements were occurring to me even as I was in the middle of explaining a previous idea I'd just decided to abandon.)
Currently, ((Signpost/Deadline/core)) uses its separated arguments to builds some transclusions of both Bri's ((User:Bri/DateCountdown)) and ((countdown)), transforming the input arguments in different ways to construct the parameters for those transclusions.
A good chunk of those transformations are date math powered by the ((#time:)) parser function, and it was reading that code that made me realize that there's really no point to requiring all those separated args. The ((#time:)) calls all end up reconstructing the ISO-8601 (YYYY-MM-DD) style date strings in order to use them as arguments to #time.
((#time: Y|(({previous-year))}-(({previous-month))}-(({previous-day))} - 1 day))|((#time: n|(({previous-year))}-(({previous-month))}-(({previous-day))} - 1 day))|((#time: j|(({previous-year))}-(({previous-month))}-(({previous-day))} - 1 day))
Those parser function calls all do calendar math to find the date value of the previous issue date in YYYY-MM-DD form, minus 1 day. There's three of them, because it separately extracts the year, month, and day values as arguments to Bri's template.
But if the code is going to reconstruct aYYYY-MM-DD-format date anyway, why not just provide it in that form to start with? That code can become simply this, with equivalent results:((#time: Y|(({previous-issue))} - 1 day))|((#time: n|(({previous-issue))} - 1 day))|((#time: j|(({previous-issue))} - 1 day))
#time can be used to extract components from a date string. So, the parts of the current code that look like this: ((countdown |year = (({next-year))} |month = (({next-month))} |day = (({next-day))} |... ))
((countdown |year = ((#time: Y|(({next-issue))})) |month = ((#time: n|(({next-issue))})) |day = ((#time: j|(({next-issue))})) |... ))
Exact same results, but with a single |next-issue=YYYY-MM-DD parameter as input.
Now, there are a lot of places where parameters like (({next-year))} and etc. are passed directly, which means converting them would create a lot more invocations of #time. Quite possibly, too many for the server to handle without going over the complexity limits for the parser and erroring out during processing.
But I have a solution for that, too. If necessary for complexity reasons, or simply because we agree it's safer this way regardless, I can insert a wrapper template around the ((Signpost/Deadline/core)) transclusion the same way I did with ((Signpost/Deadline/draftwrap)).
A theoretical ((Signpost/Deadline/datewrap)) would replace the ((Signpost/Deadline/core)) transclusion, accepting single-argument YYYY-MM-DD dates and pre-exploding them once in the process of building the actual ((Signpost/Deadline/core)) transclusion.
With this approach, the code changes inside ((Signpost/Deadline/core)) would actually be much smaller, although it would make sense to pass in both the exploded and unexploded date parameters as separate arguments and still use the combined version where appropriate.
((Signpost/Deadline)) would look largely the same as my proposed new-code example, except that would be calling ((Signpost/Deadline/datewrap)) instead. That template would simply be this: ((Signpost/Deadline/core
|previous-issue=(({previous-issue|))}
|previous-year=((#time: Y|(({previous-issue|))}))
|previous-month=((#time: n|(({previous-issue|))}))
|previous-day=((#time: j|(({previous-issue|))}))
|next-issue=(({next-issue|))}
|next-year=((#time: Y|(({next-issue|))}))
|next-month=((#time: n|(({next-issue|))}))
|next-day=((#time: j|(({next-issue|))}))
|other|args))
That way, the separation of (({previous-issue))} into (({previous-year))}, (({previous-month))}, and (({previous-day))} only happens one time, and the extracted values are used multiple times inside ((Signpost/Deadline/core)).
#time calls to subtract one day and split out the components, I could move that code into the wrapper as well, and make the /core code cleaner by using the pre-separated values. IOW, the wrapper code becomes: ((Signpost/Deadline/core
|writing-previous-year=((#time: Y|(({previous-issue|))} - 1 day))
|writing-previous-month=((#time: n|(({previous-issue|))} - 1 day))
|writing-previous-day=((#time: j|(({previous-issue|))} - 1 day))
|previous-year=((#time: Y|(({previous-issue|))}))
|previous-month=((#time: n|(({previous-issue|))}))
|previous-day=((#time: j|(({previous-issue|))}))
|writing-next-year=((#time: Y|(({next-issue|))} - 1 day))
|writing-next-month=((#time: n|(({next-issue|))} - 1 day))
|writing-next-day=((#time: j|(({next-issue|))} - 1 day))
|next-year=((#time: Y|(({next-issue|))}))
|next-month=((#time: n|(({next-issue|))}))
|next-day=((#time: j|(({next-issue|))}))
|other|args))
The "writing-*" parameters would then eliminate all of the #time invocations in ((Signpost/Deadline/core)), replacing them with simple drop-ins of (({writing-previous-year|))} and etc.
FeRDNYC (talk) 22:59, 6 November 2022 (UTC)
OK, I now have a version of the template in Template:Signpost/Deadline/sandbox that uses my newly-added Template:Signpost/Deadline/dateswrap subpage wrapper around Template:Signpost/Deadline/core instead of calling it directly.
Whereas /core has a rigid set of fiddly parameters, /dateswrap requires only two. Technically they can be in any format parseable by the #time parser function, but the recommended formats are:
|previous-issue=YYYY-MM-DD|next-issue=YYYY-MM-DD HH:NN UTCI folded the former |next-hour=} and |next-minute= parameters into |next-issue= along with the date pieces, so the full time and date of the release deadline is defined by a single template parameter. (|previous-issue= also accepts time values, but they'll be silently ignored.)
Again, the sandbox version passes all testcases. Looking at the NewPP limit report embedded on both pages, the additional call to /dateswrapper has a shockingly small effect on the transclusion stats. The sandbox version does run slower, as expected given all the additional work it does, but we're talking page generation times of 163ms (new) vs. 151ms (old). That's a difference of under 10%, barely discernible from the server's normal background fluctuations. Even the fact that /dateswrap adds 16(!) calls to the #time: parser function (used to process the input parameters and extract individual date/time components) has an apparently-negligible impact, which is a surprise (to me, at least).
This is without even making any changes to /core yet, so a lot of the work done in /dateswrap is currently both ignored by, and then repeated in, the /core template itself. Once these changes are live and I've stripped /core of all the work that can now be offloaded into /dateswrap, it'll probably result in a net performance gain. (Not that the current templates' performance requires any improvement, or is even remotely a concern.)
I'll let it sit for a bit so people have a chance to check it out and kick the tires. If nobody has any concerns, once it's live I can update the docs and start streamlining /core to use the additional parameter values passed to it by /dateswrap instead of generating them all itself. FeRDNYC (talk) 09:52, 9 November 2022 (UTC)
WhereasSlightly inaccurate, technically. There are three additional parameters which can be used in/corehas a rigid set of fiddly parameters,/dateswraprequires only two.
((Signpost/Deadline)) transclusions: |short=, |draft=, and |refresh=. Those also get passed to /dateswrap, which in turn passes them along unmodified to /core. FeRDNYC (talk) 09:59, 9 November 2022 (UTC)
|next-issue= : while it will accept a timezone identifier along with the date and time values, until the /core subtemplate is updated it'll ignore that and continue to hardcode UTC like it always has. (Once it's updated to use the new parameters /dateswrap generates for it, defining the deadline in terms of some other timezone's clock will be possible, although UTC will always be the default, the fallback, and the recommended timezone for specifying time values. FeRDNYC (talk) 17:10, 10 November 2022 (UTC)
previous-issue date, since that information is already contained in Wikipedia:Wikipedia Signpost/Templates/Issue and can be obtained from there (see discussed above). If we want to get fancy, we could then even use it to have the template detect when the next-issue time has become obsolete after publication, and display a "to be determined" message or such. Regards, HaeB (talk) 06:24, 11 November 2022 (UTC)
|next-issue= management. Right now, the official statement is that Template:Signpost/Deadline is the canonical single source of what the deadlines actually are (i.e. editing this template changes the deadlines).But I think it might be worth rethinking that, and taking a page from how software release information is managed @ MediaWiki.
|previous-issue=((Wikipedia:Wikipedia Signpost/Templates/Issue|3)) instead, and never have to update it by hand ever again.|1=1, |1=2, |1=3 arguments... I suppose there might've been some justification for that when a bot was handling publishing duties (though I doubt it), but that bot's been gone for 7 years and as an interface for humans, it's the absolute pits.((Wikipedia:Wikipedia Signpost/Templates/Issue|3)) and doesn't suck as hard. And while we're mucking about, why don't we also move the next-issue information out of the Deadline template and into a central location where all publication data is managed, so that NO part of the Deadline template ever needs manual updating, because its parameters are set by two calls to other templates?((mw:MW stable release number)), ((mw:MW stable release date)), ((mw:MW stable release link)), etc.((#invoke:)) calls to mw:Module:Version, and they produce rigidly-formatted data because they're used everywhere across the MediaWiki download pages, version history, documentation, and etc. so that version information on project pages is always current.((Signpost next issue deadline)), ((Signpost current issue volume)), ((Signpost current issue number)), ((Signpost current issue volume-number)), ((Signpost current issue date)), etc. (And maybe ((Signpost next issue volume)) and etc., if we found a need for them.)((Signpost next issue deadline year)), ((Signpost next issue deadline month)), etc. — or made the deadline template accept optional args like ((Signpost next issue deadline|month)) to extract them — those could be used directly inside ((Signpost/Deadline/core)), I could drop ((Signpost/Deadline/dateswrap)) completely (its only purpose is to extract those values), and ((Signpost/Deadline)) wouldn't even need to have any date parameters in it. FeRDNYC (talk) 13:05, 12 November 2022 (UTC)((Signpost/Deadline)) which uses ((Signpost/Deadline/dateswrap)) is now live, and ((Signpost/Deadline/core)) has been updated to make use of the new variables created by /dateswrap, it no longer contains any ((#time:)) parser function calls./dateswrap is an overall improvement in efficiency. Probably because it avoids reassembling date strings from parameters just to explode them out again.|writing-next-year=((#time: Y|(({next-issue|))} - 1 day))
|writing-next-month=((#time: n|(({next-issue|))} - 1 day))
|writing-next-day=((#time: j|(({next-issue|))} - 1 day))
|writing-previous-year=((#time: Y|(({previous-issue|))} - 1 day))
|writing-previous-month=((#time: n|(({previous-issue|))} - 1 day))
|writing-previous-day=((#time: j|(({previous-issue|))} - 1 day))
<!--Previous issue date using #time to reformat it:-->
((#time: Y|(({previous-year))}-(({previous-month))}-(({previous-day))} - 1 day))
|((#time: n|(({previous-year))}-(({previous-month))}-(({previous-day))} - 1 day))
|((#time: j|(({previous-year))}-(({previous-month))}-(({previous-day))} - 1 day))
|<!--Current deadline:-->
((#time: Y|(({next-year))}-(({next-month))}-(({next-day))} - 1 day))
|((#time: n|(({next-year))}-(({next-month))}-(({next-day))} - 1 day))
|((#time: j|(({next-year))}-(({next-month))}-(({next-day))} - 1 day))
Right now, the time, UTC, is a little past midnight (00:33 on 16 October). The time param in this template is set to be 01:00, on 16 October. So -- as expected -- the thing says "27 minutes to publication". Yet when I open any of the templates in an incognito window, it bizarrely says there are 13 hours and 27 minutes left until publication. Whuh? I'm in California, so it's currently 17:35, which means that 01:00 on 16 October in my time is not 13 hours away. I've purged the caches et cetera so I don't think this is the issue. What the heck is going on? jp×g 00:35, 16 October 2023 (UTC)
@JPxG: What was the rationale for adding a time of day to the previous-issue parameter in Special:Diff/1183371029? Don't we only need the date of its publication (rather than the exact time)? Regards, HaeB (talk) 14:39, 22 December 2023 (UTC)