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

[Peter Wendorff]

Am 24.06.2013 19:43, schrieb 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).
Dann nimm Holländisch und Belgisch, oder Hebräisch und Arabisch oder
Englisch und Schottisch oder oder oder (und nimm an, du kannst jeweils
keine der Sprachen näher).

Ich gebe dir recht, es ist häufig ersichtlich, was was ist, aber nicht
immer.
Und "dann trag nichts ein" ist eine Möglichkeit - aber das Argument ist
blöd, wenn sonst da auch niemand mapped, und ich die Möglichkeit dazu hätte.
Du versuchst hier, eine Regel festzuschreiben - etwas, das bei OSM ganz
ganz selten und nur mit extrem guten Gründen passiert.
Was aber auch ein Grundsatz von OSM ist - nicht festgeschrieben, aber
vielfach in Tagging-Schemata manifestiert: Wenn ich ein Detail nicht
weiß, sollte ich in der Lage sein, mein nicht-so-detailliertes Wissen
trotzdem beizutragen, z.B. indem ich building=yes eintrage statt
building=residential oder highway=road (wenn ich nicht beurteilen kann,
was für eine Straße das ist).
Das ist nicht perfekt, aber besser als nichts.
name=foo ist nicht perfekt, aber besser als nichts.
Du versuchst das hier umzudrehen: Wenn du die Sprache nicht kennst, lass
den Namen komplett weg. Sorry: Halte ich in der OSM-Kultur schon als
Ratschlag/Hinweis für nicht für akzeptabel, als Regel, die ausnahmsweise
technisch durchgedrückt wird, noch viel viel weniger.

>> ? 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.
Klar. Aber tun sie das?
Haben sie die notwendigen technischen Mittel? Das notwendige Wissen? Die
notwendige Zeit? Die Motivation?
Ist nicht die Karte trotzdem sinnvoll?
> 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.
Dass ein Suaheli-Nutzer nur Suaheli sehen will, halte ich für genauso
ein Gerücht, wie dass ein deutschsprachiger Nutzer nur deutschsprachige
Namen sehen will.
Ich will je nach Anwendung sehen, was mir weiterhilft.
In Frankreich helfen mir Deutsche Namen nicht bei der Orientierung, in
Afrika genausowenig (aber es gibt sowas z.B. aus der
Kolonialvergangenheit durchaus).
Um darüber hier zu reden hätte ich gerne deutsche Namen, aber vor Ort in
Paris suche ich den/die/das Champs-Élysées, und nicht die Schose Lisee,
obwohl ich ungefähr von letzterem hier sprechen würde (ich weiß, das ist
nicht der richtige Wert für name:de, aber ein Beispiel dafür, warum die
lokale Schreibweise wichtig ist).
Du hast recht: wenn die Namen nur in name stehen, kann man das nicht
trennen, aber das verlange ich ja auch gar nicht. Ich sage nur: den
name-Tag zu löschen ist falsch, denn das hilft bei keinem Problem
weiter, und zur Erziehung der Mapper taugen Vorschriften von Tags nicht.

>> 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.“
Klar kann man das, aber
1) Es muss schon verdammt gute Gründe geben, Nutzer zu vergraulen (denn
das passiert, wenn jemand veraltete Software benutzt, die nicht gewartet
wird, oder wenn Programmierer dann eben keine Lust haben, ihre Software
anzupassen), und
2) du vergraulst Mapper, wenn du - auch in einem Jahr erst - alle
name-Tags löschst, die noch nicht von Mappern korrigiert worden sind
(oder falsche Daten erzeugst, indem du das automatisch verschiebst
aufgrund einer irgendwie gearteten Sprach-Auswahl nach Region).

> 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 Evolution funktioniert anders:
Schaffe zusätzlichen Nutzen durch lokalisierte Namen.
Zeige, wo es sinnvoller ist, lokalisierte Namen zu nutzen, und nach und
nach wird die Verwendung zunehmen.
Vielleicht kommt dann auch der Punkt, an dem name nicht mehr benutzt
wird - nur kommt er dann langsam und natürlich, wie das bei der
Evolution eben so funktioniert.
Was du willst, ist Revolution, und das gibt meistens Tote, leider.

> 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. 
Und woraus generieren? Nach der Entscheidung der Stil-Editoren? was
hilft das? Es hat schon (kleinere) Streitfälle gegeben, weil die Namen
in A - B und nicht B - A getagged wurden.

> 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.
Richtig.
Du hast das ja angesprochen, dass die Software existiert, und ja: das
wäre eine gute Möglichkeit, mehrsprachige Namen in OSM zu fördern, nur
erfordert es vermutlich noch 'ne ganze Menge Arbeit oder Rechnerpower,
um dieses System auf den OSM-Tileservern laufen zu lassen.
Aber das ist genau mein Punkt: Wenn die Lösung (Multilingual Maps von
Jochen Topf übrigens) vollständig läuft, einfach aufzusetzen ist (für
eigene Rendering-Stacks) und ohne große Performance-Nachteile auch auf
osm.org eingebaut werden kann, dann ist ein Anreiz da, mehrere Sprachen
zu taggen; aber dafür brauchen wir eben NICHT name löschen.
Wenn eines Tages osm.org eine Möglichkeit bietet, die Sprache der Karte
zu wählen, und da kann ich auswählen, dass ich gerne deutsch bevorzugt,
dann englisch und notfalls halt den allgemeinen fallback (name) hätte,
dann werden Mapper anfangen, name:de redundant in Deutschland
einzutragen, weil sonst überall da, wo name:en dransteht, nur noch
englische Namen angezeigt werden.
Deine Brechstange dagegen (löschen wir halt in 'nem Jahr) führt doch zu
nichts.

> 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).
Du scheinst - auch wenn du deinen eigenen Aussagen zufolge nicht
besonders gut programmieren kannst (das ist kein Vorwurf!) - alles
andere als doof zu sein (Nein, das ist jetzt keine Ironie, sondern ganz
ernst gemeint).
Aber wenn du nicht doof bist, dann kannst du schonmal viel mehr tun als
tiefgreifende Veränderungen durch andere zu fordern:
- Wo ist dein Feature-Request z.B. im JOSM-Bugtracker?
- Wo ist ein Proposal, wie das genau aussehen könnte? (Skizze und etwas
Erklärung hilft oft viel)
- Falls Du etwas programmieren kannst - und sei es PHP oder flash oder
sowas: warum schreibst du nicht mal einen total simplen Prototypen, der
'ne .osm-Datei lesen und wieder schreiben kann? Vielleicht baut jemand
die Datenbank dahinter. Vielleicht auch einfach eine HTML-Seite, die
deine GUI demonstriert.

Der Hinweis "selbst machen" ist manchmal gemein, das stimmt. Aber die
Rückfrage hätte konstruktiv lauten können: Ich kann kaum programmieren -
kann ich sonst was dafür tun?

> Dass OSM.org von den Funktionen gegenüber jedem Konkurrenzprodukt
> absolut versagt, braucht man ja wohl niemandem zu sagen.
Bei welcher Definition von "Konkurrenzprodukt" bist du denn?
Was ist denn das "Produkt OSM", zu dem es ein besseres Konkurrenzprodukt
gibt?

> 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.
Also über zu wenig Nutzer können wir uns glaub ich eigentlich nicht
beschweren.
Über zu wenig Mapper vielleicht - aber soo schlimm sieht es da auch
nicht unbedingt aus.

> 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.
Zum Beispiel beim Google Summer-of-Code gibt es das durchaus regelmäßig.
Du kannst da also beim nächsten Mal sowohl Projektideen gerne einreichen
als auch dich als Mentor melden, um das Projekt dann zu betreuen.
Allerdings braucht es auch dazu mehr als eine Mail "macht mal".

>> 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.
Und du meinst, das könntest Du ändern, indem du name ganz rausnimmst?
Ehrlich gesagt: ich glaube nicht.

>> 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.
Merken bestimmt nicht, aber wenn ich den arabischen Schriftzug auf der
Karte dabeihabe, kann ich vergleichen. Umständlich, aber möglich.

> [...]
> 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.
Jetzt bist du aber eben wieder bei osm.org - und ob es DAS dafür gibt,
ist eben nicht für alle so klar.
osm.org ist eben KEIN Konkurrent zu Google Maps, sondern sollte
Informationsportal zum Projekt Openstreetmap und ein bisschen Karte
dazu, die außerdem vor allem schnell aktualisiert wird und für Mapper
tauglich, nicht unbedingt die beste Kartographie mit auch nicht ein
Informationsportal wie Google Maps es sein will.
OSM ist kein Konkurrent zu Google Maps, sondern zu Navteq und Teleatlas,
den Datenlieferanten. Wenn das Frontend osm.org auch als teilweiser
Ersatz von Google Maps dient - um so besser.
> 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). 
Apropos: Hast du schon gespendet? www.donate.openstreetmap.org - und
dabei reden wir nur vom Server für den absehbaren Bedarf bei aktuellem
Wachstum und Co, nicht (unbedingt) über grenzenlos zusätzliche
Funktionalitäten.
> 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 haben wir bisher eben nicht in Sachen Sprachen, aber durch erstmal
vier Kartenlayer.
Mehr sind möglich, aber wie du vielleicht schon festgestellt hast, sind
auch diese vier aus gutem Grund nicht alle von osm.org selbst gehostet.
Eine mehrsprachige, auf Nutzeranforderung hin gerenderte Karte ist aber
nochmal was ganz anderes, da funktioniert unter anderem die
CDN-Architektur, die bisher für Tiles verwendet wird, nur noch sehr
eingeschränkt. Das also einzubauen dürfte nicht ganz ohne sein.

> 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...).
Mach doch! (Nein, das erfordert praktisch keine Programmierkenntnisse,
höchstens ein paar Fragen und ein paar Seiten einlesen, dann ist das mit
carto-CSS und Tilemill nicht so schwer, sich da einzuarbeiten).

> 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.
Dann solltest Du das vielleicht mal in die Wege leiten - BEVOR du name
löschen lassen willst.
Denn das schließt sich doch nicht aus.
Vielleicht findest Du ja Unterstützer, die das mitmachen wollen - und
auch umsetzen.

>> 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.
...das kaum noch jemand korrekt schreiben kann. (aber sonst keine
schlechte Idee)

> 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.
Würde es das?
Als einzigen name-Tag würde ich es durchaus grundsätzlich benutzen.

>> Oder hattest Du Vorteile genannt, die ich übersehen habe?
> Vor allem die: So lange es name gibt, wird nichts anderes genutzt.
Falsch, aber solange nur name genutzt wird, wird nichts anderes getagged.

>[...]
> 
> 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.
Einverstanden. Aber konkrete Vorschläge, ohne dass du programmieren
können musst, hab ich dir ja schonmal genannt.

>> 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 JOSM mehrsprachige Gebiete erkennt (nicht ganz einfach) und
ansonsten die Sprache erkennen kann, ja.
Ansosten: Wo ist dein Ticket im JOSM-Tracker?

> 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.
Ticket?
GUI-Skizze?
Funktionsidee, wie entschieden wird, welche Sprachen vorgeschlagen werden?

Wir sind uns doch im Grunde einig - abgesehen von der Vorgehensweise,
Mapper zu überzeugen (wo du name einfach ignorieren oder löschen willst).
Aber entwickle deine Idee der mehrsprachigen GUI doch mal weiter.
Vielleicht setzt es jemand um, oder es hat jemand ein gutes Tutorial für
dich, wie du es umsetzen könntest. Oder es sagt dir jemand, dass man
sowas z.B. in iD einfach in Vorlagen umsetzen könnte (weiß ich nicht,
aber möglich wär es doch vielleicht). Oder, oder, oder.

Aber tu was - und schimpf nicht nur ;)

Gruß
Peter