Many users are actually quite biased toward their own language. If a map shows the German speaker “Carabinieri Bozen (Carabinieri Bolzano)” and the Italian speaker “Carabinieri Bozen (Carabinieri Bolzano)” instead of showing “Carabinieri Bozen - Bolzano” to both, the map would be biased in favor of the user. I don’t see a problem with that.
I agree about the bias, this is the easy case and can be solved by always preferring e.g. name:de for a German map, my comment was for the question how to produce/store a good “neutral” name for those that don’t want to prioritize any given language, repeating “Carabinieri” in both, German and Italian, isn’t a very good solution, it’s an unnecessary repetition and hardly anybody labelling manually would use a label like “Carabinieri Bozen (Carabinieri Bolzano)”, you’d either use a double name for the city or omit one language all together.
Having a canonical delimiter should help in deduplicating, if the user language is among the local languages. Can it help though, to construct an unbiased name to put in parentheses, in case the user is in a third language?
PS: Americana map style in this case does not need any of that, regions only show user language name, and that is fine.
You will never have a problem with a single lingual label. The problems start, when you want to show multi lingual labels, but in a different way the mapper want to see it. Therefore you need to know which local languages are existing (I assume, they are all available in OSM) and decide an order. If my users considered to be mainly Germans, I would prefer to label everything “DE - IT”. Doing this by: name:de - name:it in whole Italy would no be helpful. E.g., Rom - Roma as there is no signs in German in Rome.
In Belgium, the rules in OSM for the order of multi lingual names in name are driven by keeping peace within the community (first one decides) rather than any consistency. But consistency is what you want to see on the map. Especially if you neither know French nor Dutch.
(drifting off from “delimiters” here somewhat, but for context…)
Unfortunately, we get these too, for example disputes about the spelling of a word in a particular language. One recent one was about the New Zealand English spelling of some words of Māori heritage.
I think the real problem with this is that this will counter-intuitive to users unfamiliar with general OSM practice, and will immediately look poor on rendered maps until the tools catch-up, which will in turn lead to some reversion of the name tag. The best technical solution might not correspond with user expectations.
The former could be addressed by offering support in iD, as other editors are used by experienced contributors. From what you say using a semicolon should be the least complex for the renderers. If we move in this direction, it’s probably best to try and synchronise, say, iD and Carto-CSS support.
A few thoughts about how this might be done in iD:
Names containing typical delimiters, ask if it is a multi-lingual name before upload, and replace with “:” in advanced tagging view, possibly create an additional tag such as those suggested in this thread.
Rename current name:xx tags from “multilingual name(s)” to something like “language-specific name(s)”
Encourage population of the relevant name:xx tags
Warn if a semicolon-separated value of the name tag is not met by one name:xx tags
It would be lovely if one could directly construct the name tag from name:xx tags in the editor, but I suspect that this would require significant changes to the i/f for the single tag.
PS. Anecdata on multi-linual name usage: In 1973 I did a language exchange with a boy from Liège. My ferry to Ostend (/Oostende/Ostende) was delayed by a strike and I missed my booked train. The railway timetables in the station (or at least those I could find) were all in Flemish, and I did not know the Flemish name of Liège. I worked this out by looking at the timetable of my booked train, which arrived in Luik at the right time & was able to get to Liege on the last train of the day which left shortly afterwards.
iD has a “multicombo” field type (looks like a token field) that could be useful for hiding the raw semicolon from the user and making multiple names feel more natural. It’s currently used in the Destination field, for example. However, it doesn’t currently work with the multilingual subkeys. It probably would need to wait until iD adds support for alt_name; otherwise, mappers would be too incentivized to stuff everything in name, undifferentiated.
openstreetmap-carto would be an easy case technically. If I understand correctly, the holdup is that the maintainers are concerned about poor optics if they refine multilingual labeling anywhere in the world before improving font selection in regions that speak CJK languages or Arabic-script languages.
This is a nice idea, but it only covers the case when the names come from different languages. So far there have been a few examples in this thread where the names come from the same language but are on equal footing. Sometimes they can be distinguished by keys like loc_name and reg_name, though iD doesn’t have fields for those keys yet. A fix is waiting for review:
I think this could be partially addressed by careful phrasing of the warning. Current iD warnings tend to avoid nuances about edge cases & different tagging approaches, e.g. “outdated” often means “a more widely used scheme”. It would be interesting to know if newish users assiduously auto-correct the warnings or ignore some of them.
That’s fair, if a mapper thinks that the common-sense, language-neutral name of a POI needs to combine each language’s name in a non-obvious manner, then I think they should be able to put that combination in name, cognizant of the tradeoff that speakers of German or Italian would see some duplication (a minor annoyance at most).
But if we allow for this kind of combination, then it needs to be possible to distinguish it from the POI next door that has a less sophisticated concatenation of the two languages’ names. Otherwise, the Italian speaker would now see “Bolzano (Carabinieri Bozen)”.
It’s only possible to combine the names in this manner because German and Italian share certain similarities, such as how they’d write “carabinieri”. Similarly, I’m reminded of a supermarket I used to shop at, named “Senter Market” in English and “Chợ Senter” in Vietnamese. To save space, the sign out front said “Chợ Senter Market”. (I always got a kick out of hearing the Garmin GPS say, “Arriving at Choh Senter Market.”)
But we can’t necessarily encode those combinations in name even if signposted. In the Houston seafood buffet example earlier, the sign spliced Chinese characters between each English and Vietnamese word. Even if that’s how the sign is laid out, seeing it written that way in any other medium looks like garbled text. I think there’s a limit to how faithfully we reproduce signs, because we aren’t in the signmaking business.
(based on the complaints the DWG gets) new users treat suggestions by iD, the NSI, OsmOse etc. as gospel that must be followed. OsmOse goes out of its way to indicate that its suggestions are only suggestions; iD does not.
Whilst it can be helpful to prompt a set of brand tags for something that is “a normal brand outlet”, it doesn’t help if the NSI information is incomplete, vague or otherwise wrong. As an example (that you’re familiar with but others may not be), see this fast food place - there brand info for a brand that operates in the Southern US was added to a chicken shop in London based on the very generic name (and I’m not making this up) “Chicken Express”. While fixing one rogue entry there is helpful it only nibbles at the edges of the problem - no OSM editing software should be automatically adding tags based on something as flimsy as a generic name like “Chicken Express”. The NSI is still wrong; it’ll suggest this brand anywhere in the US when it only operates in Texas and a couple of neighbouring states.
Similarly, I’m reminded of a supermarket I used to shop at, named
“Senter Market” in English and “Chợ Senter” in Vietnamese. To save
space, the sign out front said “Chợ Senter Market”. (I always got a
kick out of hearing the Garmin GPS say, “Arriving at Choh Senter
Market.”)
That type of naming is also common in Wales.
I theory in case of name=Carabinieri Bozen;Carabinieri Bolzano you could string compare Carabinieri Bozen and Carabinieri Bolzano and avoid double naming. So in that case: Carabinieri BozenBolzano. Of course it will only work if the order is same. On the other side there might be cases, where you want to have it doubled. So not sure whether it’s a good idea…
A separate QA tool is not as in-your-face as a built-in editor warning. There’s no amount of wordsmithing that will completely eliminate the problem of overzealous warning suppression, especially now that the How Did You Contribute? tool counts “ignored” warnings against your permanent record, inappropriately in my opinion.
For something even more nuanced like naming, I think we’d need a UI that doesn’t rely too heavily on warnings to guide the user in the right direction. Part of this approach could be to automatically show the appropriate language-qualified name fields even when untagged. For example, iD could automatically show the German name field when editing anything in Bozen because of default_language=de on the South Tyrol relation, which iD might already have access to via a Nominatim reverse geocoding lookup. But as far as the main name key is concerned, mappers currently have to read a long wiki page or study the map intensively to determine the local mapping conventions.
The NSI project agrees with you. This fix to limit the brand to four U.S. states may only be nibbling at the edges (of a delicious chicken finger), but it’s only one in a very long line of edits to refine the location sets of brands to include individual states or even exclude individual cities, now that that capability exists. The project welcomes additional refinements along these lines.
I would suggest to not consider semicolons in street names as an argument one way or the other. Historically they have mainly been created by errors joining streets and I very much doubt that has changed.
I don’t think it should matter which name gets listed first. If you are going to have multiple names in the name tag, it should be because they are equally important. If one name is important enough to be listed first, it should instead be the only name in the name tag, and the others can be in alt_name or name:language. You likely would not even be able to enforce any sort of ordering rule, and it would likely be decided by whoever happens to map the object first.
This is because of my recent experience cleaning up the cuisine tag, which make extensive use of semi colon delimited lists. For years the wiki told mappers to “Order them based on the order listed on signage, or subjective sense of importance, falling back to alphabetical”. Even so, mappers didn’t seem to apply any consistent ordering, and even different branches of the same chain restaurant in the same city often had different orders or different lists of values entirely. Now the wiki just says “The order is not important”.
This was indeed a big problem in Potlatch 1 due to its poorly chosen affordance for merging two ways (holding down Shift, if memory serves). The errant semicolon lists weren’t limited to the name key by any means. Luckily, modern editors keep mappers from unknowingly creating semicolon-delimited lists when merging features:
Distinguishing pre–Potlatch 2 occurrences from more recent, more intentional occurrences can be a little tricky due to way splitting, driveway mapping, etc. But it seems like people generally consider the historical occurrences to be a manageable problem – it’s not like we abandoned the semicolon altogether because of it.
No one wants the incorrectly merged features to continue to be incorrectly merged, regardless of the delimiter. In this Osmose issue, I floated the idea of keeping the warning about dual naming but relegating it to level 3 so mappers don’t feel pressured to invent a delimiter just to satisfy the QA tool.
actually there is no German version of “carabinieri”, it is an italian name for one of their police forces and in German it is simply used with the Italian word as it is seen as a name (I guess). Translated it would be “Gendarmerie” (French word used also in German), https://en.wikipedia.org/wiki/Gendarmerie
To continue with this metaphor: Imagine the capitol of your province was named “French Fries” by the majority of the inhabitants of the province, but was called “Pommes Frittes” by the majority of the inhabitants of the capitol. And both of these names were legally on equal standing: Which should be “alt_name” or “local_name”? In my view, and also in the view of the local community there, both are to be in “name”. Now, which should be first in “name”? May I invite you to reorder them in your preferred scheme? The community there chose municipality level over province level. I do not complain. @dieterdreist wrote, that the administrative building though should not be decided on where it stands, but in what administrative level it operates. I invited him to change the order. I guess he will let pass.
Names is delicate. Good meant suggestions that fail to account for local settings might poison the community. Be warned.
Carabinieri colloquially would translate to Polizei (police). But the regulations the carbinieri (Italy) operate under and Polizei (Austria/Germany) operate under differ so much, that this translation is not valid in Italy.
There was a major issue about 18 months ago in South Africa where lots of roads were merged together by mistake, resulting in e.g. “lanes=1;2;3” and “maxspeed=100;80”. The users doing this unfortunately weren’t spotted until a month or so later, after some #adt and tomtom people had further edited the data making it even harder to restore.
But you’re entirely correct in that I’ve not seen that sort of problem introduced by e.g. an iD or Vespucci user for years.
I do not complain. @dieterdreist wrote, that the administrative building though should not be decided on where it stands, but in what administrative level it operates. I invited him to change the order. I guess he will let pass.
Names is delicate.
I will definitely not perform any remote edits on names in multilingual areas. From my point of view, the order is not so relevant, but I know there are sometimes discussions about it.
