Informatics Educational Institutions & Programs

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, 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

[[Benutzer Diskussion:Umherirrender/Archiv/2012-1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Benutzer_Diskussion:Umherirrender/Archiv/2012-1#Thema_1

Hallo Umherirrender. Die Löschung von Weinbauschule.jpg geht in Ordnung. Ich habe es nicht hingebracht d. vor längerer Zeit hochgeladene Bild auf Commons zu transverieren. HG Karl --Karl Bauer 19:19, 4. Jan. 2012 (CET)

Hallo Karl Bauer, bald wird sich ein Admin um das Bild kümmern. Du hast es auf Commons transferiert, das lokale Bild muss dann immer gelöscht werden. Es ist nicht möglich die Datei über eine Projektgrenze zu verschieben.

Ich kann nicht löschen und würde es auch nicht machen, weil wir erfahrende Leute haben, die schauen, das alles auf Commons ordentlich ist. In diesem Fall ist das einfach, weil es der gleiche Benutzer ist, aber manchmal gibt es auch Fälle, wo es Probleme mit der Lizenz gibt. Einfach abwarten. Der Umherirrende 19:27, 4. Jan. 2012 (CET)

Danke, HG Karl --Karl Bauer 19:29, 4. Jan. 2012 (CET)

Wie kommt denn die .wav-Datei auf Commons hoch, die du hier aufführst, obwohl .wav nicht zu den zugelassenen Formaten gehört? Ist es dir vielleicht möglich, die .wav-Datei herauszusuchen? 88.130.220.236 20:34, 5. Jan. 2012 (CET)

Ich bin nicht nach der Dateiendung gegangen, sondern nach den beiden Datenbankfeldern major_mime und minor_mime. Es ist also das, was MediaWiki beim Hochladen erkannt hat. Früher war es noch nicht erforderlich, das Mime-Type und Dateiendung zusammenpassen mussten. Das kam erst viel später, daher vermute ich, dass es sich Dateien mit falscher Endung handelt. Ich suche mal danach, dann haben wir Gewissheit. Der Umherirrende 20:46, 5. Jan. 2012 (CET)

Dann such bitte auch gleich die mp4-Dateien, die sind ja auch fehl am Platz. 88.130.220.236 21:05, 5. Jan. 2012 (CET)

Irgendwie scheint es beim Hochladen noch Probleme zu geben, das man solche Dateien hochladen kann. Erfreulich ist aber, das sich schon um die Dateien "gekümmert" wurde:

• Datei:20110420-RD-LSC-1074 - Flickr - USDAgov.jpg (video/mp4)
• Datei:Harvest.gif (video/3gpp)
• Datei:Harvest.tiff (video/mp4)
• Datei:Pétard.ogg (audio/wav)

Der Umherirrende 21:24, 5. Jan. 2012 (CET)

Da ja dort irgendetwas schiefgelaufen ist, habe ich mal Bug 33549 eröffnet und die 4 Dateien als beispiel genannt. Mal schauen, ob sich das jemand anschaut. Der Umherirrende 21:34, 5. Jan. 2012 (CET)

Ja, bitte das (doppelte) foto löschen. mir ist dafür ein zweites, das den ganzen burgberg zeigt, abhanden gekommen --E.mil.mil 12:52, 6. Jan. 2012 (CET)

Hallo E.mil.mil, es wird sich bald ein Administrator um das Bild kümmern und es nach Prüfung hier löschen.

Du sprichst von einem verlorenem Bild. In der Wikipedia geht kaum etwas verloren. Man kann viele gelöschte Dinge wieder herstellen. Dafür muss man nur den genauen Namen der Datei wissen und ein Administrator kann das Bild dann wieder herstellen. Ich vermute aber mal, das du dieses Bild meinst, weil du es kurz vor dem anderen Bild hier auf der deutschsprachigen Wikipedia hochgeladen hast. Der Umherirrende 17:10, 6. Jan. 2012 (CET)

svn:trunk/phase3/resources/mediawiki.libs/mediawiki.libs.jpegmeta.js Hier: um Zeile 304, tag #262

• Ist das RGB dort zufällig das RGB, über das sich die Browser beschweren, bzw. falls wenn nicht?
• Falls ja, wäre auch für 1 Million jpg auf Commons und in anderen Projekten eine Analyse machbar.
• Ansonsten scheint mir dieses .js aber auch eine wertvolle Hilfe für Bildverwalter, Grafikwerkstatt etc. zu sein. Man kann es in die Ansicht der Dateibeschreibungsseite einbinden und sich zu jedem betrachteten Wiki-Bild irgendwelche interessanten Schlüsselinformationen über das Foto anzeigen lassen. Beispielsweise könnte man damit auch ein Benutzerwerkzeug konstruieren, das beim Betrachten eines Wiki-Bildes eine Meldung aufpoppt: Achtung! Dieses Bild ist nicht RGB!
• PhotmetricInerpretation würde ich persönlich allerdings interpretieren als PhotometricInterpretation, die Anzahl der Zeichen ist nicht begrenzt; welche Auswirkungen für wen dieser String hätte, kann ich momentan nicht übersehen.
• Das tag #262 steht leider nicht an einer konstanten Byte-Position in den Bilddaten, so dass sich keine SQL-Abfrage auf das BLOB mit einem bestimmten Byte machen lässt. Es gibt aber einen extrem simplen Zwischenschritt, um dieses Byte und seinen Wert (offenbar 2 oder 6 oder Nicht-2 interessant) auslesen zu können. Bei gesichertem Bedarf bin ich in der Lage, ein C-Programm von wohl 20 Zeilen als throw-away zu schreiben, das nur sagt: JPG ohne RGB, ja/nein.

Viel Spaß --PerfektesChaos 13:52, 11. Jan. 2012 (CET)

Das ist ein guter Fund, aber man braucht immer noch das physikalische Bild auf der eigenen Festplatte oder man muss sich zu jedem Bild die ersten 100 Bytes (oder so) herunterladen. MediaWiki speichert die Dateien nicht in der Datenbank ab und es gibt kein Dump (wobei der auch zu groß wird). In der Datenbank liegt nur ein serialisertes php-Object der von MediaWiki extrahierten Metadaten (mw:manual:image table). Wenn MediaWiki allerdings das Pixel composition extrahieren könnte/würde, dann kann man auch danach suchen. Die andere Alternative hört sich aber auch gut an. Entweder auf jeder Dateibeschreibungsseite prüfen oder direkt beim Hochladen (wo das Skript eh schon geladen wird, um das Auto-Rotieren im Browsern (oder waren es nur einige?) zu simulieren). Der Umherirrende 19:54, 11. Jan. 2012 (CET)

Das sind zwei verschiedene Aufgaben mit verschiedenen Lösungen.

1. JavaScript – Nutzung dieses JS-Tools selbst:
   • Da hätte ich an ein Einzelbild gedacht, mit dem man interaktiv herummacht. Man kann einzelne Eigenschaften analysieren usw., vielleicht sogar das Upload verhindern oder nur auf ausdrückliche Bestätigung gestatten oder wie immer.
   • Die Binärdaten einer bereits hochgeladenen Bilddatei stehen ja wohl unter //upload. – und im Browser-Cache desjenigen, der gerade die Dateibeschreibungsseite im Schraubstock hat (weil man ja genau dieses Bild gerade sieht). Die Abforderung sollte der Browser also auf den Cache umlenken, nur diesmal nicht als IMG in die HTML-Seite rendern, sondern geeignet Zugriff erlauben. Da muss man also die identische URL benutzen und ein wenig knobeln, dann braucht man noch nicht mal an Netzverbindung und Server ran. JavaScript scheint mir allerdings nicht allzu gut für Binärdaten geeignet, aber da würde sich was finden. Wenn damit schon irgendwer was damit macht, kann man ja abkupfern.
   • Vor dem upload wäre es insofern schwierig, weil JavaScript in einem Browser keine Daten auf der Festplatte des Benutzers lesen dürfte. Man müsste es in einem temporären halb-hochgeladenen Zustand auf dem Wiki-Server abrufen. Ich habe aber noch niemals eine Datei hochgeladen und nicht die allerleiseste Ahnung davon.
2. C – Nur die neue Info über das tag #262:
   • Das wäre eine in C zu programmierende kleine Anwendung, die auf einer Unix-Shell etc. des Servers laufen müsste und sukzessive einen Zugriff auf eine Million JPG-Bilder von Commons etc. bekäme. Es würde mit hoffentlich nur dem ersten kB pro Bild gefüttert und antwortet mit 0 oder 1, woraufhin die Umgebung letzteres in einen Bericht schriebe. In PHP ginge das notfalls auch, in SQL theoretisch ebenfalls (aber abartigst).

Zu klären wäre aber zuerst, ob denn dieses tag #262 überhaupt das beschreibt, was das Browser-Rendering-Problem verursacht.

Schönen Abend --PerfektesChaos 20:36, 11. Jan. 2012 (CET)

Das du das JavaScript für einzeldateien gedacht hattest, hatte ich so verstanden. Man hätte dann auf der Dateibeschreibungsseite eine Warnbox, die darauf hinweist, das entweder nicht jeder das Bild sieht oder warum man es gerade nicht sieht.

Serverseitiges Script wäre natürlich viel einfacher, aber dafür müsste man dann sich sicher sein, das es das richtige Bit ist, sonst lohnt der Aufwand nicht. Ja, die Dateien stehen irgendwo unter upload.wikimedia.org, man kann sich den Pfad auch zurecht basteln, da es sich bei den Buchstaben bei der Ordner-Verteilung um den md5-gehashten Dateinamen handelt.

Für HTML-5-Brower gibt es ein Vorschaubild: rev:79029. Der Umherirrende 20:59, 11. Jan. 2012 (CET)

1. Interaktiv angezeigtes Einzelbild
   • Die Media-URL auf upload.wikimedia.org wird sich wohl in Kürze ändern, weil wir schon zuviele Bildchen haben und für jede der momentanen (wohl 256?) Pfade, die über das MD5 generiert werden zu viele Bilder in der Untertabelle stehen.
   • Es ist aber völlig egal, wie das einzelne Bild heißt. In src= des zu untersuchenden Seiten-Elementes steht die URL ja. Auf genau diese URL müsste entweder ein Zugriff erfolgen, oder man bekommt aus dem DOM des IMG die Binärdaten herausgequetscht. DOM kennt aber überhaupt keine Grafik; es wären anscheinend CharacterData und aus dem zu untersuchenden Bildchen-Node müsste man mit Bildchen.substringData(0,1024) genau das erste kB zur Analyse herausgezogen bekommen. Habe ich zwar noch nie gemacht, aber so müsste es gehen.
2. Server
   • Sicher sein, das es das richtige Bit ist: Frag doch mal die Maus, äh, unsere Grafikwerkstatt. Die sollten mit sowas vertraut sein.

Dieses Vorschaubild unter HTML5 durchschaue ich grad nicht; müsste ich mich in diesen window.FileReader der MW einlesen. Der würde dann anscheinend eine bereits ausgewählte file:/-URL bekommen. Sicherheitsmechanismen verhindern normalerweise oder in guten Browsern Festplattenzugriff von http-Seiten aus, oder sind da sehr restriktiv.

Bis neulich --PerfektesChaos 21:38, 11. Jan. 2012 (CET)

Hallo Umherirrender. Wäre es dir (mit vertretbarem Aufwand) möglich, so etwas auch für die engl. WP zu erstellen? Siehe dazu en:Wikipedia talk:WikiProject Images and Media/Commons/Drives#Already in use in WP:fr. --Leyo 13:31, 12. Jan. 2012 (CET)

Technisch dürfte es kein Problem sein. Es gibt zwar solche Vorlagen dort vermutlich noch nicht, aber eine reine Liste wäre möglich. Das Problem ist nur, das es so viele Sprachversionen gibt, das ich es nicht "professional" anbieten könnte. Das wird zu viel. Daher war das hier auch eher eine einmal Aktion. So viele Dateien werden wohl nicht hinzukommen. Ich denke ein Benutzer mit Toolserver-Zugang wäre hier schneller und könnte das dann sogar mit live-Daten oder zumindestens mit aktuelleren Daten anbieten. Der Toolserver hat alle Wikis, so dass es vermutlich ein leichtes ist, zwischen den verschiedenen Wikis zu springen.

Unabhängig davon, lese ich den Abschnitt so, das in fr.wp einfach die Bildeinbindung kopiert/importiert wurde, aber das Bild nicht da ist und es daher ein "Move to Commons" tagging des englischen Bildes geben sollte, damit es anschließend auch in fr.wp zur Verfügung steht. Auch hier wird es mit einem Toolserver-Zugang wesentlich einfacher, wobei es sich aber um eine andere Datenbanktabelle handelt (Einmal ist direkt die Datei und einmal die Dateieinbindung zu prüfen). Da wir hier in de.wp aufgrund von Bots die fehlerhaften Dateieinbindungen besser im Griff haben, wird das uns wohl nicht so interessieren. Wobei die andere Richtung (wo werden unsere Dateien genutzt) da natürlich nicht berücksichtigt ist. Der Umherirrende 19:33, 12. Jan. 2012 (CET)

Danke für deine ausführliche Antwort! Ich habe eine Unterüberschrift eingefügt, so dass nun die Zusammenhänge deutlicher sind. Dass es zu viel Arbeit wäre, kann ich gut verstehen.

Die Idee, in andern WPs eingebundene lokale Dateien zu suchen, um diese prioritär nach Commons zu transferieren, ist gut. Ich habe schon dutzende, wenn nicht hunderte Male erlebt, dass eine gerade transferierte Datei bereits irgendwo eingebunden ist. Ob sie sich praktisch umsetzen lässt, kann ich nicht beurteilen. --Leyo 17:10, 15. Jan. 2012 (CET)

Hallo Umherirrender! Du schreibst derzeit die Vorlage {{Vorlagenkategorie}} in verschiedene Kategorien hinein, u.a. auch hier. Wenn ich auf den Link klicke werde ich aber darauf hingewiesen: "Inaktives Projekt - Dieses Projekt ist erfolgreich abgeschlossen oder ist wegen Mitarbeitermangel nicht mehr aktiv. ..." Was macht dein Eintrag denn eigentlich? *kopfkratz* --Nati aus Sythen _Diskussion 16:23, 15. Jan. 2012 (CET)

Hallo Nati aus Sythen, der Text der Vorlage ist historisch gewachsen. Ich sehe aber noch die Notwendigkeit eine Vorlage als Erklärung für unser Vorlagen-Kategoriesystem zu haben (ähnlich Vorlage:Dateikategorie). Ich hatte nur noch keinen guten Einfall für einen Text, daher habe ich mich erstmal um die ca. 300 fehlenden Einbindungen gekümmert. Die Vorlage wurde vorher bereits in über 1100 Kategorien verwendet. Ich werde mich aber noch um den Text der Vorlage kümmern. Der Umherirrende 17:52, 15. Jan. 2012 (CET)

Ich habe den Text mal leicht geändert, damit zumindestens der Link auf die alte Projektunterseite entfällt. Der Umherirrende 19:32, 15. Jan. 2012 (CET)

Hatte mich mir heute unverständlicherweise auf das Eingeben in die Adresszeile versteift, statt es einfach ins Bearbeitungsfenster einzusetzen Vorlage:Smiley/Wartung/pfeif 

Es gibt seit einiger Zeit – glaube seit der Einführung von MediaWiki 1.18 Ende November – fehlerhafte AdT-Warnungen. Für morgen etwa sagt die Anzeige auf der Seite selbst einen nicht aktuellen Eintrag an, obwohl Vux gestern den aktuellen eingesetzt hat.

Im Gegensatz dazu zeigt WP:Hauptseite/Morgen nichts… der Link auf das nicht aktualisierte Schon gewusst/Mittwoch in der Einleitung müsste orange hinterlegt sein. Auch WP:Hauptseite/Schon gewusst, wo eine Warnmeldung erscheinen müsste, schweigt dazu. Entsprechend ist es offen, ob die Warnmeldung auf WD:Hauptseite/Artikel des Tages sowie WP:Hauptseite/Morgen auf die Bearbeitung innerhalb der letzten 6 Tage reagiert oder auch gar nicht funktionert.

Frohes Neues übrigens :-) Gruß, Hæggis 21:22, 10. Jan. 2012 (CET)

Die Warnmeldung habe ich gerade mal mit einem Purge wegbekommen und kann sie mit einem Nulledit (also Speichern ohne Änderung) wieder hinbekommen. Das wäre somit Bug 32948. Da MerlBot immer einen Nulledit macht (damit das mit der Kategorie klappt) gibt es dann natürlich die Warnung wieder. Ich schau mal, ob man das umgehen kann oder ob MerlBot anders arbeiten muss. Der Umherirrende 21:39, 10. Jan. 2012 (CET)

Nicht nur der MerlBot...... ;) --Guandalug 23:41, 10. Jan. 2012 (CET)

Da war doch mal was … ;-) Der Umherirrende 19:58, 11. Jan. 2012 (CET)

Ist das, hinsichtlich einer zeitnahen Reperatur, gut oder ist das schlecht? --Hæggis 21:00, 12. Jan. 2012 (CET)

Nein, das hat damit nichts zu tuen. Merlissimo muss seinen Bot ändern. Du bekommst die Meldung aber durch einen WP:Purge weg, ist erstmal unschön aber ich hoffe, das Merlissiom Zeit findet. Er war gestern nicht (sichtbar) online, daher weiß ich nicht, wie schnell das geht. Der Umherirrende 21:09, 12. Jan. 2012 (CET)

Ach du hast ja schon. Mensch, dank dir. Es ist nicht höchste TGV, nur wenn man sich an die Aktualisierung der Erinnerungsmeldung erinnern muss, kann man auch direkt schauen, ob der AdT aktuell ist ^^. Gruß, Hæggis 21:15, 12. Jan. 2012 (CET)

Das stimmt. Ich hätte die Anfrage aber auch hier verlinken können, schuldige. Was versteht du unter TGV? Der Umherirrende 21:19, 12. Jan. 2012 (CET)

Die höchte Eisenbahn :-) Hæggis 21:34, 12. Jan. 2012 (CET)

Kleines Wortspiel also, ich glaube, jetzt habe ich es auch, wurde auch allerhöchste Eisenbahn ;-) Der Umherirrende 21:38, 12. Jan. 2012 (CET)

Scheint doch nicht am MerlBot zu liegen. Dann muss ich mir mal mehr Gedanken dazu machen. Der Umherirrende 21:35, 17. Jan. 2012 (CET)

Ich habe erstmal einen Hinweistext gesetzt mit einem Link zum Cache-Leeren, weil das hilft, die Warnmeldung zu aktualisieren. Ich hoffe, das verwirrt nicht zu sehr, dann kann man aber sehen, ob der Bug zuschlägt oder ob die Meldung berechtigt ist. Zusätzlich kommt es nicht so möglichen Unterschlagung der Meldung. Geht vielleicht auch noch eleganter, aber das ist mir für den Moment eingefallen. Der Umherirrende 21:28, 19. Jan. 2012 (CET)

Der Bug ist gefixed, mit dem nächsten Software-Update sollte sich das Problem. Da hilft jetzt nur noch warten. Der Umherirrende 11:12, 21. Jan. 2012 (CET)

Ich hoffe du nimmst mir meine deutliche Contra-Stimme nicht krumm. Ich bin rein aus Prinzip gegen die Ernennung von Admins, die keine Entscheidungen innerhalb der Community treffen, unabhängig von der Person (siehe Wikipedia:Projektdiskussion/Administrativ inaktive Admins). --PM3 07:23, 25. Jan. 2012 (CET)

Nein, tue ich nicht. Auch schon bei meiner ersten Wahl gab es die Diskussion, ob und wie viel Artikelarbeit ein Admin in der Vergangenheit geleistet haben muss. Es gibt (zu guter Recht) viele Ansichten zu den Adminrechten. Die einen sehen es als Belohnung für gute Artikelautoren, andere sind der Ansicht, das dem Benutzer durch die Adminrechte die Mitarbeit hier leichter gestaltet werden sollte, andere haben wieder andere Beweggründe.

Ich kann auch deine Bedenken für deine Kandiatur nachvollziehen, weil es vermutlich aktuell viele solcher "inaktiven" Admins gibt. Da es sich aber hier immer noch um ein freiwilliges Projekt handelt, sehe ich keinen Zwang darin, das jeder mit Adminrechten, diese auch jederzeit ausüben muss und aus meiner Sicht sollten sie auch keinem, Aufgrund der vermeitlich genug vorhandenen Anzahl von Benutzern, verwehrt werden. Ich denke, es gibt auch sehr viele Sichter, die sich garnicht aktiv am Sichten beteiligen, aber aktive Sichterrechte haben. Mich stört so etwas nicht. Aber hier gehen die Ansichten projektweit sicher sehr auseinander. Der Umherirrende 18:46, 25. Jan. 2012 (CET)

Ok, dann wünsche ich dir mal weiterhin viel Erfolg! --PM3 12:50, 26. Jan. 2012 (CET)

Auch wenn ich hier den Thread "klaue" (muss keine Überschrift machen ;) - ich würde für Dich stimmen wenn ich dürfte! Danke für Deine Tips immer mal wieder! ;) Hoffe komme nie in die Situation selbst Admin-Rechte zu benötigen - wäre in einer noch verzwickteren Lage... so ganz ohne Stimmrecht... ;)) Gruss --DrTrigon 17:35, 26. Jan. 2012 (CET)

Hallo. Mit irgendwelchen Glückwünschen komme ich erst am 5. irgendwann spätnachmittags... Etwas anderes. Du erinnerst dich vielleicht an mein Problem mit einer farbigen Unterlegung diverser Seiten in der BEO hier, funktioniert prima. Ich wollte etwas ähnliches im SG-Wiki einführen, doch es funktioniert nur halbwegs. Zum Beispiel Seiten im Namensraum 2+3 in der Beo sind OK. Was ich wollte und was nicht funktionieren will ist:

• Artikel in einem Nachträglich zugewiesenen Namensraum 100+101
• und dann der gleiche Trick in den letzten Änderungen (ich versuchte es analog zu meinem hiesegen bescheidenen vector.css zu programmieren, indem ich .watschlist durch .recentchanges ersetzte); natürlich habe ich auch die Leerräume und Schrägstriche durch _Unterstreichungszeichen ersetzt

Hast du dazu eine Idee? Danke dir, Gruß -jkb- 19:06, 26. Jan. 2012 (CET)

Hallo. Auf den Letzten Änderungen steht eine solche Farbliche Markierung software-seitig aktuell nicht zur Verfügung. Die Einzige Hervorhebung ist, das Seiten die auch auf deiner Beobachtungsliste sind, dort fett markiert werden. Auf großen Wikis macht das farbliche auch keinen Sinn, weil man sich das ja über seine Beobachtungsliste anschauen kann. Auf kleineren Wikis, wo man vielleicht alle Änderungen sich anschauen möchte/kann, könnte das vielleicht interessant sein.

Da es die Namensräume 100 (Anfrage) und 101 (Anfrage Diskussion) in der Konfiguration gibt, sollte es dort genauso funktionieren wie auch bei den Benutzerseiten. Also watchlist-100-Seitenname, wobei Seitennamen hier ohne Namensraum sein muss. Die einzige Möglichkeit besteht hier, in den HTML-Quelltext der Seite zu schauen, was dort steht. Der Umherirrende 20:46, 26. Jan. 2012 (CET)

Aha. RC werde also vergessen, schade, bei dem Verkehr dort war die BEO bisher an sich überflüssig. Gut, mit 100 und 101 spiele ich morgen noch etwas (Quelltext forschen). Das hat aber erst einmal geholfen, vielen Dank, und Gruß -jkb- 22:39, 26. Jan. 2012 (CET)

Ja ja, ein Blick in den Quelltext brachte die Klarheit, ich hatte vorher fälschlicherweise auch ein Trennzeichen/Bindestrich durch _Unterschreichung ersetzt, war falsch. Also danke, Gruß -jkb- 22:51, 26. Jan. 2012 (CET)

Wenn du in deinen Einstellungen die Erweiterte Darstellung der „Letzten Änderungen“ (benötigt JavaScript) auswählst, stehen dir auch bei den RC Klassen wie .mw-changeslist-ns0-Ford_Thames_307E zur Verfügung. --Schnark 09:32, 27. Jan. 2012 (CET)

Nachdem ich mich gewundert habe, dass trotz des Bugfixes durch Krinkle auf beta.wmflabs noch immer mw.util.$content ist null-Fehler kommen, habe ich mir den Quelltext genauer angeschaut, und festgestellt, dass du dort beim Versuch der Problembehebung einen Fehler gemacht hast: Es darf nicht mw.loader.using( irgendwas, $(function() { code; } )); heißen, der using-Funktion muss natürlich eine Callback-Funktion übergeben werden, das Ganze also nochmal in ein function(){} eingepackt werden: mw.loader.using( irgendwas, function() { $(function() { code; } )});, was es nicht schöner macht, aber möglicherweise funktioniert bzw. Grund liefert bugzilla:33711 erneut wieder aufzumachen. PS: Danke für bugzilla:34194 --Schnark 10:36, 4. Feb. 2012 (CET)

Ich habe eher das Gefühl, das die Cache-Konfiguration dort etwas hartnäckig eingestellt ist und ich deshalb häufig eine veraltete Common.js ausgeliefert bekomme, die dann für JavaScript-Fehler verantwortlich ist. Wenn ich aber das Glück hatte, eine aktuelle Common.js zu bekommen, hatte ich das Gefühl das alles funktioniert. Was durch die Änderung natürlich jetzt wieder anders sein kann. Dein Beispiel klingt nachvollziehbar, führt das ganze aber etwas ins unüberschaubare. Wenn du möchtest, kannst du es auch gerne selber machen. Wenn du mir hier kurz bestätigst, dass das gleichnamige Konto dort deins ist, kann ich dich zum Admin machen. So ganz ohne Bestätigung möchte ich das nicht machen, weil man nie weiß, ob das nicht jemand ausnutzt und ich kann den Status nicht so einfach wieder entfernen. Bei den Bugs, die ich schon eröffnet habe, fällt 34194 garnicht so auf ;-) Der Umherirrende 11:00, 4. Feb. 2012 (CET)

Ich verwende zwar für Tests, bei denen ich Admin-Rechte brauche, eigentlich immer mein eigenes Wiki, aber schaden können die Rechte auch nicht, das gleichnamige Konto drüben ist meines, also kannst du mir einfach mal die Rechte erteilen. Als unangemeldeter Benutzer ist der Cache grausam, was insbesondere dann Ärger macht, wenn man mal wieder eine Seite erwischt, die noch im HTML-Code die mit rev:110592 entfernte Funktion mw.loader.setBlocking aufruft. Angemeldet kommt mir aber alles aktuell vor. --Schnark 11:20, 4. Feb. 2012 (CET)

So genau hatte ich das mit dem Cache und angemeldet/unangemeldet noch nicht beobachtet, kann aber so sein. Ich habe die Änderung an Common.js durchgeführt und dir die Adminrechte gegeben. Der Umherirrende 11:29, 4. Feb. 2012 (CET)

Jetzt bekomme ich auch angemeldet teils veraltete Versionen, aber immer wenn ich die aktuelle Version bekomme, funktioniert zumindest die common.js. Die Gadgets schaue ich mir vielleicht mal nächste Woche an. --Schnark 11:45, 4. Feb. 2012 (CET)

Ich habe grade den Senf von meinem Marmeladenbrötchen gekratzt und schmiere ihn jetzt hierhin; betreffend der obigen Verschachtelei. Ich empfehle das nachfolgende Schema; oft auch schon so oder so ähnlich gemacht.

/*
Wozu soll dieser Block gut sein?
Ggf. Pseudo-Wikilinks
Ggf. eine Art Maintainer.
Hier noch kein Datum; eher eine History.
*/
jQuery(document).ready( function () {
   // 2012-02-05   (hier auffälliger als im allgemeinen Kommentar)
   mw.loader.using( [ "mediawiki.util",
                      "jQuery.cookie" ],
                    function () {
      var x;
      code ...
      mw.util.$content ...
      mw.util.addPortletLink( ... )
      jQuery.cookie("!", "!");
   });   // loader.using
});   // document.ready

• Das jQuery(document).ready sollte den gesamten thematischen Block umschließen.
  • Die Ausführung sollte möglichst erst ganz zum Schluss erfolgen. Es ist nicht restlos gesichert, wie weit das Rendering in diesem Moment ist, aber soweit möglich sollte der Benutzer jetzt schon mal was zum Lesen bekommen haben.
  • Wenn document.ready erfolgt ist, sind nach derzeitigen Beobachtungen bereits alle Standard-Module geladen worden. mw.loader.using stellt dann nur noch fest, dass sie fertig geladen sind, und kann sofort die Funktion starten. Soweit möglich wird damit vermieden, dass die Funktion erst noch auf die Warteliste gesetzt werden muss und erst später abzuarbeiten wäre. Deshalb mw.loader.using im Inneren; außerdem fangen dann einheitlich alle entsprechenden Blöcke mit jQuery(document).ready an.
