Wikiup:Verbesserungsvorschläge/Archiv/2012/Februar

aus Wikipedia, der freien Enzyklopädie

Artikelprojektseite

Es gibt ja doch den ein oder anderen Autor, der sich größere Artikel, Artikelkomplexe, Liste etc. vornehmen will. Leider mache ich die Erfahrung, das ich da trotz mühsamen Anschreibens mitunter mehrerer Portale wenig Rückmeldung hinsichtlich Mitarbeit bekomme. Manche Themen sind ja portalübergreifend. Im Sinne einer Ressourcenvernetzung fände ich eine Vorstellungsseite ganz gut, wo man Artikelprojekte vorstellt und sich interessierte Mitstreiter melden können. Durch die Portale usw. ist das alles sehr dezentral, man sieht kaum noch, an was andere so basteln. Es würde zudem mitunter auch Kräfte schonen, wenn man sieht, huch, da arbeitet schon einer dran. Das das ein Maß an Offenheit, Aufeinanderzugehen usw. bedeutet, ist mir klar. Wenn ich aber die letzten Metadiskussionen so überfliege, beschäftigt sich WP immer mehr mit sich selbst bzw. gefallen sich gefühlt immer mehr darin, mehr zu labern statt Artikelarbeit zu leisten. Vielleicht hilft so eine Koordinierungsseite, den Blick mal wieder bissl in die richtige Richtung zu schärfen. Wie man das Ding dann nennt, ist mir fast wurscht, ich bin bloß manchmal des alleine rumwurschtelns sehr überdrüssig.--scif 00:36, 8. Feb. 2012 (CET)

Ich denke, du wirst am besten fahren, wenn du dir ein thematisch passendes Portal oder Projekt suchst. Es gibt auch übergreifende, allen voran die allgemeine QS. Mit der Eröffnung eines neuen Projekts hättest du ja nichts gewonnen, dort wärst du auch allein. --TMg 21:04, 9. Feb. 2012 (CET)
DA reden wir grob aneinander vorbei. Ich bin in zwei Projekten drin. DAs ist trotzdem keine Garantie für Rückmeldungen etc. Außerdem schlagen dort immer die selben auf, und je nach Disk-Kultur werden Neulinge auch abgeschreckt. Warum kann es keine neutrale Anlaufstelle geben, wo ich einen Gesamtüberblick habe, was einzelne Autoren so vorhaben? So könnte auch effizienter Literatur genutzt werden. Kaum einer hat doch nur eindimensoniale Interessengebiete. Außerdem, das kennen viele Autoren, fällt bei Recherchen immer mal bissl Beifang ab. Hab ich sone Übersicht, finde ich vielleicht zügig jemanden, dem das nützt.--scif 22:52, 9. Feb. 2012 (CET)

Vector-Bearbeitungsleiste auch für rekonq

Hallo, ich benutze unter KDE den Browser rekonq 0.8.1 und sehe in der Wikipedia leider nur die alten und nicht die neuen Vector-Skin Hilfe:Symbolleisten. Wenn ich die Browserkennung auf Chromium umstelle sehe ich sie plötzlich und alles funktioniert wie unter Firefox also müsste wohl hier ein Schalter umgelegt werden. Gruß Matthias 13:40, 27. Feb. 2012 (CET)

Gib mal mit normaler Browserkennung javascript:alert(navigator.userAgent) in die Adressleiste ein, und sag, was dabei angezeigt wird. --Schnark 09:14, 28. Feb. 2012 (CET)
Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.34 (KHTML, like Gecko) rekonq Safari/534.34

Gruß Matthias (Diskussion) 10:16, 3. Mär. 2012 (CET)

