Add more context to notes

[bbastin]

Use case
Some notes that users leave when unable to answer a quest are missing the context of the question, but users assume that this context is understood by other people. For example, when the quest asks whether a shops opening hours are still correct, users may assume that other people know which shop the question was asked for. Notes often look like this:

Unable to answer "Are these opening hours still correct?" for https://osm.org/node/<nodeid> via StreetComplete 55.1:

It is not there anymore.

This is problematic for objects that have changed since, for example if another user as already corrected the node without seeing the note. I know that I can always look at the object and its history and see which state it was in when the note was left, but this is a bit cumbersome.

Proposed Solution
If an object has a name, it would be helpful to include the name in the note automatically. There probably are other context clues one could include for different quests, but none come to mind right now.

Unable to answer "Are these opening hours still correct?" for "Shop A" (https://osm.org/node/<nodeid>) via StreetComplete 55.1:

It is not there anymore.

I think this could be helpful for all quests where the relevant object has a name. It would make the decision whether a note is still relevant a lot easier in those situations.

[Helium314]

Such quick checks were definitely easier when the name / type was part of the question and thus part of the note (random example: https://www.openstreetmap.org/note/2882773).
Though clicking the link and then on history isn't that hard either.

Maybe the information / hint below the question could be appended to show what the user saw.

[Helium314]

@westnordost I have two (minor) issues with this:

1. The label for streetname quest and address overlay is a little different (showHouseNumber), should this be considered?
2. Adding for $hintLabel results in Unable to answer <question> for <hint> for <element>, which is weird. Using Unable to answer <question> for <hint> (<element>) may have issues when extracting the link (GitHub does it right, but I fear ) is seen as part of the link in many cases)

[westnordost]

Option 2 sounds good,I guess one can just try out whether or not the link is generated correctly on osm

[bbastin]

Angle brackets are not allowed to be part of a URI and using them to delimit URIs is recommended by the relevant RFC 3986, this could solve this problem of incorrectly parsing links.