Address field dropdowns should choose a name in the relevant language

[1ec5]

As far as I know, most postal services and other addressing authorities use only one name at a time in each part of an address (street, city, etc.), even if OSM would give those features multiple values in name=* as a linguistic compromise.

For example, I recently had to retag a bunch of POIs where a mapper had previously accepted iD’s suggestion of addr:street=Bellaire Boulevard;Đại Lộ Sàigòn based on this nearby street, which is tagged name=Bellaire Boulevard;Đại Lộ Sàigòn. This street has two values in name=* because of dual wayfinding signs. 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. Even if they did, they still wouldn’t recognize a dual name. (Do other countries’ postal systems work like this? Please correct me if I’m wrong.)

Ideally, iD would somehow know that it should use name:en=Bellaire Boulevard instead, because that’s the standard language for addressing in most of the U.S. We might be able to use data/territory_languages.json for this purpose, but it gets tricky in multilingual countries where the countrywide default language may not be a good fit. Since iD also consults Nominatim, maybe it can access the default_language=* from the surrounding boundaries, or it could base the decision on the interface language. (Not great, but this is a fallback.) Or maybe iD could simply use the name=* but truncate it at the first delimiter (a semicolon in this case).

iD/modules/ui/fields/address.js

Line 58 in 4ffc0bc

const value = resultProp && d.tags[resultProp] ? d.tags[resultProp] : d.tags.name;

[Deeptanshu-sankhwar]

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.

[1ec5]

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.

iD/modules/ui/fields/localized.js

Lines 36 to 39 in b5d45e3

	var _territoryLanguages = {};
	fileFetcher.get('territory_languages')
	.then(function(d) { _territoryLanguages = d; })
	.catch(function() { /* ignore */ });

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:

iD/data/territory_languages.json

Line 241 in b5d45e3

"us": ["en", "es", "zh-Hant", "fr", "de", "fil", "it", "vi", "ko", "ru", "nv", "yi", "pdc", "hnj", "haw", "frc", "chr", "esu", "dak", "cho", "lkt", "ik", "mus", "cad", "cic", "io", "jbo", "osa"],

iD/data/territory_languages.json

Line 40 in b5d45e3

"ca": ["en", "fr", "zh", "yue", "es", "pa", "ar", "fil", "it", "de", "ur", "fa", "pt", "ru", "hi", "ta", "vi", "pl", "ko", "gu", "el", "ro", "bn", "pdt", "uk", "sr", "nl", "ja", "hu", "so", "hr", "iu", "iu-Latn", "tr", "oj", "ojs", "chp", "moe", "cr", "mic", "atj", "bla", "crk", "den", "dgr", "csw", "moh", "nsk", "dak", "clc", "hur", "crg", "war", "lil", "oka", "pqm", "crl", "kwk", "gwi"],

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