Hallo Ulrich, Ulrich Fuchs schrieb: Doch. Und zwar ist sind die Bausteine das logisch sinnvollste, was wir machen können. Denn so eine Navigationsleiste gehört nicht zu einem Artikel, und sollte damit auch nicht direkt in einen Artikel geschrieben werden. Für manche Sachen (ich weise mal auf den WikiReader hin) ist eine Navigationsleiste zudem absolut störend. Für normales Lesen sollen die Navigationsleisten jedoch vorhanden sein. Damit brauchen wir eine Lösung, die beides zulässt, und das geht am besten über Textbausteine - wobei allerdings die Benennung einheitlich sein muss, siehe auch das Meinungsbild zur Benennung. Gruß, Eckhart

Ulrich Fuchs wrote: Die Vehemenz, mit der du diese Meinung vertrittst, ist bemerkenswert. Du scheinst dir allerdings bei Sachen ziemlich sicher zu sein (wie z.B. wofür die MediaWiki-Funktionalität "gedacht" ist), bei denen ich nicht wirklich überzeugt bin, daß du dir da so sicher sein kannst, insbesondere wenn Teile der Funktionalität (die {{msg:}}- und {{subst:}}-Befehle) damit überhaupt nichts zu tun haben. Hinzu kommt, davon unabhängig, daß selbst wenn das stimmt, daß die Funktionalität für XYZ "gedacht" war, auch das überhaupt kein Argument wäre, sie nicht trotzdem für andere Zwecke zu verwenden. Stattdessen bestehen deine "Argumente" (so man sie denn so nennen kann) aus "Weg mit dem Zeugs" und "das bringt uns in Teufels Küche." Obendrein sprichst du von einem ominösen "Softwarefeature für Navigationsleisten", ohne auch nur im kleinsten Detail darauf einzugehen, was du dir darunter vorstellst, und inwiefern es sich von der bestehenden MediaWiki-Funktionalität unterscheiden soll, und warum die bestehende Funktionalität nicht bereits ein "Softwarefeature für Navigationsleisten" darstellt. Nicht zu vergessen sei, daß du die Pro-Argumente von Eckhart nicht einmal angesprochen, geschweige denn refutiert hast. Ist es das, was ihr hier im deutschen Teil der Wikipedia "Konsens" nennt? Oder habt ihr das hier vielleicht gar nicht? Timwi

Erik Moeller wrote: Daß soetwas geplant war, ist mir schon durchaus bewußt. Ich hoffe stark, daß das entstehende System flexibel genug ist und z.B. benannte Variablen verwendet (anstatt $1, $2, etc.), oder auch die Auslassung von Variablen erlaubt. Allerdings ist sowas nicht notwendig, um schonmal einen Anfang zu machen wie ich auf [[en:-ism]], [[en:Sort algorithm]] oder [[en:Beta]]. Ich gebe zu, daß auch ich von solchen Mammutboxen wie [[en:MediaWiki:Commonwealth of Nations]] etwas überwältigt bin, aber es ist ja wohl nichtsdestotrotz ein sinnvoller und äußerst nützlicher Einsatz dieser Funktion. Das kann ich überhaupt nicht nachvollziehen. Die Programmtexte sind eine endliche Menge (insbesondere nachdem du selbst einräumst, daß der Benutzer solche nicht neuerstellen können sollte). Dafür einen ganzen Namensraum zu schaffen ist natürlich möglich, aber völlig unnötig. Dadurch entsteht weder zusätzliche Funktionalität, noch wird dadurch irgendein Problem beseitigt. Das kommt mir echt langsam so vor, als wolltet ihr krampfhaft irgendwo Probleme sehen, wo überhaupt keine sind. Diese nicht vorhandenen Probleme zu "lösen" ist Zeitverschwendung seitens der Entwickler. Aber davon jetzt mal ganz abgesehen, habe ich ja in diesem Thread ein ganz anderes Problem geäußert, das mit dem MediaWiki-Namensraum an sich nicht so direkt zu tun hat - und zwar die Art und Weise, wie Neuerungen in der deutschsprachigen Wikipedia offenbar gehandhabt werden (oder noch allgemeiner: Entscheidungen gefällt werden). Natürlich gibt es auch in der englischen Wikipedia gewisse Abneigungen gegenüber Veränderungen und Trends, jedoch werden diese im allgemeinen auf nachvollziehbare Art und Weise begründet und ausdiskutiert, anstelle mit "Das bringt uns in Teufels Küche!" abgewiesen und dann nie wieder diskutiert zu werden. Bei sowas vergeht mir gleich die Lust an einer deutschsprachigen Wikipedia. Woran liegt das bei euch? Warum sind eure Einstellungen und Reaktionen in dieser Hinsicht so viel emotionaler und so viel weniger rational? Timwi

Elisabeth Bauer wrote: Doch - diese Diskussionen auf der de-Wikipedia stoßen mich geradezu ab. 90% der Argumente sind bogus, 90% der Inferenzen sind ungültig oder "fallacious", und so weiter. Beispiele: Und wie begründest du, daß Linkleisten "zum Artikel an sich" gehören? Wer sagt denn, daß sie das tun? Unübersichtlich? Hä? Wie bitte? Was? Was fehlt dir denn da an Übersichtlichkeit? Anders gefragt: Inwiefern ist denn der Artikelnamensraum übersichtlicher? Inwiefern ist ein Artikel mit einer zwei Bildschirmseiten großen Tabelle übersichtlicher als mit einem kleinen, aussagekräftigen {{msg:}}? Hä????? Was ist an {{msg:}} bitte "Müll" (bzw. mehr Müll als eine riesige Tabelle mit kaputtem HTML)? Was hindert eine XML-Export-Funktion daran, die {{msg:}}s optional automatisch zu ersetzen? Und selbst wenn nicht, warum kann das nicht der Verwender der Daten automatisch machen bevor er die Artikel weiterverarbeitet? Das ist doch trivial. -- Und dann verwendest du schon wieder dieses aus der Luft gegriffene "zum Artikel gehörend". Schwer? Indem wir ihnen eine einfache Möglichkeit geben, die Navigationsleisten maschinell auszufiltern? Was redest du da? Was für einen Unterschied macht es, ob du nun "MediaWiki:" oder "MediaWiki:Tabelle:" schreibst? Das ist doch völlig dasselbe. Wer dir diesen Floh ins Ohr gesetzt hat, den will ich mal treffen. Das ist Schwachsinn. Es wird in der Dokumentation *empfohlen*, da dadurch die Server-Performance gesteigert werden kann. Die Quelle für diesen Quatsch interessiert mich am meisten. Eine interessante (sprich: sinnlose) Schlußfolgerung - ich habe die MediaWiki-Software auf einem User-Account installiert, und es funktioniert hervorragend. (Sogar ohne memcached - da habe ich mich noch gar nicht rangetraut. Brauche ich auch im Moment gar nicht.) Wo kommt denn jetzt auf einmal dieses "weglassen" her? Wer läßt denn irgendetwas weg? Jeder, der die Daten importieren will, kann die {{msg:}}-Bausteine automatisch ersetzen lassen. Oder halt nicht, in welchem Falle *er* dann bewußt etwas wegläßt, nicht wir. Um nicht den Eindruck zu erwecken, ich würde mich jetzt irgendwie über dich hermachen, nehme ich jetzt auch mal Ausführungen anderer: [[Benutzer:D]] Sagt wer? Warum? Wieso? Eine völlig schwachsinnige Feststellung ohne jeglichen Hintergrund oder jegliche Begründung, die nur darauf hinausläuft, eine bestehende nützliche Funktion künstlich zu limitieren. [[Benutzer:Ulrich.fuchs]] Ich habe keinen Schimmer, von was für Wartungsproblemen der da spricht. Ist es denn so sehr zuviel verlangt, einfach ein Beispiel zu nennen, das diese Theorie verdeutlicht? - Manuell eingefügte Linkleisten sind viel mehr ein Wartungsproblem, weil man jede Änderung dann hundertmal (in jedem Artikel einzeln) durchführen muß. Da schon wieder. Dieses Pseudoargument kommt offenbar immer wieder. "Ich bin der Herrscher und Diktator, und ich werde euch alle verprügeln, und ich mache alles so wie ich es will, und was andere wollen ist mir völlig egal! Wer es wagt, sich mir in den Weg zu stellen, wird gnadenlos zur Strecke gebracht!" -- Wirklich bemerkenswert, daß ihr noch nicht einmal merkt, was ihr da überhaupt sagt. Oder ist das auch so ein Beispiel von dem, was bei euch "Kooperation" genannt wird? -- Was bildet sich dieser Ulrich ein? Wie kommt der mit so einer Attitüde überhaupt an Sysop-Rechte? Ist ihm dieses Privileg vielleicht ein bißchen zu Kopf gestiegen? Er hat sich offenbar allen Ernstes erlaubt, die Arbeit anderer einfach zu zerstören, indem er die MediaWiki-Seiten löscht, ohne auch nur irgendwen zu *fragen*, ob jemand vielleicht was dagegen hätte! Ulrich spricht weiterhin, genauso wie in diesem Thread, ständig von irgendeinem Traumfeature, das diese Navigationsleisten machen soll, weicht aber persistent der Beschreibung eines solchen Features aus. Ich hoffe, hierdurch wird klar, warum ich an der Diskussion - und, breiter betrachtet, an der deutschen Wikipedia überhaupt - nicht teilnehme (und nicht teilnehmen sollte). Timwi

