Hi Magnus! I would like to ask you to deactivate this catalog that I created. It's no longer working. I will try to upload a new one today/tomorrow. Regards
Magnus Manske
Joined 30 October 2012
Hi! Could you create some sorte of settings page where a user can set a maximum number of batches running contemporarily and can opt-in an auto-reset of errors made by batches? These features would be very useful! Good night.
Another relevant problem: some weeks ago the functionality that allowed admins to stop other users' batches vanished. It would be important to restore it. Thanks!
Hi Magnus, any updates on these? Thanks!
Hi! In the last two days Mix'n'match has been unavailable (permanent "Loading...") for most hours; it reappears for few minutes and then disappears again without apparent reason. Could you have a look at the problem? Thanks as always!
Hi, that should be fixed now, please re-open if the issue persists.
Hi! Sorry for reopening this, but there are still some problems: when I try using links like https://mix-n-match.toolforge.org/?#/issues/WD_DUPLICATE/1824 no list loads and Mix'n'match becomes not reachable for some minutes. Similar links to WD_DUPLICATE work when the catalog has very few issues. Could you have a look? Anyway, not urgent. Bye!
Similar problem when I try using https://mix-n-match.toolforge.org/?#/issues/WD_DUPLICATE/1843: no list loads and Mix'n'match becomes not reachable for some hours.
Hi, could you please update the formatter URL for mix-n-match catalog #4744. It is currently: https://www.wtatennis.com/players/$1 but should be https://www.wtatennis.com/players/$1/-. Thanks.
Update also needed for https://mix-n-match.toolforge.org/#/catalog/652 (completely matched as of now); it should be https://www.hoc.gr/el/node/$1 and effectively it seems to be so when I hover over the link, but when I click it becomes https://www.hoc.grel/node/$1 (very strange). Thanks!
The link in the catalog is actually http, not https. They have a redirect on their site, but it's missing a /. So nothing strange, just a bogus untested setup at the HOC :)
So the present URL in MnM is http://www.hoc.gr/el/node/$1 and it should become https://www.hoc.gr/el/node/$1 in order to avoid the wrong redirect by HOC. Thanks @Nono314: for making me understand this!
Having thought about this a bit more, I think the simplest solution is to give catalog creators (and admins) the ability to purge all items from a catalog so they can re-scrape/re-upload them. Also, in the "Create a new web scraper/catalog" menu, if an existing catalog ID is entered, the menu would ideally auto-fill with the scraper settings last used, so any tweaks could be made easily when re-scraping rather than needing to start from scratch.
https://www.wikidata.org/w/index.php?title=Q130213400&oldid=2241335446 and Talk:Q130213400#Adding_GND_redirect
What is the cause? Can you adjust Mix'n'match to not do that?
https://www.wikidata.org/w/index.php?title=Q16276555&diff=1865622566&oldid=1713417259
Please don't do that.
Terrible!
Would it be possible for you to make three new catalog groups for Mix'n'Match? One for fictional entities and another one for fictional characters. And a third one dedicated to anime/manga
Can you give me an example for each group? I need to change at least one catalog manually to a new group so that the group name shows up as an option. Or create your catalogs with some other group and I can change them over manually later, no problem.
You can find the examples here
- Q89209418 (characters)
- Q101081817 (anime)
- Q101083593 (manga)
- Q66116613 (music tracks)
- Q80447536 (anime and manga characters)
Nvm the one about fictional entities
Currently, QuickStatements regularly skips placing redirects on the merged article. This is usually monitored by one of the bots that finishes the merge after QS after a while. But sometimes when someone makes a change to a merged item, it gets stuck forever as a lost dupe. This caused problems for over 150 items with categories after mass merges a few months ago: Topic:Ybqi6ey7h2627itn. I suppose QS should do the full merge, since this is what the documentation says Help:QuickStatements#Item_merging?
I ran the merge batch again in manual mode on the addressed items, and none of them merged again: And it seems that all the items still have uncleared descriptions in various languages.
UPD: Tried the same in the background mode with no result as well: https://quickstatements.toolforge.org/#/batch/237139
UPD2: DeltaBot finished all the merges, putting redirects on all of them
I seem to remember that problem, it was with the API merge function, which I call and that should do all of those.
As far as I can see the inbuilt merge gadget also works through the API, but I haven't encountered similar redirect problems with it. Are there any differences in the API calls between it and QS? Or should it still be reported to Phabricator as an API bug?
https://www.wikidata.org/w/index.php?title=Q112121858&diff=prev&oldid=2243321426
Created claim: WorldCat Identities ID (superseded) (P7859): lccn-no94005868, batch #237135 Tag: quickstatements [2.0]
But https://quickstatements.toolforge.org/#/batch/237135 doesn't list that item.
Maybe just the reference is false, since the edit itself could have been done by another batch around the same time.
- https://www.wikidata.org/w/index.php?title=Q127977525&oldid=2214704180
- https://www.wikidata.org/w/index.php?title=Q128009665&oldid=2214940652
Two errors found today, both by your tool
https://www.wikidata.org/w/index.php?title=Q130209857&oldid=2240759514
One format error found today and it was created by your tool.
Found and fixed the bug, hope it's the last one for ISNI (P213)