Well the fundamental problem is that the numeric admin_level tagging scheme is, and always has been, totally insane and just doesn't work in the real world. There isn't much we as web site developers can do about that though.

Probably we should ignore admin_level and just label them all as administrative boundaries - it makes as much if not more sense as trying to divide them into regional, local and sublocal (whatever sublocal is other than not being an english word).

Even the numbering in admin_level is better than no information at all, as it at least gives a ballpark for comparing admin boundaries between each other. Remember that osm.org is useful for mapper feedback first and foremost: Plenty of places have admin boundaries with the exact same name that contain each other. For example, the boundary for the settlement of Groningen, Groningen's municipality and Groningen's province, are all simply name=Groningen. Simply wiping the slate clean would make distinguishing between these cases a hassle (currently they are labelled as Suburb Boundary, City Boundary, and State Boundary respectively in case you were wondering).

For Overpass queries, there’s currently a special case that pulls in a dedicated string based on the admin_level=* if it’s present:

Maybe instead we could use the generic “Administrative Boundary” label, using the normal code path, but add a suffix like “(Level 3)”? I shied away from numbers in #5029 (comment) because terms like “second-order administrative subdivision” exist in the real world, and the numbers don’t ever mean what they do in OSM. But if we separate it from the prefix as a parenthetical, then I think it’ll look like a piece of OSM-specific metadata.

For Nominatim queries, if a place=* tag is present on either the boundary or the label member, we show that as the label instead of anything related to the boundary:

For example, searching for “Wapakoneta” returns this boundary=administrative admin_level=8 relation but labels it as a “Town” based on the place=town tag on this label member. The label doesn’t call it a “boundary” of any sort, even if that’s what gets highlighted when you select the result. This is pretty reasonable, because the boundary represents a populated place that we’d tag as a place=town regardless of the boundary or legal designation. However, for something that doesn’t represent a populated place, such as a U.S. county or a French department, a label wouldn’t be as relevant or appropriate, so there still needs to be a “boundary” label for the search result.

I think it would be possible to use a suffix here too. It would need some additional translatable format strings.

The border_type tag is in pretty wide use (45,000 relations, wide geographic coverage). It seems like it would be pretty sensible to just use the border_type value as the preferred label, and then fall back to place=* or a generic administrative boundary label as Tom suggests.

Fortunately, Nominatim does expose border_type in the extratags field of the response, and both Overpass queries (for nearby and enclosing features) include all the element’s tags.

Unfortunately, border_type=* 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 geocoder.search_osm_nominatim.border_types.#{border_type} strings for the most common values of border_type=*. 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 “town”. I’m not sure it would be received by the community any better than the current admin_level=* labels.

Fortunately, the Nominatim result comes with a country_code field, so we could prefer more specific string keys like geocoder.search_osm_nominatim.border_types.#{country_code}.#{border_type}, falling back to a more generic geocoder.search_osm_nominatim.border_types.global.#{border_type}. We could either introduce the per-country keys as needed or come up with a more comprehensive list of common border_type=* 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.

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.

#5493 implements the enhancements above except for distinguishing a given border_type=* value that needs to be translated differently depending on the country.