bugzilla:34924 --Schnark 11:17, 3. Mär. 2012 (CET)
Kannst du auf einem Wiki, das die aktuelle Entwickler-Version verwendet ([1], [2]) testen, ob es funktioniert? --Schnark 12:09, 6. Mär. 2012 (CET)
http://translatewiki.net funktioniert mit rekonq 0.9.0-1. Die Browserkennung ist identisch wobei ich nicht verstehe warum dort "Mozilla" und "like Gecko" erscheint. Der Browser basiert auf QtWebKit. Die Toolbar funktioniert ganz normal. Vielen Dank. Gruß Matthias (Diskussion) 18:32, 6. Mär. 2012 (CET)
Browserkennungen sind eine Wissenschaft für sich, "Mozilla" besagt dabei überhaupt nichts (ich kenne keinen ernstzunehmenden Browser, bei dem das nicht vorkommt). Möglicherweise sind bei der Gelegenheit aber die Tooltips mit den Tastenkürzeln kaputt gegangen. Kannst du (etwa beim Bearbeiten-Reiter) nachprüfen, ob das angezeigte Tastenkürzel mit dem tatsächlich nötigen übereinstimmt (vermutlich wird Alt angezeigt), und falls nicht, sagen, welches das korrekte ist (Strg+Alt wäre meine Vermutung)? --Schnark 09:25, 7. Mär. 2012 (CET)
http://translatewiki.net zeigt Alt + e an und das funktioniert auch. Hier ist es Alt + Shift + e (geht auch). Gruß Matthias (Diskussion) 19:19, 7. Mär. 2012 (CET)
Sehr interessant. Der Bug hat übrigens als Target-Milestone 1.19-Release bekommen, das heißt, dass die Änderung hier womöglich sogar bald live geht. --Schnark 09:20, 8. Mär. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Schnark 09:20, 8. Mär. 2012 (CET)

Benutzerbeiträge

Dort kann man auswählen: "Nur aktuelle Versionen zeigen". Das genaue Gegenteil wäre wichtig, denn was interessieren mich die seit meiner letzten Bearbeitung unveränderten Artikel - völlig uninteressant. Ich will doch ganz im Gegenteil immer nur genau die nachsehen, die danach geändert wurden. Gruß -- Dr.cueppers - Disk. 18:49, 11. Feb. 2012 (CET)

+1 -- Matthias 22:36, 11. Feb. 2012 (CET) --
+1 -- H.Albatros 23:17, 11. Feb. 2012 (CET) --
+1 – Giftpflanze 23:25, 11. Feb. 2012 (CET) wünsch ich mir schon länger.
+1 -- ✓ Bergi 02:46, 12. Feb. 2012 (CET) Habe Bug 34344 angelegt, bis dahin gibt es auch Userscripte (hideduplicates).
Danke dafür. – Giftpflanze 18:26, 12. Feb. 2012 (CET)

Ergänzung CSS

pre-formatierter Text dient sehr oft der Darstellung von Quelltexten. 

Quelltext

Syntaxhervorhebung ist oft erwünscht, 

 .myclass {border: thin solid gold;}

beißt sich jedoch mit <pre>...</pre> 

<syntaxhighlight lang="CSS">
 .myclass {border: thin solid gold;}
</syntaxhighlight>
<pre>
 .myclass {border: thin solid gold;}
</pre>

Mein Vorschlag: Die Formatierungen für pre auch für syntaxhighlight verwenden. Damit es dann so aussehen kann 

.myclass {border: thin solid gold;}


-- Matthias 15:54, 9. Feb. 2012 (CET) --

