Talk:Key:name
 Archives | |
|---|---|
| |
Note: Most discussion can now be found at Talk:Names, since the majority of page content was moved from Key:name -> Names
noname details
Perhaps when using noname=yes there should be a recommended way of explaining how you really know that it doesn't have a name. For instance adding a noname:details="I asked the owners and they said the pond doesn't have a name even though it's so large." Jidanni (talk) 14:26, 12 March 2023 (UTC)
- I would use
note=*or maybenote:noname=*ornoname:note=*(both variations can be found for note-subtags) --Dieterdreist (talk) 09:20, 14 March 2023 (UTC)
Clarification is required
There are constant debates in my neighborhood about what is a name. The most relevant question is: What if a(n only) visible sign on a shop is a general term in the local language? E.g. imagine a shop=hairdresser (+female=yes) object that has a sign over the entrance Hairdresser (in UK) or Coiffure (in French) or Damenfriseur (in Germany). Is this an unnamed hairdresser or not? --Kogutowicz Manó (talk) 07:33, 4 November 2023 (UTC)
- The "name" key specifies the proper name of the object. It names an individual object. "Hairdresser" is not a proper name, but a common name. It names a group of objects.--RobHubi (talk) 20:43, 19 December 2023 (UTC)
Clarification about capitalisation and spelling rules
Shouldn’t we also mention that even if a name is written in all caps (e.g. on a street sign) users should write name=* with the usual spelling rules in the local language/country? It seems obvious but once in a while we find users believing in good faith that names should be written in ALL-CAPS because this is how signs are printed on the field. Bxl-forever (talk) 19:18, 24 September 2024 (UTC)
- It is well covered in Names#Good practice.
- I'm not sure how to cross-reference that material from Key:name and related articles so that it gains more visibility.
- One possibility is to merge Names into Key:name, which is the principal tag of the whole group, but that could make the resulting article too long. I did something similar recently with Types of relations, merging them into Key:type. But then, we already have #Variants section duplicated between the two articles, so it might not be too bad after all.
- Another is to keep the articles separate, but transclude the same content in both, like I did with Isochrone (see List_of_OSM-based_services#Isochrone)
- Thoughts, anyone? Duja (talk) 08:25, 25 September 2024 (UTC)