User talk:Magnus Manske

Previous discussion was archived at User talk:Magnus Manske/Archive 9 on 2024-01-01.

Hi, your bot imports nonsensical data about swimmers. Could you make it stop doing that (and ideally revert the wrong additions)?

Not interested? OK, I have removed those 1797 claims where the imported country for sports was different to the nationality. Not sure about the rest, I’ll leave those, they will probably mostly be correct.

Hi, I'm interested, just spread too thin :-(

Thanks for the cleanup! What can I do to prevent this?

The catalog was imported by User:Luca.favorido into Mix'n'match, so they would know why the country metadata is wrong.

I can delete the country for sport (P1532) metadata for the entire catalog. That should solve the specific issue from recurring. Do you think that's warranted?

Hello, I see, the error is surely mine.

The problem is only with some specific countries. I assumed that the 3 letters code was the ISO-3166-alpha-3 but I was wrong...

For example, CRO stands for Croatia, even if the standard code should be HRV. So, my assumption was the issue that caused the problems in the reconciliation between countries and Qids.

Yes, I suggest to delete the catalog metadata, or, if possible, only the nazionalità sportiva (P1532) column. Thanks.

Here we go again… I presume the nonsense data has still not been deleted from the catalog?

As I said, I'm sorry about it. If it's not possible to drop the country data from the catalog metadata, we could delete the catalog as a resolution and reimport it.

But I'm sorry @Mormegil, I don't have enough rights to do it.

Hallo Magnus, bitte sei sorgfältiger bei deinen Zuordnungen: Fahrenhorst (Q60203866) eine Ortschaft ist etwas anderes als ein Gutshaus, Feriengäste am Bollwerk (Q123243126) eine Skulptur etwas anderes als ein Gutshaus. Bitte korrigiere das. -- Gerd Fahrenhorst (Diskussion) 14:01, 9 July 2024 (UTC)

und ja, eine Zementwerk ist auch kein Gutshaus: Q110240796 --Gerd Fahrenhorst (Diskussion) 14:03, 9 July 2024 (UTC)

Magst du mal antworten?

Nun atme erst mal tief durch, ich guck ja schon... :-)

Hallo Magnus, ich schließe mich Gerds Bitte an. Auch heute noch fügst du zig falsche IDs hinzu: Ortsteile , Teiche und ganz viele Kirchen ... Die wurden alle schon mal zurückgesetzt und du hast sie wieder neu eingefügt.

Ich lass grad' was laufen, das zB Orte unmatched, hier und in Mix'n'match. Aber manche (zB Kirchen) könnten auch "Wehrkirchen" sein, die wohl als Burg gelten. Das ist automatisch nicht so einfach.

Hallo Herr Manske, auch ich schließe mich Gerds Bitte an. Auch heute noch fügen Sie etliche falsche IDs hinzu: Diese wurden alle schon mal zurückgesetzt und Sie haben sie wieder neu eingefügt.

Sollte jetzt alles in MnM entfernt sein

Hallo Magnus, bei Baindt Schachen (Q126325560) habe ich jetzt zum zweiten mal den Eintrag zu "Alle Burgen" entfernt, da es sich dabei nicht um den Ort Schachen, sondern um eine Bushaltestelle handelt. Beides mal hast du das mit Quick Statement gemacht, ich vermute daher, das du das in irgendeiner Vorlage hast. Bitte entferne Baindt Schachen (Q126325560) dort und achte künftig darauf in welche Datenobjekte du was schreibst.

Das ist von Mix'n'match, da war der automatcher etwas übereifrig... Danke, erledigt.

special:diff/2204519147 —Mykhal (talk) 22:50, 14 July 2024 (UTC)

(I dared to undo resolving without any reaction.) —Mykhal (talk) 13:59, 16 July 2024 (UTC)

I explained on some other talk page which I can't find right now. Catalog was deleted.

Hi, shouldn't this one go in Q212164 instead? Q124024879 is only the chapel inside the fortress.

Fixed, thanks!

At least for Wikidata users who would be unpatrolled; preferably for everybody until it can be improved. See Wikidata:Administrators' noticeboard#Please revert June 20 edits by User:Jephtah Ogyefo Acquah for the latest problems, beyond what I can keep up with.

Deactivated until further notice

Over the past few months, the manual batch mode in QS has started to freeze regularly. When this happens, the current edit hangs in the "run" status and the batch just freezes indefinitely. This is bug #1. There is no connection between the jobs themselves - this can happen when adding any property statement or editing a label on an empty item.

Bug #2. When the above case happens - you can restart the queue by pressing STOP and RUN again. The task will be restarted, but the item on which the freeze occurred will remain in the "run" status forever. So after the batch is finished - these cannot be restarted in any way because they are not listed in errors and do not appear in "init" listing. The only way to track them is to manually search for "run" on each page, which is quite annoying for large batches. At the moment with 1k batches it happens about 10 times. And it seems like the only way is not to use manual mode or to run the batch twice in a row.

I suppose it would be great if at least the "Try to reset errors" button would also take into account those that remain in the "run" status.

I confirm experiencing both bugs, and I agree with Solidest that solving at least #2 (if possible, also #1) would be of great help. Thanks!

Hi all, just back from Covid now. #2 should be fixed (untested but seems trivial).

1. 1 seems difficult to replicate; I'll look into it.

Glad you're back well, and sorry to bother you. But the fix has not helped. Tasks in "run" status are still not detected after clicking "Try to reset errors" and remain undone. UPD: It worked correctly in another browser. So maybe it just required clearing the cache.

And I suppose error #1 should not be that hard to reproduce. As it happens with every 200+ edits manual batch. For example, in https://editgroups.toolforge.org/b/QSv2T/1720448250160/ I had it triggered 6 times. Tried different batches on Chrome and Firefox, with and without VPN. No changes, it always happens at least once in ~100 edits (without fixed frequency - it could be three times in 30 edits, or could be 1 time in 200). Each time it was an instant response with a 502 error "Webservice is unreachable". And it is not marked with an error and retry is not done either, the queue just hangs.

I've just managed to reproduce the bug by repeating the same 100% completed batch - it still hangs and stops regularly. You could try running it as well: https://nopaste.net/egbIelbe9t

This seems to be caused by the webservice throwing 502 erros for some reason. I put an error mitigation in place, it will re-try 5 times with 2sec delay. Your example still throws 4 errors but they are of a different kind, and reset-able.

Thank you! Now the problem seems to be completely fixed. However, there is a small side effect that I have not seen before - it is rare errors occurring with the reason "Edit conflict. Could not patch the current revision." But they are handled by clicking "try to reset errors" at the end.

Hi Magnus, sorry to bother you, but I wanted to let you know that ListeriaBot is currently working inconsistently on the Hungarian Wikipedia. Based on the open issues on GitHub, it does not seem to be an isolated problem. Please see this page: although it should be updated daily, ListeriaBot fails most of the time. Unfortunately, I cannot tell you why this happens, as the bot status page does not work either. Would you mind taking a look? Thank you!

I know, working on it

Thank you!

https://www.wikidata.org/w/index.php?title=Q126361809&oldid=2172139452

Fixed

1. 2024-01-02 Topic:Xwhoclcgbbxoqste
2. 2024-01-06 Topic:Xws6eqithns3eo9m
3. 2024-02-07 Topic:Xyrhe7q69h2gxkno
4. 2024-06-28 Topic:Y7jy3mwvfis8jbny
5. 2024-06-29 Topic:Y7m62m1eyomucw7a

This should take care of the vast majotiry of cases.