Quick clarification (just to save implementation/confusion time in finding the code in the different parent widgets) :

This should be fixed by overriding doInputBackspace from TagMultiselectWidget in MenuTagMultiselectWidget

In T205734#4634253, @MusikAnimal wrote:

In T205734#4631091, @Niharika wrote:

Impose sane limits on the number of pages to process. This is the trickiest part.

I think for the sake of simplicity, for now, we can consider this number to be 50k?

The problem isn't deciding on a number, but actually imposing the limit. Currently we do category tracking as a subquery, and MariaDB apparently does not support LIMIT/OFFSET within subqueries. We'll need to construct a different query that somehow gives us the data we want without putting all the category members in memory. I'm not even certain adding a LIMIT would help, but I've not done any experimentation.

In T210682#4949493, @jmatazzoni wrote:

(If that is the issue, I'm sure we can find a way to handle such errors....E.g., by listing the page IDs that no longer connect to a title at the bottom of report or even just omitting them....)

In T212892#4944350, @TBolliger wrote:

I don't know enough about the 'map' parameter to consider any behaviors that are needed or any edge cases to say how difficult it is to implement.

For the validation of the specific tags, we need to look into allowing for validation in the original ooui widget. I created T215760: TagMultiselectWidget: Add validation method rule for arbitrary tags to look into this in OOUI.

This resolves "The 'Pages' input field should not suggest Special pages" and retains the "The error messages should continue to appear if the admin somehow manages to get these through"

Okay, so I think that it might be a good idea to slightly rename things, and potentially get a bit of consistency with the events.

3. Add deprecation note to release notes

Okay, so I had more time to actually delve into the way the code works, and I'm slightly amending my analysis. The problem with the gadgets isn't really how to filter through the itemMatcher, which only works if the entire set of items already exists -- the problem with the specific SearchWidget is the API call. We need to make it possible for those gadgets to adjust the query that's sent to the search API.

In reference to Joe's question --

In T215346#4929559, @Jdforrester-WMF wrote:

Well, users can do var searchInputWidget = OO.ui.infuse($('#searchText')); to get a handle on the OOUI widget. Is that not sufficient?

@MusikAnimal, I understand you want to delve into this one with teh data we already have -- I think that's a good idea, even to start flushing out any challenges we haven't yet seen with the current data.

This is great. @MusikAnimal question -- for old events, do we want to create a check that redoes this ? So, if we kept fetching PageIDs for events that ended up until now, we might have, in the DB, extra PageIDs that are redundant and unnecassary for that event. Do we want to add a small check that if / when people update older events, we make sure the info in the PageIDs only contains the pages that are in the range?

That looks good and straight forward to me, we can has out any further details if needed during estimation.

This is actually a really interesting idea, and could answer a lot of usability with automated stuff or quick loading of mediawiki when needed.

You're right, I think I connected the tasks wrong. Thanks for fixing it!

@MusikAnimal this is merged but is this in production? Was it deployed? If so, we can move the ticket to QA/Product.

In T213126#4881797, @aezell wrote:

These issues are certainly real but seem somewhat theoretical. In practice, I struggle to believe that these scenarios will happen on a regular basis.

This is an image that seems ripe for being translated in SVG Translate. It has one revision. It's possible this work is over-optimization.

@jmatazzoni is there a similar task to this ? I feel like I just wrote something about this...

In T213126#4880200, @Niharika wrote:

@Mooeypoo The same problem happens when while User 1 is translating the file on SVG Translate, User 2 comes along and updates the file version on Commons, adding a new translation. If we upload the new file after User 1 adds their translation, we will override the translations added by User 2.
Could we check for a new file version just before uploading our file and if there's one present, we fetch that and add our translations to it? There will be edge cases such as when the file on commons has been updated in a way that the labels have changed but we can handle that with an error message on our end.

In T213126#4867342, @Samwilson wrote:

@Mooeypoo you brought this up the other day; can you remember the bad-cache scenario we were talking about?

Followup:
If you look at Special:Search (open the "Advanced Search" drop down) in Edge, the help icons do show up, but the rules look to be exactly the same, which is really confusing -- why does it work there but not in TemplateWizard?

In T203564#4879718, @Volker_E wrote:

@Mooeypoo Quick insight on why second rule exists. That's a workaround for SVG issues, first one should load PNG, second one SVG only in browser that support this (except IE 9, which also get's fallback). It's a little bit a joke here, as the selector includes ::before which makes this rule ignored as invalid by everything aside IE 9 anyways). Have to dig deeper on what's going wrong here though.

Yeah I just verified on my Windows PC in Edge 17; the problem isn't visible on https://doc.wikimedia.org/oojs-ui/master/demos/ but is visible in MediaWiki while using the TemplateWizard dialog.

Does this appear in the OOUI demo page too? This sounds like an OOUI bug.

In T213136#4878876, @MusikAnimal wrote:

When the user leaves the tab during Fetch/Download ... leaving the tab with a Fetch/download in process will terminate the Fetch and Download request. I.e., a requested report will not begin automatically downloading when the user returns to the tab; the user will have to request the report again. Mooeypoo MusikAnimal, Is that right? Also, does it need to be a ticket, or will this already happen?

For downloads, you can leave the tab, you cannot close the tab. This is the way it works now in production.

Actually, I'm not sure, but isn't the "official" definition is different between wikis? It might be that we are defining something specific for Event Metric's purposes rather than going with the (inconsistent, if I remember right?) definition of the different wikis?

If you add it to the first, it'll get lost if you scroll?

Clarification (we can do either) -- Do you want the popup to only be shown once and then never again, or to be shown until the user purposefully clicks "ok/dismiss"?

I saw the WIP PR with Leaflet demo'ed on @Samwilson's computer. It's awesome, works amazingly well seemingly out of the box, and covers a bunch of those zoom/pinch/move features. We could probably share screenshots, but it basically looks like you'd expect; the image and the +/- buttons, enabling zoom and movement in desktop and mobile natively.

This was done during the hackathon, and then cleaned up a bit.

In T212307#4837952, @EvanProdromou wrote:

@kaldari I think the main thing we want to avoid is getting ourselves into a case where different clients expect different output for the same corner case. Since we store full revisions and not deltas, we typically ask for the different between two revisions. That's usually not a big deal, unless we're in the case we see here.

I'll talk to @Anomie today and see if we can make this case work. I'm also taking it as a task to document the correct [behaviour] on https://www.mediawiki.org/wiki/API:Compare.

Notes from the Engineering discussion:

The fact this is an error doesn't make much sense here, since this is a common behavior that is expected. You reach the "edge" of a result set (either the end or the beginning) not as an error, but as a state.

In T200365#4451359, @Halfak wrote:

IMO the good thing about "Judgment" is that explicitly human and inherently subjective. I can't find a good synonym for the word.

Yes, this is done. We're continuously adding some methods to the API, but we should create new tickets as they come.

For reference, PR is here: https://github.com/wikimedia/svgtranslate/pull/20

This is a future enhancement for sure, not really something we should deal with for the MVP.

In T203559#4723569, @Samwilson wrote:

It seems to work fine sharing the popup overlay that we're already injecting for the calendar etc. @Mooeypoo did you say there was a problem with doing that? The two sorts of popups can never be open at the same time, so I don't think things will overlap or anything.

@Samwilson I tried to merge the patch (looks good) but it fails: