Unfortunately I had to revert the removal of Template:License_template_tag. It appears that the UploadWizard extension tests for the presence of {{License template tag}} when a custom license is specified. See mw.UploadWizardLicenseInput.js and CommonSettings.php.

With the recent patch, I am curious about the following scenario:

1. the oathauth-enable user right is only available to users in particular groups,
2. all of those groups are listed in $wgOATHRequiredForGroups, and
3. a user in one of these groups does not have 2FA enabled.

Will that user be stuck unable to enable 2FA because the oathauth-enable user right is only available via a group that is disabled because they don't have 2FA enabled?

For what it is worth, with the revert applied non-CC-0 maps on Commons no longer work. See, for example, c:Data:Highway_192_in_Iowa_(3).map, which shows the error message Parameter "license" must be one of the valid license codes, for example CC0-1.0 instead of a map.

Actually the "Invalid content data" error only occurred if you moved the imported content to the Data namespace when the data did not comply with map.json requirements. Fixing the content to comply with map.json, moving it to Data namespace, and then trying to set the content model to map.json also did not not work (the closest option offered by Special:ChangeContentModel was JSON). Setting the content model of the valid ".map" content to the JSON content model (either before or after the move) does not result in a functional map. For an example of this see https://commons.wikimedia.org/wiki/Data:Highway_192_in_Iowa_(2).map

In my opinion, in cases where there the photographer has not chosen a title for the photo at 500px the title parameter should be left empty, not set to {{untitled}}, The title field should only be set to {{untitled}} for works of art where the artist has affirmatively asserted his or her work is untitled.

The linked discussion is now archived at Commons:Village_pump/Archive/2017/11#Large_lag_with_categories. The category mentioned in that discussion, Category:Images from the Geograph British Isles project, was moved on 16 October 2017 and the move is still not complete after 40 days. Is that expected behavior?

This looks like it might be a duplicate of T154071.

I>>! In T178840#3706240, @Aklapper wrote:

Is this different from T173710?

Thank you very much. I'll change the status of this bug to open, but please feel free to mark it as resolved or whatever based on how you manage your workflow.

If you think the bot behavior is correct, then, as I mentioned in my case (2) isn't the documentation inaccurate? Surely the the documentation should instead be saying someone like "Setting the state to alive, means the bot will check the URL every 3 days and mark it as dead if it fails 3 consecutive checks. The link is treated as alive until the third check has failed or the bot encounters it marked as dead in an article it reviews."

it skips the 3 check rule as it's essentially confirmed dead by another user.

But this was not the case. It was the bot itself that had marked the link as dead on a previous edit, so it was not confirmed by another user. I don't think the bot should be treating its own previous edits as "confirmation" of a dead link.

This appears to be duplicate of T150398

@Base: It's a new built-in feature of VisualEditor that allows an image to be uploaded immediately while editing a page without leaving VisualEditor.

Bug is still being reported. Latest incident: https://commons.wikimedia.org/wiki/Commons:Help_desk#Deletion_of_old_version.2C_possible_caching_problem

Commons policy specifically permits temporary undeletion to allow a file to be transferred to a project that permits fair use. By policy these requests can usually be handled speedily without discussion.

The protected edit request at Commons has been applied. Chechen dates will now display correctly on files. Files will be updated when they are edited, so old files may need a null edit/purge to force a page to rebuild the Chechen version.

Note that I and others are seeing rendering issues with the the notification icons on Commons in Safari which does support Object.defineProperty.

Only 5K or so. The time increase was probably because I was watching several categories that each had many thousands of category changes over the default watchlist period.

The initial version will by default hide categorization changes in the watch list

I've made a protected edit request at Module_talk:I18n/date on Commons; applying this edit should fix this issue on Commons.

In MediaWiki/core the file languages / messages / MessagesCe.php is using the format 'Y, j F' for Chechen dates per T94665.

OK, I found these defined at :
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikimediaMessages.git/044927dfd40df48193814391d0bfffad84360380/i18n%2Fcclicensetexts%2Fen.json

{{int:message name}} is a parser magic word that internationalizes the given interface message into the user language. All messages used in MediaWiki are defined in a messages file. While translations can be done at translatewiki.net, an initial English message and its documentation must be done in the source code (or at least, that is how I understand it).

For what it is worth, I saw "Z 0002 7925.jpg" (i.e. https://commons.wikimedia.org/w/index.php?title=File:Z_0002_7925.jpg&redirect=no) was in this category just now, did a null edit to that page, and it is no longer in this category (now https://commons.wikimedia.org/w/index.php?title=Category:Files_with_no_machine-readable_license&filefrom=Z starts with "Z 0002 7928.jpg").