If you want to fully translate a single OSM tag today, you often need to
translate it in several unrelated places: the wiki tag page itself, plus
separately in whatever localization platform each piece of software uses
for its UI strings. There’s:
Weblate for OsmAnd and OpenStreetBrowser (each with their own set of tag translations)
Transifex for iD presets (used by a lot of apps) and Vespucci (beautified-JOSM-preset).
There’s no link between any of these, so translators either don’t know the other locations exist, or have to rediscover them every time they want to fix a bad translation somewhere.
First impulse is to unify those translations into one place, but that just makes everybody evoke the xkcd comic.
I’d like to propose adding new properties to the OSM Wikibase (Data items) that would let a tag item record where its UI-string translation lives on each of these platforms, per software project. This wouldn’t unify translation into one place, it would just make each tag’s data item a
single index pointing to all the places it needs translating.
What this would enable is drawing all the translations programmatically from various sources and comparing them, and finding problems in various translations. Also, maybe in the future, this could drive some unification in translating our tags.
Following is a table to show how we would add external keys for some applications, and how we could construct URLs from those keys. I constructed URLs mostly for the Croatian language, I hope there would be a way to make those URLs more language independent.
True, many times when I wanted to add/edit a translation about a tag, I would have to remember the main projects I usually translate. I have a notepad with all the projects and platforms I actively translate or used to translate (when 100%).
I was thinking many times of trying and creating a place in the wiki to centralize all the translation places, instead of trying to think each time the various projects that may have translatable strings for that tag.
Two questions: can the URLs that have hr in them for Croatian be generated by inserting the appropriate language code in the right place, for instance de for German? Of the ones that donʼt, are there rules that determine languages?
We moved quite a few projects to a common organisation in transifex (at the time it was the only viable solution) more than a decade ago so that we could share translations and reduce duplicate effort.
That naturally didn’t stop the next lot of apps immediately going off and using something else with no regard for the translators time they started wasting and not bothering to spend a second considering if a common effort would make sense.
That said except if you want to maintain the information automatically keeping things up-to-date is going to be a royal PITA.
For translatewiki, there’s a page that shows all translations of a single term. In transifex there’s a hack to link to the “en” language, and then you just click your language and you get your translation.
I don’t have rights to create properties on our Wikibase, maybe there’s some hack we can do to get Weblate and others. POEditor has an API, maybe others also do.
But first we need to see if this is the direction we’re willing to go towards.
Some of these use the OSM tag itself as the translation key, so we could populate those semi-automatically. Others will require more effort.
This could at least bring some order into the mess, and that order would be connected directly to our wiki, which should be the source of truth for tags. I see no better solutions right now..
I am not planning to maintain anything related to data items as long as functional watchlist does not exist for regular wiki users (ability to skip translations in languages unfamiliar to given user)
Currently watchlisting more than few items and monitoring changes is impossible (unless something changed here?), as it is overwhelmed by unreviewable translation updates. Making me not interested into investing time into relying on it.
I was thinking one property per translation platform, but one general property for all might be a better solution. I think the right structure would become clearer once we start filling it in and once we try it on a few real cases."
I was thinking only the core translation, not description. But I’m not opposed to broadening the project.
I don’t think we can presume that even the translation of the item can be 1:1. Sometimes we will have a capitalized item name, sometimes in a different grammatical form, sometimes in plural..
I don’t think this proposal would depend on watchlisting items though. Nothing here needs per-item human review: the links aren’t language-specific, and for several platforms the key is derived from the tag itself, so a bot could generate and re-check them.
The maintenance risk I’m actually worried about is different: apps changing their translation keys upstream, which would silently break the links. But that’s also something a bot could detect by checking whether they still resolve, rather than something a person would have to notice on a watchlist.