Wenn man z.B. eine Navi baut und die text to speech Technik verwendet, sind die Ergebnise ziemlich fürchtbar.
Hätte man zusätzlich zu dem Namen auch z.B. name_spoken:* verwendet, so wäre die Qualität der Sprachansagen für eine OSM Navi schlagartig besser.
Mehr noch: Navi für Blinde hätte gleich eine ander Qualität.
Da es sich nur um die Orts und Straßennamen handelt, könnte es vielleicht machbar sein. Was glaubt ihr?
Umgesetzt nicht. Das erste und größte Problem ist wohl, dass kaum ein Mapper die phonetischen Alphabete beherrscht. Das gilt für IPA, aber sicher auch für SAMPA (danke, kannte ich noch nicht).
Ich hätte ein Suffix wie :spoken oder :phonetics vorgeschlagen, das man bei Bedarf dann auch an andere Tags anhängen könnte.
Hi Chris,
ich habe damit noch gar nicht nicht gespielt: Es gibt zwar die Seite mit dem Übersetzer: http://familientagebuch.de/rainer/2007/38.html#4
aber ich befürchte selbst dass dies eine Sache für Freaks ist. Aber wer weiß. Man müßte ein kleines Testgebiet taggen und in einer Testsoftware (keine Ahnung ob´so Etwas open source gibt) testen…
@ Walter: Ja, ist richtig. IPA ist mehr verbreitet. Wenn man sich für ein System entscheiden würde dann eben nur einmal…
Hmm…ich sehe das auch eher in einer externen Datenbank, wenn es nicht sogar schon Projekte gibt, die sowas gemacht haben. Das dürfte deutlich effizienter und robuster sein.
Wie häufig haben wir bspw. die Zeichenkette “Straße”, “Weg”, "Aldi"etc. in unseren Namen. In einer externen DB gibt es dann eine Zuordnung, bei einer internen DB hätte man n-mal eine solche Zuordnung.
Interessante Idee, das wäre wirklich eine große Verbesserung bei der Sprachausgabe. Mal ganz davon abgesehen, dass es teilweise recht schwierig ist, die Aussprache eines Namens aus der geschriebenen Variante abzuleiten. (Man denke an Worcester oder den Unterschied zwischen täuschen und Mäus(-)chen - was ja beides in Namen vorkommen kann.)
Ich wäre auch für name:ipa und Varianten wie name:de:ipa, denn da weiß man gleich, welches phonetische Alphabet benutzt wird.
[ font = Fraktur]
Dieſes Problem müſſte es in der deutſchen Sprache eigentlich nicht geben, da gab es mal ſehr eindeutige Regeln, die zwiſchen täuſchen und Mäuschen prima unterſcheiden konnten! [/font]
Als Quelle könnte man (noch! CC) Wikipedia nehmen, da gibt’s zu vielen Ortsnamen schon IPAs:
“Karlsruhe [ˈkaʁlsˌʁuːə] ist …”
Dann bräuchte man noch die IPAs für Goethe, Schiller, Adenauer, … und der wichtigsten Blumen und Tiere samt Abwandlungen für “Karlsruher …”, dann hätten wir auch gefühlt 95% aller Straßennahmen
Hi Mueck,
es gibt da noch ein Aspekt, mit dem wir punkten können: die Dialektausgabe.
Etwa die name:de:[hier Platzhalter für ein Region]:ipa
Das wissen ja alle die in einer Region leben und die regionale Aussprache ist oft deutlich anders als Hochdeutsch.
Ich kann jetzt über die Arbeit der Profis wenig aussagen, aber mir scheint zumindest in der Allgemeinbevölkerung eher IPA bekannt zu sein. Da die Datenbank und allen nennenswerten Editoren Unicode unterstützen, sind wir auch an sich nicht auf ASCII-Zeichen beschränkt. Ich gebe allerdings zu, dass es für Ottonormalanwender komplizierter ist, die IPA-Zeichen einzugeben. Trotzdem wäre ich einer Verwendung von IPA bei angemessener Unterstützung durch die Editoren (zusammenklickbar, am besten inklusive Testinterpretation) eher zugeneigt.
Kommt drauf an, was für Profis und was für Anwendungsfelder. SAMPA ist nur eine Teilmenge von IPA, die sich in ASCII ausdrücken lässt. Es wurde erfunden, um eine begrenzte Anzahl europäischer Sprachen mit einer Standardtastatur leicht und schnell phonemisch schreiben zu können. Wenn es aber um die Aufzeichnung beliebiger Sprachen geht, dann ist IPA meilenweit überlegen. Für OSM kann nur IPA in Frage kommen, denn OSM steht ja für alle Sprachen der Welt offen und die lassen sich nur mit IPA korrekt wiedergeben.
Die Idee finde ich definitiv gut. Eine ähnliche Datenbank besteht übrigens mit der Aussprachedatenbank der ARD, die ca. 290.000 Einträge hat (wovon aber nur ein Teil aus dem Bereich Geografie stammt). Allerdings gibt es, soweit ich weiß, keine Software, die IPA als Audio ausgeben kann. Da müsste also erst etwas entwickelt werden, bevor daraus wirklich Nutzen gezogen werden kann.
Ohne davon eine genaue Ahnung zu haben, nehme ich an, dass es eher leichter als schwieriger wäre, Software für die Audioausgabe von IPA (oder im Zweifelsfall SAMPA) zu entwickeln, als das für reale Sprache der Fall ist. Außerdem könnte ich mir vorstellen, dass es möglich ist, IPA Zeichenketten in ‘normale’ Zeichenketten umzuwandeln, die in einer Sprache, die eine Ausgabesoftware (z.B. auf einem Navi, wo ich sie nicht wirklich verändern kann) beherrscht, so ausgesprochen werden, dass sie den IPA Zeichenketten entsprechen. Also, wenn man ein englisches Navi hat, würde man die IPA Zeichen in ASCII transformieren, dass die englische Ausgabesoftware korrekt ausspricht, wenn mein ein chinesisches Navi hat, würde man sie in chinesische (Unicode-)Zeichen transformieren, die mit der chinesischen Software einigermaßen korrekt ausgegeben wird usw.
Beliebige IPA-Zeichenketten in ASCII umzuwandeln, damit sie von einer Sprachausgabe richtig ausgesprochen werden, die sich an die Ausspracheregeln einer bestimmten Sprache hält, halte ich für sehr schwierig bis unmöglich. Zumindest sehe ich keine Möglichkeit, wie man einem deutschen Sprachausgabeprogramm ein britisches th entlocken kann - genau so wenig, wie man ein deutsches ü oder ö aus einem britischen Programm zaubern sollte…
Ja, aber das Problem, dass in bestimmten Sprachen nur ein begrenztes Lautspektrum vorhanden ist, hast du immer. Normal wird ein Programm versuchen, die Zeichenkette so zu interpretieren, als wäre es eine Zeichenkette der Sprache, in der es angewiesen ist, zu arbeiten (es sei denn, es wäre so intelligent, um zumindest gewisse Fremdwörter bzw. Laute zu erkennen und für diese dann umzuschalten - dann gibt es das Problem aber für diese Laute auch nicht). Mit einer Umwandlung aus den IPA Zeichen könnte man es zumindest zwingen, möglichst ähnlich klingende Laute zu verwenden. Was auch den Vorteil hat, dass auch Zeichen, die in einer Sprache nicht vorkommen, verarbeitet werden können: Ein deutsches System würde aus einem englischen th vielleicht noch etwas akzeptables herausholen können. Aber ob es ein isländisches Thorn Þ überhaupt interpretieren kann, wage ich zu bezweifeln. Aus den IPA Zeichen würde sich das aber zumindest in etwas umwandeln lassen, was ausgesprochen werden kann, auch wenn der Laut vielleicht nicht ganz dem entspricht.
Sicher wird eine deutsche Sprachausgabe irgendwas aus ASCII-Zeichen machen und irgendwelche Laute ausgeben - aber ob die dann auch wirklich so klingen, wie es der Phonetik nach sein sollte, ist eine ganz andere Frage… Deshalb halte ich es für deutlich sinnvoller, lieber gleich die IPA-Zeichen in eine geeignete Sprachausgabe einzufüttern, die damit etwas anfangen kann. Wenn es sowas noch nicht gibt, könnte man z.B. mal bei den Entwicklern von espeak anfragen, ob es denkbar wäre, sowas einzubauen - immerhin kann espeak bereits IPA ausgeben.
Mal ganz davon abgesehen stelle ich es mir auch eher problematisch vor, die phonetische Namensbeschreibung irgendwie so in eine Karte zu übernehmen, dass ein (bereits existierendes) Navi sie irgendwie auswertet. Damit ein deutsches Navi einen “International Airport” richtig ausspricht, hat man wohl keine andere Wahl, als ihn in der vom Navi genutzten Karte “Interneschenell Ährport” zu nennen, da so ein handelsübliches Navi eben das gleiche spricht, was es auch anzeigt… Um sowohl die schriftliche als auch die phonetische Information in einer Karte zu haben und von einem Navi auswerten zu können, wird man wohl nicht vermeiden können, die Navi-Software selbst zu schreiben, und dann kann man eben auch gleich eine IPA-Sprachausgabe einbauen.
Ich habe den Wiederspruch mal hervorgehoben. Erst bezweifelst du das Ascii Zeiechen zum Erfolg führen und dann nutzt du sie genau dafür. Ja man wird entweder die Software für die Navigation neu schreiben müssen oder ebend für navigeräte den Name Schlüssel bei der Kartenerstellung ersetzen müssen. Allerdings rate ich dringend davon ab bereits in der OSM Datenbank solche Namen zu verwenden. Dafür diskutieren wir ja gearade über den neuen Schlüssel, welcher dann diese Information aufnehmen soll.
Eben, als Gegenbeispiel, um zu verdeutlichen, dass man sowas nicht in eine bestehende Navi-Software hineinprügeln kann, ohne dabei Probleme zu bekommen.
Natürlich kann man manche Laute aus einer anderen Sprache passend durch ASCII umschreiben, aber eben nicht alle, siehe mein Beispiel zum britischen th im deutschen Navi. An dieser Stelle ist es hilfreich, auch meine vorherigen Beiträge zu lesen und zu berücksichtigen.
Wobei letzteres dann in einer visuellen Kartendarstellung auf dem gleichen Navi sehr merkwürdig aussehen würde - genau deshalb ja mein Gegenbeispiel.
Das ist doch genau mein Reden und der Grund, warum ich IPA-Zeichen befürworte.
