For linked data, should help link to real wikidata instead of OSM wiki?

[bhousel]

This looks weird to me:

Maybe for the name/brand fields on a feature that's linked to wikidata, we should follow the wikidata link and get Starbucks's info, rather than show the OSM documentation.

[bhousel]

BTW, and offtopic, but "The primary tag used for naming an element." is not very beginner friendly.

[1ec5]

Is it weird because the prepopulated name looks like the thing being documented? I guess the documentation has always been misplaced from an information architecture standpoint. How wedded are we to this slide-in-below-the-field treatment, versus a help bubble or a row inserted right below the field’s header?

BTW, and offtopic, but "The primary tag used for naming an element." is not very beginner friendly.

Reworded the description.

[bhousel]

Showing the preset documentation looks even more funny:

[bhousel]

How wedded are we to this slide-in-below-the-field treatment, versus a help bubble or a row inserted right below the field’s header?

Not totally wedded, but this approach works mostly ok. It's useful that the space can show things of arbitrary length and with or without a picture.

[kymckay]

🤔 I think showing the brand information doesn't provide much value to a map editor (other than perhaps confirming it's the right brand of that name). However, I see your point that it's a little funny to provide information on a field the user can't interact with.

[1ec5]

How about placing the non-brand preset name, or the wikidata item’s label, in a header immediately above the documentation? That way at least it’s clear what the documentation refers to, even when it isn’t especially relevant.

[bhousel]

It's gotten worse.. check out this guy in the bowtie :

[bhousel]

We're looking these up from real wikidata now. Thanks for ruining my afternoon, bowtie dude. 😆
A few more things:

• Add proper sitelinks
• They don't work the first time, but they work after that. Need to figure out why.

[bhousel]

This was done!