Ulrich Fuchs wrote: Leider nein. Wovon ich da spreche, ist das *Nicht*verwenden von {{msg:}}. Was du offenbar befürwortest. Du befürwortest also Wartungsprobleme? Ihr habt allen Ernstes eine Policy gegen die Erstellungen von Neuem? Ich hatte ja keine Ahnung... Wo kommen bloß eure Artikel her? Ernsthaft: Es gibt keine Policy zu diesem Thema, und schon gar nicht eine, die dich als Admin dazu berechnet, einfach willkürlich irgendwas zu löschen. Du scheinst dir einzubilden, eine "vorläufige" Policy diktieren zu können, die einzuhalten sei, solange kein Konsens besteht. Gleichzeitig sorgst du dann mit allen Mitteln und Wegen dafür, daß niemals Konsens entsteht, und dann hast du dein Ziel erreicht. Wirklich bemerkenswert. Du solltest dich selbst mal reden hören. "Amok laufen". "zukleistern". Mit so einer Dickköpfigkeit glaubst du, einen gerechten Admin abgeben zu können? Ja, Sir, Herr Fuchs, das nächste Mal werde ich dich fragen, bevor ich auch nur einen Stub anlege, oder einen Rechtschreibfehler korrigiere, oder sonst etwas mache, das dir potentiell gegen den Strich gehen könnte. Warum sollte ich? Warum braucht jemand deine Erlaubnis (oder sonst irgendeine Erlaubnis), um etwas anzulegen? Eine kurze Zusammenfassung würde mir schon reichen. Ich bin immernoch neugierig, was für Shortcomings du in dem bestehenden System siehst (und weiterhin persistent verschweigst). Ich kann nicht garantieren, daß ich deine Idee implementieren kann, aber du kannst es doch trotzdem einfach mal posten - vielleicht mag ich einige deiner Ideen und füge sie evtl. dem bestehenden Mechanismus hinzu. Mit dieser Einstellung bekommt ihr echt keine neuen Mithelfer, Ulrich. Wie soll denn aus der deutschsprachigen Wikipedia eine (wohlbemerkt NPOV) Enzyklopädie werden, wenn dieselbe elitäre Clique bestehen bleibt und Neulinge auf diese Weise vergrault werden? Ich finde das ziemlich traurig, und ich finde, daß ihr ernsthaft darüber nachdenken solltet. Timwi

Hallo Mailingliste, On Donnerstag, 26. Februar 2004, you wrote: T> > Ich bin dagegen, den Mediawiki-Namensraum für Navigationsbausteine zu T> > nutzen. Dieses Feature sollte nur für "Meta"-Elemente genutzt werden, T> > nicht für etwas, das zum Artikel an sich gehört. Das MediaWiki-Feature halte ich für durchaus fähig, mehr zu machen als allein die Software-Beschriftungen anzupassen. {{msg:Begriffsklärung}} und {{msg:vfd}} werden ja z.B. gern genutzt. Ich wäre allerdings stark dafür, den MediaWiki-Namesraum in "Textbaustein" anzupassen, das trifft es viel besser. Das würde dann auch das Argument entkräften, dass der Namensraum nur für Meta-Elemente verwendet werden solle. Die bisher gesetzten Bausteine abzuändern, könnten wir notfalls über Nacht mit ein paar Bots erledigen. Dass dann Software-Labels und speziell erstellte Bausteine in einen Topf geworfen werden, halte ich für nicht so dramatisch, solange es möglich ist, eine Liste aller Software-Labels zu erstellen (d.h. [[MediaWiki:All_messages]] aktuell zu halten). Das ist meines Wissens gegeben. Darum kann jemand, der z.B. ein Wiki aufsetzen und die Beschriftungen von der deutschen Wikipedia übernehmen will, diese mit vertretbarem Aufwand importieren. Das Problem, das gegen den großflächigen Einsatz für Navigationsleisten etc. spricht, sehe ich aber woanders, nämlich in der Benutzerfreundlichkeit. Stellt euch die Situation vor, dass jemand einen Artikel liest und dabei einen Fehler in der Navigationsleiste entdeckt. Er wird dann auf "Bearbeiten" klicken und ein mysteriöses {{msg:Nav-Foo}} entdecken. Kein Mensch kommt dann auf die Idee: Ach ja, ich muss ja bloß http://de.wikipedia.org/wiki/MediaWiki:Foo in die Adressleiste eintippen. Das widerspricht für meine Begriffe klar dem Wiki-Prinzip. Auch die Variante auf en: (Liste aller Navigationsbausteine) halte ich für nicht ausreichend, denn die müsste vom Benutzer erstmal gefunden werden. Was also fehlt, ist ein Link "Textbausteine bearbeiten" oder ähnliches. MfG Daniel

Hallo Mailingliste, On Donnerstag, 26. Februar 2004, you wrote: T> [[Benutzer:Ulrich.fuchs]] T> > Die Tatsache, dass Ihr jetzt langsam merkt, dass ihr mit Eurer ersten T> > dämlichen Erfindung (den Navigationsleisten) Wartungsprobleme bekommt T> Ich habe keinen Schimmer, von was für Wartungsproblemen der da spricht. T> Ist es denn so sehr zuviel verlangt, einfach ein Beispiel zu nennen, das T> diese Theorie verdeutlicht? - Manuell eingefügte Linkleisten sind viel T> mehr ein Wartungsproblem, weil man jede Änderung dann hundertmal (in T> jedem Artikel einzeln) durchführen muß. Ihr redet hier aneinander vorbei. Uli ist der Meinung, dass Navigationsleisten prinzipiell unnötig sind, unabhängig davon, ob sie manuell oder per Textbaustein eingebaut werden, womit er IMHO in vielen Fällen recht hat. Kein Mensch will sich nacheinander alle Landkreise in Baden- Württemberg angucken. Hier läuft/lief die Diskussion dazu: http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Formatvorlage_Stadt#Listen Daniel

