Does this seem okay?

PR: https://github.com/wikimedia/wikimedia-ocr/pull/152

Oh yep, sorry! I totally forgot that there's an extra step here: the changes to Codex-PHP have to be released and updated in MediaWiki core. So there's nowhere to tests. Sorry to waste your time!

(oh oops, should've reloaded this task before replying!)

They're the values of $wgThumbnailSteps, which are documented at https://www.mediawiki.org/wiki/Common_thumbnail_sizes

I've been experimenting with making the popover full width as it is in the designs, and it's not simple to make it reliable.

It looks like there's a plan to improve popovers on mobile: T386144: Popover: create mobile-version in Codex

I'm not sure I understand, why would it be better to set labels via action=setnotificationtimestamp rather than action=watch? But if you think it's a good idea, then feel free to open a task for it! (We should keep this one about the deployment.)

I wondered about that, but I think it might not be great because if you accidentally click somewhere before reading it, it'll disappear forever and you might be left confused about what it was.

Please see https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines for how to format the commit message so that the patch is linked to this task.

The mobile design for this is:

Oops, yes good point! Thanks for creating the patch.

The username is also a link (to the user page), but only for new page creations (where there's no diff link).

FYI. I'm not seeing the colon. It actually looks fine in mobile to me?

"View watchlist" suggests I would see items on my watchlist. This is what is done on Edit Watchlist.

Yes, sorry I didn't do so yesterday! And as the train is blocked (T413805) for a little while longer, backporting r1235477 to .13 makes sense I think.

Thanks, sounds good.

The above patches hide the labels from the non-advanced watchlist.

I think we should also get rid of the doubled border in between the buttons as well, e.g.:

@Complicatedintegral Welcome! Thanks for working on this. You'll likely need to modify resources/src/mediawiki.rcfilters/mw.rcfilters.js. Do you have MediaWiki installed locally for development? See https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker for some useful info.

@Reeti Did you see my comment above about this already being fixed? Your proposed fix changes the wording and is also not escaped, e.g.:

Thanks! Next time I'll be bold add such a thing as a subtask. :)

I blanked the watchlisttools-view message and the tab disappeared, but then deleted it and the tab reappeared. Sorry!

T416294 is breaking Special:Watchlist in MobileFrontend. A fix has been merged, but should I think be backported to .14 before the train continues (which it will be, so I don't think that makes it a blocker).

Special:EditWatchlist is now paginated (T411596), and the unwatch button is a the top of each page.

Yep, that's the goal of T415173 (this task is just a part of it, and we've not yet made the other tasks that make up the whole feature).

Do we need to put 'never' in every cell of the table when there's no expiry? When there are no labels we leave it blank. It feels like it's more common to leave cells blank when there's no data, but I'm not really sure if there's a rule about that. If we are putting 'never', should we also put 'no labels' or something in the labels' column?

Headers and text in box don't match Figma

Well, sometimes that do not emerge with many chcekboxes.
Well, sometimes they do not appear after minutes.

What with unlabeled pages? Choosing all and excluding them is good idea or there should be easier option?

API "edit" has "watchlist" and "watchlistexpiry". Why not this? :)

This has been fixed as part of T415489 in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1234783 and will be deployed in this week's train.

Thanks @Manvikesarwani09 but this task has actually already been completed, sorry! It's not been closed, because it's going though a quality assurance process.

So, until then we can't use the new feature at all?

The greying out of the buttons has already been done away with in favour of popups that explain the states in which the buttons will not do anything (e.g. if you don't first select any pages to apply labels to). Those fixes will go out in tomorrow's train.

❌ AC1: A confirmation dialog is shown with the correct title, body text listing selected pages (including pluralization when applicable), and the buttons Cancel, OK, and Remove.
They all have "Remove pages", besides "Remove title" as specified in the task and figma.

I've scheduled the deployment for the UTC morning backport window today.

Yep, that sounds good, thanks for making the patches!

I hope the intent was not to synchronise height in all editing layouts: this would be rather a bad idea given eg proofreadpage is made to work with a vertical layout.

Do you mean that the header and the footer were resizable but now they are not because of the recently added resizing bar?