Does such a problem really have to persist for 8 and a half years without a solution? Isn't it possible to turn off the block completely if it doesn't work and prevents normal editing?

related to T106456, T217572, T76703 etc.

The bug stil persists.

Not only P31, but also other statements can be used for the generic (default) description. E.g. P17+P131 (country+administrative unit) as a basal localization of localizable instances (geographic features, structures, events etc.), P403/P4614 (tributary of / basin) for watercourses, P2505+P177 (carries + crosses) for bridges, tunels, ferries etc., P4552 (mountain range) for mountains, P27+P106/P39 for people etc. Maybe, some generic international patterns for some classes of items can be created, and specific international patterns for such cases where the generic pattern would be ambiguous, or redundant, or where the universal patter is not able to select the most relevant statements. I mean a supralinguistic summary of basic statements, which would be automatically translated into individual languages. It is important that it is a dynamic translation, i.e. that every improvement of the template is reflected in all uses and translations, without having to fix and save all translations separately.

I tested the bug in two languages, cs and en. The behaviour was identical.

See also Commons talk:Structured data/Reconciliation for som other bug reports, possibly related.

This feature should be switched off until T259323 is solved.

Nobody has been solving this bug for two years now.

Reported at:

• MediaWiki talk:Gadget-HotCat.js#Dropped-categories bug (4 February 2022)
• Commons:Village pump#HotCat bugs (27 January 2022)

No reply yet.

I'm sorry - I tagged the bug report to the projects "Maps" and "Commons" and I supposed, that it will be dealt by people who have a basic knowledge of what maps are and how the Commons work. I considered it unthinkable that anyone who deals with maps for Wikimedia projects can not know how coordinates are standardly entered in Wikipedia, Commons and Wikidata. I thought that a broad explanation of the basic general concepts could overshadow the simple nature of the problem.

I still do not understand what is not clear to you in the brief and unambiguous description of the problem. It the problem constists in the fact that there is no available map of photos containing the camera heading, what do you want to reproduce?

Is something unclear on the problem description?

Also similar to T213462.

There are several ways how to deal this need. They can be developed paralelly or even synergistically:

The problem continues...

Tested now: at Commons, the problem continues. Language/project selection in the AddLinks form fails.

This bug was reported also at Commons:Village pump#Interwiki linking disabled? at 05:31, 11 June 2021 (UTC) .

This bug report is urgent! I find a lot of damaged files among the new uploads!

It seems all false positives are redirected file names.

ErfgoedBot added a duplicate monument-ID tempate to the file page. (2020-02-11, 23:31).

Images of cultural heritage monuments in Czech Republic without id from 2020-02-15 19:36 contain many false positives again.

File:Štramberk, Horní Bašta 293.jpg seems to be a false positive in the list Images_of_cultural_heritage_monuments_in_Czech_Republic_without_id, version 2020-02-12, 05:15 UTC. The list listed this photo to be added {{Cultural Heritage Czech Republic|13170/8-3390}}, while the file page contains this tag since if was uploaded 2014-09-03.

Some another bug? Images of cultural heritage monuments in Czech Republic without id is empty suddenly, from yesterday's 7550 images.

Tonight, Nevyužité obrázky was skipped/omited again.

6 February evening, Missing commons category links and Images of cultural heritage monuments in Czech Republic without id were updated almost correctly but Nevyužité obrázky failed (was not updated).

In T228317#5342889, @Urbanecm wrote:

Some context here: Firstly, that's about edit limit, not move limit.

The problem with the rate limit affects not just file moves but also other page moves. E. g. when I rename (manually!) a set of categories in order to harmonize their names with the appropriate category tree, sometimes I have a problem with the rate limit too. I have no problem to wait a moment, but IMHO the limit can be a bit increased. Maybe to twofold?

@Aklapper: HotCat itself is available in "Gadgets" bookmark of preference settings. I don't know whether the tag is confusing and means something else. Tag "HotCat" is not available.

There seems to be no shift in the problem solution. Please help to correct, improve and internationalize a message template intended to inform uploaders of affected files.

@Aklapper: If nobody is capable to make functionality of UploadWizard at least comparable with the basic upload form, UploadWizard should be suspended and the normal upload form should be set back as the default one. Half-baked UploadWizard impedes and complicates proper categorization of new uploads and supports bad habits and misapprehension of uploaders. That is utterly counter-productive.

related to T177687

related to T42076

Related comment and discussion:

The problem is still continuing... I propose to switch cross-wiki uploads off and forbid it until the problem is solved. An other possibility is to set a 5MB limit to cross-wiki uploads, to prevent faulty uploads.

The problem is still continuing... I propose to switch cross-wiki uploads off and forbid it until the problem is solved.

In T146846#4538792, @Mholloway wrote:

Please provide a current example and/or repro steps. Thanks!

In T146845#4538795, @Mholloway wrote:

Please provide a current example and/or repro steps. Thanks!

Category:Incomplete JPG files (5 MB interruption) created for files affected with this specific problem.

Cross-wiki uploads from uk.wikipedia.org are also affected: I found 3 images uploaded on 2017-09-27 and 2017-09-28:

A recurrence reported as T201111.

In T146844#4465753, @Mholloway wrote:

It's been a while since this was filed. Is this task still valid?

Památkou_do = a date when the protection ended officially (for former monuments)
Zdroj souřadnic = source of the coordinates, "PK" value used for the "Památkový katalog"
Zdroj souřadnic datum přístupu = access date when the coordinates were taken from the source

Thus, the crucial problem is that "All public logs" (Special:Log) is not integrated into the Revision history page (action=history) and therefore the history page is misleading. I go to create a new taks for that problem.