Benutzer Diskussion:Umherirrender

^{SUL-Übersicht}

Willkommen auf meiner Diskussionsseite.
Falls du Fragen oder Anregungen/Kritik hast, dann hinterlasse mir eine Nachricht.

Der Umherirrende

Automatische Archivierung

Auf dieser Seite werden Abschnitte morgens automatisch archiviert, deren jüngster Beitrag mehr als 7 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten.

Archiv

Beiträge 2007 Beiträge 2008 Beiträge 2009-1 Beiträge 2009-2 Beiträge 2010-1 Beiträge 2010-2 Beiträge 2011-1 Beiträge 2011-2 Beiträge 2012-1 Beiträge 2012-2 Beiträge 2013-1 Beiträge 2013-2

Wie wird ein Archiv angelegt?

Editnotice

Danke. Habe auch den sperrenden Admin gebeten, die Vollsperre aufzuheben. Mal gucken, ob die Editnotice hilft. Anka ☺☻Wau! 10:22, 28. Jun. 2013 (CEST)

Keine Ursache. Der Umherirrende 14:08, 28. Jun. 2013 (CEST)

Tipp zu mwGit, und mehr

1. Betr: +git commit link
   • Diese beiden Aufrufe sind nahezu wirkungsgleich:
     1. b0455df
     2. rMWb0455df
   • Aber der zweite ist für Schreibfaule.
2. Bitte mal edit=halb + move=sysop für
   • Modul:Multilingual/codes
   • Modul:URIutil
   • Modul:URIutil/config
   • Modul:URIutil/isbn
3. Machst du bitte die Vorlage:ImDruckVerbergen auf?
   • Du kannst auch gleich selbst die class="noprint" reinschreiben, damit das Teil wieder einen Sinn bekommt.

Gute Nacht --PerfektesChaos 00:18, 29. Jun. 2013 (CEST)

Erledigt. Der Umherirrende 10:09, 29. Jun. 2013 (CEST)

neue variable in system message

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 [1] was sagen? soll ich dafuer ein ticket im bugtracker aufmachen? -- seth 10: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)

ok, bugzilla:50464. -- seth 18:28, 30. Jun. 2013 (CEST)

Vorlage:ImDruckVerbergen

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. --TMg 14: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.
• Die MediaWiki:Coll-excluded-templates sollte einstweilen aktualisiert werden auf:
  • 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.“
• Danke für das Schützen der Module im Übrigen.

Schönen Sonntag --PerfektesChaos 14:48, 30. Jun. 2013 (CEST)

Zitate bitte möglichst immer mit Quellenangabe verwenden. Danke und schönen Sonntag! --Friedrich K. (Diskussion) 15:29, 30. Jun. 2013 (CEST)

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?

--TMg 17:27, 30. Jun. 2013 (CEST)

