[RFC] Feature Proposal - Add languages: tags for name rendering

[Richard (Richard Fairhurst)]

@aseigo

A few years back I had the experience of driving about with a friend who had a satnav in their car set to English (which they spoke) as we drove through French and German language towns. The names were absolutely butchered, to the point I could barely understand them even though I knew some of the streets by name, as the nav tried vocalizing the place names as if they were English.

As the name tag does not include language information in OSM, text-to-speech vocalizations of navigation directions using those name values relies on a mix of heuristics (“people speak XXX in this country…”) and language auto-detection. Neither are exactly perfect, nor available in every nav device/service.

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.

[aseigo]

@alan_gr

The implication is that the proposal would help reduce these disputes

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.

@alan_gr

the use of dual Spanish-Catalan “name=” in certain areas near Catalonia but outside its borders.

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

@alan_gr

The only thing I can think of is that it would make it easier to implement a consensus if one is reached.

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.

@alan_gr

usually the problem is reaching the consensus in the first place.

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.

[Minh_Nguyen (Minh Nguyễn)]

@Richard

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.

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…

[SomeoneElse (Andy Townsend)]

@aseigo

It would help render the “how do we format the entries in name tags” discussions moot.

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.

That doesn’t mean that some sort of area-based approach isn’t a good idea. https://wiki.openstreetmap.org/wiki/Proposal:Add_languages:_tags_for_name_rendering#Name_Resolution_Algorithm is part of the way there, but I suspect needs to consider:

• what is the preferred languages of the person reading the map or listening to directions?
• what languages are actually present on most road signs
• what languages do most people locally speak?

Having said that, I don’t think that this proposal makes things worse, which is actually a good step forward.

[Jarek]

@aseigo

Ask yourself: how does the software know which language (or languages) the name field is in?

The proposed solution is to add new tags which note what the preferred languages are for local names so that instead of going to the name tag, renderers can instead pick out the localized tag (name:<lang code>) and render those.

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.)