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