[[[:Vorlage:Fullurl::]] 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 [[[:Vorlage:Fullurl::]] 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. --TMg 18: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. --TMg 23: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 --PerfektesChaos 23: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. --TMg 20:02, 1. Jul. 2013 (CEST)

noexternallanglinks in Archiven

Hei Umherirrender, ich hab mal die Spezialseite Spezial:Seiten mit Eigenschaften etwas ausprobiert und dabei dies gefunden: Findest du das tatsächlich sinnvoll? Das produziert wahrscheinlich zehntausende (oder wie viele auch immer) Einträge hier von lauter Disks (in Nicht-Wikidata-Namensräumen), die allesamt keine externen Links haben, die ausgeblendet werden müssten. Gibt es denn überhaupt ein einziges Beispiel dafür, dass in WP-Archivseiten externe Links von Wikidata angezeigt würden – denn auf den normalen Disks wird bei Wikidata ja eh nix eingetragen und auch sonst werden doch Archivseiten nie mit Interwikis versehen. Ich habe den Eindruck, dass das ziemlich unsinnig so ist.

Immerhin werden in der Archivvorlage nun die ganzen zugehörigen Interwikis zur Archivvorlage von Wikidata (d:Q6068612#sitelinks) nicht mehr angezeigt – man müsste die also dann per Hand wieder reinsetzen und auch aktuell halten. Also gleich 2 Dinge, die dagegen sprechen. Umgekehrt hab ich in einem WP-Archiv noch nie einen externen Interwikilink gesehen. Und wenn da mal ausnahmsweise was falsch sein sollte, dann sollte man das entweder auf Wikidata korrigieren oder in der speziellen Archivseite noexternallanglinks reinsetzen, aber dafür muss man doch nicht so viel Störendes produzieren, oder? Viele Grüße --Geitost 15:43, 2. Jul. 2013 (CEST)

Ich hab jetzt erst mal die Interwikis alle wieder reingepackt, die ja bereits nach Wikidata exportiert worden waren, damit man die zumindest wieder angezeigt bekommt (eo:, es: und it: waren noch drin, aber waren nur WL, die hab ich aktualisiert). Wenn noexternallanglinks aus der Archivvorlage wieder rauskommt, können die Interwikis alle aus der Metaseite raus, da sie allesamt auf Wikidata sind. Jedenfalls hab ich noch nicht gesehen, dass es bei noexternallanglinks in der Vorlage überhaupt irgendeinen Vorteil gibt neben den ganzen Nachteilen. Aber vielleicht weißt du da ja mehr? --Geitost 16:01, 2. Jul. 2013 (CEST)

Wie im Bearbeitungskommentar angedeutet, wollte ich nicht, das bei Archivseiten von Seiten in Nicht-Diskussionsnamensräume ein WikiData-Item-Erstell-Link auftaucht. Also bei den Archiven von WP:Fzw, WP:AA, WP:AN usw. Dort besteht keine Notwendigkeit Wikidata-Item anzulegen. Da das aber im Moment eh nicht auftaucht, kann das unproblematisch rückgängig gemacht werden. Das die Verwendung auf einer Spezialseite auftaucht, sollte aber kein Grund dafür sein, weil man dann auch viele andere Sachen verbieten sollte, die Einträge in Datenbanken hinterlassen und somit auf Spezialseiten automatisch auftauchen. Die Spezialseite ist ein nettes Spielzeug, man sollte es aber auch nicht übertreiben und sie "sauber" halten. Der Umherirrende 18:38, 2. Jul. 2013 (CEST)

Ich hatte deinen Bearbeitungskommentar anders verstanden. Dass du von Wikidata automatisch eingeblendete vorhandene Interwikilinks in Disk.-Archiven im WPNR damit ausblenden wolltest. Denn wenn keine solchen von Wikidata eingebundenen Interwikis vorhanden sind, gibt es ja auch keinen Link auf einen nicht vorhandenen Wikidata-Eintrag. Kann man noch mal drüber nachdenken. Ich hatte gestern noch mal mit Spezial:Nicht verbundene Seiten rumprobiert, was ja ein paar Bugs hat. Dabei findet man mit diesem Link sämtliche Seiten im WPNR mit Interwikilinks auf der Seite (also nicht die über Wikidata eingebundenen). Demnach gibt es also auch in einigen Disk.-Archiven Interwikilinks. Das sind dann allerdings wohl eher Fehlverlinkungen in den Seiten wie in Wikipedia:WikiProjekt Marxismus/Café/Archiv/2011, das auf den engl. Artikel en:Barry Eichengreen verlinkt statt auf ein Disk.-Archiv (wo also irgendwer den Doppelpunkt vergessen hat, was ja öfters mal vorkommt). Also zu korrigierende Links. Man müsste die Archivlinks unter dem Link mal alle auf so was hin durchsehen. Das würde dann aber auch für andere Disk.-Archive gelten, die nicht auf der Spezialseite verlinkt werden. Hingegen sind reguläre Links über Wikidataeinträge auf andere Disk.-Archive in anderen Sprachversionen wohl eher selten. Und entweder wäre so was dann als Fehlverlinkung zu korrigieren oder es wäre ein korrekter Link. Insofern sollten solche Links besser normal dargestellt werden, denk ich. Könnte man eigentlich alle Nicht-Artikelseiten automatisch auflisten, die einen Interwiki auf einen Artikel enthalten, damit die mal allesamt korrigiert werden (und nicht nur diese WP-Archive)?

Und hinzu kommt halt noch, dass die Interwikilinks, die nun über die Unterseite Vorlage:Archiv/Meta eingebunden werden statt direkt von Wikidata dargestellt zu werden, auch veralten und nicht gepflegt werden. Also spricht mMn auch unabhängig von den vielen Einträgen auf jener Spezialseite (was nicht einzig ein Grund für die Entfernung sein sollte) auch alles Andere dafür, noexternallanglinks besser aus der Vorlage wieder rauszunehmen. Oder ist so ein Erstelllink für Seiten, die noch gar nicht bei Wikidata eingetragen sind, evtl. noch (jetzt bzw. bald) geplant? --Geitost 13:51, 3. Jul. 2013 (CEST)

PS: Hatte noch gar nicht gesehen, dass du das ja bereits revertiert hast. Hab dann mal die lokalen Interwikis alle wieder rausgenommen. Ist denn so ein Erstelllink noch geplant? --Geitost 16:03, 3. Jul. 2013 (CEST)

By the way: Kannst du bitte den Interwikilink in der vollgeschützten AK-Archivseite Wikipedia:Adminkandidaturen/Archiv/2003 fixen, der völlig falsch auf en:Wikipedia:Database queries verlinkt? --Geitost 13:55, 3. Jul. 2013 (CEST)

Und aus dem Versionsarchiv Wikipedia:Adminkandidaturen/Alt01 sollten alle 10 falschen Interwikis entfernt werden, die vor der Verschiebung von Wikipedia:Administratorkandidaturen in ein Versionsarchiv noch richtig verlinkten. Ich denke, das ist nicht so gedacht mit der Verlinkung. --Geitost 14:06, 3. Jul. 2013 (CEST)

Übrigens: Auf der Spezialseite sind nun wegen dieser Rückänderung nur noch 4 Einträge (statt viele Tausende), das ist doch ein Riesenunterschied. So kann man dort auch direkt wieder sehen, wenn irgendwo ein noexternallanglinks-Tag drinsteht, man kann sie also wieder gebrauchen. :-) Das ist wirklich besser so.

Zurzeit ist das Tag außer der Hauptseite nur in 3 BNR-Seiten eingetragen, die allesamt Alternativvorschläge für die Hauptseite sind. Was ist eigentlich davon zu halten, dass alle 3 dieser BNR-Seiten die Hauptseiten-Interwikis normal enthalten, also auch direkt wie die Hauptseite auf die anderen Hauptseiten verlinken? Sollte man nicht auch dort die Interwikis alle entschärfen wie sonst ja auch im BNR üblich? --Geitost 16:12, 3. Jul. 2013 (CEST)

Ob ein solcher Erstelllink geplant ist, weiß ich nicht, nur meinte ich, das zum Zeitpunkt des einfügens auch ein WikiData-Link da war, ob er funktioniert hätte, kann ich aber nicht sagen.

Dieser Api-Query bietet die Möglichkeit, für alle Vorlagenverwendungen der Archiv-Vorlage die langlinks aus der Datenbank anzuzeigen. Da dort nur 500 angezeigt werden, werde ich noch ein Skript basteln, was dann die nächsten Seiten blättert und mir eine Liste erzeugt, so dass ich entsprechend die Seiten bearbeiten kann. Die hier genannten Seiten habe ich schon bearbeitet. Auf Seiten im Diskussionsnamensraum ist es üblich, das Interwikilinks ohne Doppelpunkt wie normale Links auf Schwesterprojekte behandelt werden, daher gibt es dort die Fälle nicht. Da nur im Wikipedia-Namensraum auch auf der Projektseite direkt diskutiert wird, brauch man sich nur diesen Namensraum anschauen. Der Umherirrende 19:38, 3. Jul. 2013 (CEST)

Ich sehe aber jetzt auch wieder Bearbeitenlinks für WikiData bei den Archiven, vermutlich ist das mit JavaScript, daher siehst du es nicht, aber es ist da. Der Umherirrende 20:04, 3. Jul. 2013 (CEST)

Oh, tatsächlich? Mmh, das ist ja blöd. Bei mir steht immer nur „Links bearbeiten“, wenn es einen WD-Eintrag gibt, ansonsten steht dort „In anderen Sprachen“ und die zugehörigen lokalen Interwikis, sonst nix. Und wenn es gar keine Interwikis gibt, dann steht dort auch wie jetzt bei Wikipedia:Adminkandidaturen/Alt01 „In anderen Sprachen“ und ein leerer Kasten darunter. Also auch wieder Geskriptetes. Mmh, und nun? Könnte man diese Erstelllinks auf Archivseiten nicht evtl. auch auf andere Weise automatisch ausblenden, beispielsweise über die commons.js, wenn das eh nur mit JS sichtbar ist? --Geitost 20:20, 3. Jul. 2013 (CEST)

(BK) Stimmt, du hast Recht (mit den Interwikis auf Disks). Hab ich schon ganz verdrängt, weil ich mich so an die Doppelpunkte überall gewöhnt hab. ;-) Dann betrifft das also hauptsächlich die WP-Seiten, die ja alle unter dem Link leicht aufzufinden sind – hab dort auch schon ein paar gefixt, anfangs waren es heute noch 688 Links, jetzt sind es schon unter 670. Bei den Links dort müssen aber auch noch etliche WD-Einträge neu erstellt werden, die noch fehlen. Jedenfalls sind dort noch etliche Seiten mit „Wikipedia:Archiv/“ oder „/Archiv“ im Lemma.

Und was ist mit BNR-Seiten? Dort werden ja auch oft ANR-Interwikis eingetragen, gerade bei Artikelentwürfen. Außerdem könnten da auch sonstige fehlerhafte Links als Interwikis drinstecken. Wie kriegt man die denn rausgefischt? Oder wären die bezüglich Wikidata egal (die Interwikibots können sich daran ja nicht mehr stören, war ja bisher ein Problem mit solchen Interwikis)? Und bei den 3 BNR-Seiten, sollte da auch die Vorlage entschärft werden, die die Hauptseiteninterwikis einbindet? Was meinst du? Oder ist das dort nun egal seit Wikidata? Bin da etwas unschlüssig. --Geitost 20:20, 3. Jul. 2013 (CEST)

Benutzerseiten bekommen auf WikiData kein Item und die Namensraumkonflikte sollten Bots da direkt feststellen. Man kann sie aber auch problemlos entfernen, Interwikilinks auf Artikelbaustellen werden auch schon seit längerem von KrdBot entlinkt. Der Umherirrende 20:25, 3. Jul. 2013 (CEST)

Ja, dann werd ich die Vorlage eben einfach auskommentieren. In welchen NR werden denn diese Erstelllinks angezeigt? Nur in den wikidata-relevanten, wo auch „In anderen Sprachen“ erscheint? Im BNR ist das anscheinend nicht der Fall, dort und auch auf den Disks erscheint das nicht. --Geitost 20:33, 3. Jul. 2013 (CEST)

Macht ja nur in WikiDate-relevanten Namensräumen Sinn, daher wird das auch nur dort angezeigt.

Ich habe die Hauptseiten-Interwikis schon entfernt. Der Umherirrende 20:35, 3. Jul. 2013 (CEST)

Ok, ja, hab Letzteres dann auch gemerkt. ;-) Bei den 23 gelisteten LK-Tagesseiten sind die Interwikis wohl auch alle verkehrt. Schon unter 620, geht ja fix bei dir. So was ist aber hier mit dem Browser auch sehr umständlich, weil ich irgendwie nicht nach einem Wort innerhalb des Bearbeitungsfensters suchen kann und dann also erst den Text rauskopieren und extern danach suchen muss. Das dann dort korrigiert wieder einzufügen, geht auch nicht, weil es dann automatisch überall lauter Leerzeilen dazwischensetzt. Also muss ich dann im Bearbeitungsfenster per Hand suchen (unter Vergleich mit dem externen Fenster, damit es schneller geht). Das sollte ich mir besser ganz sparen und dir und anderen überlassen, dann geht es fixer. Unnötiger Mehraufwand. Sollte mir besser die Nichtarchivseiten ansehen und neue Datensätze erstellen, wo es noch keine gibt, das geht ja zumindest auch neuerdings ohne Skripte. --Geitost 21:05, 3. Jul. 2013 (CEST)

