Ideally, the information displayed on mobile should be the same as the information on desktop which we decided on in T212326: Overlapping blocks may display incorrect block notice.

In T212326#5257452, @Niharika wrote:

From the estimation meeting:

• Add the block IDs
• Show the expiry (last expiry from the blocks)
• Show the reason (if we can)

This will go out with the train. Trying to SWAT it failed on the test so let's try sending it on the train. To be tested on testwiki Tuesday afternoon (PST).

This extension is being replaced by UrlShortener. That's the one that should be used instead. ShortUrl is deprecated and being removed.

From the estimation meeting:

• Add the block IDs
• Make sure it looks fine on mobile
• Show the expiry (last expiry from the blocks)
• Show the reason (if we can)

@jrbs Can you confirm if the datepicker works as expected now?

In T207893#5255918, @WMDE-leszek wrote:

@Niharika would you mind reminding us what is the planned timeline of the deployment of partial blocks? Just so that we know how urgently the fix is needed (I do anticipate that ASAP is preferred, but given you've "only" raised the priority up to "Normal" we would also only prioritize it accordingly)

@dbarratt Let me know if you need any design help on this. I imagine we can just modify the landing page to be a big Login with OAuth screen for the sake of simplicity.

@MusikAnimal If I am reading this right, you are suggesting it is possible to store pageviews for all pages in the pages in the feed and to allow sorting based on that?
Another thing we need to think about is updating this data - however often we do that. We can discuss that on T207238: Special:NewPageFeed - add option to filter by pageviews though.

Raising the priority on this as it is a blocker for partial blocks deployment.

We discussed the investigation today in the engineering meeting and I was asked to share a guideline for what the product ought to do. The following is a very rough idea of what the user workflow should be and what the product should do ideally. The things I consider more important than others have a star next to them.

In T222932#5254668, @MaxSem wrote:

Let's open a new ticket.

I agree that's an edge case we can live with.

In T222932#5246592, @dom_walden wrote:

For regression purposes I retested some PDFs which have caused us problems in the past. Either they generated fine or they had the same load issue as https://phabricator.wikimedia.org/P8588 (e.g. this file). It might be worth investigating the latter issue as I don't believe I have seen it before.

This is a fairly straightforward issue that we should fix.

@HMonroy Based on the previous discussion, it seems like the task description is correct. When a page is nominated for deletion (only via AfD), it should get marked as Reviewed.
What I was talking about earlier seems to have already been accomplished by Leon's last patch on this ticket. https://gerrit.wikimedia.org/r/#/c/507721/

In T207893#5109784, @Lydia_Pintscher wrote:

@WMDE-leszek can we sit down together and get this ready for pickup?

In T221783#5242936, @dom_walden wrote:

In T221783#5242645, @dom_walden wrote:

I can no longer provoke the "An error occurred when fetching the preview..." popup when clicking download mid-translation, on either Firefox or Safari.

However, the same error does occur when, mid-translation, you do something that moves you away from the page. For example, clicking "Log in" or "pick another file".

@Niharika Would you like bugs raised on those? Perhaps those links could be disabled when the preview is being generated as well, the same way the Downloads link is.

@SBisson I didn't view them anywhere else, no. It doesn't show me any of my past (read) notifications on Wikidata either. This is what I see:

In T207439#5240906, @dom_walden wrote:

In T207439#5237606, @MusikAnimal wrote:

Note for QA: In this iteration, I only changed the textareas auto-resize to a max of 12 lines. No other logic beyond that; the auto-resizing does not stop if it exceeds the viewport.

I tested this on "Mark as review", "Add tags" and "Mark for deletion" in the Page Curation toolbar, on Firefox 60 and Safari 10.

I noticed that the text areas do not auto-resize when I copy and paste multiple lines of text into them. They remain their original size (even if I start to type more text) and I have to click and drag to make the text area bigger.

This occurs on Firefox, Chromium and IE11, but not Safari (which does auto-resize). Perhaps this is just a cross-browser difference we cannot control. I am not sure if it is a major problem.

In T225164#5238832, @SBisson wrote:

@Niharika what do you see on Special:Notifications? Do you have Show notifications from other wikis checked in your wikidata or global preferences?

Woo! Works for me! Thanks for fixing this! :)