In T373773#10109174, @Bugreporter wrote:

maybe a bug in recountCategories.php, which runs once every month (at 1st day 4:00).

Please add all dummy images in https://commons.wikimedia.org/wiki/Category:Wikipedia_image_placeholders_for_cultural_heritage_monuments (not only https://commons.wikimedia.org/wiki/File:Archdenkmal.svg)

In T373773#10111316, @Umherirrender wrote:

Some excessive linkpurge/nulledit also happen to fill the categories due to T373722
The next run of recountCategories.php should fix it.

In T373722#10110051, @Ladsgroup wrote:

FWIW, given the size and amount of writes in commons. It usually takes a very long time, sometimes months for the changes to propagate to all pages that use a template/module. It's normal since your wiki has 100M pages.

the rules for the competition read (https://meta.wikimedia.org/wiki/Wikipedia_Pages_Wanting_Photos_2024): Include the hashtag #WPWP in the edit summary of all articles improved with images.

In T262234#9017735, @Framawiki wrote:

frwiki user reported that the tool didn't list his edits with summary Wikification (#moiswikif). Adding this char to the regex would probably be acceptable.

acc. to @JoKalliauer there seems to be a render problem with
transform="scale( in combination with <text and text-anchor="middle").

related to T358438?

There is a contest going on. For this contest it is crucial infrastructure. Be kind, be responsive.

as far as I can judge, everything is back to normal. Thanks

https://commons.wikimedia.org/wiki/special:uploadWizard?campaign=wlm-at&fields%5B%5D=56784&fields%5B%5D=47.067016/15.446529&captionlang=de&caption=F%C3%BCrst+Dietrichstein%27sches+Stiftungshaus+%28BDA-HERIS-ID%3A+51185%29%2C+Schl%C3%B6gelgasse+9%2C+Graz&descriptionlang=de&description=F%C3%BCrst+Dietrichstein%27sches+Stiftungshaus&categories=F%C3%BCrst+Dietrichstein%27sches+Stiftungshaus%2C+Graz works in FF, but does not work in Chrome.

We are running our annual photo competition WikiDaheim (starting with July, 1st), which is highly based on a working UW.

Now I logged in to test.wikipedia.org, it does not change the behavior.
I also tried to log out and log in from paws, did not change anything.
thanks for caring - still help needed

pwb.py version:

I will also remove the WMDE related tags here since we're currently not working on this feature, especially when it's about adding new functionality.

In T355114#9518050, @thiemowmde wrote:

Can you explain the proposal in a bit more detail?

I set the max width now to 1024 and it works also when zoom > 100%.
Thanks.

New observations (hint to reproduce the problem):

In T350348#9328058, @Gehel wrote:

I'm marking this as resolved as we have a working query. Blazegraph being unmaintained, reporting the issue upstream is not really helpful.

@dcausse thanks for your investigations. Your query is 8 times faster than mine (optimizing is obviously not always the way to go) and it gives 165 matches instead of my query that still gives 171.

as things are stochastic:
Now the difference between landforms and mountains is in Hanauer Spitze https://www.wikidata.org/wiki/Q21878328 and Brunnkarspitze https://www.wikidata.org/wiki/Q21878293

In T332539#8725462, @Lydia_Pintscher wrote:

@hoo @Mike_Peel Does either of you know where this is coming from? I can't find any shape definition in the related Wikidata Item or Commons pages. Is it just taking whatever OSM has there as an object?

The Wikidata User Interface, https://www.wikidata.org/wiki/Q117151102:

not fixed for https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_%C3%96sterreichische_Denkmallisten#Erweiterung_Denkmallisten_um_Shapes

the solution for this (allow the deletion of false coordinates) is only half way. In principle the bot copied it, the bot shall keep it in sync without user intervention.

Let's consider this to be an epic fail of problem management in Wikidata. This is now open for more than 7 years, and it is about trimming whitespaces. facepalm.
Everybody paralysed? The current proposal is to improve documentation and error messages, needless to say this is NOT the solution but an annoyance.
The UI is apparently not a first class interface to Wikidata.

I have the problem NOW. I was advised in T290438 to ask for reloading the erronous item. You can create your own testcases.

T291006: please reload https://www.wikidata.org/wiki/Q37986974

this seems to happen when the jupiter notebook contains output and becomes too large. Then it does not load anymore. Mine had around 66 MByre. You can strip the output before loading using

So then this needs a policy update on commons when to DR redirects. And we need a global cleanup of such wrong redirects to clean the results of media Seacrh

There are ~130600 redirects with location data in geo_tags (for commons file namespace):

I suspect that when storing coordinates the precision is applied to the value and values are changed acc. to the given precision. Changing the precision will again do some conversion on the coordinates and store new values. Original values get lost. I take the coordinates from GIS services, that offer decimal notation and degree/minutes/seconds notation as well. I have no idea, which of those values is the primary value and which is a simple conversion (not lossless!). So taking the wrong one is the first step where precision might get lost. The second is storing to WP where values might be converted to and fro. When coordinates are imported to wikidata, again a loss of precision occurs.

Hi, I just observered a behavior. Possible reactions are:
not reproducable, wontfix (with reason), fixed (the best of all possibilities) (scnr)
clarify, if unclear.

In T251480#6096842, @Reedy wrote:

Into what field are you trying to enter it?

https://www.wikidata.org/w/index.php?title=Q7861551&oldid=1095688967
first coord links to 47° 15′ 28.8″ N, 11° 24′ 38.16″ E in geohack, but is rendered as 47°15'7"N, 11°24'34"E in Wikidata (a difference of 20'' / 4'')

same for the first coord in https://www.wikidata.org/w/index.php?title=Q12343559&diff=1082146732&oldid=896933408&diffmode=source
with precision +/- 0.013101
is rendered as 46°42'19"N, 12°36'59"E in WD
but for geohack this is 46° 42′ 38.52″ N, 12° 37′ 0.12″ E

same for the second coordinate in https://www.wikidata.org/w/index.php?title=Q801607&oldid=1162774540
WD shows ''48°8'2"N, 16°17'13"E'' while
geohack shows 48° 8′ 4.92″ N, 16° 17′ 2.04″ E

In T142082#6065221, @Dvorapa wrote:

The issue is that the button is not at the bottom, actually it is above sitelinks and above external identificators. It is even hard to find it. I agree with @Herzi.Pinki, this should be handled by the add dialog window.

In T142082#2623859, @Lydia_Pintscher wrote:

How do you make sure then you are not adding a statement that is already there?

the problem occurs on Commons: https://commons.wikimedia.org/wiki/Help:Gadget-ImageAnnotator
The issue is also reported here: https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-ImageAnnotator.js#Problem

this is a duplicate of T213341

@Legoktm, can you please help again to push that issue?

Tried with another bundle of files, could not reproduce the faulty behaviour. Thanks for your attention. Sorry.

The file does not exist as I nominated it for speedy deletion. You can see the log entry.

workaround as suggested in https://www.mediawiki.org/wiki/Topic:Up2kw5v8m8q3v477

Currently we have about 1500 articles in the German WP affected by this problem (https://de.wikipedia.org/w/index.php?search=insource%3A%22ICON2%22&title=Spezial%3ASuche&go=Artikel) with usually multiple occurrences of the problem. Any change in such a page will invalidate the cache and later affect all readers. If I do a change (e.g. a typo), I do not re-check all the coordinate links.

@Aklapper, seems to be an easy to fix problem, something like the typical off by 1 (you can hang me of course, if I'm completely wrong)
can you please schedule it to the correct project?