Doch, genau das meinte der Herr Fuchs. Und genau um solche Listen diskutieren wir. Irgendjemand kam auf die Idee, unter alle bayerischen Städte Links zu allen anderen bayerischen Städten zu packen (warum eigentlich nicht gleich zu allen deutschen?). Irgendwann hat man dann gemerkt, dass das schwer zu warten ist, *weil man in jedem Artikel Änderungen einpflegen muss* - Ein Umstand auf den die Blockierer, wie Du sie nennst, seit Monaten hingewiesen haben, aber das waren ja "nur" Blockierer. Jetzt ist das Schlamassel da, und man versucht das mit der völlig unpassenden Methode zu beheben, ein Softwarefeature zu missbrauchen, dass dafür nicht gedacht ist. Die "Blockierer" weisen wieder darauf hin, dass wir uns damit in ein paar Monaten nur neue Probleme einhandeln, aber das sind ja nur die Blockierer. Sie ist nicht dafür gedacht. Ganz einfach. Eine msg ist eine MESSAGE. Ein Include. Ein Standardtext, den man in einer großen Zahl von Artikeln braucht. Nicht ein Text, den man in einigen wenigen Artikeln braucht (Oder am Ende nur in einem einzigen Artikel: sollten wir msg: nicht auch verwenden, um diese Rechts-oben-Tabellen aus den Artikeln rauszubekommen? Das ginge doch auch ganz prima! - oh gott, man soll Leute nicht auf Ideen bringen) Eine Navigationsleiste ist keine Message, sondern eine Navigationsleiste. Wir müssen das Problem mit "Navigationsleisten in mehreren Kategorien" lösen (siehe [[Gustav Heinemann]]), und zwar so, dass das vom Eingabeaufwand pflegbar und optisch ansprechend darstellbar ist - und das geht nur mit einem Softwarefeature für solche Navigationsleisten, nicht mit einem Missbrauch von "includes" Uli

Man könnte es - um es mal überspitzt zu formulieren, mit einem Krieg vergleichen, der noch gar nicht so lange her ist. Die einen sagen: Marschieren wir doch mal in dieses Land ein, scheint grade ne günstige Gelegenheit - was wir da wollen, wissen wir eigentlich nicht so recht, und was danach da passieren soll, das wird sich schon finden. Da kümmern wir uns jetzt doch noch nicht drum. Erst mal rein, alles andere kriegen wir später. Die anderen sagen: Leute, macht halblang: Ohne Konzept, was ihr da wollt, bringt das garnichts. Und heute? Das Schlamassel ist da, und ausbaden müssen es alle. Am allerwenigsten aber die, die es verursacht haben. So kann man vielleicht leider noch immer Nationen führen, aber keine Projekte managen. Wenn man es versucht, kommt sowas dabei raus wie Toll Collect ("Wir haben doch diese tolle SMS-Funktionalität in den Handies, damit lassen sich doch ganz bestimmt auch gigabyteweise Abrechnungsdaten verschicken" - merkt Ihr was?) Uli

Ulrich Fuchs wrote: Verstehe ich dich richtig? Es geht dir um die Navigationsleisten *an sich*, und überhaupt nicht um den MediaWiki-Namensraum? Warum hast du das in den -zig vorherigen Postings nie gesagt? Warum argumentierst du gegen {{msg:}} und [[MediaWiki:]], wenn es überhaupt nicht darum geht? Jetzt wird mir erstmal einiges klarer. Auch, was du mit den "Wartungsproblemen" meintest (obwohl {{msg:}} und [[MediaWiki:]] diese Wartungsprobleme ja gerade *lösen*). Nichtsdestotrotz ändert das nichts daran, daß ich es immernoch für ziemlich dreist halte, daß du Seiten im MediaWiki-Namensraum einfach gelöscht hast, ohne über Votes for Deletion zu gehen (wie auch immer das bei euch heißt). Ich kann nur wiederholen, daß ihr mit solchen Aktionen die Leute nur vergrault. Timwi

Karl Eichwalder wrote: http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Textbausteine http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Textbausteine/A… Ein paar Highlights von Uli: "Ich werde diese Dinger gnadenlos löschen, wenn sie mir in die Finger kommen, da könnt Ihr abstimmen, so viel ihr wollt." "Was das Löschen angeht: Das ist keine Drohung, ich hab die fraglichen Bausteine eben gelöscht." "Arbiträre Abstimmungen interessieren mich nicht" Hinzu kommen dann noch ähnliche Ausführungen in diesem Thread. Ich kann nur wiederholen, daß mir schleierhaft ist, wie so jemand an Sysop-Rechte kommt. Am Fuß der Seite scheint er jetzt endlich mit seiner mirakulösen Idee, wie das Feature seiner Meinung nach auszusehen hat, rausgerückt zu haben. Die Idee ist an sich nicht schlecht, aber IMHO extrem Overkill, extrem zeitaufwendig zu programmieren, und bringt wenig zusätzlichen Nutzen gegenüber der existieren Funktion. Freut mich, daß mir da jemand zustimmt. Aber ob das was ändern wird? Timwi

Ivo Köthnig wrote: Es ging hier um etwas anderes.

Sorry, aber mein Job als Admin ist, die Enzyklopädie auf der Linie "Enzyklopädie, die Wissen strukturiert verfügbar machen soll" zu halten. Wenn wir uns mal umdefinieren in "Sauhaufen, bei dem jeder jederzeit in bewährten und von vielen Leuten abgestimmten Strukturen rumpfuschen darf, ohne vorher wenigstens ein Minimum an Konsens herzustellen" werde ich mein Verhalten gerne ändern. Bis dahin seh ich sowas als Vandalismus an, und den haben wir noch nie auf den Löschkandidaten gelistet. Du sollst meine Zitate nicht aus dem Zusammenhang reißen. Es ging da um eine 10:11 "Abstimmung", die als finales "Ergebnis" dargestellt wurde - frag mal Jimmy, was er von Abstimmungen hält. Glaub mir, mir ist manchmal schleierhaft, warum ich sie eigentlich immer noch behalten hab. Vielleicht kommt ja am Ende bei meinem Berserkertum doch immer sowas wie ein Fortschritt raus. Hast Du Dir schonmal überlegt, wie Web-Communities funktionieren? Na, so mirakulös war sie nie gewesen. Es hat nur nie jemand danach gefragt. Wir haben mal wieder ein typisches EDV-Problem: Benutzer, die nicht wissen, was sie eigentlich brauchen, und Entwickler, die raten, was die Benutzer wohl brauchen könnten und mal einfach drauf los programmieren, aber nicht verstehen, was wirklich benötigt wird, weil sie zu wenig von der Sphäre der benutzer verstehen. Die Lösung ist kein Overkill, weil sie ein paar Probleme auf einmal lösen würde, die wir gegenwärtig haben (nicht nur eins). Im Gegenteil, sie ist eine Minimallösung, weil sie eigentlich mit dem Thema "Kategorisierung von Artikeln" in Zusammenhang zu sehen ist. Aber sie ist halbwegs zukunftssicher und wachstumsfähig, und ich glaube, dass man sie mit einer wie auch immer gearteten Kategorisierungslösung einfach in Einklang bekommt. Ich gebe zu, dass sie Implementierungszeit erfordert. Aber sie wäre sauber. Die msg: -Lösung ist das nicht - sie ist ein klassischer Hack: Schnell zu implementieren, aber unsauber. Das Problem ist, dass, je mehr solcher Hacks man einbaust, jede neue Änderung schwieriger wird. Es entsteht klassischer unwartbarer Spaghetti-Code, den Du in drei Jahren nur wegwerfen und neu machen kannst. Die Lösung ist unter anderem bereits deshalb aufwändiger zu implementieren, weil die Software schon jetzt recht unmodular ist, soweit ich das auf die Schnelle gesehen hab. Nochmal: Ich plädiere nicht für Overkill (dann würde ich Dir eine Meta-Syntax spezifieren, mit denen die Anwender definieren könnten, wie die Software die einzelnen Bausteinarten rendern sollte etc.) - Overkilll ist etwas, das das aktuelle Problem *zu* gut löst, und zwar mit Features, die keiner braucht. Das was ich aufgeschrieben habe, ist das, was die "Enzyklopädisten" von den "Entwicklern" im Moment *brauchen* - alles dunter ist zu wenig (dann fangen die Enzyklopädisten mit Hacks an), alles drüber ist Overkill. Uli

