Fixed with cfad7732 and hotfixed on prod. Thanks for the report.

In T272523#6838612, @Bstorm wrote:

Ok, centralauth is up as well. Thanks for the report @MusikAnimal

Hello! On which section does the centralauth database live? It does not appear to be on any of the db lists at noc.wikimedia.org. Perhaps a view needs to be created for it, too?

Fixed! Thanks for the report.

https://gerrit.wikimedia.org/r/659440 appears to have broken the hover state for Vector dropdown menus. For example at https://en.wikipedia.beta.wmflabs.org/wiki/Test_indicators I must click on the "More" menu at the top-right for it to show (if you don't see the More menu, try running e.g. mw.util.addPortletLink('p-cactions', '#', 'Foo'); ).

PR merged! Thank you. I'll go ahead and resolve this. Arabic Wikipedia has already confirmed CopyPatrol to be working for them: T271823

Looks like the fix for T273017 also fixed this! See for example https://copypatrol.toolforge.org/fr/?id=68138278 and https://copypatrol.toolforge.org/cs/?id=68154284

Hello! I'd like to point out that this will surely cause widespread breakage. Tool-Pageviews, XTools, and Event Metrics will all break (when requesting a range >1 year), and that's only naming the tools I personally maintain. If possible it would be good to have ample time to fix these.

@alaa Sorry for the long wait. The fix for T273017 appears to have worked :) There is now an Arabic feed: https://copypatrol.toolforge.org/ar (at the time of writing there is only one case that was auto-closed by the bot because the page was deleted).

Okay, that worked! There is now a feed for Arabic :) I suspect T244665 is now fixed too, but I have not confirmed that yet.

@eranroz Could I get a sanity check on https://github.com/valhallasw/plagiabot/pull/20 ? I admit it's a bit of guesswork but it seems promising based on my quick research. If there's no opposition, I might go ahead and try this in production to see if it fixes support for Arabic. Thanks for the help.

For PHP/Symfony users, the ToolforgeBundle has been updated to include a replicas connection manager. This goes by the dblists at noc.wikimedia.org to ensure your app has no more connections than it needs to. It also has a simple command (php bin/console toolforge:ssh) to open an SSH tunnel for easier development on local environments. See docs at https://github.com/wikimedia/ToolforgeBundle#replicas-connection-manager

With the Graphiod service undeployed (T242855), is this task still valid?

No errors in the past week, verified on Logstash. We also removed the filter from mediawiki-new-errors dashboard. Closing as resolved, thanks for the help, all!

In T264045#6791491, @Fae wrote:

Under discussion at Commons VP. Overwhelmingly negative.

This proposal should not go ahead unless there is some reasonable consensus as to what the desired use case is, and why it would benefit rather than harm the project collections or be used to potentially disrupt and harm the community. Various forms of NSFW categorization, classification and censorship have been discussed since the Wikimedia Commons started, it would be worth researching the VP discussion archives.

For those unaware of the history, as an example of how controversial this issue is, Jimmy Wales abandoned making contributions to Commons in 2014 because of his views about nudity/sexuality content and has made one edit since. Inviting interns to jump into these muddy waters would be, frankly, foolish.

A quick web search brought me to https://stackoverflow.com/questions/3942888/unicodeencodeerror-latin-1-codec-cant-encode-character#comment34031454_3942888

Okay, I think there is a bug with the bot. Here is a stack trace of a recent error:

Just a note that this has been running for a few days now, there just apparently haven't been any copyvios yet. Once there are, https://copypatrol.toolforge.org/ar should magically start working.

Community-Tech would be happy to participate in early testing. All we need to do to test the new infrastructure is update our code in accordance with https://wikitech.wikimedia.org/wiki/News/Wiki_Replicas_2020_Redesign#What_should_I_do%3F , correct?

In T271971#6762121, @dom_walden wrote:

Speculating (with no evidence at the moment) as to the cause of this bug, could it be due to slow replication from the master to the replica databases?

If there is already a watchlist entry for $page and you move another page to $page, it replaces the entry in watchlist on master.

If updateExpiriesAfterMove runs a select on the replica database to find out the wl_id of the $page entry, it might get the old wl_id from before the replace.

PR merged at https://github.com/wsexport/tool/pull/309. I'm assuming this belongs in the sprint?

@Niharika Any chance this could get some attention? Special:Investigate and all its benefits are largely unusable by stewards :( I can still use the Timeline view but I don't get the user agent highlighting feature, for instance.