• Die Modul-Abhängigkeiten für einen spezifischen Block sollen gekapselt angegeben sein.
  • Jeder thematische Block sollte in sich unabhängig sein.
• Im Inneren des ausführbaren Blocks sollte obligatorisch das Datum der letzten wirksamen Veränderung vermerkt sein.
  • Gern auch mit Nick.
  • Auch beim Kopieren in andere Seiten bleibt diese Info erhalten.
  • Zwischen den ausführbaren Statements ist dies auffälliger als im allgemeinen Kommentar.
  • Die MediaWiki: werden über mehrere Jahre hinweg von vielen Autoren bearbeitet; für jeden zufällig hereinschneienden Programmierer muss auf Anhieb deutlich werden, was es an Tücken gibt (Abhängigkeiten, Verschachtelung, Nebenwirkungen). Was als BK in der Versionsgeschichte für diesen Block steht, ist später kaum auffindbar; auch nicht, was mal jemand in einer archivierten Disku dazu gemeint hatte.
• Wichtige schließende Klammern sollten kommentiert sein.

Die von Schnark oben bemängelte Verschachtelungsproblematik war mir neulich auch schon aufgefallen; ich wollte deshalb nicht auf jedes Komma schwören, sondern hatte nur die prinzipielle Strategie begrüßt.

• Ich bin mit weiterer Programmiererei zu ausgelastet, um auch noch auf Beta-labs aufschlagen zu können; ich kann aber gern last-minute nochmal über eine verlinkte Seite drüberschauen, wenn das Austesten fertig ist und der jeweilige Block unmittelbar vor dem Kopieren in die Site der de.WP steht.
• Ich erwähnte bereits, dass wir im Februar unsere allgemeinen und zwangsweisen Site Scripts auf den Stand von MW 1.17 gebracht haben sollten, bevor irgendwie ab März 1.19 kommt.
• Wenn die allgemeinen MediaWiki:*.js aufgeräumt sind, kann man sich Stück für Stück den Gadgets widmen. Hier wäre ja erstmal der jeweilige Gadget-Autor zuständig und verantwortlich, sofern noch aktiv; die Gadgets kann ein Benutzer aber bei Problemen auch abschalten.

Schönen Sonntag --PerfektesChaos 10:23, 5. Feb. 2012 (CET)

Ich glaube, das ist falsch herum. Meinen Verständnis nach, sagt man per using, was man alles braucht. Der Loader sammelt dies und lädt dann die Module gesammelt nach. Wenn dann alles geladen ist, führt er den Code aus, der die Module braucht. Wenn man jetzt erst nach document.ready dem Loader etwas mitteilt, dann wird dieser vermutlich unverzüglich versuchen das nachzuladen und das kann dann dazu führen, das man sehr viele Requests erzeugt. Im Fall von mediawiki.util ist das egal, weil das immer da sein sollte, aber bereits das jquery.cookie ist kein Standardmodule und müsste erst besorgt werden. Aus diesem Grund habe ich das immer andersherum geschrieben.

Über Code Convention kann man immer streiten, aber wenn die Einrückung stimmt, dann würde ich schließende Klammern nicht kommentieren. Ansonsten ist es im MediaWiki-Namensraum auch Wiki-Prinzip, nur das nicht jeder schreiben darf und somit nicht ganz so viele Leute direkt dran teilnehmen. Indirekt kann jeder dran teilnehmen, sofern er jemanden findet, der es rüberkopiert. Der Umherirrende 12:54, 5. Feb. 2012 (CET)

• jQuery.cookie ist ein Standardmodul. Es wird immer schon in einem der ersten Pakete mitgeladen. Das using dient hier nur dazu, die Abhängigkeit zu verdeutlichen, und sorgt für den seltenen Fall vor, dass die Abarbeitung mal so schnell ist, dass das Site/User-Skript schon gleichzeitig gestartet wurde, während das Modul noch nicht fertig ist. Nur in diesem Fall wäre noch ein Momentchen abzuwarten. Hier war das so gedacht, dass eine echte Bearbeitung noch gar nicht möglich ist, weil das DOM für den Block gebraucht wird. Dann hat der Loader aber das Teil schon lange auf der Liste, weil schon von Anfang an der Server es draufgesetzt hatte. Wenn der Loader aufgefordert wird, ein Modul zu benutzen, und das bereits fertig geladen war, dann passiert überhaupt nichts weiter.
• Mit using außen herum kann man in der Tat anfangen, wenn man parallel zum Aufbau des DOM ein wirkliches externes Modul benötigt. Dann fallen tatsächlich die Ladezeit für das Holen eines zusätzlichen Moduls und die Strukturierung des DOM zusammen, was bei der Parallelverarbeitung moderner Browser Gesamtzeit spart.
• Ich hatte auch nicht vor, Konventionen vorzuschreiben; MediaWiki:Common.js sieht auch tauglich aus – obwohl es in puncto anonymer Funktionen, globaler Variablen und loader.using weiter zu verfeinern wäre. Schlimmer steht es um diverse kurze Einzelseiten, insbesondere aber um Gadgets, um die sich seit Jahren keiner mehr richtig gekümmert hat. Mir geht es eher darum, bei einer allgemeinen Aufräumaktion vorbildliche Code-Strukturen zu hinterlassen; in der Hoffnung, dass sich das auf wurstelnde spätere Bearbeiter positiv auswirkt. Wenn es beispielsweise mal allgemein übliche Sitte würde, in jeden Block das Datum seiner letzten Änderung hineinzuschreiben, dann hätten alle was davon: Unter diesem Datum könnte man sofort in der Versionsgeschichte gucken, was da gemacht wurde; wenn das vor zwei Tagen geändert wurde, wäre das wohl der Grund, warum es seit gestern so komische Rülpser gibt; wenn der Block seit drei Jahren unverändert funktioniert, ist er eher unverdächtig.
• Das Kommentieren wichtiger schließender Klammern erhöht die Verständlichkeit für uns doofe Menschen, wenn es über mehrere Dutzend Zeilen geht, und vermeidet Irrtümer, wenn man sich bei acht gestaffelten Klammern im if-Block vertut. Die schlauen Computer arbeiten an der entsprechenden Klammer weiter, wenn das Programm syntaktisch korrekt ist; nur wir Menschlein hatten das vielleicht anders gemeint. Siehe Syntaktisches Salz – die Verwechslung schließender Klammern ist ein sehr häufiger Fehler formal richtiger, aber inhaltlich falscher Programme (auch etwa Fortran benutzt END IF, andere ein end for). Da eine schließende Klammer in C, Java und JavaScript alles mögliche beenden kann, ist ohne Übertragen des momentanen Quellcodes in ein geeignetes Werkzeug die Zuordnung unübersichtlich – erst recht, wenn es dann schon nicht mehr auf eine Bildschirmseite passt.
• Zu jQuery plane ich übrigens dies.

Liebe Grüße --PerfektesChaos 14:56, 5. Feb. 2012 (CET)

Hallo, meinen herzlichen Glückwunsch zur bestandenen Adminwahl! Freut mich sehr, daß es im zweiten Anlauf doch geklappt hat und daß auch Kandidaten gewählt werden, die nur in ganz bestimmten Bereichen aktiv werden wollen und nicht das komplette Programm von Importen/SP/LD/LP/SLA/VM etc. pp. abdecken (wollen). Nichts gegen Allrounder, aber es muss auch Leute wie dich als Admin geben :-) Viele Grüße von Schniggendiller Diskussion 16:07, 5. Feb. 2012 (CET)

wie hier vor ein paar Tagen versprochen, am 5. Februar später Nachmittag kommen die Glückwünsche auch von mir :-) -jkb- 16:09, 5. Feb. 2012 (CET)

Moin! Glückwünsche auch von mir. Viele Grüße, NNW 16:10, 5. Feb. 2012 (CET)

herzlichen Glückwunsch. --Graphikus 16:12, 5. Feb. 2012 (CET)

Ausnahmsweise auch mal an einem Sonntag die Knöppe rausgerückt. Viel Erfolg damit! — YourEyesOnly ^schreibstdu 17:26, 5. Feb. 2012 (CET)

Vielen Dank für die Ausnahme, YourEyesOnly! Der Umherirrende 19:14, 5. Feb. 2012 (CET)

Vielen Dank an alle Abstimmenden und Gratulanten. Ich freue mich auf meine neuen Möglichkeiten. Der Umherirrende 19:14, 5. Feb. 2012 (CET)

Herzliche Gratulation! Ich bin froh, dass es nach meiner wohl etwas zu wenig gut geplanten ersten Nomination doch noch geklappt hat – wenn auch etwas gar viel später… --Leyo 20:27, 5. Feb. 2012 (CET)

Ich glaube, es war deine Idee, es nochmal mit einer speziellen Laudatio zu versuchen ;-) Ich habe das nur aufgegriffen und jetzt Glück gehabt. Ich habe lange überlegt, ob die Community bereit ist, einen Nicht-Artikel-Schreiber als Admin zu wählen. Laut Kommentaren ist nicht jeder damit zufrieden (was ich auch verstehen kann), aber im Großen und Ganzen hat man mir doch die Möglichkeit gegeben. Also warst du auch nicht ganz unschuldig daran. Der Umherirrende 21:20, 5. Feb. 2012 (CET)

Schließe mich den Glückwünschen an und habe gleich den ersten Auftrag an dich: labs:de:User:Bergi bitte zum Bürokraten umbenennen, damit ich mich als erstes in ✓ zurückbenennen und mich zum Admin machen kann :-) Ich würde gerne MediaWiki Diskussion:Monobook.js#neu testen, bevor du es hier aktivierst. -- ✓ ^Bergi 22:27, 5. Feb. 2012 (CET)

Auch ich wünsche dir viel Erfolg und denke, dass gerade in dieser Zeit mit der in Umbruch und Weiterentwicklung befindlichen Wiki-Software keine Langeweile aufkommen wird.

Soweit ich das überblicken kann, lag deinen Contra-Stimmen eher eine prinzipielle Ablehnung einer Nur-Technik-Admin-Position zugrunde als ein Votum gegen deine Person. Und es haben auch schon Kandidaten schlechter als mit 90 % abgeschnitten.

Viel Sonne --PerfektesChaos 09:19, 6. Feb. 2012 (CET)

Vielen Dank. @Bergi: Erledigt. Der Umherirrende 18:16, 6. Feb. 2012 (CET)

(leider ein Bisschen spät) Herzlichen Glückwunsch! --Metalhead ✉ 12:47, 8. Feb. 2012 (CET)

Auch von mir herzlichen Glückwunsch. Mach's gut oder jedenfalls besser als ich. Grüße --85.181.216.233 18:30, 8. Feb. 2012 (CET) (C34 via IP)

Hallo Neu-Admin (gratuliere! ;)

Hab ne Frage; intressierst Du dich auch für anderssprachige Wikis? Hab grade ne Diskussion bei der ich um Deine Kommentare gar nicht unfroh wäre, geht um Template-Programmierung, siehe unter w:en:Wikipedia:Bot requests#Add 'FideID' parameter to chess infobox (den Kommentar von 'Farmbrough'). Falls Du mal Zeit und Musse hast wäre das super! Danke Dir schon mal im Voraus ;) Gruss --DrTrigon 10:57, 9. Feb. 2012 (CET)

Verschiedene Benutzer, verschiedene Ansichten. Hier in de.wp gibt es mehrere Metadatenvorlagen (Wikipedia:WikiProjekt Metadaten), die ein großes switch verwenden, die Vorlage:Flagicon mit einem großen switch wurde aufgelöst …

Sofern der switch nur einmal pro Seite aufgerufen wird, sehe ich darin kein Performance Problem, aber bei mehrere Verwendungen pro Seite, kann dies schon zu merkbaren Ladezeiten führen (Die Koordinatenvorlage hatte auch solche Probleme, wobei dort kein switch (alleine) das Problem war). Eine gute Praxis gibt es da wohl nicht. Der Umherirrende 17:40, 9. Feb. 2012 (CET)

Aha eine Frage des Glaubens ("Folget dem Schu! Nein! Folget der Flasche!"). Hmmm schon ne unschöne Sache... Hab mich bisher einfach an das gehalten was da war... Wegen mehrfachen Aufrufen pro Seite; d.h. wenn eine weitere Vorlage diejenige mit dem grossen '#switch' z.B. in einem '#if' zwei mal verwendet, z.B.:

{{#ifeq: {{ big-switch }} | - | 0 | {{ big-switch }} }}

dann ist das eine mehrfache Verwendung, oder? Mir schwant übles, werde gerade an Assembler-Optimierung-Sessions von früher erinnert... ;)

Habe auch gerade erfahren, dass ev. die Vorlagenprogrammierung durch Lua abgelösst werden könnte... ev. bringt das ja was?! Gruss und Danke --DrTrigon 13:33, 10. Feb. 2012 (CET)

Ja, das if wäre ein mehrfacher Aufruf, aber der mehrfache Aufruf erfolgt nur im positiven Fall (Zahl im switch gefunden, also nicht "-"), was vielleicht noch verschmerzbar ist. Das if könnte man aber auch umgehen, in dem man dem switch ein default gibt, sofern das an allen Stellen das gleiche sein dürfte. Ich habe auch schon gehört, das Lua kommen soll, habe mich damit aber noch nicht beschäftigt, was es ist oder was man damit machen kann, kann also absolut nichts dazu sagen. Der Umherirrende 16:02, 10. Feb. 2012 (CET)

Lua ist zumindest schon mal eine etablierte Sprache und sollte keine solchen Performance-Probleme haben und mehr können - hoffe ich... Und da es schon Ansätze gibt zu Modulen mit denen Lua und python kombiniert werden kann, besteht zumindest die Möglichkeit, dass ich es meinem Bot auch beibringe und so ein konsistentes Interface (Bot verwendet selbe Sprache wie Wikipedia) erstelle. Ein Rückschritt wäre es jedenfalls nicht... ;) Aber kenne mich auch noch nicht aus damit... Gruss --DrTrigon 16:59, 11. Feb. 2012 (CET)

Hallo Umherirrender

Ich habe gesehen, dass du kürzlich einiges an den Systemskripten geändert hast. Könnte dieses Problem darauf zurückzuführen sein? Es sieht so aus, als ob die Reihenfolge der Skripte geändert hat, was an einigen Stellen (Pfeil-Hoch, modifylks) zu Problemen führt. --PaterMcFly Diskussion ^Beiträge 09:27, 18. Feb. 2012 (CET)

Hallo PaterMcFly,

ja, die Änderung an der Monobook.js war dafür verantwortlich, weil die Skriptausführungsreihenfolge dadurch sich geändert hat. Ich habe deshalb auch das Pfeil-Hoch-Helferlein entsprechend umgestellt. Warum Benutzer:PDD/modifyLKs.js dann nicht mehr funktioniert, kann ich nur ahnen. Ich denke aber, das auch hier die Skriptreihenfolge eine Rolle spielt. Es wird nämlich erst das Gadget, dann die Monobook.js ausgeführt und dann das Skript von PDD. Vor meiner Änderung dürfte das Skript von PDD als erstes ausgeführt worden sein. Ich habe PDD einen Hinweis hinterlassen. Der Umherirrende 11:12, 18. Feb. 2012 (CET)

Guten Morgen,

falls dir auf den Sonntag der Lesestoff ausginge, hätte ich zwei Wikilinks: RL und Onlyifediting.

Nur weiter so mit der Anpassung unserer projektweiten Skripte im Februar unter 1.18, bevor wir die dadurch entstehenden Bugs nicht mehr von den Böcken aus 1.19 unterscheiden können.

Schönes Wochenende noch --PerfektesChaos 00:26, 19. Feb. 2012 (CET)

Die eine Seite hatte ich mir gestern schonmal durchgelesen. Ließt sich erstmal sehr informativ. Das zweite spar ich mir noch auf, das ganz große Rad zu drehen, ist vielleicht noch etwas früh ;-) Der Umherirrende 20:59, 20. Feb. 2012 (CET)

Freut mich, wenn dir #1 gefallen hat. #2 war ja auch nur zu deiner Info, damit du weißt, was in der Schublade ist. Zurzeit habe ich gerade mein JS-Großprojekt WSTM (500kB) mal wieder in trockenen Tüchern, flöhe fileAdm mit 200kB und bringe es bald mal zur Version 1.0 und werde danach wieder intensiver die editTools (100kB) angehen; vielleicht gibt es dann schon ein klareres Bild über den RL2 und seine internationalen Gadgets. Schönen Abend --PerfektesChaos 20:22, 22. Feb. 2012 (CET)

Schönen guten Abend,

du hattest heute Mittag erwähnt, dass du einen FF10 installiert hast und dass es da eine Option gibt: async ein/aus (so habe ich das zumindest verstanden). Ich selbst bleibe bei meinen FF3.6 und möchte meine Maschinchen im Moment nicht verhunzen.

• Falls du es bisher noch nicht getan haben solltest: Könntest du bitte mal mit irgendeinem Gadget, das diese RL-Option hat, ausprobieren, ob du bei FF10-async=ein die ominöse Meldung bekommst und bei async=aus dann nicht mehr?
• Wenn sich das so bewahrheitet, wäre es nett, wenn du auf dem o.a. Bugzilla Bescheid gibst, dass es diese Option gibt und wie sie heißt (about:config).
• Es könnte sein, dass es auf Chrome auch so einen Schalter gibt; #c5 kann nicht reproduzieren, #c10 dagegen schon.
• Unsere FF10-Beschwerdeführer könnten sich das auch behelfsmäßig auf async=aus stellen.

Amüsier dich --PerfektesChaos 20:56, 26. Feb. 2012 (CET)

Eigentlich ist das eine Standardinstallation (Zumindestens nichts bewusst verstellt, so häufig nutze ich ihn nicht). Ich bin daher davon ausgegangen, das es irgendwo einen Schalter geben muss, weil ich das ganze nicht nachvollziehen kann. Ich habe aber noch nichts gefunden. In der Fehlerkonsole kann ich aber kein Warnhinweis sehen, der auf document.write hindeutet. Der Umherirrende 21:04, 26. Feb. 2012 (CET)

Beim Suchen gesehen: Problem älter als FF10?. noch einen Der Umherirrende 21:14, 26. Feb. 2012 (CET)

Hier wird gesagt, das ein Script-tag das Attribute async hat. Könnte man das nicht einfach auf den Wert des dritten Parameters setzen? Dann müsste der FireFox doch zufrieden sein. Vielleicht noch ein try/catch drum, weil der IE das wohl nicht kennt. Der Umherirrende 21:26, 26. Feb. 2012 (CET)

• Schnark schreibt etwas von Gecko-Versionen; demnach sei das Verhalten von FF seit letztem Sommer schon unvorhersagbar gewesen. Aber erst mit FF10 würde dieses Problem aktiv unterbunden und eine Fehlermeldung ausgespuckt.
• Für alle immer die async-Lademöglichkeit zu unterbinden wäre unfair und könnte allenfalls mal ein paar Tage als Behelfslösung durchgehen. Das async ist ja grundsätzlich sinnvoll und verkürzt die Wartezeit.
• Die Lösung sieht anders aus: Solange document.ready noch nicht passiert ist, müssen alle normalen Anforderungen ("bottom") in eine Warteschleife, etwa $() oder selbst geschrieben. Danach mit DOM an den BODY angehängt. Wenn jemand vor dem document.ready etwas ganz Wichtiges ("top") hätte (CSS-Layoutänderung / API-Abfrage starten), dann kann das per DOM an den bereits fertigen HEAD angehängt werden. document.write() ist aber veraltet und sollte überhaupt nicht mehr passieren (wie man weiß: Do not use).
• Aber vielleicht gäbe es ja wirklich unter den 1000 Optionen im FF eine zum Abschalten des asynchronen Ladens? Da kann man ja sonst alles Mögliche einstellen.

LG --PerfektesChaos 21:46, 26. Feb. 2012 (CET)

Ja, nur als Behelf, damit alles wieder funktioniert. So ist die Situation ja sehr unschön, weil man nicht weiß, ob das Skript bei jedem lädt. Wenn man dann eine Lösung gefunden hat und es wieder funktioniert, kann man gerne wieder async laden. Aber wenn es kaputt ist, sollte man das Feature ja nicht nutzen. Der Umherirrende 21:53, 26. Feb. 2012 (CET)

1. 25. Mai 2011 – Frechheit! Und schon mit der exakt richtigen Fehlermeldung.
2. Na, die Behelfslösung brächte nicht viel. Sie muss auf MW in mw.loader.addScript() (intern) passieren, und dann können sie es auch gleich richtig machen. Es muss eh in den frisch verteilten MW1.19 backported werden. Da erst mit einer Behelfslösung und drei Tage später mit der richtigen zu kommen wäre arg verwirrend. Wir haben keine Möglichkeit, das zu beeinflussen, und mit MW 1.18 schon gar nicht.

--PerfektesChaos 22:29, 26. Feb. 2012 (CET)

Ja, der Behelf wäre etwas für die MediaWiki-Entwickler. Selber haben wir da garkein Einfluss. Es sollte etwas passieren, wie ist mir eigentlich egal, weil das Problem wird doch Unmut schüren und die Empfehlung auf den IE zu wechseln hört sich schon komisch, weil sonst alle anderes herum das ganze sagen. Gerade der automatische Update im FireFox wird dafür sorgen, das die Version viele und auch schnell bekommen. Der Umherirrende 18:39, 27. Feb. 2012 (CET)

Wo ich das grad seh: Kannst du das Wort „beispielsweise“ am Anfang der Klammer bitte klein schreiben, da dort kein eigenständiger neuer Satz anfängt? Danke. --Geitost 20:00, 2. Mär. 2012 (CET)

Gerne. Der Umherirrende 20:08, 2. Mär. 2012 (CET)

Danke sehr. :-) Die Variante MediaWiki:Movepagetext-noredirectfixer/de-formal müsste auch noch in Sie-Form abgeändert werden. Kannste evtl. einfach hier kopieren:

Mit untenstehendem Formular können Sie eine Seite umbenennen, indem Sie sie mitsamt allen Versionen auf einen neuen Titel verschieben.
Der alte Titel wird danach zum neuen weiterleiten.
Stellen Sie sicher, dass Sie im Anschluss alle [[Special:DoubleRedirects|doppelten]] oder [[Special:BrokenRedirects|kaputten Weiterleitungen]] überprüfen.
Sie sind dafür verantwortlich, dass Links weiterhin auf das korrekte Ziel verweisen.

Die Seite wird '''nicht''' verschoben, sofern es bereits eine Seite mit dem vorgesehenen Titel gibt, es sei denn, diese ist leer oder eine Weiterleitung ohne Versionsgeschichte.
Dies bedeutet, dass Sie die Umbenennung rückgängig machen können, sofern Sie einen Fehler gemacht haben. Sie können hingegen keine Seite überschreiben.

'''Warnung!'''
Die Verschiebung kann weitreichende und unerwartete Folgen für häufig besuchte Seiten haben.
Sie sollten daher die Konsequenzen verstanden haben, bevor Sie jetzt fortfahren.

<big>'''Neu:'''</big> Bei Verschiebungen in einen anderen [[Hilfe:Namensräume|Namensraum]] wählen Sie bitte den neuen Namensraum aus der Liste (beispielsweise das Verschieben eines vorbereiteten Artikel aus dem Benutzernamensraum).

--Geitost 20:17, 2. Mär. 2012 (CET)

Stimmt. Dabei hatte ich noch drauf geachtet, das ich die Unterscheidung nicht brauche, bin dann letztendlich doch von abgekommen. Wie ich es liebe … Der Umherirrende 20:24, 2. Mär. 2012 (CET)

Jo. *lach* Dank dir. :-) --Geitost 20:29, 2. Mär. 2012 (CET)

Hallo, es ist absehbar, dass es in den nächsten Tagen zu allerhand Dramen um nicht mehr funktionierende Benutzerskripte kommen wird, wenn ich mir die bisher gelaufenen Ruckler um die Gadgets angucke.

Ich darf an MediaWiki Diskussion:Common.js #akeytt() erinnern; dann bekommt man wenigstens eine zielführende Fehlermeldung. Nach ein paar Monaten kann das ja wieder raus. Unter den Aktiven finde ich momentan beispielsweise:

• Benutzer:Stefan/monobook.js (Admin)
• Benutzer:Nikkis/monobook.js (Admin)
• Benutzer:DerHexer/addotrs.js
• Benutzer:DerHexer/importartikel.js
• Benutzer:HOWI/monobook.js sieht nicht nach einem geübten Programmierer aus
• Benutzer:Karl Gruber/unsigned.js
• Benutzer:Neozoon/addotrs.js
• Benutzer:Euku/*.js

Irgendwann in den nächsten Monaten kann man sich dann über runOnloadHook hermachen.

Gute Nerven uns allen --PerfektesChaos 09:57, 29. Feb. 2012 (CET)

Ich finde ein alert in einem zentralen Skript keine gute Wahl, auch wenn es wohl die effektivste ist. Wobei ich auch kein Problem damit hätte, wenn die Benutzer ein Javascriptfehler bekommen. Das Problem dabei ist, das ein Nicht-technik affiner Benutzer, nichts mehr machen kann und vielleicht denkt, es hätte sich ein schwerwiegendes Problem aufgetan oder ein Virus eingefangen, oder so (Im Firefox wird alles grau und nur die Meldung bleibt sichbar). Würde dann sein System/Browser neu aufsetzen und wieder die Meldung bekommen. Ich hätte da eher an eine softere Lösung gedacht. Vielleicht mit mw.util.jsMessage? Das blockiert das Arbeiten nicht, sollte man aber sehen können. Nur wenn es innerhalb der CSS-Klassen für sitenotice/fundraiser steht, würden einige Benutzer das nicht sehen. Der Umherirrende 20:06, 29. Feb. 2012 (CET)

Ob nun alert oder eine in die Seite eingebaute Nachricht sehe ich leidenschaftslos; alert hat fünf Buchstaben und war mir als erstes eingefallen; hätte auch weniger Arbeit gemacht.

1. Meines Wissens unabhängig von gern ausgeblendeten CSS-Klassen sind die mw.*, weil sie sich ggf. selbst ihre Klasse/ID spezifizieren.
2. mw.util.jsMessage() überschreibt immer die zuletzt vorhandene Box und wäre ungeeignet, wird auch selbst überschrieben.
3. jQuery.messageBox aus jquery.messageBox fügt eine zusätzliche Box hinzu, löscht keine und wird nicht überschrieben. Ein alter Bekannter übrigens, wikibits jsMsg().
4. Nebenbei lässt sich der Nachrichtentext noch verfeinern; ungetestet aber sollte so funktionieren, auch ausbaufähig mit funktionierendem Link auf TSW:

window.akeytt  =  function () {
   var s =  "<div style='border: solid 2px #0000FF; width: auto; margin-top: 10px'>"
           + "Ein Skript benutzt die <b>veraltete Funktion <code>akeytt()</code></b>.<br />";
   if (akeytt.caller !== null) {
      s  =  s + "(aufgerufen von: " + akeytt.caller + ")<br />";
   }
   s  =  s + "Wenn du der Autor des Skripts bist, solltest du sie entfernen.<br />"
          + "Wenn du nichts darüber weißt, kannst du auf [[WP:TSW]] nachfragen.<br />"
          + "-- <i>de.WP</i></div>";
   mw.loader.using("jQuery.messageBox",
      function () {
         jQuery.messageBox( { message: s,
                              id:      "dewiki-warn-akeytt" } );
      }
   );   // .using()
};   // akeytt()

Noch ist Februar; schönen Abend --PerfektesChaos 21:18, 29. Feb. 2012 (CET)

Laut Roadmap geht es heute um 23 Uhr UTC los …, ich würde so eine Änderung aber lieber am Wochenende machen, wo man das schneller eventuell nachbessern kann, ich würde daher sagen, einfach mal abwarten, wie viele sich über diesen JavaScript-Fehler ärgern. Die Rückmeldungen auf MediaWiki Diskussion:Common.js bezüglich der Änderung sind auch nicht groß. Wobei ich die dahinter stehende Idee garnicht mal so schlecht finde, aber irgendwann muss auch mal Schluss sein, mit dem Support. Vorallem werden wir auch die inaktiven nicht erreichen, daher ist ein Hinweis auf den Seiten der Benutzer wohl zielführender. Bin gerade etwas gespalten … Der Umherirrende 21:30, 29. Feb. 2012 (CET)

Der Regex \bakeytt\b auf den CSS/JS-Benutzerseiten gibt 40 Treffer, aus meiner Sicht können wir das ignorieren, auch wenn ein Benachrichtigungsservice eine gute Idee wäre. Aber der Aufwand einen entsprechenden Text zu formulieren und zu verteilen dürfte über den Nutzen für die Benutzer liegen. Der Umherirrende 17:26, 3. Mär. 2012 (CET)

Ich denke ja auch eine Nummer weiter:

• In ein paar Wochen, wenn sich der Pulverdampf um 1.19 verzogen hat und Ruhe eingekehrt ist, sollte man mal den includePage (239 Treffer) auf den Pelz rücken, runOnloadHook (11 Treffer) und hookEvent (34 Treffer) hatten eigentlich noch nie etwas in Benutzerskripten zu suchen und sind anno Tobak.
• Nächstes Jahr wird man wohl den addOnloadHook auf die Finger klopfen müssen, zwei Jahre nach MW 1.17 wäre es Zeit für eine Umstellung.
• Die ganze wikibits ist Kandidat für solche Mahn-Boxen; nur die importS*** wird man wohl auf .load() emulieren müssen.

Das Ganze ist ja dadurch verkompliziert, dass

• ein Skript auch von anderen Benutzern eingebunden worden sein kann und dort noch aktiv benutzt wird
• der Autor eines noch benutzten Skripts inaktiv sein kann
• ein größerer Teil der Benutzer von Hunderten von monobook.js inaktiv sein kann und sich bei ihnen die Pflege nicht mehr lohnt
• die Benutzer gar nicht wissen, was man ihnen in die monobook.js geschrieben hat
• unzählige Kopien von Bluefish etc. herumschwirren
• nicht jede jetzt kaputte Funktion wird täglich gebraucht.

Es ist aber einfacher, das anhand einer qualifizierten Meldung zu debuggen als dass irgendwer verärgert und schmollend in der Ecke sitzt oder wenigstens so schlau ist, in der TSW aufzuschlagen – wo wir dann Hunderte von Zeilen flöhen sollen.

• Die Funktionsdefinition von einer Benutzeranmeldung abhängig zu machen bringt nichts; geladen würde sie ohnehin, aber ausgeführt nur von denen, die sie verwenden.

Jeder Benutzer lädt rund 250 kB (komprimiert) MW+jQuery JS oder hält sie in seinem Cache, ohne Gadgets und Benutzerdefiniertes. Darin werden vermutlich über 1000 Funktionen definiert. Dann kann es ja keine ernsthafte Mehrbelastung sein, für eine angemessene Zeit (einige Monate, bis die Funktion mal benutzt wurde) ein paar Zeilen definiert und unaufgerufen mitzuschleppen.

• Wer dann hinterher kommt und jammert, dass sein Skript nicht mehr geht, den kann man auf solche Aktionen verweisen. Wir haben uns jedenfalls alle Mühe gegeben.

Im Übrigen ist die Umstellung auf MW 1.19 ja relativ glimpflich abgelaufen, insbesondere durch die Vorarbeiten auf beta und auch dein Engagement. Es gab hie und da etwas Gemurre auf CSS-Basis und einige Details, aber angesichts der Komplexität unserer Software von -zig freiwilligen Autoren kaum besser vorstellbar. VG --PerfektesChaos (D) 23:00, 3. Mär. 2012 (CET)

Auf MediaWiki:Preferences-summary/de-formal muss de-formal gesiezt werden. --Fomafix (Diskussion) 21:32, 3. Mär. 2012 (CET)

Stimmt, sollte genauer lesen. Der Umherirrende 21:51, 3. Mär. 2012 (CET)

Hallo. Wäre gut, wenn das Thema endlich bearbeitet würde. Ich würde dich dabei unterstützen. Mein erster Schritt zur Sanierung wäre, dass wir für die Eigenschaften der Tabellenzellen CSS-Klassen festlegen und die Vorbelegung der Eigenschaften auf Mediawiki:Common.css definieren. Dadurch werden die Vorlagen 1. übersichtlicher und angemeldete Benutzer können das Aussehen für sich selbst in ihrer CSS-Datei festlegen. Würdest du das unterstützen (Nur Admins können auf Mediawiki:Common.css schreiben) ? ÅñŧóñŜûŝî (Ð) 17:13, 24. Feb. 2012 (CET)

Hallo Antonsusi, da ist keine Eile geboten, nur weil es der oberste Eintrag ist. Besser etwas mehr Zeit investieren und nichts kaputt machen oder die Server belasten, anstatt es schnell erledigt zu haben.

Mir war aufgefallen, dass die Turnierpläne für verschiedene Anwendungsfälle auch verschieden aussehen. Ich gehe davon aus, das der Anwender dies bewusst gewählt hat und er wird sich über eine Veränderung wohl nicht freuen. Änderungen an Common.css sind nach Einigkeit immer möglich. Der Umherirrende 20:54, 24. Feb. 2012 (CET)

Mir geht es zunächst um die bisher hartcodierten - also direkt im Quelltext der Vorlagen vorgenommenen - Festlegungen der CSS-Eigenschaften wie Hintergrundfarben, Textfarben, Schriftart, -stil und -größe, etc. Diese sind im überwiegenden Teil der Turnierplan-Vorlagen gleich. Sie machen den Quelltext unübersichtlich und sie verhindern, dass ein Benutzer die Werte an seinen Skin, seinen Monitor und seinen Geschmack anpassen kann. Wenn wir nun diese Standardangaben als CSS-Klassen nach Common.css übertragen, dann sehen die Turnierpläne für IPs und Benutzer ohne eigene CSS-Seite genauso aus wie vorher, aber angemeldete Benutzer können eigene Eigenschaften für sich selbst setzen. Als Nebeneffekt würden die Quelltexte viel lesbarer. Ich bringe das mal in der Vorlagenwerkstatt zur Sprache. ÅñŧóñŜûŝî (Ð) 21:20, 26. Feb. 2012 (CET)

In der Vorlagenwerkstatt gibt es seit einer Woche keine Reaktion. Ich schlage vor, die Idee mit Common.css jetzt umzusetzen. ÅñŧóñŜûŝî (Ð) 17:48, 4. Mär. 2012 (CET)

Ich bin gegen eine solche Definition in der Common.css. Für mich werden die Turnierpläne auf zu wenigen Seiten genutzt, als das es eine vergrößerte Commons.css rechtfertigt, die jeder Benutzer bei seinem ersten Besuch hier herrunterladen muss. Es ist nichts gegen die Idee einzuwenden, hier die Vorlagen zu verschlanken und anderen Benutzern die Möglichkeit zu geben, sie nach den eigenen Bedürfnissen zu gestalten, aber nicht bei den Nebeneffekten. Der Umherirrende 20:51, 4. Mär. 2012 (CET)

Hallo Umherirrender. Hast du einen Überblick darüber, wo für die gleichwertige Darstellung in de-at, de-ch und de-formal Mediawiki-Seiten fehlen? Durch „Umstrukturierung“ hast du ja bereits einige überflüssige Seiten gelöscht. Vielleicht gibt es da auch noch mehr. --Leyo 12:55, 22. Feb. 2012 (CET)

Hallo Leyo, ich habe am Wochenende einige veraltete Systemnachrichten gelöscht, damit man etwas besseren Überblick hat, was noch genutzt wird, und wo man vielleicht mal Energie zum Korrigieren reinstecken könnte. Ein Nebeneffekt ist aber auch, das man so einfacher prüfen kann, von welchen Systemnachrichten eine de-ch/-at/-formal-Version fehlt. Ich werde bei Zeiten mal schauen, bei welchen Systemnachrichten das noch Sinn machen könnte und diese dann Anlegen. Da nicht alle Systemnachrichten in der Benutzeroberflächen-Sprache geladen wird, kann man das nicht pauschal sagen. Ich werde da aber dranbleiben, auch wenn es wohl nicht so viel Benutzer betrifft ;-) Der Umherirrende 18:38, 22. Feb. 2012 (CET)

Auf jeden Fall heißt es weiterhin „Hide“ statt „Ausblenden“ bei de-ch in der CentralNotice von Meta (zurzeit bezüglich der Stewardwahlen), da bislang kein Admin dort meine diesbezügliche Anfrage dazu vom 17.02. durchgeführt hat. :-( Falls ihr das bereits ausgeblendet habt, könnt ihr das sehen, wenn ihr de-ch als Sprache in einem anderen Projekt eingestellt habt. Gilt auch für de-at und auch für nl-informal. Ich hatte da schon einmal auf Deutsch und Englisch hinterhergehakt und die Anfrage strukturiert, hat aber noch keiner drauf reagiert. Dabei wär’s so einfach, wenn man die Benutzeroberfläche auf Meta bearbeiten könnte. Vielleicht sollte ich den Abschnitt doch besser neu abtrennen, damit jemand das bearbeitet? Vielleicht solltest du, Umherirrender mal Editinterface-Rechte für Meta beantragen, um so was bearbeiten zu können? --Geitost 20:34, 22. Feb. 2012 (CET)

Das editinterface-Recht scheint es aktuell nicht getrennt für Meta zu geben, sondern nur für alle WMF-Projekte (Benutzer mit dem Recht). Das wäre wohl zu viel des guten. Auf WP:CentralNotice stehen auch noch ein paar Leute, die das eventuell machen könnten. Vielleicht hast du dort mehr Erfolg als auf Meta. Der Umherirrende 21:03, 22. Feb. 2012 (CET)

Die CentralNotice-Seite hier kannte ich noch gar nicht. Ganz aktuell ist die Aufzählung wohl nicht unbedingt. Evtl. kümmert sich ja jetzt Merl drum, Barras und Axpde und Eptalon können das z. B. auch tun (und haben das auch schon) und angesprochen werden, sind dann je nach Aktivität hier dann mehr oder weniger gut hier (bzw. wohl besser auf Meta) auf Deutsch ansprechbar und sollten auch mit aufgeführt werden. Schade, dass es nicht möglich ist, in einem Wiki nur das Editinterface-Recht zu bekommen. Vielleicht kannst du dann ja auf Meta auch demnächst noch mal als Admin kandidieren (jetzt dürfte das ja gehen)? Die Glückwünsche für hier hatte ich noch „vergessen“ (war grad gar nicht hier) – sie seien hiermit nachgereicht. :-)

Weißt du, warum man im Translatewiki mit de-ch „Staff“ statt „Mitarbeiter“ angezeigt bekommt? Und wie verlinkt man das eigentlich am besten von hier aus? --Geitost 22:05, 22. Feb. 2012 (CET)

Damit man das editinterface-Recht auf dem Wiki vergeben kann, braucht es eine eigene Benutzergruppe, so wie es die Globale Benutzergruppe auch gibt, die nur dieses Recht aktiv hat. Das wurde noch nicht eingerichtet und ich glaube, das es schwierig ist, den Prozess dafür anzustoßen.

Bei einem Thread (beispielsweise beim Anfangsthread oder einen anderen beliebigen) gibt es rechts das Menü "mehr", dort dann Permalink wählen, gibt beispielsweise diesen Wikilink: translatewiki:Thread:User talk:Geitost/Beschreibung der Benutzerrechte, noch das translatewiki davor hängen und fertig oder den Weblink nehmen. Ich habe mal dort geantwortet. Der Umherirrende 17:59, 23. Feb. 2012 (CET)

Dank dir. Bei deiner Supportmeldung dort wurde ja auch wieder nur auf die alten Bugmeldungn bei Bugzilla verwiesen, aber eigentlich sollte es ja besser lokal gesondert angepasst werden, damit man eben nicht mehr das Englische für die Fallbacksprachen sieht. Macht doch keinen Sinn, jahrelang Texte in Englisch angezeigt zu bekommen, nur weil man ewig auf einen Bugfix wartet. Die Bugmeldungen für die spezifischen Fallbacksprachen werden ja immer nur sofort als Duplikat markiert, statt sie mal gesondert von dem anderen Problem der 2005er-Bugmeldung anzugehen, wo es um viel komplexere Dinge geht, die gar nicht wirklich gelöst werden sollen und die mit dem Fallback aller möglichen Sprachen auf en zu tun haben und nicht mit den Fallbacksprachen (ich halte das für 2 verschiedene Paar Schuhe, denn de: und en: sind nicht untereinander verständlich, die Fallbacksprachen de-ch, de-at und de-formal sind demgegenüber aber zu de: gut verständlich, genauso wie nl-informal auch zu nl: oder ähnliche Sprachvarianten). --Geitost 17:03, 1. Mär. 2012 (CET)

Wie ich sehe bist du eifrig am Aufräumen und Lücken schliessen. Vielen Dank dafür! --Leyo 17:06, 24. Feb. 2012 (CET)

Es sind viele. Ich muss erstmal gucken, bei welchen Nachrichten sich das überhaupt lohnt, weil ja auch einige dabei sind, die als Konfiguration dienen oder nur von unangemeldeten Benutzern gesehen werden können. Dort lohnt sich der Aufwand nicht. Ich bleibe aber dran. Der Umherirrende 20:36, 24. Feb. 2012 (CET)

Hinweis: WP:FZW#MW1.19 unter de-ch, de-at – eigentlich verkehrter Name, da das ja keine 1.19-spezifische Geschichte ist. Jedenfalls hab ich die bisherigen Links da mal zusammengefasst. Dort gibt es auch noch einiges lokal bei de-ch, de-at und de-formal an die de-Lokalisierung anzupassen. --Geitost 17:03, 1. Mär. 2012 (CET)

Die meisten Entwickler sind englischsprachig unterwegs oder aus Sprachen, wo es keine Varianten gibt. Da wird sich wohl nicht so schnell etwas tuen. Den einen Bug aufzusplitten in kleinere Einheiten, wird auch wohl nicht einfach. Der Umherirrende 19:25, 1. Mär. 2012 (CET)

Das wird es wahrscheinlich sein, bzw. die Varianten für en-gb, en-au (Australien) usw. benötigen ja kein solches Fallback, da sie automatisch auf Englisch zurückfallen. Deshalb ist das dort was Anderes. Man sollte es aber tatsächlich aufsplitten, schon möglich, dass das nicht so einfach ist. Allerdings gibt es ja bereits mind. 2 Bugmeldungen zum speziellen Fallbackproblem. Die letzte vom Januar ist noch am sinnvollsten, da dort der Seiteninhalt für de-ch usw. zuerst aus der MediaWiki-Seite für de: geholt würde und nicht zuerst der übernommenen de-ch-Sprachdatei, das würde ja nicht viel bringen, man müsste trotzdem alle möglichen Seiten weiterhin 4-fach anlegen. Oder siehst du das anders und gibt es irgendwelche gute Gründe, dass der Inhalt der de-ch-Sprachdatei vor der de-MediaWiki-Seite übernommen werden sollte? Wenn sich da was von de: unterscheidet, was recht selten der Fall ist, kann man ja in den seltenen Fällen die de-ch-MediaWiki-Seite lokal auch noch anlegen. Dann würde man meistens aber nicht auch noch de-at und de-formal benötigen (oder umgekehrt).

Das Ding ist auch, dass die beiden Bugmeldungen unterschiedliche Reihenfolgen beantragen. Wenn man sich da einig wäre, wie die Reihenfolge möglichst sein sollte, wäre es sicher auch einfacher, das mal gezielter anzugehen. :-)

Und die nächste Frage wäre, ob ein solcher Antrag (oder auch Abänderung eines der bereits bestehenden älteren Anträge) dann alle Fallbacksprachen betreffen würde (da müsste man wohl erst mal sehen, welche das noch alle sind und ob es dort auch Sinn macht) oder doch nur die 3 de-Varianten – das wäre evtl. einfacher durchzubekommen, wenn nicht gleich noch viele weitere Wikis mit betroffen wären.

Soweit mal zu den Fragen, die sich allgemein bei diesen Änderungen stellen. Möglicherweise wäre es auch sinnvoll, auf irgendeine Weise auf eine breite Diskussion dazu auf de: mit einem Konsens hinweisen zu können, damit das tatsächlich mal gefixt wird. Dafür wäre es gut, Argumente für die eine und andere Reihenfolge der Übernahme der Übersetzungen/lokalen Anpassungen zu sammeln, damit dann klar ist, welche Variante nun gewünscht wird.

Meinst du, dass es einfacher ist, das mit einer neuen Bugmeldung anzugehen (und dort auf die alten Bugmeldungen und vielen geführten Diskussionen usw. hinzuweisen und zu schreiben, dass es gesondert bearbeitet werden soll und nicht wieder als Duplikat zu dem Uraltbug laufen? Oder sollte man dafür eine der älteren Bugmeldungen weiterverwenden und präzisieren und die Duplikatmarkierung entfernen? --Geitost 21:34, 1. Mär. 2012 (CET)

Das dürfte für alle gelten, außer man sagt, das man es nur für Sub-Sprachen haben möchte, de-ch ist ja nur eine Sub-Sprache von de. Schwieriger wird es wohl bei pt/pt-br, die wohl schon mehr auseinander sind.

Viele Slawischen Sprachen haben als fallback ru, hier wird es kein Problem geben, weil auf dem Wiki nur eine Sprache, die Content-Sprache, genutzt wird und somit garkein Fallback bei lokal angelegten Nachrichten notwendig ist. Das Problem trifft also nur auf Sprachen, wo häufig vom Standard abweichende Sprachen verwendet werden. Ich muss mich da erstmal (wieder) einlesen, es kann aber gerne auch jemand anders die Initiative ergreifen, ich weiß nämlich nicht, ob man da etwas sinnvolles zusammenbekommt, ohne wieder "abgestempelt" zu werden. Der Umherirrende 21:44, 1. Mär. 2012 (CET)

Ja, so was wie pt-br oder so hab ich gemeint, man kann ja nicht wissen, ob eine solche Änderung tatsächlich in den pt-Wikis auch so gewünscht wird – bislang kamen diese Vorschläge wohl hauptsächlich von hier, was ja auch kein Wunder ist, wenn man alle Seiten gleich 4-mal anlegen muss. Das gibt es in der Form wohl tatsächlich nur hier. Und wenn die slawischen Sprachen tatsächlich auf ru zurückfallen (wusste ich auch noch nicht), dürfte das schon eher ein Problem darstellen, da diese ja auch weiter auseinander sind und untereinander nicht unbedingt so gut verständlich (wohl eher wie die dt. Dialekte oder Niederländisch zu Deutsch, und die sind ja hier durchaus eigene Sprachen – haben die dt. Dialekte eigentlich auch als Fallback Deutsch?). Vor allem wird es da wohl in den meisten Fällen nötig sein, eigene Nachrichten für die Fallbacksprachen anzulegen, da sie sich meist unterscheiden dürften – dies ist ja bei den de-Varianten gerade nicht der Fall, sondern nur in Ausnahmefällen. Denn die Änderung würde dann in der ru-WP bedeuten, dass die Benutzer mit Spracheinstellung anderer slawischer Sprachen bei der Verwendung der ru-WP bei abgeänderten ru-Nachrichten die russische Variante bekämen, die sie möglicherweise nicht so gut verstehen wie die Variante der Sprachdatei. Das könnte ein Grund sein (nach dem, was ich in den Bugmeldungen gelesen habe, dass man eine solche beantragte Änderung dann nicht durchführen und wieder als Duplikat der ersten Meldung markieren wird. Der Grund trifft aber gerade hier ja nicht zu – bei pt-br wohl auch nicht. Insofern ist es dann doch wohl besser, die Änderung nur für de: bzw. gern auch für alle Subsprachen ohne eigene Wikis zu beantragen, damit sie auch tatsächlich mal bearbeitet wird. Man sollte das Fass besser nicht zu groß aufmachen, dann wird das sicher wieder nix. Sinnvoll ist es, mal zu schauen, welche Subsprachen noch keine eigenen Wikis haben außer nl-informal und pt-br und zu überlegen, ob der Vorschlag für alle Subsprachen gleich sinnvoll ist. Ich fürchte, da sind wohl auch Varianten mit verschiedener Schrift dabei -cyrl und -latn o. Ä., die sollte man dabei besser gleich ausnehmen.

Außerdem sollte man auch darauf hinweisen, dass das Problem nicht lokal in einem Wiki gelöst werden kann, weil es in den verschiedensten Wikis wieder auftaucht (Meta, Translatewiki, Commons insbesondere), wo überall keine eigene Subversion nötig wäre, da diese nur in geschätzten 10 % der Fälle für de-ch (de-formal auch relativ selten, da oft Infinitiv statt direkter Anrede genutzt wird) und bei de-at noch wesentlich seltener nötig ist. Und man somit immer wieder neue Admins mit dem Thema beschäftigen muss, um es überall lokal anzupassen; das ist ja ziemlicher zusätzlicher Aufwand und eigentlich so gar nicht (oder nur mit sehr großem Aufwand) machbar, weshalb es ständig weitere englische Texte für die Subvarianten in den verschiedenen Wikis zu fixen gibt (und dabei dann wie im Translatewiki auch noch auf Bugzilla verwiesen wird, man also doch weiter mit englischem Text leben muss oder die Subsprachen gar nicht verwenden kann).

Da du bei der ganzen Chose einen guten Durchblick und dich ja in letzter Zeit schon viel damit befasst hast, fände ich es schon ganz sinnvoll, wenn du das in die Hand nähmest (und andere dabei unterstützend mitwirken). :-) Man kann es dann ja hier und/oder auf FZW genauer besprechen, damit diese Aktion diesmal auch erfolgreich sein kann (oder man macht dafür eine Extraseite – Benutzerunterseite oder so –, wo man die Argumente und Probleme damit auflisten und besprechen kann und auch die vorhandenen Subsprachen). Jedenfalls sollte man das Ausmaß dieses Bugs über die letzten Jahre und auch zukünftig weiter mal genauer beschreiben, denn das ist bislang in Bugzilla wohl leider noch gar nicht übergekommen. Etwas weitere Recherche kann sicher nicht schaden. --Geitost 23:14, 1. Mär. 2012 (CET)

Ja, ich schau mal. Erstmal ein weiteren Schwung an Nachrichten angelegt. Der Umherirrende 20:11, 3. Mär. 2012 (CET)

Darf ich euch einladen auf Wikipedia:Technik/Skin/Werkstatt/Fallback-Sprachen zur

• Problemdefinition, Sprachenüberblick,
• Vorgeschichte,
• Lösungsansätze,
• Formulierung eines wasserdichten Bugzilla-Textes

als voraussichtlich länger andauernde technische Projektdiskussion? LG --PerfektesChaos (D) 09:31, 6. Mär. 2012 (CET)

Hallo Umherirrender. Warum muss dort so ein fetter Klotz stehen? Gruß… --Krd 09:18, 6. Mär. 2012 (CET)

1. Grundsätzlich Wunsch und Anregung anderer Benutzer; siehe oben auf dieser Seite. Benutzerführung für Einsteiger.
2. Es würde reichen, nur das Wort „Hilfe“ als Linktitel zu schreiben; alternativ das Info-Icon ohne irgendwelchen Text. Dann kann sich niemand über fehlenden guten Willen beschweren, und Platz nimmt es auch nicht weg (float?).

Blauen Himmel allerseits --PerfektesChaos (D) 09:28, 6. Mär. 2012 (CET)

Wenn es rechts irgendwo mit beistehen würde, wäre das ja ok, aber zur Zeit klaut es locker 5 bis 6 Zeilen der Beitragsliste, und stört damit massiv. Im Kasten "Suche nach Benutzerbeiträgen" wäre dagegen Platz genug dafür. --Krd 09:48, 6. Mär. 2012 (CET)

Das meinte ich mit float. Das Problem ist vermutlich, dass diese summary-Definitionen als div an den Seitenkopf gesetzt werden; in den Kasten-Text wird man es vermutlich nicht hineinschreiben können, wenn dieser nicht geparsed wird. Allerdings könnte man der div in der summary eine absolute-position geben, so dass sie etwa 40px/40px von der rechten oberen Ecke nur den Icon zeigt (der von seiner Schriftgröße her berechenbar ist).

Was mir dazu einfällt: Man könnte nach und nach die für Einsteiger gedachten Links, die sich ohne Verlust ausblenden lassen, mit einer geschickt benannten Klasse (etwas wie help-newcomer) versehen; die Fortgeschrittenen mögen es ausblenden.

In diesem Zusammenhang sollte man aber eine Dokumentationsseite beginnen (Wikipedia:Technik/Skin/CSS/Projektweite Klassen), auf der nach und nach alle projektweit in Vorlagen und dergleichen eingeführten Klassen aufgelistet werden, die für die Benutzerkonfiguration interessant sind: Bilderwunsch, metadaten (veraltet?), help-newcomer, …)

VG --PerfektesChaos (D) 10:05, 6. Mär. 2012 (CET)

Klingt gut, ja. Können wir, bis das geklärt und umgesetzt ist, den Ursprungszustand wiederherstellen? --Krd 10:19, 6. Mär. 2012 (CET)

Ich muss zugeben, dass meine erste Reaktion auch das da war. --Schnark 10:27, 6. Mär. 2012 (CET)

@Krd: Die license to revert hast du, nicht ich. – Bei einem Feature, dass es erst seit einem Tag gibt, würde wohl kaum jemand das (vorübergehende) Verschwinden auffallen. --PerfektesChaos (D) 10:38, 6. Mär. 2012 (CET)

Die license hab ich leider auch nicht. So ganz superdringend ist es ja nicht, wenn es der Umherirrende bei Gelgenheit zurücksetzt, würde mir das reichen. --Krd 10:45, 6. Mär. 2012 (CET)

• Warum du die license nicht hättest, muss ich jetzt nicht verstehen. Ich habe dich als SG-A auf dem Schirm.
• class="help-basics specialpage-help"
style="float: none; position: absolute; top: 35px; right: 35px;" sollte in etwa passen.

Mahlzeit --PerfektesChaos (D) 12:55, 6. Mär. 2012 (CET)

Schiedsgerichtsmitglieder, die vor ihrer Wahl zum SG kein Admin waren, dürfen die Knöpfe nur für Schiedsgerichtssachen einsetzen. --Krd 13:03, 6. Mär. 2012 (CET)

Aaah – das Strichelchen soll ein Minuszeichen darstellen; soso, jetzt gibt es schon subtrahierte Admin-Rechte. Da wäre es konsequenter, wie bei „A/CU“ oder „A/B“ auch den „A/SG“ zu vergeben und in deinem Fall ein unkastriertes „SG“. Wieder was gelernt. --PerfektesChaos (D) 22:36, 6. Mär. 2012 (CET)

Ich habe das Icon mal rechts oben in die Ecke gebracht, wo auch die Lesenswert/Exzellent-Hinweise stehen. Nimmt kein Platz mehr weg, aber nimmt ein Neuling das noch wahr? Ich hatte specialpage-help überall eingetragen, damit man vereinfacht alle Hilfen ausblenden kann. Der Umherirrende 18:47, 6. Mär. 2012 (CET)

Stört jetzt nicht mehr, wird aber mMn vom Neuling auch nicht mehr wahrgenommmen. Btw, Hilfe:Benutzerbeiträge hatte am 5. März ca. 213 Aufrufe, im ganzen Februar zusammen ca. 69. Fragt sich nur; ob da hauptsächlich Neulinge oder genervte draufgeklickt haben, geht aus den Daten allerdings nicht hervor. ;) --Krd 19:25, 6. Mär. 2012 (CET)

Ich finde die Idee einer Verlinkung der Hilfe garnicht mal so schlecht. Wenn es jetzt nicht mehr stört, spricht ja erstmal nichts gegen eine kleine Testphase, würde ich sagen. Kommentare willkommen. Habe auch nichts dagegen, wenn ein Admin das ganze wieder entfernt. Der Umherirrende 21:14, 6. Mär. 2012 (CET)

Wenn man es für alle Spezialseiten usw. gleichaussehend hinbekommen würde, und zwar so, dass es keinen Platz kostet, ist es tatsächlich eine sehr gute Idee. Vielleicht sollte man das Layout gleich über eine Vorlage lösen? --Krd 21:28, 6. Mär. 2012 (CET)

• Icon-Position:
  • @Umherirrender: Lieb, dass du die Kritik gleich mundgerecht mit servierst; da fällt es leichter, dem beizupflichten. Das Icon fällt dem Hilfesuchenden nicht auf.
  • topicon ist wohl zu schlicht, fürchte ich; es müsste schon in den Kasten hinein, wo die controls stehen; und da wäre es auch in unmittelbarer Nähe zu „Zugehöriger Namensraum“, von dessen Erklärungsbedarf die Angelegenheit ja mal ausgegangen war. Magst du mal mit dem von mir vorgeschlagenen style probieren?
• help-basics habe ich auch unter dem Gesichtspunkt dieses mir neulich bekanntgewordenen privaten Stil-Vorschlags angeregt. Damit ließen sich redundante Wiederholungs-Zusammenfassungen aus den Hilfeseiten ausblenden; jedoch nur, wenn dadurch keine Lücke im Text entsteht.
  • specialpage-help wäre mir zu speziell.
• Alle Spezialseiten gleich – das wird nichts bringen. Dafür ist das Layout viel zu unterschiedlich; viele haben auch die summary mit Kurz-Infos und Hilfelinks bereits als Text, da wäre ein i-Icon dann redundant und störend. Ich bin gestern nacht mal durch sämtliche Spezialseiten durchgegangen und hatte auch ähnliche Überlegungen angestellt, jedoch wieder verworfen.

Schönen Abend --PerfektesChaos (D) 22:36, 6. Mär. 2012 (CET)

Passt den die absolute Positionierung auch mit allen Skins? Der Umherirrende 19:13, 7. Mär. 2012 (CET)

Hallo. Kann der Hausherr oder einer der mitlesenden vielleicht etwas für die Extra-Editbuttons tun, so dass der benutzerdefinierte Teil wieder geht, und dass das auch wieder in andere Wikis einbindbar ist? Danke! --Krd 17:45, 8. Mär. 2012 (CET)

Nur zur Info: Ich selber nutze das ganze nicht.

Ich hatte vor ein paar Tagen schonmal etwas kopiert, aber dann kam rev:112573 und hat es wieder zerstört. Gestern abend hatte P.Copp etwas gepostet, aber ich wollte den dort noch eine Chanche geben, drüber zuschauen. Ich habe es aber jetzt kopiert. Der Umherirrende 17:58, 8. Mär. 2012 (CET)

Falls wir uns mal irgendwann irgendwo sehen, gehen die Getränke auf mich! Danke! --Krd 18:05, 8. Mär. 2012 (CET)

Hi,

ich beziehe mich auf diese Verbesserung und rege folgende Verfeinerung der Gestaltung an:

Abschnittsüberschrift [Bearbeiten * Abschnitt hinzufügen]

Gründe:

• „Bearbeiten“ unmittelbar an der Überschrift wie bei allen anderen
• „Abschnitt hinzufügen“ verweist an das Ende
• Optische Trennung der beiden Wortgruppen nur durch „|“ ist zu mager; mit Leerzeichen und einem breiteren Platzhalter als „|“ besser als zwei unterschiedliche Links wahrnehmbar.

Ich hoffe, dass jetzt die lästige Angewohnheit mancher Bearbeiter aufhört, an den letzten Abschnitt mit == einen neuen dranzuknallen – woraufhin das in der Summary die Bezeichnung des letzten, bekannten und schon abgegessenen Abschnitts erhält, und niemand auf der Beo mitbekommt, dass ein neues Thema begonnen hat.

LG --PerfektesChaos (D) 13:56, 8. Mär. 2012 (CET)

+1, insgesamt eine sehr gute Idee, aber die Langfassung wäre noch besser. --Krd 17:43, 8. Mär. 2012 (CET)

Ich habe den Bearbeitenlink rechts am Rand stehen, da ist es besser, wenn die Bearbeiten untereinander sind und das neue links davon. Über den Trenner lässt sich sicher streiten. Das Skript kopiert den Link von oben nach unten, das bedeutet bei Monobook ein "+", aber bei Vector gibt es dann die Langform, weil oben der Reiter auch mit langtext beschriftet ist. So gibt es zumindestens keine Probleme mit der Lokalisierung. Der Umherirrende 18:03, 8. Mär. 2012 (CET)

1. Zur Langfassung:
   • Für den Anfang sollte das HTML-Element, das ja in der deutschsprachigen WP auf deren MediaWiki:Common.js definiert ist, als festkodiertes jQuery-Element gebaut werden, und die Zeichenkette "Abschnitt hinzufügen" ohne Spielkram benutzt werden.
   • Wenn es lokalisiert/i18n werden soll, müsste man ein internationales Gadget daraus machen. Dann steht die Beschriftung ja sicher in irgendeiner Systemnachricht, und die kann mit mw:ResourceLoader/Version 2 Design Specification #Implementation proposal für mw.message() verfügbar definiert werden. Das ist Zukunftsmusik und bedarf des RL2; darauf können wir gerne zurückkommen.
2. Zur Links/rechts-Frage:
   • Über mw.user.options.get("gadget-editsection-left") oder mw.user.options.get("gadget-editsection-right") oder keines von beiden lässt sich herausfinden, ob sie am Fensterrand stehen oder nicht. Wobei ich keines von beiden habe, aber in der Wirkung offenbar gadget-editsection-right sehe; dies liegt wohl an mw.config.get("skin") = "vector".

Stets der Benutzerfreundlichkeit verpflichtet --PerfektesChaos (D) 19:02, 8. Mär. 2012 (CET)

Wenn ich es richtig verstehe, dann wird in der Monobook.js/Vector.js das ganze hinter die Überschrift gebracht. Mit Gadget-editsection-left kann man sie vor die Überschrift bekommen, mit Gadget-editsection-right oder oldEditsectionLinks an den rechten Rand. Wäre vermutlich besser, wenn man das Umdrehen mit in die Gadgets einbaut, dafür muss aber sicher gestellt sein, das site bereits gelaufen ist. Der Umherirrende 20:30, 8. Mär. 2012 (CET)

Wobei ich mich gerade frage, ob die beiden Gadgets überhaupt noch funktionieren.

• editsection-right: Trifft erst nach site ein und kann dann nicht mehr wirken, es wirkt nur noch das CSS
• editsection-left: Die Überschriften stehen rechts, außer der Bearbeiten-Link des Einleitungshelferlein

Einen richtigen Unterschied sehe ich da irgendwie nicht (mehr). Sehr verwirrend (war es aber auch wohl unter 1.18) Der Umherirrende 20:47, 8. Mär. 2012 (CET)

Das ist machbar. Ich beginne mal Richtung Wochenende, mir Gedanken zu machen, wie man robust und effizient mit den Einzelteilen und den aus dem vorhandenen Dokument und von ca- geerbten Verlinkungen eine geeignete Jonglage zaubert. Wenn ich das richtig deute, wäre nur editsection-right von einer Vertauschung betroffen, während die Standard-Reihenfolge für alle Benutzer (erst „Bearbeiten“, danach „Abschnitt hinzufügen“) auch bei editsection-left gilt, damit am linken Rand alle „Bearbeiten“ untereinander stehen. Wenn mir jemand zuvorkommt, bin ich auch nicht böse. Danke schon mal für die optische Trennung der beiden Links. --PerfektesChaos (D) 20:59, 8. Mär. 2012 (CET)

Jetzt bin ich auch verwirrt.

• Die Beschreibung in editsection-right.js stimmt nicht mit dem überein, was sowieso schon passiert. Der Name von editsection-left passt überhaupt nicht zu dem, was tatsächlich stattfindet.
• oldEditsectionLinks wird anscheinend nur von MediaWiki:Monobook.js/MediaWiki:Vector.js benutzt, nicht aber von MediaWiki:Common.js. Das sollte aus der globalen Variablerei verschwinden, etwa als mw.libs.dewiki.editsectionLinksLeft. „old“ gibt es sowieso nicht; wie viel Jahre alt ist ein old? Auf benutzerdefiniertes oldEditsectionLinks kann man weiterhin reagieren; wenn jemand sich seinen eigenen Namensraum zukleistert, ist das okay.
• Die ganze Angelegenheit sollte im Paket aufgearbeitet werden; zusammen mit Einleitungshelferlein ggf. auf jQuery und den Skin-Skripten geschlossen gelöst werden.
• Zuerst sollte mal präzise beschrieben werden, was eigentlich wann mit/ohne welchem Gadget unter welcher Skin passieren soll.

Oje. --PerfektesChaos (D) 21:50, 8. Mär. 2012 (CET)

Ich benutze zwar fast immer die Tastatur, um einen neuen Abschnitt zu erzeugen, möchte mich aber trotzdem für die Idee und die Umsetzung bedanken. Coole Sache, das. Dankeschön und Gruß von --Schniggendiller Diskussion 01:39, 9. Mär. 2012 (CET)

Ein herzliches Dankeschön auch von meiner Seite! Sobald davon ausgegangen werden kann, dass es keine Änderungen am neuen Feature mehr gibt, kann dann auch die Vorlage:Hinweis neuer Abschnitt angepasst werden. --Leyo 10:17, 9. Mär. 2012 (CET)

Ich gehöre zu denjenigen, die der Ansicht sind, dass der Bearbeiten-Link zuerst kommen sollte; außerdem gibt es durch den Code einen doppelten Accesskey, sodass ein Alt-Shift-+ erst noch durch Enter bestätigt werden muss (zumindest im Firefox). Ich schlage daher diese Änderungen vor, sie sind auch getestet (im Debug-Mode wegen des grandiosen Cache-Verhaltens). --Schnark 11:25, 9. Mär. 2012 (CET)

Und eine Stunde später ist der Cache sogar im normalen Modus aktuell! Hat da womöglich jemand inzwischen den Bug behoben? --Schnark 12:26, 9. Mär. 2012 (CET)

Doppelter Acesskey ist natürlich ungünstig. Über die Reihenfolge lässt sich, wie schon angedeutet, streiten. Ich habe es aber trotzdem gemacht. Die Idee war aber nicht von mir, siehe Wikipedia:VV#Zusammenfassung. Der Umherirrende 16:03, 9. Mär. 2012 (CET)

@Leyo (Null-Edit-BK: „sollte der Abschnitt ev. besser nach MediaWiki Diskussion:Common.js verschoben werden?“):

• Ich bereite derzeit die Einrichtung von Wikipedia:Technik/Skin/Werkstatt/editsection vor. Grund: Es sind drei Gadgets (einschließlich Pfeil-hoch) betroffen, dazu mindestens drei CSS-Seiten und MediaWiki:Common.js, MediaWiki:Monobook.js, MediaWiki:Vector.js. Das sind ca. 8 Seiten, die alle irgendwie an dieser Abschnittsüberschrift herumbasteln, und die allmählich mal unter den neuen Bedingungen koordiniert werden müssten.
• Die Disku sollte nicht auf einer Einzelseite davon, sondern zentral erfolgen – und es sollte eine Gesamtlösung herauskommen, die auch langfristig i18n/RTL/RL2 ist.

Grüße --PerfektesChaos (D) 11:46, 9. Mär. 2012 (CET)

Übertragen nach Wikipedia:Technik/Skin/Werkstatt/editsection

– wäre hier erl. VG --PerfektesChaos (D) 23:02, 9. Mär. 2012 (CET)

Der IE 8 mag eine Seite nicht, der FF rennt:

• Wikipedia:Redaktion Bilder/Arbeitsliste kann ich problemlos aufrufen.
• Wikipedia:Redaktion Bilder bindet diese Seite ein, die dauert Minuten zum Laden. Nehm ich die Liste raus, alles OK.

Die Frage steht schon auf WP:Fragen zur Wikipedia#Wikipedia:Redaktion Bilder und mumifiziert gerade. Du bist ja Spezi für so etwas... Gruss --Nightflyer (Diskussion) 16:43, 9. Mär. 2012 (CET)

Bei mir stürzt der IE auch bei nur der Liste ab. Die Seite an sich ist nicht sehr groß, aber irgendetwas stört den Browser an dieser Seite. Die {{Vorlage}} wird häufig eingebunden, aber die ist vom Design nicht sehr aufwendig. Aktuell keine Vermutung. Der Umherirrende 16:49, 9. Mär. 2012 (CET)

Wofür ist das Noinclude erforderlich? Dadurch fehlt dem ersten Absatz der Bearbeiten-Link. --Seth Cohen (Diskussion) 00:02, 10. Mär. 2012 (CET)

Jetzt passt es. --Seth Cohen (Diskussion) 00:06, 10. Mär. 2012 (CET)

Wie wär's, Vorlagenänderungen in Zukunft etwas häufiger zu begründen/kommentieren? --Leyo 02:47, 10. Mär. 2012 (CET)

Mal sehen. --Seth Cohen (Diskussion) 15:59, 10. Mär. 2012 (CET)

Das Noinclude ist wichtig, damit die Hinweis nicht auf der Vorlagenseite selber angezeigt wird. Aber dein Fix ist richtig und sollte auch keine Nebeneffekte haben. Ich hatte ich nicht gesehen, das der Bearbeiten-Link dort fehlte und deine Änderung das ganze reparierte. Der Umherirrende 10:09, 10. Mär. 2012 (CET)

Alles klar. --Seth Cohen (Diskussion) 15:59, 10. Mär. 2012 (CET)

Hallo Umherirrender, kannst Du vielleicht dazu etwas sagen? Gruß --tsor (Diskussion) 15:54, 14. Mär. 2012 (CET)

Antwort dort. Der Umherirrende 20:02, 14. Mär. 2012 (CET)

Schau mal bitte: http://wiki.openstreetmap.org/wiki/WIWOSM

Das würde ich gerne nächste Woche Montag in der dt. Wikipedia live schalten, siehe auch maps-l. Daher meine Frage, ob das eine Nachricht auf der Hauptseite wert sein könnte. Nach dem Motto: "Die OpenStreetMap-Karte verfügt über eine neue Funktion, mit der die OSM-Objekte für einen Artikel hervorgehoben werden, wenn diese mit einem Wikipedia-Tag versehen sind. Mehr..." Motivation wäre auch, dass mehr Leute von diesem kleinen, komischen Kartenlink oben rechts erfahren. Ich hab mir mal sagen lassen, dass das immer noch nur eine Minderheit der Leser weiss. Außerdem braucht es unmassen Leuten die Objekte verlinken, wir haben 1 Mio deutsche WP-Koordinaten aber nur 70.000 OSM-Linien&Flächen mit Wikipedia-Tag in OSM. Findest du die Idee gut oder sollten wir das lieber still und heimlich einführen? --Kolossos (Diskussion) 21:11, 14. Mär. 2012 (CET)

Dafür sollte es durchaus eine Hauptseitenmeldung geben, denn immer wieder sind Leute recht überrascht, dass WP noch viel mehr hat, als nur den Artikel. Der Vorschlag sollte auf Wikipedia Diskussion:Hauptseite/Wikipedia aktuell hinterlegt werden, da tummeln sich hin und wieder ein paar Leute, die die Formulierung gern verbessern.

Da der Kartenlink recht unscheinbar ist, hatte ich schon überlegt, ihn mit Fettschrift zu hinterlegen. Ich reiche diesen Gedankengang mit Bitte um Umsetzung einfach mal an Den Umherirrenden weiter. ;) --32X → Autorengilde № 1 10:39, 15. Mär. 2012 (CET)

Entwurf ist eingestellt: Wikipedia_Diskussion:Hauptseite/Wikipedia_aktuell#Neues_Feature_in_OSM-Karte_-WIWOSM --Kolossos (Diskussion) 19:52, 15. Mär. 2012 (CET)

Ich finde ein solchen Hinweis auch nicht schlecht. Die Anbindung von OSM ist ja schon an vielen Stellen passiert, da sollte man eine solchen Hinweis gut verkraften können. Vorallem ist es ja auch ohne kommerziellen Gedanken oder so. Ich denke aber, das ein Link auf die Karte in Fettschrift unverhältnismäßig wirkt, vorallem weil der andere Text in der Zeile auch normal geschrieben ist. Es fällt dann auf, aber schon enorm. Vielleicht wäre ein Tooltip ein Anfang? So dass eine Beschreibung für den Leser, der den Link findet, aber dann nicht draufklickt vorhanden ist. Wird nicht umbedingt mehr Leser zum Link ziehen, aber eine Beschreibung ist immer gut. Der Umherirrende 20:19, 15. Mär. 2012 (CET)

Hallo Umherirrender, kann man dich überreden (und kannst du es) die neuen Checkboxen und Systemnachrichten auf der Beo so umbenennen, dass man sie versteht? Ist "Zugeordneter Namensraum" eine eher unverständliche Verkürzung für die Funktion "Namensraum und zugehörige Diskussionen auswählen"? lg, --Erzbischof 00:27, 2. Mär. 2012 (CET)

Ja, das ist es. Aber dein Vorschlag ist auch etwas lang. Außerdem kann man es ja auch andersherum machen, daher hat man beim Übersetzen von "Associated namespace " sich so entschieden. Auf der Beobachtungsliste gibt es die Checkboxen aber nicht. Neu ist die Checkbox auf Spezial:Beiträge, seit längerm schon auf Spezial:Letzte Änderungen. Mir war auch schon hier aufgefallen, das es jemand nicht gut findet, aber die Alternative ist auch nicht besser, fande ich. Der Umherirrende 15:13, 2. Mär. 2012 (CET)

Ok, lass' ich gelten. Spontan faellt mir naemnlich auch nur noch ("Zusammengehoerige Namensraeume') ein. --Erzbischof 17:29, 2. Mär. 2012 (CET)

Beim Angucken der anderen Sprachen könnte man auch von "Gekoppelten Namensraum" sprechen. Der Umherirrende 18:23, 2. Mär. 2012 (CET)

„Zugehöriger Namensraum“? --Geitost 18:35, 2. Mär. 2012 (CET)

Habt ihr den Knopf wirklich auch auf der Beo? Ich suche den dort vergeblich (und auch mit Vector und de:-Einstellung krieg ich den nicht). Ich hab den nur bei den Benutzerbeiträgen und bei den letzten Änderungen. Schade eigentlich, dass er nicht auch auf der Beo erscheint und es dort nur „Auswahl umkehren“ gibt. Kann man das dort nicht auch einführen? --Geitost 18:42, 2. Mär. 2012 (CET)

Genau, das war mein Fehler, ich meinte auch "Spezial:Beiträge". --Erzbischof 18:46, 2. Mär. 2012 (CET)

PS: "Diskussionen und Inhalte auswaehlen" --Erzbischof 18:48, 2. Mär. 2012 (CET)

Brainstorming Teil 5(?): „Verknüpfter Namensraum“ --Geitost 18:51, 2. Mär. 2012 (CET)

Für die Beobachtungsliste hatte ich auch mal ein Bug erstellt. Ich habe es im translatewiki geändert. Könnte morgen dann auch hier sein, mal schauen wie sich das macht. Der Umherirrende 19:05, 2. Mär. 2012 (CET)

Bedankt. Na, ist ja komisch, dass trotz der Bugmeldung das nun nur für die Beiträge neu eingeführt wurde. Aber vielleicht ändert sich das ja irgendwann noch mal.

„Verbundener Namensraum“ wäre auch noch eine passende Übersetzung ansonsten. Aber mal schauen, wie’s ankommt. --Geitost 19:13, 2. Mär. 2012 (CET)

Warum moechtet ihr an einer woertlichen Uebersetzung des ebenfalls unverstaendlichen englischen Originals fest halten - "Diskussionen und Inhalte" trifft es doch genau die Funktion? --Erzbischof 19:30, 2. Mär. 2012 (CET)

„Diskussionen und Inhalte“ finde ich wesentlich unverständlicher, da 1. das Wort „Namensraum“ nicht drin vorkommt und 2. auch auf Diskussionsseiten Inhalte erstellt werden, auch Diskussionen enthalten ja Inhalt. Oder was soll nun der große Unterschied zwischen den Inhalten auf Benutzerseiten und Diskussionsseiten sein? Dass zu jedem normalen Namensraum jeweils ein Diskussionsnamensraum und zu diesem wiederum der zugehörige normale Namensraum gehört, dürfte jedoch allgemein bekannt sein. Das lernt ja auch jeder Neuling direkt bei den ersten Schritten hier. Insofern sehe ich da keine Unverständlichkeit. --Geitost 19:41, 2. Mär. 2012 (CET)

PS: Fürs Translatewiki wär dieser Vorschlag auch eh nix, da es keine Übersetzung des engl. Textes der Nachricht mehr darstellt. Solche weiten Abänderungen der Übersetzung – in welcher Form genau auch immer – wären dann nur lokal möglich (per Erstellung von 4 zusätzlichen MediaWiki-Seiten). Auch da sollte mMn aber das Wort „Namensraum“ jedenfalls nicht fehlen. Mir fällt für so eine lokale Variante nur etwas Umständliches wie „Namensraum und zugehöriger Diskussionsnamensraum“ ein, das wäre sehr deutlich, aber halt auch länger. Muss man wissen, ob man so was will und das wirklich nötig erscheint. Hierbei würde der Text aber fast schon bis zum Zeilenende gehen. --Geitost 19:48, 2. Mär. 2012 (CET)

Ich jetzt auch mal, leidenschaftslos:

• „Namensraum mit Diskussion“
• „Namensraum und Diskussion“
• „Namensraum einschließlich Diskussion“

Als ich das erste Mal über dieses Feature stolperte, musste ich erstmal eine Probe-Filterung machen, um genauer zu sehen was da jetzt passiert. Ich hatte aber schon gerüchteweise davon gehört und bin da relativ fit; für einen Normalbenutzer ist die Mitteilung aber völlig kryptisch.

Ist die Verlinkung auf den Abschnitt einer Hilfeseite möglich?

Schönen Abend --PerfektesChaos (D) 20:56, 2. Mär. 2012 (CET)

Das klingt schon besser/verständlicher. „Einschließlich“ find ich unnötig lang, die „mit“- oder auch „und“-Variante fänd ich da am besten, „mit“ würde die Zusammengehörigkeit wohl mehr betonen.

Ein Link ginge sicher auch, vielleicht nur das Wort „Namensraum“ auf Hilfe:Namensräume verlinken? Von dort kommt man dann auch zu den Hilfeseiten für die einzelnen Namensräume. Wobei ich den Link vorne vor dem Auswahlmenü für die Namensräume bei „Namensraum:“ besser aufgehoben fände (so wie direkt darunter beim Link unter „Markierungs“-Filter auf die Spezialseite). Denn wenn man das erste Wort hinter dem Klickknopf verlinkt, kann man nicht mehr darauf klicken, um die Option anzuwählen. Zurzeit kann ich auf „Zugeordneter“ oder „Namensraum“ klicken, um die Option anzuklicken. Man müsste also wesentlich exakter klicken, das wäre wohl von Nachteil. --Geitost 21:44, 2. Mär. 2012 (CET)

Was spricht dagegen die Hilfeeinblendung zu lesen, die erscheint, sobald man die Maus über diese Option führt? Da ist übrigens schon vom zugehörigen Namensraum die Rede. Gruß --[[kgh]] (Diskussion) 00:01, 3. Mär. 2012 (CET)

Ist immer so ne Sache mit Einblendungen, mit denen man gar nicht rechnet. Ich hatte die bislang hierbei jedenfalls noch nicht gefunden, obwohl ich hier heute mehrfach diese Funktion angesehen und drauf rumgeklickt hab. Tja. Das ist bei rollback auch wohl ähnlich, das ist auch so ein Problem dabei. Wenn jedem beim Ansehen dieser Funktionen gleich völlig klar wäre, dass dort ein Hilfetext zu finden ist, dann wäre die Benennung wohl nicht ganz so wichtig. Aber der Hilfetext blendet sich oft gar nicht ein. Da muss man schon exakt darauf gehen und mit der Maus gezielt darüber stehen bleiben, und zwar ohne draufzuklicken, dann erscheint er nämlich nicht. Vielleicht wäre das auch noch irgendwie verbesserungsfähig, ich weiß nicht. --Geitost 00:15, 3. Mär. 2012 (CET)

• Verlinkung – ich hatte nicht gemeint, die Vokabel „Namensraum“ auf Hilfe:Namensräume zu erklären, sondern einen Abschnitt einer Hilfeseite (etwa zum Kontext dieser Spezialseite passend), wo erklärt wird: „Wenn du ein Kreuzelchen machst und beispielsweise ‚Portal‘ auswählst, dann bekommst du auch alles unter ‚Portal Diskussion‘ mit aufgelistet.“
• Inline-Hilfe – eigentlich ein wertvolles Feature, aber völlig wertlos, wenn nicht durch ein Icon (↑ oder ?) signalisiert wird, dass hier ein solches PopUp versteckt wäre; sonst geht da nie jemand mit der Maus hin. Ansonsten kann man bei einer Abkürzung gelernt haben, dass man zu HTML die Langform per Tooltip bekommen könnte, mehr würde man aber nicht erwarten. Ich wüsste nicht, dass und wo in der WP derartige „Infoboxen“ schon vorhanden wären (auf Beo und Beiträge und Versionsgeschichte sind sonst keine; wenn, dann müssen alle Optionen auf allen Seiten einen minimalen Tooltip haben, damit ich die Erwartung hätte, auch an diesen Feldern könnte es einen geben). Ich kann mit Tooltips vermeiden, erst aus der Seite heraus und auf eine ganz andere Seite springen zu müssen, und dann wieder an die alte Stelle, wo war ich doch gleich? Für eine kurze Bedeutungserklärung (wie Glossar) oder kleinen Bedienungshinweis optimal, gerade auf Hilfe-Seiten und Formularen. – Es gibt mit jquery.tipsy ein relativ neues Modul, das HTML-formatierte Tooltips unterstützt.

Schönes Wochenende --PerfektesChaos (D) 10:37, 3. Mär. 2012 (CET)

Schade das es gestern abend kein Export der neusten Übersetzungen gab (Warum eigentlich immer dann, wenn man es braucht?), aber ich würde trotzdem mal abwarten, wie das ankommt. So passt jetzt auch der Tooltip zum Text. Das an einigen Stellen Tooltips schlummern, die man nicht erwartet, ist natürlich noch Verbesserungsfähig, sollte man mal auf Bugzilla vorschlagen. In MediaWiki:Namespace lässt sich leider kein Link einbauen und in den anderen Nachrichten (namespace_association/invert/history-show-deleted/sp-contributions-toponly) auch nicht. Der Umherirrende 18:42, 3. Mär. 2012 (CET)

Ja, schade auch, dass das mit dem Link zur Hilfeseite hier nicht geht.

Die Tooltipps sollte man wirklich mal verbessern, damit sie auch jemand überhaupt findet. Dann erübrigen sich genauere Beschreibungen der Funktionen oder Links auf weiterführende Hilfeseiten zur Funktion nämlich ziemlich und man müsste nicht mehr ganz so viele oder auch lange Diskussionen um die perfekte, verständlichste genaue Benennung solcher Grundfunktionen führen. Den Vorschlag vom PerfektenChaos mit dem Symbol finde ich sehr gut, das wäre eine echt gute Lösung dafür. Magst du das mal vorschlagen gehen? Grüße --Geitost 19:24, 3. Mär. 2012 (CET)

Wobei das aus Gründen der Barrierefreiheit immer nur ein zusätzliches Angebot sein kann; der klassische Link muss (wo technisch möglich) erhalten bleiben und darf dadurch nicht ersetzt werden. Wer mit einer kurzen Erläuterung klarkommt, dem ist an Ort und Stelle geholfen; wer es alles nicht versteht, benötigt ein Link auf eine Hilfe-Seite mit ausführlicher Erklärung des Zusammenhangs. LG --PerfektesChaos (D) 11:39, 4. Mär. 2012 (CET)

Ich glaube nicht, dass es eine Hilfeseite gibt, die diese Funktion speziell genauer erläutert. Die müsste wohl erst noch geschrieben werden. Ich kenne jedenfalls nur die Hilfeseiten zu Hilfe:Namensräume und zu den einzelnen Namensräumen, nicht aber zur Bedienung dieser oder ähnlicher Hilfsfunktionen. --Geitost 15:27, 4. Mär. 2012 (CET)

• Die zugeordnete ist Hilfe:Benutzerbeiträge. Sie soll alle GUI-Elemente der Spezialseite reflektieren und erläutern, aber offensichtlich war da schon lange niemand mehr drangewesen.
• Gibt es irgendeine Möglichkeit, wenigstens im Kopf der Spezialseite ein Link auf die Hilfeseite unterzubringen, wenn schon die einzelnen GUI-Elemente sich nicht verlinken lassen? Oder bekommt man unten rechts die Legende verlinkt?

Sonnigen Sonntag --PerfektesChaos (D) 16:14, 4. Mär. 2012 (CET)

Bisher gab’s diese Funktion ja nur bei den letzten Änderungen, müsste also dann auf einer eventuellen Hilfeseite zu den letzten Änderungen stehen – gibt es denn eine solche?. Bei den Benutzerbeiträgen gibt es das ja erst seit dem 1. März, also 3 Tagen (neue Version MediaWiki 1.19). Kein Wunder, wenn es auf jener Hilfeseite dann nicht steht. Im Fuß der Beitragsseite sind ja bereits etliche Links, dort könnte man auch noch einen Link zur Hilfeseite für die Beitragsseite unterbringen, am besten dann so: [[Hilfe:Benutzerbeiträge|Hilfe]]. – Zurzeit nix Sonne mehr in Sicht. Grüße --Geitost 16:40, 4. Mär. 2012 (CET)

• Auf Benutzerbeiträge gibt es wohl schon etwas länger „Markierungs-Filter“, und auch das „Auswahl umkehren“ sollte der Vollständigkeit halber für die ganz Schlichten erklärt werden.
• „eventuelle Hilfeseite zu den letzten Änderungen“ – ja, sowas gibt es: Hilfe:Letzte Änderungen.
• Die Frage ist, in welchen der Systemnachrichten man Wikilinks unterbringen kann (die also geparst werden), und in welchen nicht. Ich habe damit eigentlich nichts zu tun, kenne mich da auch kaum aus, aber der Wirt unserer Disku hat da viel Ahnung von.

Sonne und Sommer wünschen kann man ja immer, so auch dir --PerfektesChaos (D) 16:58, 4. Mär. 2012 (CET)

• Kannst ja mal ne Erklärung versuchen.
• Man sollte existente Hilfeseiten zu Spezialseiten immer auch verlinken. Jetzt so du sie erwähnst, finde ich sogar auch den Link auf den letzten Änderungen dorthin ganz oben links. Dort klappt es also mit der Hilfeverlinkung.
• Bei den Beiträgen im Fuß sind ja bereits viele Links enthalten (die immer mal wieder geändert werden), dort geht’s jedenfalls.

Der Sommer kommt mit großen Schritten, warm ist es ja schon mal … dauert also nicht mehr lange. Und auch die Zeitumstellung ist ja bereits wieder in 3 Wochen. :-) Dann macht sich gleich die mMn wichtigste Änderung (des nervigsten Bugs) der neuen MW-Version bemerkbar und ich muss nicht mehr in allen Wikis einzeln die Zeit neu einstellen :-)) (denn noch im Oktober sprang sie wieder überall auf UTC zurück); man konnte die Einstellung ja nicht mal global bewerkstelligen – das wäre auch mal eine gute Änderung, wenn man alle global angebotenen einzelnen Einstellungen jeweils auch global für alle Accounts gleichzeitig umstellen könnte – bislang ist es seeeehr viel Zeitaufwand, wenn man alle einzelnen persönlichen Einstellungen auch noch in allen Wikis einzeln noch mal neu einstellen muss – da ist man Stunden mit zugange nur für ein paar der vielen Wikis des globalen Accounts.

Und wenn ich schon grad beim Wünschen bin: Ich hätte gern auch die Möglichkeit, selbst entscheiden zu können, in welchen Wikis ich eine Mailfunktion anbieten will und in welchen nicht. Da das nicht geht (und ich nur entscheiden kann, ob überall oder nirgends), habe ich mich aus verschiedenen Gründen lieber für nirgends entschieden, dann gibt’s halt keine Mail (und man kann sich dann einen Account im Translatewiki machen und mich dort ab 4 Tage nach der Anmeldung anmailen). So was wäre wirklich mal nice to have. Soviel zu meinen Wünschen bzgl. Einstellungsoptionen, falls der Umherirrende noch Lust darauf haben sollte das mal bei Bugzilla vorzuschlagen (oder hat sich diesbezüglich seit der neuen Version evtl. etwas geändert?). :-) Jetzt bin ich ziemlich vom Thema abgekommen … ;-) Grüße in die Runde --Geitost 17:48, 4. Mär. 2012 (CET)

Spezialseite mit Hilfeseite verlinken

Viele der Spezialseiten bieten die Möglichkeit per *-summary-Nachricht Text ganz oben einzubauen, wo auch Wikilinks geparsed werden, hier wäre es dann MediaWiki:Contributions-summary (auch wenns rot ist). Die Option "E-Mail-Empfang von anderen Benutzern ermöglichen" ist übrigens nicht global, vergleiche hier und Commons. Es ist zwar auf jedem Wiki die E-Mail hinterlegt (und das ist global), aber nur weil sie hinterlegt ist, kann man da nichts hinschicken. Sie kann auch nur für Passwort-Versand dienen. Das einzige Problem ist, das die Option überall standardmäßig ja ist, wenn ich mich richtig erinnere. Der Umherirrende 21:00, 4. Mär. 2012 (CET)

Auf Spezial:Logbuch gibt es so einen Wink zur Hilfeseite schon, entspricht das euren Vorstellungen? Der Umherirrende 21:08, 4. Mär. 2012 (CET)

Wink zur Hilfeseite – ja, genau; jeder Grundtyp von Spezialseiten (außer ISBN-Suche, die kann sich selbst erklären) ist bereits auf einer Hilfe-Seite reflektiert, auf der auch die GUI-Elemente nochmal ausführlich erklärt sind, und wozu das alles gut sein soll. Ich erinnere mich nur extrem dunkel, dass man vor einigen Jahren solche Verlinkungen noch nicht in die Spezialseiten einbauen konnte, und dass dies dann als FeatureRequest diskutiert wurde. Vielleicht ist das Resultat ja damit inzwischen eingetrudelt. Wenn irgendwann mal nichts Dringendes anstehen sollte und du dich langweilst, kannst du ja in die MediaWiki:-summary solche Hilfe-Links einstreuen. Es sieht so aus, als ob dann immer an der gleichen Stelle mit gleichem Erscheinungsbild ein solches Info-Link erscheinen würde; das wäre äußerst kundenfreundlich. Schönen Abend --PerfektesChaos (D) 21:29, 4. Mär. 2012 (CET)

Dann einfach mal gucken. Der Umherirrende 21:47, 4. Mär. 2012 (CET)

Mach ich; ich habe eine Überschrift auf meiner ToDo-List notiert und komme irgendwann mal mit einem halben Dutzend Zuordnungen Spezial→Hilfeseite zurück, wenn ich gelegentlich an Hilfeseiten gearbeitet und gesammelt habe. --PerfektesChaos (D) 22:11, 4. Mär. 2012 (CET)

Das sieht doch schön aus mit dem Link oben. Und wieder was hinzugelernt … :-) --Geitost 23:04, 4. Mär. 2012 (CET)

Bei der Beo könnte man analog dazu auch noch Hilfe:Beobachtungsliste oben verlinken, erscheint mir auch recht sinnvoll zu sein. --Geitost 23:13, 4. Mär. 2012 (CET)

Und wo ich schon grad bei E-Mail war: Auf Spezial:E-Mail wär eine Verlinkung zu Hilfe:E-Mail besonders sinnvoll, dort sind ja viele spezifische Infos dazu samt FAQ-Liste vorhanden. --Geitost 23:20, 4. Mär. 2012 (CET)

Ich habe mal MediaWiki:Emailuser-summary und MediaWiki:Changeemail-summary angelegt, bei den Linktexten bin ich mir nicht ganz sicher, ob die gut sind. Auf der Beobachtungsliste tue ich mich aber schwer, weil dann wohl schnell ein Aufschrei ist, das zu viel Platz "verschwendet" wird. Auf Hilfe:E-Mail sollte man aber noch etwas auf die neue Spezialseite umschreiben und das eine leere neue Adresse das löschen bewirkt. Der Umherirrende 21:46, 5. Mär. 2012 (CET)

Du warst ja wohl schon fleißig; ich habe jetzt kaum noch etwas gefunden, wo noch ein zusätzliches Link auf die Hilfe sinnvoll und möglich wäre.

• Spezial:E-Mail-Adresse ändern vielleicht noch auf Hilfe:E-Mail?
• Spezial:Version – Könnte noch in unseren eigenen ANR verlinken:
  „MediaWiki ist eine Freie Software …“

Und weil ich es dabei gerade gefunden habe:

• MediaWiki:userjspreview – Falls hier Verlinkung möglich, dann bitte Wikipedia:Technik/Skin/JS#Browser-Cache angeben.

Ich elininiere damit die Angelegenheit wieder von meiner ToDo-List. LG --PerfektesChaos (D) 10:54, 5. Mär. 2012 (CET)

MediaWiki:Userjspreview: Wenn =-Header gehen, sollten auch Wikilinks gehen. Welches Wort möchtest du verlinkt haben, bin mir unschlüssig. Parallel für MediaWiki:Usercsspreview auf Wikipedia:Technik/Skin/CSS#Browser-Cache, aber welches Wort? Das Verlinken von MediaWiki auf Special:Version halte ich für eine Kleinigkeit, auf die man wohl verzichten kann, weil es jeder auch so finden wird. Der Umherirrende 21:52, 5. Mär. 2012 (CET)

1. Wikipedia:Technik/Skin/CSS #Browser-Cache ist nur eine Art Weiterleitung und sollte eher nicht verlinkt werden; Usercsspreview müsste Wikipedia:Technik/Skin/JS #Browser-Cache mitbenutzen.
2. Eigentlich passt nur die Aufforderung zum Reload. Wie das genau passieren soll, muss man auf der verlinkten Seite nachlesen. Die angegebenen Tastenkombinationen sind ja lustig, aber eigentlich hier völlig wirkungslos. Warum, steht auf der verlinkten Seite. Der Text könnte besser lauten (verschiedene Varianten für JS+CSS zum Aussuchen):
   • Beachte: Nach dem Speichern musst du deinen Browser anweisen, die neue Version zu laden. Nähere Einzelheiten siehe hier.
   • Beachte: Nach dem Speichern musst du deinen Browser-Cache komplett leeren.
   • Beachte: Nach dem Speichern musst du deinen Browser-Cache komplett leeren. Zur Durchführung siehe Skin/JS.
3. Special:Version – ich wär gern auch in unserem eigenen Projekt geblieben, während das mw:MediaWiki/de ziemlich nichtssagend ist.
4. Beo – es würde reichen, nur das verlinkte Info-Icon ohne irgendwelchen Text einzubauen; dann kann sich niemand über fehlenden guten Willen beschweren, und Platz nimmt es auch nicht weg (float?).

Schönen Abend --PerfektesChaos (D) 22:32, 5. Mär. 2012 (CET)

E-Mail-Funktion

Noch mal zur E-Mail-Funktion, ich setz das mal etwas ab: Ist standardmäßig überall auf „ja“, das heißt die E-Mail wird automatisch in allen Wikis eingetragen, wenn ich sie nur in 1 Wiki haben will und dort eintrage. Ich hab das kürzlich (mit Version 1.18) mal in 1 anderen Wiki ausprobiert, da war sie dann auch hier direkt wieder eingetragen; hat mir alles gar nicht gefallen, was dabei herauskam (in anderen Wikis waren die E-Mail-Optionen auch immer wieder unterschiedlich eingestellt, dann müsste ich echt alle Wikis einzeln durchgehen). Bei zurzeit 525 Wikis dürfte es etliche Stunden mit diesem Rechner dauern, überall die Mailfunktion wieder auszuschalten, nur weil man sie in 1 Wiki nutzen will. Und es nützt auch nix. Wenn ich sie in einem anderen Wiki nutzen will, wird hier z. B. wieder mal automatisch das Anmeldedatum der Mail öffentlich angezeigt (und was weiß ich, in welchen anderen Wikis mit Filtern noch alles, die ich evtl. gar nicht nutze?), selbst wenn ich die E-Mail hier oder woanders gar nicht nutzen will und in dem jeweiligen Wiki auch völlig inaktiv bin – das ist wirklich bescheuert. Insofern hab ich schon mal drüber nachgedacht, mir ein E-Mail-Zweitkonto anzuschaffen, über das man mich dann anmailen könnte. ;-) Am besten nur in 1 Wiki, wo das Sinn macht + es keine aktiven Missbrauchsfilter gibt, dann könnte man auch von woanders aus dahinlinken. Alles recht umständlich jedenfalls; bei den globalen Funktionen könnte man noch vieles verbessern … --Geitost 23:04, 4. Mär. 2012 (CET)

Da die E-Mail-Adresse ein Kriterium zum Verbinden der Globalen Konten (SUL) war, wurde sie auch automatisch eine globale Einstellung, daher ist sie in allen Wikis immer die gleiche. AbuseFilter ist auf allen Wikis aktiviert worden. Das der Zeitpunkt der E-Mail-Anmeldung öffentlich ist, ist schade, aber kein so großes Manko. Viel anfangen kann man damit nicht. Der Umherirrende 20:11, 5. Mär. 2012 (CET)

Sag mal, noch ne andere Frage dazu: Hoffentlich wird’s dir hier nicht allmählich zu viel. ;-) Kürzlich wurde doch mal in den Einstellungen unter den „E-Mail-Optionen“ der kurze, dort vorhandene Erläuterungstext abgeändert, wurde wohl auf WP:AN diskutiert (müsste ich suchen gehen, vielleicht erinnerst du dich?). Warum findet sich der Text nun dort plötzlich nicht mehr wieder? Hat sich mit der neuen MW-Version irgendwas bei den Einstellungen geändert? Stattdessen finde ich den diskutierten 3-punktigen Text nun hier wieder (die Seite könnte übrigens auch nen Link auf Hilfe:Anmelden gebrauchen). Dort landet man aber über die Einstellungen und per Link auf E-Mail-Adresse festlegen gar nicht, also bekommt man diesen Infotext dort gar nicht mehr angezeigt (da man sich ja bei Eintragung der Mailadresse nicht neu anmeldet). Weißt du zufällig, woran das liegt und ob man das wieder ändern kann? Falls nicht in den Einstellungen möglich, dann sollte das zumindest als Infotext bei Spezial:E-Mail-Adresse ändern anzusehen sein, bevor man dort die Mailadresse einträgt. --Geitost 23:45, 4. Mär. 2012 (CET)

Der Text wird wohl mit dem Einbau der E-Mail-Ändern-Seite verschwunden sein, müsste ich mal genauer schauen. Der Umherirrende 20:11, 5. Mär. 2012 (CET)

Meinst du MediaWiki:Prefs-help-email? Dafür habe ich Bug 35152 aufgemacht. Der Umherirrende 14:46, 11. Mär. 2012 (CET)

Texte sind wieder da. Der Umherirrende 20:21, 15. Mär. 2012 (CET)

Hab’s auch grad gesehen. Vielen Dank, das ging ja fix. (Ich weiß nie, wann ein solcher Fix dann auch live geht, aber der Fix war echt sehr fix.) Und du findest immer so schnell die passende MediaWiki-Meldung zu allem (während ich dabei lange rumsuchen müsste). :-) Grüße --Geitost 20:28, 16. Mär. 2012 (CET)

Das ging jetzt so schnell, weil es als "regression" eingestuft wurde, es ging ja vorher und war jetzt kaputt. In so einem Fall geht es meistens zügig. Ich hatte es zufällig unter rev: (Der Gesamtübersicht der Letzten Änderungen an der Software) gesehen, aber es stand dann auch auf WP:NEU. Neue Funktionen hingegen dauern lange bis sie implementiert sind und dann lange bis sie hier ankommen. Ein System lässt sich da nicht erkennen. Der Umherirrende 20:34, 16. Mär. 2012 (CET)

Ah so, ja, da hab ich nicht geguggt. Dann muss man sich also immer überraschen lassen, wann etwas hier aufschlägt … --Geitost 20:45, 16. Mär. 2012 (CET)

Hei noch mal, hab noch mal ne andere Frage: Seit einiger Zeit (frag mich nicht, seit wann, ob nun schon vor dem Update oder nicht, ist mir grad unklar, so oft setz ich Seiten auch nicht per Hand auf „Beobachten“, Beo ist eh viel zu voll) fällt mir auf, dass die Anzeige merkwürdig ist, wenn man Seiten beobachten will und anklickt. Und nun kommt ein Beispiel zum besseren Verständnis:

• Beispiel → auf „Beobachten“ klicken → die Seite wird nun beobachtet und es erscheint anstellen von „Beobachten“ nun seltsamerweise „{{MediaWiki:Unwatch}}“, wenn man noch mal auf „Artikel“ geht (und die Seite neu geladen wird), erscheint an der Stelle dann richtig „Nicht beobachten“
• umgekehrter Weg: → auf „Nicht beobachten“ klicken → die Seite wird nicht mehr beobachtet und im Knopf steht nun wieder richtig „Beobachten“, wie es sein soll

Frage: Warum geht das bei „Nicht beobachten“, aber umgekehrt bei „Beobachten“ wird statt des Textes der Seitenname der MediaWiki-Seite angezeigt? Das ist die einzige Funktion, die ich kenne, die einen internen Seitennamen öffentlich im ANR anzeigt, insofern ist das ja nicht sonderlich toll … (und das ist keine Ausnahme, sondern seit ner Weile die Regel bei der Funktion.) Da die Beobachten-Anzeige bei den unterschiedlichen Skins ja unterschiedlich ist, sollte ich noch erwähnen, dass ich Monobook nutze. Ob das schon mal irgendwo thematisiert wurde, ist mir auch gerade unbekannt (und hab nicht danach gesucht). (… und jetzt werd ich mir die Chose noch mal mit Vector und evtl. anderen Skins ansehen – bei Vector gibt’s da ja nur ein Sternchen, muss also anders funzen, und für unangemeldete Nur-Leser ist’s dann ja zumindest nix Verstörendes).

Nachtrag: Jetzt hab ich das grad auch mal bei mw:Extension:EmailPage geprüft: Dort gibt es die Anzeige nicht. Es wird dort statt „Nicht beobachten“ oder dem Seitennamen immer der Text „nicht mehr beobachten“ angezeigt; also ist es eine lokale Anpassung. Vielleicht kann man die Anzeige ja auch einfach an die anderen Wikis anpassen, damit nicht mehr der MW-Seitenname erscheint?
2. Frage: Außerdem verstehe ich auch nicht, warum manchmal beim Klick auf „Beobachten“ oben in der URL „&action=watch&token=LANGE_ZAHLEN-/BUCHSTABENFOLGE“ erscheint und der Text des Artikels verschwindet, sodass man dann gezwungen ist, ihn noch mal neu zu laden (und weiß auch nicht, wann das passiert bzw. wie man dies vermeiden kann). Jedenfalls ist das alles auf die Dauer recht störend und nervig.

So, als 2. Nachtrag nun die Lösung der ersten Frage schon mal gefunden (mit der Anzeige des Seitennamens war’s diesmal ja nicht so schwer): ;-) Habe inzwischen beim Nachsehen den Fehler Nr. 1 gefunden (den zweiten mit dem Token aber nicht): Liegt an meinen Spezialeinstellungen Monobook in Verbindung mit de-ch. Also an MediaWiki:Unwatch/de-ch, wo genau dieser Text {{MediaWiki:Unwatch}} drinsteht, den ich auch im Artikel sehe (also muss es dann wohl seit dem 9.3. so aussehen). Dann also wohl besser statt der Einbindungen den normalen Text reinsetzen (de-at/de-formal dann entsprechend). Gilt das mit dem Einbinden wohl für viele MW-Seiten oder ist dies nur einer der wenigen Spezialfälle, wo es zu falschen Anzeigen führt? Damit hat sich auch die damit verbundene Frage geklärt, warum das beim Klick auf „Nicht beobachten“ nicht passiert, denn MediaWiki:Watch/de-ch enthält ja keine lokale Anpassung der Übersetzung. Viele Grüße --Geitost 22:00, 16. Mär. 2012 (CET)

PS: Mit Vector sieht alles wie erwartet ganz normal aus (mit dem Stern), aber beispielsweise bei Modern wird auch der MW-Seitenname angezeigt (die anderen spar ich mir dann mal). Welchen Skin nutzt du eigentlich normal? --Geitost 22:06, 16. Mär. 2012 (CET)

Bei den Nachrichten die über JavaScript in die Oberfläche gesetzt werden, funktionieren nur einzelne WikiText-Möglichkeiten, dazu gehören keine Vorlagen, sondern soetwas wie PLURAL, weil das für Lokalisierungen genutzt wird. Leider ist es schwierig zu überblicken, welche Nachricht wo und wie genutzt wird. Ich habe die Vorlageneinbindung aufgelöst. Warum wir hier einen eigenen Text nutzen, weiß ich nicht. Ich wollte nur dafür sorgen, das alle Sprachvarianten das gleiche sehen. Ich nutze Monobook, da hätte mir das auffallen können, aber so häufig nehme ich auch nicht neue Seiten auf meine Beobachtungsliste … Der Umherirrende 22:11, 16. Mär. 2012 (CET)

Ach so, mit JavaScript hat das zu tun. Danke, jetzt sieht es wieder normal aus. Damit es dir hätte auffallen können, hättest du dann auch noch zusätzlich was anderes als „de“ verwenden müssen, war insofern schon etwas spezieller. ;-)

Das mit dem Token in der URL (und Artikeltext verschwindet) scheint wohl dann zu passieren, wenn man die Seite neu lädt und sie noch nicht vollständig geladen ist (kommt mir zumindest grad so vor), vielleicht hilft es dabei ja immer abzuwarten, bis die Seite vollständig da ist. Wenn man beispielsweise eine bereits länger geöffnete Seite erst später auf die Beo nehmen will oder auch davon runter, dann kriegt man ja oft nur ne Fehlermeldung (muss irgendein Zeitablauf der geöffneten Seite sein) und muss dann die Seite noch mal ganz neu laden (oder nur die Versionsgeschichte, wenn man die Seite dann eh schließen will, geht schneller) – ich glaub, dabei passiert das dann halt auch gerne, wenn man zu schnell auf den Knopf klickt. Werd ich dann mal weiter „beobachten“, wahrscheinlich ist das nicht mal eben auf andere Art zu lösen. ;-) --Geitost 22:25, 16. Mär. 2012 (CET)

Der Token ist notwendig, damit auch nur du Seiten zu deiner Beobachtungsliste hinzufügen kannst. Vorher war es möglich, mit einem Link auf action=watch dir die Seite unterzumogeln (So wie man aktuell noch das Abmelden untermogeln kann). Jetzt musst du dort entweder extra noch ein Knopf drücken (beispielsweise Links aus E-Mails) oder wenn der Token gesetzt ist, wird dieser als Authentifikation genutzt. Wenn das JavaScript der Seite geladen ist, ersetzt es den Link hinter dem Reiter durch einen Ajax-Aufruf, dieser wird dann im Hintergrund ausgeführt und die Erfolgsmeldung oben eingeblendet. In deinem Fall dürfte die Erfolgsmeldung auf der Seite stehen, die sich dann öffnet. Dies deutet darauf hin, dass das JavaScript noch nicht fertig geladen war. Bei mir sind die Versionsgeschichten (gefühlt) eher langsam, daher funktioniert der Trick bei mir eher nicht. Der Umherirrende 22:32, 16. Mär. 2012 (CET)

Oh, echt, Seiten unterjubeln? (Dann soll’s mir recht sein und nehm das besser in Kauf.) ;-) Ok, dann weiß ich ja nun Bescheid darüber.--Geitost 23:04, 16. Mär. 2012 (CET)

Mal wieder nach vorne: Ich vermute ja, dass bei mir die Beo wohl eher deshalb so überfüllt (und unbearbeitbar) geworden ist, weil die Anzahl der Edits halt eine große Anzahl von Seiten automatisch auf die Beo gesetzt haben. Na ja, das Ganze ist halt wieder ein anderes Problem mit der Beobachten-Funktion, aber vielleicht kann man die Verbesserung der Bearbeitung der Beo (nur in Teilen) oder einer Möglichkeit zur Auswahl der Dauer der Einträge auf der Beo ja noch mal irgendwie im Auge behalten. Leider gibt es keine Einstellung: Seite beim Bearbeiten automatisch auf die Beo setzen und nach 1 Monat wieder herunternehmen. Und nur jene Seiten dauerhaft auf der Beo zu lassen, die man per Hand hinzufügt (oder evtl. auch noch die, bei der man die Seite selbst neu erstellt hat). Dann wäre die Beo automatisch wesentlich kleiner und man könnte Seiten auch nur temporär nach dem Edit beobachten statt dauerhaft (ob die Änderung in der nächsten Zeit Bestand hat). Na ja. So wie jetzt kann ich die Beo im Grunde eigentlich nur recht schlecht und begrenzt benutzen (insofern ist es relativ egal, was da drauf ist oder was nicht, wenn man entscheidende Änderungen eh übersieht). :-(

Man müsste sie in Teilen bearbeiten können, zum Beispiel nach einzelnen Namensräumen. Dann würde nicht die ganze Beo auf einmal beim Bearbeiten geladen (und lädt und lädt und lädt …) und dadurch so gut wie unbearbeitbar. So wie jetzt wird sie leider ständig größer, aber nicht mehr kleiner. Kann auch dafür leider keine gute Lösung finden, die nicht ultrazeitaufwändig wäre (jeden Artikel auf der Beo einzeln auswählen und von der Beo nehmen, wäre eine zeitaufwändige Idee). Ich hoffe dabei eher auf bessere zukünftige Lösungen seitens der Software. Sind inzwischen knapp 25.000 Einträge in der Beo, davon sicher auch viele gelöschte WL-Seiten, wo ich einfach nur irgendwann vor Urzeiten SLAs drauf gestellt hatte und die ich über meine Beo auch nie von der Beo runterkriegen werde, da gelöschte Seiten ja nie jemand bearbeitet. Und außerdem wird mir – wenn irgendwann fertig geladen – in der raw-Version nicht angezeigt, ob ein Eintrag rot oder blau ist, ob’s ihn also überhaupt noch gibt. Ein Kopieren der langen Liste hatte die letzten Male auch nicht geklappt, dabei hatte der Browser sich dann aufgehängt. :-/ Macht es evtl. Sinn, das lieber bei den Verbesserungsvorschlägen zu diskutieren oder ist die Verbesserung eher einfach ein technisches Problem für die Entwickler (und vielleicht schon mal in irgendeiner ähnlichen Weise bei Bugzilla eingetragen worden und wartet dort evtl. auf Bearbeitung)? --Geitost 23:04, 16. Mär. 2012 (CET)

Die Sache mit dem Ablaufdatum ist auch schon alt: Bug 6964. Bei der übergroßen Beobachtungsliste kann ich dir auch nicht helfen. Hast du auch schon andere Browser versucht? Vielleicht kommen die mit dem Arbeitsspeicher besser zurecht und die Seite überfordert sie nicht. Der Umherirrende 23:45, 16. Mär. 2012 (CET)

Ich dachte es mir doch, dass das Beoproblem sicher viele Benutzer betrifft und bestimmt auch schon etliche Male irgendwo angesprochen oder diskutiert wurde. Danke für den Link, da gab es ja tatsächlich schon einige unterschiedliche Ideen dazu, und 2006 ist auch schon über 5 Jahre her. Vielleicht sollte man es doch noch mal bei Verbesserungsvorschlägen diskutieren, um ein ordentliches Konzept dafür zu bekommen. Weißt du, woran es bislang bei Bugzilla gehapert hat? Am genauen Konzept, konkreten Konsensvorschlägen oder doch der Technik (kompliziert zu bewerkstelligen)? Scheint ja zu dauern, bis dabei mal was Brauchbares rumkommt. Wenn man wüsste, ob/wie man das beschleunigen könnte … ;-)

Das Problem sind ja dabei nicht nur die Diskussionsseiten von Benutzern (dort passiert ja auch mehr, die könnte ich auch mal per Hand einzeln runterwerfen, sobald sie auf der Beo aufschlagen), sondern alle Seiten, also die Menge der Seiten insgesamt, insbesondere halt auch die vielen Seiten im ANR, wo nur ab und zu mal was passiert, was insgesamt aber sehr verstopft. Man müsste alles Rote in einem Namensraum pauschal rauswerfen können, ohne die lange Beoliste aufrufen zu müssen, dann würde anschließend nur einmal angezeigt, was entfernt wurde. Und wenn man davon Einzelnes noch drauflassen will (Wiederanlegungsgefahr oder was auch immer), könnte man es einzeln wieder draufsetzen. Wer benötigt schon gelöschte Seiten auf ewig in der langen Beoliste oder existierende Artikel, wo man nur mal vor Urzeiten ne Kleinigkeit geändert hat und die danach die Bearbeitbarkeit der Beo und auch die Beo selbst verstopfen?

Der Rechner, mit dem ich es zuletzt versucht hatte und der aber nicht mehr benutzbar ist, hatte noch einiges mehr an Arbeitsspeicher zum Laden solcher Riesenseiten als der jetzige ältere – das muss ich wohl allgemein noch mal angehen. Ich probiere es dann doch besser noch mal mit verschiedenen, frisch gestarteten Browsern und frisch gestartetem Rechner mit Maximalarbeitsspeicher (dann braucht man sich nicht noch über Browserabstürze und Tabverluste zu ärgern, so was motiviert ja nicht grad) – oder ansonsten noch andere Dinge; Neuerungen sind dabei von MW ja wohl eher nicht in absehbarer Zeit zu erwarten und besser wird’s dann ja auch erst mal nicht werden. Grüße --Geitost 01:03, 17. Mär. 2012 (CET)

Ich habe mal auf Benutzer:Umherirrender/spielen.js ein Skript erstellt, welches per API durch die Beobachtungsliste geht und alle nicht mehr vorhandenen Artikel (Namensraum 0) entfernt. (Merke dir vorher mal deine Anzahl).

Vorgehensweise: Gehe auf Spezial:Meine Benutzerseite/spielen.js, kopiere das Skript in das Bearbeitenfenster und drücke auf Vorschau (kein Speichern notwendig, das ganze dient nur als Ausführungsumgebung). Danach kommt eine Meldung 'started', wenn du nun auf OK drückst, läuft das Skript los, wenn das Skript durch alle Seiten durch ist, gibt es wieder eine Meldung mit dem Text 'all done'. Fertig. Falls dein Browser zwischenzeitlich abstürzt, kannst du es immer wieder neustarten. Ich habe es zwar nicht mit so vielen Seiten getestet, hoffe aber, das es in einer endlichen Zeit durchläuft.

Falls dir das zu pauschal ist, kann man auf der Basis sicher auch eine Maske mit nur 500 Seiten deiner Beobachtungsliste bauen (Und einem Weiter-Button oder so). Da müsste ich mir aber erst etwas ausgiebiger etwas ausdenken (Aber sollte möglich sein). Der Umherirrende 01:26, 17. Mär. 2012 (CET)

Danke für die schnelle Leichtbauvariante. ;-) Ich hab es jetzt einfach mal ausprobiert, selbst wenn ich nun nicht weiß, was er da alles mit runtergeworfen hat. Aber ich meine mich vage erinnern zu können, dass sicher etliches Unbrauchbare dabei gewesen sein muss (und der Rest der roten Seiten wird sicher auch nicht so wichtig gewesen sein). Nun sind es 1.274 Seiten(!) weniger auf der Beo, :-) macht immerhin knapp über 5 % (1/20) aus, ist ja eigentlich ganz schön viel Gelöschtes dabei gewesen. Das ist ja mal ein echter Fortschritt. Vielleicht hab ich dann bei den weiteren Versuchen der Entschlackung (ist ja auch Fastenzeit, nicht?) ;-) etwas mehr Chancen. Und ich weiß dann zumindest immer, dass es die restlichen ANR-Seiten auf der Beo auch alle gibt. :-) Bau am besten mal oben in deine js-Seite so ne Art Warnung samt Anleitung ein, damit man weiß, was passiert, wenn man das nutzen will (und man auch weiß, dass man nicht weiß, was da so alles evtl. mit verschwindet) – vielleicht interessieren sich ja noch mehr Leute dafür – könnte ich mir jedenfalls vorstellen. Könnte man irgendwo anbieten, vielleicht mal auf FZW?

Die Idee mit der Bearbeitung von jeweils nur 500 Seiten auf der Beo wäre aber tatsächlich sehr interessant – sicher auch für viele andere Leute. Muss ja nicht jetzt auf gleich sein, aber das wär echt schön auf die Dauer. :-) Viele Grüße --Geitost 02:05, 17. Mär. 2012 (CET)

Das sind beeindruckende Zahlen. Vielleicht hilft das schon die Beobachtungsliste wieder bearbeitbar zu machen. Manchmal ist die Grenze nur ein klein wenig überschritten. Ich habe keine Ahnung, wie viele Seiten so ein Benutzer durchschnittlich auf der Beobachtungsliste hat, aber eine solche Bearbeitenfunktion kann vermutlich interessant sein (Bug 20483). Ich werde mir das mal anschauen. Der Umherirrende 09:32, 17. Mär. 2012 (CET)

Guten Morgen,

ich bekam gerade einen Hinweis: Die CSS/JS-Userinfo zeigen zurzeit eine Verdoppelung der Überschrift. Ich vermute, diese beiden (userjspreview und usercsspreview) machen irgendwie Kummer.

• Es heißt ja nicht -summary – vielleicht reagieren die ja allergisch auf Wikilinks. Ich habe leider überhaupt keine Ahnung von den Systemnachrichten; woher auch. Die Links funktionieren, aber vielleicht bringt die Wikisyntax-Auflösung irgendwas durcheinander?
• Falls die Links bestehen bleiben können, sollte auch das Usercsspreview auf die JS-Seite verlinken. Auf der CSS-Seite steht nur eine Art Weiterleitung auf JS; das kann man abkürzen, und der Text bei JS kann die CSS auch erwähnen.
• Den Text würde ich etwas anders formulieren:

  unverlinkt: Beachte: Wenn dies nicht dein common.js oder Skin-JS ist, musst du nach dem Speichern deinen Browser anweisen, die neue Version zu laden: Mozilla/Firefox: … und dann möglichst mit Link anfügen: … Konqueror: Strg-R. Notfalls wäre der Browser-Cache zu löschen. Für CSS entsprechend, aber gleiches Linkziel.

Schönen Sonntag --PerfektesChaos 00:55, 18. Mär. 2012 (CET)

Da sich im HTML-Quelltext <mw:editsection page="..." section="1">Vorschau deines Benutzer-JavaScripts</mw:editsection> verirrt hat, sieht es nach einem MediaWiki-Problem aus, aber auch nach dem Entfernen der Links hat sich nichts gebessert. Beim testen hatte ich nur auf den Link geachtet. Keine Ahnung, was da kaputt ist. Der Umherirrende 01:22, 18. Mär. 2012 (CET)

Als ursprünglicher Hinweisgeber: Ich hatte vermutet, daß das Problem entweder bei mir liegt (mittlerweile ja widerlegt), oder bei uns (MW-Namensraum deWP). In enWP hatte ich in einer Vorschau meiner CSS-Datei diesen Fehler nämlich nicht bemerkt. Da ich wikEd benutze, sehe ich den Seitenkopf (sowie eventuelle /Editintro-Unterseiten) oft nicht, da wikEd dafür sorgt, daß das Bild sofort so weit runterscrollt, daß ganz oben nur die Edit-Werkzeugleiste steht. Insofern könnte es also sein, daß der Fehler schon längere Zeit da ist und es bisher niemand gemerkt bzw. gemeldet hat. Getestet übrigens mit FF 2, FF 3.6 und IE 8 (man will ja nichts unversucht lassen ...) N8 --Schniggendiller Diskussion 01:33, 18. Mär. 2012 (CET)

Die en.wp hat dort auch keine Wiki-Überschrift drin, welche das Problem verursacht. Ich habe die Überschrift entfernt, weil der Seitenkopf damit doch etwas überladen aussah (Zwei Zeilen drüber war auch eine Überschrift "Vorschau"). Ich habe die unterschiedlichen Links drin gelassen, weil sich Neulinge dann nicht wundern, warum sie auf immer auf der gleichen Seite landen. Natürlich ergibt sich dadurch eine leiche Redundanz, aber wenn der Benutzer erstmal auf der Seite ist, scrollt er vielleicht etwas und findet noch etwas anders zum Thema. Der Umherirrende 09:37, 18. Mär. 2012 (CET)

Jut, danke. Gruß --Schniggendiller Diskussion 19:18, 18. Mär. 2012 (CET)

Danke erstmal.

Allerdings würde ich aus Redundanzgründen diesen Hinweis bei den preview einkürzen/ändern auf (JS):

(ohne Verlinkung des Cache). Grund: Nach dem Speichern sieht man ohnehin nochmal den view auf die Seite. Dort kann das zentral auseinanderklamüsert werden. Die nutzlosen Browser-Tastenkombinationen würde ich hier komplett streichen.

Für CSS reicht eigentlich in der preview:

Bei der Gelegenheit kam ich über den Standardtext jeder BNR-CSS/JS. Für den unkundigen Benutzer sollte er wie folgt ersetzt werden, vgl. auch enWP:

Die derzeitigen Hinweise sind wie bekannt völlig überholt; entweder überflüssig oder unwirksam. Ein abschließendes Link auf Wikipedia:Technik/Skin zur allgemeinen Information kann nicht schaden.

• Man könnte nach englischem Vorbild ein (red)Link auf die mögliche Doku-Seite (also ohne Extension) anzubieten versuchen.

Die Browser-Tastenkombinationen können meines Wissens entfallen.

• Ein Sicherheitshinweis bei CSS ist wohl nicht nötig; obwohl: *{display:none}

Schönen Abend --PerfektesChaos 22:00, 18. Mär. 2012 (CET)

Bei MediaWiki:Usercsspreview könnte man auch noch rein schreiben, das es aufgeführt wurde, nur fällt mir da keine sinnvolle Formulierung ein, die sich mit JavaScript verwechseln lässt. MediaWiki:Clearyourcache würde ich aber so lassen, oder meinst du en:MediaWiki:Jswarning und Template:Script doc auto sind hier notwendig? Der Umherirrende 19:08, 20. Mär. 2012 (CET)

Schönen Dank, dass du dich kümmerst.

1. Bei CSS habe ich den Hinweis auf die Ausführung bewusst weggelassen. Das CSS wird zwar in der Vorschau wirksam – aber man guckt grad auf einige Zeilen CSS. Wie sich die Änderung auf die Gestaltung eines Artikels auswirken würde, kann man im Moment nicht sehen. Allenfalls die Farbgebung des Portalrahmens könnte man austesten; aber lohnt sich dazu das Versprechen?
2. MediaWiki:Clearyourcache stammt aus der Zeit vor dem ResourceLoader und ist völlig überholt und die Tastenkombinationen sind weitgehend ungeeignet.
   • Bei den common/skin-Standardressourcen braucht man mittlerweile den Cache überhaupt nicht mehr zu löschen.
   • Bei selbstdefinierten Ressourcen-Unterseiten ist der Hinweis auf das Löschen des Cache dringend ratsam. Nur: Die angegebenen Tasten wirken nicht zwangsläufig und wiegen den weniger erfahrenen Benutzer in eine trügerische Sicherheit (aber ich hab doch Ctrl+F5 gedrückt!). Die hier genannten Tastenkombinationen greifen dann, wenn in die momentane Seite unter exakt dieser URL eingebunden wurde. Da es ja ein Nicht-Standard-Skript ist, wird es vielleicht nur importiert, wenn man auf der Beo oder in der Dateibeschreibungsseite wäre oder gerade editieren würde. Solange ich aber im Moment meinen geänderten JS-Code angucke, ist diese URL noch gar nicht aktiviert. Auch wenn man das identische Skript mal mit &maxage=0 und mal mit &maxage=86400 und mal ohne maxage einbindet, hat man lauter verschiedene URL und damit möglicherweise gleichzeitig unterschiedliche Skriptversionen im Cache. Deshalb ist der einzig sichere Weg die Komplett-Löschung des Cache; zumindest für die Wiki-Domain.
   • Hypergenial wäre es, wenn die Clearyourcache Vorlagensyntax könnte und man die Anzeige oder die Textformulierung davon abhängig machen kann, ob der momentane Seitenname common|vector|monobook|modern usw. wäre.
3. Template:Script doc auto wäre ein Traum; das entstehende Redlink reizt vielleicht den einen oder anderen Bastler, mal ein wenig lesbaren Wikitext als Doku zu spendieren. Der Hinweis auf zwei Kommentarzeilen im JS ist kein Ersatz für eine Doku, oder ein patziges „Guck gefälligst in den Quelltext, das ist doch ganz einfach, dann siehst du schon was du machen musst“.
4. Ganz so knallig wie en:MediaWiki:Jswarning muss es nicht sein; aber einen Hinweis würde ich gut finden und hatte ihn oben in milderer Form mit aufgeführt. Auf jeden Fall kann sich dann keiner darauf rausreden, man hätte nicht gewarnt und wir wären an allem schuld.

Schönen Abend einstweilen --PerfektesChaos 20:43, 20. Mär. 2012 (CET)

Guten Morgen mal wieder,

zur besseren Übersicht in Texten wäre es zuweilen günstig, größere syntaxhighlight-Blöcke mit Rahmen darzustellen. Weil in diesen tags nicht nur style sondern auch class HTML-wirksam sind, hätte ich gern eine Klasse .pre-border (oder so ähnlich genannt) entsprechend des <pre>-Stils MW

    pre {
        padding: 1em;
        border: 1px dashed #2f6fab;
        color: black;
        background-color: #f9f9f9;
    }

GeSHi#Configuration sähe nur eine div.mw-geshi mit dashed border für alle Verwendungen der Block-syntaxhighlight vor; das wäre mir aber zuviel und es würde nachträglich alle bestehenden Einbindungen verändert darstellen. Ich möchte aber nur selektiv in bestimmten Situationen (nicht bei sechs Zeilen) das MW-border-Format hinzufügen, das dafür auch mal an beliebige div angehängt werden kann. In der MediaWiki:Common.css ist bisher nichts definiert.

Nebenbei ist mir unklar, warum style und class überhaupt im HTML-Output auftauchen; PHP gibt nichts zu diesen Parametern her. Werden vielleicht style und class und id von allen oder vielen Wiki-Tags umgesetzt? Oder manscht Tidy nachträglich irgendwelche div zusammen?

Das ist eine gemischte Anfrage persönlich/projektweit; kann nach erster Stellungnahme zur MediaWiki Diskussion:Common.css weitergeschoben werden.

Liebe Grüße --PerfektesChaos 10:21, 21. Mär. 2012 (CET)

Zu HTML-Attributen fragst du den richtigen. Der Patch war von mir ;-). Du hast rev:113190 gesehen? Der Umherirrende 19:04, 21. Mär. 2012 (CET)

Als weitere Erklärung, was alles möglich ist und wie es eingehalten wird: Sanitizer::validateTagAttributes hat intern eine Whitelist der möglichen Attribute pro Tag. Es kann also das gleiche verwendet werden, wie bei den Tags im Wikitext (Keine Dopplung und Zukunftssicher, weil Erweiterungen in der Whitelist auch in Geshi funktionieren). Bei div/span/code/pre geht 'id', 'class', 'lang', 'dir', 'title', 'style', wobei 'lang' hier mit dem Geshi-lang kollidiert und daher nicht geht. Bei span/div zusätzlich 'align'. Bei pre zusätzlich 'width'. Der Umherirrende 20:01, 21. Mär. 2012 (CET)

• Ja, ich hatte schon so ein dumpfes Bauchgefühl, dass ich den Richtigen frage – ich meinte auch, dich in irgendeinem Bugzilla zu dem Thema gesehen zu haben und bin deshalb erstmal hier aufgeschlagen.
  • Dann werde ich mich mal dranmachen, Hilfe:Syntaxhighlight zu ergänzen.
• rev:113190 hatte ich nicht bewusst gesehen; vielleicht mal vor längerer Zeit über Bugzilla:19416 #c14 gelesen.
  • Wenn ich das richtig deute, aktiviert das klammheimlich den pre-style, sobald das live geht.
  • Das gefällt mir aber überhaupt nicht, weil dadurch das Layout von bestehenden Seiten verändert wird.
  • Es ist völlig okay, wenn ein längerer Abschnitt durch einen Rahmen zusammengefasst wird. Damit sind auch zwischengeschobene Normaltext-Absätze besser abzugrenzen. Genau deshalb fragte ich eingangs nach einem .pre-border zur einheitlichen Darstellung.
  • Es ist aber Unfug, wenn nachträglich eine einzelne Zeile Quellcode in einem bereits gestylten Artikel jetzt plötzlich mit Rahmen und padding herausknallt. Die Frage, ob für eine konkrete Gestaltung ein Rahmen gesetzt wird, sollte man individuell im Einzelfall entscheiden können.
  • Ich überlege erstmal, ob ich mir für die deWP eine Standardeinstellung pre.mw-geshi wünschen sollte, die zunächst den bisherigen Zustand beibehält; auf jeden Fall werde ich ab sofort in allen fraglichen Fällen explizit style="border:none" setzen. Vielleicht habe ich alle mich interessierenden Seiten bis 1.20 erwischt.
• Die ursprüngliche Frage nach .pre-border hat sich damit erledigt.

Liebe Grüße --PerfektesChaos 21:10, 22. Mär. 2012 (CET)

Du kannst es auch im translatewiki ausprobieren. Für mich sieht das aber noch nicht fertig aus, da sich da irgendwie etwas verschiebt, siehe auch die Kommentare an der Revision. Der Umherirrende 21:25, 22. Mär. 2012 (CET)

Hi Umherirrender,

ich habe 2 Fragen zum MediaWiki:Emailpagetext.

1. Was ist die Rolle von {{#ifeq:{{PAGENAME}}|{{#titleparts:{{PAGENAME}}|1|-1}}? Ich denke, daß selbst Spezial:E-Mail ist die einzige Seite wo das richtig ist, nicht war? Kann ich das weglassen?
2. Warum sind MediaWiki:Emailpagetext/en und MediaWiki:Emailpagetext/fr so verschiedene von Deutscher Variante?

Bináris (Diskussion) 13:48, 23. Mär. 2012 (CET)

Hallo Bináris,

{{PAGENAME}} ist auf Spezial:E-Mail/Bináris mit dem Inhalt E-Mail/Bináris gefüllt. Bei Verwendung von titleparts mit -1 bekommt man den ersten Wert vom Ende aus gesehen. Das wäre hier Bináris, der gewünschte Benutzername. Falls man aber auf Spezial:E-Mail den Benutzernamen eintippt, behält PAGENAME den Inhalt "E-Mail", daher das ifeq, weil der Benutzername nicht ermittelbar ist. Ich hatte den Quelltext von MediaWiki:Emailpagetext vereinfacht und nicht auf die anderen Sprachen (en und fr) geachtet, daher gibt es dort eine Abweichung/alternative Implementierung. Der Umherirrende 16:56, 23. Mär. 2012 (CET)

FYI: Benutzer Diskussion:Euku #Dein Mentorenprogramm.js

Schönes Wochenende --PerfektesChaos 20:43, 23. Mär. 2012 (CET)

Es war zu erwarten, das es kommt, aber es wird schon länger in der Fehlerkonsole des Benutzers gestanden haben, da ich mir nicht vorstellen kann, das es jetzt erst wirklich zu Problemen führt. Der Umherirrende 20:49, 23. Mär. 2012 (CET)

Tja, das stand da halt so drin.

Gab es heute irgendwelche MW-Upgrades? Es ist der FF10-Kunde; irgendeine Gadget-Lade-Umstellung?

Ich vermute, dass WSTM vom FF10 mal wieder gar nicht geladen wird; der heute für einige Stunden bei mir vorhandene Fehler trat nur in wenigen Artikeln auf, und schmeißt eine Fehlermeldung wegen fehlender Funktion nach Umstellung auf Anwendungsobjekt.

--PerfektesChaos 21:16, 23. Mär. 2012 (CET)

Mir sind heute keine Software-Änderungen aufgefallen. Im wikitech:Server admin log steht auch nichts für RL/JS. An den Gadgets wurde auch nichts gemacht. Der Umherirrende 21:21, 23. Mär. 2012 (CET)

Guten Morgen,

Spezial:Spezialseiten sind inzwischen ganz schön viele, und allmählich unübersichtlich. Ob du der MediaWiki:Specialpages-summary/de-at/de-ch/de-formal eine __TOC__ (notfalls manuell, mit Sternchen) spendieren könntest?

Schöne Woche --PerfektesChaos 09:23, 26. Mär. 2012 (CEST)

Ich glaube __TOC__ wird da nicht funktionieren, weil beim parsen der summary diese Information nicht zur Verfügung steht, da sich die Spezialseite aus mehreren Stücken zusammensetzt. Wie wäre es mit:

Die Spezialseiten gliedern sich in folgende Gruppen:
* Wartungslisten
* Seitenlisten
* Kontoverwaltung
* Benutzer und Rechte
* Letzte Änderungen und Logbücher
* Medien
* Daten und Werkzeuge
* Weiterleitende Spezialseiten
* Häufig benutzte Seiten
* Seitenwerkzeuge
* Bearbeitungen prüfen
* Andere Spezialseiten

Oder ähnliches. Es darf gerne direkt in meinen Vorschlag geändert werden. Der Umherirrende 20:21, 26. Mär. 2012 (CEST)

Wo werd ich da was ändern; und das ist ja sogar eine internationalisierbare Variante, die sich auch das japanische Wikisource kopieren kann! Bitte, gern so. Das ahnte ich schon, als ich „notfalls manuell, mit Sternchen“ schrieb – TOC nur für die Summary wäre etwas mager. Danke, schönen Abend --PerfektesChaos 21:25, 26. Mär. 2012 (CEST)

Ja, ich hatte mir gedacht, das man so die Änderungen an den Texten nicht nachziehen muss. Die japanische Wikisource müsste nur eine Gruppe herausnehmen, weil sie vermutlich die FlaggedRevs nicht haben, aber vom Prinzip her ist es kopierbar. Der Umherirrende 18:49, 27. Mär. 2012 (CEST)

Moin Umherirrender, muss ich das verstehen? Nicht, dass es wichtig wäre, wundert mich bloß.... -- Hepha! ± ion? 20:17, 26. Mär. 2012 (CEST)

DrTrigon hat die Diskussion ja an der Stelle durch seinen Kommentar eigentlich für erledigt erklärt, da wollte ich nicht, das der Counter für das erledigt heute erst beginnt und habe einfach die Signatur kopiert. Falls das aber nicht gerne gesehen wird, kann ich das in Zukunft auch lassen, so schlimm wäre es auch nicht. Der Umherirrende 20:23, 26. Mär. 2012 (CEST)

Naja es wird niemanden interessieren, aber im Endeffekt ist es ja schon irgendwie ne Sig-Fälschung. Ist aber wie gesagt an der Stelle weniger entscheidend, Grüße --Hepha! ± ion? 20:26, 26. Mär. 2012 (CEST)

Vielleicht eine Mischform? Benutzer:Umherirrender + getürkter Timestamp? Hier war es nur eine friedliche Werkstattseite, aber wenn es mal irgendwo streitig zugeht, könnte sich jemand aufregen. Soviel Senf dazu --PerfektesChaos 21:32, 26. Mär. 2012 (CEST)

Der empfohlene Standard für solche Fälle ist – soweit ich weiß und es selbst auch verwende – eine Zeitangabe ohne (CEST)/(CET), da solche von den Archiv-Bots nicht beachtet werden. --Schnark 09:42, 27. Mär. 2012 (CEST)

ack PerfChaos. --Hepha! ± ion? 15:37, 27. Mär. 2012 (CEST)

Ich habe es Verstanden ;-) und werde es in Zukunft nicht mehr machen. Der Umherirrende 18:46, 27. Mär. 2012 (CEST)

Hallo Umherirrender, du kennst dich mit solchen Sachen besser aus. Kannst du..? Gruss --Nightflyer (Diskussion) 13:57, 2. Apr. 2012 (CEST)

Dann würde ich Schnark den Vortritt lassen. Er ist beim Bugzilla erfassen auch gut und scheint sich hier schon etwas eingearbeitet/eingelesen zu haben. Der Umherirrende 17:09, 2. Apr. 2012 (CEST)

Hallo, Umherirrender! Könntest du die Seite Vorlage:Infobox hochrangige Straße/Doku/Kopiervorlage wiederherstellen? Sie wird für als Preload-Seite für hier befindlichen Link genutzt. Vielen Dank! --Daniel749 •Diskussion•ST•WPST 21:58, 17. Apr. 2012 (CEST)

Hallo Daniel749, entschuldige, das hatte ich nicht gesehen. Ich habe die Seite wiederhergestellt und entsprechend kategorisiert, damit das in Zukunft nicht noch einmal passiert. Der Umherirrende 19:12, 18. Apr. 2012 (CEST)

Wie das da zeigt, scheinen Deutsche Börse und Google ihre URLs oder APIs geändert zu haben, da funktioniert die Verlinkung nicht mehr. Ich weiß leider nicht, wo man so was meldet. Kannst du das vielleicht übernehmen? Danke. --Matthiasb ^{(CallMyCenter)} 13:57, 19. Apr. 2012 (CEST)

Mit User:Magnus Manske kannst du am besten über JIRA sprechen, wenn es um seine Tools geht. Daher jira:MAGNUS-314 eröffnet. Der Umherirrende 20:53, 19. Apr. 2012 (CEST)

Ah, Danke. Wenn du noch eine Antwort hättest auf dieses, spendiere ich dir ein virtuelles Bierchen. --Matthiasb ^{(CallMyCenter)} 20:58, 19. Apr. 2012 (CEST)

Ich habe dann mal bestellt. --Matthiasb ^{(CallMyCenter)} 21:36, 19. Apr. 2012 (CEST)

Unter der Woche ist das mit dem Bier immer eine schlechte Idee …, aber danke. Ich helfe gerne. Der Umherirrende 21:39, 19. Apr. 2012 (CEST)

Es werden keine eigenmächtige (große) veränderungen gemacht. die bisherige darstellung wurde von allen bearbeitern unterstützt und gepflegt. schlage es vorher in der disc vor. --Kenji (Diskussion) 17:23, 25. Apr. 2012 (CEST)

Ich habe keine Inhaltliche Veränderung vorgenommen. Ausgeklappte Textteile sind nutzlos und können genauso gut entfernt werden, weil sie sowieso keiner ließt. Die Informationen sollten direkt sichtbar sein. Ich sehe das Problem der zu großen Zeilen nicht, vielleicht sollte man darüber nachdenken, ob die Information in der Liste gut aufgehoben ist, oder doch besser in einem Artikel zu dem Thema der Zeile. Ich sehe mich als benachrichtigt an. Der Umherirrende 18:26, 25. Apr. 2012 (CEST)

Hallo Umherirrender, ich möchte gern die Versionsunterschiede im alten Design angezeigt bekommen und dank Giftbot wurde ich auf deine Seite MediaWiki:Gadget-old-diff-style.css aufmerksam gemacht. Allerdings habe ich keinerlei Erfahrungen mit solchen Einstellungsänderungen. Ich dachte mir, ich lege Benutzer:Berita/monobook.css an und kopiere das da rein, das brachte aber keine Änderung (Cache habe ich geleert). Was muss ich tun? Danke im voraus für deine Unterstützung!--Berita (Diskussion) 15:28, 26. Apr. 2012 (CEST)

Hallo Berita, hier hat der GiftBot natürlich nur den Text von WP:NEU kopiert, der als Arbeitsanweisung für einen Admin nach der Softwareumstellung galt. Helferlein (englisch "Gadgets") lassen sich über die Einstellungen aktivieren. Gehe dort auf den Tab "Helferlein". Im Abschnitt "Lesehilfen" findet sich "Stellt Versionsunterschiede in den bisherigen Farben dar". Haken davor machen und auf Speichern klicken und dann sollte es funktionieren. Der Umherirrende 17:41, 26. Apr. 2012 (CEST)

Huch, dann hab ich das ja völlig falsch verstanden. Nun hat es aber geklappt *aufatme* Dankeschön!--Berita (Diskussion) 18:27, 26. Apr. 2012 (CEST)

Keine Ursache. Den Text vom Ausrufer war da auch nicht wirklich hilfreich für das verstehen. Der Umherirrende 18:30, 26. Apr. 2012 (CEST)

		MediaWiki Bug Squad Barnstar
		Thank you for going above and beyond the call of duty. Your help with the bugs has been amazing. ☠MarkAHershberger☢(talk)☣ 16:19, 1. Mai 2012 (CEST)

Thanks! Der Umherirrende 20:30, 1. Mai 2012 (CEST)

Hallo! Bei deiner Bearbeitung an oben genannter Vorlage im November 2011 ist wohl irgendwas schief gelaufen, siehe Einbindung der Vorlage in Olympische Winterspiele 2010/Eishockey (Herren). Norwegen ist von der Spalte "Viertelfinal-Qualifikation" ins "Viertelfinale" gerutscht... Könntest du bitte nochmal drüber schauen und es korrigieren? Gruß und Danke, Thomas ^✉ 13:58, 2. Mai 2012 (CEST)

Ja, da war irgendwie etwas untergegangen. Danke für den Hinweis, sollte jetzt aber wieder passen. Der Umherirrende 19:05, 2. Mai 2012 (CEST)

Es passt wieder, Danke! --Thomas ^✉ 22:28, 2. Mai 2012 (CEST)

Hallo Umherirrender, bei der Suche in der British Library erscheint die Fehlermeldung, dass die Suche auf dem Server so nicht mehr existiert. Vielleicht kannst Du sie ja entfernen oder korrigieren. Beispielaufruf: Spezial:ISBN-Suche/0521227208 Gruß --84.161.215.136 18:49, 2. Mai 2012 (CEST)

Hallo IP, unter WD:ISBN-Suche stehen auch noch ähnliche Anfragen. Leider nennt keine davon die genaue Such-URL, was dadurch Aufwand für den Admin in Form von Ausprobieren bedeutet, was dann nicht jeder gerne übernimmt. Der Umherirrende 19:16, 2. Mai 2012 (CEST)

Habe mal in en-WP nachgesehen. Dort gibt es zwar keinen direkten Link zur British Library, aber eine Suche in Copac, die angeblich die British Library enthält.--84.161.215.136 19:25, 2. Mai 2012 (CEST)

Habe jetzt einen Link gebastelt und eingebaut. Hoffe, das die Suchseite den Erwartungen entspricht. Falls du Copac noch dazu haben möchtest, solltest du einen eigenen Abschnitt auf der Diskussionsseite aufmachen. Ich kümmere mich erstmal nur um den Erhalt der Links, neue Links sollen andere entscheiden, da bin ich nicht so fit, was gut und was schlecht ist. Der Umherirrende 19:50, 2. Mai 2012 (CEST)

Hallo Umherirrender, ich suche schon länger jemanden der mir bei 2 Turniervorlagen helfen kann. Ein paar haben schon aus Zeit- oder Wissensmangel abgesagt oder ich habe keine Antwort erhalten. Vielleicht kannst du ja helfen. Schau doch mal bei meinen Anfragen hier und hier. Ich hebe mir gedacht, dass man einfach die Vorlage Vorlage:Turnierplan16-kompakt-1 nimmt (diese enthält schon "byes", diese kopiert und daraus die beiden Turnierpläne erstellt die ich brauche, nämlich

1. einen 16er-Plan bei dem die Spiele der ersten Runde nicht aneinanderkleben (Leerzeile vertikal zw. den Spielen) und Byes: Neuer Name evtl.: Turnierplan16-ohne-byes
2. einen 8er-Plan mit byes. Neuer Name evtl.: Turnierplan8-ohne-byes.

Zur Erklärung des Wort "byes". Kommt wahrscheinlich von "Godd bye", sag "Tschüs" zu leeren Zeilen/Zellen. Gut wäre dann auch noch die Erklärung auf der Vorlagenseite unter Punkt 7. Dank im Voraus. --LezFraniak (Diskussion) 15:04, 13. Apr. 2012 (CEST)

Hallo Umherirrender, leider scheint die Hilfestellung nach meinem "Fehltritt" eingeschlafen zu sein. Kannst du da was anschieben oder soll ich nochmals in der Werkstatt posten? Hatte auch noch einen kleinen Fehler in der von mir bearbeiteten Vorlage gefunden, nun trau ich mich aber nix mehr. ;-) --LezFraniak (Diskussion) 19:51, 18. Apr. 2012 (CEST)

Hallo LezFraniak, ich habe Vorlage:Turnierplan8-mit-Datum-ohne-Position mit "byes" ausgestattet, es werden also jetzt die Rahmen und Linien nicht mehr angezeigt, wenn das Team nicht gesetzt ist. Bitte teste die Vorlage mit den verschiedenen Konstellationen und schaue, ob sich die Kästen nicht verschieben und die richtigen Linien aktiv sind. Der Umherirrende 19:22, 24. Apr. 2012 (CEST)

Hallo Umherirrender, Danke für deine Arbeit. Da ich diese Vorlage schon vor ein paar Tagen auf meiner Baustelle eingesetzt hatte, konnte ich gleich sehen dass es funkt. Habe mal ein paar Felder gefüllt bzw. gelöscht und konnte keinen grafischen Fehler entdecken. Es gibt nur noch den in der Vorlagendisku erwähnten kleinen Scorefehler bei RD2-team1, dort sollte eine 1 anstelle der 2 stehen, sonst gibt es ja das eine Ergebnis zweimal. Wenn du dass noch ausbügeln könntest. Die Technische Dokumentation finde ich auch toll. Da kann man doch endlich mal sehen wie so eine Vorlage aufgebaut ist. Wenn du diese Vorlage noch als 16er erweitern könntest habe ich dann alles was ich vorerst brauche. Als Lemmavorschlag hätte ich "Turnierplan8-mitDatum-ohnePosition-Byes". Ist vom Verständnis her besser zu verstehen als mit den ganzen Bindestrichen. Obwohl ich das Datum eigentlich nicht brauche, macht das nix, kann man ja leer lassen. Dank dir nochmals. Gruß --LezFraniak (Diskussion) 20:12, 24. Apr. 2012 (CEST) Nachtrag: Score korrigiert. --LezFraniak (Diskussion) 20:33, 24. Apr. 2012 (CEST)

Da Turnierpläne auch nur auf Tabellen basieren, diese aber durch die verbundenen Zellen sehr komplex aussehen, hat mir eine ähnliche Übersicht in Excel sehr geholfen, den Überblick zu behalten. Damit das ganze nicht wegkommt, habe ich es erstmal dort hingeschrieben. Andere Turnierpläne können auch anders aufgebaut sein und die Verbundenen Zellen komplett anders aussehen. Die 16er-Variante würde ich mir am Wochenende anschauen. Du möchtest also Abstand aber dort soll zwischen den Spielen der Runde 1, aber dort soll kein Datum stehen. Die bestehenden anderen 16er-Turnierpläne entsprechen auch nicht deinen Vorstellen, weil dort "byes" fehlt? Ich würde dann Vorlage:Turnierplan16-kompakt-1 als Kopierbasis nehmen (falls dir eine andere eher zusagt, nur zu) und dort entweder den Abstand oder "byes" einbauen. Vorlage:Turnierplan16-ohne-byes wird wohl verwirren, weil es ja nicht "ohne byes" ist, sondern ohne Datum, aber mit "byes". Fällt dir da noch etwas besseres ein? Der Umherirrende 18:39, 25. Apr. 2012 (CEST)

Ja, das mit der Benennung, vor allen Dingen der richtigen, ist anscheinend nicht einfach. Ich brauchte auch ein paar Minuten um es zu verstehen. Im Einleitungstext von Kategorie:Vorlage:Turnierplan steht eine Erklärung wie sich das Lemma zusammensetzt. Unter Punkt 4 steht die Erklärung von "ohne". Jedes dieser Argumente wird durch einen Bindestrich getrennt. Deshalb ist "Vorlage:Turnierplan8-ohne-Datum" identisch mit "Vorlage:Turnierplan8-mit-Datum-ohne-Position" abgesehen von den "Byes" die dort im Lemma nicht auftauchen. Sollte noch geändert werden. Die Anpassungen bei den beiden WM mache ich dann. Eigentlich wäre es schlauer gewesen statt"ohne" die engl. Form "noSeed" zu wählen, aber dafür ist es ja jetzt zu spät. Was ich auch schon mal angeregt hatte, ist, dass in der Lemmaerklärung Punkt 7 für die "Byes" hinzugefügt werden sollte. Wie ich bei den meisten Disku lesen konnte wussten/wissen viele nichts damit anzufangen. Ich selber habe es mit dieser Vorlage:Turnierplan16-kompakt-3-byes verstanden. Evtl. kann man dann auch noch Punkt 8-Datum einfügen. Wenn du in Vorlage:Turnierplan16-kompakt-1 die Abstände einfügst reicht dass.Geht evtl. recht schnell. Das mit dem Datum ist mir egal. Kann drin bleiben. Wenn´s leer bleibt tauchen sie ja auch nicht auf. Ich glaube die haben auch #if-Syntax. Als Lemmavorschlag hätte ich: Turnierplan16-noSeed-Datum-Byes. Wenn man dass dann noch in der Lemmaerklärung beschreibt sollte es jedem klar sein. Ich hätte noch eine weitere Anregung zu "Vorlage:Turnierplan8-ohne-Datum". Anhand der Kopiervorlage lässt sich nicht erkennen welches | für welches Feld ist. Deshalb hatte ich dass damals organisieren wollen (ohne an die Konsequenzen gedacht zu haben). Ich habe zuerst einfach Zahlen von 1–35 in die Syntax eingegeben, anstelle von nbsp. (Wie kann man eigentlich in diesem Text eine Syntax darstellen ohne dass Wiki diese als solche nimmt. Habe es mit "nowiki" versucht, hat aber nicht geklappt.) Habe dass dann auch noch in der Kopiervorlage gemacht. Wenn ich es so gelassen hätte wäre es wahrscheinlich OK gewesen anstatt nochmals gegen "RD1-team1" etc. zu tauschen. Das hätte die eingesetzten Vorlagen in den Artikeln doch nicht zerschossen, oder? Gruß --LezFraniak (Diskussion) 19:33, 25. Apr. 2012 (CEST)

Ich habe auf Basis von Vorlage:Turnierplan8-mit-Datum-ohne-Position jetzt Vorlage:Turnierplan16-mit-Datum-ohne-Position erstellt. Das   kannst du bekommen, wenn du die benannte HTML-Entität für das Ampersand & verwendest. Also tippst du im Quelltext   Der Umherirrende 17:31, 27. Apr. 2012 (CEST)

Hallo Umherirrender, war über’s WE verreist, deshalb erst jetzt die Rückmeldung. Danke für deine Hilfe und Erklärung. Die Erklärung der "byes" etc. wolltest du nicht übernehmen? Würde dies echt gerne noch verdeutlichen bevor ich alle Artikel ändere und andere diesen Turnierplan nutzen. Wie gesagt, es gibt schon eine Vorlage mit "Byes" im Lemma und es macht Sinn dies auch so weiterzuführen. Gib mal kurz Rückmeldung dazu. Gibt es eine Seite bei WP die weitere Erklärungen über die HTML-Entität erhält? Weiß zwar ungefähr was du meinst, würde aber gerne noch mehr dazu wissen. Danke nochmals. Gruß --LezFraniak (Diskussion) 19:03, 1. Mai 2012 (CEST)

Du kannst die Vorlage gerne verschieben, wenn du der Meinung bist, das "byes" im Namen auftauchen sollte. Mir ist das egal. Eine spezielle Seite gibt es nicht, unter HTML-Entity steht auch nicht so viel, aber vielleicht hilft es dir. Der Umherirrende 20:28, 1. Mai 2012 (CEST)

Habe beide Vorlagen verschoben, leider ist die Dokumentation und Kopiervorlage nicht mitverschoben worden. Warum nicht? Kannst du das bitte noch richten? Artikel mit Vorlageneinbindung angepasst. Dank im Voraus.--LezFraniak (Diskussion) 14:48, 3. Mai 2012 (CEST)

Die Dokumentation ist nur eine Unterseite, die man separat verschieben muss. Ich habe das nachgeholt, somit passt es jetzt. Der Umherirrende 18:05, 3. Mai 2012 (CEST)

Super. Danke. Wo hast du die Seiten noch gefunden? Ich würde dann noch auf der Vorlagenseite die Erklärung für die "Byes" eintragen, wenn's recht ist. Gruß --LezFraniak (Diskussion) 18:28, 3. Mai 2012 (CEST)

Die Seiten heißen genauso wie die Vorlage, nur mit /Doku hinten dran. Aber der Bearbeitenlink auf der Vorlagenseite unterhalb des Querstrichts führt dich auch direkt dahin. Ansonsten steht der Link auch noch mal am Seitenende hinter "Diese Dokumentation befindet sich ...". Der Umherirrende 18:31, 3. Mai 2012 (CEST)

Ah, Danke. Eine letzte Frage noch: Warum tauchen die beiden Vorlagen unter "Vorlage:Turnierplan" nicht auf? --LezFraniak (Diskussion) 18:41, 3. Mai 2012 (CEST)

Hängt mit der Verschiebung zusammen. Manchmal sind die Server etwas langsam bei der Aktualisierung der Kategorielinks. Jetzt passt es aber. Der Umherirrende 19:38, 3. Mai 2012 (CEST)

Dachte ich mir. Danke. erledigtErledigt --LezFraniak (Diskussion) 19:46, 3. Mai 2012 (CEST)

Hallo Umherirrender, bei dieser Verschiebung war es mir nicht möglich, in das Feld des Verschiebegrundes etwas einzutragen. Möglicherweise hängt es mit dem Namensraumausblendeskript zusammen, schaust du bitte mal? --32X → Autorengilde № 1 17:14, 8. Mai 2012 (CEST)

Vermutlich nutzt du Opera oder Chrome? Siehe auch Wikipedia:Fzw#Verschiebeformular II. Es scheint aber auch ohne Helferlein nicht zu funktionieren (Entweder deaktivieren oder in en.wp schauen). Da kann ich leider nichts weiteres mehr machen. Der Umherirrende 17:43, 8. Mai 2012 (CEST)

Hallöchen,

diese beiden Seiten Personal Firewall und Sexueller Missbrauch waren 2005 mal gesperrt.

• Vermutlich durch einen Systemfehler verblieb damals beim Entsperren ein "" in der Datenbank, somit auch im JS-Array wgRestrictionEdit (und auch wgRestrictionMove) – Anm.
• Nach dieser besonderen Ursache habe ich jetzt über drei Monate gesucht. Wenn man das weiß, ist es nicht so schlimm und lässt sich abfangen; aber ansonsten haben wir alle das Problem, dass wir nicht Mitglied der Gruppe "" sind und deshalb nicht diese „Rechte“ haben. So fährt das bei ungewarnten Programmierern an die Wand.
• Als Wiki-Datenbank-Experte fällt dir ja vielleicht der passende Dienstweg ein, das mindestens aus der de.WP und besser weltweit verschwinden zu lassen. Kleiner SQL-Lauf eines Ober-sysop halt.
• Heutzutage wird die Restriktionsgruppe wohl komplett entfernt. Ich hatte jedenfalls nie etwas anderes als leere Arrays oder den vorgesehenen Inhalt gefunden, bis jetzt auf diese beiden von 2005.
• Vielleicht magst du auch bei den Entsperrungen aus 2005/2006 im großen Logbuch surfen:
  • Ende Dezember 2005: Greifvögel, Karin Rieden, Leutersdorf (Sachsen), Röthenbach an der Pegnitz und Struppi haben eine ähnliche Geschichte, aber leeres Array wgRestrictionEdit.
  • Chris Carmack ist dagegen Treffer aus dem Oktober, genauso Kočevje und Joan Grant mit "" in den Arrays.
• Eine Null-Halbsperrung/Entsperrung könnte vielleicht lokal helfen, wenn das bedeutet, dass dadurch das DB-Feld geleert wird; kannste ja mal bei den identifizierten ausprobieren. Das klärt aber nicht die Frage, wie viele noch bei uns oder weltweit verseucht sind.

Langes Wochenende mit Sonne --PerfektesChaos 20:14, 16. Mai 2012 (CEST)

Die Seitensperren sind in MediaWiki auch schon mal rewrited worden, daher kann es da noch zu überbleibsel gekommen sein. Ich habe mal in die SQL-Dumps geschaut, dort sieht man den Datenbank-Status sehr gut und auch den Grund:

• Personal Firewall: pageid=53878, Feld page_restrictions enthält: move=:edit=
• Sexueller Missbrauch: pageid=31105, Feld page_restrictions enthält: move=:edit=

Damit ist klar, woher der leere String kommt. Wie der da hingekommen ist, kann ich nicht sagen, aber eine 0-sec-Sperre würde es wieder clearen. Nur fände ich das unnötig und bei 730 Seiten in de.wp etwas viel Aufwand. Ich schaue mal, ob man MediaWiki das nicht beibringen kann, die zu ignorieren. Wo hattest du den null gesehen? Der Umherirrende 21:06, 16. Mai 2012 (CEST)

gerrit:7821 könnte Abhilfe schaffen. Mal schauen, wie die anderen Entwickler das finden. Der Umherirrende 21:16, 16. Mai 2012 (CEST)

Schon für gut befunden, kommt dann vorraussichtlich mit 1.20wmf4 in 3? Wochen. Der Umherirrende 21:22, 16. Mai 2012 (CEST)

Danke schön.

• null hatte ich nicht gesehen, aber nach meinem Jubelschrei heute vormittag sicherheitshalber dazugeschrieben. Is eh wurst, kann auch false sein, wird sowieso nur abgefragt: if(g){}.
• Wenn man als Skript-Programmierer weiß, dass da sowas vorkommen kann, ist es etwas Mühe, aber geht. Wenn man ganz normal checkt, ob diese Gruppe beim Benutzer vorkommt, dann bekommt man eine gesperrte Seite. Ich rätselte schon seit einem Vierteljahr, warum diese beiden Seiten ausgestiegen waren.
• Könntest du nicht per mw:API:Protect sperren/entsperren? Dann sind die ein für allemal aus der deWP verschwunden, und gut ist. Welche 730 das sind, weißt du ja offensichtlich. Ansonsten muss auf ewig jeder JS-Programmierer das abfangen. Kannst ja mit 2 Seiten auf dem Testwiki anfangen. Da daas offenkundig ein Bug aus 2005 war, ist es dann für deWP erledigt.

Ruhige Tage --PerfektesChaos 21:55, 16. Mai 2012 (CEST)

Ja mir sind die 730 Seiten bekannt und es würde per API auch sehr zügig gehen, aber auch per API würde ich Logbucheinträge erzeugen, die meines Erachtens nicht notwendig sind. Da MediaWiki da in 3 Wochen mit umgehen kann, sehe ich das als bessere Lösung an, vorallem weil sie im gesamten Wiki-Universum zieht. Der Umherirrende 13:30, 18. Mai 2012 (CEST)

Naja, man kann das eine tun und das andere nicht lassen.

• Für den Moment ist das Problem gelöst; ich spiele heute noch in WSTM eine Version auf, die damit umgehen kann, und in einigen Wochen liefert der Server JS aus, wie man es erwarten würde.
• Nur sollten die Datenbanken nicht für die nächsten Jahrzehnte unerwartete Zombies mit sich herumschleppen. Jeder Programmierer in PHP und SQL muss nun bei jeder Abfrage diese nirgendwo dokumentierte Möglichkeit berücksichtigen. Das geht früher oder später schief und macht dann mehr Arbeit als einmal aufzuräumen, und die Software wird durch lauter Krücken auch nicht übersichtlicher. Da offenbar nur irgendein Bug aus 2005 betroffen ist, ist es weniger als 1 Promille der Artikel (viel weniger als aller Seiten, weil ja auch Disku+NR in den 730 drinstecken düfte). International ähnlich und vorrangig bei Projekten, die schon 2005 Seiten gesperrt hatten. Weltweit denke ich da an einen Logbuch-freien SQL-Lauf der DB-Admins zum Entfernen eines Nichts.
• Lokal in der deWP dürftest du dann mit >1460 Admin-Aktionen das diamantene Fleißbienchen erhalten.
• Persönlich habe ich kein Problem mehr, denke jedoch an Andere und die Zukunft.

Liebe Grüße --PerfektesChaos 14:43, 18. Mai 2012 (CEST)

Ja, die Nutzer auf dem Toolserver hätten dann damit nicht zu kämpfen, das ist richtig. Da der Seitenschutzstatus aber eh schon schwierig ist, wäre das nicht das einzige, worauf zu achten ist. Eine vereinheitlich wäre da sicher wünschenswert. Da Sperren ja zeitlich auch ablaufen wäre es ja nur die 730 Sperren je 0- oder 1-Sekunde lang (ja, 0 Sekunden würde gehen …). Die Datenbank hat noch schlimiere Zombies, die bei Wikis entstanden, die so gut wie alles vom Anfang an mitgemacht haben. Eine Bereinigung ist ein langwieriger Prozess, bereits jetzt warten auf Bugzilla viele Wartungs-Skripte auf Ausführung durch Shell-User. Es es scheint sich keiner drum zu kümmern, oder es sind so viele, das man es nicht merkt oder die aber der Aufwand für die Server lohnt sich nicht. Der Umherirrende 19:17, 18. Mai 2012 (CEST)

Hallo, soeben bin ich auf deinen Nicknamen gestoßen. Er gefällt mir, ist originell, sinnig ... und so sei dir mitgeteilt, dass ich gestern einen neuen Artikel über vazieren eingestellt habe. Vielleicht magst du ja da was ergänzen. LG, Geof (Diskussion) 01:44, 22. Mai 2012 (CEST)

Interessanter Artikel, in dieser Bedeutung hatte ich meine Namen bei der Anmeldung nicht gesehen ;-) Der Umherirrende 19:34, 22. Mai 2012 (CEST)

Kann Du Dir bitte das mal anschauen? --Fomafix (Diskussion) 23:21, 23. Mai 2012 (CEST)

Schaue ich mir am Wochenende an. Der Umherirrende 17:10, 24. Mai 2012 (CEST)

Hallo Umherirrender, für Carambolageturniere bräuchte ich einen Umbau deiner Vorlage Vorlage:Turnierplan16-mitDatum-ohnePosition-Byes jedoch mit 5 Scores. Diese Scores sollten keine feste Zellbreite haben sondern sich nach dem längsten Inhalt richten. Oben über den Runden sollte eine Eingabezeile für Zellüberschriften (Name / Pkte / Ball / Aufn. / GD / HS) sein. Hier ist ein Beispiel (vorletzte Seite). Kannst du das übernehmen? Oder soll ich die Anfrage in der Vorlagenwerkstatt stellen? Hat so gut mit dir geklappt. Lemmavorschlag:Turnierplan16-mitDatum-ohnePosition-5-Byes Gruß. --LezFraniak (Diskussion) 21:30, 9. Mai 2012 (CEST)

So gut bin ich beim Turnierplan erstellen auch nicht. Die anderen beiden haben auch schon etwas Zeit gekostet. Schieb das mal rüber, vielleicht findet sich jemand, ansonsten kann ich mir das am nächsten langen Wochenende anschauen. Der Umherirrende 18:00, 10. Mai 2012 (CEST)

Was meinst du mit "schieb das mal rüber"? --LezFraniak (Diskussion) 19:10, 10. Mai 2012 (CEST)

rüber in die Vorlagenwerkstatt. Du hattest ja angeboten, die Anfrage eventuell auch in der Vorlagenwerkstatt zu tätigen, daher solltest du das ganze rüberschieben (sehr umgangssprachlich gesagt von mir). Der Umherirrende 19:12, 10. Mai 2012 (CEST)

Du meinst neu anfragen. Deine DiskuSeite kann ich ja nicht verschieben. Kann in der Vorlagenwerkstatt neu anfragen. --LezFraniak (Diskussion) 19:15, 10. Mai 2012 (CEST)

Ja, einen neuen Abschnitt dort nochmals anfangen. Der Umherirrende 19:17, 10. Mai 2012 (CEST)

Habe ich gemacht. Kannst du ja mal beobachten ob da was passiert. Danke erstmal. --LezFraniak (Diskussion) 19:26, 10. Mai 2012 (CEST)

Ja, werde ich. Der Umherirrende 19:27, 10. Mai 2012 (CEST)

Hallo, in der VW hat sich jetzt 1 Woche nichts getan. Wenn du Zeit un Lust hast wäre das toll. Habe Artikel mit altem Design hier, kann dir als Beispiel dienen. Gruß --LezFraniak (Diskussion) 20:48, 16. Mai 2012 (CEST)

Möchtest du Rahmenlinien, wie bei Vorlage:Turnierplan8-5/Vorlage:Turnierplan16-kompakt-5? Oder rahmenlos? Der Umherirrende 19:11, 18. Mai 2012 (CEST)

Wo möchtest du den die Überschriften der 1-5 scores hin haben? Wie kann man die Parameter am besten benennen. Meine Entwicklungsversion sieht im Moment so aus (Die Zeilen-/Spaltenbeschriftung kommt natürlich noch weg). Der Umherirrende 20:12, 18. Mai 2012 (CEST)

Sieht doch schon gut aus. Ich würde die Überschriften in die gleiche Zeile setzten wie das Datum. Liest sich besser, oder? Der Platz für's Datum sollte reichen. Als Parametername reicht Üscore. Kann als "Paket" direkt hinter der Rundenbeschriftung stehen. Reicht ja wenn man es einmal beschriftet und die Parameter an die entsprechende Stellen schreibt. Danke. Schönes WE noch. Gruß. --LezFraniak (Diskussion) 19:29, 19. Mai 2012 (CEST)

Ich habe mich jetzt für HD-score-1 bis -5 entschieden, HD steht für Header, so kann man es auch im englischen gebrauchen. Ich hatte dort beim drüberschauen keine Vorlage in dieser Art gefunden, um den Parameter zu "klauen". Falls dir das so gefällt, würde ich es die Tage in den Vorlagennamensraum rüberkopieren. Der Umherirrende 21:13, 21. Mai 2012 (CEST)

Sieht gut aus, Überschrift ist auch OK. Gruß. --LezFraniak (Diskussion) 23:05, 21. Mai 2012 (CEST)

Vorlage:Turnierplan16-mitDatum-ohnePosition-5-Byes ist erstellt. Die Score-Spalten haben jetzt eine Mindestbreite von 10px und falls das nicht ausreicht, werden sie größer oder der Inhalt bricht um. Falls das so nicht gewünscht ist, müsste man nochmal überlegen, wie man das angeht. Der Umherirrende 18:54, 23. Mai 2012 (CEST)

Dank dir erstmal. Werde die Vorlage mal einbauen und dann wird sich ja zeigen ob's funzt. Würde mich dann evtl. noch mal melden. erledigtErledigt. Gruß --LezFraniak (Diskussion) 09:03, 25. Mai 2012 (CEST)

Habe ich hier eingebaut. Die Punkte stehen ziemlich eng. Vielleicht wäre es noch gut Eingabefelder für die Zellbreite der HD-Scores zu haben. Habe ich mal bei einer anderen Vorlage gesehen. Wahrscheinlich sieht es auch besser aus wenn sie dann mittig stehen. Sonst aber alles schick. Gruß --LezFraniak (Diskussion) 09:56, 25. Mai 2012 (CEST)

Habe ihn mal score-width genannt, wobei der für alle Scores gilt. So hatte ich es auch in Vorlage:Turnierplan16-kompakt-3 gesehen. Der Umherirrende 10:54, 26. Mai 2012 (CEST)

Das reicht, glaube ich, nicht, wenn es nur 1 Breite für alle Scores gibt. Die Ergebnisse sind 1 bis 5-stellig. wenn ich alle Zellen auf die größte benötigte Breite einstelle sieht das komisch aus. Kannst du Score-width1-5 einrichten? Dann kann man sich auch aussuchen wo man das 5-stellige Ergebnis einfügt. Kann dann auch nach ganz hinten wandern. Oder kann man der automatischen Zellbreite noch, sagen wir +7px, zuweisen? Schöne Pfingsten. Gruß --LezFraniak (Diskussion) 13:35, 26. Mai 2012 (CEST)

PS:Könnte dann so aussehen wie hier. --LezFraniak (Diskussion) 15:49, 26. Mai 2012 (CEST)

Dann gibt es jetzt 5 mal score-n-width. Ist einfacher als rechnen. Schöne Feiertage. Der Umherirrende 16:33, 26. Mai 2012 (CEST)

Super, so sieht's gut aus. Danke. erledigtErledigt. Dir auch schöne Feiertage. Gruß. --LezFraniak (Diskussion) 16:48, 26. Mai 2012 (CEST)

Hallo Umherirrender, Da ich im Portal selbst mal wieder keine Antwort bekomme wende ich mich mal wieder an dich. Kannst du hier helfen? möchte mir ersparen die Einfärbung in jede Zelle zu schreiben. Würde die Syntax auch nur aufblähen. Kannst auch direkt in meine Baustelle schreiben. Dank im Voraus. Gruß. --LezFraniak (Diskussion) 15:34, 4. Jun. 2012 (CEST)

Antwort dort. Der Umherirrende 18:01, 4. Jun. 2012 (CEST)

Nicht ganz. Aber ganz schön bunt. ;-) Die Spalte Spiel soll weiß bleiben, dito Zeilen Verlierer. Nur die Zeilen der Gewinner sollen farbig werden, also Zeile 1 & 3, nicht 2 & 4. Hast du noch einen anderen Tipp parat? Danke. --LezFraniak (Diskussion) 18:27, 4. Jun. 2012 (CEST)

Die Hintergrundfarbe war ja schon da, daher habe ich die nur weiterverwendet. Neuer Versuch. Der Umherirrende 18:32, 4. Jun. 2012 (CEST)

Das war die Sache mit dem Zebra die sich nicht ändern ließ. Muss das jetzt nicht raus? Das ist jedenfalls die Lösung. Wenn ich es richtig verstanden habe sagst du der ersten Zeile Farbe X und stellst dann nur Spalte 1 auf weiß um. Richtig? Danke für die Hilfe. Gruß --LezFraniak (Diskussion) 19:03, 4. Jun. 2012 (CEST)

Ja, so wird es gemacht. Zebra kann raus, ich sehe das aufgrund des IE eh nicht, daher ist es mir nicht mehr aufgefallen. Die Farbe der Sieger wirst du vermutlich auch noch ändern möchten, nehme ich mal an. Kein Problem. Der Umherirrende 19:07, 4. Jun. 2012 (CEST)

Wofür steht IE? --LezFraniak (Diskussion) 19:25, 4. Jun. 2012 (CEST)

Das steht für den Internet Explorer, manchmal gibt es auch IE8, das ist dann die Version 8. FF steht beispielsweise für Mozilla Firefox. Opera und Chrome haben keine (mir bekannte) Abkürzung, aber sind ja auch kurze Wörter, daher nicht so notwendig. Der Umherirrende 19:30, 4. Jun. 2012 (CEST)

uh ja, klar. Danke. Hast du Zeit und Lust eine Infobox aus der WP:en zu portieren? Eilt aber nicht. Da gibt es wahrscheinlich noch ein paar Fragen die evtl. geklärt werden müssten. Wenn du keine Lust hast sag Bescheid dann frage ich in der Werkstatt nach. Gruß --LezFraniak (Diskussion) 21:02, 4. Jun. 2012 (CEST)

Infoboxen sind nicht mein Ding. In Kategorie:Vorlage:Infobox Musik stehen aber noch einge. Infoboxen für einzelnen Personen sind außerdem schwierig in der deutschsprachigen Wikipedia, bis auf Sportler haben da keine überlebt. Der Umherirrende 21:09, 4. Jun. 2012 (CEST)

Wir hatten da jetzt eine längere Disku drüber und es wurde dann beschlossen es doch zu versuchen um das im Portal:Musik mit den anderen zu vereinheitlichen. Ich glaube ich würde dann auch einen neuen Thrad eröffnen um den Inhalt zu klären und nicht mit der Entscheidungsfindung zu vermischen. --LezFraniak (Diskussion) 21:14, 4. Jun. 2012 (CEST)

Viel Glück. Ich kann dabei aber nicht helfen. Der Umherirrende 21:16, 4. Jun. 2012 (CEST)

OK. Trotzdem Danke. Bis bald. ;-) --LezFraniak (Diskussion) 21:20, 4. Jun. 2012 (CEST) erledigtErledigt

Hallo, da ich in den Archiv-Diskussionen zu diesem Thema immer wieder auf deinen Namen gestoßen bin, wollte ich mal nachfragen, bevor ich die Vorlagenwerkstatt behellige. Ich bin ein starker Befürworter der englischen (und eigentlich, von uns abgesehen, internationalen) Vorlage:Navbox. Mir ist völlig unverständlich, was dagegen spricht, und leider konnte ich den vielen, endlosen Diskussionen im Archiv auch nicht wirklich stichhaltige Gründe entnehmen. Wäre schön, wenn du mich aufklären könntest … Gruß, XanonymusX (Diskussion) 19:57, 8. Jun. 2012 (CEST)

Du brauchst die Vorlagenwerkstatt nicht mehr bemühen, ein Benutzer hat bereits Vorlage:Erweiterte Navigationsleiste angelegt, die sich an der englischen Navbox orientiert.

Das Problem, was ich immer sehe, ist das man meint, das Vorlagen die aus en.wp kommen, viel besser sind und das sie so wichtig sind, das man sie auch hier haben muss. Das aber de.wp sich unabhängig von en.wp entwickeln kann, weil es eine andere Sprache und damit andere Kulturen hat und auch sonst andere Ansprüche stellt (ob gut oder nicht, sei mal dahingestellt), wird dort immer verkannt. Ich finde, das die Möglichkeiten, die man mit der schlichten Navigationsleiste hier in de.wp machen kann, völlig ausreichen und somit nicht eine Vorlagentechnisch auch so aufgeblähte Vorlage braucht. Einfacher ist manchmal viel schöner. Man muss nicht alle Möglichkeiten ausnutzen, die MediaWiki hier bietet. Ansonsten habe ich in den Diskussionen höchstens auf andere Diskussionen verlinkt, damit man das Thema nicht immer von neuen (auch kurzfristig) diskutieren muss. Der Umherirrende 22:56, 8. Jun. 2012 (CEST)

Oh, besten Dank für die Hilfe! --XanonymusX (Diskussion) 11:22, 10. Jun. 2012 (CEST)

Hallo Umherirrender, vielleicht hast Du irgendwann mal Lust auf ein Update - jetzt kannst Du ja selbst mithelfen, die Liste wieder abzuarbeiten... ;-) Grüße --Brackenheim 15:09, 23. Mai 2012 (CEST)

Ja, kann ich machen. Beim Abarbeiten kann ich aber nur technisch helfen, von der Fachlichkeit habe ich kaum Ahnung und überlasse es euch sehr gerne ;-). Mal schauen, was meine Leitung die nächsten Tage hergibt. Der Dump ist ja schon auf 6,2 GB gestiegen. Irgendwie scheint meine Leitung langsamer geworden zu sein oder die von wikimedia, weil dumps mit 30 KB/s oder 230 KB/s herunterzuladen, macht einen sehr kleinen Unterschied :-( Der Umherirrende 17:48, 23. Mai 2012 (CEST)

Ok, Danke schonmal! Wenn es länger dauert, ist es ja nicht schlimm - ich find auch so genügend Arbeit =) Gruß, --Brackenheim 18:18, 23. Mai 2012 (CEST)

Das Herunterladen der 6,26 GB hat fast 7 Stunden gebraucht, das Skript war dann in 30 Minuten durch. Jetzt gibt es ca. 200 neue Dateien. Der Umherirrende 20:53, 7. Jun. 2012 (CEST)

Übrigens waren mir dabei auch ca. 600 Dateien aufgefallen, die zwar identsich sind, aber nicht mit NoCommons markiert waren. Diese sind jetzt alle mit NowCommons markiert, damit diese auch bearbeitet werden können. Der Umherirrende 00:00, 9. Jun. 2012 (CEST)

Ah, deswegen ist die Kategorie plötzlich so voll... Danke für die Arbeit! ;-) Grüße --Brackenheim 22:29, 10. Jun. 2012 (CEST)

Das war die Arbeit von RevoBot… --Leyo 16:39, 11. Jun. 2012 (CEST)

Ja, schade, das es nicht mehr (zuverlässig) funktioniert, aber Ersatz kann ich euch da auch nicht bieten. Wobei Ireas Bot auch NowCommons setzen könnte (und gleichzeitig die Vorlage entfernt), wenn er den Transfer abgeschlossen hat, sofern es keine anderen Probleme damit gibt. Der Umherirrende 18:50, 11. Jun. 2012 (CEST)

Die Überprüfung auf .length > 0 bei jQuery kannst Du sparen, denn wenn die Liste leer ist, wird auch nichts gemacht. --Fomafix (Diskussion) 13:59, 16. Jun. 2012 (CEST)

Ja, das hatte ich mir auch so gemerkt, aber irgendwie finde ich es verständlicher, wenn man sieht, das da auch mal nichts sein kann und weiß, das der Programmierer auch an den Fall gedacht hat. Wer sich mit jQuery auskennt, wird von dieser Eigenschaft wissen und vermutlich auch dann daran denken. Ich werde es mir noch überlegen. Der Umherirrende 14:45, 16. Jun. 2012 (CEST)

Ich glaube, ich mach das nicht generell, weil man somit auch unnötige Arbeit für die Browser sparen kann. Wenn ein Attribut zusammengebaut wird, obwohl es nicht benötigt wird, ist das ja auch unnötig und wird der einen Prüfung wohl überwiegen. Teilweise bin ich mir auch nicht sicher, was attr auf eine leere Menge zurückliefert und wenn es undefined ist, wie das beispielsweise mit einer Stringkonkatenation zusammenspielt. Mit Prüfung bin ich da auf der sicheren Seite. Soviele length-Prüfungen können natürlich auch einen negativen Effekt haben, das ist klar. Über das ein oder andere length kann man sicher reden. Der Umherirrende 17:26, 16. Jun. 2012 (CEST)

Statt

var tab = $( '#ca-talk.new a' );
if( tab.length ) {
	tab.attr( 'href', tab.attr( 'href' ) + '&section=new' );
}

kann vereinfacht geschrieben werden:

$( '#ca-talk.new a' )
.attr( 'href', function ( index, attr ) {
	return attr + '&section=new';
} );

Mit JavaScript 1.8 kann das noch weiter vereinfacht werden:

$( '#ca-talk.new a' )
.attr( 'href', function ( index, attr )
	attr + '&section=new';
);

--Fomafix (Diskussion) 11:00, 17. Jun. 2012 (CEST)

Ist das den eine Vereinfachung? Für mich wirkt das eher so, als ob das neue mehr dem jQuery-Konzept entspricht, vorallem wenn man bedenkt, dass das jQuery-Object eine Liste sein könnte. Ist nicht schlecht, ich habe mal ein paar geändert. Viele Leute, viele Schreibweisen für das gleiche. Der Umherirrende 16:24, 17. Jun. 2012 (CEST)

Senf:

Die zweite Variante mag für die jQuery-Welt ja angehen.

Vor der dritten Version wende ich mich jedoch mit Grausen.

• Benutzer mit älteren Browsern müssen JS 1.8 noch nicht verstehen und werden vor die Tür gestellt.
• Für das einfache und fehlerfreie Begreifen durch Menschen (was der eigentliche Sinn einer Programmiersprache ist) wird das Weglassen der Klammern allerdings katastrophal.
• Vorteile bringt es keine: There is no added benefit to writing code in this manner.
• Die regelmäßige Verwendung der Klammern sorgt aber dafür, dass alle menschlichen Leser unter der Quellcode-Sequenz auf Anhieb das Gleiche verstehen wie die Maschinen. Siehe auch Dangling-Else-Problem.
• Sonst können wir ja gleich in Assembler schreiben, wie es gestern jemand einbrachte.
• Vor einer Lambda-Notation habe ich ansonsten keine Angst; ich schreibe seit Jahrzehnten auch in LISP. Aber das ist in einer der drei ältesten Programmiersprachen der Welt schon seit über einem halben Jahrhundert immanent und geht dort gar nicht anders.

Von mehreren Benutzern gewarteter Code wie MediaWiki:Common.... muss ohnehin auf gute Verständlichkeit durch wechselnde Bearbeiter abzielen.

Aber selbst individueller Code in anderen zur Verfügung gestellten Benutzerskripten und Gadgets muss schon aus Sicherheitsgründen nachvollziehbar geschrieben sein. Wenn ein Benutzer einmal nicht mehr aktiv ist, sollen aber auch künftige Wikipedianer die Software noch pflegen, weiterentwickeln und anpassen können.

Sonnigen Tag --PerfektesChaos 10:40, 18. Jun. 2012 (CEST)

Das mit der Lambda-Notation war auch nur ein Ausblick auf eine noch kürzere Schreibweise. Ein Problem wie beim Dangling-Else-Problem sehe ich nicht. Sicherlich schreiben wir nur Code, der auch auf allen Browsern funktioniert und damit ist das sowieso derzeit nicht möglich und jede weitere Diskussion darüber überflüssig. Die Features von jQuery können wir aber schon verwenden. --Fomafix (Diskussion) 10:56, 18. Jun. 2012 (CEST)

Apropos Lambda-Notation: Könntest Du meine Frage von vor fast fünf Jahren beantworten? Diskussion:Landau-Symbole#Lambda-Kalkül --Fomafix (Diskussion) 11:03, 18. Jun. 2012 (CEST)

(OT) λ

Ich kann deine Bedenken und deinen Einwand nachvollziehen, aber die spezielle Technik dieses Dingsdas bezieht das offenbar ein. Wenn es nicht so gemeint wäre, wären ja auch alle gewohnten Landau-Symbole #Beispiele und Notation für die Katz. (Verglichen mit 2007 dort heute auch deutlich besser erklärt)

Ich lese es als g=g(x)=x² und damit: Die Kurzschreibweise soll entsprechen als implizit gemeinte Bedeutung („die laxere Notation“ heißt es weiter unten; dort also etwas frei interpretierbare Schreibweisen).

Das Lambda-Kalkül wäre ja nur eine gleichwertige Notation für g(x)=x² – ändert also nichts am Zusammenhang.

Wenn dir die Antwort gefällt, kannst du sie ja dorthin kopieren.

Liebe Grüße --PerfektesChaos 21:24, 19. Jun. 2012 (CEST)

Hallo Umherirrender, ich bin's schon wieder! ;-) Du bist einfach irgendwie am zuverlässigsten, deshalb gehe ich gar nicht mehr den Umweg über die Werkstatt. Außerdem weißt du ja am besten Bescheid über deine Tabellen. Ich bräuchte diese Vorlage als 8er-Version, also ab Viertelfinale. Wäre toll wenn du das übernehmen könntest. Dank im Voraus. Gruß. --LezFraniak (Diskussion) 19:55, 12. Jun. 2012 (CEST)

Also Vorlage:Turnierplan8-mitDatum-ohnePosition-5-Byes in Anlehnung an Vorlage:Turnierplan8-mitDatum-ohnePosition-Byes. Kann ich mir mal anschauen, kann aber etwas dauern. Der Umherirrende 20:07, 12. Jun. 2012 (CEST)

Ist es nicht einfacher bei Vorlage:Turnierplan16-mitDatum-ohnePosition-5-Byes die erste Runde zu entfernen? Aber du machst das schon. Eilt nicht? Gruß. --LezFraniak (Diskussion) 14:48, 13. Jun. 2012 (CEST)

Ist fertig. Ich glaube, beide Wege sind gleichschnell, würde ich mal sagen. Leider gibt es nicht die Möglichkeit wie in Excel einfach die Spalte zu markieren und entfernen zu drücken … Der Umherirrende 12:17, 16. Jun. 2012 (CEST)

"Kommse vonne Schicht, wat schöneret gibbet nich als wie Currywurst äh Umherirrender" (reimt sich nur nicht) - frei nach Grönemeyer. Wow, das war schnell. Super. Danke. Belohnung folgt. Noch ein schönes WE und bis bald. ;-) Gruß aus Berlin. --LezFraniak (Diskussion) 22:20, 16. Jun. 2012 (CEST) erledigtErledigt

Kein Problem. Ich hoffe, du hast bald alles beisammen ;-) Danke für den Barnstar, macht sich ja ganz gut auf meiner Benutzerseite. Viel Spaß mit den Vorlagen. Der Umherirrende 09:10, 17. Jun. 2012 (CEST)

Wie's der Teufel so will wird auch noch eine nur mit Halbfinale/Finale benötigt.Mir ist noch aufgefallen dass bei den beiden(1/2) Vorlagen die Byes nicht funzen wenn man die HD-scores einträgt. Lässt sich das lösen? Gruß. --LezFraniak (Diskussion) 14:07, 18. Jun. 2012 (CEST)

Du brauchst also noch einen Turnierplan4? Also Vorlage:Turnierplan4-mitDatum-ohnePosition-5-Byes/Vorlage:Turnierplan4-mitDatum-ohnePosition-Byes. Da lässt sich drüber nachdenken.

Ansonsten ist es richtig, das die Überschriften der HD-scores immer angezeigt werden, da sollte ich nochmal nachbessern. Die width-Parameter und die Überschriften sollte man auch nur setzen, wenn man sie braucht, weil nicht geprüft wird, ob sie leer sind, sondern einfach der Wert übernommen wird und nur bei Nicht-Angabe des Parameter der Standardwert zieht. Der Umherirrende 18:48, 18. Jun. 2012 (CEST)

So schaut's aus. Dank im Voraus. --LezFraniak (Diskussion) 18:50, 18. Jun. 2012 (CEST)

Erledigt. Der Umherirrende 20:33, 20. Jun. 2012 (CEST)

Super. Danke. Habe gestern meine ersten Vorlagen selbst erstellt (stolz wie Oskar). Hat sogar gefunzt ohne über die Spielwiese zu gehen. Kannst du dir ja mal anschauen ob ich alles richtig gemacht habe. Vielleicht schaffe ich es dann ja auch mal mit den Turnierplänen, ist nur ein bisschen komplizierter. Wofür steht {{!}}? Arbeitest du direkt in Wiki oder nutzt du einen externen Editor? Gibt's vielleicht auch einen für Mac? Gruß. --LezFraniak (Diskussion) 21:16, 20. Jun. 2012 (CEST)

Ich arbeite häufig direkt im Browser, manchmal auch im normalen Editor. Ja, das ist nicht so schön, aber das ist nunmal Wikitext, da gibt es keine große Syntaxhervorhebung, sondern einfach nur Klammern, manchmal auch viele Klammern.

{{!}} wird benötigt, um zu unterscheiden, wem der Strich gehört. Innerhalb von #if (WP:VP) wird der senkrechte Strich als Parametertrenner des #ifs erkannt, aber hier wird der senkrechten Strich auch als Syntax für die Wikitabelle gebraucht, daher gibt es da ein Set von Vorlagen, die dieses Problem umgehen, siehe auch Hilfe:Vorlagen#Tabellenelemente. Der Umherirrende 21:23, 20. Jun. 2012 (CEST)

Hallo, diese Edits halte ich für eher kontraproduktiv. Laut Coding conventions (und m.W. steht das auch irgendwo anders noch genauer) soll man - gerade im global scope - immer jQuery statt irgendwelche shortcuts wie $ nutzen. Stattdessen sollte es nur - wie geschehen - innerhalb entsprechender local scopes verwendet werden. -- ✓ ^Bergi 23:24, 20. Jun. 2012 (CEST)

In MediaWiki:Common.js wird das auch so gemacht (oder mach ich das auch so) und anderen Gadgets. Müsste man dann nicht jQuery( document ).ready( ... ) schreiben, oder ist jQuery( ... ) gleichwertig? Die Übergabe von $ an die function sieht etwas gewöhnungsbedürftig aus, aber in den MediaWiki-JavaScript-Files sieht man das manchmal auch so. Technisch funktionieren wohl alle, aber was davon "am schönsten" ist, kann ich auch nicht sagen. Der Umherirrende 17:06, 21. Jun. 2012 (CEST)

Es gab im Frühjahr mal einen schwer zu findenden Fehler in der MW-Welt. Dort hatten sich in der Event-Folge zwei leicht unterschiedliche Objekte $ und jQuery ergeben. Diese hatten kleine Differenzen zueinander in der Erkenntnis des aktuellen Dokuments und seiner Struktur, und das hatte gravierende Nebenwirkungen und wurde nur durch Zufall aufgedeckt.

Bei einem derart trickreich benutzten Gebilde mit soviel abenteuerlichen Syntaxkonstrukten wie jQuery kann das schon mal vorkommen.

Deshalb wird in den closures $ zu einem lokalen Argument, das mit dem globalen jQuery aufgerufen wird.

Mit mw und mediaWiki könnte einem das zwar auch passieren, aber die sind viel statischer und weniger gefährdet. Gleichwohl wird in den closures mw zum lokalen Argument identisch mediaWiki.

Im Übrigen ist für weniger routinierte Leute, die ein Skript nachvollziehen wollen, jQuery selbsterklärend; $ wirkt zu Anfang wie ein mysteriöses JavaScript-Syntaxelement, zumal es auch buntschillernd benutzt wird.

Liebe Grüße --PerfektesChaos 18:13, 21. Jun. 2012 (CEST)

Übrigens sagt die verlinkte Seite indirekt auch, das man mediawiki anstatt mw verwenden sollte. Da wir beides in Common.js Nutzen sehe ich kein Grund, das jetzt zu verbieten. Das es für Neulinge einfacher sein kann, zu erkennen wo die ganze Magie funktioniert, stimme ich dir zu. Aber da wird auch das längere Wort wohl nicht wirklich bei helfen, befürchte ich. Der Umherirrende 20:19, 23. Jun. 2012 (CEST)

1. Ich würde dann zu einem großen W raten.
2. mw:RL/DM#mediaWiki 2 schreibt: Alias mw is available everywhere and should be used.
   • Nirgendwo in der MW-Welt, egal ob mit closure drumherum oder nicht, wird beim konkreten Zugriff auf Objektkomponenten mediaWiki. benutzt.
3. Den mw:Manual:Coding conventions/JavaScript#Globals usw. traue ich ohnehin nicht über den Weg. Dort heißt es, man solle als Argument undefined angeben. Wenn ich das mache, springt mir alles Mögliche ins Gesicht mit dem Hinweis, undefined wäre ein geschütztes Schlüsselwort und dürfe nicht als Argument einer Funktion verwendet werden.
4. Ich verwende also mediaWiki nur dann, wenn ich es in solch einer Closure auf mw abbilde. Dann setze ich auch jQuery in ein lokales $ um und verwende von dem Moment an $ – sonst nicht.
   • Um mal ein Beispiel zu nennen.

Liebe Grüße --PerfektesChaos 20:45, 23. Jun. 2012 (CEST)

dafür. -- Wo st 01 (Di / ± / MP) 13:36, 23. Jun. 2012 (CEST)

Kein Problem. Ich hatte das nur auf der Beobachtungsliste gesehen und mich erst gefragt, was du erreichen wolltest und dann gesehen, das es wohl ein Wikilink werden sollte. Wobei ich garnicht mehr weiß, warum die Vorlage eigentlich darauf ist. Der Umherirrende 13:41, 23. Jun. 2012 (CEST)

Hallo Umherirrender, ich habe kürzlich mal ein paar Infoboxen angelegt. Wie kann ich dieser mitteilen dass sie längere Zeilen nicht umbricht, sondern die Spalte automatisch anpasst. Sieht sonst immer so gedrängt aus (Beispiel). Irgendwie hat das mit „nowrap” in der Syntax nicht funktioniert. Dank im Voraus. Gruß --LezFraniak (Diskussion) 22:24, 26. Jun. 2012 (CEST)

Wo hast du das Beispiel, wo es nicht funktioniert hat? Hast du einen Versionsunterschied, dann kann ich mir das direkt anschauen. Der Umherirrende 18:20, 27. Jun. 2012 (CEST)

Hier ist die Vorlage: Vorlage:Infobox_Carambolagespieler. Gruß. --LezFraniak (Diskussion) 18:58, 27. Jun. 2012 (CEST)

Durch diesen Versuch wird es in deinem Beispiel aber etwas breit, finde ich. Aber so könnte es funktionieren. Der Umherirrende 19:30, 27. Jun. 2012 (CEST)

Danke. Vielleicht sollte ich mir überlegen ob ich es nicht so wie hier anordne. Gruß.--LezFraniak (Diskussion) 16:53, 28. Jun. 2012 (CEST)

Das wäre auch eine Möglichkeit, da eine Mindestlänge des Textes ja gegen ist. Wird das ganze nicht so breit machen und am Ende besser aussehen. Unabhängig davon würde ich die Infoboxen aber eh ähnlich gestalten, um gleiche Daten auch gleich aufzufinden. Der Wiedererkennungswert ist dir mit den Farben ja schon gut gelungen. Der Umherirrende 17:23, 28. Jun. 2012 (CEST)

Habe die Vorlage umgestrickt. Sieht dadurch schlanker aus. Das mit dem Nowrap hat aber trotzdem nicht gefunzt. Schah mal hier, da habe ich es wieder händisch eingefügt. Eine Frage habe ich noch. Wenn ich zB bei "Verein" mehrere eingebe und vor jeden ein * setze, dann bleibt das erste ein *, die folgenden werden dann korrekt als grünes Quadrat angezeigt (Beispiel). Habe mir jetzt erst mal mit einem Bullet geholfen, da funzt es. Gruß. --LezFraniak (Diskussion) 20:13, 28. Jun. 2012 (CEST)

Du musst das white-space:nowrap; auch an der Zeile angeben, wo es wirken soll. Ansonsten kann ich dir Hilfe:Vorlagen noch nahe legen, vorallem der Abschnitt Problem: Aufzählungszeichen enthält hier die gewünschte Antwort. Ich habe beides mal gemacht. Der Umherirrende 20:18, 28. Jun. 2012 (CEST)

Ah, OK. Danke. Also nur einmal umbrechen vor dem Parameter. Bevor ich jetzt noch die anderen Zeilen mit white-space:nowrap; versehe, wie schaut es aus wenn ich mehrere Jahres- und Ortsangaben habe? Dann würden wohl alle in einer Zeile stehen, oder? Kann ich dann trotzdem noch mit <br> einen Zeilenumbruch erzwingen? Danke so weit schonmal. Gruß. --LezFraniak (Diskussion) 21:01, 28. Jun. 2012 (CEST)

Ja, würden alle in einer Zeile stehen aber mit <br /> kannst du auch in einer Zeile mit white-space:nowrap; noch einen Zeilenumbruch erzwingen. Der Umherirrende 21:06, 28. Jun. 2012 (CEST)

Danke. Habe noch eine Frage zu Tabellen, stelle diese aber gleich in die Werkstatt. Kannste ja mal vorbei schauen. Bis bald.  ;-) erledigtErledigt

Dieser Abschnitt kann archiviert werden. LezFraniak (Diskussion) 23:23, 28. Jun. 2012 (CEST)

Hallo Umherirrender, ich habe gerade gesehen, dass du in mehreren Artikel die veraltete Vorlage PNDfehlt gegen die erweiterte Vorlage:Normdaten ausgetauscht hast.[1] Dazu nur ein Tipp: Wenn du die Kopiervorlage

{{Normdaten|TYP=p|GND=|LCCN=|NDL=|VIAF=|GNDName=|GNDfehlt=|GNDCheck={{subst:NormdatenDatum}}|REMARK=}}

zu stark verkürzt und dabei den Parameter "GNDCheck" weglässt, landen alle Artikel in der Wartungskategorie Kategorie:Wikipedia:GND fehlt (ohne Datum). Die Datumsangabe ist aber hilfreich für die spätere Überprüfung, da langfristig alle Artikel eine GND erhalten sollen. Fröhliches Schaffen! --Kolja21 (Diskussion) 00:43, 29. Jun. 2012 (CEST)

Hallo Kolja21, ich hatte nur die fehlerhafte Einbindung der Vorlage PNDfehlt umgewandelt. Da dort bereits kein Datum angegeben war bzw. der erste Parameter fälschigerweise mit der Nummer belegt war, habe ich auch in der umgewandelten Vorlage kein Datum gesetzt weli ich nicht wusste wann die Überprüfung statt fand. Selber fühle ich mich nicht in der Lage eine solche Überprüfung durchzuführen. Im Prinzip hast du aber Recht, das man bei Neueinfügungen nicht die Kopiervorlage kürzen sollte, da stimme ich dir zu. Der Umherirrende 14:47, 29. Jun. 2012 (CEST)

Danke, gut zu wissen. Ich wollte nur Doppelarbeit vermeiden. Dann hole ich die Überprüfung bei Gelegenheit nach. Gruß --Kolja21 (Diskussion) 00:20, 30. Jun. 2012 (CEST)

Moin Umherirrender, magst du bitte mal bei Benita Luckmann schauen. Da fehlen auch PND-Daten und ich bin noch nicht "überführungskundig". Beste Grüße --Jürgen Oetting (Diskussion) 19:35, 1. Jul. 2012 (CEST)

Es gibt noch sehr viele zu überführen. Ich habe diesen Artikel aber mal vorgezogen. Der Umherirrende 19:42, 1. Jul. 2012 (CEST)

Danke! --Jürgen Oetting (Diskussion) 20:09, 1. Jul. 2012 (CEST)

Machst Du das eigentlich per Bot oder in mühevoller Handarbeit? Hier gab es ja eine Anfrage dazu: Wikipedia:Bots/Anfragen#Einbindungen von PNDfehlt in Normdaten integrieren, aber leider hat sich dort bislang niemand gemeldet. --AndreasPraefcke (Diskussion) 10:24, 3. Jul. 2012 (CEST)

Ich habe mich an der Botanfrage orientiert und mache es halbautomatisch (Text holen, ändern, dann Versionsunterschied anzeigen lassen, den ich bestätige und dann wird die Bearbeitung ausgeführt). Für vollautomatisch ist mir das etwas zu fehleranfällig.

Zu erst hatte ich mir gedacht, dass ich einem möglichen Botbetreiber etwas Arbeit annehme, in dem ich mich um die fehlerhaften Einbindungen kümmere, also wo das Datum garnicht oder im falschen Format gesetzt oder die Parameter vertauscht waren. Nachdem das einigermaßen geklappt hatte, habe ich auch noch etwas weitergemacht, aber ich hoffe immer noch, das sich ein Botbetreiber findet, weil es doch sehr viel Seiten sind und somit sehr zeitaufwändig ist. Der Umherirrende 17:56, 3. Jul. 2012 (CEST)

Ah, ok. Ich wollte nur sichergehen, dass Du Dir nicht unnötig zuviel Arbeit machst. --AndreasPraefcke (Diskussion) 18:20, 3. Jul. 2012 (CEST)

Wäre es nicht möglich, dass man die Vorlage:Normdaten in die Vorlage:PNDfehlt einbaut? Dann wäre die ganze Umstellung unnötig. Grüße, —Derschueler 08:37, 4. Jul. 2012 (CEST)