I gave you an example above. A look at discussions about name tagging in South Tyrol (Trentino/Alto Adige) or bilingual Swiss cantons may provide additional information.
Each renderer who wants to display names as used by the local population would need its geographical database with information about the lingual situation for any point to be rendered. I as a renderer would expect this data from my geographical data provider, OSM in particular.
Removing name from features which do have a name (in multiple languages) would harm data consumers who just want the local name (however that is decided) or a guaranteed fallback for when a preferred set of languages doesn’t have a corresponding name:*.
Instead of omitting name because it is disputed, why not document that it is and give data consumers who care the option to decide based upon that information?
E.g.,:
place=ocean
name=Atlantic Ocean
name:en=Atlantic Ocean
name:ja=大西洋
name:status=global_fallback: en
Something like that. global_fallback cases would be rare, and mostly limited to things like continents and oceans.
Compound names, much more common, could then (optionally) do this:
place=country
name=België - Belgique - Belgien
name:nl=België
name:en=Belgium
name:fr=Belgique
name:de=Belgien
name:status=multilingual_compound: nl;fr;de
(Some might even have name:status=disputed like this islet, where name:status:note could then expand on the nature of the dispute for human consumption.)
That way the nature of disputed or complex name values can be codified, and data consumers can act on these if desired, including omitting them.
A suffix-key like this (not necessarily :status, a better name is probably possible) would work for any other name value as well, including alt_name or name:tok, or what have you.
Another benefit of having this information available, is that it enables data consumers to create their own compound name label using name:* and that list, but with a different separator, different ordering, or limited to some of the languages listed.
This discussion of documenting the list of local multilingual names for a feature is interesting, but is off-topic.
The proposal, and the problem I’m trying to solve is specifically about documenting the reason that the name tag is omitted.
Sorry, the use of “Baltic Sea” as an example in point 1.2 of section “Rationale” in the proposal was confusing me and still does. Is the proposal to keep the multilingual name tag and add noname=multiple_languages or to suppress it and add noname=multiple_languages instead?
It would mean omitting name is not necessary at all for the stated goals. Having name for named entities is a rather strong convention; not deviating from that benefits a lot of use cases. How is that off-topic?
Documenting the nature of a disputed or complex name means noname=yes can keep its meaning of marking the absence of a name; i.e. where something really does not have a name in reality.
I like the idea of tagging “There is no name tag because there are multiple languages”. However using noname=* key seems backwards. For (some) languages there is a name, so (to me) you can’t say it has no name.
I encountered a similar issue, when trying to tag that a river didn’t have a Wikipedia page. and used no:wikipedia=yes.
My suggested tag is missing:name:reason=multiple_languages, or name:missing:reason=multiple_languages.
I prefer missing:* to prevent people interpreting :missing as a language code. I like having :reason suffix, in case one wants to expand other details about the missing name tag.
You’re right, this was confusing and thanks for that feedback. The use of “Baltic Sea” as an example was intended to highlight one of the ways that the community has dealt with the issue of multilingual names. I am not proposing to change the community consensus on how Baltic Sea is named - I’m proposing to give an additional option for cases where no single name is appropriate.
For example, the countries that collectively border the Atlantic Ocean speak fifteen languages, which would likely exceed the character limit of name if the Baltic Sea scheme were used. The community consensus for Atlantic Ocean was to simply omit the name tag. However, this caused mappers to insert noname=yes to silence validators, which is wrong because Atlantic Ocean does have a name. There was no tagging scheme we could use to say “the community chose to omit the name tag because of multiple equally-valid languages.”
This proposal is not about what to tag the Atlantic Ocean or Baltic Sea, it’s about providing a tagging option in the case where the community decision is to omit the name tag.
I like where you are going with this. Are there any prior tagging schemes which use “missing” or “reason” that would suggest that those are the right keywords versus other potential synonyms?
For example, the countries that collectively border the Atlantic Ocean speak fifteen languages, which would likely exceed the character limit of
nameif the Baltic Sea scheme were used.
in the case of an ocean, it is also harder to justify why only the bordering countries should have a say, there will also be “valid” names in “second row” countries and in general, globally, in almost all languages there will be a name for the atlantic and pacific ocean.
[ZeLonewolf] ZeLonewolf
https://community.openstreetmap.org/u/zelonewolf Brian M Sperlongano
July 16Comment is requested on a proposal to introduce two tags to indicate the
reason why a name=* tag has been omitted from a feature:
Thank you for making the proposal. The suggestion makes sense, whether
with noname=disputed or any other new tag distinct from plain
noname=yes.
A nice side effect is that I have become aware of name:signed=no which
in turn allowed me to bring this recently discovered
way into a more
mainstream tagging.
This proposal could be expanded to include other languages too, e.g. noname:en=disputed to mean “There’s no one english language name because it’s not clear which that would be”.
But boy have I got the thread for you:
Both name:language=* and language:name=* were proposed for this purpose in 2017 and both were rejected. To the extent that name represents the local language, it can only be used for language-agnostic purposes, such as when a renderer wants to render the local name regardless of the language it’s in. Anything more becomes a guess, which is not something we really want to encourage data consumers to do with our data.
This is related to the existing practice of documenting the source of a name with source:name=*. The proposed noname=* values are more like placeholders, there to prevent a mapper from blithely setting noname=yes without understanding the nuance. The values also happen to be machine-readable, though I’m not sure that matters as much, since the audience for these values would be fellow mappers, not data consumers.
With respect to the proposal, the values noname=disputed and noname=multiple_languages could be a source of confusion among mappers. It sounds like a distinction between a real-world geopolitical dispute and a more project-specific goal of language neutrality. However, geopolitical disputes often involve or are even rooted in linguistic differences.
As a reminder, we got here because some mappers believe the name=* of a global feature must be a perfect name: neutral, universal, unambiguous. The parallel thread suggests, not unreasonably, that this is an unreasonable expectation:
In other words, these values are of no (or little) use for data consumers and won’t change anything for the renderer that wants to put a name on the Atlantic Ocean.
Thank you Amanda to bring this here.
It should lead us to a completely mainstream way of tagging, instead of focusing it on names only.
Dispute, lack of knowledge, lack of signage could actually raise on any key as mentioned upside.
Agreed.
I understand that the proposed values are explanatory, and don’t prevent mappers using the name:language namespace, but at first glance they do appear like troll tagging. “No name” because the feature has more than one name might confuse.
I also wonder what the proposal actually solves? Could this information not simply be stored with the note=* key? We could then also have a link to a discussion where a community decision was made. Or perhaps this would be better solved by having some sort of “disputed” tagging scheme (e.g. improving the boundary=disputed tagging, perhaps a dispute namespace?).
If this is mostly to prevent validators throwing a warning, then validators should (if they don’t already) understand that name:en + name:es (for example) means that name is not required.
I’d also note that the key doesn’t match the syntax convention for keys. It should be no_name=*. However, I appreciate noname=yes is already de facto usage so I doubt there’s appetite to change that.
Hi
Two different visions oppose here: note=* would be on human readable only side, while a more robust and defined tagging would allow both human readability and machine usability.
To me the second brings more value.
Furthermore, note=* could be overcrowded with all potential reasons to not define several keys, not only name=*
Sounds like an additional reason to not make it reviewed/approved here, despite the capital experience it brought to the community until now.
No, what I meant is that the specific nomenclature doesn’t make a difference for data consumers, which wouldn’t be using the values directly. But the fact that noname would not be set to yes would address the Atlantic Ocean issue. Still, I’m not 100% convinced this is the best way to address that issue; if we can agree on a name, that would be simpler all around and avoid any surprises with tools that have been treating any noname=* as being unnamed.
The difficulty of satisfying these constraints isn’t limited to international waters. As someone on a non-OSM Discord server recently discovered, OSM Americana’s secret multilingual mode includes a “Europe” almost as big as Europe. 
