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/[email protected]>
_______________________________________________
rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev
