Wikidata tag silently removed together with wikipedia tag

[matkoniecz]

current behavior: wikidata tag is silently removed as wikipedia tag is removed

I was editing https://www.openstreetmap.org/node/3009690700/history and I deleted in https://www.openstreetmap.org/changeset/51834441#map=19/49.28167/19.93222 wikipedia tag because article was gone.

wikidata entry continues to exists (see https://www.wikidata.org/wiki/Q9182533?uselang=pl )

proposed behavior: delete only wikipedia tag and make wikidata tag visible to user or ask user whatever wikidata tag also should be removed

[bhousel]

This relates to #3929 - I agree that we should make the wikidata more visible.

However I do still think that removing the wikidata tag when the user edits the wikipedia field is the right thing to do. Users would not be able to look at a lone wikidata value and know whether it's correct or not.

[bhousel]

By the way, "data loss caused by iD" is not a very nice way to start out describing your issue. I know you don't mean it in a bad way, but let's be honest about talking about a feature that is working as intended and maybe needs a slight adjustment.

You might also be interested to know that OSMCha flagged your edit as suspicious because you edited a place name and wiki tags were deleted: https://osmcha.mapbox.com/changesets/51834441/

So I don't really worry too much about this kind of data loss because it's caught very easily by review tools.

[matkoniecz]

I know you don't mean it in a bad way, but let's be honest about talking about a feature that is working as intended and maybe needs a slight adjustment.

Maybe there is no better way to do that. I know that normal editor will be highly confused by some wikidata gibberish, properly displaying it would require API call to wikidata to translate identifier into usable label (and doing that without DDoSing Wikidata servers may be tricky).

But I made edit with goal of removing solely wikipedia tag and iD decided to delete more than I wanted, so I think that "data loss caused by iD" is justified.

[HolgerJeromin]

But moved from separate issue:

Element has only wikidata entry. I try to add the corresponding wikipedia. The is no help from the editor, but this is another story.
Situation is this (osm) and I click on this drop down menu:

The drop down menu has no useful entry so I click away. Or we have a focusout because i switch browser window (to fill this issue :-)
Drop down menu closes => no wikipedia entry added, but wikidata is removed, too!

[ecatmur]

Users would not be able to look at a lone wikidata value and know whether it's correct or not.

It's pretty easy to confirm whether a wikidata tag is correct - click through to the wikidata page and check whether the address, coordinates etc match, whether any photograph corresponds to the survey, whether other metadata (name, website) matches. I don't think this is a good reason to remove the wikidata tag.

And wikidata has plenty of entries that aren't notable enough for a wikipedia page.

[bhousel]

Users would not be able to look at a lone wikidata value and know whether it's correct or not.

It's pretty easy to confirm whether a wikidata tag is correct - click through to the wikidata page and check whether the address, coordinates etc match, whether any photograph corresponds to the survey,

Ok - users don't even have to click anymore because we show the wikidata label and description in a dedicated field now (see @HolgerJeromin's screenshot from yesterday) - it wasn't the case back in 2017 when this issue was opened.

The situation now is that we should just have a single field that looks up all the wiki tags and doesn't silently remove tags.

[quincylvania]

I did #5544 (search Wikidata directly) and #5543 (update wikipedia tag when setting Wikidata). As a result, the Wikidata field feels more like the primary wiki field. So we probably shouldn't let the Wikipedia field remove the Wikidata tag anymore.

[eehpcm]

I don't know if your fixes have address this, but I have a similar issue to @HolgerJeromin. Similar, but not entirely identical.

I wanted to add Wikidata and Wikipedia to the Welsh hamlet Blaenannerch, which had neither. I added the Wikidata ID. I then wanted to add the Wikipedia page. The only Wikipedia page (other than a stub in Brazilian Portuguese) is in Welsh. So I changed the language to Cymraeg, at which point the Wikipedia field vanished and the Wikidata iD was deleted.

The workaround is to add the Wikipedia page first. At which point the Wikidata entry magically re-appeared (I don't know if it would autofill if I did it that way with something else where I hadn't first tried the Wikidata/Wikipedia sequence).

[quincylvania]

@eehpcm Removing the Wikipedia field value no longer removes the wikidata tag, but they do update each other when setting the values. This change isn't released yet but you can test it on http://preview.ideditor.com/master.

[eehpcm]

@quincylvania

Removing the Wikipedia field value no longer removes the wikidata tag,

Not quite the problem I reported. I was starting with something that had neither Wikidata nor Wikipedia tags.

This change isn't released yet but you can test it on http://preview.ideditor.com/master.

I just tried it and it also fixes the problem I reported. But I noticed two other problems.

On entering the Wikidata ID, if I use tab to complete it then it vanishes. I use tab-completion a lot, and it's a hard habit to break. If I try to use return to complete it, nothing happens. I have to click on the drop-down menu list of one item. It would be nice if keyboard tab/return completion worked.

When I try to select the Wikipedia language, the default of English isn't highlighted. So I can't just type "cy" to get Cymraeg, I either have to scroll through a long menu drop-down (which would be tedious for people who wanted, say, Türkmençe) or I have to manually delete "English" so I can type "cy". I think I can remember, several releases ago (I don't know exactly when it changed), that I could just click in the language field and type to over-ride the default of English. If I'm mis-remembering, and it was never possible to do that, it would still be nice if that were possible.

[matkoniecz]

But I noticed two other problems.

In general it is better to create a new issues for new problems (if issue is not yet existing)

[eehpcm]

@matkoniecz

In general it is better to create a new issues for new problems (if issue is not yet existing)

In general, yeah. But these problems are part of the same code. And earlier in the thread @bhousel merged related issues here.

I'm reminded of a definition of Calvinism: "You can and you can't, you will and you won't, you'll be damned if you do, you'll be damned if you don't." I expect somebody else would have complained if I'd raised it as a separate issue. Damned if I do, damned if I don't. :)

[quincylvania]

@eehpcm This issue focused on a specific change in behavior that was addressed, and so was closed. Closed issues aren't considered actionable, so if you're seeing a bug or think something should be changed then please open a new issue. In this repo we often spin off related tasks into separate issues to keep things manageable. Thanks for your thoughtfulness though!