Multiple delimited names in the name tag

Recently there has been discussion in #communities:us and #communities:de about the practice of putting multiple names in the name tag. I’m starting a topic here because the scope of discussion expanded fairly quickly.

Original local topics:

1 Like

I would say that the practice of putting multiple language/script values in a name tag is an accepted practice but there’s no standardization as to how they’re delimited.

exactly, although in all the areas I looked at there were either slashes or dashes. Having multiple names in “name” in multilingual areas is common practice and the alternative would not be having a single name but no “name” tag. That’s the situation in Europe.

Having a formalized delimiter would be an improvement, I agree,

There are a few renders supporting specific languages: Map internationalization - OpenStreetMap Wiki

But still there’s still a long way to go :cry:

There is currently also a similar discussion in German part FYI:

This is common in South Tyrol too. There even the ordering, what goes first, German or Italian name of the place changes. A quick guess, it depends on majority from the most recent census.

The americana map shows me the German name only, for minor cities, but the German name and the name with the space separated dash/minus in parentheses for the single major one. Perhaps, because my browser is configured in a way, that I prefer German names and this is a vector map, that can do individual display.

However, a semicolon for names will not fly. Not for OSM-Carto and not for americana. Another quick guess: How about a key that lists languages in order of preference of the local community: name:scaffolding=de;it e.g? So a consumer might choose from name:language=* to meet their users preferences and not have to rely on *name" at all (if present)?

Are talking about: default_language=*?

1 Like

Are we talking about the data that goes into the style or the human-readable text that comes out of it? The two are certainly different for Americana. The lack of semicolon handling is merely a bug. Having implemented Americana’s dual city labeling you’re referring to, I consider the lack of a predictable delimiter to be a flaw, not a feature.

1 Like

So far name is considered as one string to be displayed. Not sure whether it’s a good idea to define one character now with special meaning, as there might be valid names containing a “;”

Instead I think it would be technical better to teach the renderer not to use always name, but the name:<default_language> or name:<default_language_#1> - name:<default_language_#2> or any other preferred way.

1 Like

This is true with respect to openstreetmap-carto but not true with respect to a variety of other data consumers:

There is a long-documented ;; escape sequence for this very rare case. But a name that legitimately contains a slash is very common in place names and POI names. For example, there is a large real estate agency chain named “RE/MAX”. What is the escape sequence for a slash or dash? Any spelling that omits the slash is a misspelling. But neither “Bruxelles - Brussel” nor “Bruxelles / Brussel” is more correct than the other in the real world.

I agree to some extent. This is what we’ve implemented in Americana. However, it’s also useful to show the local-language name(s) alongside the user’s preferred name. This is a common practice in American maps of the world (although transliteration is more common than the local writing system in that context).

1 Like

I think we’ve strayed very far from the question of what to do about these places that a mapper unilaterally retagged to include a Native American name based on the place’s historical namesake. Can we split out a new topic for the broader question of how to represent multilingual place names in the U.S.? It seems other communities have a strong interest in how we map them here.

(Edit: The moderators have split this out as a new topic. Thanks!)

2 Likes

Sure, but a delimiter does not tell you the languages. “Bolzano - Bozen” is ordered “it - de” while “Bruneck - Brunico” is ordered “de - it”.

Sure once more, a diligent consumer, that can rely on a predictable delimiter, can find out the ordering from comparisons with name:<lang>: tags.

The only reason to display name is when the style doesn’t care which name is in which language. When Americana displays name, it’s only after the name:* in the user’s preferred language. All we’d like to do is deduplicate the names (in case the preferred language calls it by the same name as one of the local languages) and replace the hyphen with something more presentable, such as a comma. We can’t do that reliably when there are ad-hoc delimiters, because these characters may be part of a name rather than a delimiter between names, and often the name in one language is part of the name in another language.

1 Like

Bozen (Bolzano - Bozen) will not deduplicate anything for me, while there are duplicates. I fully see, why you cannot do this when ad-hoc delimiters are in the name.

No, in South Tyrol, predominant name does not follow admin boundaries of at least level 2. Is follows municipalities. No idea what admin level those are in. Also, that key does not allow for lists. On the admin2 level, there might be two languages as position 0.

My summary of the discussion so far is this:

Some people feel that the name tag should only contain one primary name, and all other names should go in other *_name or name:lang tags. However, there are many multi-lingual places in the world where it is very difficult if not impossible to do this. So the practice of putting multiple names in the name tag has become accepted and is widespread in many places. For situations where a tag contains multiple values, it is standard to use a semi-colon separator. However, name tags with multiple values are commonly delimited with slashes, hyphens, spaces, or other characters. Standardizing on semi-colon delimited multi-value name tags would allow data consumers to split the values and do much more interesting things than simply rendering out the concatenated string as if it were one name. The standard layer already handles semicolon delimited ref values quite nicely and it could do the same for names.

8 Likes

In deed, it seems currently there is no definition existing for multiple values. But it would make sense, as it would solve the issue name containing a “unknown” list of some names. So a renderer at the moment can either take, whatever is written in name or need to define the list on it’s own.
For example I would imagine, osm-de-map would give name:de in Swiss a higher priority where osm-fr-map would prioritize name:fr. But that’s not really possible at the moment.

Thanks @ezekielf for your summary, just want to add one argument from German discussion:

name=<name1> - <name2> indicates “<name1> - <name2>” is the full name of something, which is not the case. So in case there is not only one name existing, name should technical be not used. We haven’t thought about a defined delimiter, which might be the better way, so lazy renderer could simply replace a single ; with - or ’ / ’ or line break and get similar results as at the moment.

This is true at a technical level, but may not be appropriate at a cultural level: most multi-language names in the name tag are a sign that the relevant place has significant linguistic, and probably cultural, diversity. In these cases (Derry/Londonderry is a very good example) choosing one or other name may involve taking a position within this diversity.

The “-” or “/” often reflects the way local cartographic and signposting has traditionally dealt with the issue. It would make sense for OSM to adopt a single convention rather than maintaining a variety of local ones. This is unlikely to solve the issue, but may ameliorate attempts to parse name tags of this type.

2 Likes

Whatever the reason for having to two or more accepted names, the list should separated by a semicolon between each name. This is no different than we do for any set of values. The map can display that list of values using whatever method it wants.

Each one of those place names should also appear in the appropriate name: list so Nominatim can parse them correctly.

3 Likes

The main issue on that is, that Carto is treating whatever is written in name as one string to be displayed on the map. So the mapper are formatting it somehow nicely.

2 Likes

Exactly, so this discussion is about how to technical record the cultural naming in a way, data-users can work with that data. So that data-users actually have a chance to follow their users culture.

1 Like