Wikiup:Verbesserungsvorschläge/Feature-Requests/Archiv/2007

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikiup:Verbesserungsvorschläge/Feature-Requests/Archiv/2007#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Wikiup:Verbesserungsvorschl%C3%A4ge/Feature-Requests/Archiv/2007#Thema_1

Änderungen von IPs überprüfen

Hallo! Wäre es nicht sinnvoll einen Knopf für die Admins zu schaffen, mit dem sie hinter Änderungen von IPs einen automatischen "Überprüft"-Vermerk machen können? Ich denke dabei an sowas in der Beobachtungsliste:

(Unterschied) (Versionen) . . Adana‎; 17:16 . . (+2 Bytes) . . 89.49.70.230 (Diskussion) Überprüft. Admin-Name

Dann müssten wir uns nicht mehr alle gleichzeitig auf die Änderungen von IPs stürzen, sondern würden auf Anhieb sehen, dass da schon ein Admin drüber geguckt hat. --Enricopedia ⇄ 17:41, 21. Jan. 2007 (CET)

Erstens glaube ich ist es der falsche Ansatz nur Admins sowas zu erlauben (viel zuviel Aufwand alle zu überprüfen; Überprüfung ist auch normalen Benutzern möglich). Zweitens wird das allgemein schon praktiziert, und zwar bei den Tools, die einem die Letzten Änderungen anzeigen. Zu guter Letzt gibt es noch Wikipedia:Geprüfte Versionen und Wikipedia:Gesichtete Versionen. -- Amtiss, SNAFU ? 19:23, 21. Jan. 2007 (CET)

• Die Tools die einem die letzten Änderungen anzeigen und wo dies praktiziert wird, kenne ich nicht.
• Die Beschränkung nur Admins zuzulassen, muss natürlich nicht sein aber es sollte auch nicht jeder angemeldete Benutzer die Möglichkeit haben, weil man sich dann wieder nicht darauf verlassen kann, dass da nicht zwei Spinner am Werk sind.
• Wikipedia:Geprüfte Versionen ist ein ganz anderes Thema
• Wikipedia:Gesichtete Versionen würde, wenn es so umgesetzt wird, meinen Vorschlag überflüssig machen, weil nicht gleich jeder Mist sofort im Artikel steht und man mehr Zeit zum überprüfen hat.

Letztendlich sollte mein Vorschlag eine Verbesserung für Jeden und für jedermanns Beobachtungsliste sein, weil die ja wohl von den meisten Leuten regelmäßig genutzt wird − im Gegensatz zu den angesprochenen tools. Gruß --Enricopedia ⇄ 21:16, 21. Jan. 2007 (CET)

Anzeige von Herkunftslink

Es wäre oft hilfreich, wenn unter einem Artikel, ähnlich dem redirect Link angezeigt wäre, was in dem angeklickten Link hinter dem | steht. Oft ist dann klarer, warum man hierher kommt. Denn manchmal sind ja die Links mit einem ganz anderen Text als den eigentlichen verlinkten Artikel überblendet. Das würde die Handhabung meiner Meinung für den Leser wesentlich erleichtern. --K@rl 22:53, 22. Jan. 2007 (CET)

Kategorie in Redirects

nun gibt es das problem, dass im artikel nicht mehr über die kategorien navigiert werden kann, dazu müsste man auf die zeile unter der überschrift klicksen, um direkt im redir zu landen. daher wäre es sehr hilfreich, wenn die kategorien der weiterleitung auch im zielartikel aufscheinen. zb Schnitzen

1. die zeile „weitergeleitet“ erscheint auch unten bei den kats

   Kategorien: Holzverarbeitung ..

   Kategorien der Weiterleitung siehe: Holzschnitzer - mit redirect=no, das liesse sich wohl auch per CSS erledigen, erfordert aber den zusätzlichen klick

2. die kategorien werden mit in den artikel übernommen (fernziel wäre natürlich eine aufsummierung aller weiterleitung im sinne eines „in diesem artikel werden folgende schlagworte zusätzlich behandelt“)

   Schnitzen: Kategorien: Holzverarbeitung .. - also mit {PAGENAME} davor

   Holzschnitzer: Kategorien: Handwerksberuf .. mit dem referrer-titel

   1. manuell eingepflegen - dazu müsste es dann eine ungekehrte variante des <NOINCLUDE> geben, damit jetzt der artikel nicht kategorisiert wird, sondern nur angezeigt wird, etwa <REDIRKAT>Kategorie:Handwerksberuf</REDIRKAT> oder könnte das eine Vorlage {Redirkat|Holzschnitzer|Handwerksberuf|..} leisten?
   2. automatisch einbinden - der quellcode des redirects muss sowieso ausgelesen werden, also könnten die kats ohne sonderliche serverarbeit zwischengespeichert und automatisch angezeigt werden, was aber softwareseitig wenig sinn macht, wenn es sich nur um schreibvarianten handelt, und zwei „arten“ von redirs einführen, ist wohl auch sinnlos - andrerseits, reine schreibvarianten sind wohl kaum kategorisiert, und unkategorisierte redirs können dann ausgeblendet werden

-- W!B: 05:36, 8. Jan. 2007 (CET)

das Feld "Zusammenfassung und Quellen"

Als User kann man einstellen dass man gewarnt wird wenn man das Feld leer lässt. Dies ist eigentlich nützlich. Könnte man das nicht für alle IP's und für neuen User als Standard setzen?

Außerdem wäre es besser wenn man das Häkchen getrennt für Artikel und Disk Seiten setzen könnte. Das eine Default-mäßig an das andere aus.

(Ich habe das gleiche schon auf FZW und VV vorgeschlagen, jedoch ohne Reaktion) --Steffen2 20:21, 8. Jan. 2007 (CET)

Ich stimme absolut zu! Optimal waere eine Erinnerung bei Artikel-, nicht bei Diskussionsseiten... aber egal, sinnvoll waere es auf jeden Fall. Uebrigens: Die polnische Wikipedia hat sogar eine aehnliche Funktion, wenn man als angemeldeter Benutzer die Option "Warnen" *nicht* aktiviert hat! --Ibn Battuta 18:21, 27. Mai 2007 (CEST)

Beim Ausführen von SLA...

...bekommt man einen Text angezeigt: Dieser Artikel hat eine Versionsgeschichte, dann ein Link darauf. Praktisch wäre, wenn die Anzahl der Versionen angezeigt werden könnte. Damit würde vermieden, dass vandalierte und dann irrtümlich mit {{löschen}} versehene Artikel gelöscht werden. Natürlich sollte man das ohnehin überprüfen, aber das dauert eben... Wenn das nicht zuviel Arbeit wäre also eine gute Sache --schlendrian •λ• 11:33, 9. Jan. 2007 (CET)

E-Mail Benachrichtigung

Hallo bin ich hier richtig? Wäre es nicht schön eine E-Mail Benachrichtigung zu bekommen, wenn sich an einem speziellen Artikel (an dem man sehr interessiert ist) etwas geändert hat? Grüße --LBRH 19:48, 13. Jan. 2007 (CET)

Sollte nicht so problematisch sein, ist auf den Commons bereits aktiv und funktioniert super. Hab aber keine Ahnung, ob das bei einer Wikipedia die Server mitmachen. --Flominator 20:13, 13. Jan. 2007 (CET)

Macht auf jeden Fall Sinn. Für die Admins .Die könnten sich die Wikipedia in "Destrikte aufteilen" - dann weitere Bezirke (und für die wiederum zuständige Admins ernennen) usw.... Wenn in jeweiligen Zuständigkeitsbereich gearbeitet wird gibt es eine Benachrichtigung. Wäre auch ne Art von Qualitätssicherungssystem. Aber das machen die bestimmt schon oder? Grüße --LBRH20:24, 13. Jan. 2007 (CET)

Die Funktionalität ist da, es wird für uns aber trotzdem (noch?) nicht angeschaltet. Genaueres dazu findet sich bereits hier: WP:FZW Gruß, --CyRoXX ^(? ±) 20:31, 13. Jan. 2007 (CET)

Danke CyRoXX/Flominator ! Grüße --LBRH 22:38, 13. Jan. 2007 (CET)

Leute lasst uns WikiQuiz spielen !

Jeder der mitspielen möchte baut in einen/mehreren Artikel(n) seiner Wahl folgenden Baustein ein:

Beispiel: Artikel Boris Becker

{WikiQuiz:nodisplay
|frage-schwierig=2|Wann wurde Borris Becker Wimbledon Sieger?
|antwort-n|1968
|antwort-r|1985
|antwort-n|1990
}
Die Frage sollte möglichst leicht zu beantworten sein, und drei Antworten zur Auswahl geben. Der Baustein befindet sich im Artikel und wird nicht angezeigt, damit das Layout nicht leidet. Auf der Hauptseite plazieren wir das WikiQuiz Feld mit der Frage und den möglichen Antworten. Das Spielen erfolgt mittels anklickbaren Checkboxen. 500000 mögliche Fragen von einem Script per Zufall erstellt das ist schon was, oder? Wo gibt es sowas sonst? Wie wärs mit einer Rangliste, einsetzbaren Joker.....und .....und..... Das Quiz spricht sich rum => mehr Traffic => mehr Sponsoren......
Grüße an alle: --LBRH 16:37, 16. Jan. 2007 (CET)

ganz sicher wird dafür nicht der Artikel-Quelltext mit dem Baustein aufgeblasen --schlendrian •λ• 17:59, 17. Jan. 2007 (CET)

Ich finde die Vorteile überwiegen, oder? --LBRH 18:43, 17. Jan. 2007 (CET)

Unnötige Spielerei. --Στέφανος (Stefan) ± ■  18:45, 17. Jan. 2007 (CET)

Lizenzen in der Versionsgeschichte

Da ja viele Autoren, ich auch, ihre Beiträge nicht nur unter der GFDL, sondern auch anderen Lizenzen freigeben, und das besonders für WEiternutzer interessant ist, wäre es ja praktisch, das gleich in der Versionsliste sichtbar zu machen. So könnte man beispielsweise in den Einstellungen eine Zusatzlizenz angeben, die dann automatisch in der Versionsgeschichte agezeigt wird:

20:05, 24. Jan. 2007 Benutzer (Diskussion | Beiträge | CC-BY-SA) K typo

20:03, 24. Jan. 2007 Name (Diskussion | Beiträge)

20:00, 24. Jan. 2007 Blabla (Diskussion | Beiträge | FWL) Kommentar

19:35, 24. Jan. 2007 NickiBot (Diskussion | Beiträge | PD) K interwiki

14:10, 20. Jan. 2007 ≈ (Diskussion | Beiträge | Lizenziert) Schlimme Fehler entf.

„Lizenziert“ würde bedeuten, dass ein Benutzer beispielsweise mehr zwei oder mehr zusätzliche Lizenzen benutzt und diese alle auf einer eigenen Seite sammelt und kommentiert. Die Links zu den WP-Artikel sollten durch solche auf spezielle Hinweisseiten oder Bausteine ersetzt werden. Einfacher als diese m. E. eleganteste Lösung wäre vermutlich eine automatisierte Hinzufügung des Lizenzlinks zur Zusammenfassung.--Hannes2 Diskussion  18:37, 1. Feb. 2007 (CET)

Nein, das halte ich für keine gute Idee. Es ist grundsätzlich sogar fraglich, ob manche Lizenzen einfach inkompatibel mit GNU-FDL sind (Näheres weiß ich dazu nicht), außerdem würde es ein riesiges Chaos verursachen, da verschiedene Bearbeitungen eines Artikels teilweise unter verschiedenen Versionen vorlägen, wobei ja nur die hinzugefügten Teile eine andere Lizenz hätten … Grüße, — Pill δ 12:03, 22. Feb. 2007 (CET)

Dieses Chaos gibt es ja im Prinzip jetzt schon, weil viele Benutzer ihre Beiträge jetzt schon doppelt oder dreifach oder noch mehr lizensieren. So wäre es dann für die Weiternutzung viel einfacher, anstatt immer die Bausteine auf jeder Benutzerseite anschauen zu müssen oder sogar immer nachfragen zu müssen. Und damit nicht nur die hinzugefügten Teile mehrfach lizensiert werden, sondern auch ltere Beiträge so gentzt werden können, würde ich dafür plädieren, es so einzurichten, dass man es einstellen kann, dass auch alle älteren Beiträge so lizensiert werden, wie man sich das wünscht. Ich halte es durchaus für denkbar, dass so manche Artikel entstehen, die nur von Auotren geschreiben wurden, die ihre Beiträge auch mit einer CC-Lizenz lizensiert haben. Diese Artikel könnte man dann vollständig unter einer CC-Lizenz weiternutzen. Deshalb gibt es von mirfür diesen Vorschlag auch ein dickes  Pro. --Mg 19:03, 9. Apr. 2007 (CEST)

TOC automatisch einklappen u.Ä. TOC

auf Wikipedia:VV#TOC automatisch einklappen u.Ä. habe ich schon eine Diskussion angefangen. vielleicht war das der falsche platz. Deshalb stelle ich das jetzt noch hier herein! --Marci ^Diss. 13:52, 14. Feb. 2007 (CET)

Versionsvergleich genauer dargestellt

Teilweise werden nichtpassende Absätze miteinander verglichen und der passende Absatz erscheint dann darunter. Wenn z.B. ein Absatz eingefügt wurde. Dies sollte die Software erkennen. Wahrscheinlich ist der beste Weg nach dem jetzigen Vergleich für sehr "rote" Texte zu prüfen ob nicht der darüber oder der darunterstehende besser passt. Passen zwei ein wenig dann ist es wahrscheinlich eine Aufteilung. Dann sollte der Absatz der z.B. aufgeteilt wurde (gekennzeichnet) zweimal dargestellt werden. --Diwas 05:05, 18. Feb. 2007 (CET)

dafür:

1. W!B: - WinMerge etwa ist ein OpenSource-Projekt, dass genau diese option bietet, falls ein algorithmus noch gesucht wird- ich find, einer der nettesten differ am markt..
2. Diwas
3. Quilbert 問
4. Ibn Battuta 18:22, 27. Mai 2007 (CEST) Falls nicht zu viel Aufwand, koennte ausserdem noch innerhalb des Absatzes verglichen werden... denn bei einzelnen geloeschten oder eingesetzten Saetzen gibt's manchmal das gleiche Problem...

dagegen:

Falls das automatisch nicht geht, dann sollte man die Zuordnung manuell (temporär) machen können. --Diwas 05:05, 18. Feb. 2007 (CET)

Das Cadget "wikEd", verfügbar unter Einstellungen/Cadgets, hat eine alternative (verbesserte) Diff-Funktion, welche bei Bedarf automatisch zusätzlich zum normalen Diff der Wikipedia angezeigt werden kann. -- Sulai 02:04, 21. Dez. 2007 (CET)

Versionen vorschlagen, bewerten und verzögert aktivieren (Effizienz und Qualität der Wikipedia verbessern)

Ziele: - weniger Versionen, also übersichtlicher und weniger Speicherplatz und schnellere Recherche in Versionen - bessere Qualität der Artikel - bessere und komfortablere Zusammenarbeit

(Edit: Da es auch um das Verfahren geht und weil hier eher wenig Traffic ist, habe ich eine allgemeinere einfachere Formulierung des Vorschlags in Wikipedia:Verbesserungsvorschläge#Effizienz und Qualität der Wikipedia verbessern: neue Versionen werden nicht sofort zur aktuellen Version gestellt. --Diwas 20:31, 22. Feb. 2007 (CET)

Vorschlag: Wenn jemand einen Artikel bearbeitet, dann wird der nicht sofort als aktuell gespeichert, sondern als vorgeschlagene Version. Der Autor selbst und andere Autoren können die Version weiterbearbeiten, oder aber (bei Nichtgefallen der vorgeschlagene Version) die aktuelle Version bearbeiten. Die vorgeschlagenen Versionen erscheinen temporär gekennzeichnet in der Versionsgeschichte (wenn in benutzereinstellungen gewählt) Startet jemand eine Bearbeitung, wird ihm eine Liste der aktuellen und der vorgeschlagenen Versionen dieses Artikels angezeigt (wie Versionsgeschichte) sowie Bewerter, Bewertung, Kommentare. Die Änderung (nicht der Artikel) können von Angemeldeten und dauerhaft registrierten IP bewertet werden. Bewertungsstufen: -- falsch, ganz schlecht, Vandalismus, - aktuelle Version beibehalten weil besser, o egal, + besser als aktuelle Version, ++ unbedingt neue Version übernehmen. Kommentare können von allen abgegeben werden. Es kann maximal drei parallele temporäre Versionen/Versionsgeschichten geben.

Die Erstellung selbst ist schon eine Positive Bewertung ++, daraus folgt: ohne weitere Bewertung wird die Version nach Ablauf automatisch aktuell. Der Autor darf als angemeldeter Benutzer oder dauerhaft registrierte IP nach frühestens 20 h die Version einmalig nochmal zusätzlich bewerten. Nichtangemeldete Benutzer können ein temporäres Passwort für einen Beitrag anfordern, dann können auch sie ihren eigenen Beitrag noch einmal zusätzlich bewerten oder auch löschen. Der Autor, kann also bis zu 4 + vergeben. Es kann also einen bis zwei Benutzer erfordern um den Beitrag zu stoppen. Bewertungen können jederzeit revidiert werden. Versionen können vom Autor gelöscht werden, wenn darauf noch keine neueren Versionen aufsetzen. Da die Bewertungen im Versionvergleich erfolgen, sind sie immer relativ, so ergibt sich bei zwei gleich gut gegenüber der aktuellen Version bewerteten Versionen die Entscheidung welche als aktuell gespeichert wird.

bei Bearbeitung vom Autor einstellbare Optionen: Verzugszeit : von 30 bis 200 Stunden, je nachdem wie dringend und wie sicher die Bearbeitung und wie intensiv der Artikel gepflegt wird. In wenig beobachteten Artikeln kann die Zeit nicht kürzer als 70 Stunden sein, in stark beobachteten nicht länger als 100 stunden Verkürzung bei positiver Bewertung auf: 30 bis 100 Stunden. In wenig beobachteten Artikeln kann die Zeit nicht kürzer als 50 Stunden sein, in stark beobachteten nicht länger als 50 stunden Bei positiver Bewertung kann die Verzögerung automatisch verkürzt werden. Bei negativer Bewertung wird die Verzugszeit verlängert. Vorschlag: Der Autor kann seine Version als Vorschlag kennzeichnen. Diese Version wird niemals aktuell und erscheint nicht in der Versionsgeschichte. Andere können aber auf diese Version aufsetzen (ggf.unverändert speichern) und werden so zum Autor. (Man könnte noch überlegen, ob es Optionen bzgl. der Nennung von "Vorschlagenden" geben soll, wenn ein Vorschlag weitergeführt wird.)

Wird auf eine Vorgeschlagene Version aufgesetzt, dessen Restverzugszeit kleiner 30 Stunden ist bekommt die neue Vorgeschlagene Version 30 Stunden Verzugszeit. Läuft die Verzugszeit für eine Version ab die derzeit die beste und eine positive Bewertung hat, so wird sie damit aktuelle Version. Nach Ablauf der Verzugszeit der jüngsten Bearbeitung wird die bestbewertete vorgeschlagenen Version automatisch gespeichert.Dabei werden für Zwischenversionen nur die Unterschiede dauerhaft gespeichert, der vollständige Quelltext wird nur von der neuen aktuellen Version gespeichert. Artikelanzeigeoptionen: Angezeigt wird die aktuelle Version. Existieren vorgeschlagene Versionen so wird dies als Hinweis bei Aufruf des Artikels angezeigt.Die Änderungen oder die geplanten Versionen können alternativ aufgerufen werden. Angemeldete können auch einstellen, daß standardmäßig die geplanten Versionen angezeigt werden. Auch eine Kennzeichnung von betroffenen Textstellen im Artikel (wahlweise) ist denkbar.

Es gibt Einstellungsmöglichkeiten, z.B. für Beobachtungsliste oder global oder nach Kategorien sich alle oder alle weniger gut bewerteten vorgeschlagenen Änderungen, nach Restzeit und Bewertungen anzeigen zu lassen, um sie durch eigene Bewertung Einflußzunehmen. Admins können löschen (z.B. bei URV oder eindeutigem Vandalismus) oder eine Version stoppen. Dann wird sie nicht aktuell, aber es können weitere Bearbeitungen darauf aufsetzen. Vorgeschlagene Versionen die nicht in die aktuelle Version münden, werden Normalerweise nicht in der Versionsgeschicht angezeigt. Wird ein Beitrag nicht aktuell, so kann der Autor den Vorschlag permanent als Vorschlag speichern, mit Bewertungen und Kommentaren. Vorgeschlagene Versionen die indirekt in die aktuelle Version münden, werden in der Versionsgeschichte ähnlich den Mehrfachänderungen in der Beobachtungsliste angezeigt. Wikiblame sollte angepasst werden, so dass die Zwischenversionen erstmal übersprungen werden.

Das ganze wird entsprechend auch auf Neuanlagen von Artikeln angewandt.

Die Software sollte so geschrieben werden, dass Variable wie Bewertungsalghoritmus und anderes ggf. ohne Softwareänderung optimiert werden kann.

Bots sollten die aktuelle sowie vorgeschlagene positiv bewertete Versionen bearbeiten. Dabei wird die bestehende Bewertung übernommen. --Diwas 01:05, 19. Feb. 2007 (CET)

Hoi, das wäre viel zu viel Aufwand (sowohl für die Entwickler als auch für die Benutzer der Wikipedia). Ein ähnliches, vereinfachtes, Konzept zur Sicherung der Qualität ist allerdings mit den gesichteten (→) und geprüften Versionen (→) in Planung. Grüße, — Pill δ 11:30, 22. Feb. 2007 (CET)

Für die Benutzer ist es insgesamt nicht mehr Aufwand, weil die Versionsgeschichte sauberer wird und sich viele Anträge und reverts erübrigen. Vorschau erübrigt sich, eine fehlerhafte Version kann vom Autor sofort überschrieben werden, ohne Spuren zu hinterlassen. Es ist erstmal etwas aufwändiger, eine Bearbeitung wirksam werden zu lassen, dass verringert aber Vandalismusbehebungsaufwand. Die Gesichteten Versionen sind eine sehr schwaches Mittel.siehe:Wikipedia:Verbesserungsvorschläge#Effizienz und Qualität der Wikipedia verbessern: neue Versionen werden nicht sofort zur aktuellen Version --Diwas 20:31, 22. Feb. 2007 (CET)

Automatische Anpassung der Links beim verschieben (umbenennen) von Artikeln, Vorlagen und auch Bildern

Zur Zeit haben wir folgende Situation:

• wenn ein Artikel verschoben wird, entsteht ein Redirect unter dem alten Lemma. Es müssen manuell alle Links an das neue Lemma angepasst und dann das alte Lemma gelöscht werden.
• gleiches Problem bei den Vorlagen. Die Einbindungen "{{{...}}}" müssen manuell angepasst werden.
• Bilder kann man erst gar nicht verschieben. Ist unglücklicherweise ein unpassender Dateiname gewählt worden, lässt sich dieser nicht mehr ändern.

Mein Vorschlag wäre:

• wenn ein Artikel [[Alter Name]] nach [[Neuer Name]] verschoben (bzw. umbenannt wird) wird kein Redirect [[Alter Name]] mehr erzeugt, sondern automatisch alle Links [[Alter Name]] in [[Neuer Name|Alter Name]] geändert.
• analog bei den Vorlagen. Alle Einbindungen werden von {{Alter Name}} auf {{Neuer Name}} angepasst.
• Bilder (auch Videos, Tondateien, ...) soll man umbenennen dürfen. Automatisch werden alle Einbindungen [[Bild:Alter Name.png]] in [[Bild:Neuer Name.png]] geändert. --Florian Hurlbrink (Diskussion) 18:29, 20. Feb. 2007 (CET)

versteh ich nicht, wieso müssen alle links manuell angepasst werden? link auf redirect ist eh' kein problem, nötig wäre Dein vorschlag allenfalls beim löschen -- W!B: 19:23, 20. Feb. 2007 (CET)

Es wäre eleganter, wenn alle Links direkt auf das neue Lemma zeigen anstatt auf ein Redirect. Zur Zeit entstehen bei jeder Verschiebung massenweise Redirects. --Florian Hurlbrink (Diskussion) 18:50, 21. Feb. 2007 (CET)

Und wie soll das realisiert werden? Soll nach jeder verschiebung ein Bot über die ganze Wikipedia laufen und nach verweisen auf die alte Seite schauen? Ne so kann das net gehen. Und wenn man sozusagen ein system einführt, das nach dem kategoriesystem funktioniert, so dass jede seite und jeder verweis auf eine Seite in einen art katogorie verschoben wird und man/der Bott dann nur diese Liste durchforsten muss; das würde gehen, allerdings finde ich das sehr aufwendig. Was haltet ihr davon, wenn man einfach die paaar bytes großen redirekts bestehen lässt, womit dann ja auch die links automatisch weitergeleitet werden und bei vorlagen wird automatisch der neue inhalt eingebunden! --Marci ^Diss. 20:53, 21. Feb. 2007 (CET)

Die Liste gibt es doch: "Links auf diese seite" z.B. Spezial:Verweisliste/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests. Der Bot muß nur die Liste abarbeiten. Ich denke aber es gibt schlimmeres als Redirects. --Diwas 01:19, 22. Feb. 2007 (CET)

Ich wusste nicht, dass es eine solche Liste gibt. Naja egal. Ich glaube es ist ein Bot nicht wert, nur für die verschiebung alle Links zu ändern. Allerdings könnte man einen Bot machen, oder einem anderen noch zusätzlich diese Aufgabe zuweisen, dass dieser bei einer Löschung der Seite mit einem Redirekt die Links auf die Seite ändert.

Hallo, die automatische Änderung der auf die verschobene zeigenden Links würde mit einem Bot oder Ähnlichem natürlich hohen Traffic verursachen, da ja teilweise Seiten verschoben werden, die von sehr vielen anderen Seiten verlinkt sind. Ein Vorteil dieser Redirectlösung ist beispielsweise, dass auswärtige Links von anderen Websites immer noch funktionieren, ebenso verhält es sich mit nichtverlinkten Nennungen einer Seite. Zu der anfangs angeführten Problematik mit der Verschiebung von Bild- und anderen Dateien, siehe phab:T2709 (Bugzilla:709), ein solches Feature soll schon eingebaut werden, es ist technisch allerdings wohl aufwändig. Zum letzten Kommentar: Nun ja, wenn ein Administrator eine Redirectseite löscht, muss er eigentlich die Links auf den darauf verweisenden Seiten ändern; wenn es sich um viele handelt, kann er ja einen Botbetreiber damit beauftragen (auch noch nach der Löschung), das ist nicht sonderlich schwierig. Grüße, — Pill δ 11:25, 22. Feb. 2007 (CET)

das zu automatisieren ist unmöglich. Woher soll ein BOT wissen welche Links er umbiegen darf und welche nicht. Oft werden Artikel verschoben um Platz für eine BKL zu machen. Da muss man dann sowieso von Hand jeden einzelnen richtig verbiegen. --Steffen2 11:48, 25. Feb. 2007 (CET)

Also woher der Bot das wissen soll ist ganz einfach. er "schaut" in der passenden liste zu dem verschobenen Artikel nach den Seiten, auf denen ein Link ist ( Spezial:Verweisliste/Seite ). Danch durchsucht er diese Seiten nach der Adresse des verschobenen artikels und ersetz dieses duch den neuen link. allerding finde ich, dass das einen Zu hohen Traffic verursacht und nur bei Seiten mit einen entstandenen Redirect gemacht werden soll, der überhaupt nicht passt. Ansonsten finde ich es gar kein Problem den Redirekt da stehen zu lassen. Und bei Bilder u.Ä. steht oben schon eine Antowrt. --Marci ^Diss. 14:16, 26. Feb. 2007 (CET)

und genau das ist falsch, da die Links oft auf den falschen Artikel zeigen (bei der BKL-Artikeln). Beispiel: [1] Da muss man regelmäßig von Hand aufräumen, das kann NIE ein Bot erledigen. --Steffen2 21:42, 26. Feb. 2007 (CET)

und wenn der Bot da nichts findet wird er auch nichts ersetzen! So einfach ist das. Das wird der hächstens in die Log reinschreiben, dass man weiß, dass da was net klappt. Du unterschätzt Bots! Mann kann denen einfach sagen dass der den Links folgen soll, z.b. über quelltextabschnitte oder frames oder so und dann dort eine vestimmte zeichenfolge suchen und diese ersetzen soll. das klappt 95%. ein bug kann immer einmal drin sein! --Marci ^Diss. 21:16, 27. Feb. 2007 (CET)

Hmm, hier kollidieren immer wieder Ansichten über die Benutzung von Redirects. Ich habe bspw. einmal recht viele Redirects von Lemmata, die ein ß enthalten zu Lemmata, die an der selben Stelle ein ss enthalten, angelegt. Gleich am nächsten Tag kam ein Pulk, das alle neuen Redirects, von denen einige wieder auf Redirects zeigten, umgebogen um direkt auf den finalen Artikel zu zeigen. Ich beobachte tatsächlich immer wieder, wie doppelte Redirects direkt gemacht und harmlose Redirects gelöscht werden, als würden sie schaden. Das Urproblem liegt hier, denke ich, darin, dass doppelten Redirects nicht sofort gefolgt wird. Ich weiß, dass es dafür gute Gründe gibt, aber ich denke, man sollte es anders lösen, nämlich, indem nach mehreren Redirects der Weg der Redirects links oben untereinander angezeigt wird. igel+- 14:45, 1. Apr. 2007 (CEST)

Link zur Bearbeitung eines Abschnitts

Moin ! Die kleinen [Bearbeiten]-Links zur Abschnittsbearbeitung landen beim IE7 (ob's bei Vorgängerversionen genauso ist, weiß ich nicht) immer am rechten Seitenrand und etwas unterhalb des Abschnittstitels - und damit oft genau in der ersten Zeile des folgenden Textabschnitts, wenn die sich über die gesamte Breite erstreckt. Das sieht irgendwie nicht so toll aus. Beim Firefox landet der Link dagegen direkt neben dem Abschnittstitel !? Ok, klarer Fall von unterschiedlicher CSS-Interpretation der Browser, aber ein bißchen einheitlicher müßte man es schon hinbekommen können, oder ? -- 62.180.198.58 20:04, 22. Feb. 2007 (CET)

Bei Einstellungen kann man einstellen, wo der Link angezeigt werden soll. Probier mal, ob es dann klappt. (nicht signierter Beitrag von MarciS (Diskussion | Beiträge) )

Hoi, der Benutzer ist nicht angemeldet und hat somit auch keine persönlichen Einstellungen zur Verfügung. Außerdem kann die Position der Links ohnehin nicht in den Einstellungen geändert werden, sondern nur im Monobook (→), das wiederum ausschließlich angemeldeten Benutzern zur Verfügung steht. Ich habe bzgl. des Problemes einen anderen Benutzer von IE7 gefragt, der sagte, die Links seien zwar unter der Überschrift, es gebe aber keine Überschneidungen. Eventuell kannst du ja einen Screenshot machen. Grüße, — Pill δ 13:11, 24. Feb. 2007 (CET)

Des mit dem net angemeldetem Benutzer hab ich übersehen. Aber ich hab vor nem Monat oder 2 meine einstllungen geändert und danch hats des rechts angezeigt. vlt ham die des einfach rausgenommen.

Moin. Textüberlappung liegt nicht vor, der zwangsweise Umbruch sieht allerdings doof genug aus. Wie ich bei weiteren Recherchen in den Tiefen der Wikipedia gelernt habe, ist das Skript MediaWiki:Monobook.js, das offenbar standardmäßig bei allen nicht angemeldeten Benutzern in Aktion tritt, für die Umpositionierung der Links zuständig. Normalerweise müßten diese bei nichtregistrierten Benutzern direkt neben der Überschrift landen (was bei Firefox offensichlich auch funktioniert), könnte also ein IE7-spezifisches Problem sein. Hab' mich mal auf der Diskussionseite des Benutzers verewigt, der wohl diesen Teil des Skripts geschrieben hat, bis jetzt gab's allerdings noch keine Reaktion. Im Prinzip ist die Angelegenheit damit hier wohl auch fehl am Platz, bitte dies zu entschuldigen. ;-) 62.180.198.21 10:19, 25. Feb. 2007 (CET)

Versionsvergleich manuell anpassen

Möglichkeit schaffen bei dem Versionsvergleich, die Absätze mit Mausklicks neu zuzuordnen. Hintergrund: Teilweise werden nichtpassende Absätze miteinander verglichen und der passende Absatz erscheint dann darunter. Wenn z.B. ein Absatz eingefügt wurde. Noch besser: wenn auch bestimmte Textpassagen markiert und verglichen werden können. Zusätzlich sollte die Möglichkeit eingebaut werden, alles was nicht rot ist unsichtbar zu machen. --Diwas 07:25, 25. Feb. 2007 (CET)

Doppelter Eintrag: Verbesserungsvorschläge/Feature-Requests#Versionsvergleich manuell anpassen#Versionsvergleich genauer dargestellt -- Sulai 02:10, 21. Dez. 2007 (CET)

Einfache Tabellenkalkulation

Hallo,

die Software TWiki unterstützt einfache Tabellenkalkulation. D.h. beim Bearbeiten einer Seite wird ein Tabellenblatt angezeigt, welches wie in Tabellenkalkulationsprogrammen gewohnt bearbeitet werden kann. Die Bearbeitung einer solchen Tabelle ist somit wesentlich einfacher als mit prettytable - wo zumindest Anfänger große Probleme haben, die Syntax zu verstehen und richtig anzuwenden. Daher wäre ich für eine entsprechende Ergänzung der Mediawiki-Software. --BabyNeumann 21:39, 25. Mär. 2007 (CEST)

Es gibt eine MediaWiki-Extension, die derzeit noch in der Entwicklungsphase ist, die das Erstellen von Tabellen ebenfalls erleichtern soll, siehe dafür diese Infoseite. Wann das ganze fertig ist und ob es auch auf Wikimedia-Wikis implementiert werden wird, steht natürlich in den Sternen. — Pill δ 22:37, 26. Mär. 2007 (CEST)

Und wie kommt es jetzt laut Text oben auf dieser Seite zu einer Durchsetzung meines Requests und Weiterleitung an die Entwickler? (wobei ich "Durchsetzung" jetzt eher mal als "findet zahlreiche Unterstützer bzw. Personen die die Ergänzung ebenfalls sinnvoll fänden" interpretiere) --BabyNeumann 01:01, 27. Mär. 2007 (CEST)

Lemma-Äquivalenzklassen um das Durchkoppeln zu erleichtern

Grüß Gott, ich möchte bescheiden fragen, ob man serverseitig Klassen von Lemmata äquivalent behandeln könnte. Das Szenario ist dies: ich finde in einem Artikel eine fehlende Durchkopplung, sagen wir Art Déco-Stil. Nun möchte ich den fehlenden Bindestrich einfügen: Art-Déco-Stil. Es wäre nun unglaublich praktisch, wenn die Software das nun äquivalent behandeln könnte, sodass sie automatisch errät, dass hier ein Redirect auf Art Déco gemeint ist. Ich stelle mir das ungefähr so vor: Es wird zwar im Artikel gespeichert, wie das Lemma nun richtig geschrieben wird: mit oder ohne Bindestrich, aber es kann keine zwei Artikel geben, die sich nur durch einen Bindestrich, wo der andere Artikel ein Leerzeichen hat, unterscheiden. Falls man nun eine der äquivalenten Schreibweisen eingibt kommt man immer zum selben Artikel. So werden Lemmata richtig angezeigt und das Durchkoppeln ist leicht. igel+- 14:30, 1. Apr. 2007 (CEST)

Überflüssig. Wenn das Lemma ohne Bindestrich falsch ist, dann ist auf das Lemma mit Bindestrich zu verschieben. Und ansonsten kann man, wie sonst auch, einfach [[Art Déco|Art-Déco]] schreiben. Keep it simple!--Berlin-Jurist 21:15, 1. Apr. 2007 (CEST)

Huch! Meine Lösung ist doch einfacher als die |-Syntax, das ist ja gerade der Trick! igel+- 21:51, 1. Apr. 2007 (CEST)

Redirects sind nicht dazu da, es beim Verlinken einfacher zu machen. Das würde sich ja nicht nur auf die Durchkopplung beschränken, bald gäbe es dann Redirects für alle möglichen und unmöglichen grammatischen Formen. Aus „Faulheit“ beim tippen werden keine Redirects angelegt und erst recht nicht die Software geändert. -- Timo Müller Diskussion 11:37, 2. Apr. 2007 (CEST)

Ich bin sprachlos. Software ist gerade dazu da, das Tippen zu erleichtern. DU kannst ja wegen mir deine Texte hexadezimal tippen ... igel+- 11:43, 2. Apr. 2007 (CEST)

Tabellenformatierung mit pre kollidiert mit Stylesheet

Hallo! Html kennt eine echt clevere Möglichkeit, Spalten rechtsbündig an einem Zeichen auszurichten, sagen wir, einem Komma, siehe w3c], da kann man aus einer kombination von colgroup, col und align="char" Tabellen richtig formatieren.

Kein einziger Browser unterstützt align="," und Wikimedia erlaubt colgroup und col nicht. Letzteres sollte man vermutlich ändern, aber ohne align="," ist es nicht übermäßig nützlich, es ist also nicht besonders wichtig.

Die einzig funktionierende Alternative führt über Schriftarten fester Breite; ich habe Hilfe:Tabellen geändert um das zu erklärenden. Am besten und schönsten geht es mit dem pre-Tag. Leider wird das pre-Tag in Wikipedia selbst dann mit einem Rahmen dargestellt, wenn es nicht durch eine Zeile entstanden ist, die mit einem Leerzeichen beginnt. Genau das sollte man ändern, Zeilen dieser Art: Huhu! sollten mit einer CSS-Klasse versehen werden und das CSS-Stylesheet sollte nicht allen Pre-Tags einen Rahmen gönnen, sondern nur solchen, die in dieser Klasse liegen. igel+- 12:00, 3. Apr. 2007 (CEST)

Deutlichere Unterscheidung der Abschnittsüberschriften

Irgendwie hat es sich ergeben, dass niemand Überschriften der ersten Kategorie benutzt („=“). Dabei kann man diese noch einigermaßen gut von denen der zweiten Kategorie („==“) unterscheiden, obwohl beide eine <hr /> nach sich ziehen, immerhin ist der Schirftgrößenunterschied noch erkennbar.

Schon auf den ersten Blick lassen sich Überschriften der zweiten Kategorie von denen der dritten („===“) unterscheiden, da neben einer kleineren Schrfitgröße auch der horizontale Strich wegfällt, wahrscheinlich der Hauptgrund dafür, dass diese beiden Kategorien die am häufigsten verwendeten sind.

Manchmal ist es allerdings unerlässlich, noch einen weitere Unterteilung zu verwenden, hierbei stellt sich unwillkürlich das Problem, dass zwischen den Überschriften der dritten und vierten („====“) Kategorie nur schwerlich ein Unterschied auszumachen ist. Gleiches gilt für den Unterschied zwischen vierter und fünfter („=====“) Kategorie.

Ich bitte daher darum, die Gestaltung der verschiedenen Abschnittsüberschriften derart zu ändern, dass man auch ohne genaues Hinsehen die Verschachtelungstiefe erkennen kann. Zum Beispiel:

• Überschrift 3
• Überschrift 4
• Überschrift 5

Oder so etwas in der Art. Gruß Axpde 20:01, 6. Apr. 2007 (CEST)

Hallo, dass niemand Überschriften der ersten Kategorie (h1) benutzt, liegt daran, dass der Titel einer Seite eine h1-Überschrift ist, daher sollte man das aus Gliederungsgründen nur sparsam verwenden. Du kannst dir persönlich die Sache aber auch per Spezial:Mypage/Monobook.css einstellen.

h1 {

       font-size:160%;
       font-weight:bold;

} h2 {

       font-size:140%;
       font-weight:bold;
       font-weight:underlined;

}

etc. (h = heading, ===...=== wäre also h3). — Pill (Diskussion · Bewertung) 20:42, 7. Apr. 2007 (CEST)

Oder du aktivierst in deinen Einstellungen ganz einfach die Nummerierung/Gliederung der Überschriften, dann siehts so aus:
1. Überschrift 1
1.1. Überschrift 2
1.1.1. Überschrift 3
1.2. Überschrift 2
etc. --Der Umschattige talk to me 22:14, 18. Apr. 2007 (CEST)

Hyperlinks zu Bitte-jetzt-einen-Artikel-starten-Dingens

OK, und jetzt noch was Wichtiges(?): Klickt man in einem Artikel auf einen Link, erwartet man da etwas Bestimmtes? Und wenn Ja, was? Vielleicht einen Sprung zu einem anderen Artikel? Seblstverständlich? Also sollten, um diese Erwartung nicht zu enttäuschen, die Links zu den Bitte-jetzt-einen-Artikel-starten-Dingens nicht irgendwie anders aussehen? Nur so ne Frage. Guten Abend. -- Nullbarriere 00:51, 13. Apr. 2007 (CEST) (nullbarriere, heute in Fragestimmung)

Hmm, das tun sie … Hast du vielleicht eine besonders exotische Form von Browser? --Quilbert 問 01:36, 13. Apr. 2007 (CEST)

Links auf nicht existierende Artikel werden für gewöhnlich rot dargestellt. So sollte auch der folgende Link aussehen: aösldkfj --CyRoXX ^(? ±) 01:43, 13. Apr. 2007 (CEST)

<nobr> Tag

Ich würde mich freuen wenn man den <nobr> Tag bei Wikipedia benutzen könnte. --DaSch 15:31, 15. Apr. 2007 (CEST)

hm.. iirc existiert der in XHTML nicht mehr. hast du mal ein beispiel, wo man ihn bräuchte? -- ∂ 16:34, 15. Apr. 2007 (CEST)

Also zum Beispiel wenn man Tabellen hat dann werden zum Beispiel bei kleinen Auflösungen machen Elemente über mehrere Zeilen Verteil was diese unlesebar macht. --DaSch 17:03, 15. Apr. 2007 (CEST)

da hätte ich jetzt einfach | style="white-space:nowrap" | zelleninhalt versucht. aber lieber umbrochener text als eine tabelle, die mich aufgrund ihrer breite zum scrollen zwingt. -- ∂ 17:35, 15. Apr. 2007 (CEST)

Ja aber nur mal als Beispiel, stell dir vor du hast in einer Tabelle sowas

Das
ist
eine
Geschichte
von
einem
Text
der
in
einer
zu
kleinen
Tabelle
drin ist

Also ich finde soetwas ziemlich blöde zu lesen --DaSch 17:43, 15. Apr. 2007 (CEST)

Autosave, Abschnitt-Versionen, Abschnitt-Beobachtung

1. Ich vermisse eine Autosave-Funktion, die mein Geschriebenes temporär sichert (So wie das zum Beispiel Googlemail mit AJAX macht), so dass ich nicht immer mit Notepad hin und herkopieren muss. Zur Not würde auch ein Draft-Speichern Button reichen. Ansonsten bin ich leicht dazu verführt die Seite öfters mal bei Wikipedia zu speichern (und somit während des Editierens mehrere Einträge in das Änderungsprotokoll von Wikipedia zu machen)

2. Toll wäre es, wenn man die Versionen/Autoren von Überschrifts-Abschnitten anzeigen lassen könnte, anstelle nur die des gesammten Artikels. Im Moment ist es je nach Artikelgröße sehr aufwändig die Änderungen an einem Abschnitt herauszufinden. Als Implementierung könnte ich mir dazu neben dem Bearbeiten Link noch ein weiterer Versionen Link vorstellen

3. Beobachtungsliste auf Abschnittsbasis: Ich vermisse die Möglichkeit ganz gezielt einen Abschnitt zu beobachten. Manche Artikel haben ein Seitenlanges Inhaltsverzeichnis und entsprechend lang ist der gesammte Text. Da gibt es natürlich dauernd Änderungen die in der Beobachtungsliste angezeigt werden. Besser wäre es, wenn man da gezielt einen Abschnitt beobachten könnte.

--Tigerix 15:42, 18. Apr. 2007 (CEST)

1.

• dafür: Diwas

2.

• dafür: Quilbert 問
• dafür: Diwas

3.

• dafür: Quilbert 問
• dafür: Diwas

Neue Spezialseite: Text auf „Urversion“ verlinkt

(hierher verschoben)

Gelegentlich ist es ja sinnvoll, herauszufinden, von welchem Benutzer ein Text innerhalb eines Artikels stammt. Diese Recherche ist derzeit ziemlich aufwändig. Mein Vorschlag: Könnte man nicht zu jedem Artikel eine Spezialseite generieren, auf der der gesamte Text jeweils auf diejenige Version des Artikels verlinkt ist, in der er zuerst aufgetaucht ist? Dann könnte man direkt durch Klick auf die fragliche Passage sowohl die ursprüngliche Änderung (mitsamt der Intention) erkennen als auch den Benutzer, wodurch man dann durch einen zweiten (bzw. dritten) Klick direkt auf dessen Diskussionsseite kommen könnte. Das würde meiner Ansicht nach die Arbeit in der Wikipedia erleichtern und auch die Effektivität steigern. --Quilbert 問 16:25, 21. Apr. 2007 (CEST)

Siehe Benutzer:Flominator/WikiBlame. — Pill (Diskussion · Bewertung) 21:31, 6. Mai 2007 (CEST)

Deutlicher auf die Vorschau-Funktion hinweisen

Seht euch mal bitte diese Versionsgeschichte vom 10. Mai 2007 an. Sie war für mich der Auslöser dieses Feature-Requests aber nicht der einzige Grund/Fall. Könnte man den Bearbeitenden nicht mit einem dicken Hinweis auf die Vorschau-Funktion nerven, wenn er die selbe Seite innerhalb einer gewissen Zeitspanne zum wiederholten Mal editieren möchte? --Pohli 00:48, 11. Mai 2007 (CEST)

Dafür:

1. Diwas 00:06, 12. Mai 2007 (CEST)
2. Tigerix 14:09, 12. Mai 2007 (CEST)
3. --JARU 19:34, 20. Aug. 2007 (CEST)

Neutral:

1. Ich finde das Prinzip in der frz. Wikipedia eigentlich besser, da es meist eh nicht um alteingesessene Wikipedianer geht: IPs *koennen* dort gar nicht sofort speichern, die Funktion wird erst aktiviert, wenn einmal "Vorschau" oder "Aenderungen zeigen" angeklickt wurde. Ob beides (Speicher-Sperrung und Nerv-Nachtricht) noetig sind, weiss ich nicht; schlecht faende ich es nicht, aber die Prioritaet wuerde ich dann als niedrig ansetzen. Ibn Battuta 18:29, 27. Mai 2007 (CEST)
2. Die Variante der französischen Wikipedia würde ich bevorzugen, dass nämlich der Button zum Speichern so lange blass (gesperrt) bleibt bis die Vorschaufunktion gedrückt wurde. Diese Idee finde ich gut, in diesem Sinne ein "Dafür". (Allerdings habe ich auch den Einwand gelesen, dass sich "die Poweruser das rauskommentieren werden weil es auch lästig sein kann, da man ja doch in den allermeisten Fällen sich seiner Sache sicher ist"). --Brunosimonsara 11:54, 1. Jul. 2007 (CEST)

Dagegen

1. ∂ 20:12, 23. Jul. 2007 (CEST) womit wollen wir den nutzer denn noch alles "deutlicher" nerven? es gibt doch wirklich schlimmeres. wenn überhaupt will ich die möglichkeit, mehrere aufeinanderfolgende edits in der history zusammengefaßt zu sehen zu bekommen. vielleicht bastel ich mir mal ein kleines scriptchen dafür. -- ∂ 20:12, 23. Jul. 2007 (CEST)

Kommentare:

Es sollten sogar nur max. 5 Edits/Stunde an einem Kapitel möglich sein. Jedoch sollte es Möglichkeiten geben einen Edit zu speichern, ohne dass er sofort aktuelle Version wird mit der Möglichkeit die Zusammenfassung zu editieren. Diwas 00:06, 12. Mai 2007 (CEST)

Das obligatorische Ausblenden des Speichern-Knopfes bis man nicht mindestens einmal auf „Vorschau zeigen“ drückt, find ich die beste Lösung. Ich ertappe mich vielzu oft selbst dabei. --Orangerider 16:48, 1. Jul. 2007 (CEST)

 Pro Geht mir genauso. Nicht-Registrierte (also IP's) müssen es ohnehin!
Wäre generell interesseant für ALLE Bearbeitungen. Also immer wenn sich inhaltlich was ändert zur letzten gespeicherten Version, müsste der Speichern Knopf deaktiviert sein und nur "Vorschau zeigen" als Knopf auslösbar sein. Erst danach wird "Seite speichern" reaktiviert.
Technisch umsetzbar? --JARU 19:32, 20. Aug. 2007 (CEST)

Spezial:Gewünschte Kategorien für Bilder?

Wäre sicherlcih vorteilhaft, damit man das mal per bot abarbeiten klönnte. // Forrester 22:07, 13. Mai 2007 (CEST)

Volltextsuche und Pinyin mit Tonzeichen

Könnte man die Volltextsuche so abändern, dass Eingabe eines Wortes in Pinyin ohne Tonzeichen auch die Vorkommen mit Tonzeichen gefunden werden? Beispiel: „wuji“ sollte auch „Wújí“ finden. Begründung: In gedruckten Büchern wird häufig (immer?) die einfache Schreibweise verwendet. Wenn ich mir als Laie einen Begriff (ohne eigenen Artikel) mit Hilfe der Wikipedia weiter erschließen will, finde ich nur einen Teil der relevanten Vorkommen - je nach dem, welche Schreibweise die Wikipedia-Autoren verwenden. Auch kann ich i.d.R. mangels Kentnis nicht gezielt nach der Schreibweise mit Tonzeichen suchen. Letztlich würde der Vorschlag wohl auf grundsätzliches Ignorieren von Markierungen über Buchstaben hinauslaufen - keine Ahnung ob das praktikabel wäre? Gäbe es unerwünschte Seiteneffekte? --Longthinker 13:08, 20. Mai 2007 (CEST)

Das klingt fuer mich fast identisch mit diesem Bug - der ist eine entsprechende Anfrage fuer Umlaute. Ich finde aber eh, man sollte das gleiche Prinzip fuer alle Sonderzeichen (auch Akzent usw. - also pinyin) anwenden (und habe das dort auch schon vorgeschlagen).

Sprich: Wer das Problem ebenfalls behoben sehen moechte, sollte einfach diesen Verweis anklicken und dort auf der Seite (unten rechts) fuer die Problembehebung abstimmen. Ein Kommentar, dass es nicht nur um Umlaute gehen sollte, waere natuerlich auch zu empfehlen. (Auf englisch koennte man z.B. "Please include not only Umlauts, but also other special characters, e.g., letters with accents.") Fuer Rueckfragen, wie das mit dem Abstimmen geht (sehr einfach!), koennt Ihr Euch natuerlich auch gern auf meiner Diskussionsseite melden. --Ibn Battuta 18:40, 27. Mai 2007 (CEST)

Suchen in mehreren Sprachen

Wenn meine Suche nach einem Begriff in der deutschen Wikipedia erfolglos ist, möchte ich meistens ergänzend die englische durchsuchen. Dazu muss ich aber zuerst auf den Link für eben jene in meiner Lesezeichenleiste klicken, den Suchbegriff erneut eingeben und nochmal suchen. Viel viel toller wäre es für faule Säcke wie mich, wenn es auf der Suchergebnis-Seite (also dieser hier) einen oder mehrere Links gäbe ala "Suche nach <Begriff> in der englischen/französischen/hawaiianischen Wikipedia". Zudem würde mir das ein Wikipedia-Lesezeichen ersparen. :) Sollte doch eigentlich nicht allzu schwer zu implementieren sein. --Trollomat 18:12, 21. Mai 2007 (CEST)

Pro! Dies ist ein unglaublich wichtiges Feature in der Wikipedia-Nutzung. Ich nutze ständig das hervorragend umgesetzte Wechseln zwischen gleichen Artikeln in unterschiedlichen Sprachen. Es wundert mich sehr, dass ein Sprachwechsel in der Suche nicht schon lange umgesetzt ist! Gruß, UMa.--84.155.126.86 14:31, 2. Jun. 2007 (CEST) --

Ich weiss nicht, ob es technisch möglich ist interwikis auf Spezialseiten zu bringen. Ein Link auf http://vs.aka-online.de/globalwpsearch/ im Hinweistext, wenn nichts gefunden wurde, könnte evtl. Sinn machen. (Ist allerdings nicht das schnellste Tool). --JuTa(♂) Talk 15:15, 2. Jun. 2007 (CEST) --

Pro! @Trollomat: Hab ich auch schon 100000x gedacht. Nervt sehr, dieses "nicht gefunden > Begriff kopieren > Hauptseite > Englisch > Begriff einfügen" Sollte echt nicht allzu schwer sein, das zu ändern.

Inhaltverzeichnis beim Ausdruck ausblenden

Bei aktivierten JavaScript besteht die Möglichkeit das Inhaltsverzeichnis auf- und zuzuklappen. Im eingeklappten Zustand besteht das Inhaltsverzeichnis noch aus der Überschrift und dem Button zum Ausklappen. Bei Drucken wird das Inhaltsverzeichnis in dem aktuellen Zustand ausgedruckt. Sinnvollerweise werden die Buttons zum Klappen oder Bearbeiten nicht mit ausgedruckt. Beim Drucken eines Artikels mit eingeklapptem Inhaltsverzeichnis wird aber eine graue Box mit dem Text Inhaltsverzeichnis ausgedruckt.

Schöner wäre es, wenn die Inhaltsverzeichnisbox im eingeklappten Zustand auf dem Ausdruck überhaupt nicht angezeigt wird. Auf dem Bildschirm ist sie wegen dem Button zum ausklappen weiterhin notwendig.

Um dies Feature zu erreichen habe ich die Funktion toggleToc() zum Aus- und Einklappen aus http://de.wikipedia.org/skins-1.5/common/wikibits.js um die beiden fett geschriebenen Zeilen erweitert:

function toggleToc() { var toc = document.getElementById('toc').getElementsByTagName('ul')[0]; var toggleLink = document.getElementById('togglelink');

if (toc && toggleLink && toc.style.display == 'none') { changeText(toggleLink, tocHideText); toc.style.display = 'block'; document.getElementById('toc').className = 'toc'; document.cookie = "hidetoc=0"; } else { changeText(toggleLink, tocShowText); toc.style.display = 'none'; document.getElementById('toc').className = 'toc noprint'; document.cookie = "hidetoc=1"; } }

Ich habe dieses Feature in meine JavaScript-Datei aufgenommen und unter Internet Explorer, Mozilla Firefox, Opera getestet.

Wer Interesse hat kann dieses Feature übernehmen und testen. Wenn alles getestet ist könnte es vielleicht mal in MediaWiki aufgenommen werden. --Fomafix 16:20, 24. Mai 2007 (CEST)

artikelzähler in kategorien

der bei kategorien mit 'es werden n artikel aus dieser kategorie angezeigt.' ersichtliche zähler sollte auch für info-boxen nutzbar gemacht werden. ähnlich wie die sechs systemvariablen für zähler('NUMBEROFARTICLES' usw.). derzeit kommt der normaluser an diesen wert aber nicht heran.--ulli purwin 15:54, 31. Mai 2007 (CEST)

