name tag should be made deprecated with introduction of name:* tags. It just calls for argues.
name:* tags already allow having names in needed languages. Existence of name tag just creates confusion.
Introduction of another tag, something like “local_language” that would contain designation of local language (or languages separated by semicolons) may provide needed information how name is displayed on local signs.
From software side that would clean, straightforward and simple way to tag names in various languages and on social side it would remove arguing and fighting about what should stay in name tag.
name tag lost its basic function to display what is on the ground as that rule is not applied everywhere and is proved to be avoided due to various political biases.
Even where it is agreed how to put multiple languages in name tag it is impractical. Using multilingual name just makes map cluttered. Map renderer has to know local rules and parse content based on those rules.
Deprecating name tag, using name:* tags and using local_language tag would allow universal way to tag names and render maps, by having better control of rendering, regardless of languages used for naming.
I don’t want to sound discouraging, but deprecating name=* seems like a total non-starter. It might be perhaps the oldest, most consistently used (paired) tag in OSM. It is likely supported by every single use case (router, renderer, text-to-speech module…) out there, and all would need to be re-written / modified if we were to deprecate name=*. I doubt this would happen without great upset to our project.
Modifying the name=* tag, like with name: subtags, well, we’re listening and discussing, as that could actually fly.
Welcome to this discussion! As you can see, this discussion has dragged on quite a while and is a bit difficult to follow. Your point about the importance of name:* is well taken, but various posts above have touched on why it’s insufficient to rely on a key that indicates which name:* to display. Here are some links to individual comments as a starting point, to avoid repeating these arguments:
A proposal for name:language was rejected in part because mappers didn’t want to repeat the same information on every named feature in a language region.
If you’re following me so far, what remains is a debate about whether to insert human-readable punctuation or a machine-readable delimiter between multiple tag values when the values happen to be names (but aren’t alternative names, official names, short names, or the names of destinations, brands, operators, or owners).
From software side that would clean, straightforward and simple way to tag names in various languages and on social side it would remove arguing and fighting about what should stay in name tag.
sure, removing the name tag would stop arguing what to put in the tag, but introducing local_language as a new tag will start new arguing about the exact same topics (which languages to add and in which order)
Looked at the recent proposal, I got the problem statement… But I didn’t get how is the proposal going to improve the situation with name alone.
If the feature has all kinds of name:lang tags and has no “name” - all good. But when it has name? Do we expect it to exist in general? Contain multiple languages? This is not clear from the proposal text…
Which proposal are you referring to? From what I understand, this thread is a debate about how to delimit multiple values in the name=* key. It presupposes that there is a name=* tag, and that multiple languages could be represented in it. There are some other threads about whether to leave name=* unset on certain kinds of features.
There’s a separate thread to collect feedback on the new proposal. Of note for the participants here, the proposal currently doesn’t address the approach of using a semicolon to delimit multiple names in name=*, which was discussed at length here.
The reason for that being that multiple names in a single field with a separator (e.g. semicolon):
does not help e.g. audio rendering which benefits from using the right language pack to voice the names. If you’ve ever used a nav set to e.g. English to go through a city in a different language … the results are often less than helpful!
requires changes to be made to all name tags for it to be consistent. Other than being a fair amount of work, even if mostly automated, it makes situations where the policies change very hard to track (see the Haida Gwaii example in the proposal)
it also does not address other multi-lingual use cases, such where the name should appear in one language if its name:<code> tag exists, but then fall back to the official languages of the area, in correct order, if it doesn’t. Yes, this can be done manually by careful editing of all the name tags, but that is very error prone and can not be automated in those cases. (Again, see the Haida Gwaii example in the proposal)
it is not truly backwards compatible. The default case would require changes to all renderers to render the results in a pretty fashion.
In any case, comments and feedback on the proposal from people here who quite obviously care about this issue is very welcome and desired. Hope to see you over there!
Where I live, a majority of residents speak English as a second language if at all, but all the streets are named exclusively in English. When a Spanish speaker gives directions to turn onto North 4th Street, they may call it calle cuatro in translation or nort fort estret in Spanglish. A Vietnamese speaker won’t flinch at Google Maps calling it nót phót xtrít in Vietrish or Apple Maps calling it đường số bốn in translation.
A decade ago, it was still somewhat rare for a text-to-speech engine to be able to handle embedded foreign-language text, especially without any indication of the language. Today, that capability is quite widespread, even among existing OSM data consumers. For example, the Mapbox Navigation SDK uses Amazon Polly, which has no problem embedding Spanish inside English. If you prefer code switching, then you can mark up the text as a particular language using SSML. In this English recording, the street name “Calle 8” is marked up as Spanish, so it comes out as calle ocho instead of callee eight. This is no longer strictly necessary for common language pairs like English–Spanish, but more distant or obscure language pairs such as English–Chinese or English–Haida could benefit.
I understand that your proposal is designed to make it easier to come up with the language code to mark up the street name. You’re right that a semicolon delimiter doesn’t solve this problem generally. However, your proposal still needs to account for the possibility of multiple names in the same tag, because that can happen even within a single language:
Your proposal takes some pressure off disparate local communities so that they no longer need to try so hard to coexist in name=*, but it doesn’t solve the problem that semicolons are intended to solve. On the bright side, you’re using semicolons to separate language codes.
I’m not entirely sure where this is coming from. My suggestion in this thread was to introduce a semicolon delimiter as an option where name=* is already set to multiple values. If any government policy causes widespread changes on the ground, then OSM probably should see widespread changes. That goes for languages, currencies, speed limits, access restrictions, parking rules, addressing schemes, flags, you name it.
I think this is a difference in expectations. A variety of renderers, representing a variety of tech stacks, as well as non-renderers, have been handling delimiters in name=* for years without any fuss. After all, it’s just a little bit of string manipulation. Granted, not all renderers do this. I don’t know how realistic it is to expect “all” renderers to implement your proposal either.
is very welcome and desired. Hope to see you over there! 