<p></p>
<p dir="auto">Fortunately, Nominatim does expose <code class="notranslate">border_type</code> in the <code class="notranslate">extratags</code> field of the response, and both Overpass queries (for nearby and enclosing features) include all the element’s tags.</p>
<p dir="auto">Unfortunately, <code class="notranslate">border_type=*</code> values are unlocalized and un-namespaced. We’d only be able to pretty-print the snake_case keywords in English. The forum thread discusses some potential solutions. The simple solution would be to define <code class="notranslate">geocoder.search_osm_nominatim.border_types.#{border_type}</code> strings for the most common values of <code class="notranslate">border_type=*</code>. This would require every localization on Translatewiki.net to come up with a single word that corresponds to each English word. In some languages, this can be quite difficult for generic words like “<a href="https://en.wiktionary.org/wiki/town#Translations" rel="nofollow">town</a>”. I’m not sure it would be received by the community any better than the current <code class="notranslate">admin_level=*</code> labels.</p>
<p dir="auto">Fortunately, the Nominatim result comes with a <code class="notranslate">country_code</code> field, so we could prefer more specific string keys like <code class="notranslate">geocoder.search_osm_nominatim.border_types.#{country_code}.#{border_type}</code>, falling back to a more generic <code class="notranslate">geocoder.search_osm_nominatim.border_types.global.#{border_type}</code>. We could either introduce the per-country keys as needed or come up with a more comprehensive list of common <code class="notranslate">border_type=*</code> values per country. The latter would put much more of a burden on translators. I’ve seen that in the iD project, where translators have to localize each part of an address field for every country.</p>
<p dir="auto">Unfortunately, the Overpass queries execute independently of each other, so the results for nearby features won’t have any context about the containing country. Since the response is handled on the client side in JavaScript, we could parse the enclosing features results for a country boundary, whenever it arrives, and patch up the labels on the enclosing features. In the meantime, these labels would use the global strings. Kind of icky, but I guess it could work.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/5450#issuecomment-2566049746">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLNUPOGECDIG33XLXML2IHU2PAVCNFSM6AAAAABUMHGO3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRWGA2DSNZUGY">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLOBFH5KAJRF3NKZ4K32IHU2PA5CNFSM6AAAAABUMHGO3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUY6LH5E.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/issues/5450/2566049746</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/5450#issuecomment-2566049746",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/5450#issuecomment-2566049746",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>