WS Export has also recently started erroring with failures to connect to urwikisource_p.

Do the redirect templates need to be given parameters?

Thanks! Merged and released in 1.10.1.

e.g. https://ocr.wmcloud.org/?image=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fthumb%2Fa%2Fac%2FNotes_and_collections_relating_to_the_parish_of_Aldridge%252C_Part_2.djvu%2Fpage57-1280px-Notes_and_collections_relating_to_the_parish_of_Aldridge%252C_Part_2.djvu.jpg%3Futm_source%3Den.wikisource.org%26utm_campaign%3Dindex%26utm_content%3Dthumbnail&engine=google&psm=3&line_id=null&rotate=90&crop%5Bx%5D=1081&crop%5By%5D=197&crop%5Bwidth%5D=828&crop%5Bheight%5D=131

@Okerekechinweotito It looks like there might be an issue when an image is rotated and cropped, it works when first requested, but the crop is shown with the wrong offset.

Merged and released in 1.10.0.

@Ssein As r1265449 doesn't pass CI and hasn't been worked on since submission, I'd say it's okay to continue working on your r1252657 patch and to get it sorted out. It sounds like it might be good to break things up into a few different patches, if there are separate unrelated bugs to fix.

Exactly, that's the question.

The Free Knowledge Portal tool is based on using Wikidata IDs in the QR codes.

It might be best to just pull in the contributors list from that file, and not the headings and link to Translatewiki.net ("Translators on translatewiki.net and others"), then those bits can be added as messages and translated normally.

The remaining occurrences of wikimedia-ocr in wikis are historical and look like they don't need to be updated: https://global-search.toolforge.org/?q=wikimedia%5C-ocr&regex=1&namespaces=&title=

The OCR tool Git repo has now moved to GitLab. Sorry to make extra work, but could any still-active PRs above please be pushed to https://gitlab.wikimedia.org/toolforge-repos/ocr instead of GitHub? Thanks!

For the {number} pattern we could do it in one query probably, e.g. for A{number}:

Could there perhaps be some admin gadget or other, that is modifying these pages and submitting an empty value for the labels (i.e. deleting them all)?

Released as 1.3.4: https://meta.wikimedia.org/w/index.php?title=MediaWiki%3AGadget-AutosuggestSitelink.js&diff=30591595&oldid=30521553

Good idea.

Updated some wikis:

• https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource%3AWikisource%2FWikimedia_OCR&diff=2416403&oldid=2193282
• https://www.mediawiki.org/w/index.php?title=GitHub&diff=8382890&oldid=7955104
• https://www.wikidata.org/w/index.php?title=Q139309202&diff=2494755442&oldid=2485533498
• https://meta.wikimedia.org/w/index.php?title=Community_Tech%2FMaintenance%2FWikimedia_OCR&diff=30568375&oldid=26826685
• https://www.mediawiki.org/w/index.php?title=Extension%3AWikisource&diff=8382891&oldid=7752665

Thanks @taavi! Next time we'll destroy and re-create with a clean image.

MR 77 deployed in 1.3.3.

Deployed in 1.3.3.

@HakanIST Does the nowrap fix above solve for your MR 77 changes as well?

Confirmed that a commit has been added to the new repo: https://gitlab.wikimedia.org/toolforge-repos/ocr/-/commit/2709e8fc3379a1709212cf4c14d8e3f61773a353

Yes, the plan is that at some point it'll be unconditionally available on all wikis. We talked about leaving the feature flag in place, but the feeling is that MediaWiki already has so many config options and that each one adds a cost that isn't worth it in this case (similarly for watchlist expiry).

I also can't log in. I guess SSH keys aren't being copied on to the server.

Thanks for these notes @Tohaomg. Adding a random image feature sounds interesting, could you create a separate task for that?

Released in 1.3.1.

Released in 1.3.1.

It looks like this has now turned into errors such as:

Does this sound okay (for now)?

Released in 1.3.0.

Released in 1.3.0.

The scroll behaviour was (when it was a popover rather than a dialog) supposed to be that it'd close if you scrolled it off screen while it was open, and then re-open if you scrolled back.

The current search is also case-sensitive, including the initial character (which is always uppercase (for scripts that have uppercase)).

when clicking on Unwatch, the dialog should disappear

A few people have said that one-click unwatching would be good, but I'm still not sure how that should work now that we've got watchlist labels — is unwatching more useful than being able to change the labels (or expiry) for a page? Because if you click to unwatch, then you also discard your labels. We thought about adding a second button next to the watchstar, but that's a lot more complicated (especially now that the watch link is also more likely to appear in the tools menu, if Reading Lists is enabled).

Sorry about the bugs!

Thanks for this!

I've tagged version 2.1.0 and deployed it. Thanks for all your work on this @Booksmurf! It's great.

MR 8 released and deployed in version 3.1.4.

Merged and deployed in 1.9.4.

I wasn't thinking right! :) Of course. No, it can stay closed, I just thought that perhaps someone had applied a local workaround in common.css or something.

Where are you seeing it fixed? The new code hasn't been deployed yet! :)

I think this task might be covered by T417847. Should we close as duplicate? Or is this also about the non-JS interface at ?action=watch? Which could certainly be improved! (Because it was never meant as a 'change watch' form.)

@TheresNoTime This is ready for review. I went with the idea that while the popover is open you should be able to tab through all of its focussable elements, returning to the watchstar (and shift-tabbing goes the other way around). Then, to get back to the normal tab flow, clicking enter on the watchstar closes the popover (which was raised in T423013). See what you think.

Clicking a not filled in star with the panel open, I'd expect it to perform a watch action (previous behavior). Instead it doesn't do anything.

That's all true, but I don't think there's much we can we do about it, unfortunately. We just send images to the Google API and get text back. We don't have any say in their algorithm.