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
Zum zweiten Problem kann ich nichts sagen. Der Text "Weltmeisterschaften" wird mittig dargestellt, nur ist der zur Verfügung stehende Bereich durch das Bild links etwas verrutscht. Sieht komisch aus, dürfte aber andere Navigationsleisten mit Bildern auch betreffen. Wobei bei anderen Navigationsleisten das Bild nicht so groß sein dürfte. Hier habe ich keine Lösung für dich. Der Umherirrende 19:03, 3. Jan. 2013 (CET)
Danke. Jetzt schwebt das Aufzählungszeichen nur am linken Rand. Habe es schon mit Align:center versucht, ging aber nicht. hast du da eine Idee? Gruß. --LezFraniak (Diskussion) 15:32, 4. Jan. 2013 (CET)
Bei mir wird das Aufzählungszeichen für "Daniel Sánchez" ganz normal vor dem Text angezeigt, wobei der Text mittig in der Infobox steht. Ich nutze IE8/monobook. FF17/vector sieht auch gut aus, aber Opera12/vector nicht. Da bin ich ehrlich gesagt, sehr überfragt, warum dort die Aufzählungszeichen anders behandelt werden. Vielleicht hilft dir WP:CSS oder WP:TSW weiter, dort finden sich mehr Informationen und Benutzer, die so etwas häufiger machen. Der Umherirrende 16:12, 4. Jan. 2013 (CET)
Hmm, nutze Safari/monobook. Habe alles zurückgesetzt und Browser- und Wikicache gelöscht. Wird aber immer noch links angezeigt. Vielleicht lasse ich es einfach so. Dank dir nochmals. Gruß. --LezFraniak (Diskussion) 17:17, 4. Jan. 2013 (CET)
TSW ist schon da, der BK war ein Zwinkern mit dem Pfahl, äh, Zaun, äh, egal.
Im FF sind die Aufzählungspunkte bei mir auch nicht auf Linie.
Der Grund ist aber klar:
In die Tabellenzelle gehört eine div. Diese wird mittig innerhalb der Tabellenzelle ausgerichtet.
Innerhalb der div steht dann linksbündig die Aufzählung.
Nirgendwo ist ausdrücklich gesagt, dass Aufzählungspunkte trotzdem untereinander stehen sollen, wenn gleichzeitig die einzelnen Aufzählungselemente mittig stehen sollen. Was dann passiert, ist Glückssache. Ob dann das in Opera vielleicht linksbündig overruled wird und woanders nicht kann man nicht voraussetzen.
Machst du das hübsch? Da sind noch irgendwelche Untervorlagen Spieler-Siege und so, die ich noch nicht durchgeguckt habe; du warst eh grad schon dran, vielleicht kann man pipe und div ja auch auf die Untervorlagen verteilen. Es gibt möglicherweise mehrere solcher mittiger Aufzählungs-Zellen.
@PerfektesChaos: BK, FF, ARD und ZDF????? Ick fasteh nur Bahnhof! Aber wahrscheinlich war das an den Umherirrenden gerichtet, oder? Danke für's mitmischen und Anregungen. Gruß. --LezFraniak (Diskussion) 20:40, 4. Jan. 2013 (CET)PS: Eure BNs sind e.c.!
So sieht es beispielsweise im Opera/Safari aus
0
A
0
AB
0
ABC
Auf Linie sind sie im IE8 auch nicht, aber im FireFox stehen sie zumindenstens direkt vor dem Text und nicht alle linksbündig am linken Rand, während der Text der aufgezählt wird, mittig ausgerichtet ist (Ich habe es mal mit einer Tabelle etwas gefaked). Ich glaube nicht, das LezFraniak vor hatte, die Aufzählungszeichen in Linie zu haben und den ganzen Block dann in der Mitte des Textes. Das kann man wohl eher mit einer Layouttabelle erreichen. Der Umherirrende 20:51, 4. Jan. 2013 (CET)
So wie in deinem Beispiel sieht es bei mir in Safari aus. In Firefox war es OK. In Linie brauchen sie nicht unbedingt zu sein. Habe erstmal eine Zwischenlösung mit Bullet (•) und Zeilenumbruch gefunden. --LezFraniak (Diskussion) 21:16, 4. Jan. 2013 (CET)
Klammer
kann man diesen Versuch der Klammer vielleicht ordentlich hinbasteln? Ich denke mal die wird auf jeder Seite mindestens einmal gebraucht und ist daher nicht unnützlich ;-)
Was genau war den nicht ordentlich? Für mich sieht das erstmal syntaktisch richtig aus und sollte so funktionieren. Der Umherirrende 11:07, 2. Jan. 2013 (CET)
Keine Ahnung, du hast mich zurück gesetzt, daher dachte ich, ich habe vielleicht was falsch gemacht
AARGHHH! Datei:Smiley emoticons doh.gif Total verpeilt. Jetzt fällt es mir wieder ein, ich hatte mich zurückgesetzt weil es eben nicht funktionierte?! Auf dich bin ich wohl gekommen, weil ich mich auf deine letzte Bearbeitung zurückgesetzt habe. Wenn du trotzdem mal schauen könntest? Ich denke das wäre schon nützlich ;-)
Das sollte so eigentlich funktionieren. Vermutlich war es nicht sofort aktiv, wegen Hilfe:Cache oder so. Schau mir am Wochenende an. Der Umherirrende 20:56, 3. Jan. 2013 (CET)
gerrit:40799 ist dabei, es gibt also jetzt die neuen IDs.
Doppelte ID mw-import-table gibt es jetzt als mw-import-table-upload und mw-import-table-interwiki
Doppelte ID mw-interwiki-rootpage gibt es jetzt als mw-interwiki-rootpage-upload und mw-interwiki-rootpage-interwiki
input mit name=xmlimport hat eine gleichlautende ID
select mit name=interwiki hat eine gleichlautende ID
input mit name=frompage hat eine gleichlautende ID
gerrit:40808 ist noch nicht dabei, da wurde das size-, type- und value-Attribute der inputs irgendwie geändert, weil der Validator das nicht mochte. Das sollte deine Skripte nicht beeinflussen. Quelltext gibt es morgen, dann aber mit beiden Änderungen, oder möchtest du das lieber getrennt haben? Der Umherirrende 19:44, 17. Jan. 2013 (CET)
Danke für alles; mach es in Ruhe und mit möglichst wenig Aufwand für dich.
Ich schmeiße erstmal anhand der obenstehenden Hinweise die workarounds aus meinem Code, solange ich da noch durchblicke.
Danke schön; mein schicker Formatter bin ich selber, hatte einfach alles aus dem HTML-Code herausgelöscht, was nicht zum Formular und seiner ungefähren Anmutung gehört.
Etwas anderes hätte ich noch:
Die Programmierung ist abgeschlossen; nach einigen lustigenAttacken erbitte ich nunmehr Vollschutz für
Ich habe die Vorlagen mal mit [edit=autoconfirmed][move=sysop] versehen, das reicht in vielen Fällen gegen Vandalismus. Der Umherirrende 11:12, 19. Jan. 2013 (CET)
nochmal PAGENAME
Hallo Umherirrender,
ich wende mich an dich, weil du hier geantwortet hattest. Mein Problem ist folgendes: Ich möchte in dieser (und dann vielen ähnlichen) Vorlage(n) den Spielernamen, also Santi Cazorla ausgeben. Allerdings gelang es mir mit keinem der in dem FzW-Thread erwähnen Variablen. Weißt du Rat? Ein Hinweis noch: Das von dir verlinkte Funktion titleparts funktioniert hier nicht, weil ich die Vorlage selbst mit einer anderen Vorlage per preload fülle, und den eigentlichen Namen nie übergebe. Danke und Gruß -- Hepha!±ion?18:26, 21. Jan. 2013 (CET)
Die Variablen wie PAGENAME werden beim Einbinden immer auf den aktuellen Seitennamen aufgelöst. Das PAGENAME in Vorlage:Metadaten Fußballstatistik/Santi Cazorla wird also auf der Seite Deutschland auch den Wert "Deutschland" haben. Daher nützt dir auch titleparts hier nichts, wenn du ihm PAGENAME übergibst.
Wenn du das ganze aber nur auf der Vorlagenseite verwenden möchtest, kannst du {{#titleparts:{{PAGENAME}}|1|-1}} nutzen, würde dann "Santi Cazorla" ergeben. Wenn du den Wert aber in einem Artikel verwenden möchstest, musst du ihn im #switch als Wert ablegen. SUBPAGENAME funktioniert hier nicht, weil der Vorlagennamensraum nicht Unterseiten untersützt. Man kann zwar '/' im Seitennamen nutzen, aber MediaWiki ergänzt nicht den Link auf das Hauptthema, wie beispielsweise auf Archivseiten. Wenn du eine preload-Vorlage zum schnelleren Erstellen nutzt, könntest du dort ein {{<includeonly>subst:</includeonly>#titleparts:{{<includeonly>subst:</includeonly>PAGENAME}}|1|-1}} vermerken, dann wird der Spielername direkt aufgelöst, wenn das erste Mal gespeichert wird. Ich hoffe, das hilft dir. Der Umherirrende 20:09, 21. Jan. 2013 (CET)
Super! Die Funktion von PAGENAME ist mir schon klar; ich wusste nicht, dass im Vorlagennamensraum keine Unterseiten unterstützt werden und dass man titleparts auch mit PAGENAME kombinieren kann. Die switch-Funktion brauche ich nicht; ich würde dir auch gerne erklären warum, aber ich glaube du würdest es nicht verstehen; nicht weil dus nicht verstehen würdest, sondern weil ichs nicht erklären kann =). Nur so viel: Es gibt eine andere Vorlage, die auf diese Vorlage zugreift, deshalb ist es nicht nötig. Dass das ne ziemlich schwache Performance ist, ist uns bewusst, nur kriegen wirs nicht besser hin =). Jedenfalls danke nochmal! Gruß -- Hepha!±ion?21:39, 21. Jan. 2013 (CET)
indexieren, Lokalisierung
Hei Umherirrender, kannst du noch in MediaWiki:Newarticletext-2 und MediaWiki:Newarticletext-2/de-formal das Wort „indiziert“ durch das korrekte „indexiert“ austauschen? Sonst wirkt es auch seltsam, wenn es im selben Infotext mal so und mal anders steht. Die Suchmaschinen sollen doch nicht die neuen Seiten zensieren, oder? Das suggeriert das Wort aber. Man sollte auch besser statt des Kommas ein Semikolon dahinter setzen, da anschließend ein neuer Hauptsatz folgt und die Satzgliederung dann intuitiver erfassbar wäre; so wie jetzt stolpert man da etwas und muss das dann zweimal lesen. Alternativ wäre auch möglich, den Satz dort hinter „indexiert“ zu beenden und einen neuen Satz zu beginnen. Das wäre wohl noch besser als das Semikolon. Viele Grüße --Geitost18:09, 25. Jan. 2013 (CET)
1 und 2. Hoffe, das passt so. Der Umherirrende 20:43, 25. Jan. 2013 (CET)
Dein Hinweis hatte sich gerade mit meiner Bearbeitung überschnitten ;-) Der Umherirrende 10:39, 26. Jan. 2013 (CET)
Oh, das ging ja fix, danke. :-) Irgendwie dachte ich bisher, dass die de-ch-Varianten inzwischen vollständig seien, nachdem Filzstift und du da mal gezielt drübergegangen wart. Ob's da wohl noch mehr „ß“s ohne de-ch-Variante im MW-NR gibt? Ist mir bisher nicht aufgefallen. --Geitost10:44, 26. Jan. 2013 (CET)
‚Standardmäßig‘ hab ich mit der Suche jedenfalls noch 2-mal gefunden: in MediaWiki:Metadata-fields (dort fehlen auch noch die beiden Vorlagen für die Schweizer Anführungszeichen) und in MediaWiki:Revreview-edited, wo beim Singular ‚standardmäßig‘ und beim Plural ‚standardmä{{{ß|ß}}}ig‘ steht. Sollte man vereinheitlichen und dann sollte MediaWiki:Revreview-edited/de-ch gelöscht werden.
Ist ja schon bei vielen dieser Nachrichten etwas umständlich mit der Übergabe der Parameter und Ersetzung der Zeichen auf der de-ch-Unterseite, seh ich dabei gerade (ist wohl im März noch anders umgesetzt worden als jetzt). Könnte man eigentlich alles ersetzen und dann die de-ch-Unterseiten weglöschen, aber das lohnt sich evtl. im Allgemeinen nicht, da ja dasselbe anschließend weiterhin angezeigt wird. --Geitost11:16, 26. Jan. 2013 (CET)
Revreview-edited ist angepasst. Wie man ß/ss und die Anführungszeichen setzt, ist eigentlich egal, da mach ich mir jetzt keine Mühen drum. Die /de-ch können nicht gelöscht werden, weil sonst die lokalen Anpassungen nicht ziehen würden. Bei MediaWiki:Newarticletext-2 braucht es kein /de-ch, weil unter MediaWiki:Newarticletext/de-ch die Einbindung der de-Variante mit den Paramtern passiert. Es bräuchte nicht {{ß}} genutzt werden.
MediaWiki:Metadata-fields dient nur als Konfigurationsseite, welche Felder der Metadaten auf Dateiseiten angezeigt werden sollen und wird immer in der Inhaltssprache genutzt. Der Umherirrende 11:25, 26. Jan. 2013 (CET)
Aha, na gut, klingt etwas kompliziert durchdacht.
Und warum gibt es die Listenelemente gpslatitude, gpslongitude, gpsaltitude nur in den Fallback-Varianten und nicht bei MediaWiki:Metadata-fields? Werden dann mit de-ch mehr Felder auf den Dateiseiten angezeigt, als wenn man ‚de‘ eingestellt hat? Das kommt mir seltsam vor. Soll das so sein? (Oder ich hab dich da nicht verstanden.) --Geitost11:34, 26. Jan. 2013 (CET)
Es gibt mehrere solcher Konfigurationsseiten, die anschließend nach verschiebenden Muster aufgesplittet und genutzt werden, beispielsweise auch die Spamblacklist oder die Titleblacklist. Jeder Benutzer der deutschsprachigen Wikipedia bekommt die Listenpunkte, die auf MediaWiki:Metadata-fields stehen, also immer das was in der Inhaltssprache (hier de) definiert ist. Die von dir genannten Punkte sind vermutlich irgendwann mal hinzugefügt worden, hat aber keiner hier lokla nachgetragen, da solltest du aber besser Raymond fragen, weil er die Seite auch mal angelegt hatte. Der Umherirrende 11:50, 26. Jan. 2013 (CET)
Ah ok, so war das gemeint. Dann werden die 3 Punkte also hier bei de: niemandem angezeigt und sind vielleicht auch nicht mal gezielt weggelassen worden.
Was immer da an GPS-Daten angezeigt werden soll; evtl. wird damit der Standort definiert, wo ein Foto aufgenommen wurde (Längen-/Breitengrad/Höhe, en:Longitude/en:Latitude/en:Altitude). Zweifelhafte Info wäre das, so was widerspräche wohl WP:ANON, dass man dadurch weiß, wer wann an welchem Ort war, nicht? (Sind ja nicht alles Fotos von bekannten Denkmälern; bei privateren Fotos wäre das wohl problematisch, wenn dadurch der genaue Wohnort von Fotografen oder von Personen auf dem Foto bekannt würde, wenn es sich nicht um einen öffentlichen Ort handelt, wo das Foto aufgenommen wurde.) Vielleicht doch besser gezielt weggelassen, aber warum gibt's solche Variablen dann überhaupt? Auf Commons werden die dann ja sicher genutzt, sonst wären sie nicht standardmäßig vorhanden. Wäre ein Grund, nicht dort hochzuladen. Aber mit der Verschiebung nach dort würden dann private Ortsangaben sichtbar?? Mmh. --Geitost12:14, 26. Jan. 2013 (CET)
Wenn man sich die Datei herunterlädt und per Bildsoftware anschaut, kann man sich die Werte sicher auch anschauen. Es geht ja nur darum, was man auf der Dateibeschreibungsseite auf deutschsprachigen Wikipedia standardmäßig ausgeklappt dargestellt sieht. Alle anderen Felder werden eingeklappt dargestellt, sind also auch für jeden sichtbar. Das ist eigentlich auch der Sinn der Metadaten. Das man hier indirekt seinen Klarnamen veröffentlichen kann, wenn die Kamera den an die Datei hängt, kann passieren. Dateilöschungen gab es deshalb sicher auch schon. Der Umherirrende 12:19, 26. Jan. 2013 (CET)
Ja, oder die Löschung von Metadaten, das hab ich schon mal irgendwo gesehen. Man bräuchte eine Funktion beim Upload Wizard, die Metadaten abschneiden zu lassen oder einzelne gezielt weglassen zu können. Das wäre sinnvoll, wenn man schon Leute dazu animieren will, eigene Fotos zur Weiterverwendung hochzuladen. :-)
Bei Denkmälern und so wären hingegen zumindest die Geodaten schon sinnvoll, da könnte man sie gleich in die zugehörigen Artikel übertragen. --Geitost12:35, 26. Jan. 2013 (CET)
Geisterhafte Namensräume
Hallo,
in diesen Stunden taucht auf der erweiterten Suche oder in den NR-Auswahlen (etwa Alle Seiten) ein „CNBanner“ auf (866/867, CentralNotice). Vor einer Weile hatten wir dort TimedText. Haben wir den Bug oder MW? NR>101 sind bei uns nicht anzuzeigen.
08:20 logmsgbot: pgehres synchronized php-1.21wmf8/extensions/CentralNotice/ 'Updating CentralNotice to master'
Also sollte es hier ab 9:20 Uhr wohl zu sehen sein (gerrit:46497). Die eigentliche Funktionalität wurde mit gerrit:26502 implementiert. Hört sich aber so an, als ob das nur auf metawiki aktiv sein sollte. Wird dann das Übersetzen vereinfachen, würde ich vermuten. Ich habe im Change mal eine Frage hinterlassen, wenn innerhalb der nächsten 12 bis 24 Stunden nicht reagiert wurde, ist ein Bug im bugzilla wohl besser und erreicht die richtigen Leute. Gerne kann auch jemand direkt einen Aufmachen, dann gehts vielleicht schneller. Der Umherirrende 19:57, 29. Jan. 2013 (CET)
Hallo Umherirrender, diesmal geht es mal nicht um Tabellen. Kennst du dich mit Interwikilinks aus? Wenn ja, dann schau doch mal hier. Habe es versucht mit löschen und wiedereinfügen, hat aber nicht geklappt. Auch nicht mit Cache löschen. Weißt du Rat? Dank im Voraus. Gruß. --LezFraniak (Diskussion) 13:25, 31. Jan. 2013 (CET)
Dieser Abschnitt kann archiviert werden. LezFraniak (Diskussion) 14:20, 31. Jan. 2013 (CET)
Text am oberen Rand der Zelle?!
Hallo Umherirrender, da bin ich schon wieder ;-). Habe ein formales Problem mit einer Vorlage. Wenn ich in die Felder GD, ED und HS mehrere Spieler eintragen will, wird der Text mittig der Zelle gesetzt. Das sieht ein bisschen unübersichtlich aus (s. Beispiel in Vorlage). Besser wäre wenn der Text links am oberen Rand der Zelle sitzen würde. Habe es schon mit „style:align=top" und „toptextcells" versucht, hat aber leider nicht funktioniert. Außerdem zeigt die Syntax mir Klammerfehler beim „if" an. Auch da habe ich nicht herausgefunden woran es liegt. Brauche mal wieder deinen Rat. Dank im Voraus. Gruß. --LezFraniak (Diskussion) 14:04, 8. Feb. 2013 (CET)
Nach dieser Änderung sieht es für mich eigentlich gut aus, wenn ich
verwende. Du musst bedenken, wenn eine Vorlage sich selber verwendet (zum Beispiel für die Doku), kann manchmal noch die alte Version für die Anzeige verwendet werden, da hilft dann ein Purge. Die #ifs sehen gut aus. Der Umherirrende 15:21, 8. Feb. 2013 (CET)
Ahh, der hinterhältige „Purge" nun wieder. Der gibt seine Weisheit auch nur durch anschubsen preis. Danke. War dann ja doch nicht so falsch von mir. Hast du noch eine Idee hierfür? Gruß. --LezFraniak (Diskussion) 17:40, 8. Feb. 2013 (CET)
Ich würde es untereinander lassen, nur weil dein Bildschirm den Platz hergibt, muss es nicht auch bei anderen so sein, das man sie nebeneinander platzieren könnte. Siehe auch WP:Spaltensatz. Der Umherirrende 18:36, 8. Feb. 2013 (CET)
War mir nicht sicher, welches Wort am besten verlinkt werden sollte, passt es so? Der Umherirrende 12:52, 9. Feb. 2013 (CET)
Ich dachte eigentlich eher an einen rechts oben wie bei den anderen Seiten; durchschaue aber nicht, wo uns was technisch möglich ist.
Bei der Verlinkung des Wortes „Baumstruktur“ würde ich sonst als Leser vermuten, dass mir im ANR erklärt wird, was eine Baumstruktur ist. Dann besser hinter den Satz ein
Das geht hier auch, mal gemacht. Immer dort, wo auch die Common.js/Common.css geladen wird, kann man das Icon machen, auf Spezial:Einstellungen daher beispielsweise nicht. Der Umherirrende 15:12, 9. Feb. 2013 (CET)
Bei Thema was in den Hilfenamensraum und was in den Wikipedianamensraum gehört, kann ich dir auch nicht helfen. Sei mutig, dafür braucht man keinen administrativen Segen, Admins sind auch nur Benutzer mit ein paar (technischen) Sonderrechten, die hier nicht benötigt werden ;-) Der Umherirrende 19:02, 13. Feb. 2013 (CET)
Präventives Sperren auf solchen Archivseiten muss nicht sein, es werden sich wohl die wenigsten dahin verirren und noch weniger mit "schlechten Absichten". Du könntest {{Wikipedia-Archiv}} setzen, wenn du möchtest. Der Umherirrende 21:46, 15. Feb. 2013 (CET)
Schlechte Absichten unterstelle ich auch nicht, aber Benutzer im Tran, die auf historischen Suchergebnissen landen. Die Archiv-Bausteine hatte ich mir schon selbst oben drüber gebaut, aber ich habe schon Leute viele Sperren ungebremst überfahren sehen.
Nicht so wichtig; ein Weilchen werde ich die ja noch sicherheitshalber auf der Beo halten und kann Irrläufer einfangen gehen. VG --PerfektesChaos21:52, 15. Feb. 2013 (CET)
Mein erster Kunde und ich übersehe ihn. Entschuldige, ich habe deine Änderung auf meiner Beobachtungsliste irgendwie übersehen. Ich treffe die Vorbereitungen, dass du eine Mail bekommst. Bei der kleinen Anzahl an Kategorien kann ja nichts schief gehen. Der Umherirrende 23:12, 16. Feb. 2013 (CET)
E-Mail ist raus, habe 7 Seiten gefunden. Der Umherirrende 23:40, 16. Feb. 2013 (CET)
Habe die Artikel jetzt auf meiner BEO. Kriege ich dann einmal im Monat eine Mail wenn es neue unbeobachtete Artikel in der Kategorie:Pyrotechnik gibt? Grüße LZ6387Disk.Bewertung11:17, 17. Feb. 2013 (CET)
Ja, so ist es geplant. Da das ganze aber nicht automatisch läuft, wird es am Wochenende passieren. Ich denke aber, das ich Mitte des Monats mich daran erinnern kann, das ganze einmal anzustoßen. So dass erstmal nichts von deiner Seite aus zu tuen ist. Der Umherirrende 11:56, 17. Feb. 2013 (CET)
Wenn es auf preferences#RC schon seit 2009 (vorher, behauptet bugzilla:18499#c3, meldete WP:NEU 2011) seitenbezogene Gruppierung gibt, dann müsste es doch auch auf preferences#watchlist das gleiche Häkchen geben (können)? Ist das vergessen worden, geht das aus irgendwelchen Gründen nicht, oder steckt das irgendwo in der Pipeline? Ist das irgendwie neu auf der Beo?
Wenn es nicht über MW laufen sollte, kann man ja per Gadget / MW:Common.js die Beo mit einem Knöpfchen ausstatten, so dass bei user.option „erweiterte Beo“ die Seite ggf. mit &enhanced=0/1 in der URL neu ausgestattet wird.
Manche der Einstellungen für RC gelten auch für Watchlist. Diese gehört dazu, hier durch das "und auf der Beobachtungsliste" verdeutlicht, auch wenn es im falschen Tab steht. Der Unterschied ist nur, das man zusätzlich die Option "Erweiterte Beobachtungsliste zur Anzeige aller Änderungen" aktivieren sollte, sonst macht das keinen Sinn (Es können keine Gruppen entstehen). Wie weit das jetzt dem Gadgetwunsch entspricht, habe ich nicht geprüft. Der Umherirrende 17:19, 28. Jan. 2013 (CET)
Danke erstmal.
Oje, als Benutzerführung ist das natürlich Hölle; nix mit intuitiv.
Dass das so ist, wusste noch nicht einmal ich; und etwa Leyo und andere wohl auch nicht. Obwohl es auf H:BEO#Erweiterte Beobachtungsliste korrekt und erstmal halbverständlich dargestellt ist; allerdings vielleicht noch etwas besser herauszuarbeiten.
Hilfe:Einstellungen#Beobachtungsliste ist dann aber definitiv zu kurz geraten; hier muss noch ergänzt werden, dass die Option „seitenbezogene Gruppierung“ über den anderen Tab zu setzen ist.
Ich werde mich dann in Kürze über die Hilfeseiten hermachen. Welche „Manche der Einstellungen für RC gelten auch für Watchlist“ sind denn noch davon betroffen, damit ich die auch gleich erwische? Eigentlich sehe ich bei preferences#RC keine weiteren Optionen. (Ich bin kein RCler und hatte auf dieser Seite noch nie inhaltlich was gemacht; war auch nie auf den preferences#RC gewesen.)
Eigentlich müsste man auf die preferences#BEO noch einen deutlichen Extra-Hinweis mit Link auf den Abschnitt der bald ausgebauten Hilfeseite schmuggeln. Kommen wir an den Text ran?
Mit dieser Info hat sich die gadget-Vorstellung erledigt.
Mir schwebt dann aber ein Helferlein vor, das spontan an die URL auf Klick ein enhanced=anderslang anhängt.
Wie ich gerade im Quelltext sehe, stimmt das nicht (mehr?). Vielleicht habe ich es auch mit dem Wunsch vertauscht, die Optionen für die standardmäßigen Filtern auf der Watchlist auch für RC zu haben (hidebots, hideanons, hideliu, hidemyself, Bug 27050 usw.). Also kannst du meinen Satz ignorieren. Auf Preferences gibt es wohl keinen geeigenten Ort (mit uselang=qqx angeschaut). Der swap-Link sollte wohl als User-Skript reichen oder direkt in MediaWiki eingebaut werden, das einzige Problem ist, das enhanced muss man dann über alle Filterlinks/Clearbutton noch weitergeben, damit es nicht verloren geht oder man setzt per API die Einstellung beim Klick. Der Umherirrende 20:25, 29. Jan. 2013 (CET)
Na, dann denke ich mal über ein Gadget als Zwischenlösung nach.
Eigentlich ist das aber eine Sache für MediaWiki, auf den Spezialseiten ein Schalterchen anzubieten, das ein temporäres Switchen in die andere Darstellung anbietet. Das hilft aber nur denjenigen, die allgemein die erweiterte Darstellung (der Beo) aktiviert haben.
Ich benutze (im Regelfall, kannte ja keine andere) die nicht-enhanced und bin damit ganz glücklich; vor allem wenn ich mir alle ANR der letzten 30 Tage angucke, will ich die Geschichte übersichtlich und chronologisch und nicht in den zusammengefassten blauen Dreiecken begraben.
Vorübergehend per API die preferences umswitchen und dann wieder zurück ist zu wacklig und geht früher oder später schief.
Vielmehr lese ich bekanntlich Formulare aus; also hier den aktuellen Stand von allen hidden und daraus die URL mit aktiviertem/deaktiviertem getoggleten enhanced bauen:
<inputtype="hidden"name="reset"value="all"> ----------------- den nu grad nicht
<inputtype="hidden"name="days"value="0.041666666666667"><inputtype="hidden"name="hideAnons"value="1"><inputtype="hidden"name="hideBots"value="1"><inputtype="hidden"name="hideReviewed"value="0"><inputtype="hidden"name="namespace"value="10"><inputid="nsinvert"type="checkbox"><inputid="associated"type="checkbox"><selectid="namespace"class="namespaceselector">
Auf der Beo natürlich unter Beachtung von mw.user.options.get("extendwatchlist") und das gleiche Gadget auch auf RC anwendbar.
Du musst ja kein Formular auslesen, sondern nur das vorhandene um den Parameter erweitern, damit der Browser das beim submit oder Linkklick mitgibt, also sollte nachfolgendes reichen, um das mitzugeben, falls er nicht den Einstellungen entspricht (und 1 sollte man wohl nicht hardcodieren, ist ja nur eine Idee/Versuch).
Sah als test gut aus, nur nicht bei reset=all, das liegt aber an MediaWiki, weil an der Stelle nur mit bekannten Parametern weitergemacht wird und enhanced ist an der Stelle kein bekannter Parameter. Der Umherirrende 17:21, 30. Jan. 2013 (CET)
Ah ja.
Ich wusste nicht, dass sogar die GET-Methode (also das form) bereits enhanced kennt. Bisher kenne ich seit nicht mal einer Woche enhanced= in der URL. So vereinfacht es die Sache allerdings.
Bei der RC-Seite und bei einer Beo mit mw.user.options.get("extendwatchlist") kann man dann einfach eine checkbox ergänzen, die als Startwert beim Seitenaufbau mw.user.options.get("usenewrc") enthält. Alternativ kann man der checkbox sogar ein Gedächtnis verpassen, indem man in der HTML-Seite nach einem formattechnischen Anhaltspunkt grabbelt, ob enhanced aktiv ist; warum auch immer (preferences oder gerade eben temporär). Wenn ja, wird mit Häkchen vorbelegt.
Und diese checkbox kann eigentlich MediaWiki bereitstellen. Warum immer ich?
Nebenbei sind es denkbar inhaltsfreie und sinnlose Parameternamen, wenn man "usenewrc" (Was ist neu? Alles ist irgendwann mal neu. Besser wäre was mit group.) oder enhanced oder extended wählt. Die sagen nun garnix.
Viele der Parameter, die an MediaWiki gehen, funktionieren mit POST oder GET, nur wenige ausschließlich mit POST (beispielsweise das reset=all von oben).
Es sollten genug CSS-Klassen zur Erkennung bereitstehen (arrow oder so etwas).
Namen sind Schall und Rauch oder historisch gewachsen ;-) Der Umherirrende 15:22, 1. Feb. 2013 (CET)
Die vorhandenen URL plane ich noch on-the-fly entsprechend der checkbox umzunödeln. Außerdem kann auch die URL der Seite noch auf enhanced untersucht werden und den ultimativen Startwert liefern.
Was ist denn bloß mit Bergi los? Und was war das für ein verstecktes AFT am 19. Januar?
Schaut erstmal ganz nett aus, ob ich das allerdings brauche, weiß ich gerade nicht, komme mit dem togglen (noch) nicht aus.
Unter Bergis-Benutzerkonto wurde eine Rückmeldung ohne Kommentar erfasst (diese erscheinen immer in den Bearbeitungen) und anschließend von Brackenheim versteckt. Keine Ahnung, warum, ein Logbuch scheint es nicht zu geben, wo man einen Begründung lesen könnte. Der Umherirrende 19:01, 3. Feb. 2013 (CET)
Inzwischen bin ich dabei, alle nur verlinkten Optionen (bis auf die days) auch per checkbox verfügbar zu machen, damit mehrere Optionswechsel gleichzeitig ein völlig geändertes Szenario ermöglichen. Umgekehrt könnten einzelne mit einem einzigen Klick auf ein Link losgetreten werden, statt mit erst checkbox und danach [Anwenden] zwei Klicks zu erfordern. Nur die vielwertige Zeitraum- und Namensraum-Auswahl entziehen sich dem, während die schlichten ja/nein-Selektionen da simpel zu bedienen sind. Gleich geht’s weiter --PerfektesChaos12:34, 9. Feb. 2013 (CET)
Ja, das ist sehr unterschiedlich in MediaWiki gelöst, manchmal Links, manchmal Button, gibt auch verschiedene Bugs für die verschiedenen Spezialseiten für. Der Umherirrende 12:54, 9. Feb. 2013 (CET)
Die Hoffnung auf Bugs und Bugzilla habe ich aufgegeben. Die heute aktualisierte en-Version passt bei Veränderung jedes Formularfeldes auch alle Links simultan an. Obendrein gibt es eine Option, dass zusätzliche Checkboxen für die hide/show-Links ergänzt werden können. Damit kann man sich ein anderes Abfrageprofil zusammenstellen und in einem Rutsch abrufen. Soviel dazu, gute Nacht --PerfektesChaos23:57, 10. Feb. 2013 (CET)
Ja, die Situation ist bei einigen Sachen grausam. Dank gerrit konnte ich den einen oder anderen kleinen Bug aber auch schon beheben, was einiges (für mich) hier angenehmer macht. Natürlich ist auch noch Luft nach oben, aber ein kleiner Anfang ist gemacht. Das Problem was ich dort sehe ist, das sich die neuen Entwickler (teilweise) gerne in etwas neues, eigenes "verewigen" möchten. Fehler anderer zu beheben kann auch unliebsame Aufgabe sein, bringt manchmal aber mehr. Es ist ein Spagat zwischen neuen Funktionen und Pflege der alten Funktion. Aber das dürfte jedes Software-Projekt nach dem ersten Release haben ;-) Der Umherirrende 20:50, 11. Feb. 2013 (CET)
Den Eindruck kann ich bestätigen; statt den Bestand abzurunden und auch endlich mal sauber zu dokumentieren, geht es in VisualEditor und AFT und neues buntes animiertes Zeugs; der ResourceLoader ist wohl auch Anfang 2012 steckengeblieben.
Weil Leyo maulte über die Notwendigkeit der erweiterten Beo: Auf mw:API:Watchlist gibt es wlallrev – ein für URL oder GET taugliches extend=, extended=, allrev= oder sowas konnte ich bislang nicht finden, mit dem man unabhängig von den preferences für einen individuellen Seitenaufbau die Beo erweitern könnte?
Da lässt sich was machen. Ich habe mal gerrit:48660 commited. Mal schauen. Der Umherirrende 20:43, 12. Feb. 2013 (CET)
Wow!
Da warte ich doch gerne noch etwas mit dem Release meines Tools, und baue dann ein weiteres Optionsfeld ein.
Schönen Abend für den Anfang; aber bei mir quillt gerade etwas aus der Pipeline, und ich melde mich wohl noch einmal auf einem neuen Thread … --PerfektesChaos21:09, 12. Feb. 2013 (CET)
Meine Änderung wurde heute gemerged und hat es noch ins nächste Softwareupdate (1.21wmf10) am 27. Februar geschafft. Viel Spaß damit. Der Umherirrende 21:12, 18. Feb. 2013 (CET)
Ja, ich stelle mich gemütlich darauf ein und habe es schon weitgehend so eingearbeitet; werde also auf die 1.21wmf10 warten und dann das update verbreiten. Danke für die Verbesserung des Bestehenden --PerfektesChaos21:56, 18. Feb. 2013 (CET)
Solange man einen Standardwert angibt, kann man solche Ergänzungen machen. Dadurch werden die alten Verwendungen nicht "kaputt" gemacht. Kann ich mir die Tage oder am Wochenende für die genannten Vorlagen mal anschauen. Pauschal für alle Turniervorlagen wäre es aber viel Arbeit, wo ich nicht umbedingt (jetzt) Lust dran habe. Der Umherirrende 21:52, 18. Feb. 2013 (CET)
Hallo Umherirrender, vielleicht hast Du die Diskussionen über die Löschpolitik auf Commons nicht mitbekommen, aber vor diesem Hintergrund ist es nicht sinnvoll, Dateien die in der deutschsprachigen Wikipedia und Commons vorliegen, mit dem Löschenbaustein zu versehen. Vielleicht überlegst Du Dir diese Bausteineinbinderei nochmals. --Markus S. (Diskussion) 15:36, 16. Feb. 2013 (CET)
Im Umfeld von Vorlage:NowCommons oder dem Wikipedia:WikiProjekt Commons-Transfer habe ich nichts mitbekommen, das der Transfer oder das löschen von lokalen Dateien eingestellt ist. Das Commons in der hinsicht schwierig ist, ist richtig, aber hier sollte ja der prüfende Admin das einschätzen und zur Not den Baustein entfernen, falls die Chancen auf Commons schlecht sind und dann bleibt die Datei hier erhalten und wird auf Commons gelöscht. Eine Prüfung kann aber nur erfolgen, wenn die Dateien auch in einer Kategorie gesammelt stehen. Der Umherirrende 15:41, 16. Feb. 2013 (CET)
Ich bin über den gesamten Dateibestand gegangen, daher sieht es so aus, als ob ich die ganze Kategorie erwischt hätte. Ich werde mir aber in der Zukunft etwas überlegen, wie ich die Dateien auflisten kann, die zwar {{NoCommons}} haben, aber trotzdem auf Commons gelandet sind. Der Umherirrende 15:51, 16. Feb. 2013 (CET)
Das ist doch was :) Ich bekomme diese Diskussionen auch nur am Rande mit, aber was da abläuft ist schon nicht mehr erträglich. Und wenn meine Anmerkung auf Deiner Disk-Seite eine etwas sensiblere Handhabung herbeiführt ist doch schon was gewonnen. Ich wünsche noch ein schönes Wochenende. --Markus S. (Diskussion) 15:54, 16. Feb. 2013 (CET)
Leyo hat die Datei bereits wiederhergestellt. Warum sie aber trotz Mängel-Baustein lokal gelöscht wurde, kann ich nicht sagen. Der Umherirrende 17:46, 18. Feb. 2013 (CET)
Sei mutig! Du scheinst die Situation, speziell dieser Dateien, auf Commons besser einschätzen zu können als ich. Der Umherirrende 19:17, 19. Feb. 2013 (CET)
Es ist vom gleichen Rang wie dumps|download| und müsste also in diesem RegExp aufgeführt werden können, wohl in der inneren Systematik zwischen planet (Ende der http-Serie) und mail (Anfang der https-Serie).
Einstweilen helfe ich mir mit URL + relative=no unter WP:TEC #Siehe auch.
Das ist immer das Dilemma, soll man eine Whitelist oder eine Blacklist nehmen. Ich habe es mal ergänzt. Gibt auch Bug 44760 dazu. Danke für den Hinweis. Der Umherirrende 19:14, 19. Feb. 2013 (CET)
Bergis Ansatz mit der Ausnahmeliste war schon völlig okay, angesichts der Flut von neuen sub-domains.
Der Regelfall ist, dass beide Protokolle unterstützt werden; mit einer Positivliste hätten wir viel zu tun.
Einige wenige haben nur http.
dumps|download ist okay, weil das nur Performance kostet und nichts am Wiki verändert wird; download ist nicht sicherheitsproblematisch und eh offen.
Über wikitech las ich irgendwo, dass das extern bei einem separaten Provider gehostet würde, so dass selbst beim Total-Crash der WMF-Server man noch sein Bedauern annoncieren könne, und sei es über die privaten iPhones der Mitarbeiter. Deswegen wohl nicht direkt konfigurierbar.
Einige wenige haben nur https und sollten durch das Skript nicht auf http runtergesetzt werden, um danach sowieso wieder auf https raufgesetzt zu werden.
Das sind OTRS und die, die was mit Quellcode-Uploads zu tun haben, und die donate-Kreditkartennummer, und das alte secure.
So wie das ausschaut, habe ich jetzt erstmal 31 Tage Bedenkzeit mit der URL.
Ja, wikitech liegt extern und wird deshalb auch mit einer älteren Version betrieben (keine automatischen updates). bugzilla, otrs und so weiter haben nur https, andere wiederrum nur http, das ist manchmal verwirrend, aber die Liste kann man hier lokal gut anpassen. Von Bergi habe ich nichts gehört. Der Umherirrende 20:56, 19. Feb. 2013 (CET)
Ich auch nicht. Man sollte mal die Ersteller der beiden Gadgets fragen, ob das noch wie gewünscht funktioniert. Es hatte aber mal jemand unter Wikipedia:Technik/Skin/Werkstatt/editsection angefangen, das aufzulösen, was aber noch nicht geglückt ist. Der Umherirrende 18:50, 20. Feb. 2013 (CET)
Ach das Dings war das. Ich hatte nicht drauf geachtet.
Dann schließe ich hier und tauche mit einer Kopie in den nächsten Tagen an dem Werkstatt-Abschnitt wieder auf.
Mein Eindruck ist, dass es vor Jahren mal ein anderes CSS gab; dewiki oder weltweit. Das hatte man irgendwie zu erben versucht. Wenn es in allen (mindestens gängigen) Skins heutzutage von selbst geht, dann kann right raus und das left kann ggf. als Gadget einen sinnvolleren Namen bekommen; als Option muss dieser Bezeichner aber ohnehin erhalten bleiben.
Vielleicht lesen Fomafix oder andere alte Kämpen mit und können sich noch erinnern.
Ja, hier müsste mal zuerst der Code aufgeräumt werden. Was damals mal schnell als Gadget angelegt wurde, hat mir noch nie gefallen. Meiner Meinung sollte der ganze bisherige Code entfernt werden, damit die Standardeinstellungen von MediaWiki aktiv werden. Anschließend kann mit einem skinübergreifenden Gadget die Verschiebung von ganz rechts auf hinter die Überschrift realisiert werden. Dieses Gadget kann dann standardmäßig aktiviert werden, um den bisherigen Zustand zu erhalten. --Fomafix (Diskussion) 08:40, 21. Feb. 2013 (CET)
Ja, dem ist so. Es handelt sich dabei um Dateien, die nur eine Version haben, hier kann man sehr gut davon ausgehen, das kein Vandalismus vorliegt. Der Umherirrende 20:02, 22. Feb. 2013 (CET)
Ich finde diese Aktion grundsätzlich sinnvoll, da Vandalismus bei ungesichteten Dateien sonst übersehen werden kann. Allerdings fände ich es sinnvoll, Dateien von sehr unerfahrenen Benutzern auszulassen, da dort oft unsinnige Lizenzen usw. stehen. --Leyo20:19, 22. Feb. 2013 (CET)
Wie würdest du sehr unerfahren definieren? Weniger als 100, 200 Gesamtbearbeitungen? Es stehen noch ca. 4000 Dateien von ca. 2100 Benutzer aus. Gesamt werden es dann wohl 12.500 Dateien gewesen sein. Der Umherirrende 20:50, 22. Feb. 2013 (CET)
Welche Art von "Dateien" behandelst Du? Eine Prüfung der Lizenz und Relevanz (und auch in dem Zusammenhang auf Vandalismus) halte ich trotzdem für notwendig, das Sichten ist auch da sinnvoll. Alternativ könntest Du vorschlagen, dass solche Beiträge nicht gesichtet werden müssen, dann könnte man das an der Stelle diskutieren... --Quasiteilchen (Diskussion) 22:16, 22. Feb. 2013 (CET)
Wie oben geschrieben und im Sichtungskommentar vermerkt, sichte ich Dateien, die nach dem Hochladen keinerlei weitere Bearbeitungen erfahren haben, also keine Änderung der Dateibeschreibungsseite oder ein erneutes Hochladen unter gleichem Namen, so dass sich die Lizenz nicht geändert haben kann. Relevanzkritieren für Dateien gibt es nicht. Der Umherirrende 00:07, 23. Feb. 2013 (CET)
Diese Dateien können von der Lizenz her allerdings doch trotzdem ganz offensichtlich falsch eingestuft sein, Logo o.ä.? Direkte Relevanzkriterien gibt es zwar glaube ich nicht nicht, allerdings wird umgekehrt in den Löschregeln für einen regulären Löschantrag beispielsweise "Fakeverdacht oder nicht eindeutige[...] Fälle[...] mit qualitativen oder sachlichen Mängeln" genannt ( http://de.wikipedia.org/wiki/Wikipedia:Löschregeln ) oder für Schnelllöschanträge: "Eine Datei, von der anzunehmen ist, dass sie keinem enzyklopädischen Zweck dienen könnte und nicht verwendet wird. (Beispiele sind: Logos von offensichtlich irrelevanten Bands oder Unternehmen und Grafiken in offensichtlich zu schlechter Qualität, bei denen die Nutzung ausgeschlossen ist)." ( http://de.wikipedia.org/wiki/Wikipedia:Schnelllöschantrag#Dateien ). Man muss ja nicht jedes Privatfoto von Hans Wurst hier annehmen. --Quasiteilchen (Diskussion) 09:25, 23. Feb. 2013 (CET)
Ja, das kann sein, dafür scheint das Konzept der gesichteten Versionen aber nicht entsprechend genutzt zu werden und auch nicht für ausgelegt zu sein. Es soll Vandalismus in Form von Umlizenzierungen oder Beschreibungsänderungen finden, keine Überprüfung des Bestands hinsichtlich der Qualitätsansprüche/Form von Beschreibungsseiten ermöglichen. Der Umherirrende 10:17, 23. Feb. 2013 (CET)
Ich habe euch eine Liste der Dateien erstellt, die von Benutzern mit weniger als 100 Gesamtbearbeitungen hochgeladen wurden und aktuell ungesichtet sind. Es sind 1281 Dateien von 1024 Benutzern. Der Umherirrende 12:54, 23. Feb. 2013 (CET)
Leider ist es so, dass der Zeitpunkt des Hochlades und das erzeugen der Dateibeschreibungsseite um 1 Sekunde abweichen kann (Bug 34427), ich habe mal meine Prüfung um diese Toleranz ergänzt. 2208 Dateien in einer neuen Liste. Vielleicht ist 50 Gesamtbearbeitungen doch sinnvoller, bei der Anzahl. Der Umherirrende 15:04, 23. Feb. 2013 (CET)
(BK) Diese Datei(beschreibungsseit)en wurden alle nach dem Upload nicht mehr angefasst, oder? Wäre es viel Aufwand die Liste zu unterteilen nach: in DÜP-Kategorie oder nicht; verwaist oder nicht?
Man könnte auch über automatische Sichtungskriterien für Dateibeschreibungsseiten mit mehreren Versionen nachdenken. Wie wäre es beispielsweise mit hochgeladen von Benutzer mit ≥ 100 Edits, weitere Edits nur von Bots oder Admins? --Leyo15:07, 23. Feb. 2013 (CET)
Ja, die Dateien wurde nach dem Upload nicht mehr angefasst. Ich könnte in der Liste die Dateien mit DÜP noch extra kennzeichen. Verwaist ist schon etwas schwieriger, weil man das immer nur für eine Datei abfragen kann, mal schauen, ob das auch geht. In einer zweiten Stufe kann man auch über andere Kriterien nachdenken, wie beispielsweise die Bearbeitung von Bots oder Admins oder anderen Benutzer im Bereich DÜP … Der Umherirrende 17:38, 23. Feb. 2013 (CET)
Die Dateien können ja kein DÜP haben, weil sie keine weitere Bearbeitung haben dürfen. Ich habe es aber schonmal für andere Prüfungen vorgesehen, falls es dann gebraucht wird. Verwaist kann ich nicht prüfen, es dauert einfach zu lange, für jede Datei die Nutzung abzufragen. Der Umherirrende 19:35, 23. Feb. 2013 (CET)
Koenntest Du das OSM icon in ein span mit einer wohldefinierten Klasse (z.B. osm-icon-coordinates) einfassen? z.Zt. kickt das WMA scriot "dekorative" Bildchen in der Koordinatenzeile raus, das fuktionelle OSM icon mus natuerlich drin bleiben. Dazu muss ich ds script anpassen. Am besten geht das, wenn das icon im DOM tree entsprechend gelabeld wird, z.B. mt einer Klasse. --Dschwen (Diskussion) 17:17, 27. Feb. 2013 (CET)
Hm, danke schon mal, aber ich fände es besser, wenn wir den WikiMiniAtlas auch noch hinter den Geohack schieben und durch eine Pipe trennen (wie oben vorgeschlagen). Dann sind die zwei Angebote schön analog angezeigt. Die Idee hinter der Änderung war ja hauptsächlich, eine leichtere Identifizierung als getrennte Kartendienste zu ermöglichen, was auch beim WikiMiniAtlas (laut Diskussion auf FzW) offenbar noch nicht von allen registriert wurde. Das sollte imho jedenfalls auch deutlich vom Geohack abgetrennt werden, weil es derzeit irgendwie als zum Geohack dazugehörend wahrgenommen wird. --Mai-Sachme (Diskussion) 21:35, 27. Feb. 2013 (CET)
Hallo Umherirrender, leider ist das Thema schon im Archiv verschwunden. Bräuchte da nur 1 Mal ein Beispiel wie es geht, die anderen Anpassungen würde ich dann selber machen. Dank im Voraus und schönes WE. Gruß. --LezFraniak (Diskussion) 18:41, 2. Mär. 2013 (CET)
Hallo LezFraniak, entschuldige, das hatte ich letzte Woche vergessen. Damit ich es nicht nochmal vergesse, habe ich Vorlage:Turnierplan16-ohne und Vorlage:Turnierplan32-ohne direkt angepasst. Ich hoffe, das habe ich richtig verstanden. Falls du noch weitere Vorlagen brauchst, kann ich mir das auch noch anschauen. Der Umherirrende 19:35, 2. Mär. 2013 (CET)
Hallo Umherirrender, macht nix. Danke. War ja recht unaufwendig. Hatte mir das schon so gedacht, wollte nur nix vermurksen. Habe diese Vorlage noch angepasst. Gibt es eine Regel was auf den Vorlageseiten erscheinen muss (Wartungsseiten/Doku etc.)? Gruß. --LezFraniak (Diskussion) 21:43, 2. Mär. 2013 (CET)
Die Dokumentation der Turnierplan-Vorlagen sind alle dürftig, so dass man da vermutlich nicht viel machen brauch oder die ganze Dokumentation erstellen müsste. Falls es aber schon Parametererklärung gibt, ist das Erwähnen dieser optionalen Parameter aber sicher sinnvoll. Der Umherirrende 21:45, 2. Mär. 2013 (CET)
Da will keiner ran. Ich habe immer nur einen Stand kopiert, der in der Skin-Werkstatt erarbeitet wurde. Aber wenn du dir da die letzten Abschnitt dazu suchst, wirst du auch keine freudigen Kommentare finden. Seit wann tut es denn nicht mehr, passt das mit dem Software-Update vom 27.02.? Welches Gadget ist das auf Commons, kannst du die js-Seite verlinken oder mir die Beschreibung aus den Einstellungen nennen? Dann kann ich mal drüberschauen, was die letzten Änderungen so waren Der Umherirrende 19:27, 4. Mär. 2013 (CET)
Hast du deinen Skin gewechselt? Deine vector.js und monobook.js sind beide ungültig. Kommentare werden in JavaScript mit /* */ gemacht. Du müsstes ein Fehler in deiner Konsole haben mit dem Text
JavaScript parse error: Parse error: Missing operand in file 'Benutzer:Krd/monobook.js' on line 1
Habe nochmals nachgeschaut, wird wohl eher gerrit:47519 gewesen sein, wo $wgResourceLoaderValidateJS wieder auf true gesetzt wurde, was den HTML-Kommentar dann als ungültig erkennt. Dein Browser ist da vielleicht nicht so strict und verkraftet das. Der Umherirrende 17:13, 6. Mär. 2013 (CET)
Bislang war sie nicht in Strukturen eingebunden und verwaist.
Diese Seite war im März 2012 der Prototyp für die im Juli 2012 begründete Baustellen-Übersicht. Als der Vater geboren wurde, hatte ich sein schon vier Monate altes Kind längst wieder vergessen.
Ich würde gern Admin auf de.wikipedia.beta.wmflabs.org werden, kann aber die Kandidatenseite nicht finden. Außerdem hätte ich gern das Recht zum XML-Import.
Habe dich mal zum Admin gemacht, in der Annahme, du hast ein gleichnamiges Konto dort. Den XML-Import als Upload kann ich auch nicht aktivieren, das ist Steward Aufgabe. Das Wiki ist aber irgendwie nie zum testen gekommen, so dass dort nicht viel Aktivität ist. Der Cache war am Anfang auch nervig, weil er sich nicht upgedatet hat, keine Ahnung, ob das schon besser ist. Zum JavaScript-Entwicklen würde ich das nicht nehmen. Ist ja auch nur für kurze Tests von Neuerungen gedacht gewesen. test.wikipedia.org und test2.wikipedia.org sind da aber besser konfiguriert und werden vermutlich auch häufiger geupdated. Auf dem wmflabs.org steht noch etwas von 1.21alpha als Version, keine Ahnung, wann da das letzte Update war. Ein lokales Wiki ist da vermutlich einfacher zum testen. Die Vorlage sieht okay aus. Der Umherirrende 15:25, 8. Mär. 2013 (CET)
Beta: Danke, und du hast den Richtigen zum Admin gemacht.
Ich denke, das wird im Lauf des Jahres aktueller werden. Im Moment wird dieser ganze Labskaus ja erst zusammengeköchelt. Auf dem testwiki bin ich schon ich, aber dort würde ich mich langfristig löschen und alle neuen und zukunftsweisenden Aktivitäten auf wmflabs bündeln.
Einen Steward, der was mit Importen zu tun hat, werde ich gelegentlich anhauen; dann kann ich diese dussligen Import-Formulare, für die ich entwickle, auch mal selbst sehen und live testen.
Hinsichtlich der Beo-Parameter ist heute urplötzlich ein „Wikidata ausblenden“ vom Himmel gefallen; macht aber momentan nur javascript:void(0); (auf der Beo steht plötzlich „Wikidata ausblenden“, und ich sehe nicht, wo das nun wieder herkommt, MediaWiki:Common.js/watchlist.js ist unverändert).
WP:NEU#6. März. Das dient zum Ausblenden/Einblenden der Änderungen die auf WP:WikiData passieren. Die Änderungen die das jeweilige Wiki betreffen, werden dort hingespiegelt (als RC_EXTERNAL, falls du etwas von MediaWiki-Interna wissen möchtest), damit man diese auf der Beobachtungsliste und den letzten Änderungen mitverfolgen kann. Ob und wie es funktioniert, kann ich nicht sagen, habe wenige entsprechende Seiten auf meiner Liste und Interwikis interessieren mich eher weniger. Der Umherirrende 11:54, 9. Mär. 2013 (CET)
Encoding oder so
Hallo Gross-Meister!
Ich brauche Hilfe und denke Du kannst mich ev. wenigstens an die richtige Person weiterleiten. Habe Probleme mit "ä" und zwar gleich mehrere, die aber nicht zusammenhängen:
#time Parser Funktion kommt mit "ä" (März) nicht klar, siehe Vorlage:Metadaten_Fußballstatistik/Jake_Livermore. Wenn man das "ä" in ein "a" ändere (Mar...) dann gehts. Ist das ein Fehler in der mw Software?
Hast Du eine Idee? Letzteres kann schon bei mir liegen - hab aber den Code seit Äonen nicht geändert... ;)) Danke Dir und Grüsse --DrTrigon11:44, 6. Mär. 2013 (CET)
#time kann keine lokalen Monatsnamen verarbeiten (#timel auch nicht; Bug 19412), sondern nur die englischen, bei Jan. und Feb. ist das identisch, bei Apr, Mai, Jun, Jul, Aug, Sep, Nov müsste es gleich sein, bei Okt und Dez wird es wieder problematisch. Hier wäre ISO-Format wohl besser, also 2013-03-04.
Bei deinem zweitem Punkt kann ich dir nicht ganz folgen, die letzte Bearbeitung des Bots war doch am 2. März? Wo soll da das Problem sein? Der Umherirrende 17:04, 6. Mär. 2013 (CET)
Habe gerade den Abschnitt auf deiner Diskussionsseite gesehen, keine Ahnung, warum das ä nicht funktioniert aber ein Ü, ein explizites UTF-8 hast du doch hoffentlich drin? Bei deiner Zusammenfassungs funktioniert es auch, komisch. Der Umherirrende 17:31, 6. Mär. 2013 (CET)
Ja, der Link auf Benutzer_Diskussion:DrTrigon/SumDisc gestern war echt sinnlos (heute nicht mehr ;) - sorry! Weiss nicht was mich da geritten hat... ;)
Also bei #timel kann man das als bug betrachten, gut! Allerdings wenn ich sehe, dass der bug schon seit 2009 offen ist besteht da wenig Hoffnung! Weiss Du wie ich die mw Software dazu bewegen kann das von Dir vorgeschlagene ISO-Format zu produzieren, vorzugweise für ~~~~~. Gibt es da eine offizielle Lösung? Oder muss ich auf User:Quarl/advanced sig.js zurückgreifen?
... und das mit dem "ä" zu untersuchen wird eine lustige und spannende Reise werden - wenn ich dann mal Zeit dafür habe - das muss systematisch angegangen werden.
Mit den Tilden bekommst du das nicht hin, du kannst aber auch #time substen, also fügt dein Bot anstatt der 5 Tilden den Text {{subst:#time:Y-m-d}} ein, was dann zu "2013-03-07" wird. Das #time in der Metavorlage kannst du ja drin lassen, das würde weiterhin funktionieren, gibt dann 7. März 2013. Der Umherirrende 16:44, 7. Mär. 2013 (CET)
War ja klar... ;) Leider gefällt mir das ehrlich gesagt gar nicht... mal sehen was ich da zusammenbastle, zum Glück hatte ich damals meinem Bot 2 versch. solche META Tags verpasst '...-mw-timestamp' und '...-bot-timestamp') und zweiteres ist sogar ISO... :) (siehe Versionsvergleich) - puuh Glück gehabt! ;)
Was mir aber noch weniger behagt ist die Tatsache, dass die mw Software nicht mal das Format verarbeiten kann, das sie selbst erzeugt! Schon mal was von Konsistenz gehört? V.a. bedeutet das, dass man hier jedes mal eine parser function aufrufen, was das ganze auch noch ineffizient macht... gefällt mir wirklich gar nicht - bin aber wohl der einzige, wer verwendet schon 5 Tilden? Wird sicher bald ganz deaktiviert... ;))
Ok konnten beide Probleme soweit lösen und hab meine Meinung geäussert in dem bug report. ;)) Ich denke wir können das hier abschliessen - vielen Dank für Deine Hilfe und Grüsse --DrTrigon12:11, 9. Mär. 2013 (CET)
Keine Ursache. Ja, ich habe es verfolgt auf deiner Diskussionsseite ;-) Ich finde es nur komisch, das verschiedene Server verschiende locale-Ausstattung haben, aber okay, da gibt es ja verschiedene Einflüsse, die Ursache sein können. Der Umherirrende 12:16, 9. Mär. 2013 (CET)
Ich glaube/vermute das ist historisch bedingt - willow ist schon seit Ewigkeiten so konfiguriert und hatte schon immer 'de_DE' drauf (weiss nicht wie "alt" er ist und ob es da schon UTF-8 gab... ;)). Als vor ca. 1 Jahr die neuen Server aufgesetzt und konfiguriert wurden hab ich nach 'de_DE' gafragt aber die Antwort war so in der Art; von nun an gibts nur noch 'de_DE.utf8' also überall nur noch die UTF Varianten. D.h. was den TS betrifft war es eine absichtliche Entscheidung. Zwingt mich immerhin mal meinen Code zu bereinigen. Ok hätte auch anderes zu tun - aber es sorgt eigentlich schon für sauberen Code. Hat Vor- und Nachteile... :))) Gruass --DrTrigon10:58, 10. Mär. 2013 (CET)
Hilfe zu Vorlage benötigt
Hallo Umherirrender, benötige mal wieder deine Hilfe. Habe diese Vorlage erstellt. Leider kann ich die Bildgröße nicht steuern und der Name erscheint nicht unter dem Bild. Was habe ich falsch gemacht? Soll natürlich nicht sooo groß werden, sondern eher so wie ganz oben zu sehen. Weißt du Rat? Dank im Voraus. Gruß. --LezFraniak (Diskussion) 17:53, 12. Mär. 2013 (CET)
Das war schon richtig, nur wurde der Cache der eigenen Seite nicht geleert. Habe WP:Purge gemacht und die Dateien sind jetzt klein, so sollte es vermutlich aussehen. Der Umherirrende 20:32, 12. Mär. 2013 (CET)
Die verwendeten Dateien haben eine unterschiedliche Grundgröße und sind dadurch natürlich bei 80px Breite auch unterschiedlich hoch, da gibt es aber keine Lösung. Du könntest höchstens die Höhe mit angeben (Hilfe:Bilder#Feste Skalierung), dann werden die Dateien aber vielleicht auch etwas schmaler als 80px. Das Seitenverhältnis muss ja gewart bleiben, sonst sehen die Dateien verzerrt aus. Der Umherirrende 21:11, 13. Mär. 2013 (CET)
Die Frage war eher nach dem Unterbau, also 2, 1, 3. Die Stufen 2 und 1 sind zu hoch. Hast du dazu Rat? Aber Danke für den Tipp mit den festen Bildgrößen. Wollte sich auch noch ein bisschen abheben von den Stufen damit sie nicht so aneinander kleben und einen Rahmen drumziehen. Versuch mich aber erst morgen dran. Guats Nächtle. --LezFraniak (Diskussion) 00:02, 14. Mär. 2013 (CET)
Deine Zahlen haben keine eigene Höhe. Die Höhe des Kästchens mit der 1 hängt von der Höhe des Bild3 ab, daher sieht es so verzerrt aus. Die Höhe von 2 und 3 hängen vom Zahlenbild ab. Der Umherirrende 15:36, 15. Mär. 2013 (CET)
Habe ich mir schon gedacht. Ergebnis sieht unbefridigend aus. Habe SLA gestellt. Danke. erledigtErledigt
Dieser Abschnitt kann archiviert werden. --LezFraniak (Diskussion) 16:36, 15. Mär. 2013 (CET)
:Datei:GM Eugen Bregant 2.JPG
Hallo Umherirrender, User:Bregant1 hat mich bei dem Bild:GMEugen1.jpg um Hilfe ersucht, allerdings werde ich aus der Meldung selbst auch nicht schlau. Kannst du da bitte direkt auf Bregant1 zukommen. Danke im Voraus --K@rl17:33, 15. Mär. 2013 (CET)
Habe mal auf deiner Diskussionsseite geantwortet, dann stehen Frage und Antwort zusammen. Der Umherirrende 18:40, 15. Mär. 2013 (CET)
(Die Modul:Hello/doc, die du gerade gelöscht hast, enthielt die englischsprachige Doku. Nur hatte das jemand nicht geschnallt und eine deutschsprachige Doku drübergeschrieben.)
Die Sache mit der Doku wird sich wohl noch entwickeln, auch auf anderen Wikis. Aber wo denkst du, das man mehr als eine Dokuseite braucht? Das einzige Problem ist, unsere /Test oder /Wartung-Seiten. Letzteres wird man wohl nicht brauchen, Tests aber wohl.
Wenn wir mit Versionsgeschichte fremde Module importieren, ist da eine englisch- oder portugiesischsprachige Doku mit dabei. Die können wir aber nicht nachvollziehbar verwalten. Gleichwohl wollen wir sie haben, und eine nach und nach ins Deutsche übersetzte Doku aber auch.
Wenn wir selbst etwas weltweit anbieten, dann machen wir das sowohl deutsch- wie auch englischsprachig dokumentiert.
Nicht alles, was es zu einem Modul aufzuheben gibt, sollte man notgedrungen auf den Disku-Seiten parken müssen, weil es nicht anders geht.
Die Prefix-Übersicht liefert dann ausschließlich Module und sonst nix.
Die thematische Übersicht passt sowieso gut auf WP:Lua/Modul.
Andere Wikis sind auch bereits von der 828 heruntergegangen, vermutlich aus analogen Gründen.
Je früher wir umziehen und das von vornherein zukunftsfähig einrichten, desto weniger Gewirr gibt es hinterher beim Kopieren und Linkfixen, und desto weniger müssen Leute umdenken (das gibt immer so Kopfaua), wenn sich anschließend etwas verändert.
Textspenden: Dieses Wochenende ist schon rappelvoll mit WP und RL und Wetter, aber Montag/Dienstag sieht gut aus.
Hei Umherirrender, da sind noch Typos drin: Das müsste eigentlich heißen:
„stelle sicher, dass keine internen Links mehr auf den bisherigen Titel zeigen, und füge am Anfang der Seite mit dem bisherigen Titel Folgendes ein:“
Also ein ‚n‘ mehr und ein großes ‚F‘. Thanks. Und haste hierzu noch ne andere Idee, ohne die Listenartikel anrühren zu müssen? LG, --Geitost17:47, 15. Mär. 2013 (CET)
Bin nicht ganz auf dem Laufenden, aber der Text der MW-Seite suggeriert für mich jetzt, dass man zuerst die Links umbiegen soll, bevor man den SLA stellt, und auch nach (tw. prompt erfolgender) Löschung der Weiterleitung erst den Eintrag bei Wikidata aktualisieren kann. Ist das richtig, dass es egal ist, ob die WL bereits gelöscht wurde, wenn man den Wikidata-Eintrag aktualisiert? Ich ging bisher davon aus, dass man zuerst den Eintrag aktualisieren müsste, dann evtl. noch gewartet werden müsste, bevor irgendwelche Bots oder die Server die Daten erneuern, und erst später gelöscht werden dürfte, damit es nicht zu Problemen kommt wie bereits gesehen. Was stimmt denn nun dabei? Ich fürchte, das Prozedere mit dem Verschieben von Seiten mit Interwikis wird auch nicht auf der Seite Hilfe:Internationalisierung beschrieben, auf die dabei zur Erläuterung verlinkt wird; der Link hilft mir dabei jedenfalls gar nicht weiter. :-/ Oder hab ich was übersehen? --Geitost17:59, 15. Mär. 2013 (CET)
Habe die Tippfehler ausgebaut. In welcher Reihenfolge man das ganze macht, ist, so weit ich weiß, egal. WikiData dürfte es beim ändern egal sein, ob das alte eine Weiterleitung ist oder nicht mehr existiert. Der Umherirrende 18:44, 15. Mär. 2013 (CET)
Dank dir. Ja, wenn's egal sein mag, dann kann man es ja so probieren.
Die Seite MediaWiki:Movepage-moved/de-formal bräuchte dann auch noch ne Aktualisierung; de-at und de-ch binden es direkt ein. Und müsste es nicht noch eine andere MW-Seite zu Verschiebungen geben (die ich nicht finde)? Wenn es ne zugehörige, mitverschobene Disk. gibt, wird dazu auch noch was mit Link darunter in den Hinweis geschrieben. Das fehlt aber bei dieser Seite ganz. Weißt du mehr? --Geitost21:26, 15. Mär. 2013 (CET)
Die sind's jedenfalls alle nicht. Seltsam. Also mal eine Seite mit Disk. verschieben und drauf achten, ob nun der alte oder neue Text angezeigt wird. ;-) Vielleicht wird's ja irgendwie anders hinzugefügt zum Standardtext. Werd mal drauf achten. --Geitost22:35, 15. Mär. 2013 (CET)
Ok, ich hab inzwischen eine Seite mit Disk. im BNR verschoben, allerdings hatte die keine Interwikis, deshalb brauchte es den Wikidata-Text nicht. Muss mich etwas korrigieren, 2 der obigen Nachrichten kommen doch vor, und zwar unten ergänzend: Der Text oben war derselbe wie bei anderen Verschiebungen, also MediaWiki:Movepage-moved (mitsamt den Aktualisierungen und Typokorrekturen), danach fehlte der Wikidata-Text (was hier richtig war), stattdessen gab es aber einen zusätzlichen leeren Absatz, also eine große Lücke. Weiß nicht, was man da machen kann oder ob überhaupt. Liegt aber hier daran, dass der Wikidatahinweis im BNR gar nicht angezeigt wird, wie ich grad sehe. Und am Schluss kam noch dieser Text, entspricht den beiden Meldungen MediaWiki:Movepage-moved-redirect plus MediaWiki:Movepage-page-moved. Also wird der Text nur hinzugefügt, ist nix weiter zu ändern außer evtl. der Riesenlücke bei BNR-Verschiebungen mit Disks. Vielleicht könnte man die Zeilenumbrüche noch mit bei der Standardeinstellung hinzufügen, damit sie wegfallen, wenn es keinen Text dort gibt?
Bei welchen Namensräumen gibt es denn eigentlich den Wikidatahinweis und bei welchen nicht? Und wäre es nicht sinnvoll, auch für die Diskussionsseite Links auf die Seite anzuzeigen, damit man die Disk. löschen lassen kann. Das ist immer etwas umständlich, weil man erst auf die WL klicken muss und erst darüber auf Links auf die Seite.
Und kannst du bitte auch noch in der angegebenen, zu kopierenden Signatur, also bei
"{{Löschen|Kurze Begründung -- ~~~~}}"
das Leerzeichen zwischen "--" und den 4 Tilden rausnehmen, damit man dieselbe Sigformatierung hat wie in der Zeichenleiste (und man nicht jedes Mal beim Kopieren wieder das Leerzeichen extra löschen muss)? Das wurde ja bereits mal an anderer Stelle diskutiert. Außerdem wird oft die Löschbegründung mit ins Löschlog übernommen, wo die Zeichenanzahl begrenzt ist, da ist es sowieso besser, wenn es ein Zeichen weniger ist. --Geitost16:26, 17. Mär. 2013 (CET)
Signatur gekürzt; Leerraum vermutlich verhindert; Über den Link denke ich noch nach. Beim Löschen bekommt auf jedem Fall der Admin einen Hinweis, das dort noch eine Diskussionsseite wäre. Der WikiData-Hinweis ist nur bei Artikeln oder so hilfreich, weil das in WikiData steht. Ich weiß nicht, ob man Benutzerseiten dort auch hinterlegen kann. Ob der Hinweis in allen Fällen schon unterdrückt wird, wo er nicht sinnvoll ist, kann ich nicht sagen, vermutlich aber nicht. Der Umherirrende 17:14, 17. Mär. 2013 (CET)
Das hatte ich nur kopiert ;-) Habe aber die Kopiergrundlage und ein paar andere Nachrichten noch angepasst. Danke für den Hinweis. Der Umherirrende 17:14, 17. Mär. 2013 (CET)
Hei Umherirrender, kannst du mal hier vorbeischauen, ob wir es nun richtig hinbekommen haben mit dem Intro? Irgendwas war da seltsam, dass bei den Fallbacksprachen gar kein Intro angezeigt wurde, wenn man diese nicht gesondert ins Intro dupliziert. Bei anderen Sprachen wird aber richtig Englisch angezeigt. Woran liegt das und ist es jetzt richtig so? Viele Grüße --Geitost12:35, 28. Mär. 2013 (CET)
Beim switch gibt es auch die Möglichkeit der „Rückfall“-Werte, was hier wohl sinnvoller ist. Oder {{DeDialekt}}, dann werden auch noch weitere Sprachen abgehandelt. Warum das ganze auf einmal nicht mehr funktioniert, kann ich nicht sagen, aber ich denke nicht, das es mit dem gestrigen Software-Update bezüglich Systemnachrichten zusammenhängt. Der Umherirrende 14:47, 28. Mär. 2013 (CET)
Hallo Umherirrender. Seit deiner Löschung wird „Deine Aufmerksamkeit wird daher benötigt!“ angezeigt. Die Fettschrift finde ich störend. Zudem sehe ich keinen Grund für den Unterschied zum Text in MediaWiki:Flaggedrevs-watched-pending. --Leyo12:24, 29. Mär. 2013 (CET)
Das liegt daran, weil das ganze Feature mit gerrit:56538 wieder entfernt wurde. Ich werde die gelöschten Seiten wiederherstellen. Der Umherirrende 16:30, 29. Mär. 2013 (CET)
Erledigt. Alle gelöschten Seiten vom 26. März wiederhergestellt. Falls vorhanden, möchte ich die Unannehmlichkeiten entschuldigen. Der Umherirrende 18:22, 29. Mär. 2013 (CET)
Hallo Umherirrender, Geitost und ich haben versucht, das Intro des Mentorenprogramms entsprechend der Spracheinstellungen zu überarbeiten. Eine Zusammenfassung findest du hier. Wir denken, dass es nun laufen sollte, jedoch magst du evt. mal reinschauen. LG --Itti10:37, 6. Apr. 2013 (CEST)
Hallo Umherirrender, ich habe in der o. g. Vorlage den Abschnitt BEST GAME eingefügt. Jetzt passieren merkwürdige Sachen. Eigentlich ist dort ja eine IF-Funktion eingefügt, die die entsprechenden Abschnitte bei Nichtausfüllung nicht anzeigen soll. Bei BEST GAME passiert nun folgendes. Im Artikel René Vingerhoedt wird es trotzdem angezeigt und macht die Infobox extrem breit. Dagegen wird im Artikel Raymond Ceulemans nichts angezeigt, obwohl dort Einträge vorhanden sind. Hingegen ist bei Torbjörn Blomdahl alles OK. Was ist da los? Cache habe ich gelöscht, bleibt so und in der Syntax ist mir jetzt erstmal kein Fehler aufgefallen. Habe die Ergänzung per Copy/Paste erzeugt. Sollte also richtig sein. Dank im Voraus. Schönes WE. Gruß. --LezFraniak (Diskussion) 17:23, 12. Apr. 2013 (CEST)
Hallo LezFraniak, du hattest es schon richtig kopiert, aber das Feld im #if vergessen anzupassen. Du hast also das falsche Feld abgefragt, da dieses im Beispielartikel gefüllt war, wurde auch deine neu eingebaute Zeile angezeigt. Ich habe das mal korrigiert. Der Umherirrende 21:21, 14. Apr. 2013 (CEST)
Der Flüchtigkeitsteufel hatte da bei mir wieder zugeschlagen. Danke: Schönen Sonntag noch. Gruß.
Dieser Abschnitt kann archiviert werden. LezFraniak (Diskussion) 21:51, 14. Apr. 2013 (CEST)
Seit letzte Woche gab es kein Problem mit unser Slippy Map, aber zeit einige Tagen kann man nür "The requested URL /~kolossos/openlayers/embed.html was not found on this server" sehen.
Vielleicht gibt es ein Problem mit diese Kommit, das heißt "protokol-relative, wenn auch das Tool selber wieder über http lädt" ?
Ich habe keine Ahnung, wohin der genannte Button im Moment bei uns führen wird und was das dort tun wird; bitte möglichst vor der Freischaltung geeignet konfigurieren.
Hallo Umherirrender, könntest Du wohl die Kategorie:Wikipedia:Defekter Dateilink wieder so einrichten das Unterkategorien zu einzelnen Namensräumen gibt? In etwa so wie in dieser Version. Um einen statistischen Überblick über den gesamten Bestand wie in praktisch allen anderen Wikipedien zu haben fände ich es ganz sinnvoll. Gruß --Knochen ﱢﻝﱢ05:17, 21. Apr. 2013 (CEST)
Halte ich nicht viel von. Der Nutzen einer solchen Kategorie ist quasi nicht vorhanden. Eine Statistik zu anderen Sprachversionen scheint mir nicht hilfreich. Es fehlt ja auch nur der Benutzernamensraum und die Diskussionsseiten, dort ist aufräumen eh nicht erwünscht, daher sollte man die Seiten erst garnicht zum möglichen Abarbeiten auflisten. Der Umherirrende 19:34, 23. Apr. 2013 (CEST)
Seh ich zwar anders, der Benutzer:CommonsDelinker entfernt auch überall in allen Namensräumen. Es war auch nicht meine Absicht das ganze gelöschte Zeugs zu entfernen. Die Kategorie war seit Jahren so bis ich 10/2012 überhaupt vorgeschlagen hatte Unterkats zu bilden um nicht immer den CatScan zu bemühen. Es bearbeitet außer mir ohnehin kaum einer die Kat. Ich kanns nicht selber ändern, also werd glücklich damit. --Knochen ﱢﻝﱢ18:05, 24. Apr. 2013 (CEST)
Spezialfrage für den Spezialisten
Hei Umherirrender, tricky Frage: Hast du irgendeine Idee, was man tun muss, damit eine Datei immer in der neuesten Version in Artikeln angezeigt wird und man nicht die Größeneinstellungen verändern muss, damit sie die neueste Version anzeigt? Siehe diese Merkwürdigkeiten. Denn sonst hängt es ja von der gewählten Größeneinstellung ab, ob bei einer Neueinbindung die Datei in der letzten oder einer alten Version angezeigt wird, und wenn jemand zufällig 385px oder "hochkant=2.0" angibt, bekommt er eine alte Version im Artikel. Ziemlich seltsam. LG --Geitost12:37, 24. Apr. 2013 (CEST)
Bei den Dateien kenne ich mich auch nicht wirklich aus. Aber eigentlich sollten nach einem neuen Hochladen die Vorschaubilder sich auch aktualisieren. Letztens gab es da auch Probleme, die sich dann aber (nach langer Zeit) wieder gefangen hatte. Unter WP:FzW#Neue Bildversionen wurde auch schon gefragt, mit Verweis auf Commons. Vermutlich gibt es da (wieder) technische Probleme auf der Serverseite. Vielleicht kann man dort die Datei als Beispiel mit dem fehlerhaften Größen angeben. Der Umherirrende 19:59, 24. Apr. 2013 (CEST)
Das "Advanced manual thumbnail purging" für die Datei mit der Größe 385px hat geklappt. Ist nur die Frage, ob nicht auch andere Dateigrößen dort fehlerhaft sind, aber erstmal sollte es wieder passen. Der Umherirrende 20:03, 24. Apr. 2013 (CEST)
Was immer du da jetzt gepurgt hast – wenn man noch ein Beispiel dafür braucht, kann man dann das mit "hochkant=2.0" nehmen. ;-) --Geitost22:01, 24. Apr. 2013 (CEST)
Einbindung OSM
Hallo, seit heute (?) ist die Reihenfolge der Dschwen'schen und der Kolossos'schen OSM-Angebote vertauscht. Das ist mir ja prinzipiell egal, aber die Darstellung wirkt jetzt etwas unsymmetrisch, weil der Abstand zu den Pipes nicht gleichmäßig zu sein scheint.
Also bei mir ist die Reihenfolge anders herum und daher passen die Abstände. Ich glaube die Reihenfolge liegt daran, wie schnell die jeweiligen JavaScripte ausgeführt werden, vielleicht ist Dschwens jetzt schneller auf deiner Maschine? Hast du die gewechselt oder den Browser? Am Abstand kann ich erstmal nichts ändern, weil es sonst bei den vertauschten auch nicht gut aussieht. Der Umherirrende 19:49, 30. Apr. 2013 (CEST)
Oh, seltsam, sehr seltsam. Ich habe eigentlich gar nix geändert, benutze hier Opera für Windows und habe heute bemerkt, dass plötzlich die Reihenfolge vertauscht ist. Dann habe ich auch mit dem Internet Explorer nachgeschaut und beim ersten Betrachten einer Seite mit Koordinaten war die gewohnte Reihenfolge wieder da. Dann habe ich im Explorer die Seite neu geladen und es war wieder vertauscht mit Leerzeichen, wie oben dargestellt. --Mai-Sachme (Diskussion) 22:56, 30. Apr. 2013 (CEST)
Hallo Unherirrender, die Datei:Ponts de Térénez.jpg darf wegen fehlender Panoramafreiheit nicht nach Commons, deshalb wurde sie von frWP nach deWP übertragen. Da müsste noch das entsprechende Wapperl rein, das ich aber momentan erst suchen muss. --AHert (Diskussion) 17:44, 2. Mai 2013 (CEST)
Hallo AHert, du solltest auf jedem Fall ein {{NoCommons}} auf die Dateibeschreibungsseite setzen. Gerne auch mit Kommentar. Vielleicht ist auch ein {{Panoramafreiheit}} hilfreich, das kann ich nicht beurteilen. Mein Hinweis auf die identische Datei ist ja nicht direkt eine Aufforderung, die Datei nach Commons zu transferieren. Nur wenn sie transferiert wird, sieht man auch, wo die lokale Datei überflüssig wird. Eventuell findet man so sogar das Wiki, wo die Datei zu erst hochgeladen wurde und dort weitere Informationen. Der Umherirrende 22:59, 2. Mai 2013 (CEST)
Wenn du magst wäre es prima, wenn du mal beim Geitost vorbeischaust. Er hat für die OS-Wahl einen interessanten Vorschlag, jedoch fürchte ich, dass ich keine Lösung finden werde. Magst du mal grübeln? Vielen Dank, liebe Grüße --Itti22:13, 3. Mai 2013 (CEST)
Ich habe mal geantwortet. Ich hoffe, ich habe das richtige herrausgesucht. Ansonsten muss du mir noch ein kurzes Stickwort geben, was du eigentlich meintest (Um die Sortierung wurde sich ja schon gekümmert, meinte ich gelesen zu haben). Der Umherirrende 22:47, 3. Mai 2013 (CEST)
Allerdings weiß ich noch nicht, ob das jetzt ein Bug oder ein Feature sein soll, dass so was gar nicht geht. Ist doch blöd, sollte man mal bei Bugzilla zur Änderung anmelden, weil man doch nun Workarounds dafür machen muss. --Geitost19:43, 4. Mai 2013 (CEST)
Ich denke mal, der Usecase ist begrenzt, das man die eigene Seite auf den Änderungen an verlinkten Seiten haben möchte. Da wird es wohl auch wenige Fälle geben, wo man das wirklich braucht. Der Umherirrende 20:08, 4. Mai 2013 (CEST)
Das kann gut sein, ist mir bisher auch noch nicht untergekommen. ;-) Dann sollen sie halt lieber endlich mal die wichtigen alten Bugs bearbeiten, wäre besser, hehe. :-) --Geitost21:17, 4. Mai 2013 (CEST)
Kannst du noch hier das „alles“ in der Klammer kleinschreiben? Ansonsten klingt wohl „bei wichtigen Themen“ etwas besser als „für wichtige Themen“, denk ich. Ach, zwischen MediaWiki:Anonnotice und die fehlt auch noch ein weiteres Komma (fast übersehen) – wär aber stattdessen auch optisch möglich, „wenn gefüllt (alles außer -)“ in Gedankenstriche einzufassen statt Kommata, vielleicht sähe das dann besser aus? Ausprobieren.
Und warum bekommt man die Notiz eigentlich beim Anblick des Quelltextes gar nicht angezeigt? Dafür ist die doch da, nicht? Oder funzt die Notiz nur, wenn man auch die Rechte zur Seitenbearbeitung hat? Und dank dir fürs Kümmern. :-) LG --Geitost21:48, 4. Mai 2013 (CEST)
Da ich sie angezeigt bekomme, scheint es wirklich an der Bearbeitbarkeit der Seite zu liegen. Wenn du die Seite nicht bearbeiten kannst, brauchst du ja auch keine *edit*notice ;-). Ansonsten habe ich deine restlichen Anmerkungen mal umgesetzt. Danke fürs gegenlesen. Der Umherirrende 21:57, 4. Mai 2013 (CEST)
Immer gerne doch. So wie jetzt sieht’s auch gut aus, gute gestraffte Lösung statt der Gedankenstriche. :-)
Hei Umherirrender, kannste mal beim Hexer vorbeischauen? ;-) Unter BD:DerHexer#File:SUL finalization de.svg gibt’s irgendwelche seltsamen Anzeigen der SVG-Datei, aus denen ich nicht schlau werde und die völlig verwirren. Wenn du die Bug-Nr. noch parat hast, kannste die auch noch mal verlinken. Aber zumindest die Originaluploads müssten doch richtig angezeigt werden, aber auch da passt schon was nicht. Bin mir ganz sicher, dass bei der 2. neuen Datei Datei:SUL finalization de 2.0.svg eben, als es noch 2 Versionen gab, die 1. (Archiv-)Version mit der 2. Version [1] übereinstimmte, was zu dem Zeitpunkt die neueste Version war. Jetzt, wo unter dem Link die 3. Version und weiterhin die neueste Version (wohl immer die neueste) liegt, ist die 1. Version plötzlich identisch mit der 3. (neuesten), aber die 2. wird unterschiedlich angezeigt, das wäre aber eigentlich die richtige Version. Es ist verhext, na ja, die Datei ist ja auch vom Hexer, aber hat der die jetzt auch verhext? ;-) LG --Geitost19:37, 4. Mai 2013 (CEST)
Hallo Geitost, eine Bugnummer mit den Bildern habe ich jetzt nicht. Da hieß es aber, das nur Vorschaubilder der aktuellsten Version betroffen waren und nicht auch Vorschaubilder von alten Versionen. Relevant wird das auch nicht sein. Große Unterschiede erkenne ich in den Vorschaubilder unter "Dateiversionen" auch nicht. Die per Link erreichbare Version sollte aber immer die auch wirklich gemeinte sein, sonst gäbe es wirklich einen großen Fehler. Da ich keine Möglichkeit habe, mir SVGs direkt anzeigen zu lassen, sondern nur per PNG-Generierung von MediaWiki, kann ich da auch nicht wirklich helfen, aber wie gesagt, das sollte unkritisch sein. Ich habe aber mal den Wunsch auf Bugzilla gelesen, das man einen Versionsunterschied für SVGs haben möchte, da es ja eigentlich nur xml-Dateien sind. Der Umherirrende 20:07, 4. Mai 2013 (CEST)
Ach, so ist das. Ich kenn mich mit SVGs so gar nicht aus, keine Ahnung. ;-) Das wäre aber sicher interessant, wenn das tatsächlich ginge mit dem Versionsunterschied. Aber wenn nur die Vorschaubilder der aktuellen Version betroffen sind, dann passt das zumindest dazu, da ja anscheinend nur die aktuelle Version per Direktlink nicht richtig angezeigt wird, da sie sich erst dann ändert, wenn sie zu einer älteren Version wird. So sah es zumindest für mich aus. Mmh, klingt jedenfalls nicht gut, das Ganze. --Geitost21:22, 4. Mai 2013 (CEST)
Klicks auf Beobachten ohne Skript nicht möglich
Jetzt hab ich doch noch mal ne andere Frage. Ist es eigentlich so gedacht und richtig, dass man nur mit eingeschaltetem (und funktionierendem) JavaScript Seiten auf die Beo setzen und davon entfernen kann, die man nicht gerade bearbeitet (der Klick auf den Knopf „Diese Seite beobachten“ im Editmodus funzt auch ohne Geskriptetes)?
Beispiele:
Wenn ich bei der Seite MediaWiki:Sitenotice/Editnotice, die bisher nicht auf der Beo ist (und die ich ja auch nicht bearbeiten kann), ohne den Skriptkrams (was mit diesem Browser irgendwie gar nicht funzt, obwohl eingeschaltet!) auf den Knopf oben „Beobachten“ (mit Monobook) klicke, dann sieht es so aus, als ob die Seite auf die Beo gesetzt wird (es kommt „Beobachten …“ und er lädt was, dann passiert aber doch nichts weiter. Wenn ich die Seite dann neu lade, sehe ich wieder den Knopf „Beobachten“ statt „Nicht beobachten“, also tatsächlich nix. Der Link nach Beobachten zeigt richtig http://de.wikipedia.org/w/index.php?title=MediaWiki:Sitenotice/Editnotice&action=watch&token=ZIFFERN+BUCHSTABEN an, das stimmt also. Wenn ich darauf geklickt hab und mit der Maus wieder darauf gehe, zeigt er aber was Anderes an, nämlich diesen seltsamen Link stattdessen: http://de.wikipedia.org/wiki/MediaWiki:Sitenotice/null?title=&action=watch – der Seitenname hat sich also durch den Klick geändert und das Token ist weg. Noch mal klicken hätte also keinen Sinn mehr.
Wenn ich umgekehrt auf deiner BD auf „Nicht beobachten“ klicke (mit dem richtigem Link samt Token), erhalte ich anschließend beim näxten Klick den folgenden Link: http://de.wikipedia.org/w/null?title=&action=unwatch – da wurde ebenfalls das Letzte durch „null“ ersetzt und das Token entfernt. Ist das so richtig ohne Skript oder kann man das reparieren? fragt --Geitost22:05, 4. Mai 2013 (CEST)
Hab’s mal mit Vector getestet, da passiert genau dasselbe, außer dass sich dort das Sternchen stattdessen dreht, das Ergebnis ist aber dasselbe. Also nicht skinabhängig. --Geitost22:21, 4. Mai 2013 (CEST)
Egal, ob das nun so gedacht ist oder nicht, dass man das nur mit Skript machen kann (geht ja so Einiges ohne Skript nicht mehr, stell ich so fest, z. B. das ganze Übersetzungsinterface auf Meta geht auch gar nicht), Barrierefreiheit ist jedenfalls was Anderes. In den Einstellungen steht ja normalerweise auch dabei, was nur mit JavaScript funzt und was nicht. Aber dass nicht mal das Beobachten/Nicht-Beobachten von Seiten noch funzt, find ich ja schon seltsam. --Geitost22:27, 4. Mai 2013 (CEST)
Dein JavaScript ist aktiv, hat aber irgendein Problem mit deinem Browser oder mit der Seite. Das es aktiv ist und auch irgendwie funktioniert, kann man daran erkennen, das aus "Beobachten" "Beobachten …" wird. Dies soll anzeigen, das es jetzt arbeitet. Nur warum es dann nicht zum Ende kommt und mit "null" hantiert, ist die nächste Frage. Was nutzt du für einen Browser? Steht etwas in deiner Fehlerkonsole? Versuch mal diesen Link. Du müsstes auf einer Seite landen, wo du das Beobachten noch mal bestätigen musst. Der Umherirrende 22:52, 4. Mai 2013 (CEST)
Das ist interessant, mit dem Link geht es. :-) Muss ich mir merken. Fehlerkonsole werd ich mal nachsehen gehen. Ist eine ältere Opera-Version, ich könnte noch mal gucken, ob ich noch ne neuere Version auf die alte Gurke draufkriege, bevor ich sie aufgebe; die neuesten Versionen gehen jedenfalls nicht. ;-) --Geitost23:18, 4. Mai 2013 (CEST)
Übrigens: „Seitenbezogene Gruppierung in den «Letzten Änderungen» und auf der Beobachtungsliste (benötigt JavaScript)“ stimmt so nicht, das funzt tw. auch ohne JavaScript. Man bekommt die Änderungen alle schön untereinander zusammengefasst dargestellt, nur dass sie nicht mehr zusammengefasst versteckt werden, sondern alle Änderungen offen angezeigt stattdessen. Aber die Reihenfolge passt, es ist also sehr gut ohne JavaScript verwendbar. Man sollte das „(benötigt JavaScript)“ besser rausnehmen, sonst probiert man es gar nicht erst aus. --Geitost22:37, 4. Mai 2013 (CEST)
Die Gruppierte Beobachtungsliste ist mit Klappen angedacht, daher steht da JavaScript hinter. Die Anordnung der Gruppen wird auf den Server gemacht, daher funktioniert sie auch ohne JavaScript. Der Umherirrende 22:52, 4. Mai 2013 (CEST)
Kann es übrigens sein, dass das der alte Bug ist: Bugzilla:24544 (versteh ihn nicht 100%ig)? Oder ist das was Anderes, da steht auch nix von „null“. Sonst hab ich unter den bei WP:BIENE verlinkten Accessibility-Bugs grad nix gefunden, was da passen würde. Die Hinweise auf der Beo werden übrigens auch allesamt ohne Skript nicht angezeigt, im Gegensatz zur Sitenotice, da ist es seltsamerweise kein Problem. Insofern ist es schon gut, wenn darüber auch die Leute ohne JavaScript die aktuelle Mitteilung zu sehen bekommen. :-) --Geitost22:50, 4. Mai 2013 (CEST)
Nein, das ist etwas anderes. Wenn du deinem Browser sagst, er soll keine Bilder laden, dann siehst du den Stern in Vector nicht und kannst somit nicht drauf klicken, um Seiten zu beobachten. Der Umherirrende 22:55, 4. Mai 2013 (CEST)
Ok, dann was Anderes. Die Bearbeitenleisten hier im Editfenster fehlen übrigens (oben und unten) auch vollständig. Deshalb muss ich z. B. die Sig immer händisch eintippen. Interessanterweise hatte ich mindestens die obige auf Meta beim Bearbeiten eben vorhanden, was ich jetzt nicht kapiert hab. Hab in den Einstellungen den Klick bei „Bearbeiten-Werkzeugleiste anzeigen (benötigt JavaScript)“ mal rausgenommen, das hat aber auch nix geholfen. --Geitost23:18, 4. Mai 2013 (CEST)
Interessant, jetzt hab ich zufällig eine Möglichkeit gefunden, wie das mit dem Beobachten-Klick doch klappt: Man muss nur drauf klicken, während die Seite noch lädt und nicht abwarten, bis sie fertig geladen hat, dann geht’s und dann wird ja am Ende was Anderes angezeigt und man muss die Seite noch mal neu laden. Umständlich, aber geht zumindest.
Fehlerkonsole sagt:
Unknown thread, name: TypeError, message: Statement on line 53: Could not convert undefined or null to object
Dann kommt jede Menge unverständlicher Fehlercode mit ein paar ultralangen Links, die ich mal hier in einen Kommentar setze, kann man dann ja wieder rausnehmen, vielleicht sind die Links aufschlussreich?: …
Und noch was Anderes ausgetestet: JavaScript ganz ausgeschaltet. Sehr interessant: Plötzlich geht das mit dem Beobachten wieder, passiert allerdings dasselbe wie eben, als ich während des Seite-Ladens auf den Knopf klickte: Die Seite wird mit „Die Seite «Benutzer Diskussion:Umherirrender» wurde von deiner Beobachtungsliste entfernt.“ neu geladen und man muss dann noch einmal auf „Nicht beobachten“ und noch einmal auf „Beobachten“ klicken, um sie wieder genauso draufzubekommen. Geht also, wenn auch umständlich. Dann ist es also doch nix für Bugzilla, man muss nur das nicht funzende JavaScript ganz ausschalten. Mmh. Seltsame Geschichte ist das. Das hat hier jedenfalls schon etwas weitergeholfen (zu sehen, wo es ungefähr hakt). :-) Na ja, ich muss hier mal grundsätzlich was rechnertechnisch ändern, da nützt es auch nix, daran weiter rumzufrickeln. Ist jedenfalls schon besser so als vorher. :-) Danke erst mal. --Geitost00:03, 5. Mai 2013 (CEST)
Ich schalt mich mal ein. Die Infos aus deinem Kommentar vorher sind ja schon mal interessant. Bitte mach das selbe noch einmal, hänge aber ein ?debug=true an die Adresse der Seite an, auf der du es probierst. --Steef38900:11, 5. Mai 2013 (CEST)
Auf WP:FzW#Module sichten gibt es auch schon äußeren dazu. Der Modul-Namensraum ist im Moment kein Sichtungsnamensraum. Per gerrit:62979 hatte ich es für dewiki angedacht, habe aber auch schon gerrit:62985 gesehen, der es für alle Wikis mit FlaggedRevs macht. Ist wohl der bessere Ansatz. Mal schauen, ob das Montag etwas wird, Freitags sollte man ja nicht umbedingt noch Konfigurationsänderungen machen und sich dann ins Wochenende verziehen.
Die Farbdefinitionen hatte ich mal übertragen, das sollte funktionieren. dl/dd/dt schaue ich mir noch an. Der Umherirrende 08:24, 11. Mai 2013 (CEST)
Seite sieht eh komisch aus in mobile, weil die code-Blöcke soviel padding haben, oder? Habe mal Bug 48352 für die dts gemacht und das lokal vorgezogen. Der Umherirrende 09:48, 11. Mai 2013 (CEST)
Danke schön.
Ich weiß nicht, wie die CODE auf echten Telefonen aussehen, vielleicht passt das ja dort. Mal Chemiewikibm oder Cepheiden fragen, die hatten ja geseufzt. Komisch, dass das weltweit noch keiner angemeckert hatte.
Nach Meldung auf FZW hab ich mir den Code mal angeschaut. Falls kein Monat ausgewählt ist, wird als Datumswert für ucstart <aktuelles Jahr>-00-01T00:00:00Z generiert. Dies wird als <aktuelles Jahr - 1>-12-01T00:00:00Z verarbeitet. Um das zu beheben, müsste wohl eine Ausnahmebehandlung für den Fall, dass kein Monat ausgewählt ist, eingefügt werden (in prefixContribsInit()). Magst du dich drum kümmern?
Das Problem dürfte aber erst seit dem Software-Update auftreten, da seit dem das Jahresfeld standardmäßig gefüllt wird. Ich habe mal diese Bearbeitung gemacht. Der Umherirrende 17:42, 11. Mai 2013 (CEST)
Nein, du kannst nur Seiten auf dem gleichen Projekt in einer Kategorie zusammenfassen. Da die oben genannte Seite auf dem Meta-Wiki liegt (meta.wikimedia.org) und wir hier in der deutschsprachigen Wikipedia sind (de.wikipedia.org) funktioniert es nicht. Der Umherirrende 19:10, 13. Mai 2013 (CEST)
Hei Umherirrender, kannst du mal bei Inkowik vorbeischauen (ab meinem 2. wieder links eingerückten Beitrag um 20:45)? Möglicherweise kannst du zu der Spezialseite noch was sagen oder einen Bugreport schreiben (entspricht en:Special:UnconnectedPages)? Die Seite ist ja so gar nicht benutzbar und zudem auch noch völlig veraltet (monatelang). --Geitost22:23, 15. Mai 2013 (CEST)
Hallo Umherirrender, hier wurde angemerkt, daß eine auf einen bestimmten Filter (sprich: Filter-Nr.) begrenzte Suche im Filterlogbuch alle Treffer ausgibt, sofern man nach einem als privat deklarierten Treffer gesucht hat. (Bei dir als Admin wird das natürlich anders sein.) Mich hatte das auch schon länger gestört, ich hatte mich dann dazu aufgerafft, einen Bug-Report zu schreiben. Nun fangen aber die Probleme an: Auf mw:Extension:AbuseFilter#User rights stehen die entsprechenden Benutzerrechte. Ich wollte auf Bugzilla eigentlich schreiben, daß das Problem nur Leute betrifft, die das Benutzerrecht „abusefilter-log-private“ nicht haben. Zu meiner großen Überraschung stelle ich fest, daß lt. Spezial:Gruppenrechte aber bei uns niemand dieses Recht hat, in enWP auch nicht. Dafür haben Admins in enWP das Recht „abusefilter-view-private“, das bei uns wiederum nicht vergeben ist. Ich bin sehr verwirrt. Was soll ich denn nun auf Bugzilla schreiben? Gruß --Schniggendiller Diskussion 18:07, 12. Mai 2013 (CEST)
Hallo Schniggendiller, ja, bei mir als Admin, der ja die Filter sehen darf, funktioniert die Suche. Das Recht 'abusefilter-modify' erlaubt das sehen und bearbeiten von privaten Filtern. Auf en.wp ist es so, das es eine eigene Benutzergruppe für das bearbeiten von Missbrauchsfiltern gibt, es dort als nicht jeder Admin automatisch kann. Damit die Admins aber nicht ganz außen vor sind, wurde vermutlich ein Recht zum anschauen von privaten Filtern erstellt, die aber das bearbeiten von Filtern nicht erlaubt. Ansonsten kann ich dir noch meta:Abuse filter anbieten, wo die Benutzerrechte auch nochmal aufgeschlüsselt sind.
Habe mal Grob im Quelltext geschaut: Zum Anschauen von privaten Filtern wird auf 'abusefilter-modify' und 'abusefilter-view-private' abgefragt. Zum Anschauen der Logeinträge von privaten Filtern wird auf 'abusefilter-modify', 'abusefilter-view-private' oder 'abusefilter-log-private' abgefragt. Hoffe, das hilft dir. Der Umherirrende 20:45, 12. Mai 2013 (CEST)
Moin, danke für deine Erläuterungen – und für bugzilla:37337. Keine Ahnung, warum ich den neulich nicht gefunden habe. Dann hoffen wir mal, daß der Bug mal irgendwann behoben wird … Grüße --Schniggendiller Diskussion 14:15, 19. Mai 2013 (CEST)
Aktualisierungserinnerung für "Schon Gewusst"
Hallo Umherirrender,
ich glaube, du hattest schon mal mit dem Thema zu tun, darum frage ich bei dir nach. Eigentlich ist es ja so gedacht, dass man auf der HS-Disk einen Hinweis bekommt, wenn die Vorlage für den nächsten Tag bei Schon Gewusst nicht editiert wurde. Die Prüfung läuft, soweit ich das sehe, über die Kategorie Kategorie:Wikipedia:Hauptseite/Schon gewusst/alt ab, wo ggf. die veraltete Vorlage von Wikipedia:Hauptseite/Schon gewusst/Bearbeitungshinweise einsortiert wird. Genau dieses Kategorisieren scheint aber nicht zu funktionieren. Wikipedia:Hauptseite/Schon gewusst/Sonntag ist z.B. derzeit nicht drin, obwohl seit 12.5. unverändert. Beim AdT funktioniert es dagegen, obwohl der Quelltext von Wikipedia:Hauptseite/Artikel des Tages/Bearbeitungshinweise fast genauso aussieht, bis auf das zusätzliche Abfragen der REVISIONID, was nach meinem Verständnis aber nicht die Ursache des Problems sein kann. Allerdings kenne ich mich mit Vorlagenprogrammierung auch kaum aus. Könntest du bitte mal draufschauen?--Berita (Diskussion) 14:46, 18. Mai 2013 (CEST)
Hallo Berita, du hast hier mit dem Cache zu kämpfen. Dieser speichert den Seitenaufbau für die schnellere Anzeige. Leider aktualisiert er sich nicht automatisch, wenn es einen neuen Tag gibt, daher macht ein Bot dies (Eigentlich Benutzer:MerlBot, siehe Benutzer:MerlBot/Touch/täglich.js). Dies scheint aber nicht funktioniert zu haben. Ein manueller Nulledit zeigt aber, das es grundsätzlich noch funktioniert. Es wäre möglich, das MerlBot aufgrund der aktuell schlechten Toolserver-Situation heute nacht nicht gearbeitet hat. Ich würde das an deiner Stelle ein paar Tage beobachten und sonst Merlissimo mal fragen. Der Umherirrende 15:01, 18. Mai 2013 (CEST)
Achso daran liegt das, danke für die Erklärung. Dann werde ich das bei mir auch mal einbauen, dass die Vorlage vom nächsten Tag gepurged wird. Doppelt hält besser, zumal mein Bot zu Hause und nicht auf dem Toolserver läuft, in diesem Fall mal ein Vorteil. Nochmals Danke und schönes WE--Berita (Diskussion) 15:26, 18. Mai 2013 (CEST)
Wie ich gerade sehe, scheint es doch nicht am Bot zu liegen, sondern daran, wie #time auf js-Seiten funktioniert (gibt nämlich englisch zurück). Ich habe Merlissimo mal angeschrieben. Der Umherirrende 06:02, 19. Mai 2013 (CEST)
Ok, das würde auch erklären, warum die Meldung schon seit Monaten nicht mehr erscheint (zumindest ich habe bis gestern keine gesehen). Ganz so schlimm steht es um den Toolserver dann wohl doch nicht.--Berita (Diskussion) 09:41, 19. Mai 2013 (CEST)
Modul-NR, Doku und IP
Schönen Abend,
es gibt ein lustiges Problem im Modul-Bereich:
Wenn man eine Seite wie Modul:AdressenSort als angemeldeter Benutzer anguckt, sieht sie korrekt aus.
Wenn du unangemeldet anguckst, oder du als oller httpsler das s aus der URL nimmst, kommt Bruch.
Offenkundig wird die Doku nicht gezeigt.
Kann das etwas damit zu tun haben, dass die Doku nicht markiert ist? Alle Seiten im 828 müssen wohl markiert und gesichtet werden, damit sie IP angezeigt werden, und ohne Doku gibt es Murks bei der Zusammenführung.
Das ist nicht so furchtbar dringend, weil Leute, die sich für Module interessieren, üblicherweise auch User sind und mittlerweile auch über SUL beim Wechsel aus anderen Projekten zwangsangemeldet werden.
Wenn ab jetzt neue Seiten im 828 angelegt werden, kann oder muss man irgendwas tun oder betrifft das nur die Altfälle?
Ah, dann hätte ich mir das hier sparen können. Das ist der klassische Fall, eine Disku über drei Seiten zu zerfleddern; ich kam nach einigem Nachdenken und Sinnieren über Tlu’s Beschwerde in der Lua-Werkstatt. Hier erledigt, gleichwohl danke. --PerfektesChaos21:10, 20. Mai 2013 (CEST)
Neuanmeldungslogbuch-Bug
Hei Umherirrender, weißt du zufällig, warum nicht alle Benutzerkonten, die aus anderen Wikis hier automatisch angemeldet werden, im Neuanmeldungslogbuch erscheinen – bzw. warum auch bei Wikidata nicht alle Benutzerkonten im Neuanmeldungslogbuch auftauchen (Bsp. bei Wikidata: siehe mein eigenes Logbuch und das von -jkb-, Anmeldungsdaten: [2], [3]). Derselbe Bug ist mir heute auch hier wieder einmal aufgefallen, also gibt es ihn weiterhin. Woran mag das liegen? --Geitost21:21, 23. Mai 2013 (CEST)
Das passiert immer dann, wenn man sich beim ersten Mal manuell eingeloggt hat und nicht automatisch angemeldet wurde. Vorallem bei Benutzer, die keine Cookies von Drittdomains erlauben, passiert dies auf Projekten außerhalb von *.wikipedia.org, weil sie dort nicht automatisch angemeldet sind, sondern sich manuell anmelden müssen. Siehe Bug 42434. Der Umherirrende 21:38, 23. Mai 2013 (CEST)
Hatte mich gar nicht mehr erinnert, dass wir das hier schon diskutiert hatten und es sogar ne Bugmeldung dazu gibt. ;-) *kopfkratz* Nur falls noch Beispiele benötigt werden, hatte ich grad noch mal weitergeschaut: [8], [9]. Das mit den Cookies und Drittanbietern könnte schon passen. Hängt das auch damit zusammen, dass man sich bei Wikidata, Meta, Commons und Co. überall noch mal neu anmelden muss, wenn man sich hier bereits angemeldet hat und dann dorthin wechselt? Denn dann bin ich da immer nicht angemeldet, hatte vermutet, das sei auch so ein MediaWiki-Bug. Beim Abmelden hingegen wird man überall gleichzeitig abgemeldet, nur beim Anmelden klappt das grundsätzlich nicht. --Geitost21:57, 23. Mai 2013 (CEST)
Ist ja auch so ne Sache, dass man auf die Art rausbekommen kann, wer Cookies von Drittanbietern ausgeschaltet hat, oder? Mmh. Datenschutzproblem, würd ich mal sagen, oder? Und wenn gesperrte Benutzer das ausgeschaltet haben, dann bekommt man bei denen über das Neuanmeldungslogbuch standardmäßig gar nicht mit, wenn sie sich mit neuem Konto anmelden. Auch nicht so dolle. Ich fürchte, so damit kann man sogar CU-Anfragen überflüssig machen, da nach meinen Stichproben gerade nur sehr wenige Benutzer nicht im Neuanmeldungslogbuch erscheinen. Oder alternativ wäre das ein neues Argument bei einem CU-Antrag. oO --Geitost22:05, 23. Mai 2013 (CEST)
Die Gerrit-Links gehen übrigens auch nur mit Skripten. Versteh ich das dort richtig, dass das mit dem näxten Update dann zumindest endlich gefixt sein wird, wenn sie schon seltsamerweise über 5 Monate und erst nach einer neuen gleichen Bugmeldung in einem anderen, neuen Wiki feststellen, dass man den Bug plötzlich als sehr kritisch einstuft und sofort fixen muss? Ja, was passiert denn da bei Bugzilla, dass ein Bug nach über 5 Monaten plötzlich höchst kritisch wird und vorher niemand es auch nur einmal für nötig hielt, darauf überhaupt nur zu reagieren? Kommt mir höchst seltsam vor. Ich glaube, wir müssen noch an den Bugmeldungen feilen, damit dort demnäxt schneller was passiert oder was kann man da demnäxt tun, damit Bugs auch bald gefixt werden?
Was ich dabei noch nicht verstehe – der Rest passt jedenfalls zusammen: Wikimedia.org ist doch auch unterschiedlich von wikipedia.org. Dann hätte demnach doch auch dieser Logeintrag genau wie die Anmeldung desselben Benutzers heute hier nicht geloggt werden müssen, oder? Denn das war ja nur 1 Minute nach der nicht geloggten Anmeldung hier. In der Minute stellt ja niemand plötzlich die eigenen Cookies-Einstellungen um. --Geitost22:34, 23. Mai 2013 (CEST)
Komisch, dass der Bug nicht schon vor Urzeiten aufgefallen ist. Im Neuanmeldungslogbuch des im Mai 2012 angelegten Wikis zur Wikimania 2013 ist der erste Eintrag vom 9. Mai 2012, dann noch je 1 am 20. und 25. Juni, das sind die einzigen bis Juli, sämtliche anderen Anmeldungen vor Juli fehlen komplett, und so ging es dann auch weiter, die meisten Anmeldungen wurden nicht im Neuanmeldungslogbuch geloggt (und „was created automatically“ steht da erst mal gar nicht) und niemand hat’s gemerkt. oO
Wie lange das wohl schon so geht? Im Mai 2011 sah es beim Wikimania-Wiki 2012 auch schon nicht anders aus, da wurde auch kaum was geloggt: [10], [11]. 2010 ebenfalls schon: [12], [13]; 2009 auch: [14], [15]; Mai 2008 ebenso: [16], [17]. Dann gab’s den Bug also immer schon seit der SUL-Einführung im März 2008, also seit über 5 Jahren, ohne dass es wer gemerkt hat! Da ist es ja schon seltsam, dass es diesmal plötzlich doch mal wem beim Wikimania-Wiki auffällt. oO Wikidata: [18], [19]. Kannst die Links ja mal beim Bug einfügen, nach über 5 Jahren ist der Bug plötzlich sehr kritisch. ;-) --Geitost00:19, 24. Mai 2013 (CEST)
Warum das erst so lange nach der Einführung von SUL aufgefallen ist, und warum er auf einmal kritisch ist, kann ich auch nicht sagen. Es gibt auch Bugs die viel älter sind, solange kein Entwickler darauf gestoßen wird, tut sich da kaum etwas, aber anderseits ist es auch schwierig die Aufmerksamkeit von Entwicklern zu bekommen, damit sich etwas tut. Viel wird dann auch von freiwilligen Entwicklern gemacht. Eine Ergänzung der Links im Bug wird jetzt auch nichts mehr nutzen, auch wenn die Aufstellung natürlich schon etwas umfangreich ist. Der Umherirrende 07:55, 24. Mai 2013 (CEST)
Mmh, wahrscheinlich benötigen die Entwickler erst mal einen Haufen Beispiele und Links, bevor die irgendwas machen. Bedeuten diese Gerrit-Links dort denn nun, dass der Bug inzwischen gefixt wurde und nur noch nicht live geschaltet wurde, oder wie ist nun der Stand der Dinge? Falls nicht, könnten sich die Links ja durchaus lohnen. Übrigens würde ich ja den Bug anders angehen. Denn grundsätzlich ist es ja nicht sonderlich sinnvoll, dass man sich zwar überall gleichzeitig abmelden, aber andersherum nicht überall gleichzeitig anmelden kann. Man muss sich ja nach einer Abmeldung hier in sämtlichen unterschiedlichen Projekten (Wikipedia, Wikimedia, Wiktionary, Wikibooks, …) immer einzeln wieder anmelden. Das führt dann auch dazu, dass man nicht mitbekommen hat, dass man woanders noch nicht automatisch wieder angemeldet wurde und plötzlich die IP in der Versionsgeschichte steht. Insofern betrifft das nicht nur das Neuanmeldungslog, sondern geht weiter. Ich habe selbst bereits in mehreren Wikis nach solchen versehentlichen IP-Anzeigen wegen dieses Bugs Oversights beantragt, die dann auch durchgeführt wurden. Es handelt sich in der Hauptsache um ein Datenschutzproblem, das deshalb auch endlich mal in irgendeiner Weise gefixt werden sollte. Denn wenn einem mitgeteilt wird, man logge sich überall gleichzeitig ein, und das stimmt dann aber gar nicht (während es aber beim Ausloggen doch funzt), dann ist das auch sehr irreführend und führt genau zu solchen Fehlern und zu Oversights. Und andere Leute wissen gar nicht Bescheid über die Möglichkeit, diese versehentlichen IP-Edits oversighten zu lassen, und so bleiben sehr viele versehentliche IP-Edits in den Versionsgeschichten stehen und ersetzen die CU-Anfragen. oO
Der Haupt-Bug muss also gefixt werden, dass anschließend endlich mal sowohl die Ab- als auch die Anmeldung in diesen ganzen Wikimedia-Wikis gleichzeitig erfolgt und nicht nur die Abmeldung (warum geht das überhaupt, dass man sich zwar überall gleichzeitig abmelden, aber nicht gleichzeitig anmelden kann?). Kann man nicht den Cookies mitteilen, dass die anderen Wikimedia-Wikis keine Drittanbieter sind, sondern zusammengehören? Denn dann gäbe es wohl auch das Problem gar nicht mehr, dass man sich in einem anderen Projekt wieder neu per Hand statt automatisch anmelden müsste. Höchstens noch dann, wenn man beim normalen Wiki nach über 30 Tagen ausgeloggt wurde und man dann, statt sich erst dort wieder einzuloggen, direkt zu einem anderen Projekt geht und sich da einloggt, wo man noch gar nicht registriert war. Das wiederum ist aber ein wesentlich seltener Fall als der hier so oft vorkommende (dass Benutzer von einem Wiki zum anderen wechseln und dort nicht automatisch eingeloggt sind), da die meisten Leute sich ja erst mal in ihrem üblichen Wiki wieder anmelden, bevor sie woandershin gehen. Mit einer einheitlichen Anmeldung in allen Wikimedia-Wikis wäre man 99 % dieser Probleme los. Das müsste also stattdessen ganz gefixt werden, da es seit 2008 bereits nicht funzt. Kannst du das irgendwie dort noch verständlich rüberbringen? --Geitost11:52, 24. Mai 2013 (CEST)
Ein gerrit-Change steht immer erstmal zum Review bereit und kann dann von anderen Entwicklern bewertet werden und abschließend wird er gemerged. Dies ist heute mit dem Change passiert, daher wird das ganze mit dem nächsten Software-Update auf Version 1.22wmf5 auf den jeweiligen Wikis aktiv. Hier dann am 5. Juni.
Die automatische Anmeldung an allen Projekten funktioniert, sofern du deinem Browser erlaubst, die Cookies der Drittanbieter zu akzeptieren. Je nach Browser kann man das auch auf Domains eingrenzen (Musst also nicht generell freigeben, sondern kannst die WMF-Domains, wie wikipedia.org, wikidata.org, usw. angeben, musst dies aber einzeln tun). An einer Lösung dafür wird aber auch gearbeitet, weil nun auch FireFox angekündigt hat, das solche Sachen wohl nicht mehr automatisch funktionieren. Warum aber erst der FireFox ins Spiel kommen muss, lasse ich lieber unkommentiert.
Die Abmeldung ist immer zentral, weil du die Sitzung auf den Server beendest und diese ist aufgrund des SUL für alle Projekte mit der gleichen Sitzungsnummer verbunden. Wenn du dich nachträglich an einem anderen Projekt anmeldest, bekommst du vom System die gleiche Sitzungsnummer zugewiesen, die du auch bei allen anderen Projekten hast. Dadurch bist du zentral abgemeldet. Hat den Vorteil, das man nicht überlegen muss, wo man alles war, um sich dort einzeln abzumelden. Der Hinweis, das man als IP arbeitet wird immer angezeigt, falls man mal versehentlich abgemeldet ist, das sollte man schon kurz lesen, was über den Bearbeiten steht, auch wenn man meint, schon alles zu kennen. Anderseits hilft es auch, wenn man einen anderen Skin als den Standard hat, dann fällt einem das auch schneller auf, weil die Oberfläche anders aussieht. Hier ist aber jeder selber für sein handeln verantwortlich, da die 30 Tage immer irgendwann ablaufen können, so dass man auch bei automatischer Anmeldung in allen Projekten mitten in seiner Arbeit abgemeldet sein kann (Keine Ahnung, ob das so richtig erklärt ist, nutze das nicht, da mein Browser beim schließen eh alle Cookies löscht) Der Umherirrende 13:21, 24. Mai 2013 (CEST)
Ok, 5. Juni ist ja überschaubar. Hat nun ein halbes Jahr gedauert, mmh.
Das mit dem Domains-Eintragen ist ne gute Idee, das schau ich mir mal an, damit es dann demnäxt besser klappt. Zu der Feuerfuchs-Sache schreib ich besser mal nix. ;-) Wenn sie zumindest dann mal dran arbeiten, isses ja schon mal ein Fortschritt.
Das mit der Sitzungsnummer ist interessant, man weiß ja nie, wie die so was deichseln. ;-) Ich hab ja Monobook extra eingeschaltet, so kann ich sofort am Seitenlayout sehen, wenn ich abgemeldet bin. Aber wenn man schon eine Seite angemeldet offen hat, sich dann (vor 1 Jahr) im MediaWiki-Wiki abmelden musste, um die Sache mit Vector testen zu können, weil es angemeldet nicht ging (lag an Monobook, hatte ich erst danach festgestellt und dann wieder angemeldet und Vector eingeschaltet), und sich dann dort wieder anmeldet, um dann hier etwas zu schreiben in das offene angemeldete Fenster, dann wird halt gespeichert, ohne dass man den Hinweis mit der IP zu sehen kriegt. Dann sieht man es erst nach dem Speichern und dann ist es zu spät. Weißte? Da muss man aufpassen wie ein Fuchs, sonst geht es schief, ohne dass man den Hinweis sieht. Ich hatte mich ja hier weder ab- noch angemeldet, sondern nur beim MediaWiki-Wiki. Also hatte ich nicht damit gerechnet, dass ich trotzdem dann hier abgemeldet war. So was kommt dann dabei heraus. Ein anderes Mal war beim Benutzen des Übersetzungseditors, wo in einem anderen Wiki abgespeichert wurde, wo ich aber nicht angemeldet war. Da hatte ich auch den IP-Hinweis und die Vector-Oberfläche nicht zu Gesicht bekommen, bevor gespeichert wurde. Solche Sachen kommen halt ab und zu vor, das ist superblöd. Deshalb muss das auch gefixt werden. --Geitost15:53, 24. Mai 2013 (CEST)
Die 30 Tage waren dabei hingegen nie ein Problem, da ich dann ja – wie du richtig sagst – durch die unübliche Vector-Oberfläche genügend gewarnt bin. Das fällt wirklich gut ins Auge. :-) Und ohne JS kann ich das Übersetzungsinterface ja eh nicht benutzen, dann kann das da auch nicht mehr passieren, hehe. Hat eben doch auch einige Vorteile ohne JS ;-) – der schnellere Rechner macht aber auch einiges Andere wett, das so nicht geht. --Geitost15:55, 24. Mai 2013 (CEST)
Ist jetzt bereits live gegangen. Der Umherirrende 14:49, 25. Mai 2013 (CEST)
Das ist mal zur Abwechslung eine erfreuliche Nachricht. :-) Wie du das immer so schnell mitbekommst … --Geitost15:18, 25. Mai 2013 (CEST)
Danke, dort was geschrieben (rutsch mal nach links).
Allerdings stelle ich leider beim Testen des Neuanmeldelogbuchs gerade fest, dass es leider doch nicht so funzt. :-/ Hab versucht, mich bei wm2011:Special:UserLogin anzumelden (also nicht registrieren, sondern anmelden), wo ich bisher noch nicht registriert bin (oder auch angemeldet, je nachdem, also noch kein dortiges lokales Konto jedenfalls). Ohne Cookies geht das jetzt gar nicht mehr, vorher ging das ja, halt dann aber ohne den Logeintrag. Für WM2011 hab ich auch nicht extra Cookies angewählt. Nun bekomme ich also statt der erfolgreichen Anmeldung zu sehen:
„Login error“
„There is no user by the name "Geitost". Check your spelling.“
Außerdem steht da noch:
„You must have cookies enabled to log in to Wikimania.“
Geht das Anmelden also jetzt grundsätzlich nur noch, wenn man auch die Cookies für Drittanbieter (oder speziell die für das Wiki) oder so zulässt und sonst nicht? Vielleicht sollte einem das bei der Anmeldung auch mitgeteilt werden, dass man jetzt neuerdings in den Einstellungen die Cookies für Drittanbieter für eine erfolgreiche Anmeldung zulassen muss. Mmh. Auch nicht so dolle. Oder muss man die Anmeldung dann über die Registrierung vornehmen? Mal weiter testen. --Geitost16:15, 25. Mai 2013 (CEST)
Also, ich krieg es mit dem Einloggen/Registrieren dort weder mit http noch mit https hin und ich seh dort auch nur einen Knopf „Log in“, aber einen Knopf zum Neu-Registrieren find ich gar nicht dort. :-( Das heißt also, man kann sich bei den Wikis dann nur noch mit Drittanbieter-Cookies anmelden, wenn ich das richtig sehe. Wird einem aber leider gar nicht mitgeteilt. Dann werden es wohl viele gar nicht mehr schaffen, sich dort neu anzumelden. Oder ist bei dem Wiki die Registrierung ganz abgeschaltet inzwischen? Hab jetzt kein anderes Wiki gefunden, vielleicht versuchst du es mal bei wm2013:Special:UserLogin oder wm2014:Special:UserLogin, wo ich schon angemeldet bin und es deshalb dort nicht mehr testen kann und ein anderes, neueres Wiki zum Testen fällt mir grad nicht ein. Bei den beiden Wikis hat das normale Anmelden jedenfalls in den letzten Tagen noch funktioniert (+ jeweils ohne Neuanmeldungslogeintrag), soviel ist sicher. --Geitost16:29, 25. Mai 2013 (CEST)
Das wikimania2011-Wiki ist bereits geschlossen, daher kann man sich dort nicht mehr registrieren, auch nicht im Rahmen von SUL. Ich habe bereits auf allen Projekten ein Konto angelegt, daher auchin wikimania2013 und 2014 und kann das ganze nicht testen. Du könntest es auf dem loginwiki mal versuchen. Das ist noch nicht so alt und du scheinst dort noch kein Konto zu haben. Der Umherirrende 17:36, 25. Mai 2013 (CEST)
Ok, das hat geklappt, und nun steht ich auch im dortigen Neuanmeldungslog. (Hat das Wiki gar kein Interwiki-Kürzel?)
Ich hab dann noch ne andere Seite bekommen, die ich anwählen sollte: Special:CentralLogin/complete. Das hat nicht geklappt, dort bekomm ich die Anzeige:
„Central user log in
The provided authentication token is either expired or invalid.“
Was immer da komplettiert werden sollte. Hab ich jetzt nicht kapiert. Jedenfalls steht dann also nun in den jeweiligen Neuanmeldelogs auch „was created automatically“ drin. Solche hatte ich auch schon bei Wikidata gesichtet, als noch die automatischen doppelt angezeigt wurden. Deshalb musste es auch eigentlich funzen.
Ich versteh nur nicht, warum man ein geschlossenes Wiki nicht auch explizit als solches kennzeichnet und man stattdessen immer angezeigt bekommt, das Konto gäbe es nicht und man solle Cookies annehmen und sich über https anmelden. Das sind doch alles Irreführungen, dann probiert man sich nen Wolf und in Wirklichkeit geht es gar nicht, weil das Wiki zu ist. Dann soll man doch auch überall hinschreiben, dass es dicht ist. Wo hast du denn die Info so schnell gefunden? Ich hatte noch in wm2011:Special:Log etliche Neuanmeldungen am 17.05.2013, also vor einer Woche, gefunden (darunter etliche Stewards, 1 Botkonto und noch andere Konten) und war mir da nicht sicher, ob es noch offen war. Steht auch nirgends. Nicht mal auf der Hauptseite finde ich irgendeine Info dazu. :-( Sollte das nicht eigentlich das Minimum sein, dass man geschlossene Wikis entsprechend kennzeichnet? Am besten auf allen Seiten? --Geitost19:05, 25. Mai 2013 (CEST)
Das loginwiki ist noch nicht so alt, da gibt es wohl noch kein Interwikikürzel (siehe Spezial:Interwikitabelle). Das loginwiki soll man irgendwann die zentrale Anmeldung an allen Projekten von WMF machen und die Cookie-Problematik umgehen, oder so. Aus diesem Grund gibt es dort die Spezialseite "CentralLogin", da es aber noch in der Erprobung ist, ist der Fehler wohl noch in Arbeit.
Ja, geschlossende Wikis sollte man auf dem Projekt sichtbar kennzeichen. Sichtbar ist das im Moment nur auf Spezial:Sitematrix, wo die Wikis durchgestrichen sind. Da die Benutzerkonten am 17. Mai alle zeitnah angelegt wurden, denke ich mal, das da irgendein Skript zur Gange war, was für Stewards die Konten anlegte. Da weiß ich aber auch nichts drüber. Für Notfälle können Stewards auch noch auf geschlossenden Projekten bearbeiten machen. Wenn man auf so einem Projekt bereits ein Konto hat, müsste das Anmeldung auch weiterhin möglich sein, weil ja nur das Anlegen von Benutzerkonten unterbunden wird (und daher das "Benutzerkonto anlegen" oben rechts fehlt). Der Umherirrende 19:27, 25. Mai 2013 (CEST)
Ja, das erklärt natürlich, dass der Registrierungsknopf fehlt. Dann kann ich also wohl davon ausgehen, dass ein Wiki, wo der Knopf fehlt, geschlossen wurde, wenn es schon sonst nirgends zu erkennen ist. Auf die Sache mit der Kennzeichnung müsste man denHexer oder so noch mal anhauen.
Die Spezialseiten muss ich mir merken (bzw. mein Browser), die sind gut. Wusste gar nicht, dass es soooooo viele Interwikikürzel gibt zu Nicht-Wikimedia-Wikis und sogar auf ganz andere Seiten, die gar keine Wikis sind. Sogar Google ist mit dabei. oO
Das Wikimania2012-Wiki ist also auch schon zu, dann müsste ich mich da ja noch einloggen können, da hatte ich ja auch einiges übersetzt. => ausprobiert, anmelden hat geklappt, aber die Benutzeroberfläche ist futsch, also nix Vector wie vor dem Einloggen, nix Monobook, wie es eingestellt ist, sondern wohl Simple/Einfach-Standardoberfläche. Komisch, sieht völlig bescheuert aus. Man muss ganz nach unten zu den Knöpfen scrollen und die richtigen raussuchen gehen. Beim 2011er krieg ich zumindest Vector ohne Anmeldung. Aber man bekommt beim Bearbeiten „view source“ und als Grund „The action you have requested is limited to users in the group: Stewards.“ Insofern kann man es dadurch auch noch bemerken. Bei 2011 auch. Aber warum bei 2012 das selbst eingestellte Skin nicht mehr geladen wird und stattdessen gar keins bzw. das Standard-Fallback-Skin Simple/Einfach, ist mir auch schleierhaft.
Auf dem Wiki habe ich kein Konto, aber auf anderen Wikis, die geschlossen sind, funktioniert die Anmeldung und ich habe auch einen funktionierenden Skin, daher ist es schwer zu sagen, was dort speziell nicht funktioniert, da eigentlich die Skins mit ausgeliefert werden müssten. Aber ist eigentlich auch egal, wird ja nur als History aufbewahrt. Der Umherirrende 20:25, 25. Mai 2013 (CEST)
Interessant. Du kannst es gerne dort noch mit verlinken, ist vermutlich für den ein oder anderen Nicht-Englisch-Leser interessant. Der Umherirrende 20:27, 30. Mai 2013 (CEST)
Hallo Brackenheim, da dürfte nicht mehr viel sein, weil ich solche Fälle gerne mit {{NowCommons/Mängel}} versehe und den Hinweis auf NoCommons-Baustein. Ich schaue aber mal, ob sich doch noch etwas findet. Der Umherirrende 15:27, 1. Jun. 2013 (CEST)
Da ich dafür die image-Table von Commons brauche, müsste ich erst 9 GB herunterladen, das dauert etwas zu lange. Ab und an prüfe ich, ob bei Dateien die NowCommons-Vorlage fehlt und dabei prüfe ich auch auf NoCommons und setze dann, wie oben gesagt, die Mängelvorlage, das sieht dann so aus. Was im Rahmen der normalen NowCommons-Kategorie-Arbeiten dann abgearbeitet wird, daher ist eine Aktualisierung der oben genannten Seiten eigentlich nicht mehr notwendig. Ich habe sie mal mit einem Archiv-Baustein versehen. Der Umherirrende 17:42, 1. Jun. 2013 (CEST)
ob ich dich motivieren könnte, deinen Credits vier Pättsche hinzuzufügen?
Es geht um mw.Api.* und den dort eingekastelten Hinweis.
Bei mw.Api().get() waren die ebenfalls mal drin, aber sind dort auch inzwischen deprecated und optional.
Bereits seit Juni letzten Jahres war auf das Promise umgestellt worden, und .get() und .post() entsprechend optional umgebaut. Diese Serie hier hatte man offenbar vergessen.
Ich hatte mal eine Dreiviertelstunde bei mir nach einem Bug und der Ursache für die kryptische Fehlermeldung vom Ajax gesucht, bis ich dahinterkam.
In gerrit:10662 war das ok und err für parse optional, wurde dann aber mit gerrit:45239 wieder zurückgebaut, warum auch immer. Ich kann aber mal schauen, das es wieder rein kommt. Der Umherirrende 15:39, 1. Jun. 2013 (CEST)
Jetzt gerrit:66335. postWithEditToken habe ich mal raus gelassen, sieht eh kaputt aus (api.post kennt keine 3 Parameter), da müsste man das ganze mal umkrempeln. titleblacklist würde ich machen, wenn das andere gemerged wurde, dann weiß ich auch, wie die Entwickler es gerne hätten, das muss man ja nicht parallel pflegen. Der Umherirrende 17:23, 1. Jun. 2013 (CEST)
Danke schön.
Diesen Zick-Zack-Kurs muss ich ja nicht begreifen.
Ich hatte es vor Monaten auf Eis gelegt und erstmal abgewartet, ob sowieso jemand grad dran baut. Heute kam ich aufgrund einer Anfrage wieder drüber.
Krinkle schreibt, das es unnötig wäre, weil "Deferred done/fail methods have built-in support for type checking and ignoring undefined values". Mag du einmal schauen? Danke. Der Umherirrende 08:25, 2. Jun. 2013 (CEST)
Sorry, ich wollte dich in nichts reinquatschen. Als ich das letzte Mal dran war, wurden auf der console Error ausgelöst (weiß aber nicht mehr ob aus jquery oder aus mw) hinsichtlich null für function.
(an einem Tag trägt mir Leyo die AK an, und du legst mir den Developer nahe. Ich kann jetzt schon das Ende der Warteschlange nicht mehr sehen.)
Ich habe den Patch dann mal mit deinem Text verworfen. Kein Problem, klang ja auch erst gut, wenn man nicht weiß, das defered das selber prüft.
Developer Access ist aber einfacher, als hier Admin zu werden ;-) Dafür brauchst du nämlich nur ein Konto auf WmfLabs anlegen und kannst dann zumindestens anfangen zu kommentieren und wenn du möchtest auch zu committen. Es gibt auf gerrit auch kein Mindestmaß an Aktivität, die Wahrscheinlichkeit aufgrund von (vermeintlicher) Inaktivität abgewählt zu werden, ist dort nicht gegeben. Der Umherirrende 16:46, 2. Jun. 2013 (CEST)
Ich habe die beiden Dummies aus meinem Aufruf herausgenommen. Und wehe, wenn der jetzt doch noch mal abschmiert. Diesmal fotografiere ich die Fehlermeldungen! Es muss ja irgendwo was gewesen sein, sonst hätte ich nicht den Ajax-Bug aufdröseln müssen; ich finde bloß nichts, das sich in den letzten Monaten geändert hätte. Deshalb ging ich gestern auch davon aus, dass das immer noch so sei.
Ich habe mir sogar am Anfang meiner BD eine Einladung zum Developer auf nicht-archivieren gesetzt. Ich habe aber keinerlei Zeit über, mich in die Strukturen dieses Patching und des archaischen Bugzilla hineinzuwursteln und bin heilfroh, dass ich mich nach SVN jetzt auch in den Gerrit-Quellen gut zurechtfinde. Zu viele Hochzeiten; ich bin dicht und würde dann nur oberflächlich murksen. Möchtest du dich nicht in Lua einarbeiten?
Ein gerade geborenes Waisenkind kannst du dir vielleicht mal angucken hinsichtlich Richtigkeit und Vollständigkeit; und gern ergänzen wenn ich noch was übersehen habe.
Hallo Umherirrender, ich habe hier eine Vorlage gefunden die anscheinend nicht vollständig aus der en:WP portiert wurde.Deshalb ist sie auch nicht in Benutzung. Habe den Ersteller hier angeschrieben, ist ihm aber wohl auch nicht so ganz klar was er weiter damit anstellt. Kannst du sie vervollständigen und nutzbar machen? Würde sie gerne Nutzen. Dank im Voraus. Gruß. --LezFraniak (Diskussion) 17:33, 2. Jun. 2013 (CEST)
WP:Spaltensatz sollte vermieden werden. Ansonsten kürzt die Vorlage nur einen Tabellenanfang ab, was man im Notfall auch direkt im Artikel schreiben könnte. Damit sie sinnvoll nutzbar ist, scheint es noch {{Col-Unterbrechnung}} aus en:Template:Col-break zu benötigen. Ich würde das aber nicht importieren lassen, sondern {{Col-Beginn}} und {{Col-Ende}} löschen lassen. Der Umherirrende 19:53, 2. Jun. 2013 (CEST)
Hallo Umherirrender,
ich habe gesehen, sie arbeiten immer wieder auch hieran mit und sind sogar Kenner in Strukturfragen, so daß ich vermute, daß Sie dieses Thema gut beurteilen können.
Vor ein paar Wochen wurde eine Weiterleitungsseite gelöscht, die genau die hier im ersten Absatz beschriebene Funktion erfüllte. Hier können Sie nachvollziehen, wie aber selbst mein Hinweis darauf nicht zur entsprechenden Korrektur führte.
Wegen der grundsätzlichen Bedeutung des Falles, möchte ich die Löschung nun prüfen lassen. Vielleicht können Sie sich die Sache einmal ansehen und sie beurteilen, ich bin sicher, das muß doch rasch vernünftig abgeschlossen werden können.
Vielen Dank im Voraus & viele Grüße! Friedrich Hoffmann (Diskussion) 21:35, 5. Jun. 2013 (CEST)
Ich denke, auf der Löschprüfung ist dies gut aufgehoben und wurde dort von Kollegen bearbeitet, die sich mehr mit dem Thema und auch mit Weiterleitungen beschäftigen. Der Umherirrende 18:47, 6. Jun. 2013 (CEST)
Hallo, keiner muß, das ist klar, aber daß diese "Kollegen" sich jemals besonders damit beschäftigt haben sollen, ist stark zu bezweifeln.
Moin Umherirrender, ich muss dich leider wieder mal bemühen, weil ich es einfach nicht gebacken kriege. Ich habe eine Vorlage erstellt. Diese soll, wie {{NONE}} in eine Tabelle oder Turnierbaum eingebunden werden. Was dabei leider rauskommt ist dies (Hilfeseite hat leider auch nicht weitergeholfen.). Habe auch die Syntax von NONE kopiert und angepasst, funzt aber trotzdem nicht. Woran liegt's. Dank im Voraus für's Ausbügeln. --LezFraniak (Diskussion) 11:29, 9. Jun. 2013 (CEST)
Hallo LezFraniak, da waren noch Zeilenumbrüche in der Vorlage, die die Tabellensyntax stören. Wenn due ine Tabellenzeile in nur einer Quelltextzeile angeben möchtest (also mit || arbeitest), dann darf die ganze Zeile keinen Zeilenumbruch enthalten. Die Zeilenumbrüche kamen hier durch die Vorlage rein und dann wurde die Tabellensyntax nicht mehr richtig interpretiert. Der Umherirrende 11:43, 9. Jun. 2013 (CEST)
Na, da soll einer wie ich draufkommen. Super. Danke.
PS: Bevor ich dich vom Haken lasse. Diese Vorlage setzt das Komma bei Spielstätte, wenn längere Venus eingefügt werden, in die nächste Zeile. Das sieht komisch aus. Ein „nowrap“ hat da auch nicht geholfen. Der Umbruch soll natürlich erst nach dem Leerzeichen erfolgen. --LezFraniak (Diskussion) 11:52, 9. Jun. 2013 (CEST)
Scheint so gewollt zu sein, der Parameter "Spielstätte" enthält das "<br />, was für einen Zeilenumbruch steht. Du müsstes ihn dort entfernen und um den Ort ein nowrap machen, wenn du nicht möchtest, das die Flagge getrennt vom Text steht. Der Umherirrende 11:59, 9. Jun. 2013 (CEST)
Hallo Umherirrender, ich möchte (z.B. hier) in dem Abschnitt Gruppenphase" die beiden Tabellen so verbinden, das, wenn man die Legende aufklappt, die Tabelle Gruppe B nicht nach unten rutscht, sondern an der Stelle bleibt wo sie ist. Platz wäre ja. Alle versuche meinerseits waren nicht von Erfolg gekrönt. Geht das? Kann man eigentlich den Abstand zwischen 2 Tabellen verkleinern oder ist das so voreingestellt? Gruß. --LezFraniak (Diskussion) 18:45, 10. Jun. 2013 (CEST)
In dem du die zweite Tabelle mit in die Tabellenzelle der ersten Tabelle packst. Und das zweite mit padding-left oder margin-left. Kannst es vermutlich auch in die Legende direkt packen, musst mal ausprobieren. Habe dir Hilfeseiten verlinkt, damit du den Unterschied siehst und dich dann entscheiden kannst. Der Umherirrende 20:44, 10. Jun. 2013 (CEST)
Prost
Flotte Antwort. Wenn ich das richtig verstehe (und sehe) hat die Tabelle nun anstelle von 3 Zellen nur 2 Zellen. Zelle A1 (mit der Gruppentabellen A & B) und Zelle A2 mit der Legende. Was macht das padding bzw. margin? Ich hatte diese Lösung schon probiert, da hat's dann aber die Tabelle Gruppe B zerrissen. Mir erschließt sich nicht die Funktion? Es scheint, in diesem Fall anscheinend das „Zerreissen" zu verhindern. Was passiert, wenn ich das gleich in die Vorlage schreibe und diese Vorlage aber alleinstehend und nicht, wie hier, innerhalb einer Zelle eingesetzt wird? Also ober-/unterhalb eine anderen Tabelle steht. Dank dir jedenfalls recht herzlich. Deine Hilfeseiten machen einiges verständlicher als die auf der Wiki. Muss ich mir mal in Ruhe durchlesen, aber nicht mehr heute. Schönen Abend noch (evtl. im Biergarten bei der lauen Nacht. Lass es dir schmecken!). --LezFraniak (Diskussion) 21:45, 10. Jun. 2013 (CEST)
PS: Bist du eigentlich mal auf einem Wiki-Stammtisch anzutreffen? Jetzt wird's ja mal Zeit auf ein Bierchen mit uns beiden.
http://de.wikipedia.beta.wmflabs.org zurzeit ausschließlich per http, ansonsten wäre es egal; alles mit Quellcode und Bots ausschließlich per https. Da du wohl unter https arbeitest, müsstest du beim Anklicken eine Sicherheitsmeldung bekommen.
Danke für die Hinweise, beide subdomains ausgenommen.
Der editsection-Code sieht jetzt nicht groß anders aus, daher lohnt es sich nicht, das zu ändern, auch wenn er mehr dem Standard entspricht (beispielsweise variablen am Anfang deklarieren). Funktioniert beides, ist beides lesbar und nachvollziehbar ;-). Ich hätte aber kein Problem damit, wenn ein anderer Admin meint, das müsste jetzt anders aussehen. Der Umherirrende 16:53, 11. Jun. 2013 (CEST)
Ich arbeite in die Richtung, dass unser projektweites Zeugs eines Tages mal LINT-fähig sein möge; wovon es bislang noch ziemlich entfernt ist. LG --PerfektesChaos22:10, 11. Jun. 2013 (CEST)
β-dewiki
Hallo Umherirrender,
kannst du mich bitte hier zum Admin machen, damit ich ein bisschen mit den MediaWiki-Nachrichten (insbesondere AFT) rumspielen kann?
Viele Grüße--se4598 / ?00:58, 13. Jun. 2013 (CEST)
Ist erfolgt. Viel Spaß beim testen. Der Umherirrende 18:16, 13. Jun. 2013 (CEST)
Hei Umherirrender, sach mal, wo siehst du denn beispielsweise hier einen Link auf die besagte Abrufstatistik? Ich seh da nirgends so was. Allerdings ist es auch egal, da ohne JS sowieso nix bei der Statistik angezeigt wird. Aber im Footer seh ich den Link jedenfalls schon im Gegensatz zu den Seiteninfos. Da stimmt doch was nicht. Viele Grüße --Geitost22:21, 15. Jun. 2013 (CEST)
Der steht im Abschnitt "Informationen auf externen/privaten Diensten/Servern", das solltest du auch ohne JS sehen. Der Umherirrende 22:22, 15. Jun. 2013 (CEST)
Also, ich hab da genau 4 Abschnitte, und die heißen „Basisinformationen“, „Seitenschutz“, „Bearbeitungsgeschichte“ und „Seiteneigenschaften“. Das mit den externen Diensten und so ist nicht dabei. Sind auch alles interne Links, keine externen dabei. Und wenn ich mir die Infos zu einem Artikel ansehe, dann ist dort der einzige externe Link der auf Wikidata, sonst nur interne Links vorhanden. Dort fehlt auch unten der Abschnitt „Seiteneigenschaften“, sodass nur 3 Abschnitte übrig sind. --Geitost22:27, 15. Jun. 2013 (CEST)
Stimmt, die Schweizer waren benacteiligt. Ist aber jetzt behoben. Der Umherirrende 22:30, 15. Jun. 2013 (CEST)
Ja, danke, nun sind da viel mehr Links, auch externe. :-) Do kanns zaubre, man könnte dich mit dem Hexer verwechseln. ;-) Wie soll man darauf bloß kommen? Kann es sein, dass noch wesentlich mehr nicht zu sehen ist als nur dies? Und wie kann man das ändern? Sieht man das auch alles nicht, wenn man mit engl. Oberfläche hier werkelt? Das wäre ja auch sehr blöd, wo bestimmt auch viele damit rüberkommen und hier was machen. Kann man das nicht irgendwie ändern? Und: War das immer schon so oder ist das jetzt neu? Und warum? Ich versteh’s nämlich nicht, dass so was skinabhängig ist. Viele Fragen … --Geitost23:19, 15. Jun. 2013 (CEST)
Ich habe das Gefühl, das eine Software-Änderung vor einigen Wochen daran Schuld ist. Der Footer auf Spezial:Beiträge (MediaWiki:Sp-contributions-footer) hatte ja auch lange funktioniert und war dann für die Sprachvarianten verschwunden. Der Umherirrende 16:52, 16. Jun. 2013 (CEST)
noch mehr de-ch/-at/-formal-Unterschiede bei den MW-Nachrichten
Hei noch mal. Wir müssten das Thema noch weiter vertiefen, da funzt sehr vieles nicht mehr wie gewohnt. Bis zum 5. Juni um ca. 20 Uhr (das war die Softwareänderung an dem Donnerstag) funktionierte noch alles wie gewohnt. Aber seitdem stell ich immer wieder was Neues fest, was nicht mehr da ist. :-( Man müsste mal feststellen, was am 5. Juni eigentlich geändert wurde und das wieder zurück ändern. Geht das irgendwie? Kannst du rausfinden, was bezüglich der Sprachversionen am 5. Juni geändert wurde?
Näxtes Beispiel hab ich eben erst gefunden: Mit de-ch sieht es wie folgt aus, wenn ich eine alte Version einer > 30 kB großen Seite bearbeiten will bzw. auf Bearbeiten klicke – also einerseits > 30 kB und andererseits alte Version, ich pack es hier einfach mal zusammen, sind aber sicher mehrere verschiedene MW-Nachrichten:
Achtung: Du bearbeitest eine alte Version dieser Seite. Sofern du sie speicherst, werden alle neueren Versionen überschrieben.
Keinerlei Hinweis auf die Seitengröße mehr da, einfach futsch, den hab ich eben vermisst und es direkt mit de: ausprobiert, da ist es weiterhin vorhanden. Sieht dort so aus, in einem roten Kasten umrandet (bei de-ch ist das nicht so, dort ist nur der Text fett):
Achtung: Du bearbeitest nicht die aktuelle, sondern eine ältere Version dieser Seite. Wenn du speicherst, wird diese als aktuelle Version neu gespeichert. Um die aktuelle Version dieser Seite bearbeiten zu können, brauchst du nur die Bearbeiten-Schaltfläche noch einmal anzuklicken.
Und unter dem Rahmen dann noch:
Größe der Seite bzw. des bearbeiteten Abschnitts: xx KB.
Das fehlt bei mir ganz. Kannst du das auch noch beheben? Und dann müsste man mal vergleichen, was sonst noch alles anders ist und sämtliche de-ch/-at/-formal-Seiten zu den analog zu den für de: angelegten MW-Seiten ebenfalls anlegen, damit das mit den unterschiedlichen Anzeigen mal aufhört. --Geitost20:32, 21. Jun. 2013 (CEST)
Die eigentliche Änderung dürfte gerrit:57518 gewesen sein. Habe gerade Bug 48956 gefunden, wo das ganze angemerkt mit der sp-contributions angemerkt wird. Das ganze ist ein schwieriges Thema. Von der vermeintlichen Verbesserung habe ich aber noch nichts gesehen, wo doch gerade die hier genannten Fälle ein gutes Beispiel wären.
So hätte ich mir das Fallback vorgestellt: lokal [de-ch] -> lokal [de] -> messages.php [de-ch] -> messages.php [de] -> messages.php [en]
Da bei uns die Sprache de ist, werden Nachrichten die auf /de enden niemals genutzt. Der Umherirrende 13:09, 22. Jun. 2013 (CEST)
Bislang nicht, aber dort ist auch eine Änderung geplant, damit man verschiedene Fallbackfälle auffangen kann.
Bislang lief Fallback wohl so: lokal [de-ch] => messages.php [de-ch] => messages.php [de] => messages.php [en].
lokal [de-ch] -> lokal [de] -> messages.php [de-ch] -> messages.php [de] -> messages.php [en] ist wohl unerwünscht, da dann auch andere Fallbacksprachen nicht mehr die Variante aus dem Translatewiki, sondern eine lokale erhielten, und die tw. unverständlicher wäre als hier bei de-ch und de:. Sinnvoll wäre deshalb zumindest stattdessen: lokal [de-ch] => messages.php [de-ch] => lokal [de] => messages.php [de] -> messages.php [en], damit nicht mehr auf die de- oder gar en-Translatewiki zurückgegangen wird, sondern stattdessen erst mal die lokale de-Version genommen wird. Und für die Möglichkeit, lokale Versionen auch in den anderen Sprachen verfügbar machen zu können, soll dann wohl mal die lokale /de-Version genommen werden, damit man das dort eintragen kann. Denn die ist ja bislang noch ungenutzt und könnte dann dafür neu genutzt werden. --Geitost14:46, 22. Jun. 2013 (CEST)
MediaWiki:action-hiderevision: die Nachricht existiert im Translatewiki irgendwie gar nicht und kann somit nicht übersetzt werden, ist bei den Fallbacksprachen also in Englisch
MediaWiki:addedwatchtext: Fallback-Unterseiten entweder anlegen oder anpassen, es fehlt tw. der Halbsatz mit den letzten Änderungen und überall fehlt der Link auf die Hilfeseite Hilfe:Beobachtungsliste, stattdessen gibt’s nen Link auf die Spezialseite.
Man muss sich manche Nachrichten genauer anschauen, da manche Seiten nur Steuerungen beinhalten die immer in der Inhaltssprache herangezogen werden, beispielsweise gadgets-definition und ein paar andere in deiner Auflistung. Andere werden nur unangemeldeten Benutzern angezeigt, brauchen daher auch nicht in allen Sprachen vorliegen, da diese eher weniger mit de-ch unterwegs sind. Der Umherirrende 19:50, 22. Jun. 2013 (CEST)
Jo, dachte mir schon, dass da irgendwo noch so was dabei sein könnte, war mir nicht überall sicher und hab sie halt im Zweifel mit aufgelistet. Kannst so was ja dann dabei weglassen. Welche wären das denn noch so? Alle Seiten für anonyme Benutzer also jedenfalls, die mit den Steuerungen krieg ich nicht so auseinanderdividiert. --Geitost21:00, 22. Jun. 2013 (CEST)
MediaWiki:searchresulttext: prettytable => wikitable, prettytable ist veraltet und sollte zumindest mal endlich auf den MW-Seiten raus. Ist auch sonst nur noch bei der commons.css drin und dort ist das wohl beabsichtigt.
gudn tach!
hab ich das richtig im kopf, dass du dev bist? kannst du zu meinem request bzgl. einer zusaetzlichen variable von abusefilter system messages
[20] was sagen? soll ich dafuer ein ticket im bugtracker aufmachen? -- seth10:44, 30. Jun. 2013 (CEST)
Ja, ein Ticket macht wohl am meisten Sinn. Ich kenne die Extension nicht gut und habe keine Testumgebung dafür, so dass die Änderung bei mir viel länger dauern würde, als bei jemandem der sich auskennt. Der Umherirrende 17:06, 30. Jun. 2013 (CEST)
Bitte Vorlage und Diskussion wiederherstellen und entsperren, damit die Vorlage repariert und wieder benutzt werden kann. Ich begreife wirklich nicht, was Benutzer:Friedrich K. dazu treibt, eine Softwarefunktion so penetrant zu „bestalken“ und ausmerzen zu wollen. Was hat er davon? Viele Benutzer haben viel Zeit in die Verbesserung der PDF-Ausgabe gesteckt. Was ermächtigt ihn dazu, das mal eben für hinfällig zu erklären? Fehler in der Software müssen repariert werden, nicht systematisch ausgelöscht. MediaWiki:Coll-exclusion category title existiert weiterhin und verweist auf Kategorie:Vorlage:Vom Druck ausgeschlossen. Bugzilla:48052 ist unbeantwortet. Ich versuche gerade, per Mail zu den Entwicklern der Erweiterung durchzudringen, erhalte aber leider nur Antworten, die genauso kurz und unklar sind wie das Changelog. Warum die offenbar kaputte Extension überhaupt auf die Wikimedia-Server ausgeliefert wurde, konnte ich noch nicht herausfinden. --TMg14:20, 30. Jun. 2013 (CEST)
+1 – siehe 2 drüber #3
Wir sollten hier zukünftig zweigleisig fahren und nach und nach überall die class="noprint" reinschreiben; egal ob das PDF-Kategorie-Dings nun funktioniert oder nicht. In der HTML-Druckversion soll das in aller Regel auch nicht auftauchen. Wenn es gleichzeitig über die Kat vom Export ausgeschlossen wird, schadet das nicht. Ich vermute aber, die bekommen ihre Vorlagen-Kat-Abfrage so schnell nicht wieder hin; es würde mit Parsen im Zusammenhang mit Scribunto zusammenhängen.
Vorlagen und Textelemente, die mit class="noprint" gekennzeichnet sind, wurden aus dem Dokument ausgeschlossen.
Nebenbei sollte nach der PDF-Generierung und vor dem Herunterladen angezeigt werden, wie viele MB in etwa zu erwarten sind. Aber das wäre irgendwann eine Anmerkung zu einem Bugzilla, wenn man mit den PDF-Export-Entwicklern am Plaudern ist.
Unsere ganzen QS-Vorlagen sollten individuelle Ausprägungen einer Mutter-Vorlage mit Kategorisierung usw. werden; dazu gab es in der Vorlagen-Werkstatt schon einmal eine Initiative. Aber ich werde mich nicht mit 80 durcheinandermotzenden Portalen anlegen.
Von Friedrich K. habe ich mir in Gold gerahmt den Spruch „Anscheinend wurde die Problematik noch nicht von allen Interessenten verstanden.“
Hallo TMg, nach Aussage der Extension-Programmierer ist die Funktion der Druckausgabe-Verhinderung über die Kategorie entfallen (und nicht kaputt), daraus ergibt sich auch, das Vorlage:ImDruckVerbergen nicht mehr funktioniert, da sie darauf beruht, das ihr Aufruf samt Parameter beim Erzeugen des PDFs entfällt. Durch Lua ist das ganze aber wohl etwas schwieriger, daher wurde auf diese Kategorie verzichtet und die besagte Vorlage funktioniert nicht mehr. Zum Zeitpunkt des Löschens war die Vorlage bereits in keinem Artikel mehr benutzt worden. Es ist aber schwierig zu sagen, wann sie wo entlinkt wurde. Ich denke, es ist weniger Hilfreich, wenn man in der Vorlage den Paramter mit einem span/div und class=noprint versieht, weil es je nach Kontext halt ein Block oder ein Inline-Element sein muss. Das kann man auch direkt an der entsprechende Stelle schreiben.
Die Programmierer müssten noch die Hinweise auf der Statusseite anpassen, das ist richtig. Der Umherirrende 16:17, 30. Jun. 2013 (CEST)
„nach Aussage der Extension-Programmierer“. Es gibt keine belastbare Aussage der Programmierer. Weder eine Google-Gruppe noch Mails, die niemand kennt, taugen als Beleg. Es ist unklar, ob die in den Wikimedia-Projekten laufende Version der Erweiterung identisch mit der bei PediaPress ist und überhaupt leuchtet mir nicht ein, wie und warum ein solcher Breaking Change offenbar vollständig undokumentiert und damit auch ungetestet ausgeliefert werden konnte. Aus den E-Mail-Antworten der PediaPress-Leute und eigenen Tests ergibt sich nun, dass auch die alternativen Druck-Untervorlagen nicht mehr funktionieren – ein Feature, für das es nicht einmal einen Workaround gibt. Mein Bugreport würde nicht beantwortet, weil man das Bugzilla-Passwort verloren hätte und außerdem der Meinung sei, der eine vage Kommentar da hätten das Problem abschließend geklärt. Das lässt mich alles ziemlich fassungslos zurück. Ich habe nicht unerheblich viel Zeit dafür aufgewendet, die PDF-Ausgabe für verschiedene Vorlagen zu optimieren. Mit welchem Recht wird das in die Tonne gekloppt?
„daraus ergibt sich auch, das Vorlage:ImDruckVerbergen nicht mehr funktioniert“. Kaputte Vorlagen werden nicht gelöscht sondern repariert. Das hätte längst jemand getan, wenn sie nicht gesperrt wäre.
„Zum Zeitpunkt des Löschens war die Vorlage bereits in keinem Artikel mehr benutzt worden“. Ja, weil sie ausgemerzt wurde, obwohl in den Diskussionen mehrfach um Geduld gebeten wurde.
„Das kann man auch direkt an der entsprechende Stelle schreiben“. Ja, kann man. Na und?
Hier ein Beispiel dafür, wer hier „die Problematik noch nicht“ im vollen Umfang überblickt. Ich sage, dass der Code <div class="noprint">…</div> nicht in Artikeln stehen sollte. Die Vorlage mag trivial erscheinen, aber sie ist für die meisten Gelegenheitsautoren, die keine Ahnung von HTML und CSS haben, viel weniger fehleranfällig, sie ist viel leichter verständlich und viel leichter zu ändern, wenn sich die zugrunde liegende Technik wieder einmal ändern sollte. Nachdenken könnte man über einen vielleicht noch besseren Namen. Vorlage:Nicht drucken? Aber auch in diesem Fall wäre mir lieb, wenn man die Versionsgeschichte und vor allem die Diskussionen zu dieser Vorlage nachvollziehen könnte. Ich bitte deshalb nochmals um Wiederherstellung. --TMg18:24, 30. Jun. 2013 (CEST)
Die Erweiterung Collection nutzt mwlib als Renderengine (siehe mw:Extension:Collection#Documentation & Support). Dieses externe Modul wurde am 26. März 2013 auf Version 0.15.4 geupdated (siehe wikitech:Server Admin Log#March 26). Das an mehreren Stellen verlinkte Change Log zur Version 0.15.0 enthält den Hinweis "Unfortunately the ‘template blacklisting’ and ‘print templates’ functionality had to be removed in order to support the scribunto extension. The documentation has not been updated and may still mention those features.". Die Aktualisierung von mwlib wurde gemacht, damit Vorlagen, die auf Lua basieren wieder funktionieren, das dabei die Druck-Untervorlagen und die oben genannte Kategorie entfallen ist, ist schade, da stimme ich dir zu, ist aber nicht mehr rückgängig zu machen. Eine bessere Informationspolitik von PediaPress wäre hier auch von Vorteil gewesen.
Für mich stellt sich eh die Frage, ob die Vorlage für die direkte Verwendung im Artikel angelegt wurde und ob man damit einen Weblinks-Abschnitt oder einzelne Dateieinbindungen vor dem Drucken ausblenden sollte. Dies ist aber wohl persönlicher Geschmack. Der Umherirrende 20:28, 30. Jun. 2013 (CEST)
Das Changelog wurde erst gestern oder vorgestern nachträglich verändert, weil ich den Entwicklern per E-Mail auf den Geist gegangen bin. Dass die Druck-Untervorlagen ebenfalls in die Tonne gekloppt wurden, dürfte jedem hier neu sein, sogar Benutzer:Friedrich K. Den Abschnitt hat er nämlich noch nicht aus der Hilfe gelöscht. Von Alternativen und dem weiteren Vorgehen ist nach wie vor nirgends die Rede. Auf meine entsprechenden Fragen per E-Mail habe ich gar keine Antwort mehr erhalten. Auch zuvor war man wie schon gesagt extremst wortkarg. So kann ich nur rätseln, was hier warum unter den Teppich gekehrt werden soll. Dass diese Intransparenz hier Unterstützung findet und alles, was auf die Sache hindeutet, ausgemerzt wird, inklusive der stumpfsinnigen Substituierung unerwünschter Vorlageneinbindungen, stört mich erheblich. Ich bitte weiterhin um Wiederherstellung. Dass eine Vorlage falsch verwendet wird, heißt nicht, dass sie nicht sinnvoll verwendet werden kann. Es kann beispielsweise sehr wohl sinnvoll sein, ein Video auszublenden, das nur in Bewegung Sinn ergibt. --TMg23:05, 30. Jun. 2013 (CEST)
Also, ich hatte bei der Weiternutzung der Vorlage nur an <span> gedacht, weil ein komplexes <div> als Vorlagenparameter mit Tabellen-Pipes sowieso unzumutbar ist; Blöcke müssten dann schon per HTML ausgeschlossen werden, falls irgendwer seinen Lieblingsartikel mal ganz besonders PDF-gerecht aufbereiten möchte. Und die Vorlage ist nur eine kleine Freundlichkeit gegenüber den Autoren hinsichtlich Syntaxverständlichkeit. Bislang wurde sie anscheinend eher in Vorlagen oder Unterseiten hineingesetzt und sollte diese über den Kategorie-Trick komplett ausblenden; um nur einzelne Elemente eines Textes zu verbergen, war sie doch bisher nicht geeignet gewesen? VG --PerfektesChaos23:29, 30. Jun. 2013 (CEST)
Wenn es euch hilft: Ich habe die Vorlage und die Diskussionsseite wiederhergestellt. Da ein Seitenschutz eine Seitenlöschung nicht überlebt, ist die Seite jetzt auch für die allgemeine Bearbeitung geöffnet. Der Umherirrende 19:11, 1. Jul. 2013 (CEST)
Danke. Nicht, dass du meine Reverts falsch verstehst. Ich gehe von einem Missverständnis aus. Vielleicht hilft der Vergleich: Du würdest doch auch nicht die Kategorie:Vorlage:nur Subst entfernen, weil die Kategorie keine Substituierung auslöst sondern die Vorlagen statt dessen subst: verwenden? Zur weiteren Diskussion würde ich jetzt die entsprechenden Diskussionsseiten vorschlagen. --TMg20:02, 1. Jul. 2013 (CEST)
LG Lady Whistler ☎/± 17:56, 6. Jan. 2013 (CET)
rechts oben wie bei den anderen Seiten; durchschaue aber nicht, wo uns was technisch möglich ist.
| 
) einfach mal umsetzen, sowie Tooltips implementieren? --Mai-Sachme (Diskussion) 22:27, 26. Feb. 2013 (CET)
sollte imho jedenfalls auch deutlich vom Geohack abgetrennt werden, weil es derzeit irgendwie als zum Geohack dazugehörend wahrgenommen wird. --Mai-Sachme (Diskussion) 21:35, 27. Feb. 2013 (CET)
Xfkbg - Disk 19:06, 13. Mai 2013 (CEST)
Xfkbg - Disk 19:15, 13. Mai 2013 (CEST)
(CallMyCenter) 23:03, 5. Jun. 2013 (CEST)
![[1]](https://upload.wikimedia.org/wikipedia/commons/3/30/SUL_finalization_de_2.0.svg){kind=link}
