I have a selenium script for producing screenshots in multiple languages. Is this useful?

Oh right, that makes sense; and Selenium tests are run against a DB that persists between tests?

Are jobs only run for POST requests?

I've had a crack at the first warning, building a matching error div to the one that's made by showErrors(). This feels like a bit of a clunky way to do it... anyway, will comment further on the above patch.

In T190231#4421739, @Mooeypoo wrote:

I think by default, actions appear on top and bottom, so while that is considered OOUI dialog's "normal" behavior (to have buttons on footer/top, if the design is different here, then we shouldn't bother.
An ActionWidget would just be a [widget][button] set, like input/button or input/label, etc.

Maybe I'm doing it the wrong way, not sure. I just don't want to merge my travis-integration branch in order to test it. Any ideas?

This is now working.

All required packages are installed.

@Mooeypoo: should the close-template button be turned into an ActionWidget that's tied to the dialog? Or do actions only appear in the header and footer of a dialog?

I agree that not changing prefs, and returning a warning, is a good way to go.

Giving the user a confirmation popup when they try to remove a field with any data.
Giving the user a confirmation popup when they hit "Remove all fields" with data in any of the non-required fields.

Looks good!

In T195924#4417850, @MMiller_WMF wrote:

• I created three drafts, and gave them all different categories. I see them all with state = "All", but I'm not seeing them show up with the State filters that correspond to their categories.

That's okay, testwiki is one commit behind at the mo'; it'll be updated in about 7 hours (I think?).

Same thing in Chrome and Firefox, and no it doesn't matter where in the list the field is. The calendar popup is obscured behind the dialog:

@Mooeypoo your patch gives me this:

This is ready for review.

No, I'm afraid I can't find the specific OOUI changes... I think they were made as part of https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/GlobalPreferences/+/370152 and then undone in the same patch, before merging. It wasn't all that complicated, and I think quite a few things have change with core Preferences since then (i.e. with how it's done OOUI) so probably wouldn't be of massive help anyway.

Is there anything left to do for this?

Changing the top message sounds sensible. And I like your idea @cmadeo of keeping the 'optional fields' header and adding a message below it. It wouldn't be too hard to only show one panel, but I think keeping them both makes sense (people would already be used to seeing two and so would know more where to look to find the parameters, and there they'd see the notice).

So did we resolve how to treat the array-type preference values (i.e. email-blacklist and echo-notification-blacklist)? It sort of seems to make sense to match what core does (i.e. return as arrays, rather than newline-delimited strings), but I know that's more complexity and probably not going to be used anyway.

Yes, true.

This is still happening, e.g.: https://wikiapiary.com/w/index.php?title=Sails_of_Care&oldid=4657503

the API doesn't point out which were translated and which weren't, so I can't really tell the dialog interface "only align to content language if the string is not translated".

We could add an extra button to the toolbar that just opens the ws-google-ocr tool in a new tab, with the image URL pre-filled. That would probably be the quickest to implement. For the WikiEditor toolbar, it could go a level down, under 'proofreading tools'; for the old toolbar, it'd just be next to the existing button (with some sort of external-link icon?).

No it's a hacky PHP script that uses the API. I'll get it online soon. The raw data is:

The first iteration of this is ready for review. We'll probably want to change it later to be able to rebuilt tags for Draft pages that are already in the triage queue (when next a new tag is introduced, I mean). But for the current purposes, I think including just the missing Drafts is the way to go.

The distribution of description lengths on enwiki:

Thanks for working on it! :-)

I'd go so far as to suggest that editing be disabled until this is fixed.

There is an issue with the no-templatedata message:

Description issue: T198291

This is also coming up in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageTriage/+/440018/

This is done (as part of T192854).

I'm running PageTriage on PHP 7.2 and all is fine. Those are underscorejs template tags aren't they?

With no hover?

I agree, two lines does look better.

I've changed it to do the same window-sizing as TemplateData does (which is the window.height - 200, although for ours it's adding an extra bit to account for the footer; don't know if that's necessary). But as far as button sizes etc. I'm not seeing any difference.

This seems to be because of the caching. The 'unreviewed' stats at the bottom there are cached for 10 minutes (and nothing refreshes the cache when an item is updated, I guess by design?).

This is what long descriptions look like (I don't think very many templates have very long descriptions):

No worries, large (not larger) it is. I've fixed up a few other bits and pieces, and updated the commtech deployment.

I've set up the cronjob that calculates the scores, so something should at least happen now when people add contests (with index pages).

Do you have an idea of how many revisions were not imported? And whether there is any other missing data?