Volle Zustimmung meinerseits. Ich habe ehrlich gesagt nie verstanden, warum ein reines <syntaxhighlight> einen optisch so schlecht abgesetzten Quelltextblock erzeugt. Auf der anderen Seite ist die Formatierung des <pre> schon wieder einen Tick übertrieben. Achtung: Es gibt <syntaxhighlight> auch inline (var beispiel = "ja";), das darf natürlich keinen Rahmen erhalten. --TMg 20:58, 9. Feb. 2012 (CET)
Ich finde, die meisten Syntaxblöcke sind durch Block+Bunt schon genug abgesetzt. Gerade innerhalb von Threads, etwa Wikipedia:TSW#Script funktioniert nicht überall, stört mich ein pre-Rahmen jetzt schon (vor allem wenn nicht eingerückt), aber alle Code-Absätze mit so etwas aufdringlichem auszustatten fände ich zu viel des Guten.
Ich kann zwar verstehen, dass manche Abschnitte wie einen pre-Rahmen bekommen sollen (und habe selbst schon <div>s so ausgerüstet), bitte aber von einer allgemeinen Veränderung abzusehen. Möglich wäre etwa ein Klasse sourcecode o.ä., die mit den pre-Stilen ausgrüstet wird.
Ein Rahmen wäre auch gar nicht so einfach zu basteln. Geshi hat viele Ausgabeformate (standard: div>pre, inline: span, numeriert: div>ol, .css/.js-Seiten: pre, …), und für div>pre unterdrückt sogar jedes einzelne language-stylesheet die pre-Berahmung, die im skin.css definiert wird. Die vielen Spezialfälle führen keinesfalls zu schönem Code :-( -- ✓ Bergi 00:52, 10. Feb. 2012 (CET)
Der Kern dieser Anfrage ist die Vereinheitlichung. Von mir aus auch mit einem ganz neuen, dezenten Mittelweg. Was spräche dagegen? Oder anders gefragt, welchen konkreten Grund gibt es für die beiden so stark voneinander abweichenden Formatierungen? --TMg 02:09, 18. Feb. 2012 (CET)

Mehr Platz im Versionslöschungsgrund-Feld (mit RevisionDelete)

Moin, wie viele Zeichen passen in das Feld? Ich habe oft Probleme, da den vollständigen Grund bzw. URV-Quelllink unterzubringen. Bei 2 URV-Quelllinks geht's schon gar nicht. Ist das Feld evtl. sogar kleiner als das Zusammenfassungsfeld für normale Beiträge? Es wäre hilfreich, wenn sich entweder durch ein Skript oder durch eine Mediawiki-Änderung die Anzahl der Zeichen erhöhen lassen könnte. Wer weiß Rat? XenonX3 - (☎:✉) 21:52, 15. Feb. 2012 (CET)

100 Zeichen. Ich bat mit bugzilla:34467 darum, das zu erhöhen. In der Zwischenzeit kannst du ja wie ich Web Developer verwenden um die Zeichenbegrenzung abzuschalten und 250 Zeichen dort unterzubringen. --Schnark 11:14, 17. Feb. 2012 (CET)
Das Problem ist aber, das bei Verwendung von einem vordefinierten Grund aus der Drop-Down-Box und einer zusätzlichen Eingabe das Limit nicht so einfach überschaubar ist. Ansonsten ist es 255 Bytes, wie auch bei der Bearbeitenzusammenfassungszeile. Der Umherirrende 16:19, 17. Feb. 2012 (CET)
Man könnte es etwas erweitern, dann ist aber wieder die Gefahr, das Text abgeschnitten und durch … ersetzt wird, was Benutzer auch nicht toll finden: Beispiel. Der Umherirrende 21:11, 17. Feb. 2012 (CET)
Eine Erkennung, ob ein vordefinierter Grund verwendet wird, ist jetzt eingebaut: [3] -- ✓ Bergi 02:35, 18. Feb. 2012 (CET)
Ich habe es mal im Bug ergänzt und mir erlaubt in deinem Link das Protokoll hinzuzufügen, da https für wmflabs zwar schon seit Ewigkeiten angekündigt wird, aber noch immer nicht funktioniert. --Schnark 09:35, 18. Feb. 2012 (CET)
Danke, das zweite Argument geht aber erst ab MediaWiki 1.19. Also für die vollständige Lauffähigkeit des Skripts müsste man sich noch zwei Wochen gedulden. Der Umherirrende 11:31, 18. Feb. 2012 (CET)

Zusammenfassung

Üblicherweise wird zum Bearbeiten eines Absatzes diese Überschrift in die Zusammefassungszeile /*Überschrift 1*/ gesetzt. Auch wenn man einen neuen Absatz mit Überschrift beginnt bleibt das /*Überschrift 1*/ drin stehen. Praktisch wäre wenn dieses /*Überschrift 1*/ durch die neue /*Überschrift 2*/ die man ja neu begonnen hat beim Abspeichern bzw. bei der Vorschau ersetzt werden würde. Damit würde man einerseits eine Menge Arbeit ersparen oder jenen dies sichs selbst ersparen, zu denen ich zeitweise auch gehöre, eine korrektere Zusammenfassung machen. --K@rl (Verbessern ist besser als löschen) 15:58, 15. Feb. 2012 (CET)

Äh, das wurde erst vor 4 Tagen archiviert: #Auto-Zusammenfassung für neue Diskussionsabschnitte mit irreführendem Bearbeitungskommentar. Kurz: Es gibt ein Skript, und das elfte Gebot lautet: Nutze den „neuer Abschnitt“-Button! Gerade wenn du dir des Themas bewusst bist, solltest du es nicht ignorieren! -- ✓ Bergi 16:09, 15. Feb. 2012 (CET)
Ein Benutzerscript ist zwar gut, aber besser wäre eine in MediaWiki implementierte Lösung. --Leyo 16:19, 15. Feb. 2012 (CET)
Die in MW integrierte Lösung heißt section=new. Wenn du auf den bearbeiten-Button des letzten Abschnittes klickst, sagst du damit dass du den letzten Abschnitt bearbeiten willst, etwa ergänzen – nicht dass du einen gleichwertigen Abschnitt anfügen willst.
Auch wenn ich die Leute nicht verstehen kann, die erst die ganze Seite herunterscrollen um dann falsch zu bearbeiten, wäre es vielleicht sinnvoll, den section=new-Link (erstmal per Skript) an das Seitenende zu verfrachten. Möglich wäre bei den Kategorien oder besser direkt neben dem letzten Editsectionlink. -- ✓ Bergi 16:37, 15. Feb. 2012 (CET)
Ich habe mal auf dem Testwiki etwas ausprobiert (Beispiel). Würde das wohl als Standard akzeptiert werden? Der Umherirrende 16:50, 17. Feb. 2012 (CET)
Ich find's gut, aber ob ich repräsentativ bin…? --Leyo 16:53, 17. Feb. 2012 (CET)
Ja, so in etwa hatte ich mir das vorgestellt (Nur den Link in die bereits bestehenden Klammern rein, wie auf Wikipedia:PRD). Vielleicht wäre der Link in einer Zeile vor den Kategorien besser aufgehoben, aber neben dem letzen editsection-Link fällt er eben auf :-) -- ✓ Bergi 01:01, 18. Feb. 2012 (CET)
An dieser Stelle, neben der letzten Zwischenüberschrift, kommt mir der Link äußerst merkwürdig vor. Wie soll man ihn dort finden? Je nachdem, wie lang der letzte Absatz ist, befindet sich dieser Link immer woanders. So ergibt das wenig Sinn. Der Link gehört entweder ganz ans Ende oder ganz nach oben. --TMg 02:06, 18. Feb. 2012 (CET)
Jein. Merkwürdig, ja, aber dort wird er anscheinend gesucht. Ich stelle mir den Ablauf so vor: Jemand liest die ganze Seite durch, stellt fest dass sein Thema noch nicht angesprochen wurde, will einen neuen Abschnitt anlegen und scrollt zum nächstbesten Edit-Link. Oder wird das gar mit Absicht gemacht, weil der Nutzer nicht einen kompletten Wikitext durchscrollen will, um am Ende etwas anzufügen? Ich weiß es nicht.
Am Seitenende steht man imho vor allem vor einem Layout-Problem. Wie soll der Link dahin? Vorschläge:
oder vielleicht auch (sorry für die unpassende Einrückung,
aber hier brauchts einfach ein bisschen Text um einen Eindruck gewinnen zu können):
Ersterer ist semantisch besser, zweiterer gefällt mir optisch besser. -- ✓ Bergi 04:07, 18. Feb. 2012 (CET)
Das obere gefällt mir. Natürlich nur auf Diskussionsseiten. Leider ist das nicht per Vorlage lösbar. Die würde ja nach oben wandern, sobald man einen Abschnitt anfügt. --TMg 10:49, 18. Feb. 2012 (CET)
Mir gefällt die obere Version besser.
Ich habe übrigens einen Hinweisbaustein-Entwurf gemacht: Vorlage:Hinweis neuer Abschnitt. Verbesserungen sind willkommen. --Leyo 00:08, 24. Feb. 2012 (CET)
Gute Idee! Ich habe die Formulierungen mal ein bisschen geändert. -- ✓ Bergi 10:07, 24. Feb. 2012 (CET)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup:Verbesserungsvorschläge/Archiv/2012/Februar&oldid=223327895“