[Wikide-l] Re: mediawiki-bausteine als navigationselemente

Timwi timwi at gmx.net
So Feb 29 05:16:14 UTC 2004


Ivo Köthnig wrote:

> Da sieht man, dass du selten Artikel schreibst.

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. ;-)

>>(Ihr wart doch bei den msg:-Bausteinen teilweise auch deshalb so
>>abgeneigt, weil sie angebnlich nicht dafür "gedacht" waren. Die
>>Redirects sind absolut perfekt total dafür gedacht, und du beschwerst
>>dich immernoch? :-) )
> 
> Ich hab mich über diese Funktion und ihre Nutzung nie beschwerd. Warum fängst 
> Du hier damit an?

Tut mir leid -- ich tendiere wohl dazu, meine Diskussions"gegner" in 
einen Topf zu werfen. Das muß ich mir echt abgewöhnen.

>>>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...
>>
>>Das ist ja wohl auch trivial, in dem man den alten Benutzernamen einfach
>>als neuen Account registriert und dann nicht verwendet.
> 
> Sag mal will du mich nicht verstehen oder bist du dazu unfähig?

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?

>>Wenn es zu einfach ist, seinen Benutzernamen zu ändern, dann machen die
>>Leute das ständig. Es ist wichtig, Benutzernamen mit Personen (bzw.
>>Persönlichkeiten) verbinden zu können, aber wenn die Benutzernamen sich
>>ständig ändern, geht das nicht mehr. Man weiß dann vorne und hinten
>>nicht mehr, wer wer ist.
> 
> Genau deshalb habe ich ja auch gesagt, dass der alte Account einen Monat lang 
> gesperrt bleiben soll. Das kann man ja auch leicht dahingehend ausbauen, dass 
> der neue mindestens einen Monat bestand haben muss...

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.

>>>Aber alleine der Wust an komischen undurchdachten
>>>uneinheitlichen Markup-Befehlen ist schon nicht schön.
>>
>>Meine Güte, ihr findet wirklich an allem Kritik. :-) Die Mark-up-Befehle
>>sind doch nun wirklich eine Kleinigkeit! Ich kann mir zwar tatsächlich
>>nicht vorstellen, daß sie sonderlich durchdacht wurden (außer die
>>Tabellen-Syntax - die wurde ja vollkommen totdiskutiert), aber was du
>>mit "uneinheitlich" meinst, ist mir auch etwas schleierhaft.
> 
> Es gibt auf meta deutlich bessere einheitlichere Vorschläge. Schau sie dir 
> einfach mal an...

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?

>>>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.
>>
>>Und wer bearbeitet dann die halbe Million Artikel auf die neue Syntax
>>um? :-)
> 
> Software? Dass sollte ja nur dann nicht möglich sein, wenn die alte Syntax so 
> schlecht ist, dass sie nichtmal ein definiertes Ergebniss liefert. Aber dann 
> sollte sie erst recht ersetzt werden...

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.

> Am Ende landen wir sowieso bei etwas, was ähnlich zu XML ist
> und wir werden nur noch logisch formatieren...

Hm, da bin ich mal gespannt. :-) Bis dahin mache ich mal lieber mit der 
einfachen und schnellen Wiki-Syntax weiter, hmkay? :-)

>>>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...
>>
>>Vielleicht sollten wir wirklich mal eine Seite auf meta.wikipedia.org
>>erstellen, die das erklärt.
> 
> Es kann nie Schaden die Software zu dokumentieren und auch zu erklären, warum 
> man bestimmte Dinge so macht, wie man sie macht.

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?

> Wenn die Developer das kapieren würden, könnten sie sich eine Menge
> unnützer Diskussionen ersparen...

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.

>>>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.
>>
>>Das momentane Datenbankschema ist doch im CVS zugänglich:
> 
> Aber ohne jede Erklärung wozu was gut ist oder gut sein soll...

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