My conscious is a jukebox
I can confirm a log has been saved to /data/scratch/community-tech-tools/wsexport-errors.log, as Max says. I think that's it for this ticket?
Ping @Khamul1 to make sure you see this
Hello! As you can see, it is limiting results to one month after the start date, so 2002-03-05 — 2002-04-05. You can extend this to as far as one year. Admin Stats no longer supports ranges wider than a year, because those queries usually don't finish and they slow down XTools for everyone else (see T201850).
Tue, Apr 23
Did you review the T221403#5123935 solution? It is not a complete "invert", per se. Obviously there is no solution everyone will agree on. This one I think Alex is in favour of (him to confirm), and at the off-site in San Diego, @Prtksxna gave the okay as well.
I'm reasonably certain T221425#5129085 is our only feasible approach, and it will work in all cases. If we're okay with the way it looks (sounds like @alexhollender was endorsing it), then we should move forward with it. I don't think it's safe to try to override anything that comes from wikitext.
@Anomie I don't know if you can help with this? It is currently a blocker for me migrating my tools to use the actor storage.
Thanks for the CSS! Indeed I don't think T221425#5129052 will work in all cases. Infoboxes for instance are not uniform cross-wiki; French Wikipedia uses .infobox_v2 while English uses .infobox. We've also only fine-tuned the Vector skin. Users may have their own CSS overrides too, and they will get applied after ours.
Mon, Apr 22
Fri, Apr 19
I think the mobile apps have their own rendering engine, meaning layout and colours and such are fully within their control. Unfortunately on desktop, there is an infinite possibility of what colours the community may have chosen for their templates, etc. Attempting to override these individually will be a nightmare, and will never be foolproof. So basically I doubt we can borrow much from the mobile apps. We'll likely need to use CSS inversion techniques, but with that we can also tweak the contrast, hues, etc., and we can easily exclude imagery and other media. I don't think we can safely choose any exact colours, though :(
Thu, Apr 18
As we were saying on Slack, we don't need to build something into MediaWiki to test what this looks like. It's just CSS. You can try this tiny script, which uses the same approach:
I think this can be resolved. No work was needed to make this apply to events without participants. Example https://eventmetrics-dev.wmflabs.org/programs/76/events/370
I assume you meant only to remove Community Tech.
@Matthewrbowker Are you still working on this? It should be as adding the tag to semi_automated.yml. I think it's safe to assume other wikis will follow suit of using tags, so I'd put it in the global section.
Thanks for helping improve AutoEdits! I have deployed this configuration change. Example: https://xtools.wmflabs.org/autoedits-contributions/www.wikidata.org/Swpb/4/2019-04-16/2019-04-18?tool=RequestDeletion
I will admit this is not a straightforward task, especially with the new architectural design of Admin Stats. Basically everything revolves around logged actions (in the logging table). We'd have to add some special code to do an edit count on the MediaWiki namespace. I suspect this could be really slow, too.
Merged and deployed
Wed, Apr 17
The issue is that Simple English is not a real language. Intuition for some reason still has a label for it, but it is not being used because the simple language code is marked as deprecated and hence falls back to plain English. This apparently matches MediaWiki behaviour (based on the comment), and I agree with it. In this case of File:Chemnitz_Verkehr.svg, the author probably added Simple English back when we still treated it as a distinct language.
I had an additional, possibly unrelated issue: When I chose español as the target language, I get the popup "An error occurred when fetching the preview. Please continue translating, but if this error persists do report a bug (via the link in the footer below)." when I attempt to add translations. But indeed if I ignore it and attempt to download, I get the 500 error reported here.
Tue, Apr 16
With #288 (needs review) https://eventmetrics-dev.wmflabs.org/programs/150/events/364 no longer times out, finishing in about 4 minutes.
E.g. see Risker, Zzuuzz, and others at https://xtools.wmflabs.org/adminstats/en.wikipedia.org/2019-01-01/2019-01-05
So I totally forgot about this task, @Matthewrbowker ! I reworked Admin Stats recently, and managed to resolve this all the while.
To give an example, fetching pageviews for https://eventmetrics-dev.wmflabs.org/programs/76/events/370 takes around 2.5 minutes. With the async implementation it takes around 4.8 seconds.