Du verwechselst Klasse mit Masse. Nicht mit Allwissenheit, aber damit, genau diese Brücke zu sein, verdien ich mein Geld. Stell Dir mal vor. Vielleicht willst Haha. Bleib mal auf dem Teppich. Und da bist Du wieder der typische Programmierer: Dein "Feature" ist, den msg:-Befehl implementiert zu haben, und Du sagst: Damit kriegt Ihr das doch prima hin, was Ihr braucht. Die Anwender sagen: Nein, damit kriegen wir es nicht prima hin. Wir brauchen kein Feature für Messages, wir brauchen eins für Navigationsleisten. Es ist softwaretechnisch heute vielleicht mit einem ähnlichen "Softwarefeature" implementierbar, aber die "Geschäftsfunktion" ist eine strukturell andere. Stop. Liebe Softwareentwickler: Die Anwender schreiben Euch vor, was sie brauchen! Ihr definiert nicht über die Software, wie Eure Anwender arbeiten sollten. In gewissem Maße existiert hier natürlich ein Wechselspiel (in dem befinden wir uns gerade). Aber am Ende definieren die Anwender, was sie brauchen. Auf dem freien Markt wechseln sie im Notfall die Software, hier (wo das nur eingeschränkt möglich ist), gibt's im Notfall böses Blut. Falls Du's noch nicht gemerkt hast: Viele von der Enzyklopädistenfraktion sind relativ genervt darüber, dass wir ganz tolle neue Features bekommen, die keiner braucht (Buttonleiste), aber dass Grundlegendes wie eine Volltextsuche nicht funktioniert. Vielleicht solltet Ihr auch mal an Eurem Selbstverständnis arbeiten. Uli

Timwi &lt;timwi(a)gmx.net&gt; writes: Auch das Datenlöschen ist wichtig. Sehr wichtig sogar. Wichtiger als das Rumfummeln an der Software, wenn ich das mal so sagen darf. PS. Das "die Presse" die WP offensichtlich allerorten lobt und daß die WPner dieses Lob annehmen, ist für alle Beteiligten sehr bezeichnend. - Als allgemeine Enzyklopädie wird doch wohl hoffentlich niemand die WP ernstnehmen wollen; die WP ist allenfalls als gesellschaftliches Phänomen interessant. Beispielsweise der Artikel "Kunst" ist noch immer dünn (zeitweilig war es noch schlimmer, Ulrich hat dort mal aufgeräumt); der unterhaltsame Quatsch von Liebermann wird noch immer zitiert, Suger, Thomas von Aquin, Alberti, Vasari, Leonardo, Dürer, Kant, Herder, Goethe, Schlegels, Hegel, Wagner, Joyce, Mann, Adorno, Benn, Brecht, Schmidt, Wollschläger etc. scheinen aber nicht gelebt zu haben (um nur einige wenige anzuspielen, (künstlerisch) produktiv waren und Theorien entwickelt haben). Der Artikel zu Th. Mann ist wahrscheinlich immer noch herzlich so gut wie nichts, und bei Goethe steht jetzt viel Text, aber nichts wird auf den Punkt gebracht. etc. pp. Mit der Geschichte von Afghanistans sind wir bestimmt auch noch nicht groß vorangekommen. Und eine brauchbare Deutschlandkarte gibt es beim Deutschland-Artikel auch nicht - dafür sind die Feiertage gelistet und der(?) Themenring ist angeklatscht. Was ist mit den Themenringen: "Reiche Staaten", "Natostaaten", Nordseestaaten, Ostseestaaten, Alpenstaaten, Staaten mit dänischen Minderheiten? Das ist alles nicht schlimm, nur sollte man sich nichts in die Tasche lügen. -- | ,__o | _-\_<, http://www.gnu.franken.de/ke/ | (*)/'(*)

Am Freitag, 27. Februar 2004 12:20 schrieb Andreas Hoerstemeier: Eure Argumentation ist ungefähr so: Jemand raucht zu viel, säuft, hockt nächtelang vorm Computer und ernährt sich von Fertigpizza. Seine Haut wird gelb, er hustet, und überhaupt geht's ihm garnicht gut. Eure Kur ist zu sagen: Hier sind ein paar Vitamintabletten, die helfen Dir bestimmt. Uli

Hallo Mailingliste, On Freitag, 27. Februar 2004, Ulrich Fuchs wrote: UF> Sie ist nicht dafür gedacht. Ganz einfach. Eine msg ist eine MESSAGE. Ein UF> Include. Ein Standardtext, den man in einer großen Zahl von Artikeln braucht. UF> Nicht ein Text, den man in einigen wenigen Artikeln braucht (Oder am Ende nur UF> in einem einzigen Artikel: sollten wir msg: nicht auch verwenden, um diese UF> Rechts-oben-Tabellen aus den Artikeln rauszubekommen? Das ginge doch auch UF> ganz prima! - oh gott, man soll Leute nicht auf Ideen bringen) UF> Eine Navigationsleiste ist keine Message, sondern eine Navigationsleiste. Wir UF> müssen das Problem mit "Navigationsleisten in mehreren Kategorien" lösen UF> (siehe [[Gustav Heinemann]]), und zwar so, dass das vom Eingabeaufwand UF> pflegbar und optisch ansprechend darstellbar ist - und das geht nur mit UF> einem Softwarefeature für solche Navigationsleisten, nicht mit einem UF> Missbrauch von "includes" Ich würde gern den Artikel http://de.wikipedia.org/wiki/Tischtennisweltmeisterschaft_(1926) nach [[Tischtennisweltmeisterschaft 1926]] verschieben, entsprechend auch die anderen TT-WM-Artikel. Allerdings hat jede Seite eine Navigationsleiste, die ich (anders als die Landkreis-Themenringe) nicht einfach löschen will, weil ich mir hier gut vorstellen kann, dass jemand sich nacheinander die WM-Artikel ansehen will. Bei der Gelegenheit möchte ich dann auch die Leerzeichen durch non-breaking Spaces ersetzen. Ich werde aber den Teufel tun, anzufangen, diese Themenringe in jedem Artikel einzeln zu ändern. Dein (Ulrichs) Kategorisierungskonzept ist zwar ganz nett, aber es wird dauern, bis das erstmal implementiert ist. Deshalb möchte ich jetzt die MediaWiki-Bausteine verwenden. Betrachte es meinetwegen als dirty workaround, aber es funktioniert nunmal, ist praktisch und, sobald Timwi eine Funktion zur Anzeige von Baustein-Bearbeitungslinks implementiert hat, auch benutzerfreundlich (darauf, dass diese Funktion in absehbarer Zeit kommt, verlasse ich mich jetzt mal). Wenn dann dein Konzept irgendwann in die Praxis umgesetzt wird, kann man die Artikel immer noch ändern. Wenn du also vorhast, meinen Textbaustein [1] zu löschen, dann sag mir jetzt bitte vorher, wie du stattdessen die Tischtennis-WM-Artikel ändern würdest. MfG Daniel http://de.wikipedia.org/wiki/MediaWiki:Navigationsleiste_Tischtennisweltmei…

Hallo Mailingliste, On Samstag, 28. Februar 2004, you wrote: UF> Im übrigen ist derzeit ne ziemlich große UF> Mehrheit gegen solche dirty workarounds UF> (Wikipedia_Diskussion:MediaWiki-Textbausteine - UF> 18:4, wenn ich das richtig seh), also werde UF> ich den Workaround ggf. auch wieder löschen OK, das hatte ich nicht gesehen, dann richte ich mich danach. Wird dann wohl auf den von dir vorgeschlagenen Link auf die Liste hinauslaufen. MfG Daniel

Karl Eichwalder wrote: So ein Quatsch.

Nochmal ein Beispiel, zu München. Jeder der folgenden Themenringe wäre sinnvoll, und könnte theoretisch unter München drangeklebt werden. Keiner ist wichtiger als der andere, alle sind interessant, alle würden eine Naviagtion erlauben: Städte in Bayern Landeshauptstädte in Deutschland Olympia-Städte 10 größte Städte Deutschlands Städte in Bayern mit SPD-Regierung (sehr kleiner Themenring) Wichtige Städte im Nationalsozialismus Bischofssitze EDV-Zentren in Deutschland Verstehst Du nun? Wir haben das Problem der "multiplen Kategorisierung" eines Artikels. Drum funktioniert die simple Denke nicht, dass ein Artikel in genau einen bestimmten Themenring gehört, und man dem Nutzer da eine ganz einfache Navigation anbieten kann. München müsstest Du gleichberechtigt in obige acht Themenringe einsortieren, aber wenn Du das machst, ist das Themenring-Feature nicht mehr in der Praxis verwendbar, wenn Du alle Themenringe einfach unten an den Artikel pappst. Das mag heute noch funktionieren (bei Politikern funktioniert es heute schon nicht mehr), aber je mehr wir wachsen, um so problematischer wird das. Dann brauchen wir vielleicht irgendwann eine Möglichkeit, den Themenring, durch den der Leser gerade navigiert anzuzeigen, und alle anderen auszublenden etc. pp. Das Problem ist viel komplexer, als es eine naive Betrachtung nahelegt. Die Bibliothekswissenschaften schlagen sich seit Jahrhunderten mit dieser Aufgabe herum und haben noch keine endgültige goldene Lösung. Also tut doch bitte nicht so, als wäre es ganz einfach mit ein paar simplen Links unter einem Artikel getan. Uli

