Hello! Please take a look at this solution @1ec5 whenever you can. I have prioritized name:en values if it exists for a given nearby address, else I have resorted to name with the fallback to return the string before the delimiter ; in case it exists. I have attached a screenshot below on how the nearby address dropdown looks now.

Following up on some of my half-baked suggestions in #10541 (comment):

Since iD also consults Nominatim, maybe it can access the default_language=* from the surrounding boundaries

Note that this file currently only consults country-coder, but country-coder has declined to include language-territory information: rapideditor/country-coder#131. So that’s why I suggested Nominatim. Consulting Nominatim isn’t foolproof, but it’s more language-neutral than what’s currently in this PR.

The Nominatim API integration lives in modules/services/nominatim.js. There’s a countryCode method that grabs the country code out of a Nominatim reverse geocoding result, but it isn’t quite what we’re after, since the default_language would be on the containing country or perhaps a political subdivision of the country. Unfortunately, a standard reverse geocoding request doesn’t seem to include any metadata about those containing boundaries.

That’s as far as I got at a glance, but feel free to explore this approach some more and ask in Nominatim’s discussion board if you need more help.

or it could base the decision on the interface language. (Not great, but this is a fallback.)

You’d call utilDisplayName to get the same name that iD is currently showing as the label for the street on the map. The label already prefers the user’s language, irrespective of the language spoken locally. This is a lot simpler but can be inaccurate, for example, if an English speaker from the U.S. happens to edit in Japan.

One other potential approach I had forgotten was that the Multilingual Name field already fetches information about which countries speak which languages. You could make this field behave similarly.

Unfortunately, it isn’t very granular. For example, the entry for the U.S. lists a lot of languages that the postal service does not speak, and you’d have no way of knowing that the preferred language in Québec is French, not English:

But in combination with the user’s preferred language as used by utilDisplayName, maybe it could work.

The question here is if the linguistic compromise led to multiple languages to be included in the name tag, should it not also be the same for the address tag?! Because otherwise it could easily lead to edit wars when one of the two (or more) languages have to be chosen in the address tag. Also, having the same value in both the highway name and addr:street makes it easier for data consumers to ingest the data, and is as far as I know the current standard to map addresses.

But neither the U.S. Postal Service nor the county records manager recognizes “Đại Lộ Sàigòn” as a street name for addressing purposes.

That said, this seems to be rather specific situation here. Usually, when roads have multilingual names (e.g. in Belgium or South Tyrol), the postal services accept all recognized languages also in the postal address. So, this would require to add a special exception for the US only?

PS: Slightly off topic, but semicolons should probably be avoided in (multilingual) names in general, see https://wiki.openstreetmap.org/wiki/Multilingual_names

That said, this seems to be rather specific situation here. Usually, when roads have multilingual names (e.g. in Belgium or South Tyrol), the postal services accept all recognized languages also in the postal address. So, this would require to add a special exception for the US only?

Maybe. I guess this gets into whether the dropdown should be more helpful than merely looking at name=*. For example, a vast number of addresses in the U.S. are along roads that only have numbers, not names. There are specific formats for those numbers in addresses, such as “State Route 123” for ref=SR 123 on the way (or network=US:XY ref=123 on the route relation). Encoding these formats as name=* is controversial, to say the least.

Slightly off topic, but semicolons should probably be avoided in (multilingual) names in general, see https://wiki.openstreetmap.org/wiki/Multilingual_names

There’s a long discussion questioning that premise on the forum…

Anyways, this issue is not really about semicolons. It came up in the context of this debate about hybrid street names in Canada. “Rue John Road” is not a street name that Canada Post would recognize in either French or English, and not a name that anyone would search for, regardless of the language they speak. iD would ideally suggest either name:en=John Road or name:fr=Rue John. Truncating at a semicolon was only a suggestion about how to solve part of that issue more easily.