I would state "transferring uploads from one local wiki to Commons" differently, unless you meant what is done with FileImporter (https://www.mediawiki.org/wiki/Extension:FileImporter). Something like "Doing cross-wiki uploading using Upload dialog (https://www.mediawiki.org/wiki/Upload_dialog )" will be clearer.

Let's say someone is autoconfirmed at English Wikipedia, but not on Commons. Would you want them to be allowed to upload or not? And vice versa?

The nearby feature improvement sounds nice and is expected to be faster. Can you include measurement to check how much faster it turns out to be into the plan? Would it be outside of the scope of GSOC?

You are right. That seems to work for my needs.

If we can rely on web.archive.org, the icon was not there about a month ago. Compare:

• https://web.archive.org/web/20240130154252/https://ja.wiktionary.org/w/index.php?title=%E7%A6%85&action=edit&oldid=1725096
• https://web.archive.org/web/20240225131150/https://ja.wiktionary.org/w/index.php?title=%E7%A6%85&action=edit&oldid=1725096

@TheDJ I submitted T358327. Thanks for your help.

Thanks, I edited the comment so the image should be visible now.

A triangular warning icon is added to message boxes in anonymous editing with captcha, as in https://ja.wiktionary.org/w/index.php?title=jipul&action=edit (when logged out - at least in my environment, captcha is apparently unconditionally shown to logged out users, not just when trying to add an external link). Is that a result of this new styling, intended or unintended?

No subsequent breakage as far as I know, so I guess we are done!

I'm pretty sure the cron task is migrated in the first part of the last 7 days. [1] The remaining number will go away soon, if we just wait more.

See https://commons.wikimedia.org/wiki/User_talk:ArchiverBot#Stuck?

Update: I intend to migrate it but it might take some more time. (I was not the original maintainer and still don't know how the code is organized well.)

Can the MinMT suggestion be converted into something like a beta feature, in which MinT results will be shown to users who explicitly have agreed to test it?

I largely agree. I tried https://translate.wmcloud.org/ and encountered the same pattern of errors including weird puctuation and spacing in Japanese. (All English commas and periods seem to be left untranslated, and would need to be revised by human.) Here is the result for the pre-filled text about Jazz:

My 'brute-force' method was pretty simple. I manually tried different images one by one and eventually found one that doesn't say logrotate is not found when executing "logrotate --version". Maybe I just got lucky when I hit it fairly soon. "Find an image that doesn't fail at command X" could perhaps be made as a script, though.

There were some problems but I think I sorted them out.

I am struggling to find an image containing logrotate (or its alternative). I have been using /usr/sbin/logrotate to rotate log files daily.

This might be a tangent but

I didn't migrate it because I couldn't figure out how to use venv inside kubernetes properly. I think I now know how.

@Esanders Thanks for the pointer. I believe the CSS solution would allow [[トーク:あ]] to be stylized as "トーク：あ" (or very similar to that). However, I would also want [[トーク：あ]] (in wikitext) to be an alias of or a redirect to [[トーク:あ]] and I don't think that's possible with CSS. Perhaps it was unclear with the description I wrote 10 years ago (!). I will try revising it later.

@Xqt You are right, the patch works as described in this task's description. I only skimmed the code and misunderstood how it works. (I should have tested it at least before commenting, sorry.)

Is this the same as T312773?

@MPhamWMF If the Search team doesn't want to keep owning the task, I think we can just remove the "Discovery-Search" tag. In fact, it looks like this task was only added to "Discovery-Search" in 2021, after 10 years.

You are right, saying the current behavior is to sort by the last post is wrong. I will change the description and the title.

FYI: https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#Jawiki_has_NOT_reached_consensus_on_implementing_Vector_2022_yet

(For future reference) T301649 changed the URL of the pageview service. The change of the URL had to be reflected on an allowlist used by popular ad blockers and privacy plugins: https://github.com/easylist/easylist/pull/11049

Is this different from T12268?

https://ticket.wikimedia.org/ redirects to https://ticket.wikimedia.org/otrs/index.pl which contains "otrs". Does this have to be changed, too?

This seems to overlap with T124841.

Yes, let's close. It might have been slightly better if we made the bahavior configurable, but after 4+ years, I guess the benefit of doing so now is little to none. (Most people would not be using the older versions of MediaWiki any more.)

If no, are there any reasons we could not run WHOIS commands from Clouds machines and cache them in a database?

There might be a common cause, but I think the old task was about edits. My problem here is about bot actions, not bot edits.

In T276613#6887916, @MisterSynergy wrote:

Just for the sake of completeness, I added some of the log items in concern into the description.