Field info-(i) should show data on the tag, not the key

[tordans]

When I have a surface field with a value added (just added) and click the info (i) icon, I get a description of the key, not the tag.

Instead, it should give me details on the tag, which would be https://wiki.openstreetmap.org/wiki/Tag:surface%3Dpaving_stones / https://wiki.openstreetmap.org/wiki/Item:Q16180

Update:

In the "Tags"-Area, the system is better:
It shows the tag data and only falls back to the key data when nothing else was found:

tags with fallback	only key

---

Suggestion

1. Use the same lookup for fields that is used now for the tags (first look at the tag, then fall back to the key)
2. For multi combo fields (semicolon separated), find some workaround. Eg. (a) only lookup the full tag, which will likely result in using the fallback key instead; (b) lookup the data per value-part (but only show the fallback once or only when no results where present); …

[1ec5]

I’m surprised we don’t have a preexisting issue about this. Value descriptions do appear as tooltips in the combo box’s dropdown menu (generally powered by taginfo I think). Documentation about the key is also useful to get a broader sense of what the field is for. If we show the value description instead, the user would need to clear the field just to access the key description.

What’s confusing is that the documentation slides in under the value as if that’s what it’s describing. The intention was probably to keep the text field from shifting, but I don’t think shifting it would be all that jarring.

[tordans]

…Value descriptions do appear as tooltips in the combo box’s dropdown menu (generally powered by taginfo I think).

That is something else, which we might want to improve in the future. The options object eg. in https://github.com/openstreetmap/id-tagging-schema/blob/61f5dffa6b0c281790d887aeff2696b6b83ca041/data/fields/cycleway.json#L18-L52 can have a hard coded description property that is handled by the id-tagging-schema data and translations.

Documentation about the key is also useful to get a broader sense of what the field is for. If we show the value description instead, the user would need to clear the field just to access the key description.

Assuming that tag info is needed at all. I don't think we need to show both. The tag description together with the field label and value should give enough indication to what it is about. And users that need to learn more can to that via the wiki link for the given tag.

What’s confusing is that the documentation slides in under the value as if that’s what it’s describing. The intention was probably to keep the text field from shifting, but I don’t think shifting it would be all that jarring.

I don't think breaking up the UI-element would make it better. I think the current system works quite well.

[1ec5]

That is something else, which we might want to improve in the future. The options object eg. in https://github.com/openstreetmap/id-tagging-schema/blob/61f5dffa6b0c281790d887aeff2696b6b83ca041/data/fields/cycleway.json#L18-L52 can have a hard coded description property that is handled by the id-tagging-schema data and translations.

In combo fields that don’t have these hardcoded strings, tooltips can also come from taginfo.

[tyrasd]

Documentation about the key is also useful to get a broader sense of what the field is for.

I think this was probably the reason why this was originally implemented to only show the "generic" field key reference. but I also think that showing the most precise info possible is better in practice: For empty fields (e.g. from a new object), the generic info is what you need (and get), and for an already filled-in field one would typically like to know what the currently filled in tag value means: if the description does not match what you see on the ground, one can then go ahead by clearing the field and by doing that is back at the previous situation of an empty field.

[tyrasd]

…Value descriptions do appear as tooltips in the combo box’s dropdown menu

In combo fields that don’t have these hardcoded strings, tooltips can also come from taginfo.

That is something else, which we might want to improve in the future.

Yeah, that sounds like something worth exploring. But it would be better to discuss this in a dedicated issue. 😉

[1ec5]

If we show the value description instead, the user would need to clear the field just to access the key description.

To clarify, I was thinking of the case where the field was already populated with some value, not a value that the user had already entered themselves. But I agree it’s a minor difference.