<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 15, 2022 at 7:47 PM Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>> wrote:</div><div dir="ltr" class="gmail_attr"> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I can see that Mateusz has expanded this section a lot in 2021, adding <br>
examples why he thinks that the name:xx duplication makes sense. It was, <br>
however, an otherwise unremarkable edit by ZeLoneWolf on 09 November <br>
2021 that changed the "do not delete duplication" to "duplication should <br>
be created":<br>
<br>
<a href="https://wiki.openstreetmap.org/w/index.php?title=Names&type=revision&diff=2217092&oldid=2217080" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/w/index.php?title=Names&type=revision&diff=2217092&oldid=2217080</a><br>
<br>
I don't know if this was by accident or on purpose, but I find it a <br>
rather big change in meaning. Driven to the extreme, it would mean that <br>
every single one of the tens of thousands of place names in Germany <br>
should be amended with a name:de=<whatever is in the name tag>.</blockquote><div><br></div><div>Yes, this was deliberate and followed a mailing list discussion on this topic which I'm surprised you missed. However the rationale you described for why this duplication is needed was not correctly stated. Initially I also argued your view that this is purely redundant until Mateusz pointed out why duplicating the local language name tag is needed in cases where multiple languages are tagged on a name. If I recall correctly, this discussion followed a series of edits in which an editor was adding name:en tags to cities in the US.</div><div><br></div><div>Suppose you are a speaker of German, but you also speak English as a second language. You might wish to render a map that displays name labels using the following rule: "Render a German-language name if available, if not, render the English-language name, and if neither is available, render the local language name". Thus, we would want to render the label for Munich "München", which of course is the local German name.</div><div><br></div><div>Munich is currently tagged as follows:</div><div><br></div><div>name=München</div><div>name:en=Munch</div><div><br></div><div>Applying our language rules, we would find no name:de tag, and fall back instead to the name:en tag of "Munich", thus rendering the "wrong" language label. There is no way to infer from OSM tagging alone that the "name" tag is in German language.</div><div><br></div><div>In order for language fallback to work properly, a consumer would either need a name:de tag to be set, have some external data source that can geolocate the local language, or use wikidata. We could certainly say that "the names of places in other languages does not belong in OSM, that goes in wikidata", and this would be a perfectly workable solution for data consumers, however, there is definitely not a consensus to remove language-specific name tags from OSM.</div></div></div>