I think both iOS and Android have a language detection library built in. iOS certainly does, because I’ve implemented it in my cycle.travel app - it will happily tell you to “Turn left on” [English voice] “Rue de la Republique” [French voice], or conversely, “Tournez a gauche sur” [French voice] “Main Street” [English voice].
But that said, I would quite like to have polygons for alternative languages, so I could offer the user a choice of English or Welsh in Wales, or Spanish or Catalan in Catalonia, without having to encode every single name:* value in my vector tiles or routing graph.
It would help render the “how do we format the entries in name tags” discussions moot. There are a few ongoing right now on the forums.
Would this proposal remove any and all possibility for disagreement? No. Would it help reduce the frequency? I believe so, yes.
Reducing the importance of name should at least help with these sorts of things, and if the direction is to look at the formal decisions made within administrative districts when there are unresolvable disagreements, that may help even a bit more.
Again, there will still inevitably be some disputes. People are people and language is part of cultural and person identity, …
Speaking of Catalonia, I recall traveling in Galacia and noticing how people were “correcting” official highway signs by hand
That is another aspect of it … it creates a way to set default policy. It lowers the stakes on consensus finding, as changes would be easier to implement (not having to edit every name tag, e.g.g) and could be implemented quickly.
If we look at just the issue of standardizing separators or whether to use full names each language or “mash-ups” of them, this immediately helps there. That is a category of discussion lacking consensus that is currently ongoing in multiple threads on this forum, and which would no longer really be very interesting or needed with this proposal.
It has been noted previously, but the idea is to find a 90%+ solution that doesn’t do harm to the cases it can not help with. It’d be awesome if we could reduce the number of disputes around the content in name fields. I have no delusions that it will resolve all such cases, however.
I wonder, how long before an esperantist helpfully adds an area for languages:preferred=eo spanning ±85° latitude and ±180° longitude? Even if it gets reverted immediately, that’s as much fun for the tile cache as long roads named Andy…
It wouldn’t, because many (most?) data consumers would continue to just use the name tag. Opinionated mappers that favour a particular language would continue to argue over that. Experience suggests that you’re not going to persuade the slower-moving consumers (including OSM Carto) to support anything new.
I’m in the DWG and we’ve seen lots of these disputes over the years. People will find an excuse to argue about everything - even variations of language tags (“old”, “official”) that almost no-one consumes. Places also have different layers of government and these different layers can issue conflicting language edicts.
In your scenario, if the user has a preference to hear German street names in German, the software will look at name:de if it’s set, so it doesn’t need to guess what language name is in.
If the user has not specified a preference that matches local languages, then even with your suggested change the software needs to decide on a language to use (because should it read the German names, or the French names, or the combo name?). How will it decide what language to read in Biel/Bienne or Brussels if the user’s locale is set to Polish? The only improvement I see is it enables the software to default to reading both name:nl and name:fr together but in appropriate voices, instead of reading name and trying to guess the pronunciations. Is that your goal? (Though it’s different than the entire scenario you presented about English speakers wanting German street names.)
This is a non-argument, as it implies improvements waiting until data consumers adapt to improvements … which they can’t until the improvements are made.
This proposal obviously won’t fix things overnight, but it gives a pathway to improvement over time.
That’s fine. Most places have this sorted out at the administrative level, so most of the world would work with this.
As I have repeatedly noted, the goal is not to find a 100% solution, but a 99%+ solution. There is no reason for 99% of the word (or whatever the actual percentage is) to have worse rendering because we know some small percentage of people can’t agree on this matter.
Assuming this is correct, so what? Should we stop trying to improve the data set?
That said, if we can get a dark mode on OSM, I dare to dream that we can get real improvements like rendering names in a better way.
Don’t let perfect be the enemy of good. The majority of the world has this sorted out to one extent or another, and this proposal matches how those policies work in most places in the world.
Can you provide a real-world example of this which would not be representable with the proposed tags?
Of course, an order is required due to how rendering works, so one will need to be selected and I hope we can generally agree that a consistent order is better than an inconsistent one. So the local mappers will need to determine what that order is.
The local mappers can decide to resolve this in several ways:
look at the street signs and follow that ordering
defer to any suggestions / guidelines / requirements from local government
defer to local custom
… and then they can encode that decision in languages:* tags. And should that decision be changed in future, the change can be made quickly.
So, for instance, if the local mappers decide at some point that map users are better served by having names that reflect street signage order, they can update one tag and have it reflected in renderers with no further edit churn.
Sadly, in the case of Biel/Bienne, the current name order does not reflect the order on street signs, and should the local mappers ever decide to bring them into line the edit effort would be massive under the current systems employed.
This would either be a use case for languages:self or to only put a name: tag and not localized tags.
This issue could be addressed expanding the proposal, with the “noorder” or “random” feature, that instructs the consumer should randomly choose which language to use. but it opens a door for another kind of problems… I doubt any consumer would respect this feature anyway, i haven’t found anyone yet that uses short_name when there is little screen to display it, and it would be IMO much more useful and easier than this “random” feature.
The Mapbox Streets source uses short_name=* – too aggressively in my opinion. For example, this street is tagged name=Martin Luther King Drive East and short_name=MLK. Any Mapbox-powered map labels it as just “MLK”, ignoring name=*, regardless of the available screen real estate. That’s partly because no one there had figured out how to make a vector map fall back to short_name=* more conditionally. I have a prototype of that for OSM Americana, which is based on similar technology. Unfortunately, it relies on hard-coded heuristics, because OpenMapTiles doesn’t expose short_name=*.
The reason I skipped past this particular topic is that It is a non-issue:
Regardless what we may feel as human beings, rendering is ordered. A default ordering therefore exists. Most OSM data has already decided on an ordering.
Randomly shuffling the ordering of significant data is hostile to users (a basic interface usability principle) and so should not be a core feature.
Users can set personal preferences in their mapping application (assuming it supports language settings) if they wish to enforce a given ordering, including randomization. Developers of renderers / applications can do similarly.
As such, I would not wish to extend the proposal in consideration of this.
Sure, the text lacked a joking tone :-). I also wouldn’t extend it and didn’t expect that…
But at the heart of the political and cultural problem, when there is no other possibility of agreement, perhaps they can agree to let chance order the names, and at least that allows OSM to move forward from this kind of edit wars…
(digging up this post from ages ago just to potentially fill in some of the “how”)
It’s absolutely possible to display different names in different areas based on “some rules imposed by the person making the map”. Part of the reason that I created this et al was to try and demonstrate that people didn’t need to have language wars inside OSM data fields and could “just make a map in their own language”.
What I hadn’t realised until recently is that at least some vector processes support this natively, so at the “making a map” stage it’s even easier, although of course:
