I have not seen this happen on staging so far this morning.

In T220954#5121410, @MusikAnimal wrote:

I don't know how to check :/ Is https://commons.wikimedia.org/wiki/File:Chemnitz_Verkehr.svg an example? SVG Translate sees "simple" as one of the source languages. I did notice there's no dropdown on the File page to change the language from English to Simple English, as you would see with other multilingual SVGs, e.g. https://commons.wikimedia.org/wiki/File:Scheme_ant_worker_anatomy-en.svg

I have not seen this error anymore on staging or production.

When entering or removing text, I find a 1-2 second delay before the state of "Upload to commons" is updated. This gives me a window in which I can upload a duplicate image, giving the same error as T216209#5107613.

When logged out, there is a link "Log in to enable uploading". This takes a user to /svgtranslate-test/login.

Checked the image in the description and a couple of others I have seen this problem with previously (here, here and here).

I was not able to reproduce this on staging or production, using the SVGs in the description.

I was not able to reproduce this on staging or production, using the svg in the description. I also compared the SVG downloaded from svgtranslate with the one from Commons. The <tspan> style attribute is being preserved correctly.

On staging, I did not notice any dramatic differences in rendering of text between svgtranslate and Commons, or anything that looked obviously wrong (like the image in the description).

Looking at the revision history of the reports in https://en.wikipedia.org/wiki/User:Community_Tech_bot, I see all the reports have been updated in the last 7 days. I guess that means the cron is working.

Acceptance criteria

• The Automatically block the last IP address used by this user, [...] checkbox behavior should be changed from hide/show to enable/disable
• The Hide this username checkbox behavior should be changed from hide/show to enable/disable

When I first visit the tool (or after refreshing the page), the "Upload to Commons" but is enabled. I can click it and I get:

500: Internal Server Error
The upload is an exact duplicate of the current version of [[:File:Osmotic pressure on blood cells 20190220211300.svg]].

I have not seen this error for the image from T219227#5097672, nor for any of the 40+ images I have tested as part of other work.

I have not seen this for any of the 40+ images I have tested so far as part of other work.

I notice in the SVG linked in the description that translations inside a <switch> span don't always have the same number of separate text spans (either inside <text> or <tspan> elements).

Waiting for T220463 to be resolved to test this. Currently, we time out long before the 24 hour limit that this change introduces.

On Staging, ordering is alphabetical with respect to the character code.

Bugs raised so far:

• T216831
• T219882
• T220533

This error has been reported in https://meta.wikimedia.org/wiki/Talk:Community_Tech/SVG_translation#500:_Internal_Server_Error. So, I uploaded the file that caused the error to beta commons and tried to load it in svgtranslate-test:
https://tools.wmflabs.org/svgtranslate-test/File:Anatomy_of_the_Human_Ear-pa.svg

latestcontrib will return the last entry for that user or IP in the revisions table.

I currently have two events processing data. With DevTools open, I see they are making GET requests to https://eventmetrics-dev.wmflabs.org/events/job-status/$jobid.

In T219835#5091682, @jmatazzoni wrote:

@dom_walden, what do you think? Is the limit someplace around 6500 pages? It still doesn't explain why this event doesn't show an error message when it times out, if that's what it's doing...

This event, which is en.wiki category "Living people" for 10 minutes, is still crunching after well over an hour.

In T219835#5091682, @jmatazzoni wrote:

In T219897#5091678, @jmatazzoni wrote:

...So, is that it? Are a lot of pages bad but a lot of users if fine?

I did a few tests and it's possible that that is the answer. I broke the "First quarter WPMED edits" event into smaller pieces: all the pieces have the same number of participants, but they took place over shorter durations, so involve fewer contributions—most specifically, fewer pages improved:

• First quarter WPMED edits, original, 3 months, 14,037 pages improved : DOESN'T PROCESS
• First quarter WPMED edits. 1 day only, 102 pages improved. PROCESSES INSTANTLY
• First quarter WPMED edits. 1 week only, 756 pages improved, PROCESSES QUICKLY
• First quarter WPMED edits, 1 month only, 4,810 pages improved, PROCESSES IN 5-10 MINS
• First quarter WPMED edits, 6 weeks only, 6,500 pages improved, PROCESSES IN ?? MINS
• First quarter WPMED edits, 2 months only, ?? pages improved, CRUNCHED FOR A LONG TIME THEN DID WHAT THE 3 MONTH VERSION DOES.
  
  @dom_walden, what do you think? Is the limit someplace around 6500 pages? It still doesn't explain why this event doesn't show an error message when it times out, if that's what it's doing...
  
  LATER COMMENT: See T219449#5091755. It doesn't appear to be as simple as number of pages. An event wit 5.7k pages improved succeeded in processing, while two with significatnly fewer pages did not.

In T219449#5091755, @jmatazzoni wrote:

AF 1
(Size of event: Pages created, 487, pages improved, 4k)
CRUNCHED FOR HOURS THEN FAILED

If wpCreateAccount is set in the url, then "Block account creation" will be checked/unchecked as appropriate and not change when toggling.

No failures on https://travis-ci.org/wikimedia/mediawiki/builds for the last 7 days.

The Files in use metric was tested as part of T219379. I saw no inaccuracies in the figures for the events I have checked so far.

For two commons events (one with categories and participants, the other with just categories) I compared the event summary reported "Uploaded files in use", "Uploaded files" and "Unique pages with uploaded files" to my own database queries.

Most of the testing of the accuracy of the figures has been done in the CSV report in T210775.

Ran the pages improved report for a number of different events across different wikis, including commons and wikidata, and for events with more than one wiki which were filtered by Categories, Participants and both Categories and Participants.

On Special:Block and Special:Block/$username, there is a link to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback.

Specification in description appears to be satisfied.

No longer reproducible on staging.

It is possible to view the HTML and CSV All Edits report for the event in the reproduction steps.

In T216831#5077452, @dmaza wrote:

I feel like that's still a bug. We shouldn't allow for non-existing namespaces to be saved. At the very least we shouldn't display an empty namespace in the BlockList.