Der Internet Explorer kommt mit den großen Seiten auch nicht zurecht und geht in die Knie. Der FireFox schafft das besser, da geht auch die Browsersuche. Daher kann ich das ganze direkt im Browserfenster korrigieren. Man muss dann nur erst auf Vorschau gehen, weil es könnten auch noch andere Interwikilinks drin sein, die nicht gezählt werden, weil pro Sprache ja nur ein Link vorhanden sein darf. Der Umherirrende 21:12, 3. Jul. 2013 (CEST)

Ja, das Letzte ist mir heute auch schon zum ersten Mal aufgefallen. Wusste bislang gar nicht, wie MW darauf reagiert, wenn 2 verschiedene Links zur selben Sprache enthalten sind, aber offensichtlich wird dann immer der erste genommen. Jedenfalls danke fürs Fixen, damit hat de: dann heute etliche übrig gebliebene Interwikilinks weniger in den Seiten. :-) --Geitost 21:16, 3. Jul. 2013 (CEST)

MediaWiki hat auch mal beide Links angezeigt, aber immer nur den ersten in der Datenbank gespeichert, was einige Interwikibots auch durcheinander brachte. Dann hat man aber auch die Anzeige des doppelten Interwikis unterdrückt.

Sind jetzt bei 565 Einträgen und die Archive sind aus meiner Sicht erledigt. Der Umherirrende 21:54, 3. Jul. 2013 (CEST)