Bitte phab:T8943 (Bugzilla:6943) und ergänzend phab:T5834 (Bugzilla:3834) beobachten. --:Bdk: 12:33, 22. Jul. 2007 (CEST)

Zusätzlicher Löschknopp für Admins wünschenswert

Schade, dass zu den Knöppen keiner gehört, mit der wir einzelne Versionen direkt in der Artikelhistory vollständig löschen können. Das erleichterte die Bereinigung ungemein. Falls das schon x-mal erklärt und abgelehnt wurde, entschuldige ich mich: war zu faul zum Suchen. --Wwwurm Mien Klönschnack^TM 17:02, 3. Jun. 2007 (CEST)

Du meinst Oversight. --Versusray | Diskutiere mich! 19:32, 21. Jul. 2007 (CEST)

Nein, das ist damit nicht gemeint. Was gemeint ist, wenn auf der Versionshistorie neben jeder Version ein Knopf ist, wo man nur diese eine Version regulär löschen kann, z.B. bei URVs oder Edits, die Straftatbestände etc. erfüllen. Bisher muss man für sowas immer die komplette Seite löschen und dann nur bestimmte Versionen wiederhestellen kann, was einerseits zu einem technischen Problem, andererseits einem versehentlichen Wiederherstellen bereits zuvor gelöschter einzelner Versionen führen kann. --STBR – !? 19:35, 21. Jul. 2007 (CEST)

Wo ist da der Unterschied? Dass bei Oversight die entsprechende Version vollkommen futsch ist? Da wird ja auch eine Artikelversion gelöscht. --Versusray | Diskutiere mich! 19:45, 21. Jul. 2007 (CEST)

... die auch von Admins nicht wiederhergestellt werden kann, was bei Irrtümern ja blöd wäre. Nein, es geht WWW doch offenkundig einfach um den blöden Aufwand, evtl. 200 Versionen löschen und dann 199 wiederherstellen zu müssen. Das Häkchensetzen ist in der Tat lästig. --Xocolatl 19:50, 21. Jul. 2007 (CEST)

Ah, verstehe. Verzeiht meine Unwissenheit, ich bin nun mal kein Admin und habe nur wenig Ahnung von Löschknöpfchen. --Versusray | Diskutiere mich! 20:00, 21. Jul. 2007 (CEST)

Dann sollte man vieleicht besser schweigen? ;) Marcus Cyron in memoriam Otto Häuser 17:56, 22. Jul. 2007 (CEST)

Hatte vorher die Versionslöschung immer mit Oversight verwechselt, weil von der ähnlich gesprochen wurde. Drum meinte ich, wenns das Feature schon gibt und jemand danach fragt, dann muss dasjenige das schon existiert Oversight sein. Bitte nicht auf meine wirre Argumentation eingehen, aber ich weiß es momentan nicht anders auszudrücken... --Versusray | Diskutiere mich! 12:44, 23. Jul. 2007 (CEST)

Bitte phab:T5576 (Bugzilla:3576) im Auge behalten. --:Bdk: 12:24, 22. Jul. 2007 (CEST)

Danke für den Hinweis, aber zumindest ich verstehe auf solchen Seiten leider nur Bahnhof. Und dabei wollte ich doch (für alle Admins) nur ein Knöpsken mehr... ;-) --Wwwurm Mien Klönschnack^TM 18:19, 22. Jul. 2007 (CEST)

sieht so aus, als handle sich da um genau das feature, das du haben möchtest. -- ∂ 00:27, 23. Jul. 2007 (CEST)

Schön - aber wie bekomme ich das, und am besten auch gleich funktionstüchtig? Dass ausgerechnet ich euch Wissenden hier die Würmer millimeterweise aus der Nase ziehen muss,... ;-) --Wwwurm Mien Klönschnack^TM 02:50, 23. Jul. 2007 (CEST)

Bekommen? – Leider noch nicht. – Wann? – Ein Umsetzungszeitpunkt ist noch nicht benannt, es soll aber in MediaWiki implementiert werden. Ansonsten siehe Hinweise im Kopf dieser Seite, insbesondere Hilfe:MediaZilla, wo's auch einen Abschnitt zum einfachen „Abstimmen“ für einen Bug gibt :-) --:Bdk: 13:38, 23. Jul. 2007 (CEST)

Sobald der Status auf FIXED steht, dauert es in der Regel nur noch Tage. Im Moment heißt es aber leider noch etwas warten, bis die Software dazu fehlerfrei ist. --Raymond ^{Disk. Bew.}

Kurz gesagt: das wird, wenn überhaupt, „betreiberseits implementiert“ und ich muss einfach nur zuwarten? Schön. Entschuldigt meine Stutzigkeit, aber ich bin wirklich eine Programmiernull und werd's wohl auch bleiben. Danke und Gruß von --Wwwurm Mien Klönschnack^TM 13:44, 23. Jul. 2007 (CEST)

Reduzierung des Datenverkehrs durch Optimierung der Sonderzeichenleiste

Hallo, vor vielen Monaten wurde die Sonderzeichenleiste (div#specialchars), die im Bearbeiten-Modus angezeigt wird, in der jetzigen Form eingeführt. Schon damals war mir aufgefallen, wie viel zusätzlicher Datenverkehr bei jeder Übertragung durch die Auslieferung der vollständigen Leiste erzeugt wird, und es wundert mich, dass das noch nicht aufgefallen ist und geändert wurde. Der weitgehend monoton aufgebaute Code der Leiste beansprucht einen Speicherplatz von etwa 100 kB und damit bei kleinen zu bearbeitenden Seiten den überwiegenden Teil des übertragenen HTML-Codes. Zum Vergleich: Der HTML-Code einer minimalen Seite im Anzeige-Modus ist etwa 12 kB groß. Die Leiste kann nur mit eingeschaltenem JavaScript bedient werden, also könnte man sie auch nach dem Laden im Browser durch JavaScript generieren lassen, sodass dann nur das um schätzungsweise 90 % kleinere Generatorskript ausgeliefert werden müsste. --Wiegels „…“ 04:15, 7. Jun. 2007 (CEST)

Hey, super Sache; ich würde dir empfehlen, damit direkt zu MediaZilla zu gehen. Grüße --Quilbert 問 01:05, 8. Jun. 2007 (CEST)

ausserdem, wenn man die Extra-Editbuttons installiert hat, braucht man einen gutteil der Leiste garnicht (etwa Wikisyntax, die man mit BLueFiSH.as's Optionen für das Sonderzeichenmenü einzeln ausblenden kann) - wenn man da also noch mehr einstellen könnte, wärs sowieso gut -- W!B: 06:32, 8. Jun. 2007 (CEST)

das aktuelle system ist für die tonne. ich nehme stark an, daß es dafür im mediazilla schon was gibt. -- ∂ 20:14, 23. Jul. 2007 (CEST)

Ich muss meinen Vorschlag mal relativieren. Was ich übersehen hatte, war, dass der HTML-Code für die Übertragung komprimiert wird. Aus 109 KB HTML-Code und 6 KB erzeugendem JavaScript-Code würden nach der Komprimierung (6 KB bzw. 2 KB) und sich die Ersparnis von über 100 KB pro Übertragung auf vermutlich weniger als 4 KB reduzieren. --Wiegels „…“ 23:48, 23. Jul. 2007 (CEST)

Suchmaske verbessern

Aloa, ich liebe Wikipedia nur eine Sache stört mich immer wieder...

Also nach einer Erfolglosen suche kommt man ja immer auf die selbe Seite, das ist auch okay soweit nur finde ich das man auf der Seite die Möglichkeit haben sollte die Sprache zu wechseln bzw in anderssprachigen Wikipedias zu suchen.

Das würd die suche ungemein erleichtern da man nicht immer erst ins z.b. Englische (welches ja teilweise wesentlich ausführlicher ist wie das Deutsche) Wikipedia gehen müsste und da erneut suchen, sondern einfach mit einem Klick.

Wär echt klasse wenn ein solches Feature noch von jmd der es kann eingefügt werden könnte, danke!

MFG MagicF

Ich hab das etwas weiter oben auch schon vorgeschlagen, aber unterschreib hier auch gerne nochmal. Unbedingt dafür. --Trollomat 19:15, 7. Aug. 2007 (CEST)

Kategorien

Es wäre schön, wenn man als angemeldeter Benutzer selber einstellen könnte, wie viele Artikel man in den Kategorien angezeigt bekommen möchte, die Vorgabe von 200 finde ich recht nervig. Die ist nichts halbes und nichts ganzes. Zudem wäre es schön, wenn angezeigt werden würde, wie viele Artikel sich insgesamt in einer Kategorie befinden. Dann erspart man sich das ewige durchklicken in größeren Kats. Marcus Cyron in memoriam Otto Häuser 17:52, 16. Jul. 2007 (CEST)

Den Vorschlägen/Wünschen stimme ich voll zu.

Darüber hinaus stört mich die Auswirkung der folgenden Regel: Wird ein Artikel in eine Kategorie eingeordnet, bitte nicht gleichzeitig in eine ihrer Überkategorien einordnen! Diese eigentlich sinnvolle und logische Regel ist für Nutzer lästig, die in einer Hauptkategorie eine alphabetische Gesamtauflistung aller Einträge brauchen bzw. sehen möchten, weil sie nicht in allen Unter- und weiteren Subkategorien zusätzlich suchen mögen! Ich schlage deshalb vor, zur Schaffung einer besseren Gesamtübersicht zusätzlich (oder für den angemeldeten Nutzer alternativ) eine synoptische, alphabetisch sortierte Darstellung aller Einträge in einer Hauptkategorie inclusive aller Unterkategorien auf einer Seite (ggf. mit Hinweis auf die Unterkategorie hinter dem jeweiligen Eintrag) zu programmieren. --HvR 01:04, 29. Aug. 2007 (CEST)

Nach meiner Meinung kann - aus der Sicht eines Suchenden, für den die Enzyklopädie ja eigentlich gemacht ist! - die ausschließliche Verwendung von Unterkategorien unter Ausschluss der Oberkategorie keinesfalls zwingend sein: Wenn ich z.B. ein deutsches Adelsgeschlecht suche, würde ich jedenfalls in die Oberkategorie „Kategorie:Deutsches Adelsgeschlecht“ gehen, denn woher soll ich als Suchender wissen, dass es sich bei diesem Adelsgeschlecht um ein sächsisches, preußisches oder sonstwie geartetes handelt? Es sollten also gern beide Kategorien genannt werden dürfen. Eine identische Diskussion hatten wir mal bei Kategorie:Militärperson (Preußen) und der Kategorie:Artillerist (Preußen): Woher soll ich als Suchender bei einem preußischen General wissen, ob er Artillerist oder Infanterist war? Entsprechend wurde dort die Angabe beider Kategorien von Admins zugelassen. Ich plädiere also für die Zulassung beider Kategorie-Ebenen. --Seeteufel 11:35, 31. Aug. 2007 (CEST)

Darstellungsfehler in der Beobachtungsliste bei Änderungskommentaren mit arabischen Schriftzeichen im Mozilla Firefox

In der Beobachtungsliste taucht folgendes auf:

[[Bild:Arr_r.png]]<code> <span class="minor">K</span>   09:21 </code>Google Talk (Unterschied; Versionen) . . RobotQuistnix (Diskussion | Beiträge) (Bot:  Ergänze: yi:גוגל טאלק)<br />
[[Bild:Arr_r.png]]<code>     09:19 </code>Apple (Unterschied; Versionen) . . Mmp78 (Diskussion | Beiträge) (laut www.apple.com/de)<br />

Mozilla Firefox hat bei der Darstellung Probleme, wenn der Änderungskommentar mit Zeichen endet, die von Rechts nach Links geschrieben werden (beispielsweise arabische Zeichen). Die Uhrzeit in der nächsten Zeile verrutscht.

 K   09:21 Google Talk (Unterschied; Versionen) . . RobotQuistnix (Diskussion | Beiträge) (Bot: Ergänze: yi:גוגל טאלק)
     09:19 Apple (Unterschied; Versionen) . . Mmp78 (Diskussion | Beiträge) (laut www.apple.com/de)

Lösung dieses Problems durch Einfügen eines U+200E LEFT-TO-RIGHT MARK (‎) am Ende des Kommentars:

 K   09:21 Google Talk (Unterschied; Versionen) . . RobotQuistnix (Diskussion | Beiträge) (Bot: Ergänze: yi:גוגל טאלק)‎
     09:19 Apple (Unterschied; Versionen) . . Mmp78 (Diskussion | Beiträge) (laut www.apple.com/de)

Automatisches Einfügen von U+200E LEFT-TO-RIGHT MARK durch CSS:

.comment:after {
  content: "\200E"; /* U+200E LEFT-TO-RIGHT MARK */
}

 K   09:21 Google Talk (Unterschied; Versionen) . . RobotQuistnix (Diskussion | Beiträge) (Bot: Ergänze: yi:גוגל טאלק)
     09:19 Apple (Unterschied; Versionen) . . Mmp78 (Diskussion | Beiträge) (laut www.apple.com/de)

Wenn der CSS-Code eingebaut ist, zeigt Firefox die Beobachtungsliste korrekt an. Ich habe das nun seit 10 Monaten erfolgreich getestet. Der Code könnte in MediaWiki aufgenommen werden. Die richtige Stelle wäre /skins-1.5/monobook/main.css --Fomafix 10:12, 18. Jul. 2007 (CEST)

Siehe hierzu auch Bug 8996: RTL in edit summary makes watchlist goes wild. --Raymond ^{Disk. Bew.} 13:14, 26. Jul. 2007 (CEST)

Neue Schriftarten

Ist es möglich noch mehr Schriftarten in die Software zu integrieren? Die einzigen die ich irgendwie gefunden habe waren auf Wikipedia:TeX#Text und Schriften. Oder hab ich welche übersehen? --Versusray | Diskutiere mich! 19:38, 21. Jul. 2007 (CEST)

imho keine gute idee, das es keine möglichkeit gibt vorherzusehen, welche schriftarten der benutzer in seinem browser überhaupt installiert hat. für print ist das sinnvoll, im web nur in ganz engen grenzen. -- ∂ 20:09, 23. Jul. 2007 (CEST)

Ein paar Grundschriftarten wirds wohl geben, die jeder Browser kann, oder? --Versusray | Diskutiere mich! 13:17, 25. Jul. 2007 (CEST)

MediaWiki bringt keine eigenen Schriftarten mit. Die Darstellung wird komplett über CSS gesteuert. Ausnahme ist die Erweiterung für TeX zum Rendern der erzeugten Grafiken. Aber ich glaube nicht, dass du diese meinst. --Raymond ^{Disk. Bew.} 13:18, 26. Jul. 2007 (CEST)

Belegung der Buttons in der Bearbeitungswerkzeugleiste modifizieren

Schlicht und einfach: Der Button "Bildlink" in der Bearbeitungswerkzeugleiste gibt ein einfaches [[Bild:Beispiel.jpg]] aus. Das ist ja in seiner Syntax (weitgehend) unerwünscht, was den Button fast unbrauchbar macht. Kann man nicht das "fehlende" |thumb| hinzufügen, so dass das Anklicken [[Bild:Beispiel.jpg|thumb|]] erzeugt? Das wäre eine sinnvolle Ergänzung. Ebenso wäre vielleicht zu überlegen, ob man den Button für den äußerst selten benötigten und wenig erwünschten "Horizontale Linie"-Button durch etwas wichtigeres ersetzt, zum Beispiel <ref></ref> (bisher nur durch zwei Zwischenschritte in der Sonderzeichenauswahl erreichbar). Den Editoren würde das deutlich helfen und der Aufwand der Implementation scheint mir sehr gering. Gruß, Denis Barthel 10:50, 26. Jul. 2007 (CEST)

Das |thumb habe ich im MediaWiki-Corecode eingefügt: rev:24394. Sofern Brion keine Einwände hat, wird das in einigen Tagen live gehen. ref und Verwandte kann ich nicht so ohne weiteres im Corecode einbauen, da es sich um eine Erweiterung handelt, die nicht jede MediaWiki-Installation von Hause aus mitbringt. Jemand mit JavaScript-Kenntnisse könnte das aber bei uns in der de.wp einbauen. Es wurde schon öfters der Wunsch geäußert, die Werkzeugleiste zu erweitern. --Raymond ^{Disk. Bew.} 13:11, 26. Jul. 2007 (CEST)

Zusätzliche Buttons wurden schon x-mal vorgeschlagen. Da aber keine Einigung erzielt werden konnte, welche Buttons wichtig sind, wird es wohl nie umgesetzt werden (da bin ich Realist). Für den Privatgebrauch dürften allerdings diese Buttons ausreichen. Die sind durch so wenige Zeilen im monobook.js einsatzbereit, dass sogar ich das hinbekommen habe. --Ephraim33 18:00, 26. Jul. 2007 (CEST)

@Raymond: Danke! Das nenne ich prompt:) ! Das wäre dann das zweite Bier, das du bei mir gut hast, sobald Du/Ihr euch wieder mal bei x.0 einfindet.

@Ephraim33: Danke für den (mir schon bekannten) Tip. Diese ganzen Erweiterungen per Script sind natürlich dufte, kommen aber mangels Bekanntheit nur den "Hardcore-Editoren" zugute. Gerade Sachen wie die ref-Tags oder auch die Bilder-Erweiterung sind aber so wichtig, das sie auch Newbies oder Gelegenheits-Editoren direkt zur Verfügung stehen sollten. Außerdem sollten ja ganz elementare Funktionen auch nicht nur durch externe Erweiterungen vorhanden sein. Und wie immer: in der WP funktioniert sowieso vieles nicht durch Einigung und Konsens, sondern allein durch unwidersprochenes Willküren in kleinen Schritten ;) . Denis Barthel 19:09, 26. Jul. 2007 (CEST)

Du "Hardcore-Editor" ;-) --Ephraim33 20:29, 26. Jul. 2007 (CEST)

Babel/User auf Benutzer Diskussion

Vorlage:Babel und die "User"-Vorlagen (en-3 z.B.) erzeugen die User-Kategorien-Einträge (en-3 z.B.) im allgemeinen nur auf der Benutzerseite, nicht auf der Benutzer-Diskussions-Seite. Gerade bei User_en-3 fehlt der Eintrag auf der Diskussionsseite. Vgl. etwa meine Benutzerseite und Benutzer Diskussion:Frank Schulenburg. Vorlage:User es-1 etwa funktioniert auch auf der Diskussionsseite, wie ich an meiner eigenen zwischenzeitlich festgestellt hatte. Oder Vorlage:User la-2 funktioniert auch auf Benutzer Diskussion:Frank Schulenburg. -- Ich bin wohl nicht der einzige, der den Babel-Kasten auf seiner Diskussionsseite eigentlich sinnvoller als auf seiner Benutzerseite findet (wenn mir jemand was mitteilen will und z.B. sich des Lateinischen mächtiger fühlt als des Deutschen, würde er doch meine Diskussionsseite erklicken, oder?). Sollte/kann man die User-Vorlagen nicht in dieser Hinsicht vereinheitlichen? -- Lückenlos^wecken! 15:20, 7. Aug. 2007 (CEST)

