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

Sa Feb 28 20:07:08 UTC 2004

> > 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.
>
> Du hast vergessen, zu erklären, was an einem Redirect auszusetzen ist.

Die Performance, dass da immernoch der alte und nicht der neue Name steht...

> Wenn man einen Artikel verschiebt, wäre es auch schön, wenn alle Links
> darauf sich entsprechend korrigeren würden. Da sie das aber nunmal nicht
> tun, haben wir Redirects.

Da sieht man, dass du selten Artikel schreibst. Das kann in die Hose gehen, 
wenn man beispielsweise einen Artikel verschieben will, weil der aktuelle 
Inhalt nicht an diese Stelle gehört...

> (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?

> > 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...
>
> Eine relativ naive Lösung, wenn ich das sagen darf. Du vergißt dabei die
> dadurch entstehende zusätzliche Belastung der Datenbank beim Anzeigen
> jeder Seite.

Also das kann ja nun kaum mehr Zeit beanspruchen als die 
{{msg:trallala}}-Funktion...

> >>>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.
> >>
> >>Ich weiß nicht, wovon du redest. Einen Benutzernamen kann man
> >>trivialerweise mit einer Änderung in der 'user'-Tabelle ändern. Eine
> >
> > 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...
>
> 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?

> >>automatisierte Funktion dafür anzulegen wäre möglich, und auch nicht
> >>sonderlich schwierig, aber es bringt eher gesellschaftliche Probleme mit
> >>sich als technische. (Interessanterweise gibt es exakt dasselbe Problem
> >>und exakt dieselbe Herangehensweise auch bei LiveJournal.)
> >
> > Wie sieht das gesellschaftliche Problem aus?
>
> 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...

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

> > 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.
>
> Ich fürchte, es liegt viel mehr daran, daß darin im allgemeinen kein
> Nutzen gesehen wird.

Den Nutzen darin wird man schon noch früh genug erkennen. Da mach ich mir 
keine Sorgen. Am Ende landen wir sowieso bei etwas, was ähnlich zu XML ist 
und wir werden nur noch logisch formatieren...

> > Erstaunlicherweise wird jetzt ja argumentiert, dass
> > es nichts bringt, einen schnelleren Parser zu basteln.
>
> Keine Ahnung, wovon du redest. Es wird vielmehr dafür plädiert, einen
> schnelleren (und modulareren!) Parser zu schreiben. Ich habe nur meine
> Meinung geäußert, daß ich nicht glaube, daß das unser Performance
> Bottleneck ist (wo ich durchaus falsch liegen könnte).

Es ging nicht darum, was du jetzt sagst, sondern was "früher" gesagt wurde...

> > 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. Wenn die Developer das 
kapieren würden, könnten sie sich eine Menge unnützer Diskussionen 
ersparen...

Aber am Ende neigen sie dann wohl doch dazu lieber mal schnell ein Feature zu 
implementieren. Man hat ja grade mal Zeit zwischen der Beantwortung 100ter 
Fragen gefunden... :-)

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

> Tabellen:
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/wikipedia/phase3/maintenan
>ce/tables.sql?rev=1.11 Indexes:
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/wikipedia/phase3/maintenan
>ce/indexes.sql?rev=1.5
>
> Brion Vibber hat die folgenden Änderungen an dieser Datenbankstruktur
> vorgeschlagen:
> http://meta.wikipedia.org/wiki/Proposed_Database_Schema_Changes
>
> Ich habe im Juli letzten Jahres eine radikal neue Datenbankstruktur
> vorgeschlagen:
> http://meta.wikipedia.org/wiki/Experimental_new_database_schema

Das gilt auch für diese Code-Fragmente...

--Ivo Köthnig