Wie ist es möglich, die Übersetzung der Tags ins Deutsche zu deaktivieren? Ich hätte gerne die Oberfläche in deutsch, finde es aber eher verwirrend, wenn die Tags und die Erläuterungen in den Standard-Presets dazu auch ins deutsche übersetzt werden. Kann ich das unterdrücken?
Ich finde vor allem die Übersetzung der Tags geradezu falsch, ist aber so gewollt. Es gab dazu schon einige Diskussionen bei den Entwicklern, daher ist da wohl auch keine Änderung zu erwarten. Ich verwende daher immer “English” als Sprache.
hier auch English weil die deutschen Übersetzungen mehr schaden als helfen. Sorry, weil das leider dem OP auch nicht weiterhilft…
Habt ihr da beispiele? Ich nutze JOSM von Haus aus immer auf Englisch…
Ist das wirklich so gewollt?
Zum Beispiel steht in Listen dann Gebäude statt building oder Grenze statt boundary, ein highway=footway wird als “ausgewiesener Fußweg” gelistet und ähnliches.
Kann man einfach ausprobieren, wenn man JOSM mit dem Parameter --language=de startet.
Warum stört mich das? Weil ich finde, dass Anwender die Tags kennen lernen sollten, die man dann auch im Wiki wiederfindet.
Es gibt aber eben auch die Ansicht, dass Anwender, die evtl. kein Wort English verstehen, mit übersetzten Tags besser zurechtkommen.
Ich halte den Einwand für falsch.
Ja, es gab mal eine Zeit, vor mehr als ein Jahrzehnt in der Zwischenzeit, da war es nicht nur nötig die Bedeutung eines Schlüssels und Wertes zu kennen, sondern auch den genauen Wortlaut so dass man es händisch eintragen konnte. Die Zeiten sind schon lange vorbei, und wenn man tatsächlich mal den rohen Wert den wir in den Daten speichern braucht, dann kann man es ja nachschlagen.
Im Gegenteil, dass sich versteifen darauf, dass die Werte genau passen, keine Tippfehler oder andere Schönheitsfehler haben führt zu so fatalen Unsinn wie wir es gerade mit dem Tagging von Packstationen erleben.
Ja, ich kenne die Argumente und bestreite auch gar nicht, dass es für viele einfacher ist.
Mein Einstieg in OSM war wohl eher ungewöhnlich. Ich habe mir einst ein Garmin Oregon 300 gekauft und war dann ziemlich unangenehm überrascht, als ich festgestellt habe, dass ich mit der vorinstallierten Karte keine Routenplanung machen kann.
Bei der Suche nach Hilfe bin ich auf mkgmap gestoßen. Meine ersten Versuche, damit eine Karte zu erstellen, gingen wegen Speichermangel schief. Also habe ich mir die Sourcen angeschaut und auf diese Art tags wie highway=secondary oder kennengelernt. Ich habe mir aber nie wirklich Gedanken über eine exakte deutsche Bezeichnung gemacht.
Als ich dann irgendwann in JOSM oder iD die Übersetzungen gelesen habe, musste ich mir die immer erst wieder ins (OSM) Englisch zurückübersetzen bzw. habe das manchmal gar nicht geschafft. Da war die Umstellung auf English deutlich einfacher 
So ähnlich geht es mir auch. Genau deswegen habe ich gefragt. Ich überleg (noch) mal, ob ich nicht auch komplett auf Englisch wechsele, wenn es da keine Möglichkeit gibt.
das Vertippen war auch vor 15 Jahren schon gelöst, indem man Autocompletion verwendet. Klar, es gab gelegentlich mal seltene Ausrutscher, z.B. dass man sich vertippt hat bei einem noch ungenutzten tag und sich das dann falsch in die lokale Vorschlagsliste eingeschlichen hat, aber praktisch immer hat sich das dann über kurz oder lang wieder ausgebügelt. Man bekommt ja auch keine Rückmeldung wodurch bei dargestellten tags (icon, render, etc.) eine wirksame Kontrolle bereitsteht.
Presets zu benutzen dauert halt in der Regel länger als die passenden tags zu setzen, wenn man sie kennt. Im Grunde traue ich den presets auch nicht, insbesondere bei iD würde ich allein aus diesem Grund schon davon absehen, aber selbst auf dem Smartphone geht es schneller, die Tags per autocompletion / Auswahlliste und Eingabe des Taganfangs einzugeben, als sich mit Presets rumzuschlagen. Gibt nur wenige fails, namentlich die Adress-tags, die einem durch ihre Struktur die Autocompletion “versauen”, auch die lifecycle-tags fallen in diese Kategorie. Gut, dass sich das namespacing “aus Prinzip und nicht nur bei Notwendigkeit” bisher nicht durchgesetzt hat.
Nachtrag: Richtig falsch ist es aus meiner Sicht dann, wenn z.B. ein highway=tertiary in z.B. Indien oder Australien als Kreisstraße angezeigt wird. In D mag das helfen, im Rest der Welt ist es mindestend sehr verwirrend.
Steht da mittlerweile echt “Kreisstraße”? Darüber hat man früher endlos diskutiert und es wurde von manchen strikt abgelehnt (weil es ja auch inhaltlich z.T. falsch ist). Auch in D. gibt es Kreisstraßen mit höherer Klasse, und tertiary mit anderem Baulastträger als dem Landkreis.
Standortabhänige (Standort des Objektes) Vorlagen sind schon jahrelang Stand der Kunst.
Die englischen Bezeichnungen wie “highway” darf man ja nicht wörtlich nehmen und die deutschen Übersetzungen (presets) erst recht nicht.
Woanders steht auch “trunk”, was bei uns als track mit grade5 durchgehen würde.
OSM verwendet de facto eine eigene Sprache mit aus dem Englischen entlehnten Wörtern.
Verstehe ich nicht ganz. Wird dann je nach Region eine andere Bezeichnung plus Übersetzungen verwendet? Dachte, dass bezieht sich eher auf Tags, wie unser gemeinsam benutzter path.
Ja, deshalb wäre eventuell eine Option für keine Übersetzung der Tags eine Möglichkeit, damit die Gui weiterhin in der lokalen Sprache ist, aber die Daten im “Original” angezeigt werden.
Das vermindert zwar die Gefahr von irreführenden Übersetzungen, erhöht aber gewaltig die Schwelle für nicht-englisch-Sprechende.
Die müssten sich dann zumindest am Anfang jedesmal die deutschsprachigen Erläuterungen im Wiki dazu ansehen. Das ist für mich ein Ausschluss-Kriterium, fast so gravierend wie eine rein englische Nutzeroberfläche.
Übersetzte Tags sind kein Hinderungsgrund für sorgfältigere Übersetzungen. Ein “wie Kreisstraße” würde ja z.B. viele Irritationen beseitigen, die man auf den ersten Blick hat.
Da, hast Du mich wohl falsch verstanden. Ich gehe von einer zusätzlich einschaltbaren Option aus und nicht als Ersatz für Übersetzungen.
Gute Übersetzungen sind nicht immer einfach und machen einiges an Arbeit, sind aber wichtig. Was meistens noch erschwerend hinzukommt, ist dass wir keine wirkliche Struktur bei der Übersetzung haben. Im Wiki werden die Tags auch nicht übersetzt, somit backen halt viele ihre eigenen Brötchen, was aber auch mehr Arbeit beim Übersetzen macht und die Qualität nicht steigert, wenn für jede Software erneut übersetzt wird.
Als Tipp noch die Taste “F1” generell und insbesondere auch in der Tagliste, wenn ein Merkmal markiert ist.
Es gibt 2 Aspekte
-
die Übersetzung, die von den Spracheinstellungen des Betriebssystems oder der Applikation abhängt. Je nachdem, speziell wenn es Unterschiede innerhalb der gleichen Sprache gibt die berücksichtigen, z.B. de_DE vs. de_AT vs. de_CH (Beispiel Straße vs. Strasse).
-
die eigentlichen Vorlagen. Möchte ich jetzt highway=tertiary “korrekt” übersetzen, so kann ich eine Vorlage “District road” erstellen die auf DE beschränkt ist, die dann auch ohne Spezialwissen übersetzt und korrekt angewendet werden kann. Ausserhalb von DE ist das einfach eine “Tertiary” die man dann mit “Drittklassige Strasse” oder was auch immer übersetzt.
Simon
PS: typischerweise braucht man die Standortkonfiguration in Vorlagen um regionale Taggingunterschiede festzumachen, aber dass kann schlussendlich auch der Name sein.
Hi@all;
auch im ID-Editor in meinem Firfox Browser an meinem Bürorechner wird keine Übersetzung mehr angeboten. Und das sieht doch ziemlich ätzend aus… Würde gerne einen screnshot posten…
Komischerweise funzt der Editor an meinem Rechner zu Hause normal…
Martin.
Nachtrag: Scheint irgendein merkwürdiger bug in meinem Firefox Broswer zu sein; habe gerade Microsoft Edge getestet: da funktioniert auch alles einwandfrei:rolleyes: