Wikivoyage:Lounge/Archiv 2008-04-14

Aus Wikivoyage
Index > Organisation > Lounge > Archiv > Archiv 2008-04-14
Dieser Artikel ist Teil unseres Archivs. Den aktuellen Artikel findest Du unter Wikivoyage:Lounge.


Grenzüberschreitende Regionen dringender Klärungsbedarf

(WV-de) Bbb hat um Diskussion gebeten, da durch Steffen M eine neue Hierarchie via IstIn eröffnet wurde, wie am Beispiel Rhön zu sehen. Die Folgende Diskussion ist eine Kopie aus der Diskussion Rhön.


Das Konstrukt wird m.E. immer abstruser und undurchschaubarer, Bitte Dringend um Diskussion durch die Gemeinschaft vor weiteren eigenmächtigen Handlungen Einzelner.

Hätte da einen wesentlich einfacheren Vorschlag für die Rhön, da die Region nur Bundesländer überschreitet:

Die politischen Orte in die oberste politische Region /Hessen = Osthessen, Thüringen = Südwestthüringen, BY = Unterfranken), wie z.T. schon jetzt gegeben;
Die Region Rhön unter IstIn deutsche Mittelgebirge
Fertig, alles weitere wie Schattenartikel etc. entfällt;--(WV-de) Bbb 15:17, 29. Feb. 2008 (CET)[Beantworten]
Dem kann ich voll und ganz zustimmen. Die Konstruktion war von Anfang an ein Notbehelf. Bbb Vorschlag ist sinnvoll. --(WV-de) Der Reisende 15:47, 29. Feb. 2008 (CET)[Beantworten]

Der Vorwurf von Bbb ist berechtigt, eigenmächtige Schritte sind sehr unschön. Nur: hätte ich dies vorher vorgeschlagen, wäre es - wie es sich hier zeigt - ohnehin abgelehnt worden. Die Idee dazu kam mir, nachdem ich gesehen hatte, dass ein Benutzer (ich weiß nicht mehr wer) begann, auch die Wegweiser über IstIn einzuorden. Da offensichtlich sehr viel Wert darauf gelegt wird, dass ALLE Artikel mit IstIn verlinkt werden und die betroffenen Artikel eben NICHT Teil der geographischen Hierarchie sind (und damit nicht auf die übernächste oder überübernächste Hierarchieebene verlinkt werden), betrachte ich das als guten Kompromiss. Den Vorlschlag zur Parallelhierarchie gab es schon und ich halte ihn für zutiefst fatal. Wenn ein Mittelgebirge grenzüberschreitend ist, heißt das noch lange nicht, dass auch alle anderen grenzüberschreitend sind. Und wenn ihr damit anfangt, auf deutsche Mittelgebirge zu verlinken, was passiert dann z.B. mit Hallertau? Deutsches Hopfenanbaugebiet? --(WV-de) Steffen M. 19:11, 29. Feb. 2008 (CET)[Beantworten]

Und warum die Rhön nicht in Deutschland einordnen? Ruhe ist! Wir sind doch nun wirklich kein Katasteramt. Jedenfalls sind für mich diese Schattenartikel völlig unpraktisch. Da qualmt mir beim Gedanken daran der Kopf. Für Nutzer der Druckversion sind breadcrumb und erst recht Schattenartikel eh' nutzlos. Und wenn Dorf "ABC" in der thüringischen Rhön liegt, warum nicht in Breadcrumb Thüringen oder eins drunter angeben? Im Einleitungssatz steht doch eh' "Rhön" oder? -- (WV-de) DerFussi 19:43, 29. Feb. 2008 (CET)[Beantworten]
Ja Fussi, wenn es nach mir gehen würde, hätte ich den Artikel Rhön schon längst auf drei Einzelartikel ohne Schattenartikel aufgeteilt. Das ist dann für eine Druckversion, also eine Buchversion der wirklich beste Weg. Ich bekomme mehr und mehr den Eindruck, dass der IstIn-Baustein nur als kleines Verschönerungsaccessoir denn als Suchhilfe angesehen wird. Wenn dich das ganze stört und unpraktisch erscheint (das gilt für alle), habe ich noch einen radikaleren Vorschlag, der allen gerecht wird: lasst uns die geographische Hierarchie abschaffen und die IstIn-Navi durch Kategorien ersetzen. Dann kann die Rhön sowohl in Deutschland, in Hessen/Thüringen/Bayern, im deutschen Mittelgebirge, in der gemäßigten Klimazone und in der variszischen Gebirgsformation liegen. --(WV-de) Steffen M. 20:09, 29. Feb. 2008 (CET)[Beantworten]
Die Hierarchisierung mittels IstIn ist ursprünglich nur für die geografische Hierarchie gedacht gewesen. Dann wurde es als ganz praktisch empfunden, auch im Namensraum Wikivoyage: damit zu strukturieren. Dass aber inzwischen IstIns vom Hauptnamensraum in den Namensraum Wikivoyage: stattgefunden haben, halte ich für nicht so glücklich. Aber das ist hier nicht das eigentliche Thema.
Das „Rhön-Problem“ entsteht immer dann, wenn man versucht, 2 verschiedene Hierarchisierungskriterien (hier politisch und geografisch) miteinander zu kombinieren. Im Grunde genommen das gleiche Problem, wie man es bei der WP oft bei Kategorien antrifft, so nach dem Motto „Südbayrische Kleinstädte mit barockem Stadtkern und mindestens einer Kirche, deren Turm höher als 35m ist“. Letztendlich muss man bei diesem Versuch immer mit einer Krücke leben. Ich fände es sauberer, in einem solchen Fall die bisher wenig beachtete AltIstIn-Lösung zu wählen. Sie ist flexibler und funktioniert auch in komplizierteren Fällen. Sie setzt allerdings voraus, dass man sich in jedem Einzelfall auf ein Haupt-IstIn einigt und mögliche alternative Kriterien zu Neben-IstIns macht. Trotzdem meine ich, dass es mehr zur Klarheit beiträgt.
Ein IstIn deutsche Mittelgebirge halte ich für falsch. Steffen hat bereits aufgezeigt, zu welchen Absurditäten dieser Ansatz führen kann, wenn man ihn konsequent weiter denkt. Das Problem ist, dass deutsche Mittelgebirge ein Sammelbegriff, aber keine Region ist.
-- Hansm 19:52, 29. Feb. 2008 (CET)[Beantworten]
Ach du liebe Zeit, jetzt habe ich erst kapiert, worum es eigentlich geht. Also, dann mein entschiedenes Nein zu IstIn "Grenzüberschreitende Regionen". Das ist keine Region. -- Hansm 19:57, 29. Feb. 2008 (CET)[Beantworten]
Ja richtig, das ist keine Region, dafür sind die "Schattenartikel" auf die nächsthöhere Regionsstufe verlinkt. Wir können auch die Verlinkung auf die "Grenzüberschreitenden Regionen" weglassen, aber dann sollte die IstIn in den betroffenen Artikeln auch ganz wegfallen. --(WV-de) Steffen M. 20:27, 29. Feb. 2008 (CET)[Beantworten]
Hallertau wäre IstIn Bayern, die Orte dann Oberbayern und Niederbayern. Kein Einheimischer würde die Hallertau nach Nieder- oder Oberbayern aufdividieren, die Holldeau gibt es nur als ganzes. Eine politische Gliederung greift für diese Region nicht (bestenfalls für die Orte) und wäre künstlich. Hier sollte individuell auch etwas auf die kulturell jeweils gegeben regionale Situation Rücksicht genommen werden, nicht alle "Grenzüberschreitenden Regionen" haben gleiches Selbstverständniss der Einwohner.
Thema Rhön: Hier haben alle "Eingeborenen" 45 Jahre mit einer ungewollten Grenze durch die eine Region gelebt, und waren froh, als diese endlich weg war (habe meine Jugend in unmittelbarster Nähe von dem Ding verbracht). Ob es da so attraktiv ist, wenn in den ersten beiden Zeilen des Artikels zweimal das Wort Grenze wiedererweckt wird ??? ........
--(WV-de) Bbb 20:10, 29. Feb. 2008 (CET)[Beantworten]
Dann stellt sich mir die Frage, warum man einen Ort im Fichtelgebirge dem Fichtelgebirge zuordnen sollte, einen Ort in der Hallertau aber nicht der Hallertau, sondern Ober- oder Niederbayern. Nein Bbb, mit dieser sinnfreien Argumentation wirst du mich niemals überzeugen können. Das mit der ungewollten Grenze, was völlig an der Sache vorbeischlittert, lasse ich mal unkommentiert. --(WV-de) Steffen M. 20:21, 29. Feb. 2008 (CET)[Beantworten]
Kleine Ergänzung. Was mich rein persönlich betrifft, ich habe die Breadcrumb-Navi schon immer nur als nette Ergänzung (ich will nicht sagen: Spielerei) betrachtet. Vielleicht deshalb meine entspannte, pragmatische Sichtweise. Aber Einzelartikel für die drei Teile der Rhön - in dem Fall nicht, denke ich. Wir sollten hier touristisch sinnvolle Artikel anlegen und nicht unsere Struktur nach Einordbarkeit in die "Breadcrumbnavi" konzipieren. - Um jetzt mal ganz ketzerisch anzumerken. Wenn mich ich als Tourist/Leser/Nutzer entscheide, nach Kota Kinabalu in den Urlaub zu fahren weiß ich, dass es in Malaysia liegt - und sollte es mich interessieren, erfahre ich im Einleitungssatz dass es zum Bundesstaat Sabah gehört. - Aber am Ende isses mir Wurscht, was bei rauskommt. Sorry. -- (WV-de) DerFussi 23:58, 29. Feb. 2008 (CET)[Beantworten]
Genau aus der sich hier abzeichneden Diskusion, bleibe ich Befürworter der Politischen IstIn Navigation, denn die ist zumindest in der Hinsicht eindeutig. Nichts gegen geografische Regionen aber, wenn die über die subnationale Grenzen führt ist es eine schlechte Wahl (Ich rede hier von der höchsten oder auch erste Ebene der politischen Einteilung des Landes). Das wir uns hier gleich richtig verstehen, in einem Kanton/Departement/Bundesland usw. kann eine Geografische Naviagtion vorteilhaft sein, also anstelle der Bezirke (niedrigste Ebene). Grundvoraussetzung ist allerdings, das die Kleinregionen klar abgernzbar sind und auch, im Kerngebiet komplet, im jeweiligen Bundesland/Kanton usw, liegt. Gossregionen die vieleicht sogar über Staatsgernzen führen (z.B Alpen), sind keine geeignete Navigationshilfmittel. (WV-de) Bobo11 00:30, 1. Mär. 2008 (CET)[Beantworten]
dito: (Stichwort Himalaya), im übrigen wird das bei Alpen schon diskussionslos recht pragmatisch entsprechend praktiziert, siehe z.Bsp. Innsbruck, Salzburg, Davos, Bruneck, diese Orte sind alle nicht IstIn Alpen als oberste geografische Region, sondern IstIn jeweils nächste politische oder geografische Ebene, die greift (und das funktioniert prima so); --(WV-de) Bbb 08:02, 1. Mär. 2008 (CET)[Beantworten]

Wenn ich das richtig sehe, dann sollen Orte in die politische istin Navigation und die besagten Regionen dann in die nächsthöhere --> also Rhön IstIn Deutschland und Alpen IstIn Europa. Stimmt das so ? --(WV-de) Der Reisende 09:18, 1. Mär. 2008 (CET)[Beantworten]

Mein Vorschlag wäre der: Orte oder Regionen nicht zwangsweise in die Ebene einer grenzübergreifende Region einordnen (also nicht: IstIn:Alpen > ...., IstIn:Himalaya > ..., IstIn:Hallertau >..... IstIn:Eifel >...) sondern bei einem Zuordnungskonflikt dann einfach die Orte in die nächste politisch eindeutige Region (das kann dann auch gleichzeitig eine geografische sein).
Die Regel muss also die sein, dass Orte mit IstIn nur dann in eine geografische Region eingeordnet werden dürfen, wenn diese politisch eindeutig ist (nicht: Hallertau, Eifel: grenzüberschreitend), bei politisch nicht eindeutigen Regionen gilt für die Zuordnung der Orte dann immer die Einordnung in die Struktur der politischen Ebenen ( Niederbayern / Oberbayern oder D / B);
Die grenzübergreifende Region lässt sich immer mindestens im Kontinent selbst (oder halt ein Sammelartikel Europa/Gebirge, Europa/Küsten) unterbringen.
Beispiel Hallertau: Hallertau: IstIn:Bayern, Orte der Hallertau: IstIn:Oberbayern oder IstIn:Niederbayern;
Beispiel Rhön: siehe oben;;--(WV-de) Bbb 10:12, 1. Mär. 2008 (CET)[Beantworten]
Beispiel Himalaya: alle Orte nach Nationen oder national eindeutigen Unterregionen (analog zu Alpen)
Beispiel Eifel: (Staatenübergreifend, und auch Paradebeispiel, dass das mit den 'Schattenartikel nur zur Navigation nicht funktioniert, siehe dort): Orte IstIn:Deutschland >... oder IstIn: Belgien >..., der Regionenartikel IstIn:Europa oder IstIn:Europa/Gebirge (analog zu den Alpen );
keine weiteren Konstruktionen oder Schattenartikel erforderlich.
WV ist zwar noch in einer sehr "jungen Projektphase", aber ich denke dass die Anzahl dieser Problempunkte überschaubar bleibt und habe mich hoffentlich verständlich ausgedrückt. --(WV-de) Bbb 10:12, 1. Mär. 2008 (CET)[Beantworten]
So wie Bbb, seh ich es auch. Geografische Regionen Artikel als Übersichtsartikel in die nächsthöheren möglichen Artikel. Bei Orten, ist aber eine IstIn Navigation welche sich den politischen Grenzen orientiert Pflicht, was allerdings nicht ausschliest dass es Zusammenlegeung von gleichwerigen politischen Einheiten zu einer Region geben darf. Hierbei solte allerdings darauf geachtet werden dass eben keine Grenzen darüber stehenden politischen Einheiten verletzt werden. ZB. Das Oberegadin (statt Bezirk Maloia) und Unteregadin (statt Bezirk Inn) zusammen in Engadin welches in Graubünden eingeordet werden kann. Es ist ja möglich durch Blaulink auf den Regionen Artikel zu verweisen, auch wenn er sich nicht auf dem IstIn Pfad befindet. (WV-de) Bobo11 10:41, 1. Mär. 2008 (CET)[Beantworten]
Genau.--(WV-de) Bbb 10:51, 1. Mär. 2008 (CET)[Beantworten]

Ich fasse das mal so zusammen: Ihr wollt Artikel auch in naturräumliche Regionen einordnen - aber nur , wenn sie nicht grenzüberschreitend sind. Das ist rein willkürlich und mit mir nicht machbar. Nochmal mein Vorschlag von weiter oben: Fussi hat ja meine Einschätzung bestätigt, also lasst uns die "lästigen" IstIn-Bausteine per Bot durch Kategorien ersetzen und gut ist. --(WV-de) Steffen M. 11:03, 1. Mär. 2008 (CET)[Beantworten]

OK. Was mein der Rest, brauchen wir eine Abstimmung?--(WV-de) Der Reisende 11:10, 1. Mär. 2008 (CET)[Beantworten]
Sieht fast so aus--(WV-de) Bbb 11:15, 1. Mär. 2008 (CET)[Beantworten]

Ich denke wir sollten alle nochmal in Ruhe über das von Hans gesagte nachdenken, da wir genau diese Diskussion schon mal hatten. Ich habe mal für Bischofsheim an der Rhön das AltIstIn eingefügt, und packe die Rhön mal nach Deutschland, schaut es Euch an, denkt 24 Stunden nach und dann sehen wir weiter.--(WV-de) Der Reisende 11:49, 1. Mär. 2008 (CET)[Beantworten]

Wie gesagt: Es kann nicht sein, dass Bischofsheim irgendwo bei Unterfranken eingeordnet wird und Rhön bei Deutschland, während Herbstein bei Vogelsberg und Vogelsberg bei Mittelhessen verlinkt wird. Nehmt bitte die geografische Hierarchie ernst oder schafft sie ganz ab. --(WV-de) Steffen M. 11:56, 1. Mär. 2008 (CET)[Beantworten]
Ich sehe das auch so wie Bbb und Bobo11 --(WV-de) elb 14:05, 1. Mär. 2008 (CET)[Beantworten]
Ps. was man aber auch immer mit beachten muss sind orte die wie

zb. das Jungfraujoch politisch in kanton wallis liegt aber nur vom kanton bern zugänglich ist muss natürlich in kanton bern eingeortnet werden zb. das dorf Campione ist mitten in der schweiz gehört aber zu itallien kommt also in die schweiz zb. samnaun ist in der schweiz kann aber nur von ostereich her erreicht werden --(WV-de) elb 14:26, 1. Mär. 2008 (CET)[Beantworten]

Ja, das Argument von Elb überzeugt. Politische IstIn-Einordnung zur Pflicht zu erheben funktioniert nicht. Es kann bestenfalls als unverbindliche Richtlinie gelten. Ich fürchte, die Entscheidung muss in jedem Einzelfall neu ausgehandelt werden.
Ich bin klar gegen die Benutzung von Kategorien als Mittel der geografischen oder politischen Hierarchisierung. Aus folgendem Grund: Wenn wir Kategorien benutzen würden, gäbe es zu jeder Region eine eigene Kategorie. Die hierarchische Einordung würde redundant erfolgen, eimal muss der eigentliche Artikel eingeordnet werden, zum anderen die zugehörige Kategorie. Das ist Fehleranfällig und macht doppelte Arbeit. Außerdem lösen Kategorien das Problem nicht, nämlich dass man sich für ein Einordnungskriterium entscheiden muss, wenn man die Breadcrumb-Navi aufrecht erhalten will.
Ich halte es für einen gedanklichen Fehler, IstIn mit Breadcrumb-Navi gleichzusetzen. Die IstIn-Einordnung ist mehr, auch wenn man z.Z. nicht mehr sieht als die BC-Navi. Was ist IstIn eigentlich? Die logische Zuordnung zu einer geografischen Region. Das ist etwas anders als die BC-Navi. So kann man hoffentlich in absehbarer Zeit die IstIn-Zugehörigkeit nutzen, um Listen aller Orte in einer bestimmten Region zu erstellen oder um regionale Einschränkungen bei einer Datenbank-Suche zu machen. Eine IstIn-Einordnung in Europe/Gebirge ist meiner Meinung nach ein Missbrauch. Wenn man so was unbedingt braucht, wären hierfür Kategorien besser geeignet. Ich sehe aber eigentlich gar keine Norwendigkeit dafür. Das jeweilige Gebirge oder Mittelgebirge kann doch in die nächsthöhere Region eingeordnet werden, die es vollständig umschließt.
-- Hansm 15:54, 1. Mär. 2008 (CET)[Beantworten]
Hätte meinerseits mit Eifel IstIn:Europa kein Problem, die Aussage ist auf jedenfall richtig und zutreffend, und dass die Eifel etwas kleiner ist als die Alpen (sind in Europa, und hier gibt es bisher keine IstIn Probleme) ist eh "relativ". Habe aber da von jemand anderem noch eine andere Position im Kopf, siehe die damalige Diskussion zu diesem Thema. Für die Anden bleibt auch nur IstIn:Südamerika übrig, und: siehe auch: Pyrenäen; --(WV-de) Bbb 18:39, 1. Mär. 2008 (CET)[Beantworten]
Ich glaube wir brauchen hier eine klare Abstimmung, da wir es nie auf einen Konsens schaffen werden... Außerdem hätten wir dann eine mehrheitlich-beschlossene, einheitliche und vor allem verbindliche Lösung. --(WV-de) Felix 21:20, 1. Mär. 2008 (CET)[Beantworten]
99% der artickel können ohne problehme geografisch oder politisch je nachdem was logischer ist eingeortnet werden wens unstimigkeiten gibt abstimmung über diesen einzelfall der gesunde menschenverstand urteilt meistens besser als die gesetze --(WV-de) elb 23:16, 1. Mär. 2008 (CET)[Beantworten]
Elb hat nicht unrecht, aber der gesunde Menschenverstand ist hier nicht gefragt (leider). Ich bitte daher nochmals zu überlegen und möglichst genaue Vorschläge (sog. Abstimmungsvorlagen) zu erarbeiten. --(WV-de) Der Reisende 10:37, 2. Mär. 2008 (CET)[Beantworten]
Also, ich mische mich dann auch kurz mal ein: Kann Elb nur zustimmem. Der gesunde Menschenverstand ist das wichtigste - deshalb bin ich dafür die Rhön unter Deutschland einzuordenen und nicht in eine neue Liste, die ich nicht brauche. Bürokratie gibt es im wirklichen Leben genug. Ich möchte mich auch nicht noch unnötig auf WV damit herumschlagen. Mehr habe ich dazu erstmal nicht zu sagen. Allen noch einen schönen Sonntag! Grüsse --(WV-de) celsius 10:52, 2. Mär. 2008 (CET)[Beantworten]
Eine erste Vorschlag für eine Abstimmungsvorlage für die Zuordnung von Artikeln in der "IstIn" Naviagtion:
  • Die in Europa Nationenübergreifende Region Eifel (in D und B) wird in Europa eingeordnet. Die Orte dieser Region werden nicht in der Region Eifel eingeordnet, sondern in der jeweiligen Hierarchie der Nationen Belgien und Deutschland. Die bisherigen Schattenartikel zu Eifel werden Artikel zu Unterregionen der Eifel, eingeordnet über IstIn bei Eifel;
  • Die in Deutschland Bundesländerübgreifende Regionen Rhön (By, Th, Hessen), Spessart (By, Hessen), Harz werden in der IstIn Naviagtion in Deutschland eingeordnet. Die Orte dieser Regionen werden nicht in der Region Rhön, Harz und Spessart, sondern in die jeweilige Hierarche der entsprechenden Bundesländer eingeordnet.
  • Die in Bayern Regierungsbezirkübergreifenden Regionen Bayerischer Wald und Hallertau werden in der IstIn Naviagtion in Bayern eingeordnet. Die Orte dieser Region werden in der entsprechenden Regierungsbezirk Niederbayern und Oberbayern eingeordnet.
  • Die Zuordnung der betroffenen Orte dieser Regionen zur jeweils zugehörigen Region erfolgt über AltIstIn.
  • Die Schattenartikel entfallen (Ausnahme: Eifel).
weitere Regionen bitte Ergänzen.
Da EifelYeti derzeit offensichtlich unterwegs ist (Tippe da auf Nordirland), Bitte entsprechender Zeitraum einplanen dass er auch teilnehmen kann. --(WV-de) Bbb 11:37, 2. Mär. 2008 (CET)[Beantworten]

Habe die gesamte Diskussion in die Diskussion:Geografische Hierarchie kopiert, da ich denke, dass sie mittlerweile sinnvoller dort aufgehoben ist. Neue Beiträge bitte dort ablegen. --(WV-de) Der Reisende 11:58, 2. Mär. 2008 (CET)[Beantworten]

2.000.000 Seitenaufruf

Schon wieder ich, man wird mich einfach nicht los... Wollte nur mal darauf hinweisen, dass wir uns der 2 Millionen-Marke nähern!!! --(WV-de) Felix 18:03, 14. Mär. 2008 (CET)[Beantworten]

Stimmt, s. hierzu auch Wikivoyage:Logbuch/2008/13. März -- Hansm 18:33, 14. Mär. 2008 (CET)[Beantworten]
Und um es offiziell zu machen: Wir haben es geschafft! 2 MILLIONEN Seitenaufrufe! Ich weiß leider nicht, wann genau. --(WV-de) Felix 15:37, 27. Mär. 2008 (CET)[Beantworten]

Location Datenbank: Tag der offenen Tür

Nachdem ich jetzt schon immer mal wieder den mysteriösen Begriff Location Datenbank benutzt habe, würde ich gerne mal veranschaulichen, was ich mir darunter vorstelle. Ich veranstalte morgen, also am Dienstag, einen "Tag der offenen Tür" auf meiner Entwicklungsumgebung. Den Entwicklungsstatus würde ich noch nicht mal Alpha nennen, aber mit etwas gutem Willen kann man meistens kapieren, wie's mal werden soll. Bitte keine Bug-Reports, ich weiß selbst noch Tausende. Der hässlichste Fehler liegt im Moment darin, dass das Javascript bei der Eingabe vermutlich nicht unter IE6 und IE7 laufen wird. (Es wäre ein Wunder, wenn doch. Ich hab's dort bisher nicht getestet.)

Für mich wären Rückmeldungen über das allgemeine Konzept und Einschätzungen zur Verwendbarkeit wichtig. Es geht dabei nicht um Kleinigkeiten des Ist-Zustands, sondern um das, was man (hoffentlich) als Entwicklungsziel erkennen kann.

Features in Stichpunkten:

  • Modular aufgebaut, bisher nur 2 Module, nämlich "IsIn" und "Geo", weitere können folgen.
  • Zentrale Eingabe für alle Sprachversionen.
  • Daten können von allen Sprachversionen verwendet werden.
  • Gemeinsame geografische Hierarchie für alle Sprachversionen und Shared:
  • Benutzer sieht bei der Eingabe den von ihm bevorzugten Namen für jede Location.
  • Versionsgeschichte wird geführt.
  • Zwei Locations können zu einer vereinigt werden. (Wieder trennen geht noch nicht.)
  • Interwiki-Links werden von der Location Datenbank gesteuert und müssen nicht mehr manuell gesetzt werden.
  • Bread-Crumb-Navi, wird von Location-Datenbank gesteuert, Vorlagen IstIn und AltIstIn verden nicht mehr benötigt.
  • Einblendung der geografischen Koordinaten wird von Location Datenbank gesteuert, Vorlage Geo überflüssig.
  • Einschränkung der Suche nach Zugehörigkeit zu einer geografischen Region, z.B. in Schweiz.
  • Umkreissuche.
  • Statistik zu allen Unterartikeln einer Region. (Link in Toolbar beim Artikel)

So, und wo isses? Wer Lust hat, kann ab sofort bis Dienstag abend spielen, es kann nichts kaputt gehen, also keine Scheu beim Ausprobieren. Es geht um 4 Testwikis:

-- Hansm 23:23, 17. Mär. 2008 (CET)[Beantworten]

Nur ganz kurz angemerkt (ich hab noch nicht viel damit rumgespielt) aber wenn die geographische Hierarchie (Breadcrumb) in Zukunft in allen Sprachversionen einheitlich sein soll, denke ich, sollten wir überlegen ob wir nicht doch eine rein politische geographische Hierarchie aufbauen (auch wenn das komplett gegen meine Beiträge in der Hierarchiediskussion verstoßen würde). Sonst sehe ich da eine Menge Konfliktpotenzial zwischen den Sprachversionen, auch wenns z.Z. nur 2 sind. Allerdings habe ich in dieser Testversion diese Einheitlichkeit nicht bemerkt, so ist die Einordnung anders, wenn ich Buenos Aires in der deutschen Version (unter Pampa Húmeda -> Pampa -> Argentinien) oder in der italienischen (direkt unter Argentinien) eingebe. Oder hab ich da was falsch verstanden? Gruß --(WV-de) Kkkr 23:37, 17. Mär. 2008 (CET)[Beantworten]

Geh mal in der Toolbar auf den Link "Location DB". Dann beim Eingabefeld "primary IsIn" auf den Link "browse". Dann siehst du vielleicht besser, was ich meine. Es gibt eine gemeinsame Hierarchie, allerdings werden in der Bread-Crumb-Navi die Ebenen ausgelassen, zu denen in der jeweiligen Sprachversion kein Artikel besteht. -- Hansm 23:45, 17. Mär. 2008 (CET)[Beantworten]
Verstehe ich noch nicht ganz. Kann ich unter Summary ein Hotel im Radius von 100 km rund um Bangkok suchen? --(WV-de) Steffen M. 09:43, 18. Mär. 2008 (CET)[Beantworten]
Nein. Alles was auf dem Ldb:-Wiki läuft, dient ausschließlich der Eingabe in die Location Datenbank. Summary ist heißt nach wie vor Zusammenfassung und hat dort die gleiche Bedeutung wie auf jedem anderen Wiki, nämlich einen Kurzkommentar zur gemachten Bearbeitung einzugeben.
Die Suchfunktion ist da, wo ich meine, dass man sie am ehesten vermutet, nämlich auf de8: und it8: (auch shared8:), also auf den Wikis, die die Loation Datenbank als Datenquelle benutzen. Hier gibt es auf den Spezialseiten Special:Search zusätzliche Eingabefelder, über die man die normale Textsuche einschränken, kann. Die Suche nach Hotels ist bisher nur als Textsuche möglich, da es noch keine Erfassung von Unterkünften in der LocDB gibt. Eingabe wäre also so: Suchbegriff "Hotel", centre "Bangkok", max. distance "100", Einheit "km". Das liefert mir 4 Ergebnisse: Pattaya, Ayutthaya, Bangkok, Phangan. Es werden dabei allerdings nur die Artikel berücksichtigt, die einen Eintrag in der LocDB haben und deren geografische Koordinaten bekannt sind.
-- Hansm 10:49, 18. Mär. 2008 (CET)[Beantworten]

Ja wie geil ist das denn!! Genial, vor allem die Option list subs, da hier ist in und altistin angezeigt werden. Damit scheint mir die Hierarchie Diskussion fast schon hinfällig zu sein. Sehr cool. Noch eine Frage: Wie werden zukünftig Punkte wie georeferenzierte Unterkünfte oder Museen eingebunden?--(WV-de) Der Reisende 13:05, 19. Mär. 2008 (CET)[Beantworten]

Auch ich kann nur begeistert staunen. Genau so etwas hatte ich mir vorgestellt, wenn es um die Umkehrbarkeit der Breadcrumbnavi (list subs) geht. Und die Möglichkeiten sehen nahezu unbegrenzt aus (ich weiss aber nicht wie das mit dem technischen Arbeitsaufwand in diesem Zusammenhang aussieht) - Hut ab, tolle Arbeit, Hans! --(WV-de) Mulleflupp - Беседа 13:22, 19. Mär. 2008 (CET)[Beantworten]
Mir fiel gerade noch etwas ein angesichts der Diskussion um Auslagerungen aus Artikeln und den dazugehörigen Namensraum. Kann man die LocDB nicht auch auf den Themennamensraum anwenden. Beispielsweise Essen und Trinken in den USA AltIstIn USA und via LocDb haben wir es dann unter List subs mitdrin. Ähnlich bei Reiserouten, dann wäre die Vernetzung total und alles leicht aufin- und zuordenbar.--(WV-de) Der Reisende 13:25, 19. Mär. 2008 (CET)[Beantworten]
Ich habs inzwischen glaube ich auch kapiert ;-) (also: beliebig viele IstIns nebeneinander möglich, praktisch also wie Kategorien?) und schließe mich damit den Lobeshymnen an. Zwar funktioniert die Umkreissuche im Raum Argentinien noch nicht, aber ich vermute einfach, das da die Daten noch fehlen. --(WV-de) Kkkr 14:28, 19. Mär. 2008 (CET) (Genauso wars, die Koordinaten haben noch gefehlt. Mit großen Kilometer-Zahlen klappts dagegen.)--(WV-de) Kkkr 14:37, 19. Mär. 2008 (CET)[Beantworten]

OK, dann habe ich den Eindruck, dass ich die richtige Richtung erwischt habe. Danke für die Begeisterungsstürme ;-) Es war sicherlich nicht ganz einfach, die Bedeutung der einzelnen Eingabefelder bzw. Links auf der Anwendungsseite aus den Variablen-Namen, die später Systemmeldungen enthalten sollen, zu erahnen. Aber so wie es aussieht ist es Euch nach anfänglichen Verständnisschwierigkeiten doch ganz gut gelungen.

Nachdem ich Konqueror, Firefox und Opera auf meinem eigenen Rechner testen konnte, hatte ich inzwischen auch die Gelegenheit, mein Javascript auf dem furchtbarsten Browser der Welt zu debuggen, ein Kampf, der sich über mehrere Stunden hinzog. Wenigstens auf Version 6.0 funktioniert es jetzt passabel, wenn auch nicht ganz perfekt. Vielleicht kann demnächst noch jemand berichten, wie sich IE 7.0 und Safari anstellen.

Die Features auf den Wikis der Sprachversionen sind sicherlich der angenehmere Teil der LocDB, aber es können natürlich nur die Daten aufbereitet werden, die auch erfasst worden sind. Ich habe mich bemüht, die Eingabe (das auf ldb8) möglichst DAU-sicher zu gestalten, aber man wundert sich doch immer wieder... Letztendlich wird davon aber der Erfolg oder Misserfolg des ganzen Konzepts der LocDB abhängen. Ich will auf jeden Fall noch eine reine Textversion der Eingabe machen, so dass fortgeschrittenen Benutzer nicht dauernd mit der Maus rumklicken müssen. Dafür muss man dann natürlich eine Minimal-Syntax lernen.

Wie bereits gesagt, die LocDB soll modular aufgebaut sein. Nachdem das Rahmenwerk sauber steht (tut's noch nicht), sollte die Erstellung neuer Module, wie z.B. Hotel, Restaurant, Distance (Entfernungstabellen) oder Climate, kein all zu großer Aufwand mehr sein. Somit stimme ich Mullflupp zu: die Möglichkeiten der Anwendung sind groß.

Gemäß dieses Konzepts bekämen Unterkünfte ein eigenes Modul, nennen wir es mal Hotel, das bliebig viele Unterkünfte aufnehmen kann. Für jede Unterkunft gibt es einen Haufen Eingabefelder, in die man das schreiben kann, was jetzt mit der Vorlage:VCard erfasst wird. Zusätzlich noch ein Beschreibungsfeld, das sprachspezifisch ist. Soll heißen, wenn ich Ldb:it:Milano aufrufe, sehe ich das italienische Beschreibungsfeld, wenn ich Ldb:de:Mailand aufrufe, sehe ich die gleichen Hotel-Daten, aber mit deutschem Beschreibungsfeld. Dann könnte man auf den Sprachversionen im Artikel Mailand einfach {{ldbHotels}} schreiben, und es werden alle Übernachtungsmöglichkeiten aus der LocDB eingeblendet.

Zum Namensraum Thema: Ich hatte über die Frage des Reisenden auch schon mal kurz nachgedacht, aber bin noch zu keinem Schluss gekommen. Auf keinen Fall will ich bei der LocDB beide Namensräume miteinander vermischen. AltIsIn (oder secundary IsIn) zwischen Hauptnamensraum und Thema: gefällt mir wegen der strukturellen Form nicht. Dann vielleicht eher so, dass man in der LocDB zu jeder Location so was wie Related Articles angeben kann, die sich dann automatisch auf den Namensraum Thema: beziehen. Dann bleibt natürlich die Frage nach der sprachunabhängigkeit der LocDB.

Und zuletzt noch was zu IsIn/AltIsIn: Ich habe eigentlich nichts Neues geschaffen. In der LocDB heißt unser IsIn primary IsIn und unser AltIsIn heißt secundary IsIn. Dass man keine Kategorien für den Hauptnamensraum braucht, habe ich hoffentlich jetzt nachgewiesen. Was immer und ewig die brennende Frage bleiben wird, ist, was primary IsIn sein darf und was nur secundary IsIn. Das war meiner Meinung der Kern der ganzen Hierarchien-Diskussion und hier kann auch die LocDB keine Lösung liefern.

Ich danke dem konditionsstarken Leser für das Durchhaltevermögen. -- Hansm 11:18, 20. Mär. 2008 (CET)[Beantworten]

Kann es sein, dass Du hier mit der Entwicklung der LocDB sowas wie wikitechnische Geschichte schreibst? Eines ist sicher, es wird auf jeden Fall WV helfen, sich positiv zu profilieren und sich klar von anderen (Reise-) Wikis abzusetzen. Auch kann uns eine verbesserte Funktionalität und eine größere Benutzerfreundlichkeit nur von Nutzen sein. Einer der großen Pluspunkte der LocD ist sicherlich auch die Verwendung gleicher Informationen in allen Sprachversionen, sodass die Arbeit in einer Sprachversion gleich auch Früchte in einer anderen Sprachversion tragen kann. Wenn ich in irgendeiner Weise behilflich sein kann, nur zu, ich stehe jederzeit zur Verfügung, auch wenn meine Programmierkenntnisse nicht weit reichen. --(WV-de) Mulleflupp - Беседа 11:38, 20. Mär. 2008 (CET)[Beantworten]
Na, das mit der „wikitechnischen Geschichte“ würde ich mal nicht so hoch hängen. Jede Entwicklung ist Teil der Geschichte. Was Hilfe Betrifft: Im Moment geht es darum, den bestehenden Code in eine noch etwas bessere Struktur zu bekommen. Dann muss alles, was irgendwie sinnvoll cachebar ist, gecached werden, damit die Datenbankzugriffe minimiert werden. Gleichzeitig können wir uns um eine konsistente Benennung der Variablen für Systemmeldungen Gedanken machen und anfangen, diese mit Texten zu füllen. Dann eine große Debug- und Testphase und wenn sich das Konzept bestätigt hat, Erstellung weiterer Module. Ein bisschen technische Doku wäre auch nicht schlecht. So wäre auf jeden Fall mein Plan zur weiteren Vorgehensweise. Also, wenn du Interesse hast, kann ich dir ja mal den Code schicken. Er ist allerding weitestgehend unkommentiert. -- Hansm 13:43, 20. Mär. 2008 (CET)[Beantworten]

Danke für die Zusammenfassung. Insgesamt in der Tat ein cooles Stück WikiGeschichte. --(WV-de) Der Reisende 17:35, 20. Mär. 2008 (CET)[Beantworten]

Nochmal ganz kurz zu dem Primary und SecondaryIstIn. Ich komme leider nicht mehr rein (wohl schon abgeschaltet, ist ja auch schon Donnerstag) und konnte es daher nicht selbst ausprobieren. Mich würde folgender Fall interessieren:

  • Das deutsche Wikivoyage sagt: Wir unterteilen ein Land politisch. Also Stadt PrimaryIstIn Bundesland PrimaryIstin Land.
  • Ein anderes Wikivoyage sagt aber: Wir wollen lieber eine naturräumliche Unterteilung. Also Stadt PrimaryIstin Naturregion PrimaryIstin Land.

Würde sich, wenn jetzt diese andere Wikivoyage-Version die Änderung in der Location DB vornehmen würde, auch für die deutsche Version die Breadcrumb-Navigationsleiste ändern? Oder bliebe die Änderung auf die andere Version beschränkt d.h. die Versionen schöpfen zwar aus einem gemeinsamen "IstIn"-Bestand, legen aber selbst fest, was Primary und was SecondaryIstIn ist? Das klarzustellen wäre imho wichtig, denn wenn PrimaryIstIn auch einheitlich wäre, müssten sich alle Sprachversionen auf eine Struktur einigen. Und dann bliebe wie schon oben angedeutet für PrimaryIstIn eigentlich nur die politische Struktur übrig (was natürlich nicht heißen muss, das andere IstIns nicht möglich sind). Ich hoffe ihr versteht was ich meine :) Gruß --(WV-de) Kkkr 19:51, 20. Mär. 2008 (CET)[Beantworten]

Die Location DB verwaltet Locations, nicht Artikel. Locations sind Orte, Regionen, Länder, usw. Alle Eingaben in die LocDB beziehen sich auf die Location, nicht auf den oder die Artikel in den Sprachversionen. Folglich müssen sich die Sprachversionen auf ein gemeinsames primary IsIn einigen, wenn sie gemeinsame Locations benutzen wollen. Es ist aber natürlich kein Problem, z.B. it:Milano und de:Mailand als zwei verschiedene Locations laufen zu lassen. Aber dann muss natürlich jede Location unabhängig von der anderen gepflegt werden.
Mir ist aber nicht klar, warum für sprachübergreifende Locations nur die politische Unterteilung in Frage kommen sollte. Es ist doch ein und dieselbe Region, nur wird sie in verschiedenen Sprachen beschrieben. Warum sollte das eine Auswirkung auf die Brauchbarkeit einer Unterteilung haben? OK, es kann mit internationaler Beteiligung noch schwerer werden, sich auf eine Unterteilung zu einigen, aber letzendlich hat man dann mehr davon, weil sie nicht in jedem einzelnen Wiki neu ausgefochten werden muss. Außerdem sind die Sprachversionen dann untereinander konsistenter.
-- Hansm 20:20, 20. Mär. 2008 (CET)[Beantworten]
Gut, damit wären meine Zweifel beseitigt. Das mit der politischen Einteilung per PrimaryIstIn bezog sich darauf, das die politische ja die einzige eindeutige Einteilung ist. Kompliziert könnte es nämlich dann werden, wenn die verschiedenen Sprachversionen deutlich mehr als die bisher überschaubare Autorenzahl haben (was wir ja wohl alle hoffen) und Neulinge, die keine Ahnung von den anderen Versionen haben, an den Einstellungen der Location-Datenbank herumspielen. Beispielsweise legt irgendjemand in der italienischen Version einen Artikel an, wundert sich, warum das PrimaryIstIn nicht so festgelegt ist wie er das möchte, und ändert es. Dann kommt irgendwann einer der deutschen Version drauf, das seine vorherige Struktur plötzlich kaputt ist, und ändert es wieder. Da steckt imho ein riesiges Konfliktpotenzial drin. Mir fallen da auf die Schnelle nur drei Lösungen ein:
1) man einigt sich auf eine politische Struktur und macht das unmissverständlich in allen Versionen auf den Hilfeseiten etc. klar.
2) man einigt sich auf eine flexiblere Struktur und stellt die gewählte Hierarchie auf einer Hilfe-Seite komplett als Baum dar und richtet einen sprachübergreifenden Diskussionsraum dazu ein (aufwändig, aber eventuell die beste Lösung)
3) man legt in allen neuen Sprachversionen per Bot schon mal die Artikel zu der Struktur (natürlich nur bis zu einem bestimmten Grad) an, nur ohne Inhalt (dann hätten wir schnell dieselben Probleme wie Wikitravel, nämlich tausende Artikel, die nur aus "XX ist eine Stadt in YY" bestehen). Immerhin käme Wikivoyage dann schnell in diese Liste ;-)
4) Das PrimaryIsIn wird unabhängig von den einzelnen Sprachversionen festgelegt (erfordert zusätzlichen Programmieraufwand, Machbarkeit?).
Es geht mir hier wie gesagt, nur um das PrimaryIsIn. Artikel außerhalb dieser Struktur, also die "grenzüberschreitenden Regionen", sind davon ja nicht betroffen. Und wie ich oben schon gesagt habe, die Idee der LocationDB finde ich super, nur wollte ich eben auf einige praktische Schwierigkeiten hinweisen, die sich ergeben könnten. Gerade weil wir vor kurzem über die geographische Hierarchie diskutiert haben, wäre es jetzt ein guter Zeitpunkt, um sich auch da auf eine Lösung zu einigen. Gruß --(WV-de) Kkkr 22:01, 20. Mär. 2008 (CET)[Beantworten]
Nachtrag: Interessant wäre eventuell, wie viele Länder überhaupt auf der ersten Ebene unterhalb der Nationen per Naturraum statt per politischer Gliederung gegliedert sind. Wenn ich da mit meinem Argentinien der einzige wäre, hätte ich kein Problem mit, das anzupassen (man kann die Provinzen ansatzweise in die Regionen einordnen, aber eben nur ansatzweise...).--(WV-de) Kkkr 22:05, 20. Mär. 2008 (CET)[Beantworten]
Dein Punkt 2. wäre für mich das Ideal. Punkt 1. wäre mir zu starr, du hast am Beispiel von Argentienien gute Gründe dagegen aufgezeigt. Punkt 3. wäre mein Alptraum, wir sind sowieso schon in irgendsoeiner Liste drin. In diese kommen wir auch, nächstes Jahr. Punkt 4. wäre möglich, obwohl ich es nicht so gerne hätte, aber immer noch besser als 1. oder gar 3. Man könnte beim entsprechenden Aliasnamen eine Checkbox setzen, mit der man bestimmen kann, ob die BreadCrumb durch die LocDB oder das IsIn im Artikel gesteuert wird. So richtig toll fände ich das nicht, aber immer noch besser als Bürgerkrieg.
Zum Nachtrag: Ich gehe jetzt gleich schlafen, die Demo- bzw. Entwickler-Wikis laufen gerade wieder. Bis morgen früh in Mitteleuropa hast du Zeit. Dann mache ich wahrscheinlich wieder was dran, was fast zwangsläufig zu Crashs führt. Du kannst ja mal jedes Land durchklicken, am besten die Statistik-Seite, also z.B. http://www.wikivoyage.org/w/de8/index.php?title=Spezial:LdbListSubLocs/Argentinien&mode=stat
-- Hansm 00:06, 21. Mär. 2008 (CET)[Beantworten]
Interessant, diese Statistikseiten kannte ich gar nicht. Die sind ja insofern sehr nützlich, dass man auf einen Blick schnell sieht, welche Artikel am meisten angeklickt werden, d.h. wo man am besten die Artikel vertieft. Toll! Im Bezug auf meine Argentinien-Hierarchie stehe ich kurz davor, meine Struktur doch soweit anzupassen, das zumindest das IstIn über die politischen Regionen läuft. Aus folgenden Gründen: Erstmal waren ausnahmslos (!) alle Länder außer Argentinien, die ich angeklickt habe, auf irgend einer Ebene politisch gegliedert (meistens nach dem Muster Land -> Überregion -> politische Region -> Naturräume). Zweitens, was in Hinblick auf die zukünftige Entwicklung (neue Sprachversionen) fast wichtiger ist: Sowohl Wikitravel/en als auch Wikitravel/es gliedern Argentinien ebenfalls auf der 2. Ebene politisch (WT/en allerdings mit vereinzelten Ausnahmen). Und drittens: Wenn ich mir die Struktur in Argentinien genau ansehe, gibt es nur in einem recht begrenzten Bereich, nämlich in Zentral- und Westargentinien, wo ich wohne, Zuordnungsprobleme. Sowohl in Patagonien, Mesopotamien, im Nordwesten und in der Pampa sind die Zuordnungen eigentlich fast eindeutig. Aber ich überlegs mir noch ein paar Tage (eilt ja nicht).
Ich gehe mit dir konform, das die Bot-Variante von meinen oben genannten Lösungsvorschlägen nicht wünschenswert wäre. Gerade die vergleichsweise hohen Qualitätsstandards an den Artikeln d.h. die recht geringe Stubzahl finde ich hier sehr angenehm. Auch ich wäre am ehesten für Variante 2, oder notfalls 4, wenn es zu aufwändig sein sollte.--(WV-de) Kkkr 04:38, 21. Mär. 2008 (CET)[Beantworten]
Hallo, ich wollte mich auch nochmal dazu äußern, nur hatte ich in den vergangen Tagen leider wenig Zeit dazu. Ersteinmal bin ich begeistert von den Möglichkeiten die sich aus dieser System-Umstellung ergeben könnten. Auch wenn ich noch nicht alles durchschaut habe, hoffe ich, dass es durch die Location Datenbank in Zukunft einfacher wird Informationen zu sammeln und zu bearbeiten. Eine Frage habe ich allerdings noch. Wie können normale User (eventuell sogar unangemeldete Neulinge) dieses System nutzen und dabei alle Informationen richtig eintragen. Ein Hotel kann ich ja dann nicht mehr einfach in einen Artikel schreiben und gut ist, es muss ja in die Datenbank entsprechend (richtig!) eingepflegt werden. Wie kann ein unbedarfter Nutzer dieses ohne Vorkenntnisse erreichen? --(WV-de) Felix 13:56, 23. Mär. 2008 (CET)[Beantworten]
Tja, einen Tod muss man sterben. Bei alltäglichen Bearbeitungen können wir davon ausgehen, dass den meisten Neuankömmlingen die Wikioberfläche von der WP her vertraut ist. Sobald wir irgendwie was Neues machen, ist das natürlich nicht mehr der Fall. Das gilt aber bereits für die richtige Verwendung unserer Vorlagen. Was natürlich immer geht, ist, das Hotel einfach als normalen Text wie bisher auch in die Seite zu schreiben. Es wäre auch denkbar, beim Bearbeiten des Abschnitts "Unterkunft" durch einen Link direkt auf die LocDB hinzuweisen. Alles weitere wird nur so möglich sein, wie bisher auch in anderen Fällen: Den neuen Autor persönlich ansprechen und auf die Besonderheiten hinweisen. -- Hansm 15:04, 23. Mär. 2008 (CET)[Beantworten]
Wäre es denn möglich Eingabe-Formulare in die Bearbeitungsseite einzubauen? Naja, vielleicht macht es das auch noch komplizierter, aber eine Überlegung wäre es. --(WV-de) Felix 15:30, 23. Mär. 2008 (CET)[Beantworten]
Technisch würde das mit einigem Aufwand sicherlich irgendwie gehen, aber konzeptionell halte ich das nicht für geschickt. Dann zerfleddern wir ja die zentrale Daten-Eingabe wieder über die einzelnen Wikis. Nein, ich glaube, jemand, der mit einem Link zur LocDB nichts anfangen kann, kann auch mit den Eingabe-Feldern nichts anfangen. -- Hansm 16:12, 23. Mär. 2008 (CET)[Beantworten]
Mir geht es noch um ein paar gedankliche Geschichten. Stichwort gemeinsame Hierarchie auf shared: und in den Sprachversionen. Jetzt gibt es noch zwei Stichpunkte. 1: Auf shared: haben wir einige Zwischenstufen ausgelassen. Ich selbst habe es in Malaysia so gehandhabt: Malaysia -> Bundesstaat -> Ort. Eine Zwischenstufe auf de: entsorge ich noch, da eigentlich unnötig (Westmalaysia in Ost- und Westküste zu unterteilen ist sinnlos, eine Zwischenstufe die nie in vernünftigen Maß mit Informationen gefüllt sein wird, obwohl dann Westmalaysia etwas mehr als neun Unterartikel bekommt). In Deutschland ist es wohl ähnlich oder? Wir haben nur Deutschland -> Bundesland -> Ort. Kann man damit leben? Oder sollte man die Zwischenhierarchien auch analog auf shared: abbilden. 2. In Vietnam habe ich zwei verschiedene Hierarchien benutzt. Auf de: habe ich Vietnam (erstmal) nur in 6 (nicht administrative) Teile geteilt. Vietnam -> Südlicher Küstenstreifen -> Mỹ Sơn. Wenn nicht plötzlich zehn Insider hier auftauchen, die zu jedem Ort was schreiben können, würde das auch mittelfristig reichen. Das heißt in den meisten der Teilen werden wahrscheinlich so schnell nicht mehr als 10 Artikel auftauchen. Für shared: Habe ich die Provinzen genutzt Vietnam -> Quảng Nam -> Mỹ Sơn. Da werde ich vileleicht doch schon mal mit den Provinzen auf de: arbeiten, damit das dann konsistent ist. Die Provinzen stehen ja bereits in den Überregionen, waren nur noch nicht verlinkt. Also die Hauptfrage geht eigentlich um die Hierarchie auf shared: -- (WV-de) DerFussi 07:37, 25. Mär. 2008 (CET)[Beantworten]

zu 1.: So lange es sich um echte Zwischenstufen handelt, ist es kein Problem. Sie werden einfach übersprungen, wenn sie in einem Wiki nicht existieren. Also z.B. auf de:

Index Reiseführer > Europa > Mitteleuropa > Deutschland > Bayern > Franken > Mittelfranken > Nürnberg

aber auf shared: nur

Index > Europe > Germany > Bavaria > Nuremberg

genau so, wie es jetzt auch ist.

zu 2.: Soweit ich das überblicke, hast du auf de: mehrere Provinzen zu einer größeren Region zusammengefasst. Wenn das stimmt, ist auch das kein Problem. Dann wäre das gemeinsame Hierarchie-Schema:

Vietnam > Großregion > Provinz > Ort

wobei auf shared: die Großregion wegfällt und auf de: die Provinz. Problematisch wird es allerdings, wenn die Großregionen auf de: einzelne Provinzen teilen. Das bekommt man nicht mehr zusammen.

-- Hansm 10:03, 25. Mär. 2008 (CET)[Beantworten]

Hast du richtig gesehen. Großregion und Provinzen sind verschneidungsfrei. Gut. Wenn auch das geht, ist das erstmal ok. Dann kann ich die Provinzen auch später nach Bedarf aufbauen und kann das erstmal stressfrei so lassen. -- (WV-de) DerFussi 10:09, 25. Mär. 2008 (CET)[Beantworten]
Ergänzende Frage: Weiß die LocDB, ob zwei Artikel der Hierarchie wirklich korrespondieren oder nicht? Auf gleiche Schreibweise kann sie ja nicht achten. Beispiel:
de: Vietnam -> Südlicher Küstenstreifen -> Mỹ Sơn
shraed: Vietnam -> Quảng Nam -> Mỹ Sơn
Allerdings sind 'Südlicher Küstenstreifen' und 'Quảng Nam' Nicht das selbe. (Letzteres liegt ja am Ende sogar in dem Ersteren) -- (WV-de) DerFussi 10:15, 25. Mär. 2008 (CET)[Beantworten]
Die Antwort ist verblüffend simpel: Die LocDB weiß, dass 2 Namen die gleiche Location bezeichnen, wenn man ihr das sagt. Ich habe beim Import in die Testwikis einfach die Interwiki-Links dazu benutzt. Deshalb steht shared: weitestgehend isoliert da, während zwischen it: und de: eine gute Verbindung besteht. -- Hansm 11:55, 25. Mär. 2008 (CET)[Beantworten]
Ich habe es für Mỹ Sơn mal hingezaubert. Vgl. dabei die Hierarchie in der LocDB (browse-Link neben primary IsIn) und die auf de8: und shared8:. Im Moment kannst du aber selbst kaum was ändern, weil der Cache nicht richtig akutalisiert wird. Oder genauer: wenn du jetzt die Hierarchie änderst, wird sie morgen richtig angezeigt, weil dann der Cache seinen Timeout hat. -- Hansm 12:28, 25. Mär. 2008 (CET)[Beantworten]
Da fällt mir gleich noch eine Frage ein. Was passiert, wenn ich den italienischen Namen in der deutschen WV-Suche eingebe. Findet er das dann trotzdem? Also z.B. Firenze statt Florenz. --(WV-de) Felix 14:05, 25. Mär. 2008 (CET)[Beantworten]
Wenn der it. Name nicht zufällig im Text des Artikels steht, nein. Aber das wäre noch eine Idee, über die ich nachdenken muss. Vielleicht wäre es hilfreich, wenn man auch Seiten in anderen Sprachen angezeigt bekommt, wenigstens dann, wenn sonst keine oder nur wenige Treffer erzielt werden. -- Hansm 14:23, 25. Mär. 2008 (CET)[Beantworten]

Noch ein kurzer Nachtrag zu dem was ich oben geschrieben habe, falls es jemand interessiert: Ich habe mich bei Argentinien jetzt doch entschieden, auf der ersten Ebene unter der Nation rein naturräumlich zu gliedern, aus den Gründen die ich in der Hierarchiediskussion dargelegt habe (sinnvoll für den Reisenden) und außerdem bin ich doch nicht der einzige, denn Island macht das auch so. Die zweite Ebene habe ich jetzt so hingeschoben (bzw. bin ich gerade dabei, das zu tun), dass alle Reisegebiete "zweiter Ordnung" eindeutig sowohl einem Naturraum als auch einer Provinz zuzuordnen sind. Das heißt: Sollte es in Zukunft mit der LocDB Konflikte geben zwischen "Naturraum-Sprachversionen" und "Politik-Sprachversionen", wären beide Zuordnungen möglich; bis dahin hat jede Region ein eindeutiges IstIn (Naturraum) und ein eindeutiges AltIstIn (Provinz). Nebeneffekt: Die 7+2-Regel wird besser umgesetzt, und noch tiefere Gliederungen sind nur in Einzelfällen notwendig. Gruß --(WV-de) Kkkr 04:55, 27. Mär. 2008 (CET)[Beantworten]

Expedition "Einleitungen"

Besteht Interesse an einer Expedition "Einleitungen"? Ich habe mir für die nächste Zeit vorgenommen, die Einleitungen der Artikel (erstmal in meinem Interessengebiet Südamerika) zu überarbeiten, denn ich halte es für sehr wichtig für das Erscheinungsbild von Wikivoyage, wenn der Artikelanfang ansprechend geschrieben ist, denn die Einleitung ist ja quasi die "Visitenkarte" eines Artikels, und wenn da nur steht "XX ist eine Stadt in YY" sieht das imho nicht so gut aus. Gekommen bin ich auf die Idee übrigens, als ich mich im englischen Reisewiki Travellerspoint festgelesen hatte und dabei erstaunt war, wie gut die Einleitungen trotz der recht geringen Artikelzahl aussahen - und siehe da, die hatten ein Wiki-Projekt "Einleitungen schreiben" dazu. Ist übrigens ne nette Seite, von der WV eventuell einiges lernen könnte, wenn auch kommerziell und viel umfangreicher (mit Foren, Blogs und Online-Reisebüro).

Hab jedenfalls im meinem Benutzerraum Benutzer:Kkkr/Einleitungen als "Notizblock" angelegt. Wenn Interesse besteht verschiebe ich es in die Expeditionen.--(WV-de) Kkkr 04:30, 23. Mär. 2008 (CET)[Beantworten]

Hallo Kkkr, wieder sprichst du mir aus der Seele. Ich bin schon lange der Meinung, dass die Einleitungen auf Wikivoyage zu langweilig sind und emotional aufgepeppt werden müssen. Sicher ist nicht immer Zeit und Muse vorhanden, um dies zu tun, aber gelegentlich versuche ich es. Natürlich setzt eine gelunge Einleitung auch gute Ortskenntnis voraus, aber ich hoffe, dass sich genügend Leute finden, um einige der Einlietungssätze zu bearbeiten. Denkst du denn, dass es sich lohnt eine eigenen Expedition zu starten? Bei Zustimmung der anderen Benutzer, könnte man deine guten Ansätze vielleicht auch einfach in bestehende Artikel einarbeiten, ohne großen "Verwaltungsaufwand" :-) --(WV-de) Felix 14:06, 23. Mär. 2008 (CET)[Beantworten]
Da bin ich natürlich dabei. --(WV-de) flöschen 14:13, 23. Mär. 2008 (CET)[Beantworten]
Nur seh ich hier auch ein anderes Problem. Denn die Einleitung kann auch zu Emotional werden, denn zu wertent solten wir nicht werden. Das XY ist eine Stadt in XY hat eben der Vorteil das alle Artikel ähnlich aussehen, was nicht ein Nachteil sein muss, denn dadurch kan man gut feststellen ob man im richtigen Artikel gelandet ist. Das dem Standartsatz allerdings ein zweiter Satz mit den Reisegründe folgt, dagegen ist nicht einzuwenden. (WV-de) Bobo11 14:49, 23. Mär. 2008 (CET)[Beantworten]
Also ich hab da eher an 4-6 Sätze insgesamt gedacht (also 2 Absätze laut den allgemein akzeptierten "Regeln" für Journalisten und Co.). Das die Artikel zu emotional werden, ist glaube ich am wenigsten von der Einleitung abhängig, bisher sind mir die meisten "Blüten" in dem Bereich eher irgendwo versteckt bei den Sehenswürdigkeiten, Nachtleben oder Hotels aufgefallen. Wie ich mir eine gute Einleitung vorstelle könnt ihr euch ja mal bei den von mir im Rahmen des Projekts bearbeiteten Artikeln (z.B. Argentinien, aber auch das neugeschriebene Cayenne) anschauen. Das heißt: durchaus sachlich und eben "nicht" wertend, aber mit lebendiger Sprache (also auch mit Adjektiven, ganz im Sinne des hier geltenden Objektivitätsgrundsatzes).
Denn Sinn einer "Expedition" würde ich einfach darin sehen, dass man dann eine Seite hätte, wo man eintragen könnte, wo schon an den Einleitungen gearbeitet wurde und wo noch fehlt. Wie bei meinem persönlichen Notizblock ;) --(WV-de) Kkkr 21:29, 23. Mär. 2008 (CET)[Beantworten]
Dann mach mal ein Beispiel, dann weis man ja auch von was du redest. (WV-de) Bobo11 23:58, 23. Mär. 2008 (CET)[Beantworten]
Steht doch im letzten Absatz... die Einleitungen von Argentinien, Buenos Aires oder ganz brandneu Grytviken ... oder was meinst du? --(WV-de) Kkkr 01:47, 24. Mär. 2008 (CET)[Beantworten]
Ja wenn du das darunter verstehst, dann hast du meine Unterstützung. Wichtig ist mir eben das alle Artikel im Stil; "Ort" ist eine "Stadt/Gemeinde/Badeort usw." in "Land" (ggf + Region) anfangen. Denn ich halte es für sehr wichtig, dass der Leser schon nach dem lesen des erstens Satzes weis ob er im richtigen Artikel gelandet ist, und dafür braucht er nun mal die wichtigesten Infos wie Namen und Land. Z.B die Einleitung in Piriápolis finde ich Müll, denn der Atlantik ist gross, ohne IstIn weis keiner wo das liegt.(WV-de) Bobo11 09:55, 24. Mär. 2008 (CET)[Beantworten]
Da hast du Recht, Piriápolis werde ich mal so schnell wie möglich ändern. Obwohls in meinem Interessenraum liegt, von mir stammt die komische Einleitung nicht ;-) Der erste Satz sollte wirklich den Artikel geografisch einordnen. --(WV-de) Kkkr 19:42, 24. Mär. 2008 (CET)[Beantworten]

Mit dem Aufpeppen der Einleitungen rennst Du bei mir offene Türen ein. Ob es eine Expedition braucht weiß ich nicht. Vielleicht einfach eine Ergänzung in den entsprechenden Hilfeartikeln und evtl eine Umstellung des vorgegebenen Satzes in den Skeletten nach der Art: Artikelname ist eine Stadt in Region. Das 1305 gegründete Städtchen ist vor allem wegen seiner mittelalterlichen Altstadt und des hervorragenden obergärigen Bieres berühmt. Bereits der Große Dichter Schnaps Drossel besang die seligmachende Wirkung des Gebräus in seiner Ode Schenke er nach. -- Mir würde es gefallen.--(WV-de) Der Reisende 12:30, 25. Mär. 2008 (CET)[Beantworten]

Naja, "Artikelname ist eine Stadt in Region" würde ich schon lassen, gerade damit auch Neulinge einfach einen Artikel anlegen können ohne sich groß um die Einleitung zu kömmern. Ich würde eher einen Hinweis als Kommentar reinschreiben (sowas wie "kurze Einführung in das Reiseziel") und in den Vorgaben auch einen Satz reinschreiben, was in die Einleitung kann. Ich überleg mir mal was. --(WV-de) Kkkr 21:25, 25. Mär. 2008 (CET)[Beantworten]

Ich komme nicht drum herum, an dieser Stelle doch etwas loszuwerden: Anstatt "Artikelname ist eine Stadt in Region" lieber "Die Stadt Artikelname liegt in Region" schreiben. Wir haben nämlich nicht die Aufgabe, irgendetwas zu definieren; das machen die Kollegen von der großen Wiki-Enzyklopädie viel besser. --(WV-de) Steffen M. 21:36, 25. Mär. 2008 (CET)[Beantworten]

Guter Vorschlag. Gefällt mir auch besser so herum.--(WV-de) Kkkr 06:42, 26. Mär. 2008 (CET)[Beantworten]
Seh ich auch so. Irgendwie hab ich das sowieso schon immer so gemacht, glaub ich... --(WV-de) Felix 15:31, 27. Mär. 2008 (CET)[Beantworten]

Spezialseiten

Irgenwie ist die Spezialsieten die Suchseite nach nicht korekten oder fehlenden IstIn abhanden gekommen. --(WV-de) Bobo11 00:25, 24. Mär. 2008 (CET)[Beantworten]

