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

[Minh Nguyễn]

1ec5 left a comment (openstreetmap/openstreetmap-website#6641)

> the change implies going from a more or less neutral source of labels to one that is not viewed as unbiased in the community.

The existing strings aren’t completely unopinionated either. The only truly neutral source of labels is a raw display of key=value pairs. If there are specific concerns about inaccuracies in the source strings, they should be raised with the maintainers of the relevant repository. But it’ll likely be a more fruitful conversation in a dedicated tagging project than in a project like osm-website that’s focused on other things.

Most languages are not English. When osm-website’s search prefixes and id-tagging-schema’s preset names are translated into a given language by the same dedicated OSM community members, charges of bias are completely unfounded. These translators would appreciate not having to maintain so many more translation strings. On the other hand, when they’re translated by different individuals, mappers suffer from miscommunication. Mistakes can go [unnoticed for many years](https://translatewiki.net/wiki/Special:Diff/13673499) because these search prefixes are buried within a larger project.

Discrepancies between the two projects are usually unintentional, unrelated to any dispute between editor developers. The most common reason is that Translatewiki.net has no barriers between the projects it hosts. Translators who don’t specialize in OSM sometimes uncritically accept superficially similar but completely unrelated strings from, say, the game _FreeCol_, which has completely different tagging semantics. By contrast, other translation platforms maintain more separation among their projects’ translation teams and translation memory databases. I don’t think this is a major problem overall that would force us to reconsider Translatewiki.net as our translation management service, but it does put any concerns about bias in perspective.

That said, if your suggestion is that we should consider unifying the search prefixes with a different tag translation project or spin off our own based on osm-website, a concrete proposal would be appreciated.

> if you want to do this properly you need to match presets with the tags for the element in question and then using the (translated) field names from the presets. I'm not sure if changing things is worth it if you go full in on this.

The field names shouldn’t be necessary. I think we still want the search prefixes to remain fairly general. id-tagging-schema does have separate presets for, say, “Burger Fast Food” (`amenity=fast_food` `cuisine=burger`) where osm-website would’ve just said “Fast Food”. We might have to account for that by giving the search prefixes more space in the UI, like on a two-line display. But there shouldn’t be many cases where id-tagging-schema would be so much less specific than osm-website that we’d need to dive into the fields ourselves.

> currently iD and the iD presets are translated on transifex (with a number of other projects) this is more than slightly controversial in the mean time, and any translators on translatewiki are not going to be happy with being asked to move there.

As noted above, openstreetmap/iD#7508 tracks moving away from Transifex. While that’s a complicated move for reasons we don’t need to get into here, one possible way forward would be to separate id-tagging-schema translations from iD core translations. That would be an opportunity to move those translations to a different TMS (not necessarily Transifex, not necessarily Translatewiki.net). Such a separation would be long overdue, since hitching id-tagging-schema’s translations to iD’s Transifex project delays translations from going into other clients based on iD’s release schedule.

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

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