User talk:Magnus Manske

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

Listeria bot is currently not working after working very well for a week. Thanks.

Listeria Bot is currently not updating since yesterday morning. Thanks.

Listeria Bot is currently not working, Thanks.

The bot is not working again. Thanks.

Sorry, that's me above.

The bot is currently not working. Thanks.

The bot is currently not working. Thanks.

LIsteria bot is not working again, since two days ago. Thanks,

Listeria bot is currently not working. Thanks.

Listeria Bot is currently not working. Thanks.

Listeria Bot is currently not working. Thanks.

Listeria Bot is currently not working. Thanks.

Listeria Bot is currently not working. Thanks.

Listeria Bot is currently not working. Thanks.

Hi. Could you please add success/failure messages to the catalog aliases page ( https://mix-n-match.toolforge.org/#/aliases/1 )? Because it is not visually displayed in any way, and you can only track it in the http responses - when an "OK" response is received. With large batches, this can take more than a minute, when you start thinking about a timeout or some other error, and it is not always practical to keep track of the responses.

I have encountered a few entries that did not add themselves to the Wikidata entries after connecting the QID:

https://mix-n-match.toolforge.org/?#/entry/71058566

https://mix-n-match.toolforge.org/?#/entry/166575937

https://mix-n-match.toolforge.org/?#/entry/166575949

https://mix-n-match.toolforge.org/?#/entry/166575963

The edits are visible here: https://mix-n-match.toolforge.org/#/rc but my Contributions do not show any of these: Special:Contributions/DetriaSkies

I have done a good amount of matches over the past month over discovering the service and I worry there are more unsynced matches that flew under my radar.

This sometimes happens:

• you might have lost the oauth login for Mix'n'match (cookie "timeout"). Force-reload the MnM page and see if you are still logged in
• if you run QuickStatements (browser or background) at the same time, it also edits as "you". The MnM edit might trigger some bulk edit threshold.

I am still logged in upon force reloading.

Hi - I've just been spending many hours dealing with another few hundred duplicate-authors actions; this tool is *really* not ready for prime time. Latest example: https://www.wikidata.org/w/index.php?title=Q4757048&diff=2133123022&oldid=2118661421 - how can you merge "Andrew G. White" and "Alex White"? There have been far too many similar merges like this that I've had to revert - and I'm concerned that somebody's going to go in again and re-merge them if the tool is recommending this. Also I'm finding many cases of incorrect merges where the issue is likely that the wrong person was assigned to a paper by the other author in Wikidata, so your tool thinks they're the same person because of that. I had a case yesterday where a political scientist with the same name as a biochemist was set as the author of some biochemistry papers, and your tool then was used to merge them. What actually would have been useful in a case like that was to point out that those biochem papers had been likely assigned to the wrong person as author. Can you adjust your tool to do that? In any case until some significant fixes are in place this needs to be turned off ASAP.

By the way part of the problem (including the political scientist one) is that ORCID sometimes has these bad author assignments - some of the data in ORCID comes from services like Scopus that can be mistaken on things like this.

Another common issue I'm seeing is two different authors with the same family name and same first initial co-authoring a paper. This often happens with husband-wife teams; also other family relationships can result in paper co-authoring, and even just being from the same region of the world area two individuals may be likely to share a surname. Your duplicate authors game will always try to merge these cases, because of course being co-authors on a paper means they are both co-authors with the other authors on that paper. Instead I think it should catch cases like this as a sign that they *are not* the same person. Having both wikidata id's as co-authors on the same work should be an indicator that they are distinct, not the same. I know there are exceptions where real duplicates exist, but at the least it should be handled differently from other cases where they are never co-authors.

Dear Magnus,

can we please just *turn this off* for new users? I just spent a couple of hours reviewing this user's edits - a totally new Wikidata user, making 57 merges with the "distributed game - duplicate authors", of which I had to revert 27 (i.e. 53% good, 47% bad merges). So many of these merges were obviously wrong - completely different given names etc. Some were subtle. None should have been done by a completely fresh wikidata user. How do new users even run into this? In any case, merging should not be treated as a game like this. Bad merges have severe knock-on effects, and if there's a data problem causing your game to think two people should be merged, a good portion of the time merging is not the right solution.

Hi Magnus,

I'm developing a game for The Distributed Game, I've been showing it to some people on test mode but today I noticed it's been added twice to the list of games (probably somebody clicked by mistake). Could I ask you to delete it whenever you have some time? It's games 91 and 92 (per their ID on the URL). They are both called "Montevideo street names" and both have the "test" image as logo. I'm planning to add the game properly soon but I still need to fix a couple of things first.

Thanks, and good job with the platform. BTW, would you be interested on PRs for some fixes? I've noticed the layout breaks on mobile when the labels on the buttons are too big.

Hey Magnus, every so often I run into QuickStatements trying to add qualifiers or references to statements created in the same batch too quickly/parallelly resulting in an error (the base statement was not found). I would assume Special:Diff/2158793861 is a special case of that issue but without any error messages (I noticed it by accident) hence a bit more worrying. QS basically added the qualifier but removed it while adding the reference.

Hi Magnus! If you have time, can you please deactivate these two (, ) Mix'n'Match catalogs I created? Unfortunately something went wrong (with this catalog I don't quite sure why since everything seemed to be fine in the preview, although according to the description "error: repetition quantifier expects a valid decimal" the problem is in the regex) and they are both not working correctly. As soon as they are disabled I plan to re-create them but in a working (hopefully) state. Regards

Both deactivated

Mix'n'match [1.0] inserts ISNI in spaced format, example: 2024-02-02 https://www.wikidata.org/w/index.php?title=Q124408545&oldid=2067027790

2024-02-14 behaviour persisting https://www.wikidata.org/w/index.php?title=Q124527901&oldid=2076914287

@Anvilaquarius: 2024-02-14 you created

1. https://www.wikidata.org/w/index.php?title=Q124536572&action=history
2. https://www.wikidata.org/w/index.php?title=Q124537285&action=history

Can you confirm that the spaced format of the ISNI, which causes constraint violations, came from mix-n-match?

Yes, it came from Mix-n-match. I try to correct them, but maybe I forget it sometimes. --Anvilaquarius (talk) 10:27, 20 February 2024 (UTC)

Thank you. @Magnus Manske: It would be helpful if you could fix the problem at the source, by removing the spaces in any P213 stored there.

I have cleaned up non-standard ISNIs in Mix'n'match, but I don't have a good mechanism to prevent them from being added for new entries

By new entries, do you mean new entries in Mix'n'match, created after the clean-up?

yes.

Left a note at Talk:Q28054658#ISNI format and linked that from Help:P213.

@Magnus Manske: https://www.wikidata.org/w/index.php?title=User:DeltaBot/fixClaims/maintenance/P213format&oldid=2085273963 14 items, each spaced ISNI from mix-n-match and inserted by Reinheitsgebot with the comment "Created a new Item: #quickstatements; details; invoked by mixnmatch:CreateNewItemsFromCatalogWithNoSearchResults from catalog 6218"; "details" links to https://editgroups.toolforge.org/b/CB/65d8e8ee10f12969781889/

2024-02-24 new item from mix-n-match containing spaced ISNI and non-spaced ISNI https://www.wikidata.org/w/index.php?title=Q124653772&oldid=2086098294

2024-03-01 new item from mix-n-match containing spaced ISNI and non-spaced ISNI https://www.wikidata.org/w/index.php?title=Q124708468&oldid=2090941453#P213 @Epìdosis, Bargioni: this is from a catalog from Italy, can you see what is actually store there? It seems to have been imported before "User:Magnus Manske: "I have cleaned up non-standard ISNIs in Mix'n'match".

ISNI is stored without spaces in identificativo SBN di un autore (P396). But as of now it seems that the catalogue of MnM has both the forms with and without spaces in the auxiliary data; the first should be removed.

@Magnus Manske: can you have a look why 2024-02-24 and 2024-03-01 new items created contained "spaced ISNI and non-spaced ISNI"?

Hi Magnus, in https://mix-n-match.toolforge.org/#/catalog/5076 the auxiliary data still contain identificativo ISNI (P213) both with and without spaces; the form with spaces should be removed to avoid format-constraint violations. Thanks in advance!

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

Hello, I have imported mixnmatch:6299 and mixnmatch:6300 for Archnet site ID (P7323) and Archnet authority IDs (which don't have a property yet) using the import form. Both ended up having 0 IDs though the example entries in the preview looked fine. Do you have an idea what might have gone wrong? Thanks a lot in advance for any help or recommendations!

I manually ran an update, should be all there now.

Vielen tausend Dank!