IIRC It is a gadget to link Commons file to Commons, not a configuration.

1 week with "nobody cares", this is good to go from usual Wikimedia-Site-requests perspective.

Please know that shouting is not good manner. Read the Phabricator etiquette (and the following Code of Conduct).

Probably this, and the user is probably referring to the Preferences > Site > Project 's "Wikia".

@MusikAnimal Completely forgot about this.

Red/Green idea came from the diff's red/green, I dunno how colorblinds deal with that part of MediaWiki? (Maybe bold the changed part and/or the coloring?)

I am good with the proposed new format, with one additional info: display what right was added/removed with green/red display (temporary right expiration change should count as added). It will help identifying which right was modified.

Not a bug.

I don't know about peachy so I'll leave the testing to Steinsplitter. Though I'd like to have another bot waiting for archival if our primary one fails.

In T204016#4573024, @APerson wrote:

I'd think the fix for this would be to make article-namespace creation its own right, given only to autoconfirmed & confirmed users, but there're probably other ways to do this.

Probably ArticleCreationWorkflow?

Dunno what causes it but WORKSFORME.

not only (24%), but also (24) causes this problem.

In T193486#4173640, @Smalyshev wrote:

Search for 김정은 works fine.

https://commons.wikimedia.org/wiki/Special:AbuseFilter/209 as a workaround, but may be incomplete.

I tried once again, actually stash was empty at the moment (meh) so I re-tried the upload with the expectation that the upload will fail (and UploadStash will fail again), but it managed to upload it successfully this time (meh).

Managed to upload it myself while trying to reproduce T200820. #

Should the last downloaded version of the article remain on their device?

I was merely informing @Base that his concern was (mostly) resolved. I already know the behind the scenes stuff that caused expedition of this task. (i.e. T192668 also happened elsewhere)

I thought security team and autopatrolled users on Commons has reached a compromise — T194864: Raise the rate limit for autopatrollers on Commons

In T106285#4448214, @Mholloway wrote:

I think this is within the bounds of convention for those languages.

1. 깨진링크=아니 should be 깨진링크=아니오
2. https://ko.wikipedia.org/w/index.php?title=토론:패치_오하라&diff=prev&oldid=21769315 {linkrescued} >.>

In T199055#4406571, @AndyRussG wrote:

@revi can you please try previewing the banner when logged out, and see if you still get the warning? Maybe the warning is due to a gadget that you're loading from enwiki?

In T187047#4406437, @Cyberpower678 wrote:

Request filed: https://ko.wikipedia.org/wiki/위키백과:봇/등록_신청#InternetArchiveBot

In T199055#4406347, @Steinsplitter wrote:

The banner is not loading content from enwiki, so this is likely not related. I cannot reproduce the issue in FF (no content loaded from en.wiki). Maybe it is caused by a user script but not related to the banner in question.

Translations at https://ko.wikipedia.org/wiki/User:-revi/IABot.

Hmm, seems macOS 10.13.5 Safari version 11.1.1(13605.2.8) skips the correct value and recognizes incorrect one.... meh.