[Talk-de] "Sprache des Namens" Fehler in Kort.

[Hans Schmidt]

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.