Content deleted Content added
→Validation: reply |
→best practices for image information fields: new section |
||
| (36 intermediate revisions by 5 users not shown) | |||
Line 62:
:::::::*[[User:JPxG/sandbox99#All_arb_reports_since_2015,_sortable_by_7-day_views]]
:::::::There's no way to query pageviews in wikitext (because they have to be dynamically loaded from a different API); it has to be done by an external application. The only thing we have that can do this is the Vega graphing extension; it might theoretically be possible to use a grotesque hack like rendering a Vega embed for pageview data in some way that displayed a wikitext error message that embedded the pageview count in it... but even if that worked, it would require viewers' browsers to perform thousands of queries to the pageview API every time they tried to load a table like the ones above (for data that isn't really going to change ever, like "pageviews between January and February 2017"). '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 22:47, 11 January 2023 (UTC)
{{dedent|:::::::}}{{ping|JPxG}} I made a [https://github.com/jp-x-g/wegweiser/pull/1 pull request] to Wegweiser to use the same Lua table format as SignpostTagger. Does that look like an acceptable way of making the diffs cleaner in the index modules? <p>As for the question of why page view data is necessary, I understand that you want to display the page view data in wikitext, and that using the page view API for this directly would be impractical. The thing I'm not understanding is why you want to add page view data to wikitext in the first place. Are you planning to add a page view counter on article pages? Or are you planning to use the data in some other way? Best — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 05:02, 22 January 2023 (UTC)</p>
== Fleshing ==
Line 99 ⟶ 100:
::Could be a bug in parsing usernames or something else that runs on page load - if there is an error there, then the script wouldn't progress far enough to display the "Manage tags" link. There was a recent issue reported [[Special:PermaLink/1134401284#Signpost Tagger|here]] where this happened. If you see this again, check if there are any exceptions reported in the console. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 14:46, 18 January 2023 (UTC)
== Author and pageview in returnable form
{{ping|Mr. Stradivarius}} I have a working modification for the module, currently located at [[Module:Sandbox/JPxG]], which is capable of using the author/pageview metadata in list/table generation. I don't want to just slap it into the main module without any notice, so I am letting you know here. This version (which you can see the test cases for at the [[Module:Sandbox/JPxG/doc|doc page]]) allows for returning the author, as well as viewsSeven, viewsFifteen [...] up to viewsOneEighty. Below I'll embed a use case, which is a table of the view counts for yesterday's issue:
{{User:JPxG/sandboxbollocks}}
<nowiki>{{User talk:JPxG/sandbox99
| rowformat = {{Wikipedia:Wikipedia Signpost/Templates/Article list maker/Pageviews|date=${date}|subpage=${subpage}|title=${title}|viewsseven=${viewsSeven}}}
| sortdir = descending
| startdate = 2023-01-15
| enddate = 2023-12-01
}}</nowiki>
|}
Anyway, I don't see this conflicting with any other use of the module, and it hasn't broken in the period of me testing it, so I will add these changes to the main module, unless you have an objection or want to do it better (I don't think this is the best-written code, as I am not a "Lua guy"). '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 05:05, 17 January 2023 (UTC)
:{{ping|JPxG}} Thank you for implementing this. Personally, I would use digits to specify the page view durations: <code>views7</code> and <code>getViews7</code> instead of <code>viewsSeven</code> and <code>getViewsSeven</code>. I find it easier to tell at a glance what the number is when using digits. Also, once it gets over 100, things start to get less obvious. Should it be <code>getViewsOneTwenty</code>, <code>getViewsOneHundredTwenty</code> or <code>getViewsOneHundredAndTwenty</code>? Users of the module will probably have to look at the documentation to get it right. Otherwise, the code looks good to me. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 14:32, 18 January 2023 (UTC)
::{{ping|Mr. Stradivarius}} Yeah, that would be the sane thing to do. That was what I initially tried, and it triggered Lua errors every time. You can try it and see: if you go into the sandbox code and do nothing but change <code>viewsSeven</code> to <code>views7</code>, then edit the table maker to call <code>views7</code>... it will flip out. I don't know if this is an insurmountable issue with Lua, or a skill issue on my part (likely the latter). If there's any way to make it just be "views7", that wold be infinitely preferable lol. '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 23:29, 18 January 2023 (UTC)
:::{{ping|JPxG}} I edited the sandbox to make it work. The trick was to change the pattern that detected variables like <code>${title}</code> to accept both letters and numbers - previously it only accepted letters. Best — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 15:06, 19 January 2023 (UTC)
== whitespace ==
{{ping|Mr. Stradivarius}} I accepted your pull request, but running the program, the [https://en.wikipedia.org/w/index.php?title=Module:Signpost/index/2023&diff=prev&oldid=1135520547 whitespace] seems to still be quite different -- is this a bug, or am I running it incorrectly? '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 04:31, 25 January 2023 (UTC)
:{{ping|JPxG}} [[Special:Diff/1135520092|This]] looks like the output from the luadata package, not the lua_serializer module that I wrote. I tested that the output of the lua_serializer module looks like [https://github.com/jp-x-g/wegweiser/blob/bc77977e01319905611ed43865e880bfdd43facc/test/test_lua_serializer.py#L71 this]. Probably the most likely explanation is that you ran the bot from an old version of the code. Or perhaps the code you are using to update the Lua index modules does not use [https://github.com/jp-x-g/wegweiser/blob/bc77977e01319905611ed43865e880bfdd43facc/lua_wrangler.py#L52 lua_wrangler.luaify]? There may be another entry point that I have missed. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 05:36, 26 January 2023 (UTC)
::Yeah, it is kind of strange (I assume you tested it and it worked). I will have to take another look. '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 05:37, 26 January 2023 (UTC)
:::{{ping|JPxG}} Did you get a chance to look into this? I can also take a look if you're willing to let me have access to the bot's execution environment. (Are you running the bot from a shared environment like [[wikitech:Toolforge|Toolforge]], or just running it locally?) Best — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 06:28, 30 January 2023 (UTC)
::::{{ping|JPxG}} Actually, I think I found the cause: I missed an entry point in my pull request. It looks like Wegweiser is still using the luadata package for serialisation in [https://github.com/jp-x-g/wegweiser/blob/4a4c644cd5b0cf6d8dd38c72b2fb4a65cf35e423/mass_tagger.py#L130 mass_tagger.py]. I'll submit another pull request later on to fix this; the execution environment access won't be necessary. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 06:35, 30 January 2023 (UTC)
:::::Ok, pull request [https://github.com/jp-x-g/wegweiser/pull/2 submitted]. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 07:21, 30 January 2023 (UTC)
::::::{{ping|JPxG}} Looks like I still missed a few, so I [https://github.com/jp-x-g/wegweiser/pull/3 submitted another pull request]. These should be the last ones. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 00:51, 31 January 2023 (UTC)
{{outdent|::::::}} {{ping|JPxG}} I [https://en.wikipedia.org/w/index.php?title=Special%3AContributions&target=Mr.+Stradivarius&namespace=828&tagfilter=&start=2023-01-31&end=2023-01-31&limit=50 undid] WegweiserBot's edits to the index modules with my new serialisation code, due to [https://github.com/jp-x-g/wegweiser/pull/3#issuecomment-1410060723 this issue]. The fix was also pretty simple, so I've made a [https://github.com/jp-x-g/wegweiser/pull/4 new pull request]. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 13:49, 31 January 2023 (UTC)
:I had a look into [[WP:SPT]]'s handling of <code>\uxxxx</code> escapes as well. It turns out that Lua doesn't actually have that kind of escape, as it treats strings as a series of bytes, rather than a series of Unicode characters. So it's not really a bug in [[WP:SPT]], but rather a fundamental issue of how Lua was trying to parse those strings. In other words, my serialisation code in Wegweiser was outputting incorrect Lua strings, so that's the thing we need to fix. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 14:14, 31 January 2023 (UTC)
::I merged your PR request from this morning, and am running it on a few index pages. [https://en.wikipedia.org/w/index.php?title=Module:Signpost/index/2005&action=history It seems to work as intended] :) '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 23:06, 31 January 2023 (UTC)
:::Nice. 😎 Thanks for the merge! — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 01:30, 1 February 2023 (UTC)
== Multiple authors ==
{{ping|JPxG}} Regarding [[Special:Diff/1136023834|this edit]] - how about adding {{para|authortemplate}}, {{para|authorformat}} and {{para|authorseparator}} parameters to specify how to format each author in the output? That way you can do things like link each user's userpage, etc., instead of just listing the usernames separated by commas. Also, maybe we could do the same for tags with {{para|tagtemplate}}, {{para|tagformat}} and {{para|tagseparator}} parameters. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 04:03, 29 January 2023 (UTC)
== Authors: names or usernames? ==
{{ping|JPxG}} About [[Special:Diff/1139235436]]: it looks like [[User:WegweiserBot|WegweiserBot]] is using display names for author names, but [[WP:SPT]] is using usernames. This is going to cause the two scripts to keep overriding each other, so we should choose one approach. I would prefer to include only username, as that makes it easier to do things like make user links. I can see that there would be a case for listing display names instead, though. Or if we really want, we could include both, in tables like <syntaxhighlight inline lang="lua">{user = "Bluerasberry", display = "Lane Rasberry"}</syntaxhighlight>. What do you think would be best? — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 04:28, 14 February 2023 (UTC)
:{{ping|Mr. Stradivarius}} Sorry for not having responded to this for a million years (I thought I had at the time). I pondered this for a while; what I eventually came up with was for each writer to be credited under one canonical name, which in a great many cases was the person's real name -- or failing that, whatever name they want to be credited under. Just going by username would simplify the process of linking to their userpage, but it's sometimes the case that we run articles from people with different home wikis, or Heaven forfend, people who aren't Wikimedians at all -- so I think whatever scheme we use should account for this. The idea of having two fields for the author does put another idea in my head, which is to have some kind of structured data for authors.
:Most newspapers and magazines have bylines for authors, which appear under their articles, and on the CMS's author page (e.g. https://slate.com/author/mary-c-curtis shows Mary Curtis's articles, but also "Mary C. Curtis is a columnist at Roll Call and host of its Equal Time podcast" etc etc). It occurs to me that this would be nice to do for ''Signpost'' articles as well, which would allow for the freedom to link to whatever someone wanted (like say they wanted the link to go to their blog or personal website), as well as to give more detailed bylines than just a name.
:I don't know how complicated it would be to implement something like that in the module -- my guess is "very" -- so it is more of a pipe dream I'm plopping out here than a thing I think is likely to actually happen, but it is worth considering. Maybe. '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 08:19, 6 August 2023 (UTC)
::On that matter, I absolutely do not appreciate you/the bot having mass-changed all these bylines in old stories some months ago without consulting with the rest of the team first. There are various arguments against it, for example that it is ahistorical to retroactively change the byline of something that was published over a decade ago - it does make a difference whether a story was written under a pseudonym or a real name, for instance. But however one weighs the pros and cons here (also about which version of a contributor's name to standardize on), the main point is that it is not a technical decision but a content decision, one that can also greatly affects [[Search engine results page|SERPs]] for people's names btw.
::Regards, [[User:HaeB|HaeB]] ([[User talk:HaeB|talk]]) 20:59, 6 August 2023 (UTC)
:::Perhaps this was dumb. I did post about this to [[Wikipedia_talk:Wikipedia_Signpost/Technical#Byline_pages|Wikipedia talk:Wikipedia Signpost/Technical]] back in January; perhaps some more discussion would have been good. From the height of a few months, this seems like it would have been a better choice, but at the time, I was just trying to make author search function. What I discovered was that the lack of machine-readable Signpost archives was concealing a [[Special:Permalink/1136012646|bizarre shitpile]] of some 1,212 distinct author fields, about [[Wikipedia:Wikipedia Signpost/Statistics/Authors|300 of which]] were nonsense. For example, sorting alphabetically gives <code>[User:GerardM</code>, <code><nowiki>{{{2}}}</nowiki></code>, <code>§hep</code>, <code>\/</code>, <code>+sj +</code>, <code>2 May</code>, <code>3 July 2006</code>, <code>03 July 2006</code>, <code>3family6</code>, <code>3family6 1 April 2016 19:58 (UTC)</code>, <code>05 November 2007</code>, <code>10 other editors</code>, <code>11 other editors</code>, <code>12 August 2015</code>, <code>14 April</code>, <code>18 August</code>, <code>19 November 2012</code>, <code>22mikpau</code>, <code>24 April</code>, <code>24 Apri</code>, <code>26 April 2010</code>, <code>27 other editors,</code>, <code>28 other editors</code>, <code>32 other editors</code>, <code>38 editors</code>, <code>51 other editors</code>, <code>53 other editors</code>, <code>79 other editors</code>, <code>91 editors</code>, <code>106 editors on the French Wikipedia; translated for The Signpost by JohnNewton8</code>, <code>273 other editors</code>, <code>1233</code>, <code>2008</code>, <code>16912 Rhiannon 15 July 2015</code> (literally all of which are parsing errors except for three); your articles, specifically, were under <code>HaeB</code>, <code>Tilman Bayer</code>, <code>Tilman Bayer</code>, <code>Tilman Bayer 1 April 2016 19:58 (UTC)</code>, <code>Tilman Bayer 03:08 (UTC)</code> (two of those ''appearing'' to be identical strings, but one of them with a nonprinting character). I guess what I am trying to say here is that if you want me to de-alias your name changes, I can do that, but I think that given the volume of work being done it was not something I could realistically post about at [[WT:Signpost]] (I recall that around December/January you had been saying we should be stricter about posting stuff on the right talk pages, which is why it was at /Technical). '''[[User:JPxG|jp]]'''×'''[[User talk:JPxG|g]]''' 23:14, 6 August 2023 (UTC)
::::Appreciate your reply, but my point above was exactly that this is a major content decision (and one affecting authors - and interested readers! - who may not be interested in following the Signpost's technical side). In that repsect, /Technical was the wrong place for such discussions (at least without announcing them in more content-focused locations too, which I don't recall seeing at the time).
::::As for the specific content examples you're raising: Yes, I'm sure there were a lot of uncontroversial fixes among these mass changes, but also a lot of deliberate choices being altered. (I wasn't mainly thinking about my own bylines here, but apart from nonprinting characters etc., these were also not accidentally different.) Lastly, I would recommend to distinguish between building a more systematic, consistent way for handling bylines in future editions (great!) and retroactively changing reader-facing content in old issues. Regards, [[User:HaeB|HaeB]] ([[User talk:HaeB|talk]]) 00:02, 7 August 2023 (UTC)
== JSON for the indices ==
{{ping|Mr. Stradivarius}} Per [https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#mw.loadJsonData this], it's now possible to have Lua modules load JSON rather than Lua tables. I think this would be a lot better to work with (i.e. all utilities wouldn't have to constantly serialize and deserialize Lua tables using the idiosyncratic whitespace/indentation/etc format). Additionally, a page with the JSON content model would be constrained and sanitized by MediaWiki, rather than a Lua table which can just have wrong stuff in it etc. I would like to write some more utilities to work with these indices but the Lua tables are kind of an awkward sticking point. What would the procedure be for converting them? I would be able to write patches for the Signpost tagger and Wegweiser (and may be able to help with the Lua module itself). <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 23:52, 8 December 2023 (UTC)
:{{ping|JPxG}} I guess you could do that, but you would still have the issue of making sure the JSON is indented and sorted the same way across all tools that write to the data pages. Just switching to JSON doesn't guarantee that all JSON parsers format everything the exact same way. Also, you can't save syntactically incorrect Lua pages; Mediawiki won't allow it. So I don't think there is a real difference between Lua and JSON there. One pitfall is that you would have to change the content model to JSON when creating the data pages, which as far as I'm aware only admins can do. This would mean that WegweiserBot would have to become an admin bot, which would require another BRFA. Also, non-admin users would no longer be able to use SignpostTagger to tag pages for which the data page is not yet created; they would have to wait until either WegweiserBot or an admin user changes the content model. All in all, to me this sounds like a solution looking for a problem. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 08:47, 9 December 2023 (UTC)
::My thinking is mostly that converting the JSON to Lua tables adds another dependency for every program that puts things into or out of the indices; JSON is a pretty widely used standard and there's lots of utilities available for parsing it. It just seems like it's more straightforwardly compatible with what exists now, and more forward-compatible with whatever the future brings.
::As for the content models, I hadn't thought about that. It is true that [[WP:TEMPLATEEDITOR|TE]]s can change content models, but that's still not very great. Fortunately my RfA was successful so I'd be happy to manually pre-create and set content models for blank JSON indices up to, say, 2060 or so ;) <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 02:41, 10 December 2023 (UTC)
== New subheading and image fields ==
Lately it has occurred to me that the way old Signpost archives get generated is very ass-backwards. We ''have'' a giant database of every article, its title, its author, et cetera... we're just not using it. It does get used ''sometimes'', like in [[Wikipedia:Wikipedia_Signpost/Templates/Single_talk]]. But for the archive issues, we have hundreds of individual pages, like [[Wikipedia:Wikipedia Signpost/Single/2022-11-28]], that redundantly store article titles, subheadings, et cetera. The modifications I'm working on now (which I've incorporated into the snippet template and the publishing script) allow articles to be associated with custom images, so the archives will have that too, but then this creates a problem: modifying an image for an article requires me to edit the article, then update [[Wikipedia:Wikipedia Signpost]], then update [[Wikipedia:Wikipedia Signpost/2023-12-04]], and such.
Anyway: I'd like to, as much as possible, use the module for stuff instead of static wikitext pages. However, this will again require some more fields to be added. Right now, my thinking is:
* <code>subhed</code> (subheading, or blurb, or whatever) -- string, nowadays this is a sentence or so but in some old issues it's GIGANTIC (paragraph or more). Has various random crap in it (templates, quotation marks, etc).
* <code>piccy</code> -- string, image file for the article. These, ideally, would be a 1:1 aspect ratio, but might sometimes not be, which brings me to:
* <code>piccy-meta</code> -- coordinates for CSS crop of the image. I am not 100% on this. It might just be four CSS crop coordinates. But I am also contemplating other attributes, like filters (what if we want to desaturate an image, etc).
Like above, I am fine to incorporate these into the publishing script, Wegweiser, and the tagging script, but may need some assistance with the Lua part (and I don't know if this should be done before or after the lua table-json thing). {{ping|Mr. Stradivarius}} what do you think? <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 00:04, 9 December 2023 (UTC)
:{{ping|JPxG}} This sounds fine to me, although I would avoid abbreviating the fields: <code>subheading</code> and <code>image</code> should be fine. I would also make "image" a table, so you could do something like <syntaxhighlight lang="lua" inline>image = {filename = "Example.png", width = 100, height = 100}</syntaxhighlight>, where "width" and "height" (or whatever metadata you need) are optional. I'm not aware of any way to crop an image in Mediawiki using inline styles - I think we are limited to the options provided at [[mw:Help:Images/en]], but let me know if I'm missing something. Best — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 09:03, 9 December 2023 (UTC)
::{{ping|Mr. Stradivarius}} I was able to figure out what was going on in {{tl|CSS crop}} well enough to implement it (far slimmer) on the snippet template; specifics (and examples) at [[Wikipedia talk:Wikipedia Signpost/Newsroom#Template for article images]]. Here is what the template looks like with all its arguments;
<nowiki>{{Signpost/snippet|2023-12-04|Essay|I am going to die|And so are you.|0.3 MB|sub=0.3 MB|by=[[User:WhatamIdoing|WhatamIdoing]]|pic=File:Memento Mori 'To This Favour' by William Michael Harnett, c. 1879.JPG|credit-name=William Michael Harnett|credit-license=PD|pic-p=800|pic-x=350|pic-y=100}}</nowiki>
{{Signpost/snippet|2023-12-04|Essay|I am going to die|And so are you.|0.3 MB|sub=0.3 MB|by=[[User:WhatamIdoing|WhatamIdoing]]|pic=File:Memento Mori 'To This Favour' by William Michael Harnett, c. 1879.JPG|credit-name=William Michael Harnett|credit-license=PD|pic-p=800|pic-x=350|pic-y=100}}
:After actually working it out enough to build something that functioned, it turns out there are only three meta attributes needed to fully specify a scale and crop: <code>scale</code>, <code>x</code> and <code>y</code>. All are integers, although I think it might also be useful to permit values like <code>top</code>, <code>bottom</code>, <code>left</code>, <code>right</code> and <code>center</code> (these aren't handled by the template yet but they could be in the future). There are also two more params I didn't think of above, <code>author</code> and <code>license</code>, which are necessary for image attribution. <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 03:59, 11 December 2023 (UTC)
=== Subheadings ===
Need to be supported by various scripts in order to work properly.
*Accepts {{yeac}} processes {{yeac}} Wegweiser
*Accepts {{yeac}} processes {{yeac}} Signpost tagger
*Accepts {{yeac}} processes {{yeac}} Module
I have rewritten Wegweiser to fetch metadata from parsing article wikitext instead of HTML pages; this posed some slight difficulties with respect to user tags in author fields but is now good. It can now work a lot faster, and it also provides subheadline metadata. There's a line I have commented out right now in the script, but can enable to make it store subheading data when it parses metadata. When the subheading data is in the module indices, the module still works fine to retrieve articles etc (of course it can't do anything to ''parse'' or use the subheading yet, but it doesn't break anything). However, the Signpost tagger chokes trying to save tags for articles with subheading data and won't work on them, so I won't do all of the indices with it for now. <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 22:06, 15 December 2023 (UTC)
:Now done. <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 12:23, 23 December 2023 (UTC)
== best practices for image information fields ==
So right now I've integrated into Wegweiser and SignpostTagger the fields for piccy information, like this:
<pre> {
date = "2023-12-04",
subpage = "Essay",
title = "I am going to die",
authors = {"WhatamIdoing"},
tags = {"essay"},
views = {d007 = 1526, d015 = 1919, d030 = 2029, d060 = 2029, d090 = 2029, d120 = 2029, d180 = 2029},
piccycredits = "William Michael Harnett",
piccyfilename = "File:Memento Mori 'To This Favour' by William Michael Harnett, c. 1879.JPG",
piccylicense = "PD",
piccyscaling = "400",
piccyxoffset = "70",
piccyyoffset = "",
subhead = "And so are you.",
},
</pre>
496 chars. This seems, uh, stupid. It works but I have temporarily reverted. Since these six fields are all about the same thing, there's no good reason to have them occupy six whole fields -- they should probably just be a dict like the viewcounts are. Like such:
<pre> {
date = "2023-12-04",
subpage = "Essay",
title = "I am going to die",
authors = {"WhatamIdoing"},
tags = {"essay"},
views = {d007 = 1526, d015 = 1919, d030 = 2029, d060 = 2029, d090 = 2029, d120 = 2029, d180 = 2029},
piccy = {filename = "File:Memento Mori 'To This Favour' by William Michael Harnett, c. 1879.JPG", credits = "William Michael Harnett", license = "PD", scaling = "400", xoffset = "70", yoffset = ""}
subhead = "And so are you.",
},</pre>
467. But, upon thinking this thought, something rather devious popped into my mind: aren't these labels kind of long? It seems pretty insubstantial, but... there are a lot of articles. Six letters for each key, across {{Signpost/Number of articles}} (currently 5462) articles (plus 3 extra chars for the <code> = </code> necessitated by using a label at all) is {{#expr: {{Signpost/Number of articles}} * 9}} bytes (currently 49158). For reference, the size of all extant module indices is {{#expr: {{PAGESIZE:Module:Signpost/index/2005|R}} + {{PAGESIZE:Module:Signpost/index/2006|R}} + {{PAGESIZE:Module:Signpost/index/2007|R}} + {{PAGESIZE:Module:Signpost/index/2008|R}} + {{PAGESIZE:Module:Signpost/index/2009|R}} + {{PAGESIZE:Module:Signpost/index/2010|R}} + {{PAGESIZE:Module:Signpost/index/2011|R}} + {{PAGESIZE:Module:Signpost/index/2012|R}} + {{PAGESIZE:Module:Signpost/index/2013|R}} + {{PAGESIZE:Module:Signpost/index/2014|R}} + {{PAGESIZE:Module:Signpost/index/2015|R}} + {{PAGESIZE:Module:Signpost/index/2016|R}} + {{PAGESIZE:Module:Signpost/index/2017|R}} + {{PAGESIZE:Module:Signpost/index/2018|R}} + {{PAGESIZE:Module:Signpost/index/2019|R}} + {{PAGESIZE:Module:Signpost/index/2020|R}} + {{PAGESIZE:Module:Signpost/index/2021|R}} + {{PAGESIZE:Module:Signpost/index/2022|R}} + {{PAGESIZE:Module:Signpost/index/2023|R}} + {{PAGESIZE:Module:Signpost/index/2024|R}} + {{PAGESIZE:Module:Signpost/index/2025|R}}}} (currently 1406253). So that's, uh, {{#expr:4915800/1406253 round 3}}% of the total index size being taken up just by key names. These have to be parsed by, basically, everything, and it's not quite clear that repeating the field names all these thousands of times is more efficient than just having them as an array whose ordering is documented. Perhaps it would be better to do this? {{ping|Mr. Stradivarius}} <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 13:51, 23 December 2023 (UTC)
| |||