Ah, good point! In that case, we'll just need the link to the main TWL site (and perhaps include a bit of explanation).

In T378077#10258366, @Samwalton9-WMF wrote:

I just wrote an example sentence in the mockup, but I wonder if it's worth documenting further what the EDS integration is / how you can become eligible for the library somewhere and linking out to that, or just having a more verbose note here

Marking as resolved since the underlying issue (bot scraping of the tool) has been dealt with. As for the odd appearance of - http://hasty.ai in the HTTP request line in violation of RFC 9112, this is something that should be split off into its own task (if it's even worth investigating).

Sorry for getting to this late! My email filters weren't working well and I completely lost the Phabricator email in the noise. I've fixed this with 36339af6bb3a37917e11d3c66a656abe0ae11f54, which was deployed just now. Thanks for reporting!

Done with f170aaf7abaf4a834fdd10d0a7deb463bd3f3a5f, deployed just now.

Done with 5c271610993104af5b1caf4997017cf71ed6baf4, deployed just now.

Great to know! You're right about the members thing; parent projects can't have direct members.

I wanted to put this on next week's Tech News but the deploy missed the deadline for drafting by 3 hours. I've made a message about the change at the week after next's Tech News talk page.

Will do in a bit after I finish some current pending work. Should be easily doable, since Phabricator provides that info in project.search.

Assumed resolved.

Fixed with the latest deploy. Thanks for reporting this! (and working on T373742 :D)

Nice! Thank you, Taavi! :D

Deployed!

Verified that all these logos look good. Will schedule for the UTC late backport window today.

Deployed!

Looks like it was a bad character escaping issue, and the fact that parentheses weren't part of the escaped characters list. I've replaced the mediocre escaping method with a better (and probably overkill one) at 91d736da. I would deploy this now, but it seems like Toolforge Build Service had other plans (T373243). Will deploy whenever able.

Noting here that I'm unable to use Build Service, probably due to the same issue. Related log line:

[step-clone] 2024-08-25T22:59:56.754700588Z {"level":"error","ts":1724626796.754072,"caller":"git/git.go:55","msg":"Error running git [fetch --recurse-submodules=yes --depth=1 origin --update-head-ok --force ]: exit status 128\nfatal: unable to access 'https://gitlab.wikimedia.org/toolforge-repos/techcontribs/': Could not resolve host: gitlab.wikimedia.org\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:55\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:150\nmain.main\n\tgithub.com/tektoncd/pipeline/cmd/git-init/main.go:53\nruntime.main\n\truntime/proc.go:255"}

Looks like it was because of a missing check prior to showing the activity chart. This affects anyone with historical contributions, but no patches owned, uploaded, or reviewed in the past year. This should be fixed with 749a84e (+ changes from 4bf3d68, because I accidentally rebased them onto the wrong commit which also changed the activity chart :facepalm:), which has been deployed.

Tried to deploy with Clare earlier, but there were issues with some of the files:

• Wikisource Georgian's wordmark has some untrimmed spaces on the side which is causing it to overflow into the search bar. The font of the wordmark also differs from the one on the logo; is this intentional? Might have to follow up with the uploader and/or reupload the mark as extracted from the logo.
• Wiktionary Karakalpak's logo was too far to the left. There appeared to be some untrimmed excess on the right side from even before the file was resized.

In the interest of safety and double-checking, I decided not to proceed with attempting to deploy the rest of the patches. However, taking a look at the image files for the rest of the wikis, those should be fine and good to go. I'll triple check again tomorrow (a few hours). Will refile kawikisource and kaawiktionary patches, and then upload new patchsets for the other wikis as needed.

It doesn't seem like Superpes has been active recently, so I'm reassigning this to myself to get the other logos done. This task seems to have been mostly inactive for almost two months and it'd be nice to finally get this done for the communities of those wikis.

PR for this filed at https://github.com/wikimedia/CopyPatrol/pull/185

Indeed it was me. I think we also discussed if it was possible to use MediaViewer with TheDJ? Not sure if there was anything specifically blocking, though.

@Superpes15 Still planning to work on this soon? I can work on the rest if you're not; no pressure though.

Testing this out, there's two issues which make it a bit harder than just adding position: sticky; top: XXXpx:

1. Images are overlapping the header; z-index issue.
2. Following links to section headers leads to the section header appearing under the now-sticky header. This could be fixed with an offset; Vector '22 already does this to avoid the section headers appearing below the sticky header. I can't find the code for this though, so I have no clue how it's currently already being done.

Done. Thank you, @TheresNoTime!

