User talk:Matěj Suchánek

Jump to navigation Jump to search

About this board

Check Property talk:P214/Duplicates

4
Epìdosis (talkcontribs)

Hi! The Listeria-query in Property talk:P214/Duplicates seems not working anymore (ListeriaBot, when invoked, says "No items"). Could you check it? It was a very useful page! Thank you very much in advance!

Epìdosis (talkcontribs)
Epìdosis (talkcontribs)

Now fixed: the query went in timeout and in any case it seems that it is now impossible to show more than 8000 results in a page, so I've set a prudent LIMIT 7500. Now the bot seems working.

Epìdosis (talkcontribs)

Not so easy: the problem seems clearly connected to dimension, but LIMIT 7500 was ineffective; I tried with 5000 and 1000, nothing. So I created Property talk:P214/Duplicates/humans and using 500 it worked well. I leave LIMIT 7500 in the main list hoping it will work in the future. If you have suggestions, obviously they are welcome - so I leave this thread open :) Bye!

Reply to "Check Property talk:P214/Duplicates"
Kusurija (talkcontribs)

Nejde vložit u Bohumil Bouček ani lt:wikt:Kategorija:字 skaitomas kaip めぐむ spojit s cs:wikt:Kategorie:Obsahuje 字 čtené jako めぐむ(Invalid CSRF token.) (a mnoho dalších)

Matěj Suchánek (talkcontribs)

Obě vyřešeny. Pradvěpodobně nějaký dočasný problém (obvykle stačí odhlásit/přihlásit). Viz též w:cs:CSRF.

Reply to "czeski lekarz"
Melderick (talkcontribs)

Hi Matěj

Volonteers have been testing the new version of moveClaims for a few months now. I only got positive feedback so I think you can merge it with your version whenever you have some free time.

Feel free to contact me for any support.

Melderick (talkcontribs)

Hi again, 2 persons mentioned that they used the wrong tab to move a statement from an item to a property (instead of moving it to another property of the same item).

I didn't know that the original code could do that. I have added a quick check in performMove and generate an error (differenttype) if oldentity and newentity don't start with the same letter. If you think moving to a different type is an interesting feature to keep, we could create a popup asking to confirm the move/copy.

Matěj Suchánek (talkcontribs)

Yes, this was intentional. Lexeme support, for example, was a goal. I don't believe it's a good idea to except properties just because of wrong input.

Feel free to work on this further, I'm not sure when I'll be available to update it.

Melderick (talkcontribs)

Hmm then how about having a warning and request a confirmation when you try to move a statement from :

Q1 to P1

L1 to P1

(Eventually P1 to Q1 or L1)


From what you said we want to keep moving from Q1 to L1, right ?

Another suggestions was to use a different color scheme for each tab to alert them but I am not a big fan of this.

Matěj Suchánek (talkcontribs)

Having reconsidered, I think the warning is a good idea. Although moving claims from an item/lexeme to a property should be possible, I suppose it's very rare.

Melderick (talkcontribs)

Hi Matěj, I finally found a way to manage the confirmation.

So, when you press Move/Copy to another entity, it checks that both entities are of the same type (meaning : both starts with the same letter). When it's not the case, it prints :

The current entity $1 and the new entity $2 has to be of the same type. Use the above checkbox to override this control.

And a new checkbox appears : Allow type mismatch:

Now, if you check it and press Move/Copy again, it will accept to do it.

If you press Move/Copy with the checkbox unchecked it will print the same message again.

Of course, every time you open the dialog, the checkbox is unchecked and hidden.


What do you think ?

Now that I have read our past discussion, I wonder if all this control should not be made only if the new entity is a property ? Allowing a flowless copy/move between an item and a lexeme...

Matěj Suchánek (talkcontribs)

Hi, thanks for continuing work on this. I wouldn't block moving to lexemes, I believe Lids are not ambiguous. Unlike Pids which has been confused recently. (@Spinster: As you did that mistake, would you find this feature useful?)

@Jura1: You have recently moved content to Property:P8150, what do you think?

Spinster (talkcontribs)

Hello @Matěj Suchánek - yes, I was confused because I thought I was moving a statement from one property to another in the same Wikidata item. If that is a feature you are thinking about: that would indeed be very useful (especially for statements with references which would be tedious to swap to another property in the same item). Thanks for all the work you do!

Melderick (talkcontribs)
Spinster (talkcontribs)

@Melderick Thanks, I just did some tests in the sandbox indeed. The modification is great, thank you - it has indeed prevented me from making that mistake. I think, however, that I found a bug (at least when editing in the sandbox): when I attempt to move a claim from one property to another in the same item right after creating that claim, it gives me the error message 'There was an error editing the entity: no-such-entity' - but when I reload the item, it works fine. Or is this intentional?

Melderick (talkcontribs)

@Spinster hmm I have tried to move a newly created claim and I got no error. Can you reproduce the bug ?

Jura1 (talkcontribs)

It's rather rare that I move claims from items to properties, but I wouldn't exclude it entirely.

What should be possible is to move between the base lexeme, lexeme-forms, and lexeme-senses; or even from items there.

Reply to "moveClaims"

Auto-copying page names as month item labels

5
Deryck Chan (talkcontribs)

e.g.

Is there any chance MatSuBot may be configured so that it doesn't copy the "Portal:時人時事/" ("Portal:Current events/") part of the page name when handling month items?

Matěj Suchánek (talkcontribs)

Hi, sorry. I will make sure the bot doesn't do this anymore.

Deryck Chan (talkcontribs)

Thank you Matej. If it helps, the format string for month item labels, for all Gregorian month items, in zh (all variants), yue, and ja are all "Y年M月", e.g. "2020年5月" (May 2020), "1989年12月" (December 1989).

Matěj Suchánek (talkcontribs)

Thanks for the hint. Since my bot won't overwrite any label, this query can be used for prefilling missing / fixing wrong labels.

Deryck Chan (talkcontribs)

Thanks, that's helpful. I had to do one language at a time and take out the OPTIONAL to make it work, so that the query only returns items with wrong labels, and not items without labels.

Reply to "Auto-copying page names as month item labels"
Vanbasten 23 (talkcontribs)

About this edition thank you very much. I was thinking about to program this, and now i see that you did it, perfect!!! Thanks!!!

Matěj Suchánek (talkcontribs)

Yeah, you are welcome. In fact, I had made the bot quite some time ago but the query it used began timing out, so I had to find some time and optimize it (with some compromises).

Reply to "Dates"
Herzi Pinki (talkcontribs)

Hi, stumbled across your import from de:WP: from (the current version at the time of import). Coordinates differ, it is unclear to me, why. As the decimal values are identical. Might be caused by different precisions, see also https://phabricator.wikimedia.org/T250627 Just to get your support on the phab-ticket.

Matěj Suchánek (talkcontribs)

Hi, the precision is determined by Pywikibot, specifically this method. As for the bug report, you've got the point that the looks strange but I cannot help with debugging now.

Reply to "unclear import of coordinates"

Need a means to create edition from File:

4
Billinghurst (talkcontribs)

I tried to cheat to create an edition using the WEF framework tool from Commons from the file, with the intention to delete the File: link after completion, though was rightfully defeated by AF/37. It would be really useful if there was a means to create the item from the file and leave the c: ink empty, and then I can reverse inhale the Q-item into the book template, or in the situation of a book item at Commons, just then delete the c: link.


Billinghurst (talkcontribs)

Even the ability to create an inhaleable file. I find it totally annoying to have to flick back and forth between screens and add fields one by one, whereas WEF allows a one-off push. Works well from elsewhere, though cannot do it natively from Commons.

Here I wanted to create the data file first as there will be nothing at enWS for a while until the transcription is done, and there won't ever be the work at enWP. So the first step introduction of a work to WMF wikis is inhibited.

Matěj Suchánek (talkcontribs)

Hi, sorry to hear that. My first thought was if WEF could be told not to add links to file but export the rest. If not, what do you suggest? An exception for new items if exported using WEF from Commons?

Billinghurst (talkcontribs)

WEF has an import function, though I haven't found any specs for its use. We already leverage the book template to import into the fields at our Index: ns through the script s:en:MediaWiki:Gadget-Fill_Index.js which leverages the same script frWS s:fr:MediaWiki:Gadget-Fill_Index.js.

Maybe it is better to create a pull mechanism at this end where {{book}} is used. All out of my pay scale, I just know that there has to be a better way.

Reply to "Need a means to create edition from File:"
Jura1 (talkcontribs)
Matěj Suchánek (talkcontribs)

The filter is supposed to catch descriptions identical to labels. But the detection for new items was created when items were created from scratch, not in a single edit. (The filter really is hackish.) I will fix this.

There is also Special:AbuseFilter/74 which we already talked about.

Jura1 (talkcontribs)

Thanks for looking into filter 64.

Indeed, I had in mind that other filter (74) we already talked about.

Reply to "filter 64"
Jura1 (talkcontribs)

I wonder if we should have a warning filter for edits like this:

Matěj Suchánek (talkcontribs)

There isn't much information the filter would use to identify those: Special:AbuseFilter/examine/1182552819. Except for the edit summary and the amount of removed data. quarry:query/42666 shows this would also catch some maintenance, mass-edits and edits using moveClaims. (Moreover, edit_delta look different in the logs, doesn't it?)

Jura1 (talkcontribs)

Indeed not really great. Maybe:

  • page_namespace: 0
  • edit_delta: > 200
  • user_editcount: < 20000
  • summary: wbremoveclaims-remove:1 , but no tool (#)
  • removed_lines: .*P248 .+P248 .+ (for two stated in (P248))
  • page_age: > 86400
Matěj Suchánek (talkcontribs)
Reply to "referenced statements deletion"
Jura1 (talkcontribs)

seems this went through

Matěj Suchánek (talkcontribs)

We didn't catch removals. Fixed.

Reply to "filter 101"