Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

name:etymology:wikidata disables all name fields #8870

Open
RudyTheDev opened this issue Jan 3, 2022 · 3 comments
Open

name:etymology:wikidata disables all name fields #8870

RudyTheDev opened this issue Jan 3, 2022 · 3 comments
Labels
question Not Actionable - just a question about something

Comments

@RudyTheDev
Copy link
Contributor

Having a name:etymology:wikidata= tag disables all name-based fields even though there is no primary wikidata tag, rather its name's etymology entity does. Probably caused by #6683 being too eager? Expecting only etymology field to be disabled (at least until openstreetmap/id-tagging-schema#256 is also separate).

Repro:

name=The 123
name:de=Das 123
name:etymology=123
name:etymology:wikidata=Q123

Etmy

@tyrasd tyrasd added the question Not Actionable - just a question about something label Jan 7, 2022
@tyrasd
Copy link
Member

tyrasd commented Jan 7, 2022

What would you expect in this case? If the name tag was not locked then one could accidentally change the name to something different (e.g. say, The 42), causing the etymology to not match the name anymore. In a perfect world the field would still be editable, but the name:etymology part would need to stay in there (e.g. you could change the above name to The mighty 123, but not to something not containing 123). But that would be very tricky to implement, and most likely not worth the effort if you ask me.

@RudyTheDev
Copy link
Contributor Author

Heya!

What would you expect in this case?

I expected the regular name fields to not be be grayed out, because they are not based on a Wikidata item; I expect (only) the etymology field to be grayed out, because it is based on a Wikidata item. Besides being confusing, I can think of various use cases, but they are all a variation of "cannot edit wrong name(s) field(s)":

The street name changes and keeps etymology. Say "123 street" to "123 avenue". Or it's a typo like "123 streat". The name field is locked.

The street name changes to different etymology. Say "123 street" to "456 street". The new wikidata value is set, but the name field is (still) locked.

The street name without etymology changes to now have a new name and etymology. Someone adds etymology tags before changing the name, but the name field is now locked.

Another language/translation name is wrong. The language's name field is locked.

Someone wants to add another language/translation. The "+" is locked.

Someone wants to delete incorrect language name. The trash can button is locked.

Multiple features are selected where some are missing a value set in others. Say one has "123 street"/"straad 123" but the other only "123 street". The second language's name field is locked.

@1ec5
Copy link
Collaborator

1ec5 commented Jan 7, 2022

openstreetmap/id-tagging-schema#256 would at least separate the etymology into a separate field, perhaps with a corresponding field for the etymology’s Wikidata QID, making the reason for locking a little more discoverable. Grouping the Wikidata fields with their non-Wikidata counterparts would help too: #8104.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Not Actionable - just a question about something
Projects
None yet
Development

No branches or pull requests

3 participants