Splitting off mswikisource and dtpwiki into T372031, since this was something someone at the Wikimania Hackathon approached me with. Will get that done today.

I completely missed Hooks.php! Guess I'll file another patch to cover that one... 😅

I don't have the permission to edit Campaign-namespace pages on Commons. @Robertsky (or anyone with the right perms lurking), can you test if this is still an issue on your end?

Experiencing the same thing on Jueteng; everything below the etymology sections seems to be greyed out. I checked the source and there's nothing popping up I can see that should be an issue.

Might be better to just attach the mw-disambig and mw-redirect classes to these and allow user CSS to style them, just like we normally do on parses. Not sure how expensive that might be performance-wise.

Found a temporary solution. This should work for now until T364144 finally gets worked on.

Bad news: the way the filter works is inherently incompatible with QueryBuilder.

Got this checked by a DBA to make sure it's safe, see T364144 for the general sentiment.

I've got the previous patch working on the latest commit of Nuke (as part of Wikimedia-Hackathon-2024), i.e. converted it to use the new QueryBuilder system. Lots of reusable stuff, so might as well just improve that patch rather than create a new one. Uploaded it under the same patch (541077).

In T43351#9767132, @Samwalton9-WMF wrote:

I think this is worth putting in Tech News:

Nuke will now correctly delete pages which were moved to another title.

I've updated Xiplus' patch to work on the latest revision of Nuke for Wikimedia-Hackathon-2024. Nuke was migrated to query builder some time ago so I've changed it up to use that.

Should we rename this task, @Sportzpikachu? Considering we only really have one choice for internationalization (per T348406).

Biggest blocker for this has been resolved (link). The Great Refactoring is upon us.

Probably related to the 17 hour replication lag for enwiki right now, similar to T362725. Root cause appears to be an issue with the replicas (T363077).

De-assigning until I can dedicate more time to this. Here's a summary of where I'm at though:

More information on how developers can react to the changes can now be found at mw:Trust and Safety Product/Temporary Accounts/For developers. I'll try to work on this, among other things, this week and next week.

Looks like this has been fixed. I can confirm that the CC BY-SA 4.0 text now shows up on the Android app. page-talk-page-subtitle in ruwiki PCS i18n data also reflects the latest from TranslateWiki. Marking this as resolved, unless something else comes up.

In T356704#9556128, @Tgr wrote:

If you want to debug what's happening, I think your best bet is checking out Quibble so you can run the test in the exact same environment it runs in on the CI servers, but with a debugger enabled.

Sorry for the relative silence! The year kicked off pretty busy for me. I'll be much more available now though.

This is an issue with RedWarn, as Ultraviolet doesn't have a right-click menu (as of now). We'll make sure this is fixed in reimplementation.

Can't seem to replicate this locally, or at least I know too little of the configuration to ensure that I'm replicating this properly. The page is undeleted with no issues. But the debug log it spat out corroborated what I wrote above.

I checked Flow but it was mostly localization and npm updates, so I wasn't ready to blame it just yet. In my head, this loop being interrupted by the teardown was pretty odd, and I focused on that instead.

Been investigating at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/997634 by putting a bunch of log statements in and I'm a bit stumped. Here's where I'm at:

You'll need the ORES extension installed and active, if it isn't already. The copyvio tag is, for some reason, attached to ORES being present in the wiki. Without it, PageTriage just skips searching for the copyvio tag entirely. Setup is here, to save you a few clicks.

Definitely related. Selecting the "copyvio" filter and any other filter on the new pages feed causes this issue to show up. The copyvio tag is JOINed separately from the rest of the tags, which in turn causes the reference to ptrpt_tag_id at ApiPageTriageList.php:577 to become ambiguous if both the copyvio tag and some other tag (newcomer, learner, etc.) have been requested.

Possibly related to T354894? The request URL matches the one on that task and it was opened just recently (though the logs here look like the underlying issue for that task).

Seems like it's happening when the "Copyvio"/"None" possible issue filter is paired with one of the "Were created by" filters (newcomer/learner/etc., except "Autopatrolled users" and "Show all"). This was reported for wmf.12 but it's still happening to me right now (seems like wmf.13 was deployed just minutes ago).

Caused by on-wiki changes, namely a flood of new version numbers on the Wikidata item for the page. At least it wasn't anything more serious.

We should also make sure to handle cross-origin requests (Access-Control-Allow-Origin), at least for Wikimedia sites. Otherwise, another external tool would be required to call these endpoints whenever they're needed from the browser side. In addition, we'll need to prevent cross-site request forgery (CSRF) through single-use tokens. That probably also needs an endpoint.