Am 24.06.2013 17:31, schrieb Peter Wendorff: > Und ich, der ich weder Französisch noch Holländisch spreche, kann den > Namen gar nicht mehr eintragen, weil ich nicht weiß, was davon welche > Sprache ist.
Dann wäre es aber sinnvoll, wenn du es erst gar nicht eintragen würdest. Ich würde auch mal behaupten, dass der Anteil der ausländischen Nutzer, die nicht in ihrem Heimatland mappen und von den dortigen Landessprachen absolut keine Ahnung haben, unglaublich gering ist. Und ein Einheimischer kann das normalerweise sofort unterscheiden. Mal davon abgesehen ist das auch für einen Nicht-Einheimischen recht klar (Dass „Quai de Mariemont“ Französisch ist, und „Mariemontkaai“ Holländisch ist ja doch schon recht ersichtlich). > ? Wenn ich in Tansania bin, kann ich die Schrift lesen, und oft ist das > sogar sehr einfach, weil viele afrikanische Sprachen, wenn sie > geschrieben werden, recht nah an der Lautschrift in lateinischen > Buchstaben geschrieben werden. > Aber in Tansania werden über 100 Sprachen gesprochen. Bei einem Namen an > einem Laden irgendwo Abseits der Städte wäre ich mir also nicht sicher, > dass das wirklich Suaheli ist, obwohl Suaheli die > de-facto-Nationalsprache ist. Das stimmt natürlich, allerdings könnte das ja ein Einheimischer machen. Trennen musst du das ganze ja so oder so: Es gibt ja jetzt auch schon andere Tags wie name:suaheli oder name:xulu (Ich kenne gerade die Codes nicht). Die sollten doch auch genutzt werden, oder nicht? Das ist ja im Grunde auch der Kern des ganzen Problems: Die entsprechen name:xx-Tags werden nicht genutzt, weil alles in name hineingeschrieben wird. Aber es ist doch sinnvoll, getrennte name-Tags zu haben, oder? Ein Suaheli-Nutzer würde halt gerne nur alles in Suaheli sehen. Wenn aber die Namen nur in „name“ stehen, dann kann man das nicht trennen. In deinem speziellen Fall kann man das ja auch einfach in den Kommentar schreiben, mit der Bitte, dass jemand Kundiges das später trennt. > Und wem willst Du Feuer machen? Der Software? Den Entwicklern? Die sagen > dir dann zurecht, dass du warten musst oder es selbst umsetzen sollst - > sonst machen sie das, wenn sie wollen - und das IMHO zurecht. Natürlich, aber man kann dann natürlich auch einfach sagen: „In einem Jahr wird es so nicht mehr funktionieren. Wenn deine Software dann nicht mehr geht, hast du Pech. Änder was dran.“ So funktioniert halt technischer Fortschritt: Ohne Anpassung geht nichts. Ein Netscape Navigator 1.0 wird mit der aktuellen OSM-Seite auch nichts mehr anfangen können. Besonders bei Open-Source-Projekten fällt mir allerdings auf, dass man immer krampfhaft versucht, jede Software zu unterstützen, und es so gar nicht voran geht. Wie gesagt, das muss nicht von heute auf morgen geschehen, aber wenn da mal ein anständiger Plan existiert, der vernünftig kommuniziert wird und auch mit einer großzügigen Zeitspanne, dann sehe ich da eigentlich nicht wirklich ein Problem. Aber nun gut, ich gebe zu, es ist komplizierter als ich gedacht habe. > Wenn name:de nicht existiert, name nicht mehr "Mariemmont/Mariemontkaai" > enthält und in meinem Browser weder Französich noch Holländisch als > akzeptierte Sprache definiert ist - was soll die Karte dann denn zeigen? > Irgendjemand wird das entscheiden müssen, und die Konflikte gehen von > vorne los, nur dass jetzt nicht mehr Mapper untereinander einen Konsens > finden müssen, geschweige denn regional, sondern die Entwickler des > Kartenstils sind an allem Schuld. Ich glaube nicht, dass das wirklich > viel besser macht. Das stimmt zwar, aber in dem Fall kann man den name-Tag (bzw. die Anzeige, nicht den Tag selber) ja automatisch generieren lassen. Ich würde mal sagen (ohne es jetzt genau zu wissen), dass es einem Belgier völlig egal ist, wie der name-Tag aufgebaut ist, wenn er normalerweise eh nur den französischen Tag sieht. Ich kenne das von Japan her: Da steht im name-Tag aller möglicher Schranz, weil die Einheimischen eh nur der name:ja-Tag interessiert. Das ging doch auch schon in diesem Test von dem mehrsprachigen Render: name:fr / name:nl (oder so ähnlich), und dann wurde einfach beides dargestellt. Am 24.06.2013 17:31, schrieb Peter Wendorff: > JOSM kann erweitert werden - schreib das Plugin dafür! Typisches Open-Source-Problem: Nicht jeder Benutzer/Teilnehmer an einem Projekt kann programmieren. Selbst wenn man es kann, kann man es vielleicht nicht gut genug für das spezielle Problem. Ich predige das andauernd und ständig: Manche Leute haben halt ihre Fähigkeiten in einem anderen Fachgebiet und verdienen damit gut ihr Geld. Sie wären völlig bereit, jemanden monetär zu vergüten, wenn er eine gewünschte Funktion einbaut. Leider gibt es die Möglichkeit bei OSM z.B. absolut gar nicht. Ich wäre sehr dafür, dass es mal einen Spendenaufruf wie 1x jährlich bei Wikipedia gäbe, der allerdings nicht (nur) in die Server fließt, sondern auch ganz banal mal in die Software (besonders OSM.org; JOSM ist ja schon ganz gut, auch wenn dort manche Verbesserungen gebraucht werden könnten). Dass OSM.org von den Funktionen gegenüber jedem Konkurrenzprodukt absolut versagt, braucht man ja wohl niemandem zu sagen. Und auch wenn das die ganzen „OSM ist nur eine Datenbank!!!!11“-Nutzer nicht glauben wollen: Die Leute kommen und bleiben wegen osm.org beim Projekt. Wenn die Webseite schon schlecht ist, bekommt man keine Nutzer. Und mehr Nutzer heißt auch mehr Bearbeiter -> besseres Kartenmaterial. Selbst wenn OSM keine Organisation zur Verwaltung der Finanzen hat, wäre es vielleicht interessant, bei so etwas eine Kooperation mit irgendeiner anderen Organisation einzugehen: Free Software Foundation eventuell. > Siehe http://wiki.openstreetmap.org/wiki/Names#Localization > z.B. name:ko_rm > Generell ist jedoch auch hier wieder fraglich, ob die romanisierte > Variante in den daten stehen muss. Zumindest für Sprachen, denn sie > könnte auch generiert werden. Die kann aber nicht immer fehlerfrei generiert werden. Es spricht nichts dagegen, sie automatisch zu generieren, aber sie sollte dann zumindest zur Bearbeitung offen sein. Deswegen sollte sie auch gerne schon in einem Tag gespeichert werden. Und ja, sowas wie ko_rm oder ja_rm o.ä. gibt es – Wird aber in der Praxis nur sehr wenig angewandt. In praktisch allen Fällen wird name:en für sowas verwendet, obwohl es eigentlich gar kein Englisch ist. > Schonmal probiert, dann das richtige Straßenschild zu finden? Viel Spaß, > wenn du "Sapporo" auf den Straßenschildern wiederfinden willst, die mit > japanischen Schriftzeichen geschrieben sind. > Was da also sinnvoll ist, ist stark vom Nutzungsszenario abhängig. In den allermeisten Ländern ohne lateinische Schrift gibt es immer eine Umschrift mit lateinischer Schrift auf dem Schild, so auch in Japan. Und derjenige, der die ursprüngliche Schrift nicht lesen kann, kann auch mit „Ich vergleiche mal“ nichts anfangen. Eine Schrift, die man nicht gelernt hat, ist so etwas von unübersichtlich, so dass sie einfach überlesen wird. Selbst wenn du vergleichen möchtest, ist es unmöglich. Du kannst mir nicht erzählen, dass du dir bei einem arabischen Straßenschild die arabische Schrift merken kannst. Die wird einfach als undefinierbares Zeichengewurstel vergessen. Daher ist die Sache, dass man auf einer Landkarte gerne doch nur das haben möchte, was man auch lesen kann: Wenn ich in Ägypten bin, interessiert mich eine Karte mit zusätzlich eingeblendeten arabischen Zeichen absolut null: Ich kann damit gar nichts anfangen. Ich möchte gerne komplett alles in Umschrift haben. Das macht die Karte auch übersichtlicher, da ich nicht komische Zeichen auf der Karte habe, die Platz wegnehmen. Umgekehrt möchte ein Ägypter ungern Umschrift sehen. > Sicher? Wieso? name:ja=札幌 name:ja-rm=Sapporo name:zh=札幌 name:zh-rm=Zhazhuang Ein Chinese schreibt genau wie ein Japaner. Er wird also Japanisch lesen wollen, nicht eine Umschrift (vorausgesetzt, es gibt keinen dedizierten name:zh-Tag). Du liest dir ja auch keine griechische Umschrift von „New York“ durch. Davon abgesehen wäre eine Umschrift gar nicht das, was er kennen würde: Er kennt Sapporo nur als Zhazhuang, nicht als Sapporo (will ich hier nicht weiter ausführen). Die Sache ist jedenfalls, dass manche Länder nicht unbedingt die Romanisierung als „internationale“ Schrift gebrauchen können. Das führt dazu, dass z.B. ein Tag namens name:international unbrauchbar ist... > Die Aussprache kann sich erheblich unterscheiden, sodass ich das nicht > sicher als gegeben nehmen würde, und wenn wir die Schriftarten > weglassen: Als Deutschsprachiger Nutzer möchte ich in den ehemals > französischen Afrika-Kolonien deshalb noch lange nicht lieber den > französischen Namen von Orten und Straßen lesen, sondern den in der > entsprechenden Landessprache, wenn auch natürlich bevorzugt so, dass ich > ihn lesen kann (also die romanisierte Schreibweise, falls notwendig), > und im ehemaligen Ostpreußen möchte ich ehrlich gesagt die alten > deutschen Namen nicht sehen - höchstens zusätzlich, aber sicher nicht > als den einzigen mir präsentierten Namen. Ehrlich gesagt finde ich, dass solche speziellen Anforderungen gerne aufs Nutzerprofil ausgelagert werden können. Es gibt eine Vorlage, und man kann sich die im Nutzerprofil dann gerne einstellen. Ich z.B. hätte folgende Anforderung: 1. Wo es geht, Deutsche Namen 2. Gerne auch in Polen (Aber nicht bei ganz kleinen Städten, nur bei +100.000 Einwohnern, als Beispiel) 3. In Japan hätte ich gerne weder deutsche noch englische Namen, sondern in Japanisch, zusätzlich darüber name:ja-Furigana. 4. In englisch- und französischsprachigen Ländern die Originalsprache. Klar, alles sehr... speziell. Aber für solche Zwecke gibt es doch OSM, wo man selber einstellen können sollte und nicht Google Maps, wo alles vorgegeben wird. Wäre bei einer vernünftigen Implementierung sicherlich möglich (Dass das nicht mal „eben“ möglich ist, ist auch klar, aber dafür könnte man ja Spenden sammeln). Das wäre natürlich für den Normalnutzer zu kompliziert, aber man könnte z.B. bei einem Nutzerprofil abfragen, welche Sprachen man lesen kann und dann wird automatisch ein derartiges Profil generiert. Oder auch einfach irgendwelche Vorlagen zum Angebot. Die meisten Leute werden ja die gleichen Anforderungen haben (z.B. so wie du). Das heißt, dass die Vorlagen einmal halbwegs qualifiziert ausgearbeitet werden würden und anschließend übernommen werden würden. Man könnte ja beispielsweise erst einmal eine allgemeine Welt-Vorlage vorbereiten (z.B. dass in Deutschland name:de benutzt wird, in USA name:en, in Flandern name:nl, in Walonien name:fr, in Brüssel name:fr / name:nl, in Taiwan name:zh-Hant, in China name:zh-Hans, in Japan name:ja, in Kanada name:en, in Quebec name:fr...). Anschließend übernimmt jedes Sprachprojekt (also z.B. Deutschland) diese allgemeine Vorlage und passt sie an: In jedem Land soll zuerst name:de dargestellt werden, als Fallback dann die jeweilige Landessprache (sprich die allgemeine Welt-Vorlage), _es sei denn:_ die Landessprache wird nicht in lateinischen Buchstaben geschrieben (Dafür kann man ja eine Liste erstellen, welche das genau sind), dann nehme die entsprechende Romanisierung. Klar ist das Arbeit, klar dauert das seine Zeit. Das finde ich aber alles wesentlich sauberer als heutzutage mit name. > Das ist aber keine Kleinigkeit: > OSM soll ja vor allem auch z.B. in Navigationssystemen eingesetzt > werden, und die sollten bitte nicht "La Petite Franze" (mit stimmhaftem > e natürlich) lesen, sondern "La Peti Frongz" oder so ähnlich, weil es > eben französisch ist - und auch in einem deutschen Textkontext > französisch bleibt. Wäre da nicht eher eine Notierung mit IPA (Lautschrift) das sinnvollste? Das Problem hast du selbst bei deutschen Namen: Ich denke mal, jeder Screenreader wird in „Mecklenburg“ das eck kurz aussprechen, nicht lang (es ist ja ein Dehnungs-c), wenn er da keine Ausnahme für hat. Und da muss er ja viele Ausnahmen für haben. Deswegen wäre es dafür dann sinnvoll, einfach einen Tag name:de-ipa=la pətit ˈfran.t͡se zu erstellen. Bei einem name=La petit france wüsste der Screenreader ja auch nicht, wie er es aussprechen sollte. Das wäre nur bei name:fr=La petit france möglich, was aber in Deutschland dann einfach ignoriert werden würde. > Oder hattest Du Vorteile genannt, die ich übersehen habe? Vor allem die: So lange es name gibt, wird nichts anderes genutzt. Allerdings muss ich zugeben, dass ich bei der letzten Diskussion auch noch die gleiche Position wie du vertreten habe :D In der Zwischenzeit habe ich mir das aber noch mal überlegt. > - In Editoren sollte sinnvollerweise eine einfache Möglichkeit > geschaffen werden, mehrsprachige Varianten tabellarisch zu erfassen. > Helfen willst du dabei nicht, weil du nicht genug programmieren kannst. Ich will natürlich. Würde ich lieber machen als immer nur darüber zu reden ;) Aber ich kann es halt einfach nicht. > P.S.: Java ist nicht sooo schwierig, JOSM ist open-source, und ein > Plugin macht erstmal nichts kaputt außer möglicherweise bei dir lokal. > Ein zusätzliches Spezialtool, das nur deine tabellarische > Übersetzungsarbeit erlaubt, wäre ja auch möglich. Ich bringe mir nach langer Programmierpause im Moment wieder etwas Programmieren mit Python bei. Und selbst dort habe ich schon bei einfachen Sachen zu kämpfen, einfach weil ich in das Programmieren hineinkommen muss: Wie geht man ein Problem am schnellsten an, was gibt es für Möglichkeiten usw. Bei JOSM ist allerdings das Problem, dass es ein bereits bestehendes Projekt ist: Da überhaupt mal durchzusteigen ist prohibitiv schwer. Ich wollte z.B. mal bei Scribus was verbessern, aber ich habe mir den Quelltext angeschaut und wusste nicht einmal, wo ich anfangen sollte zu gucken. Gut, JOSM ist jetzt vielleicht nicht so komplex wie Scribus, aber überhaupt anzufangen ist auch schwierig. Ganz ehrlich: Da würde ich lieber 50€ (oder sogar noch mehr) spenden, wenn es dann jemand anders für mich übernehmen würde, der schon in der Materie drin ist (Vorausgesetzt ich hänge wirklich so stark an der Funktion). In der ganzen Zeit, die ich bräuchte, bis ich mir beigebracht habe, wie man überhaupt anfangen könnte, habe ich das entsprechende Geld nämlich schon 10x verdient und nutze die Freizeit lieber dazu, meinem richtigen Hobby nachzugehen. > Ja, ich gebe dir recht: Man kann sich darauf einigen, dass lokalisierte > Namen sinnvoll sind. Man kann das auch als gewünscht bewerben, dass > jeder Name zusätzlich lokalisiert vorhanden sein sollte. Naja, dann wäre es aber doch zumindest sinnvoll, wenn zumindest JOSM bei jedem Vorgang einen entsprechenden name:xx-Tag kreiert, oder? Und in mehrsprachigen Gebieten direkt zwei Felder anzeigen würde. Wenn man nämlich in jedem Fall extra einen zweiten name:xx-Tag erstellen muss, dann kann ich vollkommen verstehen, wieso das keiner macht, wenn es nicht notwendig ist. Einen neuen Tag hinzufügen und zu editieren braucht nämlich viel zu viele Klicks. Ich würde im Grunde sagen, dass da direkt ein spezieller Button nur für den Namen interessant wäre. Auf den Knopf drücken, und direkt kommt ein Fenster welches nur die verschiedenen Name-Tags anzeigt: name, name:fr, name:de, name:en usw. Man könnte dann ja in den Optionen konfigurieren, was man genau haben möchte. Naja, gut, aber du hast Recht, die ganze Sache ist doch komplizierter, als ich gedacht habe. _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de