Topic on User talk:Matěj Suchánek

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.

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.

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.

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.

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.

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...

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?

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!

@Spinster I made some changes to prevent moving a statement to a property by mistake. Would you mind testing and let us know what you think about it ? you can use Wikidata Sandbox (Q4115189) and Sandbox-Property (P2368) for testing.

@Matěj Suchánek Ok I have restricted the confirmation step to properties only. I have just tested copying a statement to Lexeme:L123 and it worked flowlessly.

@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?

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

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.