Hallo Ulrich,

Ulrich Fuchs schrieb:

...

ich weise mal auf die Diskussion auf http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Textbausteine hin.

Einige Leute haben entdeckt, dass sich Mediawiki-Bausteine perfekt dazu eignen, Navigationsleisten in Artikel einzufügen. Bis jetzt gibt es: http://de.wikipedia.org/wiki/MediaWiki:Hochtaunuskreis http://de.wikipedia.org/wiki/MediaWiki:Landkreis_F%FCrth http://de.wikipedia.org/wiki/MediaWiki:Nav-Schonen

Wollen wir das?

Nein.

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:

...

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 -

Nein. Das geht am besten über ein Softwarefeature für Navigationsleisten. Das haben wir nicht. Also werden wir auch kein anderes Softwarefeature (nämlich eines, das für die Internationalisierung der Software-Führungstexte gedacht ist) dafür missbrauchen. Ihr könnt Euch gerne für ein entsprechendes Feature stark machen - meine Unterstützung habt ihr. Aber damit, Inhalt und Software-Führungstexte zu vermischen, fangen wir garnicht erst an - das bringt uns in Teufels Küche.

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:

In der Tat diskutiere ich mit Tim Starling darüber, wie wir dieses System verfeinern können, um auch Variablen- Substitution zu ermöglichen. Dann kann man z.B. auch Ländertabellen damit realisieren. Das stellt ein einheitliches Layout innerhalb der Wikipedia sicher und vereinfacht die Wartbarkeit erheblich.

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.

Ich denke, Ulrichs Kritik ist insofern berücksichtigt als im Moment nutzerdefinierte Bausteine bunt gemischt sind mit Programmtexten. Das ist in der Tat unschön. Ich würde mir hier möglichst bald eine Trennung in einen "Template:" bzw. "Vorlage:" Namensraum und den aktuellen "MediaWiki:"-Namensraum wünschen. Im MediaWiki:-Namensraum ließen sich in diesem System keine neuen Seiten anlegen, sondern nur existerende Programmtexte verändern.

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:

Es hindert dich nichts daran, dich an der Diskussion auf http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Textbausteine zu beteiligen.

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:

Ich bin dagegen, den Mediawiki-Namensraum für Navigationsbausteine zu nutzen. Dieses Feature sollte nur für "Meta"-Elemente genutzt werden, nicht für etwas, das zum Artikel an sich gehört.

Und wie begründest du, daß Linkleisten "zum Artikel an sich" gehören? Wer sagt denn, daß sie das tun?

1. hätten wir so bald eine völlig unübersichtliche Menge an

Textbausteinen, unter denen man dann auch wieder nicht durchblickt und die so ihren Nutzen schnell wieder verlieren.

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:}}?

2. in der Datenbank und in der per XML exportierten Seite steht dann

nur noch Müll, bzw. {{msg:irgendwas}} statt der zum Artikel gehörenden Informationen.

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

Damit machen wir es Leuten, die unseren Content anderswo nutzen wollen, unnötig schwer.

Schwer? Indem wir ihnen eine einfache Möglichkeit geben, die Navigationsleisten maschinell auszufiltern? Was redest du da?

ja, mit solchen Subräumen könnte man das erste Problem vermutlich erschlagen.

Was für einen Unterschied macht es, ob du nun "MediaWiki:" oder "MediaWiki:Tabelle:" schreibst? Das ist doch völlig dasselbe.

Der Mediawiki-Namespace lässt sich momentan nur aktivieren, wenn man einen zusätzlichen Dienst namens Memcached laufen lässt.

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.

Der stellt auf Multiuser-systemen aber eine Riesensicherheitslücke dar.

Die Quelle für diesen Quatsch interessiert mich am meisten.

De Facto kann nur jemand, der wirklich einen ganzen Server für sich hat, die Mediawiki-Features nutzen, Leute, die nur irgendwo Webspace mit PHP und Datenbank gemietet haben, jedoch nicht.

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

Wenn wir die weglassen, fehlt doch einiges vom Inhalt, den auch Leute, die Wikipedia importieren, vermutlich erhalten wollen.

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

in MediaWiki sollten nur texte, die für die applikation selbst nötig sind.

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

Die Tatsache, dass Ihr jetzt langsam merkt, dass ihr mit Eurer ersten dämlichen Erfindung (den Navigationsleisten) Wartungsprobleme bekommt

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

MediaWiki ist ein Namespace zur Internationalisierung der Software, Artikelinhalte haben hier drin nichts verloren.

Da schon wieder. Dieses Pseudoargument kommt offenbar immer wieder.

Ich werde diese Dinger gnadenlos löschen, wenn sie mir in die Finger kommen, da könnt Ihr abstimmen, so viel ihr wollt.

"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:

...

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

Offenbar weißt Du ja doch, von welchen Wartungsproblem ich spreche.

Leider nein. Wovon ich da spreche, ist das *Nicht*verwenden von {{msg:}}. Was du offenbar befürwortest. Du befürwortest also Wartungsprobleme?

Mein Job als Admin ist es, dafür zu sorgen, dass Policies eingehalten werden, und das tue ich.

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.

[...] auf einmal Amok Laufen und massenweise unabgestimmt Artikel mit msg: aus dem MediaWiki-Namespace zukleistern.

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?

Vielleicht hätte man mal fragen sollen, bevor man die Dinger überhaupt anlegt?

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?

...

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.

Mitnichten. Es hat nur noch nie einer danach gefragt, [...] Wenn Du möchtest, kann ich das gerne mal spezifizieren - [...]

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.

...

Ich hoffe, hierdurch wird klar, warum ich an der Diskussion - und, breiter betrachtet, an der deutschen Wikipedia überhaupt - nicht teilnehme (und nicht teilnehmen sollte).

Dann ist es vielleicht besser, wenn Du Dich ab jetzt wieder an diese Deine Erkenntnis hältst.

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

Dieses Argument kann ich verstehen und nachvollziehen. Allerdings kann ich mir kaum vorstellen, daß das jemand ein "Wartungsproblem" nennt, also glaube ich nicht, daß Ulrich das meinte. (Wenn doch, wäre nett, wenn er hierauf kurz antworten würde.)

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.

Ja, das stimmt natürlich - niemand will sich alle Landkreise in Baden-Württemberg der Reihe nach angucken. So eine Navigationsleiste hätte ich ja auch niemals angelegt. :-) Wie daraus jedoch folgen soll, daß der MediaWiki-Namensraum und die {{msg:}}-Funktionalität grundsätzlich nicht zu verwenden sei, ist mir vollkommen schleierhaft.

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

wären), dann wird ein solcher Bug eben gefixt. Aber lieber erst mal das Thema totdiskutieren, anstatt einfach mal anfangen und sehen was passiert.

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:

Die anderen sagen: Leute, macht halblang: Ohne Konzept, was ihr da wollt, bringt das garnichts.

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:

Timwi timwi@gmx.net writes:

...

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

Ist das wahr?

http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Textbausteine http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Textbausteine/Ar...

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.

...

Ich kann nur wiederholen, daß ihr mit solchen Aktionen die Leute nur vergrault.

Da hast du recht.

Freut mich, daß mir da jemand zustimmt. Aber ob das was ändern wird?

Timwi

Ivo Köthnig wrote:

...

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.

Was ist daran so schwierig nur einzelnen Versionen zu löschen?

Es ging hier um etwas anderes.

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

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.

"Arbiträre Abstimmungen interessieren mich nicht"

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.

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.

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?

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.

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

Es ist weder dein Job, noch sonst irgendjemandes Job. Hör auf, dir das einzubilden. Du wirkst wirklich wie ein selbsternannter Diktator. Wenn dir Struktur und "Korrektheit" in so einem peinlichen Ausmaß wichtig ist, daß du sogar in Kauf nimmst, daß deswegen nur noch halb so viele Leute bei Wikipedia mitmachen möchten, dann hat deine Sysopschaft ihren Zweck leider verfehlt.

Du verwechselst Klasse mit Masse.

...

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.

Und du bist jetzt also die allwissende Brücke zwischen ihnen, die exakt weiß, was der eine braucht und der andere machen soll?

Nicht mit Allwissenheit, aber damit, genau diese Brücke zu sein, verdien ich mein Geld. Stell Dir mal vor.

Vielleicht willst

du jetzt also auch noch anfangen, den Programmierern "korrekte Manieren" beizubringen, indem du jeden CVS-Commit kategorisch einfach wieder rückgängig machst, weil es ein "Hack" ist?

Haha. Bleib mal auf dem Teppich.

...

Die msg:-Lösung ist das nicht - sie ist ein klassischer Hack: Schnell zu implementieren, aber unsauber.

Du würfelst jetzt zwei Dinge durcheinander. Was ein Feature kann, und wie es implementiert ist, sind zwei Paar Schuhe. Daß MediaWiki nicht viel mehr ist als "Spaghetticode", da stimme ich dir zu.

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.

...

Overkilll ist etwas, das das aktuelle Problem *zu* gut löst, und zwar mit Features, die keiner braucht.

Außer, daß du nunmal nicht derjenige bist, der uns vorschreibt, was wir brauchen, oder wie ein Problem "gut" oder "zu gut" zu lösen ist.

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 timwi@gmx.net writes:

Ich fürchte, wenn das einzige, das du beiträgst, darin besteht, Daten zu löschen und dich dann bei den Entwicklern zu beschweren, dann wird da nie was draus.

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.

Am Freitag, 27. Februar 2004 12:20 schrieb Andreas Hoerstemeier:

Ulrich Fuchs wrote:

...

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

Und dank des neuen Features braucht man dann nur noch einmal das msg einpflegen, und dann im MediaWiki-Artikel die Änderungen für alle anderen eintragen.

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:

...

Wie daraus jedoch folgen soll, daß der MediaWiki-Namensraum und die {{msg:}}-Funktionalität grundsätzlich nicht zu verwenden sei, ist mir vollkommen schleierhaft.

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

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:

Oder wir müssen zu jeder TTWM auch noch einen Themenring der anderen Weltmeisterschaften des gleichen Jahres beistellen und die Liste aller WMs, die am gleichen Ort stattgefunden haben, und alle beliebigen Events des gleichen Jahres an diesem Ort.

So ein Quatsch.

...

So ein Quatsch.

Du verstehst es nicht. Dich haben sie schon (= du denkst hübsch in eingefahrenen Gleisen). Das muß ja auch nicht schlecht sein, aber für mich ist das langweilig.

Man kann jedes Ding in viele Zusammenhänge sinnvoll einsortieren - und für jeden dieser Zusammenhänge ist ein "Themenring" durchaus denkbar. Fällt der Groschen nun?

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:

Mir ist bei der Durchschau der "letzten Änderungen" aufgefallen, dass, wenn ich auf eine Artikel-Diskussion klicke, zwar diese Diskussion angezeigt bekomme, zum eigentlichen Artikel aber kein Link existiert und und selbst die "Links auf diese Seite" nicht zum Ursprungsartikel führen. Gibt es da Möglichkeiten der Verbesserung?

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:

...

Mir ist bei der Durchschau der "letzten Änderungen" aufgefallen, dass, wenn ich auf eine Artikel-Diskussion klicke, zwar diese Diskussion angezeigt bekomme, zum eigentlichen Artikel aber kein Link existiert und und selbst die "Links auf diese Seite" nicht zum Ursprungsartikel führen. Gibt es da Möglichkeiten der Verbesserung?

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.

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:

Man kann jedes Ding in viele Zusammenhänge sinnvoll einsortieren - und für jeden dieser Zusammenhänge ist ein "Themenring" durchaus denkbar. Fällt der Groschen nun?

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:

...

Du denkst total schwarz-weiß. Du meinst, wenn man mal einen Themenring hat, muß man gleich jeden noch so obstrusen aus der Luft gegriffenen

Weißt Du was? Ich gebs auf. Du willst es nicht verstehen, und Du bist so von der Richtigkeit Deiner Sicht von etwas überzeugt, von dem Du offensichtlich nicht die geringste Ahnung hast. Du weigerst Dich beharrlich, die Argumente der "Enzyklopädisten" auch nur zur Kenntnis zu nehmen. Meine Zeit ist mir zu schade. Programmier, wozu Du lustig bist - ich lösch, wozu ich lustig bin.

OK :) Ich bin weiterhin konstruktiv, du destruktiv :)

Katharina:

Wir haben bereits X verschiedene Versuche, ein und dasselbe Nutzerbedürfnis umzusetzen (nämlich Zusammengehörendes als Zusammengehörendes zu erkennen).

Wäre es nicht schlauer, EINE Lösung zu suchen, diese as far as possible zu automatisieren und DIESE EINE Lösung dann eisern durchzziehen statt erneut was neues zu versuchen, wo der Misserfolg bereits vorprogrammiert ist?

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

dest.

...

Im übrigen ist derzeit ne ziemlich große Mehrheit gegen solche dirty workarounds (Wikipedia_Diskussion:MediaWiki-Textbausteine - 18:4, wenn ich das richtig seh),

Überrascht mich wenig; die, die dafür gestimmt hätten, sind schon längst aufgrund deiner Herrschaft frustriert abgereist.

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:

Im übrigen ist derzeit ne ziemlich große Mehrheit gegen solche dirty workarounds (Wikipedia_Diskussion:MediaWiki-Textbausteine - 18:4, wenn ich das richtig seh), also werde ich den Workaround ggf. auch wieder löschen

Inzwischen ist der Stand nur noch 17:6.

Gruß, Eckhart

Timwi timwi@gmx.net writes:

Woran liegt das bei euch? Warum sind eure Einstellungen und Reaktionen in dieser Hinsicht so viel emotionaler und so viel weniger rational?

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.

...

Ich denke, Ulrichs Kritik ist insofern berücksichtigt als im Moment nutzerdefinierte Bausteine bunt gemischt sind mit Programmtexten. Das ist in der Tat unschön. Ich würde mir hier möglichst bald eine Trennung in einen "Template:" bzw. "Vorlage:" Namensraum und den aktuellen "MediaWiki:"-Namensraum wünschen. Im MediaWiki:-Namensraum ließen sich in diesem System keine neuen Seiten anlegen, sondern nur existerende Programmtexte verändern.

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.

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.

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?

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

...

Da dreht's mir als Entwickler und Softwareberater absolut den Magen um, drum wehr ich mich da mit Händen und Füßen.

Ehrlich gesagt dreht sich bei *mir* absolut der Magen um, wenn sich jemand so totalitär und autoritär verhält. Ich kann mir nicht vorstellen, der einzige zu sein, der dadurch von der deutschen Wikipedia abgehalten wird und lieber bei der englischen mitmacht, wo man sich willkommener fühlen kann.

...

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.

Dann kannst du mir ja mal in drei Jahren schreiben, einen Link auf dieses Posting anhängen und sagen: "Ich hab's dir doch gesagt".

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

...

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?

Ich verstehe das Problem nicht. Dafür gibt es doch Redirects. Es gibt durchaus einige Leute auf der englischsprachigen Wikipedia, die ihren Benutzernamen mal geändert haben.

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

...

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

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?

...

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.

Zu einem gewissen Maße stimme ich dir da zu. Einige Dinge in der MediaWiki-Software sind wirklich etwas chaotisch und schlecht durchdacht. Es ist aber keineswegs so schlimm, wie du es aussehen läßt.

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

Ganz offensichtlich finden sich die Leute in diesem Quelltext ja noch prima zurecht (und bei mir will das was heißen). Andere Open-Source-Projekte sind nicht weniger chaotisch und/oder schlecht durchdacht. So ist das halt, wenn viele zusammenarbeiten und niemand koordiniert.

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

...

Wozu werden beispielsweise alle Artikel in einer Datenbank eines Datenbankmanagementsystems wie MySQL abgelegt?

Diese Frage kommt auf wikitech-l immer wieder und wieder auf. Wir brauchen das wirklich nicht jede Woche von Neuem durchzukauen. RDBMSe haben ihre klaren Vorteile, und Wiki-Systeme, die auf Dateien basieren (wie Twiki und MoinMoin) sind für Riesenwebsites wie Wikipedia unbrauchbar.

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

Die momentane Datenbankstruktur ist schlecht designt und deshalb langsam. Auch wird - soweit ich das sehe - memcached nicht zu seinem vollen Potential genutzt. Das sind beides keine Argumente, grundsätzlich keine DB zu verwenden.

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.

Die Volltextsuche ist ein anderes Thema; damit habe ich wenig Erfahrung, und ich weiß nicht, was es neben DBMSen da für Alternativen gibt. Evtl. ist dafür ein anderes System besser geeignet.

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 timwi@gmx.net writes:

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.

Die Seiten sehen in der Regel wie Perl-Code aus und am übelsten ist es, daß bei Listen Langzeilen erforderlich sind.

Und wer bearbeitet dann die halbe Million Artikel auf die neue Syntax um? :-)

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.

Timwi timwi@gmx.net writes:

Du würdest also allen Ernstes 20% der Wikipedia vorübergehend unbrauchbar machen

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.

und extrem viel Arbeitsaufwand erzeugen?

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.

Nur um auf eine andere Wiki-Syntax umzusteigen?

Irgendwann muß ja das aktuelle Chaos bereinigt werden. Je eher, desto besser.

Auch wenn man nur "Probleme" sieht, gibt es immer Wege, diese meistern.

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

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:

DAS DARF KEIN XML SEIN

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:

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

Am Sonntag, 29. Februar 2004 06:16 schrieb Timwi:

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

Wer weint denn hier? :-))

...

...

...

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?

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

...

...

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.

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.

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

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.

Davon abgesehen, hast du meine Frage nicht beantwortet. Was ist denn jetzt an unserer momentanen Syntax uneinheitlich?

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.

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.

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.

...

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? :-)

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.

...

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.

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.

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?

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.

...

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.

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.

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

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.

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.

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

...

Wozu werden beispielsweise alle Artikel in einer Datenbank eines Datenbankmanagementsystems wie MySQL abgelegt?

Diese Frage kommt auf wikitech-l immer wieder und wieder auf. Wir brauchen das wirklich nicht jede Woche von Neuem durchzukauen. RDBMSe haben ihre klaren Vorteile, und Wiki-Systeme, die auf Dateien basieren (wie Twiki und MoinMoin) sind für Riesenwebsites wie Wikipedia unbrauchbar.

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

Die Volltextsuche ist ein anderes Thema; damit habe ich wenig Erfahrung, und ich weiß nicht, was es neben DBMSen da für Alternativen gibt. Evtl. ist dafür ein anderes System besser geeignet.

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:

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

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@gmx.de (Erik Moeller) writes:

Ich denke, Ulrichs Kritik ist insofern berücksichtigt als im Moment nutzerdefinierte Bausteine bunt gemischt sind mit Programmtexten.

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?

Hallo Mailingliste,

On Donnerstag, 26. Februar 2004, you wrote:

T> Karl Eichwalder wrote:

...

erik_moeller@gmx.de (Erik Moeller) writes:

...

Ich denke, Ulrichs Kritik ist insofern berücksichtigt als im Moment nutzerdefinierte Bausteine bunt gemischt sind mit Programmtexten.

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?

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

-----Ursprüngliche Nachricht----- Von: wikide-l-bounces@Wikipedia.org [mailto:wikide-l-bounces@Wikipedia.org] Im Auftrag von Stefan Kühn Gesendet: Donnerstag, 26. Februar 2004 18:07 An: 'Daniel Herding'; 'Mailingliste der deutschsprachigen Wikipedia' Betreff: AW: [Wikide-l] Re: mediawiki-bausteine als navigationselemente

...

http://de.wikipedia.org/wiki/Gustav_Heinemann

Genau wegen diesen unschönen Aussehn habe ich mich auch dagegen ausgesprochen. Einzig und allein bei Vorgängern und Nachfolgern würde ich eine Navigationsleiste befürworten, wie z.B.

de.wikipedia.org/wiki/Alexander_III._(Russland)

Hubs zu Früh gesendet

Stefan

Daniel Herding wrote:

...

...

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?

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.

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?

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

Außer, daß sich das Layout dieser Leisten noch verschönern läßt, sehe ich da kein Problem.

Timwi

Eckhart Wörner wrote:

Hallo Timwi,

Timwi schrieb:

...

Außer, daß sich das Layout dieser Leisten noch verschönern läßt, sehe ich da kein Problem.

Kein Problem: Auf http://de.wikipedia.org/wiki/Wikipedia:Themenringe ist eine Abstimmung zu diesem Thema. Du bist herzlich eingeladen, hier auch neue Vorschläge zu bringen.

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:

...

Außer, daß sich das Layout dieser Leisten noch verschönern läßt, sehe ich da kein Problem.

Dann hast Du vermutlich noch nie wirklich mit einer Enzyklopädie *arbeiten* müssen.

Hm, was meinst du damit? Kannst du das etwas de-kryptifizieren? ;-)

Timwi

Eckhart Wörner wrote:

Hallo,

Elisabeth Bauer schrieb:

...

ich weise mal auf die Diskussion auf http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Textbausteine hin.

Die Diskussion zu diesem Thema ist extrem unübersichtlich geworden und drehte sich teils im Kreise. Aus diesen Grund habe ich den Inhalt nach [[Wikipedia Diskussion:MediaWiki-Textbausteine/Archiv]] verschoben und das Ganze mal zusammengefasst. Ich hoffe, ich habe alle Argumente aufgelistet, wenn nicht, bitte nachtragen.

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:

Hallo Timwi,

Timwi schrieb:

...

Ich habe mir mal erlaubt, das eine Contra-Argument von Eli, das von falschen Annahmen ausging und deshalb ungültig war, zu entfernen.

Und zwei weitere sind mir absolut schleierhaft, und der Autor sagt uns nicht, was er damit meint. :-(

1. Vermischung von Content und Inhalt

Was soll das? Ich habe es extra noch einmal nachgeschlagen; Inhalt ist die Übersetzung von Content.

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.

2. Es braucht eine weitere Metaebene zur Navigation innerhalb der

Navigationsleisten Ebenfalls keinen blassen Schimmer, was das heißen soll.

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