Hallo Martin, Martin Zeise schrieb: Ich kann mir nicht vorstellen, was du meinst. Habe eben mal in die Änderungen gesehen und wahllos eine Diskussion angeklickt. Der Link "Artikel" war da. Gruß, Eckhart

Eckhart Wörner wrote: Doch, ich hatte das auch schon mal, kommt aber anscheinend nur selten und unsystematisch vor. Ich achte mal drauf, wenn ich ein Beispiel finde. MfG -asb

Karl Eichwalder wrote: Du denkst total schwarz-weiß. Du meinst, wenn man mal einen Themenring hat, muß man gleich jeden noch so obstrusen aus der Luft gegriffenen Themenring auch haben. Daraus schließt du dann (fallaciously), daß es keine Themenringe geben darf. Timwi

Ulrich Fuchs wrote: OK :) Ich bin weiterhin konstruktiv, du destruktiv :)

Katharina: Ich darf vielleicht - auch wenn es heute schon meine zweite E-Mail ist - darauf hinweisen, dass wohl bald eine weitere, diesmal aber software- gestützte Möglichkeit hinzukommen wird, nämlich ein Kategoriensystem, siehe auch http://meta.wikipedia.org/wiki/Categorization . Dieses sollten wir auf jeden Fall benutzen, denn dann muss man nur noch an *einer* Stelle, nämlich im Artikel, festlegen, wozu dieser Artikel gehört, indem man z.B. in [[Elektron]] folgendes einfügt: [[Kategorie:Physik]] (oder wie auch immer das letztendlich genau aussehen wird). Dann ist der Elektron-Artikel automatisch auch von einer Physik-Kategorie-Seite aus verlinkt. Dieser Mechanismus dürfte einfache Link-Listen ersetzen. Auf die Portale sollten wir aber nicht verzichten. Auf denen werden ja auch nicht alle thematisch passenden Artikel verlinkt, sondern nur wichtige Einstiegsartikel, oder neue/fehlende etc., und das finde ich sehr übersichtlich. El -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++

dest. Mann Junge. Hast Du eigentlich noch nicht begriffen, dass ich einer der letzten bin, die es überhaupt noch für Wert erachten, über das Thema zu debattieren? Die anderen (elian hat den Thread meines Wissens angestoßen, und Du findest auf besagter Seite 18 Leute, die ebenfalls meiner Meinung sind, was die Verwednung des MediWiki-Namespaces angeht) haben offenbar längst frustiert aufgegeben. Argumente von anderen tust Du mit "So wein Quatsch" ab. Du solltest Dir mal überlegen, wer hier von uns beiden der Betonkopf ist. Uli

Hallo Ulrich, Ulrich Fuchs schrieb: Inzwischen ist der Stand nur noch 17:6. Gruß, Eckhart

Timwi &lt;timwi(a)gmx.net&gt; writes: Das liegt nicht an "uns". Das liegt daran, daß die Schreiber jede Woche von softwaretechnischen Neuerungen überrascht werden. Neuerungen sollte höchstens 2x jährlich eingespielt werden - dazwischen nur echte Bugfixes. -- | ,__o | _-\_<, http://www.gnu.franken.de/ke/ | (*)/'(*)

Doch, bitte trennt das. Es wäre ein Hack und nichts anderes, enzyklopädische Information (Navigation=Artikel, die dem Leser als Gruppe präsentiert werden können) und Softwareführungstexte in einen Topf zu werfen. Da dreht's mir als Entwickler und Softwareberater absolut den Magen um, drum wehr ich mich da mit Händen und Füßen. Sowas tut heute vielleicht noch nicht weh, aber wenn Du das in drei Jahren aus irgendwelchen Gründen wieder auseinanderbröseln musst, siehst Du alt aus. Wir haben heute noch Nupedia-Geschichten im normalen Namespace und redirects von ehemals persönlichen Benutzerseiten. Wie Du schon sagst, die Programmtexte sind eine endliche Menge - langfristig sollten die im übrigen ganz aus dem Namensraum raus und in eine datenbank-externe geschichte (XML-Datei) rein: Ein eigener Namespace ist dafür in der Tat zu dick. Bitte, haltet die Architektur sauber. WikiMedi ist dank Eurer Arbeit die beste Wikisoftware, die es derzeit gibt. Wir sollten nicht mit Hacks anfangen - der enzyklopädische Anspruch sollte sich da auch wiederspiegeln. Die Entscheidungsfindung ist durchaus rational. Die engl. WP hat eher die Haltung "Probiern wir mal aus". Aber "einfach mal machen und kucken ob man gegen die Wand fährt" ist bei einem Projekt dieser Größenordung keine vernünftige Strategie. Wenn hier drei Leuten einfällt, was ändern zu wollen, sollen sie sich erstmal drum bemühen, dass die anderen mitziehen, und sie nicht vor vollendete Tatsachen stellen - genau das passiert nämlich gerade mit diesen Navigationsleisten, die gerade mal 10 von 10000 Usern (so kann man das nämlich auch formulieren) haben wollen. Ich behaupte, die engl. WP wird eher Probleme kriegen als wir, die Massen Artikel vernünftig zu verwalten (=wiederfindbar und halbwegs konsistent zu halten), weil sie sich nicht permanent konsolidiert (sie verghisst das nötige "refactoring" der Artikel). Meiner persönlichen Meinung hat sie die Probleme schon (sonst wär die 1.0-Diskussion nicht entstanden). Uli

Zu der Einstellung kann ich nur auf das Posting von Sebastian verweisen, der fragte, warum man seinen Benutzernamen nicht ändern kann. Ich hab dann erstmal etwas vorschnell geantwortet: "weil es noch keiner implementiert hat". Bei näherem drüber nachdenken viel es mir dann aber auch wie Schuppen von den Augen, dass dies gar nicht möglich ist. Außer man läßt all die schönen Signaturen, die man überall in den Diskussionen findet aussen vor und kann die später niemandem mehr zuordnen. Was passiert mit der Nutzerseite? Wird die automatisch verschoben? Tja, dass sind wohl alles Dinge, an die ein fleißiger Programmierer wie Du nicht gedacht hat, als die Funktion eingeführt wurde, und die nun solche simplen Sachen wie die Änderung des Benutzernames verhindern oder nur schwer implementierbar machen. Und so wird munter weiter ein skurilles Feature nach dem anderen implementiert, was den Code von mal zu mal unwartbarer macht. Alles im Namen der Nutzer. Unsere technischen Schwierikeiten haben einen Namen: unüberlegtes und unkontrolliertes anhäufen von Features ohne jedes Konzept. Programmiert wird in der Sprache die man grade gerne hat. Genutzt werden Dinge, mit denen man sich grade gut auskennt. Ob sie sinn machen oder nicht. Wozu werden beispielsweise alle Artikel in einer Datenbank eines Datenbankmanagementsystems wie MySQL abgelegt? Nur um irgendwelche Suchfunktionen nutzen zu können, die weil sie langsam sind (da ein DBMS ja nicht dafür gedacht ist) sowieso ständig abgeschaltet sind? --Ivo Köthnig