Und welches Feature erbittest du gerade? Ich habe mir auch ein en-2 auf meine Disk geklatscht. Das kann doch jeder so handhaben wie er will. --Revolus Δ 15:26, 7. Aug. 2007 (CEST)

Ich erbitte, dass sich die User...-Vorlagen gleich verhalten hinsichtlich Kategorie-Eintrag. Dein Text deutet an, dass Du meine Problembeschreibung überhaupt nicht verstanden hast. -- Lückenlos^wecken! 19:45, 7. Aug. 2007 (CEST)

Sie verhalten sie alle gleich. Es wird eben die Seite einsortiert, auf der das Bapperl klebt. Anders wäre es gar nicht möglich. Wenn man will, dass die Benutzerseite in einer bestimmten Sprachkategorie steht, muss ma halt [[Kategorie:user de-M]] (o.ä.) an das Ende seiner Seite schreiben. Wenn man hingegen will, dass die Disk nicht in einer bestimmten Kategorie steht, bleibt einem nichts anderes übrig als den Quelltext der Vorlage zu kopieren und die Kategorievermerke daraus zu entfernen. (Siehe Hilfe: Kategorien) --Revolus Δ 19:54, 7. Aug. 2007 (CEST)

Druckversion eines Abschnitts in einem WP-Artikel

Dass die WP-Artikel als Ganzartikel in der Druckversion gedruckt werden können finde ich toll. Aber ist es technisch möglich, einen Abschnitt wie zum Beispiel im Artikel Autismus wie Entstehung oder das Asperger-Syndrom isoliert auszudrucken und auch hierfür eine Druckvorschau bereitzustellen? Dies würde m. E. die Wikipedia aufwerten

Liebe Grüße --JARU 00:15, 9. Aug. 2007 (CEST)

Hm, nicht perfekt: https://de.wikiup.org/index.php?title=Autismus&action=edit&section=13&printable=yes --Revolus Δ 00:38, 9. Aug. 2007 (CEST) --Revolus Δ 03:14, 9. Aug. 2007 (CEST)

Ich habe ein kleines Skript dafür geschrieben. Schau mal hier: Wikipedia:Skin/Baukasten#Revolus. --Revolus Δ 03:14, 9. Aug. 2007 (CEST)

@Revolus Danke. Aber ist es technisch machbar, dass ein Seitenumbruch immer OBERHALB einer Überschrift erfolgt? Wäre wünschenswert. Vielleicht kann man es auch einrichten, dass man die Position des Seitenumbruchs selbst festlegen kann. --JARU 08:05, 30. Aug. 2007 (CEST)

Direktes Übersetzen von DE.WP Artikeln

Ist es technisch machbar, direkte Übersetzungen von Artikeln in der Deutschen Wikipedia in die anderen Sprachen zu übersetzen und nicht nur auf die WP des jeweiligen Landes zu wechseln. Wäre manchmal interessant! Als Ergänzung zu Wiktionary, wo man nur einzelne Wörter übersetzen kann.

Denkbar wäre auch ein Einbau dieser Funktion in die Wiktionary.

Bitte diesen Vorschlag wohlwollend prüfen --JARU 19:41, 20. Aug. 2007 (CEST)

Du weißt ja, wie schlecht automatische Übersetzungen sind (Babelfish). Technisch machbar wäre es bestimmt, aber was würde es bringen? --Versusray | Diskutiere mich | Bewerte Mich 10:45, 21. Aug. 2007 (CEST)

"Verschlimmbesserung" http://de.wikipedia.org/wiki/Spezial:Hochladen

Offenbar ist die Bilder-Hochladeseite in letzter Zeit mal geändert worden.

Auffälligste Änderung für mich ist, dass der Baustein mit der Bildbeschreibung aus dem erläuterndem Text der Seite verschwunden ist und nun im Eingabeformular auftaucht.

Der Haken bei der Sache: Man muss dazu Javascript eingeschaltet haben. Hat man es nicht eingeschaltet, bekommt man den Baustein nicht. Konnte man sich früher durch ein einfaches Copy-und-Paste leicht weiterhelfen, steht man jetzt erstmal ziemlich dumm da.

Da Beschreibungs- und vor allem Lizenzdaten grundlegende Bestandteile eines Bildes bei Wikipedia sind, ist dies als deutlicher Funktionsmangel anzusehen, speziell auch vor dem Hintergrund, dass benutzerfreundliche Webseiten so weit wie möglich ohne den Zwang zu Javascript auskommen sollten, und Wikipedia sich doch in diese Kategorie einreihen sollte.

Mein Vorschlag ist daher, den Lizenzbaustein wie vorher im Text der Seite unterzubringen, von wo er ggf. per Copy&Paste übernommen werden kann. Für diejenigen, die Javascript angeschaltet lassen, mag die jetzige Variante mit dem Eingabeformular bestehen bleiben, das schließt sich ja gegenseitig nicht aus.

Ein zweiter Vorschlag wäre, in Zukunft nach Änderungen an solchen Seiten zu testen, ob es nicht zu Fehlfunktionen durch die Änderungen kommt. Deaktivieren von Javascript (Flash, Java, ...) wäre m.E. ein wichtiger Testfall.

(Ich hab' anderswo schon kräftig gelästert, aber hier scheint der geeignete Ort für diesen Vorschlag zu sein)

Oxensepp 22:06, 22. Aug. 2007 (CEST)

Länderflaggen links unter "Andere Sprachen"

Hallo,
ich fänd es ganz gut und interessant, wenn man im Menu unter "Andere Sprachen" jeweils eine Flagge für das jeweilige Land finden könnte. Manchmal wüsste ich gerne, welche Sprache und welches Land das nun ist (weil die Sprachenbezeichnungen ja jeweils in der Sprache sind, wo sie hinführen). Man könnte eine Flagge, oder zumindest einen kleinen Hinweis auf die aktuelle Sprache (aber dann bitte für jedermann verständlich, z.B. auf Englisch) irgendwo unterbringen, vielleicht oben rechts, oder ganz nach unten irgendwo. Damit man halt weiß, wo man ist.

Zusammenfassung: Ich wünsche mir eine Kennzeichnung in der Wikipedia, bei der ich sehe, in welcher Sprache ich grad unterwegs bin (Flagge, kleiner Link...). --87.123.218.7 21:57, 26. Aug. 2007 (CEST)

• In den meisten Browsern wird beim Überfahren der Links in der Statusleiste (unten) die Zieladresse angezeigt, welche leicht die Sprachkennung nach ISO 639 erkennen lässt. Gruß --Quilbert 問 20:23, 28. Aug. 2007 (CEST)

Die Kennzeichnung der Sprachen mit Hilfe von Flaggen ist mitunter problematisch, da sich die Staatsgrenzen und die Verbreitungsgebiete der Sprachen nicht 1:1 überdecken. So wird etwa Deutsch nicht nur in Deutschland, sondern auch unter anderem in der Schweiz gesprochen. Oder aber: Welche Flagge soll man für Englisch wählen? Den Union Jack oder das Sternenbanner? Warum aber lässt man etwa die australische Flagge außen vor, wo doch dort Englisch de facto Amtssprache ist?

Auf der anderen Seite gibt es Sprachversionen der Wikipedia, zu denen sich gar keine Flagge eines Staates finden lässt, so beispielsweise für das Obersorbische, das unter http://hsb.wikipedia.org vertreten ist. Ich stimme hingegen zu, dass es vielleicht eine interessante Lösung wäre, beim Überfahren des Links einen Tooltip anzeigen zu lassen, der den Namen der Sprache in Deutsch oder Englisch zeigt, damit man nicht unbedingt den ISO-Artikel durchsuchen muss bzw. als Unwissender auch ohne Kenntnis der im Link versteckten Sprachkürzel oder des ISO-Artikels die Sprache in Erfahrung bringen kann. Grüße, --CyRoXX ^(? ±) 23:00, 29. Aug. 2007 (CEST)

Dezente Eigenwerbung: Wikipedia:Skin/Baukasten#Revolus --Revolus Δ 23:11, 29. Aug. 2007 (CEST)

Neue Startseite mit der Suchmaske

Die neue Startseite mit der Suchmaske nach Aufruf von: http://www.wikipedia.de gefällt mir sehr gut. Sie sollte nur unbedingt für den angemeldeten User auch die bei allen anderen Seiten oben erscheinende Leiste mit

Hvrandow Eigene Diskussion Einstellungen Beobachtungsliste Eigene Beiträge Abmelden

enthalten, damit man nicht extra auf die Hauptseite oder einen Artikel gehen muß, wenn man sie gleich braucht um etwas zu kontrollieren oder zu werken!! --HvR 22:10, 29. Aug. 2007 (CEST)

Diese Seite gehört dem Verein Wikimdia Deutschland. Hat mit der Wikipedia selbst nur indirekt zu tun, gehört nicht zum eigentlichen "Wikipedia-Inventar". Ist also nicht wirklich die Wikipedia-Startseite, nur ein Portal. Marcus Cyron in memoriam Volkmar Fritz 22:22, 29. Aug. 2007 (CEST)

Ist mein Vorschlag deshalb also technisch nicht umsetzbar? Oder kann die Wikimedia Deutschland dies nicht durch Querverlinkung mit der Wikipedia doch einfügen? Ich vermisse jedenfalls hier die fehlende Nutzerleiste sehr! --HvR 22:55, 29. Aug. 2007 (CEST)

Es geht eher darum, daß hier der falsche Ort ist ;). Wende dich damit am Besten an Benutzer:Akl. Marcus Cyron in memoriam Volkmar Fritz 10:00, 30. Aug. 2007 (CEST)

Artikel löschen - Konfiguration

Hallo , da ich ebenfalls ein Admin bin (nicht hier sondern da (kurdische Wikipedia)), stört es mich oft, dass, wenn ich eine normale Seite (also einen Artikel) lösche, dass dann noch die Diskussionsseite zu löschen ist. Es ist ein bisschen aufwändig. Wäre es nicht möglich, über alle MediaWiki's eine Änderung vorzunehmen, sodass man beim Löschen des Artikel ein Kästchen ankreuzen kann, welches besagen soll, dass mit dem Löschen des Artikel auch die Diskussionsseite gelöscht werden soll? (Wobei diese Option standardmäßig aktiviert sein sollte. Ansonsten wäre eine Spezialseite "verwaiste Diskussionsseiten" praktisch, die man nach Möglichkeit auch noch auf den Namensraum eingrenzen kann, da eine solche Auswahl auf dem Benutzernamensraum keinen Sinn macht.) --Bangin ¤ ρø$τ Bewertung 23:16, 8. Sep. 2007 (CEST)

Filtern in der Eingangskontrolle

Es besteht zur Zeit nur die Möglichkeit beim Überprüfen der Letzten Änderungen die Beiträge von unangemeldeten Benutzern, Bots und angemeldeten Benutzern herauszufiltern. Um die Eingangskontrolle (und Vandalenjagd) etwas effizienter zu gestalten, wäre es von Vorteil auch nur Beiträge von unangemeldeten und neuen Benutzern sehen zu können. --Nikkis^?!?!+/- WikiWiki 10:38, 16. Sep. 2007 (CEST)

Seitenlog statt Löschlog

Nun taucht im "Löschlog", und auch wenn ich eine gelöschte Seite aufrufe der Auszug, die Löschung der Seite auf, aber nicht deren Anlage. Ich denke, es wäre für mehrere Fragen sinnvoll, zu sehen, wer die Seite wann und warum (Changelog) angelegt hat. Gruß --...bRUMM↔fUß! 20:17, 18. Sep. 2007 (CEST)

Eine hervorragende Idee, würde ich sehr befürworten. —jtt (Disk  –  Feedback) 01:36, 7. Okt. 2007 (CEST)

Suchfunktions-Umwandlung von Halb- und Viertelgeviertstrich

Die Suche ist ja mittlerweile fähig, Groß- und Kleinbuchstaben ineinander umzuwandeln und dahingehend leistungsfähiger zu sein. Ich schlage vor, dasselbe für Halb- und Viertelgeviertstrich einzuführen. Das würde viele lästige Redirects ersparen. --KnightMove 14:02, 14. Aug. 2007 (CEST)

(C+P von der VV-Hauptseite, dort gab es keine Kommentare.) --KnightMove 20:21, 18. Sep. 2007 (CEST)

Versteckte Suchbegriffe und Relevanz der Suchbegriffe

Hallöschen, ich versuche mich einfach mal in einem Vorschlag. Nach einer kleine Diskusion in Weiterleitung von Basaltsteine stellte mich die Frage, warum man in den Artikeln nicht bestimmte Begriffe als Suchbegriff deklarieren kann. So in der Art:

• <keywords>basaltstein</keywords>
• <keywords>basaltsteine</keywords>
• <keywords>basaltgestein</keywords>

Oder, bzw auch Kennzeichen von Suchbegriffen im Fließtext:

• Basalt wird fälschlicherweise oft als <keywordsinText>Basaltstein</keywordsinText> bezeichnet. Richtig wäre jedoch <keywordsInText>Basaltgestein</keywordsInText>

Diese Suchbegriffe wären dann im Suchergebniss in der Relevanz weiter oben.

Hintergrund: Viele suchen etwas und wissen gar nicht wie es richtig heißt. Denen Menschen wäre dann geholfen, da es ja der Sinn einer Enzyklopädie ist, wissen zu vermitteln.

Mir ist aber auch klar, das die Verwendung von Suchbegriffen ins Uferlose gehen kann. Daher sollten diese beschränkt sein. Denn es ergibt nicht unbedingt Sinn, wenn jemand Erbach sucht, die Seiten von Einhard findet. Nur weil mal jemand gesagt habe, Einhard wäre der Stammvater des Grafen zu Erbach

Das ist ein spontaner Vorschlag eines Neuling, also nicht gleich hauen. --MfG - Lupusverlach 09:48, 23. Sep. 2007 (CEST)

InterWiki zu externen Seiten

das ist in Wikipedia:Löschkandidaten/23. September 2007#InterWiki zu InterWiki aufgetaucht:

das mit [[google:Wikipedia]]) wusste ich gar nicht: google:InterWiki, geht ja.. ;) aber welchen vernünftigen grund gäbe es, ernsthaft eine google-seite zu verlinken? kontrollieren kann man ja nur mehr artikelweise ob google auf der seite velinkt ist (Spezial:Linksearch&target=http://www.google.com/search?q=InterWiki, diese hier findet die Weblink-Suche nicht..)

jedenfalls wenn, sollte das als mindestens die seite http://www.google.at/search?hl=de&q=$SUCHBEGRIFF$++-wikipedia.org+-site%3Awikipedia.org verlinken, es hat ja keinen sinn, uns immerwieder in einer enlosschleife selbst in google zu spiegeln.. -- W!B: 23:58, 23. Sep. 2007 (CEST)

Smilies für die Diskussionsseiten!

Jedes größere Forum hat eine kleine Auswahl an smilies für die Benutzer zur Verfügung, welche dabei helfen in Diskussionen Gefühle auszudrücken. Dadurch wird mancher Konflikt vermieden. Wäre toll, wenn wiki das auch hätte!--Robert Michael Schulz 23:54, 29. Sep. 2007 (CEST)

Es gibt mehr als genug Smilies in commons:Category:Smilies, die du mit der normalen Bildsyntax einbinden kannst. -- Prince Kassad 00:00, 30. Sep. 2007 (CEST)

Wikipedia ist aber kein Forum. Marcus Cyron in memoriam Hans Georg Niemeyer 00:37, 30. Sep. 2007 (CEST)

Wikipedia ist kein Klickibunti-Forum. Manchmal sind Smileys durchaus angebracht, v.a. um Ironie auszudrücken. Dafür gibts auch die old-school Tastatursmileys: :-) oder ;-). Versteht auch jeder. Ebenso wie z.B. :-p oder :-/. Sonst kann man auch schreiben *staun*, *sich-den-Kopf-kratzend* etc. wenns denn notwendig sein sollte. --Der Umschattige talk to me 12:08, 7. Okt. 2007 (CEST)

Bei Abschnittbearbeitung zusätzlicher Button für Vorschau des Ganzen Artikels

Dann sind auch die references und das Inhaltsverzeichnis zu sehen und wie sich der Abschnitt in den Artikel einfügt.--Diwas 17:57, 13. Okt. 2007 (CEST)

a:after in der commonPrint.css (erledigt)

Hallo, in der commonPrint.css ist derzeit folgendes angegeben:

1. content a.external.text:after, #content a.external.autonumber:after {

   /* Expand URLs for printing */
   content: " (" attr(href) ") ";

} Dadurch wird – zumindest bei einigen Browsern – beim Ausdrucken nach Weblinks die URL in Klammern angegeben. Aus „Wikipedia“ wird also auf dem Papier „Wikipedia (http://wikipedia.org)“. – Bei den Paragraphenverlinkungen über die Vorlage:§ führen diese URL-Angaben allerdings zu unschönen Ergebnissen wie z. B. „§ 434 (http://bundesrecht.juris.de/bgb/__434.html) Abs. 1 Satz 2 Nr. 1 BGB“. Das Thema wurde auf waus Diskussionsseite von einem Benutzer angesprochen.

Können wir eine Möglichkeit schaffen, die URL-Ausgabe in Einzelfällen zu unterdrücken (oder gibt es die jetzt schon)? Zum Beispiel, indem wir folgendes in der CSS-Datei hinzufügen: .url-no-print a:after {

    display:none;

} Grüße -- kh80 •?!• 14:17, 25. Okt. 2007 (CEST)

Ja, genau so müsste es gehen. In einem Test von mir mit Opera klappt es aber irgendweswegen nicht, komischt. Ich würde die Klasse plainlinks-print o.ä. in Anlehnung an plainlinks benennen. Gruß, --Revolus Echo der Stille 16:20, 25. Okt. 2007 (CEST)

Hmm, mit dem Firefox hat's geklappt (und bei IE funktioniert a:after sowieso nicht). Deinen Namensvorschlag fände ich auch okay. Grüße -- kh80 •?!• 21:41, 25. Okt. 2007 (CEST)

Falls in den nächsten Tagen keine Einwände mehr kommen, würde ich den Request bei Bugzilla veröffentlichen. (Die sind doch zuständig, oder? Wir Admins können ja nicht an der commonPrint.css herumfummeln ...) Grüße -- kh80 •?!• 17:30, 29. Okt. 2007 (CET)

Hm auf gewisse Weise schon. Du kannst zwar nicht in der commonPrint.css rumfummeln, aber dafür den Medientypen bestimmen, wofür eine Änderung in der MediaWiki:common.css wirksam sein soll:

@media aural, braille, embossed, tty {
	.plainlinks-print {
		display: none;
		}
	}

--Revolus Echo der Stille 17:40, 29. Okt. 2007 (CET)

Ah, danke, man lernt nie aus. :) Dann würde ich also in common.css das Folgende ergänzen:

@media print {

       .plainlinks-print a:after {
               display: none;
               }
       }

Grüße -- kh80 •?!• 18:25, 29. Okt. 2007 (CET)

Ja genau (ich muss sagen, im Copy-Pasten war ich auch schon mal besser :-\). Gruß, --Revolus Echo der Stille 18:37, 29. Okt. 2007 (CET)

Ich merke gerade, dass in der MediaWiki:common.css schon für die Klasse coordinates Ausnahmen festgelegt waren. Ich habe die Angaben für die Klasse plainlinks-print übernommen ([2]). Scheint zu klappen. :) Grüße -- kh80 •?!• 00:49, 30. Okt. 2007 (CET)

Bei mir (Opera 9.24) klappt das so leider nicht. Ich habe ein bisschen rumexperimentiert und es funktioniert sogar nur, wenn man display: none !important; nimmt. Der Grund ist mir immernoch schleierhaft. --Revolus Echo der Stille 00:58, 30. Okt. 2007 (CET)

Danke für den Hinweis. Hmm, dann werden bei dir also auch die URLs der Geokoordinaten wie ausgedruckt? Sollte man dann beides in [...] { display:none !important; } (oder [...] { content: ""; display:none !important; }?) ändern? Grüße -- kh80 •?!• 01:13, 30. Okt. 2007 (CET)

Da klappt es ja, was noch komischer ist :-\ Vielleicht die plainlinks-print-Klasse doch streichen und coordinates dafür missbrauchen? Wenn ich die benutze, wird in der Druckvorschau kein Link bei den Paragraphen angegeben. Gruß, --Revolus Echo der Stille 01:30, 30. Okt. 2007 (CET)

Dann würde die Paragraphen-Links aber nicht mehr als externe Links gekennzeichnet. :( Grüße -- kh80 •?!• 18:58, 31. Okt. 2007 (CET)

Ok, jetzt geht es. Ich glaube, ich bin nur manchmal etwas duslig ;-) Gruß, --Revolus Echo der Stille 15:57, 2. Nov. 2007 (CET)

Links auf Begriffsklärungen in der Vorschau violett darstellen

Um Autoren zu informieren, welche Links im bearbeiteten Artikel auf Begriffsklärungen (Kategorie:Begriffsklärung) verweisen, wäre es sehr sinnvoll diese Links in der Vorschau violett darzustellen. Wäre dies technisch umsetzbar? --Diwas 13:43, 1. Nov. 2007 (CET)

Funktion in der Bearbeitungsansicht: Links prüfen

Um bereits vor Ausführen der Vorschau zu sehen ob die Links in Ordnung sind, wäre eine Funktion sinnvoll die es erlaubt nach anklicken von „Links prüfen“ den Quelltext der Links farblich zu kennzeichnen: blau: ok, rot: nicht vorhanden, violett: Begriffsklärungsseite, grün: Weiterleitung. Wäre dies technisch umsetzbar? --Diwas 13:49, 1. Nov. 2007 (CET)

Es gibt eine ähnliche Form der Linküberprüfung. Wikipedia:Helferlein/Navigation-Popups bietet eine Artikelvorschau, wenn im Quelltext ein mit eckigen Klammern umschlossener Begriff markiert wird. Bei Nichtexistenz gibt es einen Hinweis auf eine Leere Seite. --Mandavi מנדבי?¿disk 14:22, 22. Nov. 2007 (CET)

Geschütze Zeichen kommandointerpretieren lassen

Eine starke Verbesserung, wenn geschütze Zeichen wie   interpretiert werden könnten. Die lassen sich schwer merken und werden deshalb von Benutzern seltener als benötigt verwendet. Die Verbesserung spart Edits, traffic und Platz, weil diese Zeichen oft nachträglich von anderen Benutzern eingetragen werden. Die Befehlszeile dafür dürfte ja auch nicht so lang sein.

Ich schlage vor &, das kommt in den Verbindugen & & oder &-& nie vor. -- Carl 22:16, 1. Nov. 2007 (CET)

Siehe Bug 3461: Syntax extensions: special character for non-breaking space (& nbsp ;), — Raymond ^{Disk. Bew.} 23:03, 1. Nov. 2007 (CET)

.Danke Raymond. Setzt das auch jemand um? -- Carl 22:59, 2. Nov. 2007 (CET)

Literaturliste im Benutzerraum mit Vorlage:Literatur, Grenze raufsetzen?

Hallo, wie man hier sieht, Beispiel Benutzer:JEW/Literatur, ist hier rasch die Grenze mit der ansonsten wirklich nicht schlechten Literaturvorlage erreicht. Die Liste enthält die Informationen der verwendeten Literatur vorgefertigt in Vorlagen, damit die Quellenangaben in den Artikeln gemacht werden können. Könnte man die Grenze eventuell von ca. 256 auf 512 oder mehr raufsetzen? Danke! – Simplicius ☺ 13:15, 7. Nov. 2007 (CET)

Soweit ich das einschätzen kann ist das ein technisches Problem, da man nur eine maximale Anzahl an Bytes in eine Seite per Vorlage einfügen kann. Ich finde gerade nicht die Seite wo das stand. Entweder muss dann die Vorlage:Literatur entschlackt werden, oder eine neue Unterseite anfangen, wobei man das entschlacken nicht einfach so machen sollte, sondern vorher ankündigen/diskustieren, wobei ich das entschlacken nicht für sinnvoll halte. Man kann die Unterseite doch gut aufteilen. Der Umherirrende 18:26, 7. Nov. 2007 (CET)

Genaueres würde mich da mal interessieren. – Simplicius ☺ 20:12, 7. Nov. 2007 (CET)

Na ja, an der Stelle würde ich sagen, subst: ist dein Freund. --Revolus Echo der Stille 20:26, 7. Nov. 2007 (CET)

Ich habe es gefunden: hier den letzten Punkt der Auflistung oder direkt hier (beides englisch). Der Umherirrende 21:25, 7. Nov. 2007 (CET)

Ich habe mal die Dokumentation aus der Vorlage:Literatur ausgelagert. Jetzt sind ein paar mehr Verwendungen pro Artikel möglich. Jetzt könnte man nur noch an den Leerstellen und Zeilenumbrüchen sparen. --Revolus Echo der Stille 23:01, 7. Nov. 2007 (CET)

Das hat gut gewirkt. Könnte man möglicherweise auch die Interwikis auf eine Unterseite als Vorlage auslagern? – Simplicius ☺ 23:45, 7. Nov. 2007 (CET)

Habe ich gemacht, hat aber nicht so viel wie der erste Edit gebracht. --Revolus Echo der Stille 00:07, 8. Nov. 2007 (CET)

Danke, ein bissl hat es was gebracht. – Simplicius ☺ 02:34, 8. Nov. 2007 (CET)

An wen kann man sich denn wenden, um die byte-mässige Grenze hochzusetzen? – Simplicius ☺ 23:48, 9. Nov. 2007 (CET)

MediaZilla --Revolus Echo der Stille 01:38, 10. Nov. 2007 (CET)

Redirects und ihre Probleme

Derzeit ist mal wieder ein Streit über Redirects im Gange, der vor allem Redirects in anderen Sprachen geschriebenen (z.B. arabisch oder chinesisch) betrifft. Da Redirects nicht zu einem Artikel gehören ist es z.B. ohne Probleme möglich auf George W. Bush mit einem Redirect zu verlinken, der in mongolisch vieleicht "der Teufel" bedeutet und 99% der Nutzer wären nicht einmal in der Lage diesen Fehler zu erkennen, bzw. von den verbleibeden 1% finden auch nur noch 1% den falschen Redirect.

Aus diesem Grunde wäre ich dafür Artikel um eine Meta-Angabe für Synonyme zu erweitern, die dann automatisch von der Software erkannt und als Redirect vermerkt werden. Sollten zwei Artikel den gleichen synonymen Begriff verwenden, dann sollte der Nutzer am Speichern gehindert werden, da bereits ein anderer Artikel dieses Synonym für sich beansprucht.

Außerdem könnten so viele Seiten die nur zwecks Redirect existieren eingespart werden, bzw. die bisherigen Redirects könnte man gleich komplett abschaffen. Es wäre außerdem sinnvoll anzugeben, in welcher Sprache dieses Synonym exisiert (ähnlich der Vorlage:lang), damit leicht unterschiedliche Schreibweisen nicht zu Missverständnissen führen. --Niabot (Diskussion) 02:36, 19. Nov. 2007 (CET)

Das vorgeschlagene Feature könnte sinnvoll sein für ein bisschen mehr Komfort, allerdings technisch wohl etwas aufwändig. Das angesprochene Problem stellt sich IMHO aber nur in der Theorie: Über Spezial:Whatlinkshere können ja schon mit einem Klick alle Weiterleitungen auf einen Artikel angezeigt werden, die Verbesserung wäre also nur marginal.

Zu den Fakes: Sollte so ein falscher Redirect tatsächlich nicht auffallen, dann hat er wohl auch noch keinen Schaden angerichtet. Das Argument gilt ansonsten ja auch für interwikis bzw. eig. alle Artikel die Themen aus den entsprechenden Sprachräumen behandeln. Da sind wir nun mal auf die Benutzer angewiesen, die sich dort auskennen und neue Einträge prüfen und das funktioniert ja auch bisher gut. Gruß --Spananien 11:04, 19. Nov. 2007 (CET)

Um ehrlich zu sein, wer benutzt denn schon regelmäßig Spezial:Whatlinkshere? Welcher nicht angemeldete, des arabisch mächtige Nutzer weiß davon? Es ist außerdem wesentlich komfortabler die Redirects zu pflegen und würde damit auch automatisch dazu führen, das mehr "Redirects" angelegt würden. Gleichzeitig hätten die Autoren des Artikels die volle Kontrolle, da sie ja über die Anlegung jedes Redirects alleine durch Beobachtung des Artikels, auf den verlinkt wird, alle Änderungen bemerken. Außerdem lassen sich so auch viele Datenbankeinträge einsparen, da dies die Software intern übernehmen kann, indem sie eine einfache Liste der Weiterleitungen führt. --Niabot (Diskussion) 11:14, 19. Nov. 2007 (CET)

Naja, ich denke die meisten regelmäßigen User benutzen die "Links a.d. Seite". Andererseits, welcher nicht angemeldete arabisch sprechende Nutzer schaut in den Quelltext um sich die Metadaten für die Synonyme anzuschauen? Es sollte ja idR jeder Begriff von dem weitergeleitet wird auch im Artikeltext stehen insofern bekommt man durch Beobachtung eines Artikels oft auch neue Weiterleitungen mit.

Aber trotz allem würde ich so ein Feature durchaus begrüßen, von der Logik her wäre es auf alle Fälle das sinnvollste. Ich glaube nur, dass du mit deiner Einschätzung mit den weniger Datenbankeinträgen falsch liegst, eine solche Funktion würde wohl (vor allem bei der Suche) eher mehr kosten, bzw. intern würden in der Datenbank dann eben doch die Redirects einzeln liegen. Aber warten wir mal, was die Profis dazu sagen.--Spananien 11:24, 19. Nov. 2007 (CET)

Da hast du schon recht, aber wenigstens wüssten die normalen Autoren über einen solchen Redirect bescheid, bzw. man würde damit fast automatisch erzwingen das ein solcher Begriff auch im Artikel steht, was bisher kaum zu kontrollieren ist.

Frage am Rande: Warum sieht mir dieser Nutzer wie eine Sockenpuppe aus? --Niabot (Diskussion) 11:32, 19. Nov. 2007 (CET)

Welcher Nutzer? --Spananien 11:37, 19. Nov. 2007 (CET)

Der Nutzer Spananien, da er mir seit gestern zu existieren scheint, bzw. seitdem die Diskussion mit den Weiterleitungen richtig entbrannt ist :-) --Niabot (Diskussion) 11:42, 19. Nov. 2007 (CET)

Ach so. Ja, der kommt mir auch verdächtig vor. --Spananien 11:45, 19. Nov. 2007 (CET)

Wenn das Software-technisch möglich ist, wäre die vorgeschlagene Vorgehensweise sicherlich der Königsweg. --seismos 10:55, 19. Nov. 2007 (CET)

"Da Redirects nicht zu einem Artikel gehören ist es z.B. ohne Probleme möglich auf George W. Bush mit einem Redirect zu verlinken, der in mongolisch vieleicht "der Teufel" bedeutet und 99% der Nutzer wären nicht einmal in der Lage diesen Fehler zu erkennen, bzw. von den verbleibeden 1% finden auch nur noch 1% den falschen Redirect." Das Beispiel ist nicht nachvollziehbar. Ein Redirect in mongolischer Schrift wär, auch nach dem Meinungsbild, für Bush nur gerechtfertigt, wenn er Mongole wäre und die Schriftzeichen auch im jeweiligen Artikel angegeben wären. Wenn du nicht-lateinische Schrift für unüberprüfbar und als leicht Vandalismus-anfällig betrachtest, müsstest du alle nicht-lateinischen Schriftzeichen aus diesem Grund aus der deutschsprachigen Wikipedia entfernen. Ansonsten gilt, wie immer, dass auch für nicht-lateinische Schriftzeichen eine Quellenangabe gemacht werden sollte, wodurch das Argument der Unüberprüfbarkeit eigentlicht widerlegt wird.

Finde den Vorschlag recht kompliziert und zu aufwändig, das findet der "nicht angemeldete arabisch sprechende Nutzer", der noch nicht viel Erfahrung mit Wikipedia hat, wahrscheinlich auch. Und wieso würden Synonyme in nicht-lateinischer Schrift hier toleriert und als Weiterleitung nicht? --Shikeishu 13:40, 19. Nov. 2007 (CET)

Ich glaube du hast hier etwas in den falschen Hals bekommen. Was ich hier versuche zu skizzieren, ist eine recht einfache Möglichkeit die Probleme die Redirects mitbringen zu beseitigen. Ein Problem wäre z.B. die ungewollte Verweisung oder eben das es Vandalen, mit nur schlechter Kontrollmöglichkeit, möglich ist so etwas durchzuführen.

Es soll hier keinesfalls versucht werden die Redirects abzuschaffen, sondern eine bessere und sogar für den Autor leichter wartbare Möglichkeit zu schaffen Redirects anzulegen und zu verwalten. Die mit der "neuen" Variante angelegten Redirects könnten dann durchaus auch in jeder Sprache geschrieben sein, da die Kontrolle bei den Autoren des Artikels liegt.

Am Beispiel von ஸ்ரீனிவாஸ ஐயங்கார் ராமானுஜன kann man dies doch sehr schön sehen was es für ein Problem ist einen Redirect zu korrigieren, denn der falsche Redirect muss erst aufwändig gelöscht werden und ohne den LA wäre vermutlich Prince Kassad niemals über diesen Schreibfehler im Redirect gestoßen. Oder er hätte ihn zwar im Artikel korrigiert, allerdings würde der Redirect vermutlich vergessen werden.

Aus diesen Gründen bin ich hier für die Suche nach einer besseren Lösung, die sogar in deinem Sinne sein sollte. --Niabot (Diskussion) 14:36, 19. Nov. 2007 (CET)

Eine weitere Idee: Damit man sich zusätzliche Arbeit spart und das Synonym im eigentlichen Artikel nicht zweimal auftauchen muss wäre ich dafür eine weitere Schreibweise für Links einzuführen, die z.B. so aussehen könnte:

'''Neu-Delhi''' (auch ''[[[syn:de:Neu Delhi]]]''; [[hindi]]: [[[syn:hi:नई दिल्ली]]], [[[syn:hi-Latn:Naī Dillī]]]; [[Englische Sprache|englisch]]: ''[[[syn:en:New Delhi]]]'') ist die [[Hauptstadt]] [[Indien]]s mit 321.883 Einwohnern in der eigentlichen Stadt und 17.753.087 in der [[Agglomeration]] zusammen mit der nördlich gelegenen älteren ''Stadt [[Delhi (Stadt)|Delhi]]'' (Stand 1. Januar 2006). Sie liegt im [[Unionsterritorium]] [[Delhi (Unionsterritorium)|Delhi]] und ist Verwaltungszentrum, Industriestadt, Verkehrsknoten und Kulturzentrum. Da Neu-Delhi und die Stadt Delhi eine urbane Einheit bilden, werden in Indien meist beide Städte zusammen einfach nur ''Delhi'' genannt.

Dabei wird der Text einfach an der entsprechenden Stelle ohne weitere Formatierung eingefügt. Die Software merkt sich aber diesen Namen gleichzeitig auch als Redirect. So braucht der Name nur einmal als Synonym gekennzeichnet werden, was den Arbeitsaufwand veringern würde. Die Sprachattribute sollten nicht verpflichtend sein, können aber genutzt werden um ähnliche Schreibweisen eindeutig einer bestimmten Sprache zuzuordnen und somit Konflikte vermeiden. --Niabot (Diskussion) 21:50, 19. Nov. 2007 (CET)

Das wäre natürlich gut. --Diwas 00:56, 20. Nov. 2007 (CET)

Das finde ich allerdings auch und hoffe, dass das schon die konsensfähige Lösung darstellt! --Port(u*o)s 04:59, 20. Nov. 2007 (CET)

Das Problem ist hier halt, dass es von einer breiteren Masse unterstützt werden müsste. Am liebsten würde ich dies als Teil eines neuen Meinungsbildes (altes MB) sehen wollen, da damit viele Kritikpunkte entfallen würden und fremdsprachigen Redirects eigentlich nichts mehr im Weg steht. Fremdsprachige Lemma würde ich hier aber nicht mit einbeziehen wollen, da Artikel halt mit Hilfe einer normalen Tastatur eingebbar sein sollten. --Niabot (Diskussion) 08:50, 20. Nov. 2007 (CET)

Die Wikisoftware müsste dann wohl bei jedem Speichern den Artikel nach Redirects durchsuchen und dann bei Änderungen nachfragen ob der Redirect wirklich angelegt oder gelöscht werden soll. Die Wikisoftware musste dann den Redirect anlegen und vollsperren bzw. löschen. Es müssten noch Begrenzungen festgelegt werden, damit nicht tausende Redirects mit einem Edit angelegt werden können. --Diwas 01:13, 21. Nov. 2007 (CET)

