Street name quest gives confusing option when name:etymology is specified on adjoining road

[arrival-spring]

Fairly rare occurrence, but I came across it today while using SC.

There was a road tagged with name and name:etymology:wikidata
A road adjoining this did not have a name (but should have had the same name).

When I went to answer the "What is the name of this street" quest it looked something like this (with en and etymology:wikidata filled in appropriately)

This looks quite confusing as the wikidata value is something like Q123456 (so looks nothing like a name).

I left it as default to see what would happen and when I got back I checked and saw that this had added name, name:en (same as name) and name:etymology:wikidata.

I think the quest should probably add etymology if the road name is identical, but perhaps without showing it to the user.
It should not add name:en (or whichever language code) if there's only one actual name (such as this case).

A look through the first few pages on taginfo when searching for name: shows up some things that should be checked for and treated differently:
name:etymology:wikidata (153700 uses)
name:etymology:wikipedia (27300 uses)
name:etymology (11,800 uses)
name:source (9800 uses) (likely a synonym for source:name, and would probably be better as that for reasons like this)
name:wikipedia (3800 uses)
name:adjective (3060 uses)
name:pronunciation (2850 uses)
name:etymology:description (2720 uses)

[westnordost]

Oh my god, whose idea was to invade on the name namespace like this?

The proper tag should have been wikidata:name:etymology...otherwise, things like this happen!

Oh well, thanks for the report, I will see what I can do

[matkoniecz]

The proper tag should have been wikidata:name:etymology...otherwise, things like this happen!

Or etymology:wikidata to fit other prefixed tags like brand:wikidata

[westnordost]

Can you please explain how you ended up with a view like this or provide the element with which it is reproducible?
The code doesn't look like it takes just any tag that starts with name:* to display it there.

[arrival-spring]

I should have specified that this is when you select one of the suggestions, I think it's coming from here.

[westnordost]

Ah, when selecting a suggestion. Thanks!

[westnordost]

Hmm, I misread the initial post a bit. I thought that name would be set on name=Q123456 or something like that.
So, this behavior:

I left it as default to see what would happen and when I got back I checked and saw that this had added name, name:en (same as name) and name:etymology:wikidata.

is okay. The wikidata of the etymology of the name is related to the name, so it can be copied over when applying a suggestion. Basically, the assumption that anything that follows the pattern name:.* is related to the name is even true for the examples you posted.
On the other hand, the current code assumes that anything that follows that pattern is an ISO 639-1 code (or similar, f.e. name:th-Latn=Krung Thep) and the interface is certainly built in a way that assumes that.

I think the quest should probably add etymology if the road name is identical, but perhaps without showing it to the user.
It should not add name:en (or whichever language code) if there's only one actual name (such as this case).

So, not so sure about that. Couldn't it have any negative consequences to copy tags without showing them?
For example, if the street has an alt_name, old_name, ref or other "name-like" attribute, it is currently neither shown nor copied.

[westnordost]

I think I will solve it his way:

• do neither show or copy any of name:* where * is not something like an ISO code
• do neither show or copy any "name-like" attribute like old_name, alt_name etc

Reason:

• The surveyor records with StreetComplete only on-site verifiable data, i.e. what's on the sign. A wikidata ID and all the other tags like that are not verifiable, so they are not copied over. Doesn't mean that it does not make sense to copy over, just not in StreetComplete.
• Many of the "name-like" attributes are not verifiable on-site (old name etc), and alt_name is rare enough that in this case people can just leave a note.

[1ec5]

Oh my god, whose idea was to invade on the name namespace like this?

I believe the idea was that name:etymology describes the etymology of the name in name, rather than the etymology of the feature itself. (There was a time when it was also unclear whether name:source or source:name would be better, but only names have etymologies, whereas lots of keys could have sources.)

In any case, I don’t think it’s particularly sound to assume that all subkeys of name are language codes. Other subkeys like name:left, name:forward, name:pronunciation, and name:genitive are quite common, and some are part of broader tagging schemes that affect other keys. If the quest needs to limit itself to only localized names, then it should assume an ISO 639 alpha-2 or alpha-3 language code, optionally followed by an ISO 15924 alpha-4 script code and/or ISO 3166-1 alpha-2 country code. In other words, look for a subkey that is less than four characters long (after truncating at the first hyphen).

[arrival-spring]

Ah, when selecting a suggestion. Thanks!

Sorry for forgetting to specify that in the original post.

• The surveyor records with StreetComplete only on-site verifiable data, i.e. what's on the sign. A wikidata ID and all the other tags like that are not verifiable, so they are not copied over. Doesn't mean that it does not make sense to copy over, just not in StreetComplete.

Those reasons make sense, I wasn't quite sure either way.
They're the sort of thing that are armchair mapped in the first place, so would be added again later if desired.

Other subkeys like name:left, name:forward, name:pronunciation, and name:genitive are quite common

Ah yes, I missed name:left and name:right in my scan of taginfo (both have ~28000 uses)
name:forward and name:backward only have ~280 uses each.

[1ec5]

name:forward and name:backward only have ~280 uses each.

That’s true. I mentioned them because they are supported by routers (at least OSRM if not others) for road names. Intuitively, I’d expect these keys to be somewhat rarer than the other subkeys because direction-dependent road names would be less common in reality than, say, etymologies, though probably still common enough to be special-cased.

There’s also a tagging scheme for clarifying dates of old names that uses an indefinite number of name subkeys instead of old_name. This scheme appears to be used on over 4,000 features worldwide.