Wenn ich meinen Benutzernamen ändere, wäre es schon schön, wenn überall dort, wo ich mal meinen Wilhelm drunter gesetzt habe auch automatisch die neue Seite aufgerufen wird (nicht über ein redir) und auch der Neue Name angezeigt wird. Außerdem wäre es Klasse, wenn die Benutzerseiten auch automatisch an den neuen Platz verschoben werden würden. Letzteres ist ja nicht so schwierig, aber alle Quelltexte nach [[Benutzer:Coma|Coma]] abzugrasen um daraus [[Benutzer:Dorftrottel|Dorftrottel]] draus zu machen ist wohl doch etwas aufwendiger. Daher war meine Idee ja auch, dort im Quelltext [[ID:263]] einzufügen, wenn man mit ~~~[~] unterschreibt. Dann muss dass beim Parsen des Quellcodes eingefügt werden und stellt kein Problem bei einer Änderung dar... Das hab ich ja nicht bestritten. Aber damit sind meine Signaturen nicht geändert worden. Abgesehen davon muss so ein Feature auch so implementiert sein, dass der alte Name eine Weile gesperrt ist, damit ihn sich niemand aneignet, während alle anderen noch realisieren müssen, dass Coma nun ein Dorftrottel ist... Wie sieht das gesellschaftliche Problem aus? Naja, ich weiß jetzt nicht, wie schlimm es ist oder wie schlimm ich es habe aussehen lassen. Aber alleine der Wust an komischen undurchdachten uneinheitlichen Markup-Befehlen ist schon nicht schön. Ich wäre sehr dafür, da mal einen Schnitt zu machen und das durch etwas zu ersetzten, was ich erstens leichter erlernen und zweitens wieder einheitlicher ist. Ich hatte zu dem Thema schon vorschläge gemacht. Aber die sind wohl dummerweise auch in eine Zeit gefallen, wo niemand etwas implementieren wollte, was noch etwas mehr Server-Zeit frist. Erstaunlicherweise wird jetzt ja argumentiert, dass es nichts bringt, einen schnelleren Parser zu basteln. Dann hätte es früher aber auch nicht geschadet ein etwas modulareres System aufzusetzten... Nur weil andere es schlecht machen, müssen wir das ja nicht auch tun. Aber ich gebe zu, dass das natürlich nicht einfach ist zu organisieren... Es hätte mir gereicht, wenn man mir sofort die richtigen Argumente liefert. Zur Not mit einem Verweis auf eine alte Mail, in der das schon steht... Ein Problem ist auch, dass es schwierig ist, aktuelle und gute Infos zum Design zu finden. Dann könnten auch Leute wie ich mitreden, die zwar nicht programmieren wollen, aber schon genug Ahnung haben, um Vorschläge für ein besseres DB-Design machen zu können. Damit kenne ich mich auch nicht so aus, aber es läuft darauf hinaus einen mehr oder weniger guten Wörterbuchindex zu schaffen, der die Artikel auflistet, in denen die Wörter vorkommen. --Ivo Köthnig

Timwi &lt;timwi(a)gmx.net&gt; writes: Die Seiten sehen in der Regel wie Perl-Code aus und am übelsten ist es, daß bei Listen Langzeilen erforderlich sind. Ich schätze mal, daß man 80-90% nach automatisch nach XML umsetzen kann - die Umsetzung in ein ½-wegs erträgliches HTML funktioniert ja auch. Der Rest ist einfach kaputt für eine Übergangszeit; das wird schon nicht tragisch sein, da auch momentan bestimmt 20% nicht optimal sind. -- | ,__o | _-\_<, http://www.gnu.franken.de/ke/ | (*)/'(*)

Timwi &lt;timwi(a)gmx.net&gt; writes: Ja. Von diesen 20% werden ja 80-90% durchaus lesebar bleiben, vermute ich. Man könnte ja auch den alten Stand nur lesbar von einem parallelen Server für eine Übergangszeit zugänglich halten. Es wird immer jemanden geben, der sich mit solchem Kram rumschlagen will. Die Leute hier haben auch genügend Zeit, die kuriosesten Listen zu pflegen, Rechtschreibfehler zu fixen oder ohen zwingenden Grund an der Bildereinbindung rumzufummeln. Irgendwann muß ja das aktuelle Chaos bereinigt werden. Je eher, desto besser. Auch wenn man nur "Probleme" sieht, gibt es immer Wege, diese meistern. -- | ,__o | _-\_<, http://www.gnu.franken.de/ke/ | (*)/'(*)

Nein, nein, und nochmals nein. Bloß nicht. Was auf der technischen Seite passiert (text in der Datenbank) ist mir wurscht. Was aber im Edit-Fenster erscheint, DARF KEIN XML SEIN DAS DARF KEIN XML SEIN Nochmal? DAS DARF KEIN XML SEIN Ich bin vollkommen d'accord, dass eigentlich XML ein geeignetes Instrument wäre, um unsere Artikel sauber zu speichern. Wir sind aber nicht die Nupedia mit einem "Markup-Team". Das Problem ist, dass wir auf Autoren aus sind, die grade bestenfalls mal Word bedienen können (und mit Leerzeichen die Einrückungen machen). Das sind keine EDV-Gurus, die sich durch geschachtelte Open und Close-Tags wühlen können. Der Riesenvorteil eines Wikis ist ja gerade die extrem einfache Syntax. Das Editfenster muss im Grunde wie eine Schreibmaschinenseite daherkommen. XML ist eine Auszeichnungssprache, die von Anfang an dafür entwickelt wurde, mit *Tools* bearbeitet zu werden und *im Notfall* auch mal mit einem Text-Editor. Das Zeug ist nicht menschenwürdig menschenlesbar. Wenn Ihr also die Wahrscheinlichkeit, dass jemand vom Schritt "Bearbeiten anklicken" bis zum Schritt "Text ändern und auf speichern drücken" von 10% auf 0,004% senken wollt, dann führt XML als Editor-Sprache ein. Die Wikipedia-Syntax ist kein Problem - Syntax ist Syntax. Was wir bräuchten, wär ein vernünftige Grammatik-Beschreibung und ein entsprechender Parser. Im Moment machen wir das ganze nämlich mit regular expressions, oder? Uli

Am Samstag, 28. Februar 2004 21:39 schrieb Ulrich Fuchs: Ich hatte von etwas ähnlichem gesprochen! Attribute usw. brauchen wir eigentlich nicht... Also bleibt nur noch etwas mit Klammerung übrig. Das ist dann ungefähr schon wo wie wir es jetzt haben, nur dass wir es fernünftig und schnell parsen können, weil wir nur eine Klammer und einen Namen haben. Zum Beispiel sowas: [[Fett:das ist fetter Text]]. In XML sieht das zugegebenen maßen so aus, und das würde ich auch nicht wollen: <FETT>das ist fetter Text</FETT> Statt "Fett" kann könnte man auch [[b:das ist fetter Text]] schreiben. Das ist prima einfach! und ich kann für jedes Formatierung, ob logische oder physische das selbe Schema verwenden. Für ein Zitat muss man dann halt mal [[zitat:das ist ein Zitat]] schreiben. Aber dann kann sich der Benutzer selbst aus suchen, wie sowas im Browser dargestellt wird. --Ivo Köthnig

