Wikidata field

[quincylvania]

Edit: Closes #4382. See: #5500 (comment)

This is a first step toward #4382, though it doesn't fulfill that issue's specific task. It adds a field for editing the wikidata tag and includes a button linking to the item's page on https://wikidata.org.

While casual mappers are unlikely to add Wikidata IDs separate from Wikipedia pages, this field is useful since it shows users if a value is present and lets them quickly open the Wikidata page. Having this as a separate field makes for a simpler interface, especially should more functionality be added to either field in the future (such as loading Wikidata values right in iD).

To maintain a sensible order, the Wikidata field is made to directly follow the Wikipedia field if both are present.

[1ec5]

Thanks for getting the ball rolling on #4382!

Do you plan to include functionality to “pretty-print” the Wikidata field (such as displaying the label) as part of this PR or leave it for later as tail work? If we merge the field without any pretty-printing, note that many existing features will show the QID, which most users will find a bit inscrutable.

It looks like changing the Wikipedia field will automatically update the Wikidata field, just as it updates the wikidata tag on master. Will setting the Wikidata field similarly set the Wikipedia field, if applicable? The same MediaWiki API call that fetches a Wikidata item’s Wikipedia sitelink could easily include the item’s label and description, allowing us to kill two birds with one stone.

[quincylvania]

@1ec5 Thanks for the feedback! I'll look into fetching/displaying the basic Wiki meta and auto-updating the Wikipedia tag.

While I agree that only displaying the ID could be confusing, I think the benefit of the "open Wikidata page" button makes the field worth adding it as-is. Right now the ID is still visible in the raw tags editor with little indication of what it means, so it would help to have the button. That said, I'm also fine with holding off if that's what others prefer 🤷‍♂️

[1ec5]

I agree that making the Wikidata tag more visible is a good move, even if there are rough edges for the moment. I’d personally be OK with the field’s presentation as it stands, but my familiarity with Wikidata makes me biased in that regard. 😉

It looks like the existing Wikidata service (for converting a Wikipedia article title to a QID) already makes a wbgetentities call from the MediaWiki API:

iD/modules/services/wikidata.js

Lines 23 to 30 in 107f669

	d3_json(endpoint + utilQsString({
	action: 'wbgetentities',
	format: 'json',
	sites: lang.replace(/-/g, '_') + 'wiki',
	titles: title,
	languages: 'en', // shrink response by filtering to one language
	origin: '*'
	}), function(err, data) {

Here’s an API call that should be suitable for converting a QID to a Wikipedia article title (via props=sitelinks) and displaying a label and short description (via props=labels|descriptions). The response is kind of large, so the sitefilter parameter might be useful as well. I think this would be just for display purposes, since using claims and such in tags would touch on the broader discussion in #4382.

[quincylvania]

I've updated the field so that the label and description are fetched and displayed, and as such this PR now closes #4382. Details:

• If the data is not available, the UI is not displayed.
• The label and description are requested for the user's language. If this language is not available, it falls back to a language that is. This does mean that different users may see different results.
• Clicking the button next to each Wikidata value selects the text and copies it to the clipboard. Users can then manually paste it into a tag if desired. This is a half-step toward mapping Wikidata values to OSM tags.
• The query runs every time the field UI is loaded or the value is updated. This could be optimized in the future, but the results are so small that I think it's okay for now.

@1ec5 I've decided not to automatically update the wikipedia tag when the user changes the Wikidata field since I couldn't think of a great way to determine the preferred article language. We don't want to be guessing and have the wikipedia tag for Tulsa link to the Chinese-language article, for example.

[bhousel]

awesome attention to detail here 😍

[quincylvania]

Thanks!

[bhousel]

Nice, this is great @quincylvania 👍 Happy to merge it like this and then we can think about if we want it to do more of the other #4382 stuff later..

[quincylvania]

we can think about if we want it to do more of the other #4382 stuff later..

Sounds good. The discussion in #4382 did spiral beyond the initial scope of the issue, so it makes sense to create separate issues for the parts of it we may want to tackle.

[1ec5]

Thanks again for this feature! Not only does it make the Wikidata feature feel less sneaky, but it also helps the mapper verify their Wikipedia article selection on the spot.

I've decided not to automatically update the wikipedia tag when the user changes the Wikidata field since I couldn't think of a great way to determine the preferred article language. We don't want to be guessing and have the wikipedia tag for Tulsa link to the Chinese-language article, for example.

That sounds like a bad situation at a glance. But as long as we make an effort to preserve the existing language, I think the need to keep the two tags in sync would outweigh the awkwardness of a foreign Wikipedia article title in some edge cases. So in this example with the Chinese speaker, either we’d end up with an English article title as expected, or we’d end up with a Chinese article title because Wikipedia has an article about Tulsa in Chinese but not in English, the local language. I opened #5543 to track keeping the tags in sync.