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?

PR: https://github.com/wikimedia/svgtranslate/pull/109

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).

In T221425#5132561, @alexhollender wrote:

Aside from consistency issues do you see other drawbacks to adding some additional code that enhances certain elements for at least part of the audience?

In T221425#5132021, @jmatazzoni wrote:

Danny has directed us to do desktop only and Moriel agrees that doing mobile would be challenging. So let's please focus on desktop only and leave mobile web solutions out of this from here on. Thanks.

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.

In T221425#5125977, @jmatazzoni wrote:

Would it be feasible to just exempt templates from the color change (in addition to images, maps, graphs...)?

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 :(

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.

In T220954#5121851, @dom_walden wrote:

I don't think that file has any translations (SVG Translate prod does not see any). https://commons.wikimedia.beta.wmflabs.org/wiki/File:Chemnitz_Verkehr.svg, which I uploaded a Simple English translation from SVG Translate, has a dropdown with "en-simple".

@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!

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

In T171996#5121781, @DannyS712 wrote:

I don't think we need to limit the timespan.

In T171996#5121775, @DannyS712 wrote:

@MusikAnimal I don't think it would be that slow - see this Quarry query - it took 0.53 seconds to see that you have made 388 edits in the MediaWiki namespace (with "AND rev_user_text = MusikAnimal") and 4.84 seconds to get the edit count of all users to have edited in the MediaWiki namespace (1309 editors, including a lot of IPs)

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

In T220954#5121373, @Samwilson wrote:

What language do SVGs (that have 'simple' in a contentLanguage) render in on Simple Wikipedia? I think if they can be displayed correctly there, then they should be able to be translated.

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.

In T220522#5118836, @MusikAnimal wrote:

I had an additional, possibly unrelated issue: I chose español as the target language, and 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.

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.

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

E.g. https://xtools.wmflabs.org/adminstats/ur.wikipedia.org/2019-01-01/2019-04-01

So I totally forgot about this task, @Matthewrbowker ! I reworked Admin Stats recently, and managed to resolve this all the while.

In T193888#5112763, @Bencemac wrote:

@MusikAnimal; Thanks for your work! I forgot to mention Global sysops who can create similar logs as stewards. For example, see Billinghurst's activity at urwiki. Could you implement this user group as well?

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.