[openstreetmap/openstreetmap-website] Unify search result prefixes with id-tagging-schema (Issue #6641)

Sun Dec 21 02:52:16 UTC 2025

1ec5 created an issue (openstreetmap/openstreetmap-website#6641)

When we generate Nominatim search results and Overpass query results, we prefix each result with a human-readable label corresponding to a top-level feature tag. We’ve been maintaining these search prefixes directly in the repository, but as the repertoire of POI types continues to grow, I wonder if we should depend on [id-tagging-schema](https://github.com/openstreetmap/id-tagging-schema/) for this purpose, since one of its core functions is to manage human-readable names of tag presets.

## Rationale

### Code maintainability

There seems to be a preference for simplifying this repository by adopting reusable libraries. A recent example is the migration of custom tag linking logic to tag2link: #6197. We could similarly delegate the responsibility for curating the tags to developers who already focus on that task. As with the search prefixes, id-tagging-schema’s preset names are as short as possible, in order to fit a space-constrained preset search UI.

In general, the search prefixes here are in decent shape, but we aren’t keeping up with the set of established feature tags as it continually grows. We’ve only added or modified [24 prefixes](https://translatewiki.net/w/i.php?limit=50&search=-qqq+inlanguage%3Aen+prefix%3A%22Osm%3AGeocoder.search+osm+nominatim.prefix.%22&title=Special%3ASearch&profile=advanced&fulltext=1&ns1222=1&sort=last_edit_desc) since April 2022, whereas id-tagging-schema has added new presets [131 times](https://github.com/openstreetmap/id-tagging-schema/pulls?q=is%3Apr+label%3Anew-preset+is%3Amerged+merged%3A%3E2022-04+) since that time. The existing strings include some obsolete tags: https://github.com/openstreetmap/openstreetmap-website/pull/5029#discussion_r1694824546.

### Translation maintainability

The total number of translatable messages for osm-website is [approaching 3,000](https://translatewiki.net/wiki/Special:MessageGroupStats/?group=out-osm-site&messages=&suppressempty=1&x=D). This presents a psychological hurdle to prospective translators. At least I’ve felt that when reaching out to different language communities about contributing or maintaining translations of the overall site. The [hundreds of strings](https://github.com/openstreetmap/openstreetmap-website/blob/56b153f62b77543a24708e4958d6097e189d6eeb/config/locales/en.yml#L770-L1552) for these search prefixes account for 29% of the messages.

Most if not all of these strings are also being translated for id-tagging-schema. When someone translates id-tagging-schema, it benefits [many applications](https://github.com/openstreetmap/id-tagging-schema/wiki/Projects-that-are-using-this-tagging-schema), including editors, query tools, and map sites for laypeople. However, language communities also need to prioritize osm-website’s coverage of the same strings because the site’s search function is so prominent. As a translator, I’ve struggled to keep the tag translations consistent between osm-website and id-tagging-schema. Inconsistent translations of these labels can easily cause miscommunication among mappers. I think the less experienced mappers who mainly use id-tagging-schema–powered editors would especially need consistency between what they enter into OSM and what they get out of OSM.

## Implementation

Query results are generated in JavaScript. id-tagging-schema is available as [an NPM package](https://www.npmjs.com/package/@openstreetmap/id-tagging-schema). [schema-builder](https://github.com/ideditor/schema-builder/) has documentation on the format. The matching is unfortunately up to the client, but we could start simple with something equivalent to the single tag matching we currently have.

https://github.com/openstreetmap/openstreetmap-website/blob/56b153f62b77543a24708e4958d6097e189d6eeb/app/assets/javascripts/index/query.js#L98-L108

Search results are generated in Rails code. We’d need to load the same JSON file of translations and perform the same matching in Ruby.

https://github.com/openstreetmap/openstreetmap-website/blob/56b153f62b77543a24708e4958d6097e189d6eeb/app/controllers/searches/nominatim_queries_controller.rb#L30-L34 

Many id-tagging-schema presets match a combination of multiple tags (e.g., for iterative refinement). We don’t currently do that because of code complexity, but we do get [all the necessary tags](https://github.com/openstreetmap/openstreetmap-website/blob/56b153f62b77543a24708e4958d6097e189d6eeb/app/controllers/concerns/nominatim_methods.rb#L25) from Nominatim and Overpass. Over time, we can build more sophisticated matching on both sides of the codebase as needed. I don’t expect us to need something quite as sophisticated as what the editors are doing. We don’t need any fields and we probably don’t need the more granular presets that [name-suggestion-index](https://github.com/osmlab/name-suggestion-index/) provides.

## Coverage

id-tagging-schema currently translates roughly twice the tags into slightly more than half the languages, for roughly the same level of coverage:

Project | Messages | Translations | Languages[^untranslated] | Coverage
----|---:|---:|---:|---:
openstreetmap-website | [844](https://translatewiki.net/w/i.php?search=-qqq+inlanguage%3Aen+prefix%3A%22Osm%3AGeocoder.search+osm+nominatim.prefix.%22&title=Special%3ASearch&profile=advanced&fulltext=1&ns1222=1) | [71,879](https://translatewiki.net/w/i.php?search=-inlanguage%3Aen+prefix%3A%22Osm%3AGeocoder.search+osm+nominatim.prefix.%22&title=Special%3ASearch&profile=advanced&fulltext=1&ns1222=1) | 168 | 50.7%<!-- 71879/(844*168) -->
id-tagging-schema[^presets] | [1,663](https://app.transifex.com/openstreetmap/id-editor/viewstrings/#en/presets/176462824?q=key%3Apresets.presets%20key_not_contains%3Aterms) | [83,736](https://app.transifex.com/openstreetmap/id-editor/translate/#uk/presets?q=key%3Apresets.presets%20key_not_contains%3Aterms%20translated%3Ayes)<!-- 1663+1644+1448+1498+291+1539+649+168+1552+236+1435+1638+1514+1288+59+1663+1663+1663+1663+1663+1663+1662+1662+1654+1651+1650+1656+1647+1642+1636+1636+1636+1641+1619+1619+1628+1575+1598+1493+1435+1552+1521+1575+1437+1262+1553+1355+1343+1234+1282+1513+1285+1274+870+960+648+490+588+535+648+338+288+660+239+213+324+190+124+120+120+29+28+49+15+39+81+26+28+73+17+3+12+8+4+17+4+5+97+82+1+8+1+109+4+95+5+4+2+3+3+1+1+1 --> | 103 | 48.9%<!-- 83736/(1663*103) -->

My main concern with migrating to id-tagging-schema right away is that some languages would likely lose substantial coverage. The impact is probably not as bad as for the osm-community-index dependency (#3653), as osm-website’s search prefixes are more obscure than id-tagging-schema’s preset names from a translator’s perspective. I haven’t looked into it thoroughly, but at a glance, Arpitan, Icelandic, and Slovene would likely be among the most impacted languages. Interlingua and Shan have complete osm-website translations but empty id-tagging-schema translations.

We could reach out to these languages’ translators on Translatewiki.net offering to move their work to id-tagging-schema with their permission. We probably couldn’t do it automatically, because Translatewiki.net is [licensed](https://translatewiki.net/wiki/Project:About#Copyright_and_disclaimers) under either CC BY 3.0 or the license of this project (GPLv2), whereas id-tagging-schema is under the [ISC](https://github.com/openstreetmap/id-tagging-schema/blob/3d12b86143cb762ca780bb2d4d078c52a2f13a7d/LICENSE.md) license.

[^untranslated]: Excluding localizations that are completely untranslated.
[^presets]: Preset names only.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/6641
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/6641 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20251220/df42ac37/attachment-0001.htm>