Hä? Gab's so was mal? -- Hansm 01:02, 24. Mär. 2008 (CET)[Beantworten]
Ja, frag mich aber nicht nach dem genauen Namen. Man konnte jedefals mal nach den Artikeln suchen die kein IstIn hatten oder deren IstIn Pfad nicht in einem Land-Artikel landeten. Irgen wie find ich den nicht mehr, und ich hab wirklich alles durch geklickt. War so eine Art Statistikseite wo man nach Länder suchen konnte, oder eben nach dem Rest.(WV-de) Bobo11 01:14, 24. Mär. 2008 (CET)[Beantworten]
Es gibt Spezial:Nicht kategorisierte Seiten, aber das geht nur für Kategorien. Dass wir so was mal für IsIn gehabt haben sollten, ist mir neu. -- Hansm 01:19, 24. Mär. 2008 (CET)[Beantworten]
Es war die Seite wo aufgeschlüsselt war, welches Land wieviele Seiten mit welcher Länge hat, und dies mit Prozent angaben. Dort gab es eben auch das Knöpfchen Artikel ausserhalb dieser Liste. Und damit konnte man ganz gut nach falschen oder fehlenden IstIn suchen.(WV-de) Bobo11 09:46, 24. Mär. 2008 (CET)[Beantworten]
Ah, an das Knöpfchen konnte ich mich nicht mehr erinneren. Was mit der Spezialseite passiert ist, weiß ich. Das ganze Ding war zwar ganz nett, aber hinter den Kulissen eine ziemliche Krücke. Das große Problem ist, dass die IsIn-Information aus den Artikeln ausgelesen werden muss, solange es keine LocDB gibt. Das ist furchtbar Resourcen-intensiv. Ich hatte diese Spezialseite beim Umstieg auf die PostgreSQL Datenbank nicht wieder aktiviert. Mal sehen, wenn sie ohne großen Aufwand läuft, schalte ich sie wieder an, aber meine Priorität heißt LocDB. -- Hansm 10:30, 24. Mär. 2008 (CET)[Beantworten]
Die Prozente bei den Ländern war zwar nett aber nicht wirklich wichtig. Aber das wirklich sinnvolle an der Seite war eben das Knöpfen zum suchen was nicht erfasst wird. (WV-de) Bobo11 10:47, 24. Mär. 2008 (CET)[Beantworten]
Ja,ja, aber das Problem liegt in der Beschaffung der Daten. Wenn man sie erst mal im Speicher hat, ist es Wurscht, ob man Prozente anzeigt oder nur die nicht eingeordneten Artikel. Ich hab's wiederbelebt, aber du musst erst noch ein bisschen "pumpen" (ein paar mal aufrufen), bis genügend Artikel analysiert wurden. Hoffentlich gibt's jetzt keine bösen Überraschungen mit fehlerhaften Seiten. Das kann nämlich gut passieren. Die Spezialseite liegt unter Verteilung der Artikel. -- Hansm 11:05, 24. Mär. 2008 (CET)[Beantworten]

Geo-Vorlage spinnt in Playas Doradas

In dem genannten Artikel wird bei mir immer bei der Breite "Fehlerhafte Eingabe" angezeigt. Ich habe schon die Vorlageneinbindung von Grytviken (wo sie genau gleich im Format eingebunden ist und tadellos funktioniert) reinkopiert und dann die Zahlen angepasst, um zu verhindern, das ein falsches Apostroph die Schuld hatte - hat nichts gebracht. Weiß jemand, woran das liegen könnte, ist das eventuell sogar ein Bug? Ich steh grad total auf dem Schlauch... --(WV-de) Kkkr 02:35, 25. Mär. 2008 (CET)[Beantworten]

Habs korrigiert. Der Grund war folgender: 60" geht nicht, dass ist eine Minute. Habe also die 02' 60" in 03' 00" geändert. -- (WV-de) DerFussi 07:12, 25. Mär. 2008 (CET)[Beantworten]
Danke, daran hab ich gar nicht gedacht... (hab irgendwie geglaubt, das Limit seien 90 Grad) Aber komisch, dass es dann in der (spanischen) Wikipedia klappt - von daher hab ich die Angabe nämlich... --(WV-de) Kkkr 21:21, 25. Mär. 2008 (CET)[Beantworten]
Ja, die Grad gehen schon sogar bis 360. Bei mir sogar bis 400 - aber ich bin ja auch Vermesser und wir benutzen "Gon". Gut, auf dem Globus dann ja von -180 bis +180. Aber bei den Minuten und Sekunden ist halt bei 60 Schluß. Davon abgesehen hängt hinter der Geo-Vorlage eine Eigenprogrammierung von Roland. Ich schätze, dort ist (noch) kein "Schutz" gegen eine "Falscheingabe" wie zum Beispiel die unkorrekten 60" einprogrammiert. Bei WP/es wird das vielleicht abgefangen. - (WV-de) DerFussi 22:18, 25. Mär. 2008 (CET)[Beantworten]
Ich habe es dabei belassen, 60" als falsche Eingabe einzustufen (weil volles Grad). Im Code wird zwar noch nach verschiedenen Fehlern unterschieden, aber es erfolgt immer nur die Ausschrift "Fehlerhafte Eingabe". --(WV-de) Roland 12:04, 3. Apr. 2008 (CEST)[Beantworten]

Ausführliche Erwähnung auf den Seiten des HR

schaut mal hier, da werden wir ausführlich vorgestellt. Hat jemand da seine Kontakte spielen lassen, oder wurden wir so erwähnt? Würde mich mal interessieren. Die Formulierung "nicht immer als journalistisch gesichert gelten." finde ich zwars nicht so nett, aber na ja... --(WV-de) celsius 12:48, 28. Mär. 2008 (CET)[Beantworten]

Ich vermute einmal, dass auch die Rundfunkanstalten immer mehr das Internet für die Recherche nutzen, vor einiger Zeit war schon einmal ein Bild von mir von Gelnhausen auf den Seiten des HRs zu finden. Für uns ist dies natürlich eine schöne Sache. -- (WV-de) Jens 13:07, 28. Mär. 2008 (CET)[Beantworten]
NA ja, dass "nicht immer als journalistisch gesichert gelten." stört mich eigentlich nicht unbedingt. Wenn ich seh wie gewisse Journalisten (z.B gewisse Boulvardzeitungen) arbeiten möchte, ich nicht mit denen verglichen werden ;-). Und es stimmt nun mal, dass wir Amateure sind auf dem Gebiet des Journalismus, und hier eben Reisende für Reisende schreiben. Und das dies nicht unbedingt das gleiche ist wie ein Journalist für Reisende schreibt. Es ist nun mal, dass wir keine Journalisten sind und es ist in jedem Wiki so, dass man nicht alles für bare Münze nehmen darf (Hirn selber benutzen). Selbst ein Reiseführer ist beim erscheinen schon veraltet. Bei unseren Artikeln ist das nicht anders. Wenn ich heute ein Hotel beschreibe das ich gestern Besucht habe, kann das morgen schon geschlossen sein. Ich versteh den Einwand als; nicht als alleinige Quelle für eine Artikel über irgendetwas benutzen. (WV-de) Bobo11 13:47, 28. Mär. 2008 (CET)[Beantworten]
Hmmm, Bearbeitungskonflikt, Bobo war schneller. Muss ihm auf jeden Fall Recht geben. Hier stellt sich natürlich auch die Frage, was der HR unter "journalistisch gesichert" versteht, bzw. inwiefern dieses Kriterium überhaupt von anderen Reiseführern erfüllt wird (werden kann). Erwähnungen, solange es sich nicht um einen kompletten Verriss handelt, sind auf jeden Fall immer als positiv zu bewerten. --(WV-de) Mulleflupp - Беседа 13:52, 28. Mär. 2008 (CET)[Beantworten]
sitimmt, vor der Seite wie Bobo11 das sieht habe ich das noch nicht betrachtet. Mit Boulvardzeitungen will ich auch nicht verglichen werden. Schön ist natürlich, das wir erwähnt werden. --(WV-de) celsius 17:05, 28. Mär. 2008 (CET)[Beantworten]

Dass WV als eine von drei Informationsquellen aufgeführt wird, ist auf jeden Fall ein Indiz für die Bedeutung, die wir inzwischen haben. Island ist zwar schwer zu erreichen, aber einer unserer Top 10 Artikel. Das ist eindeutig der große Verdienst von (WV-de) Gipsyqueen, denn sie ist unsere unumstrittene Islandkönigin. Und jetzt zum großen Preisrätsel: Was schätzt ihr, wieviele Referrer uns dieser Beitrag vom Hessischen Rundfunk eingebracht hat? Der Gewinner wird per E-Mail beneachrichtigt. Einsendeschluss bis Samstag in 8 Tagen. -- Hansm 23:03, 28. Mär. 2008 (CET)[Beantworten]

Gute Frage, dazu müßte man eigentlich zumindest mal Wissen wie lange der HR freundlicherweise schon auf uns verweist. Also, ich schätze mal 500 Besucher insgesamt, seit der HR Beitrag im Netz steht - ist ein Schuss ins blaue, da ich wirklich keine Vorstellung habe ;-)--(WV-de) celsius 09:42, 29. Mär. 2008 (CET)[Beantworten]
Ist ne Wiederholung vom Juni 2007. --(WV-de) Der Reisende 09:52, 29. Mär. 2008 (CET)[Beantworten]