A globally blocked IPs is prevented from resetting passwords (testing on local vm as don't have rights to block globally on beta).

• There seems to be a timing/debounce bug with the widget: if I type 'user' (all lowercase) fairly quickly then "User" is not highlighted (grey background). If I type slowly everything works as expected.

I have not been able to submit Special:Block with namespace=-1.

After partially blocking my admin, with autoblock set. Successfully undeleted a page via web.

T219737 is now fixed, so...

In T208965#4903469, @TBolliger wrote:

May be solved by T209097

• Large event, multiple wikis: The 50k limit is per wiki. What happens when an event combines multiple wikis and tries to track a large number of items on each?

In T209097#5035130, @dom_walden wrote:

The only thing outstanding is T209097#5015139, if @dbarratt would like me to raise it as a separate bug.

• Large event, one wiki: EM can theoretically track a per-wiki maximum of 50k pages, Commons files or wikidata items. But what is its real limit? Create an event with a number approaching that limit on 1 wiki. This should be fairly easy to do by combining certain large categories. The Wiki Loves Monuments categories, for example, are conveniently grouped by year. One might also do this by combining some of our most into an event (there's a report of Top Editors on Wikistats 2.0).
  • Can the event successfully process or does it time out?

In T210775#5069767, @dom_walden wrote:

@MaxSem I think the xtools links should not convert "/" to "%2F" (in the title of a page).

I have not seen the original bug on https://en.wikipedia.beta.wmflabs.org, but I have come across another issue (T219737) preventing from successfully submitting blocks.

In T205734#5065436, @dom_walden wrote:

@MusikAnimal When attempting to include the en.wikivoyage category "Chicagoland" in an event, after I click "Save categories" I get the error:

In T205734#5065436, @dom_walden wrote:

@MusikAnimal When attempting to include the en.wikivoyage category "Chicagoland" in an event, after I click "Save categories" I get the error:

500: Internal Server Error
The server said: An exception occurred while executing 'INSERT INTO event_category (ec_title, ec_category_id, ec_domain, ec_event_id) VALUES (?, ?, ?, ?)' with params ["Chicagoland", 61612, "en.wikivoyage", 374]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '374-61612-en.wikivoyage' for key 'ec_event_domains'

I have not found this with any other categories so far.

I also notice that wikidata is not included in "Per-wiki metrics" table. Should it be?

Users must supply a minimum of at least one category for each wiki about which they want results. If they don't, they'll get no results for the unfiltered wiki (and will probably see an error message, as per T216280).

Event with commons, en.wiki, en.wikivoyage, en.wiktionary, wikidata.

@MaxSem I think the xtools links should not convert "/" to "%2F" (in the title of a page).

In T210898#5068366, @jmatazzoni wrote:

@MaxSem, @dom_walden you did what do you think?

@MusikAnimal When attempting to include the en.wikivoyage category "Chicagoland" in an event, after I click "Save categories" I get the error:

500: Internal Server Error
The server said: An exception occurred while executing 'INSERT INTO event_category (ec_title, ec_category_id, ec_domain, ec_event_id) VALUES (?, ?, ?, ?)' with params ["Chicagoland", 61612, "en.wikivoyage", 374]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '374-61612-en.wikivoyage' for key 'ec_event_domains'

I have not found this with any other categories so far.

Tested various functions offered by UploadWizard with different block configs.

As described in the commit, when editing a preexisting block or if posting of the Special:Block form failed (i.e. validation issues), the account creation checkbox will not change when switching from sitewide to partial (or vice versa).

Worth checking also that a partially blocked user can use the "Advertise" feature, which they are also currently prevented from doing.

In T217278#5034495, @Niharika wrote:

The blocker is resolved now and from my testing it works on beta commons.
@SPoore You can go ahead and test this on the following beta sites:

• Beta commons
• English beta Wiktionary
• English beta Wikisource
• English beta Wikibooks
  
  Once we're confident enough with those, we can begin a rollout for other projects.
  
  We do have a fair number of beta sites in other languages too so we can also use them for testing after this first round.

@Tchanders It appears to block partially blocked users at the stage just after they have selected the image.

In T208510#4987903, @dom_walden wrote:

Waiting for T216845 to be fixed. I would like to see is how it handles editing a block which has already set "Account creation" to a "non-default" value (i.e. a sitewide block with "Account creation" unchecked or a partial block with it checked). Is the "Account creation" checkbox considered already "interacted with"?

Pushing this on as I have done more testing elsewhere (e.g. T217704).

In T217704#5034011, @MusikAnimal wrote:

The API response does not have entries for dates prior to Feb 27 within the 31-day window, so Event Metrics assumes the item was created on the 27th. We're talking about an average here, so I think this particular scenario is fine -- even if it happens a lot. Regardless, we're running out of time for this project so we might turn a blind eye to trivial differences in pageviews, specifically, unless you suspect there is a larger issue that might be more noticeable and widespread.

Tested in this bug:

I am seeing occasional discrepancies for pages with very sparse pageviews.

@MusikAnimal I think you also need to escape double quotes.

On beta, non-privileged users don't see the "Your password is not valid" dialog. Privileged users do.

@TBolliger Special:MassMessage does not seem to respect blocks (partial or sitewide). For example, if you are blocked from someone's user_talk page you can still send a message to it.

@MusikAnimal Could you check my workings of the figures for https://eventmetrics-dev.wmflabs.org/programs/76/events/259/pages-created?format=wikitext

@MusikAnimal Attempting to run Pages Created report for https://eventmetrics-dev.wmflabs.org/programs/101/events/205 and https://eventmetrics-dev.wmflabs.org/programs/56/events/110 I get:

Considering this is quite a small change, I am not doing any testing especially for this task.