Ivo Köthnig wrote: Bitte versuche doch, dir solche herablassenden Kommentare zu sparen. Ich versuche hier, faktisch zur Diskussion beizutragen, und nicht die anderen Kinder zum Weinen zu bringen. ;-) Tut mir leid -- ich tendiere wohl dazu, meine Diskussions"gegner" in einen Topf zu werfen. Das muß ich mir echt abgewöhnen. Bitte beruhige dich etwas. Ich bin sicher nicht unfähig, aber vielleicht drückst du dich nicht klar genug aus. Du wolltest doch, daß der alte Benutzername unbenutzbar wird? Also leg einfach einen unbenutzbaren Account unter diesem Namen an. Was ist daran falsch? Selbst bei nur einem neuen Namen pro Benutzer pro Monat gäbe es immernoch ein heiloses Durcheinander. Bei mehr als 30 Benutzern wäre das schließlich mehr als eine Namensänderung pro Tag. Ich habe eins davon gesehen (http://meta.wikipedia.org/wiki/Wikitax), bin davon aber wirklich nicht sonderlich vom Hocker gerissen. Was ist so sonderlich anders, wenn man statt ''...'' halt [/.../] benutzt. Kommt aufs Gleiche raus. Die vorgeschlagene Syntax zum Einrücken ist Overkill (wer muß schon rechts einrücken) und komplizierter als einfach ':'. Davon abgesehen, hast du meine Frage nicht beantwortet. Was ist denn jetzt an unserer momentanen Syntax uneinheitlich? Aha. Du gibst also selbst zu, daß es zwei Möglichkeiten gibt: (1) Die Syntax ist prima maschinell parsebar. Warum dann eine neue einführen? (2) Die Syntax ist nicht maschinell parsebar. Dann würde eine Umstellung also einen Teil der Artikel vorübergehend unleserlich machen und unnötigen Arbeitsaufwand verursachen. Hm, da bin ich mal gespannt. :-) Bis dahin mache ich mal lieber mit der einfachen und schnellen Wiki-Syntax weiter, hmkay? :-) Andererseits gibt es aber auch einige Dinge, die einfach selbstverständlich sind; vorausgesetzt, es sind hinreichend erfahrene Leute dabei. Was natürlich bei einer so extrem offenen Community wie Wikipedia nicht immer ganz der Fall ist. Für Web-Anwendungen, die Daten verwalten, verwendet man halt ein RDBMS. Das ist halt so. Das hat sich bewährt, rohe Dateien nicht. Ich verstehe eigentlich auch gar nicht, warum so viele Leute das in Frage stellen. Wozu gäbe es denn sonst RDBMSe? Vielleicht. Auf der anderen Seite kann man sich aber fragen, ob die Leute, die diese Art von Diskussionen lostreten, überhaupt dabei sein sollten. (Nicht, weil sie vielleicht etwas nicht wissen, sondern vielmehr, weil sie glauben, etwas zu wissen ("Dateien sind besser! RDBMSe sind Mist!") und von diesem Glauben nicht abzubringen sind.) Mir ist schon klar, daß die Diskussion "RDBMS vs. Textdateien" ein Extrembeispiel ist, und bei subtileren Dingen ist Dokumentation natürlich schon wichtig. Das ist dazu gut, die Daten zu speichern. :-p Es *soll* dazu gut sein, die Daten *effizient* zu speichern. :-p Ernsthaft: Datenbankschemadesign ist wohl eher sowas, wo man nicht sagen kann, "das ist wegen soundso und deshalb dies und jenes". Es ist vielmehr etwas, das so mit der Erfahrung kommt. Man kann vielleicht sagen, "Wir brauchen einen Index, um die Daten effizient abrufen zu können", aber gleichzeitig will man ja auch nicht zu viele Indizes. Das gleiche gilt für verschiedene andere Aspekte (welche Spalten in einer Tabelle, welche Datentypen, welche Zusammenhänge). Es gibt sehr viel mehr "Grundregeln" (z.B. möglichst wenig Spalten variabler Länge) und sehr viel weniger spezifische Entscheidungen ("ich verwende hier X statt Y weil blahblah"). Ich kann dir aber wohl sagen: Die zwei Hauptprobleme, die ich mit der momentanen Datenbank sehe, sind (1) die Aufteilung in 'cur' und 'old', und (2) viel zu häufige Verwendung von Textdatentypen (VARCHAR und BLOB), wenn Ganzzahlen (INT) ausreichen. Brions Vorschlag löst nur das erste. Timwi

Am Sonntag, 29. Februar 2004 06:16 schrieb Timwi: Wer weint denn hier? :-)) Das Problem ist: Jemand will seinen Account-Namen ändern und alle Signaturen und jedes andere Vorkommen seines Namens sollen sich mitändern! Ich glaube ausser Dir ist das jedem hier klar geworden. Du fällst ständig in einen Rechtfertigungsmodus zurück, indem du nicht dieses Problem vor Augen hast, sondern nur ein Teilproblem und präsentierst eine völlig unzureichende Lösung... Dann sind es halt 2 Monate und beim nächsten mal muss man ein halbes Jahr warten. Ist deine Fanatsie so begrenzt, dass du jetzt den Zeitraum in Frage stellen musst. Du solltest Wissen dass man Software an der Stelle leicht anpassen kann. Es benutzt immer die gleiche Klammerung. Das ist leichter erlernbar. Jeder der eckige Klammern sieht, weis genau, da ist etwas ausgezeichnet. Bei unserer Syntax muss man das ganze Markup kennen... Abgesehen davon kann das die Software aus dem gleichen Grund leichter parsen. Zum Beispiel die Verwendung von {{}} solchen Klammern für den Media-Wiki bezug. Zum Beispiel die Verwendung von ~~~~ für Signatur. Zum Beispiel <nowiki></nowiki> (ich dachte wir wollen kein XML). Genauso <math> und </math>. Und dann natürlich noch '',''',==,=== usw. Da ist überhaupt nichts einheitlich. Das ist ein sammelsurium von "Das brauchen wir grade", lasst es uns einfach mal so machen, egal ob es ins bisherige Schema passt. Schon wieder das Rechtfertigungsschema: Ich habe die Antwort auf (1) doch schon längst gegeben. Das war ja der Grund für diese Teildiskussion. Und warum man den 2. Fall erst recht beheben sollte ist doch wohl auch klar. Oder willst Du eine Software haben, die ständig undefinierte Sachen produziert. Also deine Argumentation ist lustig. Bei RDBMS, einem riesen Monster von komplizierter Software (die garantiert 100erte von Bugs enthält) bestehst du auf dessen Verwendung, noch dazu unter dem Performance-Argument (und nach wie vor lasse ich nur das Argument des einfacheren Designs der MediaWiki-Software, Datensicherheit und vielleicht gerade mal so noch Skalierbarkeit gelten). Aber wenn es um XML geht, was ja fast zu unserem Zweck erfunden wurde und unter dem Gesichtspunkt der Einfachheit entwickelt wurde, da ist es dir dann zu kompliziert. Noch dazu wo es schon schnelle, einfache Parser für soetwas gibt, die uns die halbe Arbeit abnehmen könnten. Das Problem dabei ist: Für den einen ist es selbstverständlich, der andere hat keine Ahnung davon. Und an anderer Stelle ist es umgekehrt. Ohne dass es wirklich fruchtet, aber genau deshalb wird jedem Informatikstudenten von Anfang an nahe gelegt die Software zu dokumentieren. Undokumentierte Software ist spätestens nach 5 Jahren unwartbar, weil dann keiner mehr exisitiert, der sie versteht. Abgesehen davon ist genau dass auch ein Grund, warum das Rad ständig neu erfunden wird in dieser Branche. RDBMSe gibts zur Verwaltung von großen strukturierten Datenbeständen. Die gab es auch schon lange vor dem Web, damit hat es überhaupt nichts zu tun. Das Web ist nur ein neuer Anwendungsfall, aber auch dort eigentlich nur für "große strukturierte Datenbestände", wie z.B. Kundendatenbanken... Ich erkläre es auch nochmal hier: Wir haben zwar große Datenbestände, aber unsere Artikel sind höchstens ein bissel verlinkt. Und wir müssen sie maximal nach ein paar Kriterien sortieren. Der einzige Grund für ein RDBMS hier sind die eher Nebensächlichen Vorteile, die ein DBMS noch zu bieten hat. Zum Beispiel, dass viele Personen gleichzeitig drauf zugreifen können, und bestimmte Dinge betreffs Datensicherheit. Schon bei der Skalierbarkeit glaube ich nicht mehr so recht an mySQL oder Postgre. Also ich denke ich weiß schon worüber ich da rede, schließlich habe ich das studiert. Ich mag mich in der Praxis da nicht so gut auskennen, weil ich mich mit Datenbanken nun nicht primär beschäftigt habe, aber ich kenne die Vor- und Nachteile vom theoretischen Standtpunkt durchaus. Und im Gegensatz zu manch selbsternannten mySQL-Guru weiß ich auch ungefähr, was da intern in einer Datenbank abgeht. Wenn ihr statt SQL lieber Relationale Algebra verwenden würdet (und intern wird eine Abfrage (keine Anweisung!, wie z.B. schreib dies und dass dort hin) immer insowas umgewandelt), könnte ich Euch auch genau sagen, welcher Ausdruck schneller als der andere ist. Abgesehen davon kann man an der Stelle von Hand optimieren, was der SQL-Parser nur sehr sehr bedingt kann. Die Frage an der Stelle wäre höchstens noch, ob wir so kompliezierte Abfragen haben oder nicht. Wenn nicht, lohnt sich der Aufwand auch nicht. Abgesehen davon, kann es natürlich auch sein, dass mySQL gar keine direkten Abfragen in dieser Form zuläßt? Dass wissen dann höchstens wieder die Gurus. Warum man welchen Datentyp verwendet finde ich nun auch nicht besonders spannend. Aber das Grunddesign (wozu ist welche Tabelle gut und was steht drind) muss man schon erklären. Meine Erfahrung ist auch die, dass man beim Schreiben einer ausfürlchen Dokumentation wie von selbst viele Schwachstellen findet, weil man nochmal intensiver über sein Design/Code reflektiert. Die Trennung von cur und old hat zumindest den Vorteil, dass cur klein ist und man das noch runterladen kann. :-). Aber im Bedarfsfall sollte eine einfache SQL-Abfrage auch eine Cur-Tabelle generieren können. --Ivo Köthnig

Die Frage bezog sich nicht aufs RDBMS (das ist in der Tat für unsere größenordnung zwingend), sondern auf mySQL im speziellen - für unsere Größenordnung wird das Ding nämlich langsam zu klein. Die Grundkritik war eigentlich, dass die Software keine Abstraktionsschnittstelle von der Datenbank hat. Sie benutzt native mySQl-Features, und die machen es extrem schwierig, jetzt auf eine andere Datenbank (z.b. PostgresSQL) zu wechseln, die mit dem Datenvolumen besser klar kommt (weniger Locking-Probleme bereiten würde etc.) Eigentlich sollten wir eine eigene Volltext-Suche schreiben (bzw. ein möglw. existierendes OpenSource-System verwenden). Der Trick wäre, eine Indizierung neben der eigentlichen Datenbank aufzubauen, etwa per Joblauf zu aktualisieren (es müssten jeweils nur geänderte Artikel betrachtet werden, und an die ist schnell darnzukommen). Also: Nicht die Texte durchuschen (im Moment haben wir glaube ich irgendwelche %like%-Suchen über mySQL?), sonden vorbereitete Index-Tabellen. Wenn's da noch nichts Opensourciges-gibt: Die Algorithmen für sowas sind zumindest bekannt und gut publiziert. Uli

Ulrich Fuchs wrote: Wie Agon ja schon sagte, ist es höchst umstritten, ob PostgreSQL wirklich so viel besser ist bei großen Datenbanken. LiveJournal verwendet auch MySQL, ist (zumindest laut Alexia) sehr viel populärer als Wikipedia, und hat eine zirka zehnmal größere Datenbank (ca. 80 GB im Vergleich zu ca. 8 GB bei Wikipedia). Zwar ist LiveJournal auch nicht gerade die schnellste aller Webseiten, aber (heutzutage) meistens wohl doch erheblich schneller als Wikipedia. Ich kann mich an keine Argumente mehr erinnern, aber ich vertraue Brad Fitzpatrick, daß er weiß, wovon er redet, wenn er sagt, daß MySQL an sich nicht kategorisch weniger geeignet ist als jedes andere RDBMS. Timwi

erik_moeller(a)gmx.de (Erik Moeller) writes: Vor allen Dingen kann es auch nicht angehen, daß bei Städten, Ländern usw. immer nur verwaltungspolitische Themenringe angeboten werden. Die Verwaltungspolitik dominiert bereits in der geliebten Tabelle. Also müßten an eine Stadt z.B. mehrere Themenringen angehangen werden: Universitätsstädte Orte in 100 km Umgebung Orte an der Straße der Romanik Orte an der Weinstraße Orte an der Märchenstraße Orte in der Bundesliga Vor 1500 gegründete Städte Städte, die im 2. Weltkrieg zu mehr als 50% zerstört wurden Bischofssitze Wo soll das bitte enden? Warum sind die hessischen Parallelstädte von Kassel wichtiger als die nicht unbedingt weiter entfernten Städte wie Göttingen oder Erfurt? -- | ,__o | _-\_<, http://www.gnu.franken.de/ke/ | (*)/'(*)

Hallo Mailingliste, On Donnerstag, 26. Februar 2004, you wrote: T> Karl Eichwalder wrote: T> Wir haben Artikel über Personen. Berühmtheiten dominieren bereits in der T> ganzen Enyklopädie. Also müßten z.B. mehrere Artikel hinzugefügt werden: T> Meine Freunde T> Meine Verwandte T> Meine Haustiere T> Meine Nachbarn T> Meine Lehrer T> Meine Autos T> Wo soll das bitte enden? Das hast du falsch verstanden. Gemeint waren nicht überflüssige Artikel, sondern überflüssige Themenringe. Das Problem ist nunmal, dass einige Artikel in mehreren Themenringen auftauchen würden, was dann ziemlich hässlich wird. Den Zustand haben wir teilweise schon bei einigen deutschen Politikern, vgl. http://de.wikipedia.org/wiki/Gustav_Heinemann Daniel

de.wikipedia.org/wiki/Alexander_III._(Russland) Hubs zu Früh gesendet Stefan

Daniel Herding wrote: Ich fürchte, du hast mich nicht verstanden. Mir ist schon klar, daß es dir um Themenringe ging; ich habe versucht, den Fehler in deinem Argument mit einer Analogie zu Artikeln zu verdeutlichen. Nämlich: Nur weil wir keinen Artikel über meinen Nachbarn haben sollten, heißt das nicht, daß wir keine Artikel haben sollten. Folglich: Nur weil wir keinen Themenring "Städte im Umkreis von 500 km" haben sollten, heißt das nicht, daß wir keine Themenringe haben sollten. Verstehst du's jetzt? Außer, daß sich das Layout dieser Leisten noch verschönern läßt, sehe ich da kein Problem. Timwi

Eckhart Wörner wrote: Danke für die Einladung :-) aber die Seite habe ich bereits gesehen. Mir gefallen die Vorschläge alle gut, bis auf #1. Eigentlich ist mir das Design relativ egal, Hauptsache es ist ein Kasten und somit als Ganzes Erkennbar. Irgendwie. Ich hatte ja auf der englischen Wikipedia eine ähnliche Diskussion über das Design dieser Kisten losgetreten: http://en.wikipedia.org/wiki/Wikipedia_talk:Page_footers Ich habe vor, den Konsens abzuwarten, und dann das "Gewinnerdesign" in der globalen CSS-Datei zu definieren, so daß man nur noch class="footer" anzugeben braucht, um das Layout zu erhalten. Insofern wäre es durchaus sinnvoll, wenn nicht jede Wikipedia ein eigenes Layout hätte. :-p Timwi

Ulrich Fuchs wrote: Hm, was meinst du damit? Kannst du das etwas de-kryptifizieren? ;-) Timwi

Eckhart Wörner wrote: Danke sehr. So ist es doch etwas übersichtlicher. Ich habe mir mal erlaubt, das eine Contra-Argument von Eli, das von falschen Annahmen ausging und deshalb ungültig war, zu entfernen. Timwi

Eckhart Wörner wrote: Ja, ich fand das auch etwas seltsam. Vielleicht meinte er "Vermischung von Inhalt und Design" oder "Vermischung von Inhalt und Struktur". Beides ist aber natürlich durch die Wiki-Syntax sowieso der Fall, insbesondere bei größeren Tabellen wie den Taxoboxen. Ich kann mir vorstellen, daß hiermit vielleicht gemeint ist, daß jemand, der über diese Navigationsleisten einen Überblick erhalten möchte, dazu auf eine weitere Meta-Ebene gehen muß... mit anderen Worten: Es klingt für mich in etwa wie: "Wenn die Navigationsleisten die Artikel miteinander verbinden, was verbindet dann die Navigationsleisten miteinander?" - Allerdings sehe ich darin auch irgendwie kein Contra-Argument. Timwi