Nein das soll sie nicht machen! Die Wikisoftware sucht nach der im Text entsprechend markierten Stellen und merkt sich (ohne einen neuen Artikel anzulegen) diese Synonyme und zu welchem Artikel diese gehoeren. Wenn nun ein Artikelname eingegeben wird, dann wird der Artikel sowohl in der normalen Datenbank, als auch in der Liste der Synonyme gesucht. Sollte der Artikel in der Liste der Synonyme gefunden werden, dann wird die Seite angezeigt zu der das Synonym gehoert. Es sollte allerdings zuerst nach einen normalen Artikel gesucht werden, da sonst Synonyme normale Artikel verstecken könnten, z.B. die Hauptseite.

Beim Speichern muss allerdings ueberprueft werden, ob nicht zwei Artikel das gleiche Synonym fuer sich beanspruchen. Das speichern sollte in diesem Fall verhindert werden und der Schreiber sollte die Information bekommen, mit welchem Synonym er kollidiert. Dann kann der Schreiber eine entsprechende Beriffsklaerung anlegen. --Niabot (Diskussion) 10:16, 21. Nov. 2007 (CET)

Ich habe eben eine neue Übersichtsseite angelegt welche alle Informationen zu diesem Thema zusammenträgt und versucht übersichtlich darzustellen. Solltet ihr dazu noch weitere Vorschläge haben, dann schreibt es entweder dort bei den Vorschlägen hinzu oder sprecht es an dieser Stelle an. --Niabot (Diskussion) 18:02, 21. Nov. 2007 (CET) PS: Gibt es hier auch irgendjemanden der die Seite betreut? Bisher musste ich mir alle Diskussionsteilnehmer selbst mitbringen!

Audio in WP

In Hilfe:Audio steht, dass als Audio-Format Ogg, Vorbis oder WAV möglich (WAV aber nicht gern gesehen) sei.

WAV hochladen funktioniert aber bei mir nicht (Fehlermeldung).

OGG wird von NERO Essential nicht abgespielt, sondern nur in der Professional-Variante (und die hat ja nicht jeder). Zu OGG: "Momentan ist das Problem noch die Hardwareunterstützung. Diese fehlt bei den meisten Rechnern noch. Das Abspielen von OGG-Dateien bereitet dem normalen Computernutzer ebenfalls noch Probleme, denn zum Beispiel der Windows-Media-Player oder ähnliche gängige Player unterstützen das Format nicht. Dazu müssen erst extra Codecs installiert werden."

Ich finde, WP muss von jedem Standardrechner nutzbar sein. Mit jedem Standardbwowser. Ohne "Installation" von irgendwas. Weder beim Lesen noch beim Schreiben.

Ich verstehe nichts von Formaten. Vielleicht kann aber jemand ein Script schreiben, das hochzuladende Dateien automatisch prüft und in ein entsprechendes Format wandelt? Eines das a) WP-konform ist und b) von jedem Browser gelesen werden kann? Gruss, --Markus 09:05, 9. Okt. 2007 (CEST)

verschoben von Wikipedia:Verbesserungsvorschläge/Feature-Requests-Vorschlag, was gelöscht wurde von --Ephraim33 09:46, 19. Nov. 2007 (CET)

WAV kann nicht (mehr) hochgeladen werden, die Seite Hilfe:Audio habe ich soeben aktualisiert.

OGG kann seit einigen Wochen direkt im Browser abgespielt werden. Auch hierzu habe ich die o.g. Hilfeseite aktualisiert

„WP muss von jedem Standardrechner nutzbar sein“ Das ist sie auch. Zur Philosophie der Wikimedia Foundation gehört jedoch auch, dass nur freie Software und freie Formate unterstützt werden. Daher wird es auch in Zukunft kein WAV, MP3 u.a. Formate geben. Der vor kurzem hinzugekommene Online-Java-Player behebt jedoch alle Probleme beim Abspielen von Audio- und Videodateien.

„… ein Script schreiben, das hochzuladende Dateien automatisch prüft und in ein entsprechendes Format wandelt?“ Ist bereits in Arbeit, ich weiß nur leider auch nicht, wann es fertig sein wird.

— Raymond ^{Disk. Bew.} 16:08, 19. Nov. 2007 (CET)

Super, herzlichen Dank! --Markus 14:09, 24. Nov. 2007 (CET)

Indizierung von Benutzer- und Diskussionsseiten durch Suchmaschinen

Einiges was in Wikipedia schief läuft, lässt sich mit dem hohen Suchmaschinenranking von Wikipedia erklären. So werden beispielsweise Benutzerseiten regelmäßig dazu genutzt, Werbung durch SEO zu betreiben. Auch andere negative Effekte werden dadurch ausgelöst: Gespräche auf Diskussionsseiten und persönliche Informationen (nicht zuletzt auch Babels) können über Suchmaschinen leicht gefunden werden, manchmal nur zum Ärger der Editierenden (insbesondere durch den Privatsphäreverlust), noch öfter aber zum Nachteil für das Image von Wikipedia. Eine Verbesserung wäre ganz einfach: Über entsprechende Metatags könnte es Suchmaschinen verboten werden, Benutzerseiten und Diskussionsseiten (sowie deren Unterseiten) zu indizieren. Technisch bedeutet das nur minimalsten Aufwand. Zum Teil machen wir das ja soweit ich weiß auch schon. Wenn dies prinzipiell auf alle nicht-redaktionellen Seiten ausgedehnt würde (also alle Seiten außerhalb des Artikelsnamensraums, evtl. Portalen, etc.), wäre dadurch meines Erachtens viel gewonnen. VG ISBN 19:03, 23. Nov. 2007 (CET)

Du sprichst mir aus dem Herzen. (Zustimmung!) Ich habe kürzlich mal eine von mir zu Arbeitszwecken auf meinen Benutzerseiten angelegte Linksammlung an dritter Stelle oder so unter zig oder Hunderten von Google-Treffern gefunden. -- Lückenlos^wecken! 23:40, 23. Nov. 2007 (CET)

Datenschutz wird auf Benutzerseiten und Diskussionsseiten auf WP völlig missachtet. Ich habe schon mehrfach auf diesen Missstand hingewiesen, zuletzt im Oktober 2007. Benutzerseiten und Diskussionen müssen dringend für die Suchmaschinen gesperrt werden! Es kann doch nicht sein, dass alle sich hinter Pseudonymen verstecken müssen bzw. durch den mangelnden Datenschutz quasi dazu gezwungen sind.

Wegen der basisdemokratischen Struktut der WP wurde von Bdk ein Meinungsbild vorgeschlagen, das Hans Koberger umsetzen wollte. Aber selbst dieses wurde von erfahrenen Wikipedianern abgelehnt (alles Pseudonyme). Die Begründungen waren z.T. recht unverständige. Es gibt aber absolut keinen Grund, nicht schon jetzt wenigstens das heute Machbare umzusetzen und für die Zukunft sichere Lösungen zu entwickeln. - Grundsätzlich meine ich, dass so grundlegende Dinge wie das Recht auf Datenschutz nicht "diskutiert" werden kann. Auch nicht in WP.

Für die Diskussionsseiten wurde dies bereits im Juni 2006 verwirklicht. Gruss, --Markus 11:47, 24. Nov. 2007 (CET)

Diskussionseiten sollten schon von der Indexierung ausgenommen sein. Wenn man sich die zugehörige Seite anschaut, wüsste ich nicht wo das stehen sollte. Aber das ist ja nur die Technische Frage, hab damit nicht viel zutuen. Aber eine Indexierung der Benutzerseiten sollte verboten werden. Auch schon wegen der Anonymität oder der Werbung die somit auch sichtbar ist. Auch ist der Benutzernamensraum nur ein Arbeitsbereich und wer lässt sich schon in seiner Arbeit fuschen oder auch in seine Arbeit gucken? Der Umherirrende 12:10, 24. Nov. 2007 (CET)

Verstehe ich Dich richtig: das Meinungsbild vom Juni 2006 wurde nicht umgesetzt?
falls ich das richtig verstanden habe: was ist zu tun?

Auf Wikipedia.org/robots.txt habe ich ja leider keinen Zugriff. Wer sind da die Verantwortlichen?

Gruss, --Markus 12:35, 24. Nov. 2007 (CET)

FreeMind Viewer-Extension

Für den Entwurf der Artikelstruktur von Artikeln und zur Abstimmung dieser Struktur mit anderen Autoren habe ich gute Erfahrungen mit Mindmaps gemacht. Mit FreeMind gibt es ein freies Tool zur Erstellung von Mindmaps, zur Darstellung in MediaWiki-basierten Wikis (wie z.B. der Wikipedia) gibt es sogar eine Viewer-Extension.

Ich fände es sinnvoll, wenn die FreeMind Viewer-Extension in der Wikipedia verfügbar wäre.--Belsazar 09:45, 24. Nov. 2007 (CET)

Mal abgesehen davon, das ich Mindmaps nicht als unbedingt notwendig empfinde, da ich aus diesen bisher kaum einen Nutzen ziehen konnte, werden die Maps hier als Flash eingebunden. Da es nicht für alle Plattformen einen freien Flashplayer gibt, wäre ich gegen eine direkte Einbettung. Würden diese Mindmaps allerdings von der Wikisoftware unterstützt werden, indem sie z.B. als PNG mit Imagemaps eingebunden würden, dann wäre technisch nichts einzuwenden. Allerdings fehlt mir immer noch eine gute Begründung, wo Mindmaps unbedingt gebraucht werden, bzw. wünschenswert sind. --Niabot (Diskussion) 12:06, 24. Nov. 2007 (CET)

Mindmaps können ganz allgemein als Werkzeug zur Strukturierung von Themen verwendet werden. Ich denke hier konkret an den Einsatz bei der Abstimmung der Struktur neuer Artikel oder bei der Neustrukturierung existierender Artikel. Insbesondere bei komplexen Themen kann man mit der Methode effizient die einzelnen Aspekte erfassen, strukturieren und in anschaulicher Weise dokumentieren. Der Vorteil käme insbesondere dann zum Tragen, wenn auch andere die Mindmap verwenden und ändern können. Daher ist es mit der grafischen Darstellung alleine nicht getan (das würde je bereits mit den heute vorhandenen Mitteln gehen), sondern es müsste eine gemeinsame Arbeit an der Mindmap möglich sein. Bei FreeMind ist das so gelöst, dass einfach die Source (".mm"-File) in dem Wiki gespeichert wird. Der Viewer erlaubt dann die Betrachtung auf den (Diskussions-)Seiten. Zum Thema "Plattformunabhängigkeit": Die Mindmaps können wahlweise über einen Flash-basierten Viewer oder als Applet dargestellt werden, damit dürfte eine weitgehende Plattformunabhängigkeit gewährleistet sein. Der Umsetzungsaufwand wäre m.E. gering, da es ja die erforderlichen MediaWiki-extensions bereits gibt (siehe o.g. Links) - sie müssen nur aktiviert werden.--Belsazar 15:18, 24. Nov. 2007 (CET)

Da die Dateien aber ständig neu hochgeladen werden müssen, existiert im Endeffekt ja doch kein richtiges Versionssystem. So können z.B. 2 gleichzeitig hochgeladene Dateien kollidieren. Und dann ist es durchaus nicht einfach möglich die Änderungen zu verschmelzen, bzw. überhaupt festzustellen, ob dies passiert ist. Besser wäre hier doch ein auf Ajax basierendes System, das die Änderungen als Syntax in den Quelltext der Seite schreibt. Sollten sich Mindmpas wirklich als sinnvoll erweisen, dann könnte man diese Datei doch als Download anbieten und eine daraus erzeugte Grafik anzeigen. Für Gruppenarbeit ist die bisherige Erweiterung jedenfalls noch nicht wirklich tauglich. Hier müsste es dann auch einen entsprechenden Editor mitbringen oder Quelltexte interpretieren können. Derzeit geht der Wert kaum über ein Bild hinaus. Strukturen kann man aber auch sehr Anschaulich mit Hilfe von Überschriften abstrahieren. Versteh mich nicht falsch, ich bin für Neuerungen. Allerdings sollten die etwas ausgereifter sein. --Niabot (Diskussion) 16:04, 24. Nov. 2007 (CET) PS: Ich habe mit dem Programm auch schon gearbeitet, aber ohne Online-Dateiveränderung sehe ich hier wenig Nutzen.

Du hast schon recht, die konsequente Lösung wäre ein integrierter GUI-basierter Editor. Das ganze könnte vom "Look and Feel" z.B. ungefähr so aussehen, wobei man dann natürlich auch Funktionalität zur Änderung der Struktur, zum Editieren der Texte und zur Anzeige von Änderungen bereitstellen müsste. Der "Mindmap-Editor" wäre dann nur ein optionales Frontend, die Sourcecode-Syntax (=Wiki-Quelltext) und die Versionierung würden dem heutigen System entsprechen.

-Ehe wir hier Dinge diskutieren, die bereits längst ausdiskutiert und entschieden sind: Das Thema "GUI-basierte Oberfläche" dürfte doch schon an anderer Stelle ausführlichst diskutiert worden sein, oder?--Belsazar 00:11, 25. Nov. 2007 (CET)

Anpassbarer Rahmen um Bilder

