[Tagging] International and UN names

[Minh Nguyen]

Vào lúc 04:00 2022-03-16, Martin Koppenhoefer đã viết:
> sure, there are many cases where "default_name" is not working, but it 
> does not mean we have to add additional "name:de" tags to every place in 
> Germany, just to be sure. I am not opposing (also "duplicate") 
> name-variant tags where the (preferably local) mappers think it is 
> useful, but I would oppose adding mechanically name:de tags by copying 
> the name-value (in Germany, as an example).

No argument there. I don't think Germany needs to fear being blanketed 
with redundant name:de=* tags.

The language situation in the U.S. is considerably more complex, but as 
a practical matter, relation 148838 is tagged default_language=en and 
Puerto Rico's relation 4422604 is tagged default_language=es as an 
override. It would be quite reasonable for data consumers to assume an 
individual name=* is in English unless otherwise stated (by setting some 
other name:* and setting name:en=* to some other value).

>     Even in a country with a single official language, POIs in an ethnic
>     enclave or tourist destination can still be in a different local
>     language, which may not correspond to an administrative boundary that
>     can be tagged with default_language=*.
> 
> 
> 
> the wiki says that default_language can be added to other areas than 
> administrative ones, as well, in exceptional cases.

That's a prudent exception, but it basically means any ethnic enclave at 
the neighborhood level would get a Swiss cheese multipolygon tagged with 
nothing but default_language=*. Most localities don't have language laws 
strict enough to facilitate a well-defined linguistic boundary in OSM.

Even my usual example of a well-defined linguistic enclave, the town of 
Oldenburg, Indiana, isn't so clear-cut: the roads and shops are named in 
German, but the buildings, churches, and maypole are named in English. 
[1] Regardless of which default_language=* I set on the town boundary, I 
either have to tag lots of redundant name:en=* or lots of redundant 
name:de=*.

> For POIs I am not sure how to deal with them. Imagine a restaurant in 
> the Italian speaking part of Italy called "Le Bistrot". Should it get a 
> name:fr tag? To cater for your "correct pronounciation navigator 
> instructions"-requirement we should somehow tell that the "name" is in 
> French, right? On the other hand, the "name:fr" tag would not help in 
> telling that "name" is in French. name:de=Paris, name:en=Paris and 
> name:fr=Paris all look the same, but their pronounciation is different, 
> and it does not tell that "name" is in French either.

Most applications would try to serve the user's preferred language(s) 
when available. It's only when those languages are unavailable that this 
last-resort fallback and default_language become relevant. If the 
application needs to render or say this name=Paris as a last resort, and 
Paris is actually a town in a region lacking a default language, then 
the application will be at a loss as to the fallback language. It will 
probably have to treat "Paris" as a name in the user's language, or it 
could assume int_name is in English, despite any mispronunciation. This 
is an argument for judicious use of the name:language=* key, which was 
previously rejected. [2]

> Btw. I had a look at Paris and someone thought it would be helpful to 
> add pronounciation tags as well:
> https://www.openstreetmap.org/node/17807753 
> <https://www.openstreetmap.org/node/17807753>
> name:en:pronunciation
> name:fr:pronunciation
> also a generic name:pronunciation which is documented 
> https://wiki.openstreetmap.org/wiki/Key:name:pronunciation 
> <https://wiki.openstreetmap.org/wiki/Key:name:pronunciation>
> 
> For the moment I guess I am more happy than not that the other 152 
> name-variation tags of the Paris-place do not have their pronounciation 
> rules explicitly tagged as well,  ;-)

name:*-Latn-fonipa has been floated as an alternative to 
name:pronunciation. [3] I like that it would be explicit about the 
language and conform to BCP47, much like what I said about name:*-UN 
earlier. However, it's harder to remember, and name:pronunciation=* 
already has traction among some existing data consumers.

On the bright side, name:pronunciation=* is an override key that doesn't 
require comprehensive coverage, much like the UN names discussed in this 
thread. I probably would've omitted it from Paris, because every 
text-to-speech engine will get the pronunciation right in English or 
French without additional context. But if you use the usual English 
pronunciation for Versailles, Indiana, you're guaranteed to get blank 
stares from the locals, so name:pronunciation=* is needed there. [4] As 
it happens, the folks up the road in Oldenburg have avoided anglicizing 
their town's name.

[1] https://www.openstreetmap.org/user/Minh%20Nguyen/diary/47362
[2] https://wiki.openstreetmap.org/wiki/Key:name:language
[3] https://wiki.openstreetmap.org/Special:Diff/2092286/2131103
[4] https://www.openstreetmap.org/relation/127363

-- 
minh at nguyen.cincinnati.oh.us