Bei Bilder gibt es bei MediaWiki den Parameter border, mit dem um das Bild ein Rahmen gemacht werden kann: . Bei der Transformation in XHTML wird dem Element img folgendes ergänzt: class="thumbborder". Die CSS-Klasse ist in main.css definiert als img.thumbborder { border: 1px solid #DDDDDD }.

Wie wäre es, wenn der Rahmen anpassbar wäre?

• alt: [[Bild:Beispiel.png]] ergibt <img … />
• alt: [[Bild:Beispiel.png|border]] ergibt <img class="thumbborder" … />
• neu: [[Bild:Beispiel.png|border=2px red]] ergibt <img class="thumbborder" style="border:2px red" … />

Sinnvolles Anwendungsgebiet sehe ich bei Flaggen. Flaggen haben häufig weiße Ränder, die durch einen Rahmen abgegrenzt werden müssen. Ein mit border eingefügter Rahmen verbreitert aber das Bild um zwei Pixel, was bei Listen störend ist. Es muss also eine einheitliche Breite für alle Flaggen eingestellt werden. Alle Flaggen mit einem Rahmen zu versehen wäre unschön, da der Rahmen nur bei Flaggen mit weißen Rändern benötigt wird. Flaggen mit Rahmen um zwei Pixel zu verkleinern, würde die Flaggen unterschiedlich groß machen und dadurch verzerren. Ideale Lösung wären transparente Rahmen. Mit obiger Erweiterung von MediaWiki könnte folgendes gemacht werden, ohne dass um die Deutschlandflagge ein Rahmen wäre und trotzdem alle Flaggen gleich breit wären:

• [[Bild:Flag of Slovakia.svg|border|18px|Slowakei]]
• [[Bild:Flag of Germany.svg|border=transparent|18px|Deutschland]]

Für diese Erweiterung gibt es sicherlich noch viele andere geeignete Anwendungsgebiete. --Fomafix 15:42, 30. Nov. 2007 (CET)

Dem steht im Moment wohl phab:T2689 (Bugzilla:689) entgegen. Wenn das dort umgesetzt werden würde, würde das Erweitern der Datei:...-Funktionalität wesentlich einfacher werden. --Revolus Echo der Stille 13:20, 3. Dez. 2007 (CET)

Ein transparenten Rahmen um Bilder lässt sich auf folgendermaßen erzeugen: (Siehe: Wikipedia Diskussion:Ländervorlagen mit Flagge#border)

• Mit Rand: [[Bild:Flag of Slovakia.svg|18px|border|Slowakei]]
• Mit transparentem Rand: <span style="padding:1px">[[Bild:Flag of Germany.svg|18px|Deutschland]]</span>

Für Flaggen ist daher keine MediaWiki-Erweiterung notwendig. --Fomafix 12:23, 6. Dez. 2007 (CET)

Verweis von deutschen Artikeln auf den englischen Artikel mit wordcount

Parallel zu den Links "Andere Sprachen", welcher den user auch zum englischsprachigen (und oft ausführlicheren) Artikel weiterleited, wäre ein direkter Hinweis, in dem man den wordcount des englischen (und somit wichtigsten) Artikels im Vergleich zum deutschen Artikel sieht, hilfreich.

D.h. wenn ein user einen deutschen Artikel liest, der eventuell sehr knapp und nicht ausreichend ist, könnte er gleich (eventuell am oberen Rand des Artikels in einem kleinen Infokasten) sehen, ob der englische Schwesterartikel ausführlicher ist und wird somit vielleicht eher dazu veranlasst weiter zu gehen und den englischen Artikel lesen und sich somit weiter zu informieren.

Der Link "English" verweist zwar auf diesen Schwesterartikel, allerdings werden relativ wenig user diesen Weg häufig gehen - würde hier allerding im deutschen Artikel ein auffälliger Hinweis auf das Volumen des englischen Artikels (verglichen mit dem Volumen des deutschen Artikels) vorhanden sein, würden wahrscheinlich mehr user diesen Weg gehen. (Der vorstehende, nicht signierte Beitrag stammt von UdoRudolph (Diskussion • Beiträge) 02:31, 8. Dez. 2007) Revolus Echo der Stille

Davon halte ich ehrlichgesagt sehr wenig. Erstens würde das die deutsche Wikipedia zur einer Version zweiter Klasse dekradieren, bei der man sich deshalb gar nicht beteiligen sollte; zweitens können wohl die meisten, die hier reinschauen, wohl die deutsche Sprache besser als die englische oder wissen zumindest was mit Andere Sprachen gemeint ist; und drittens ist oft nur die Quantität der englischen Artikel, jedoch trifft das leider für die Qualität nur sehr selten zu. --Revolus Echo der Stille 04:03, 8. Dez. 2007 (CET)

Automatische Überschriftennumerierung fallweise ausschalten

Ich habe in meinen Einstellungen "Überschriften automatisch nummerieren" aktiviert, um bei längeren Artikeln den Überblick zu behalten :-). Leider werden auch beispielsweise in dem Portal:Griechenland die Überschriften numeriert, was nicht nur überflüssig ist, sondern auch das Layout leider etwas durcheinander bringt ("Soziales // 13 * [Bearbeiten] // Hilfsorganisation ESEPA"). Ich fände es daher wünschenswert, die automatische Numerierung:

• in den Benutzereinstellungen für alle Artikel in dem Portal-Namensraum unterbinden oder
• per Quelltext-Befehl seitenweise ausschalten

zu können. Tim Landscheidt 14:30, 10. Dez. 2007 (CET)

Wenn die Überschriftennummern mit einer CSS-Klasse versehen wären, könnte ausblenden Namensraumspezifisch per CSS geschehen. Derzeit erzeugt MediaWiki

<h4><span class="mw-headline">13 *</span>…</h4>

Wenn stattdessen

<h4><span class="mw-headline"><span class="mw-headlinenumber">13 </span>*</span>…</h4>

erzeugt würde, könnte die Überschriftennummern im Portalnamensraum mit folgender CSS-Anweisung unterdrückt werden: --Fomafix 14:58, 10. Dez. 2007 (CET)

.ns-100 .mw-headlinenumber { display:none }

Nebenbei würde sich damit auch ein größerer Abstand zwischen Überschriftennummer und Überschriftentext wie im Inhaltsverzeichnis aktivieren lassen: --Fomafix 16:31, 10. Dez. 2007 (CET)

.mw-headlinenumber { margin-right:0.3em }

Kontextbezogene Hinweise beim Bearbeiten von Artikeln

Meiner Meinung ist die Hauptursache, dass beispielsweise unrelevante Weblinks oder Literaturangaben falsch hinzugefügt werden, dass die Benutzer die entsprechende Richtlinien nicht kennen. Gerade Benutzer, die äußerst selten oder zum ersten Mal in Wikipedia bearbeiten, finden sich aufgrund der vielen Meta-Seiten nicht zurecht, oder ahnen nicht, dass es Richtlinien gibt, die beachtet werden müssen. Um nun möglichst kontextbezogene Hilfe anzubieten, die auch sofort gesehen und somit auch eher beachtet wird würde ich folgendes Vorschlagen: Wenn man beispielsweise auf den Bearbeiten-Link von Weblinks klickt wird automatisch ein Balken eingeblendet, der darauf hinweist, wo die Richtlinien-Seite, sowie technische Hilfe zu finden ist, ähnlich der Warnung wenn man unangemeldet bearbeitet. Man könnte zum Beispiel in einer MediaWiki-Seite festlegen bei welchem Abschnitt, welche Vorlage eingebelndet wird. Beispielsweise so:

Weblinks|Vorlage:WissenswertesWeblinks Literatur|Vorlage:WissenswertesLiteratur Siehe auch|Vorlage:WissenswertesAssoziativeVerweise

Wenn dieser Vorschlag auf Zustimmung stößt, müßte man eine entsprechende Bugmeldung schreiben. --Eneas 16:06, 16. Dez. 2007 (CET)

Hab ich auf einem anderen so Wiki implementiert: MediaWiki:Previewnote enthält {{Editarticle NS {{#ifexist: Vorlage:Editarticle NS {{NAMESPACE}} | {{NAMESPACE}} }} }}

Vorlage:Editarticle NS enthält hält dann Hinweise für den Artikelnamensraum und alle nicht speziell angepassten Namensräume, Vorlage:Editarticle NS Hilfe ist der Hilfe-Namensraum, Vorlage:Editsarticle NS Benutzer Diskussion die Benutzer-Disk...

Mit z.B. {{#ifeq:{{SUBJECTSPACEE}}|{{NAMESPACEE}|Artikelseite|Diskussionsseite}} oder {{#ifexist:{{FULLPAGENAME}}}} kann man auch noch spezielle Weichen in die Editarticle_NS einbauen. --Revolus Echo der Stille 23:23, 17. Dez. 2007 (CET)

Ich wollte die vorgeschlagenen Vorlagen abhängig von der Überschrift des Absatzes machen und nicht vom Namensraum. Wenn man den Abschnitt Weblinks bearbeitet soll ein anderer Hinweis kommen, als bei der Bearbeitung vom Abschnitt Literatur. Bei der Überschrift „Allgemeines“ kommt nach meinem Beispiel keine Vorlage mit zusätzlichen Hinweisen zum Vorschein. --Eneas 11:09, 18. Dez. 2007 (CET)

"Nicht beobachten"-Button auf der Beobachtungsliste

Ich hätter gern einen kleinen unscheinbaren "Nicht beaobachten" Button zu jedem angezeigten Eintrag auf er Seite "Beobachtungsliste", um einen uninteressanten Einrag schnell und einfach aus der Liste der zu beobachtenden Seiten zu entfernen. -- Sulai 03:07, 21. Dez. 2007 (CET)

Versionsvergleich: in den Artikel springen

Beim Versionsvergleich: per javascript bei Klick auf Vergleichsblock oder per Anker-Link in den entsprechenden Bereich des Artikels springen. Die Zeilenangaben sind meist eine nutzloser Hinweis. -- Sulai 03:07, 21. Dez. 2007 (CET)

Benachrichtigung bei Änderung eines Absatzes

Auswahl beim Editieren von Absätzen: "benachrichtigen bei Änderung des Blockes". Dies soll die Anzeige eines Hinweisblockes wie bei der Benutzerdiskussionsseiten-Benachrichtigung bewirken, sobald ein edit in dem entsprechenden Abschnitt vorgenommen wurde.

• Diskussionspartner kann schneller reagieren
• Vorteil bei sehr großen oft bearbeiteten Diskussionsseiten
• wenn eine lang vergessene Diskussion wieder aufgenommen wird

Ähnlicher Feature-Wunsch: #Autosave, Abschnitt-Versionen, Abschnitt-Beobachtung -- Sulai 03:07, 21. Dez. 2007 (CET)

Spezial:Nicht kategorisierte Dateien

Die Spezialseite Spezial:Nicht kategorisierte Dateien sollte nur lokale Bilder zeigen, die keine Kategorie haben. Derzeit werden alle Bildbeschreibungsseiten gelistet, die keine Kategorie haben, darunter auch Beschreibungen für Commonsbilder, oder {{Geschützt-Ungeklärt}} und {{Geschützt}}. Es wäre aber sinnvoller nur die lokalen Bilder zu zeigen, welche keine Kategorie haben. So kann man Bilder finden, die keinen Lizenzbaustein haben, da diese oft in keiner Kategorie sind. Ich habe auf bugzilla nichts gefunden. Wenn es keinen entsprechenden Bug gibt, kann gerne einer aufgemacht werden. Ich hoffe ich bin hier an der richtigen Adresse. Der Umherirrende 18:35, 27. Dez. 2007 (CET)

Zusätzliche Zustimmung der GFDL via Kästchen

Es kommt immer mal wieder in Diskussionen zum Vorschein, dass Artikelautoren (natürlich meistens unerfahrene) meinen, sie haben das alleinige Recht über den Inhalt "ihrer" Artikel. Dies resultiert daraus, dass vielen - auch wenn es über dem "Speichern"-Button vermerkt ist - gar nicht klar ist, unter welcher Lizenz sie ihren Artikeln veröffentlichen bzw. was deren Inhalt in etwa aussagt. Wäre es deswegen nicht sinnvoll, ein "Kästchen" einzurichten, das man zuerst ankreuzen muss, bevor man die Seite speichern kann, mit dem man versichert, dass man sich darüber im Klaren ist, unter welcher Lizenz das Selbstverfasste stehen wird? Angemeldete Benutzer sollten in den Optionen diese Funktion aber ausschalten können, bzw. automatisch ankreuzen lassen (also das Selbe wie bei kleinen Änderungen und automatisches Hinzufügen auf die Beobachtungsliste), ansonsten könnte sowas sicherlich nervig sein, wenn man viele kleinere Edits am Tag betätigt. 83.76.179.197 21:51, 8. Sep. 2007 (CEST)

Meines Erachtens gute Idee! Dann könnte man nämlich auch optional in einem zweiten Kästchen unter Creative Commons-Lizenz was ankreuzen (Es gibt ja Benutzer, die doppelt lizenzieren). Außerdem beschweren sich auch einige über die GFDL-Lizenz, da sie für Artikel eher ungeeignet sei; langfristig wäre das eine Möglichkeit, auf eine andere Lizenz umzusteigen. (?) --Versusray | Diskutiere mich | Bewerte Mich 22:09, 8. Sep. 2007 (CEST)

Meiner Meinung nach kann niemand, sich darüber im klaren sein, weil es nicht klar ist. Ansonsten sinnvoll, allerdings sollten in dem Zusammenhang auch die rechtlichen Folgen gekläert werden und - wer weiss wie lange die GFLD noch relevant für die Wikipedia ist. --Diwas 03:38, 10. Sep. 2007 (CEST)

Denkt bitte an die Leute die hier viel abarbeiten etc. und somit sehr viele Seiten editieren. Für die wäre ein solches Häckchen der absolute Horror. jodo 16:50, 31. Jan. 2008 (CET)

Dagegen. Über dem Speichern steht: "...und willige ein, ihn unter der GNU-Lizenz für freie Dokumentation zu veröffentlichen." Das sollte reichen. Es gibt auch viele aus anderen Wikipedias, die hier einfach nur Interwikilinks setzen, dennen sollte man keine weiteren Steine in den Weg legen. Und deutscher Alleingang erscheint mir nicht sinnvoll, da es kein deutsches Problem ist. --Kolossos 21:12, 31. Jan. 2008 (CET)

Zumindest sollte folgender Text optisch unmittelbar mit dem Speicherbutton verbunden werden: Ich versichere hiermit, dass ich den Beitrag selbst verfasst habe bzw. dass er keine fremden Rechte verletzt, und willige ein, ihn unter der GNU-Lizenz für freie Dokumentation zu veröffentlichen. Mir ist bekannt, dass ihn jeder unverändert oder verändert, auch kommerziell veröffentlichen darf, wenn dabei die Lizenzbestimmungen erfüllt werden. --Diwas 18:32, 1. Feb. 2008 (CET)

Was du schreibst ist eine Interpretation der GDFL. Wie die GDFL rechtlich zu interpretieren ist kann nur ein Anwalt sagen. Deswegen dagegen. jodo 19:16, 1. Feb. 2008 (CET)

Könnte es da irgendwelche Zweifel geben? Mir ist ja einiges zweifelhaft an der Lizenz aber das? --Diwas 03:00, 2. Feb. 2008 (CET)

Warscheinlich nicht. Also wirklich zu 99% warscheinlich. Jedoch sind wir m.E. auf der sichereren Seite wenn wir gar nicht erst anfangen die GDFL teilweise zu interpretieren. Besonders wirst du (weil die Zustimmung ja kurz sein muss) immer nur Teilaspekte der Lizenz erfassen können. Auch das könnte ev. negativ ausgelegt werden. Also ich bin rechtlich Laie, könnte mir aber vorstellen, dass solche geringfügigen Änderungen rechtlich große Konsequenzen nach sich ziehen können. jodo 14:14, 2. Feb. 2008 (CET)

Kurze Artikel II

Bei den allgemeinen Verbesserungsvorschlägen hatte ich schon vorgeschlagen, Falschschreibungshinweise und Begriffsklärungen aus der Spezialseite der kürzesten Artikel zu entfernen. Durch die benutzte Vorlage:Falschschreibung oder Vorlage:Begriffsklärung müsste das doch möglich sein, oder? --Ephraim33 18:03, 14. Mai 2007 (CEST)

Der Vorschlag ist gut. Über dieses Problem habe ich mich selber schon oft geärgert. SD1990 18:46, 18. Feb. 2008 (CET)

Text von Einzelnachweisen erst am Ende des Artikels definieren

Wenn ein Artikel viele Einzelnachweise enthält, wird der Quelltext schnell unübersichtlich. Ich habe schon von verschieden Benutzern den Wunsch gehört den Einzelnachweistext erst am Ende des Artikels zu definieren und vorne nur eine Referenz anzugeben. Das ist im Prinzip auch jetz schon möglich.(siehe Beispiel [3]) Allerdings wird dann ungewollterweise ein zusätzlicher link erzeugt. Also z.B ein (a,b) obwohl es ein einfacher Einzelnachweis ist. Kann man das nicht abstellen? Ich fände eine funktionierende Variante sehr nützlich. Also konkret: Mit einem Befehl wie <refdef name="Quelle A">Fußnotentext</refdef> sollte ein Einzelnachweis definiert werden. Die Stelle an der er im Text auftaucht sollte weiter mit <ref name="Quelle A"/> festgelegt werden. Die bisherige Angabe von Einzelnachweisen soll natürlich weiter durch die Software unterstützt werden. Gruß Stefanwege 22:11, 14. Jun. 2007 (CEST)

kann ich nur beipflichten: dann könnte man sie nämlich auch kapitelweise definieren, und bei allfälligem überarbeiten oder auslagern eines abschnitts in einen anderen artikels mitnehmen. oder ein unter #Literatur angegebenes werk in bezug auf einen abschnitt dort genauer angeben, etwa mit Autor, Datum, Kapitel sowieso, S. 111ff - guter kompromiss zwischen einzelbeleg und "hauptquelle".. -- W!B: 19:40, 15. Jun. 2007 (CEST)

•1• EN werden jetzt schon zwangsläufig kapitelweise definiert, oder bezieht sich kapitelweise auf die Quelle?

•2• Mitnehmen kann Mensch EN mitsamt Fließtext doch jetzt schon, oder wie ist das mit „auslagern/mitnehmen“ gemeint?

•3• „oder … in bezug auf einen abschnitt dort genauer angeben …“ verstehe ich leider überhaupt nicht. --ParaDox 06:21, 14. Feb. 2008 (CET)

•1• Ich verstehe nicht, weshalb das »siehe Beispiel [4]« hier als Beispiel gut sein soll, erst recht nicht, wenn ich mir dort den Quelltext ansehe.

•2• „den Einzelnachweistext erst am Ende des Artikels zu definieren und vorne nur eine Referenz anzugeben“ hat auch den Nachteil, dass solche EN beim hinzufügen/entfernen die abschnittsweise Bearbeitung (&action=edit&section=n) verhindern würden: Es müsste dann sehr viel häufiger der ganze Artikel bearbeitet werden.

•3• MMn könnte/sollte in diesen Feature-Request auch noch das dort integriert werden. --ParaDox 06:21, 14. Feb. 2008 (CET)

Man könnte es auch mit dem Feature der Möglichkeit einer verschachtelten Referenzierung kombinieren, siehe hier. --Carolin 11:09, 2. Mär. 2008 (CET)

Assoziationsvorschläge und Schnittmengensuche

könnte man nicht, ähnlich wie bei amazon, eine Funktion einbauen ala ?wenn sie das hier mögen, könnte ihnen auch das hier gefallen? Eine Assoziationsfunktion auf Grundlage der bisherigen Seitenaufrufe bisheriger Nutzer?

und noch einen: Gibt es eine Möglichkeit die Suche auf eine Untergruppe einzuschränken? Was großartig wäre, wenn man irgendwie aus Gruppen Schnittmengen bilden könnte: Beispielsweise: Suchbegriff: "Daniel"...zeige alle gemeinsamen Artikel der Gruppe: Drogendealer und Schauspieler. Das wäre doch was. (nicht signierter Beitrag von 217.186.122.33 (Diskussion | Beiträge) 11:06, 11. Feb. 2007 (CET))

Spezialseite:Anzeigen von Einleitungen

Die folgende Anfrage ist bereits mit einigen Benutzern diskutiert und wäre nach überwiegender Auffassung eine brauchbare Verbesserung, die sich auch umsetzen lassen könnte.

Konzept

Gesucht wird eine Spezialseiten-Funktion, die die Einleitungen aller Artikel einer Kategorie auf einer zu generierenden Seite anzeigen kann. Dabei sollen druckbare Seiten (Druckvorlage) entstehen, die wie die Seiten einer herkömmlichen Enzyklopädie aussehen und z.B. zu Readern oder Büchern gebunden werden können.

• das Skript sollte erkennen, wo die Einleitung beginnt und aufhört
• es sollte Vorlagen, Tabellen und andere Quelltextbestandteile vor dem Beginn des ersten Abschnitts ausklammern können
• wenn Bilder in der Druckvorlage gewünscht sind (selten), könnten diese vielleicht im Quelltext entspechend markiert werden, damit sie vom Skript erkannt werden
• auf der Druckvorlage zwei Spalten pro Seite, der Text formatiert

Weitere Bemerkungen

• Anders als für den Artikelkörper, für den ausführliche und umfassende Inhalte erwünscht sind, sollen die Einleitungen das Lemma und den Artikelinhalt kurz, aber möglichst vollständig erlären.Wikipedia:Wie_schreibe_ich_gute_Artikel#Begriffsdefinition_und_Einleitung Damit liegt ein brauchbarer Text, allerdings mit geringerer Ausführlichkeit vor. Vermutlich wird deshalb eine Begrenzung aller Einleitung auf eine noch zu diskutierende Zeichenzahl wünschenswert sein. Artikeleinleitungen, die diese Begrenzung überschreiten, könnten in der Druckvorlage ausgespart oder stilistisch umgestaltet und komprimiert werden, damit die Spezialseite auch diese Artikel in das Druckbild integrieren kann.

Anwendungen

• Überall dort, wo kurze Artikel ausgedruckt werden sollen.
• Überall dort, wo Einleitungen der Reihe nach abgearbeitet werden sollen.
• Erstellung von Übersichten, um die Qualität der Einleitungen vieler Artikel beurteilen, verbessern und stilistisch und formal vereinheitlichen zu können.

Diskussion und Vorschläge

Bei der Realisierung der Idee werden wahrscheinlich noch einige konzeptionelle Probleme auftreten. Bitte beteiligt euch, indem ihr sie nennt. -- Carl 23:56, 29. Okt. 2007 (CET)

Probleme dürfte es vor allem mit Templates geben: einige will man ausfiltern (z.B. Taxoboxen, Neutralitätswarnungen, etc), andere will man auflösen (z.B. Lautschrift). Ansonsten wäre zu überlegen, ob man wirklich immer den ganzen abschnitt bis zur ersten Überschrift haben will, oder ob nicht auch der erste Absatz reicht - oder gar der erste Satz. Evtl sollte das Tool flexibel genug sein, das als Option anzubieten.

Ganz praktisch ist eine Umsetzung als Spezialseite wohl nicht möglich - das laden und auswerten aller Artikel einer Kategorie dauert einfach zu lange, um das "dynamisch" machen zu können. Als Tool das auf einem Dump arbeitet (oder auf der Datenbankkopie auf dem Toolserver), und alle paar Wochen solche Auszüge für eine Kategorie (oder auch alle Artikel) erstellt, wäre durchaus machbar. Ich würde das evtl sogar machen, aber erst in ein paar Monaten. -- Duesentrieb ⇌ 00:06, 30. Okt. 2007 (CET)

Gute Idee, dann könnten andere Webseiten(z.B. Google) Kurzdefinitionen anzeigen. Die Einleitung sollte man mit <def> </def> auszeichnen. mfg --Uranus95 16:53, 19. Jan. 2009 (CET)

Ich denke, das ist mit Wikipedia:Helferlein/Navigation-Popups auch gut zu lösen. Der Umherirrende 18:14, 7. Feb. 2009 (CET)

---